 One of the most dramatic moments in Apollo 11's already pretty dramatic first lunar landing was when the 1201 and 1202 program alarms threatened to force an abort at the last second before touchdown on the moon, but the crew didn't have to abort. Instead, they were able to reboot the lunar module's computer and continue the landing mission safely, and it all came down to a man no one's ever heard of, Hal Lanning. In 1957, when the Soviet Union launched history's first artificial satellite, Sputnik, J. Halcom Lanning, who went by Hal, was a 10-year veteran at the MIT Instrumentation Lab, now known as Draper for its founder, Dr. Charles Stark Draper. As it did for scientists nationwide, Sputnik opened the potential for Lanning to use his engineering background to explore the new ocean of space. Lanning had a unique background to bring to this new challenge of the space age. He'd previously worked on the guidance system for the Polaris missile. Polaris, it's worth noting, was more than just a missile. It was launched from a submarine, which meant that its internal guidance system had to know where the missile was and where it was going in spite of swelling seas. That meant that it had to have a fixed base as a reference point, something that was achieved via a gyroscope establishing the inertial platform on board. This is an oversimplification, but between the gyros and the onboard computer, Polaris could get to where it was going. It was actually half analog with a digital differential analyzer. It needed both analog guidance logic and digital logic, and that was Lanning's element. It wasn't long before Lanning began applying his background to studying a potential mission to Mars. The idea was to develop a simple satellite with a gyroscope at its core to keep the whole thing stable in flight, an optical sighting system to gather navigational data points and a digital computer to manage everything. The idea was that the optical system could take in-situ measurements and feed the data to the computer for a running check of the spacecraft's position. In this way, it could self-maintain its navigation. This of course went against both NASA's and the U.S. Air Force's idea that a human onboard the spacecraft would bring necessary reliability. But it wasn't enough for the computer to run checks on the spacecraft's position. The computer's ability to check the spacecraft's position in real time meant that it could choose any alternate course of action at any point in the flight, essentially real-time thinking and reacting to changes. All of this early work on a Mars mission remained theoretical until April of 1961, when Robert Chilton from NASA visited the instrumentation lab. The space agency was starting to figure out how it was going to get to the moon. Yes, though Kennedy hadn't announced the moon landing yet, NASA was already considering it as the next step, and the team at the instrumentation lab was known for solving these kinds of problems. Chilton was impressed with the team there, including landing, and immediately saw the potential to parlay the early work on the Mars mission into Apollo. Because even though there would be men on board, there would be so much to do to keep the spacecraft on target that it made more sense to make it as automated as possible. When some of that Mars team got to work on the guidance program from Apollo, how landing reprised his role as the man behind the digital computer. He brought his Mars heritage to Apollo. The computer developed was a three layer computer system. At the bottom, ruling all the low level instructions, was a computer language called BASIC, all lowercase, not to be confused with the algebraic compiler programming language called BASIC, all caps developed in the 1970s. Every line of code in landing's BASIC equated to one command to the computer, making it an assembly level language, convenient for computer experts to use, but a really steep learning curve for engineers who thought in vectors and matrices rather than in registers shuffling bits around. A much larger and heavier computer could have provided a large variety of more engineering friendly commands, but under the given constraints, the only way to provide such commands was by emulating them in software, a system called an interpreter. Fortunately, the higher math operations like calculating a mid-course correction burn could tolerate the slower operation of the emulated commands, so landing's interpreter made a workable second level. Running above the two command levels, BASIC and interpreter, was the executive. The executive program determined the order in which each program ran. Taken together, the interpreter and the executive were the equivalent of the operating system for the Apollo guidance computer, and it wasn't by accident that landing named both after human jobs. His idea was that just like people in the lab talk and follow hierarchy, so too with the programs in a computer. But there's an element in landing's executive program that made it not only revolutionary, but vital to Apollo's success. In the early 1960s, programs in real-time computers kept it simple by running like a washer and dryer. Each program step takes its set amount of time and you run them in a fixed sequence, but landing didn't like that approach. He knew that there would be more urgent matters on an Apollo flight, such as astronaut commands and data uplinked from the ground, and also variable timing for running necessary programs. So he developed the executive to add an asynchronous element to the computer. At any given instant, the computer could work on only the highest priority programs, but events could change those priorities multiple times a second, and it was the executive dogs to halt one program and run another accordingly. To the human operator, it looks like the programs were running simultaneously, but the computer was actually swapping between programs every few seconds, so it only looked simultaneous, but it didn't matter. It was fast enough for the spacecraft and its crew. What the executive effectively did was to run programs in their priority order. This kept resources clear for critical programs at critical moments. The drawback was that it was, to some extent, unpredictable. There was some concern that a bug or an unanticipated situation could make the computer unable to proceed. The solution was an auto-restart function that could reboot the computer without the executive losing track of what it was supposed to be running. So what do those 1201 and 1202 program alarms have to do with any of this? As Apollo 11 was getting close to touching down on the moon, the rendezvous radar, not even in use at that time, was in a rare abnormal state that falsely made it pour bits into the computer at the maximum rate, wasting over 13% of the computer's time. The executive found that there were no more spaces in the computer to run new steps of essential programs. This triggered the 1201 alarm signaling executive overflow, no core sets, and the 1202 alarm signaling executive overflow, no vac areas. These, in turn, triggered a software reboot, which was landing's failsafe. All jobs were canceled regardless of priority and then started again in priority order, quickly enough that no guidance or navigation data was lost. But it didn't clear up the issue. The computer was still overloaded by the same spurious radar data, stopping new program steps from running. In all, it triggered four 1202 alarms and one 1201 alarm. Eventually, Buzz Aldrin noticed that the 1202 came up when they entered the verb 16 noun 68, a program that would display the range to the landing site and the ellen's velocity. The command itself didn't place a heavy load on the computer, but with the existing load, that extra bit of processing power seemed to trigger the 1202 alarm. Realizing this, the solution was simple. Ask Houston for the data instead of calling it up from the computer. Houston, as we know, gave Apollo 11 a go on all five 1201 and 1202 alarms. If those alarms had been closer together, it could have wiped out navigation data during a reboot. But being separated by even a few seconds meant that the vital information was retained. It also helped that the spacecraft computer rebooted about 10,000 times faster than a desktop PC does now. Effectively, it was landing's foresight that allowed the ellen computer to reboot itself in a matter of milliseconds while still flying. The priority scheme worked. Thanks to Draper's Hack the Moon initiative for making this video possible. To find out more about Draper's role in getting Apollo astronauts to the moon, check out wehackthemoon.com. To cite Chronicles, the engineers and technologies behind the Apollo missions, is full of thousands of never-before-seen images, videos, and stories about the people who hacked the moon. Be sure to check out wehackthemoon.com and for more vintage space every single day, be sure to follow me all across social media. And if this is your first time visiting vintage space, welcome and consider subscribing so you never miss an episode. Thanks and see you guys next time.