Three minutes before Eagle touched the Sea of Tranquility, the guidance computer inside the lunar module started shouting for help. A yellow warning light flashed on the display and panel. Buzz Aldrin read the code aloud: 1202. Neither he nor Neil Armstrong knew, in that instant, whether it meant continue or abort.
The computer did not crash. It did something stranger and more deliberate. It threw work away.
The reason it could do that — the reason Armstrong kept flying instead of pulling the abort handle — was a piece of software architecture Margaret Hamilton and her team at the MIT Instrumentation Laboratory had insisted on building: a priority scheduler that treated overload as a survivable condition rather than a failure. When a switch setting flooded the Apollo Guidance Computer with unexpected radar data, the machine shed lower-priority jobs, kept the landing functions running, and restarted cleanly enough to hold altitude, attitude, and descent rate steady. BBC Science Focus’s reconstruction of the descent puts the first alarm at roughly three minutes before touchdown, with additional alarms following in the next few minutes.
A 70-pound computer with almost no room to think
The Apollo Guidance Computer weighed about 70 pounds. It ran on core-rope memory, physically woven by hand at Raytheon. Its working memory was measured in kilobytes. It was expected to guide a spacecraft to a soft landing on another world while parsing telemetry, firing thrusters, updating the DSKY display, and doing dozens of housekeeping tasks in real time.
Hamilton became responsible for the onboard flight software in the mid-1960s. She had come from earlier computing projects, and she took over a discipline that did not yet have a name. She gave it one. The phrase software engineering became associated with her insistence that code deserved the same rigor as a combustion chamber or a heat shield.
The stack of listings she stood beside in the famous 1969 photograph flew inside two programs: Colossus in the command module, Luminary in the lunar module. Luminary was the one that had to land.
The switch that flooded the computer
The trouble began with a rendezvous radar. During powered descent, the radar was set to a position that kept it available in case Armstrong and Aldrin had to abort and climb back up to Michael Collins in the command module. That was prudent. What nobody had fully modeled was how the radar’s data stream, in that configuration, would interact with the guidance computer’s electrical timing.
The radar started stealing processor cycles. It was asking the computer to service interrupts it did not need to service during a landing. The Christian Science Monitor’s account of the descent describes how the extra load consumed a significant portion of the machine’s capacity — enough, on top of the descent workload, to push it over the edge.
The 1202 alarm meant executive overflow: the computer had more jobs queued than it had core sets to run them in. The related 1201 alarm meant a similar shortage of vector accumulator areas. Both said the same thing in engineering language. Too much work, not enough room.
What Hamilton’s team had built instead of a crash
A less thoughtful system would have frozen or reset with all state lost. The Apollo software did neither. It restarted cleanly, kept its critical data, discarded the low-priority jobs, and picked up where it had left off on the important ones.
That behavior traced back to an asynchronous executive designed around a scheme by J. Halcombe Laning at MIT. Every task had a priority number. When the queue overflowed, the executive dumped the lowest-priority jobs first and issued a restart. The computer, built this way, would keep doing what mattered most no matter how many lower-value jobs it had to drop along the way.
Landing functions — reading the inertial platform, running the guidance equations, driving the descent engine’s throttle, updating the pilots’ display — were high priority. The rendezvous radar’s stray inputs were not. The computer, in effect, chose the moon over the radar, over and over, five times in four minutes.
The decision in Houston
Mission Control had to decide what to do about the alarm before Armstrong needed to decide what to do about the ground. In the guidance back room, Jack Garman was the specialist watching the AGC. Steve Bales, the guidance officer at the front console, had to give a call to CAPCOM Charlie Duke, who had to relay it to Eagle.
Garman had seen a 1202 in simulation before. That day, the simulation supervisors had thrown a program alarm at the team, Bales had called an abort, and it turned out the abort had been unnecessary. The lesson was written down. Garman kept a list of alarm codes at his console. When the real 1202 came, he already knew: if the guidance data stayed stable, they could keep flying.
Duke communicated to the crew that they were cleared to continue despite the alarm.
A minute later, another 1202. Then a 1201. Then two more 1202s. Each one, the room held. Each one, Armstrong kept flying.
The daughter who crashed the simulator
Years before the landing, Hamilton had brought her young daughter into the lab on weekends. Her daughter, playing with the command module simulator, pressed a sequence of keys that crashed the program. Hamilton wanted the software hardened against that class of error. NASA’s initial position was that astronauts were trained not to make that mistake.
Then, on Apollo 8 in December 1968, Jim Lovell selected the pre-launch program mid-flight. The navigation data got wiped. Hamilton’s team spent hours reconstructing it from the ground. The point had been made in the worst possible way, and the safeguards Hamilton had asked for went into the code.
The story is not that Apollo software was perfect. It is that the people writing it assumed something would go wrong, and designed a machine that could keep working when it did. That habit is why the 1202 was survivable. The alarm did not mean the computer was broken. It meant the computer knew it was under stress and had a rehearsed response.
What was still ahead when the alarms stopped
The 1202 story sometimes gets told as if the alarms were the whole crisis. They were not. Once the computer stabilized, Armstrong looked out the window and saw that the automatic guidance was steering Eagle toward a boulder field near a crater later named West. He took semi-manual control and began flying laterally, hunting for a smoother patch.
Fuel margins collapsed. Duke called out fuel warnings as propellant reserves dwindled to critical levels. Eagle touched down with less than half a minute of hover fuel left. Armstrong’s manual flying, on top of the software recoveries, is what made the last minute possible.
Flight director Gene Kranz, interviewed by ABC News on the 50th anniversary, looked back on how closely the mission’s own training had anticipated that night’s crisis. “Our final training run, we exercised those alarms,” he told ABC News. “I always go back and I think what we would have done if we had seen those for the first time.”
Why the story keeps being told wrong
Popular retellings sometimes describe the 1202 as caused by a “checklist error” — Aldrin flipping the wrong switch. That framing has been picked apart by engineers who worked the mission. A discussion on Ars Technica’s forum on the Apollo software traces the actual cause to a subtle electrical phase mismatch between the radar and the AGC’s timing reference, a fault condition the crew’s checklist reflected but did not create.
The switch position was in the flight plan. The interaction it produced was not fully understood on the ground until after the landing. What saved the descent was not the crew avoiding the switch — they didn’t — but the computer being built to survive its consequences.
The other frequent flattening is to attribute everything to Hamilton alone. She led the software effort and made the calls that mattered, but the priority-scheduling architecture had older roots. Hal Laning’s executive design made bounded overload recoverable at all. Hamilton’s insistence was that the design be trusted, tested, and defended when NASA pushed back on adding what looked like paranoid safeguards.
Software as flight hardware
The reason Apollo software mattered as an engineering event, not just a computing event, is that it forced a discipline into existence. Before Apollo, code was often written informally, patched in flight, and treated as adjunct to the machine. After Apollo, at least at MIT and inside NASA, code was reviewed, versioned, simulated, and signed off with the same seriousness as a valve or a strut.
Spacewar has written before about what happens when that discipline is missing. Mariner 1 in July 1962 was lost partly because a missing overbar in a guidance equation slipped through review, sending the Venus probe off course 293 seconds after launch. The $18.5 million spacecraft was destroyed by range safety. Seven years later, on the descent to Tranquility Base, a computer built by people who had absorbed lessons like that one held together long enough to land two humans on the moon.
What the alarms actually protected
The 1202 and 1201 codes were not warnings that something might fail. They were confirmations that the failure mode Hamilton’s team had planned for had arrived, and that the plan was working. Each alarm meant the executive had shed a job, restarted, and resumed the critical loop. Each alarm was, in a real sense, the software announcing itself.
Hamilton herself later summarized the philosophy in a single line: the software discarded the lower-priority jobs and kept the higher-priority ones, including the landing functions. That is what the machine did on 20 July 1969, at roughly 300 metres above the lunar surface, five times in four minutes, while a rendezvous radar switch it could not turn off kept flooding it with data it did not need.
In 2016, President Obama awarded Hamilton the Presidential Medal of Freedom. The citation named her contribution to the moon landings. The technical version of that citation is shorter and lives inside Luminary’s source code, where a comment near the executive block still reads, in effect: if you cannot do everything, do the most important thing.
Fifty-seven years after the landing, the AGC listings are digitised and searchable. The rope memory modules sit in museum cases. The pilots are gone or aging — Armstrong died in 2012, Collins in 2021, Aldrin is 96. What still runs, in a way, is the idea their computer proved: that a well-designed machine, asked to do the impossible, can refuse gracefully, and that the refusal, done properly, is what success looks like.
