On 20 July 1969, about five minutes into the powered descent to the lunar surface, Neil Armstrong and Buzz Aldrin heard an alarm they had never trained for. The Apollo Guidance Computer, or AGC, flashed a “1202” program alarm, then a “1201”. In Houston, 26-year-old guidance officer Steve Bales had roughly fifteen seconds to decide whether to abort a mission that had left Earth four days earlier. He called “Go”. The computer was not broken. It was doing exactly what its designers had built it to do: shed low-priority work and keep flying.
That moment is the answer to how a machine with 2,048 words of erasable memory, about 4 kilobytes in modern terms and less silicon than the chip inside a singing greeting card, landed two humans on another world. The AGC was not powerful. It was disciplined.
What was actually inside the box
The Apollo Guidance Computer was designed at the MIT Instrumentation Laboratory under Charles Stark Draper, beginning in 1961. By the time of Apollo 11 it fit into a sealed magnesium box roughly 61 cm long, 32 cm wide and 17 cm deep, weighing about 32 kilograms. It drew around 55 watts, less than a modern laptop charger.
Its processor ran at 2.048 MHz and used a 16-bit word (15 data bits plus one parity bit). Memory came in two flavours. The erasable side, actual read/write RAM built from tiny ferrite cores threaded on wires, held 2,048 words. The read-only side, called core rope memory, held 36,864 words. That is roughly 72 kilobytes of program storage and 4 kilobytes of working scratch space to fly a spacecraft between two celestial bodies.
Core rope was extraordinary in its own right. A “1” bit was a wire threaded through a small ferrite ring; a “0” bit was a wire routed around it. The finished program was, quite literally, woven by hand, often by women from the Waltham, Massachusetts textile industry, and NASA engineers took to calling it “LOL memory” for “Little Old Lady memory”. Once woven, the software could not be changed. Every instruction that flew to the Moon on Apollo 11 had been physically threaded through metal donuts weeks earlier.
The trick was the operating system, not the hardware
If 4 kilobytes of RAM sounds impossible, that is because the usual mental model of a computer (one program running at a time, with the OS as passive housekeeper) is wrong for the AGC. Software architect Hal Laning at MIT built something closer to a modern real-time operating system, nearly a decade before that phrase existed.
The AGC ran up to eight jobs concurrently. Each job had a priority number. The executive scheduler, called the Executive, handed the processor to whichever job had the highest priority and needed to run. Lower-priority jobs waited. A companion routine, the Waitlist, handled short timed tasks. Together they let a 2 MHz machine juggle inertial navigation, radar tracking, throttle control, star sightings, and astronaut keyboard input as if it were doing them all at once.
Crucially, when the machine was overloaded, it did not crash. It restarted the lowest-priority jobs and kept the critical ones running. This is called restart protection, and it is exactly what saved Apollo 11.
What actually happened during the 1202 alarm
During descent, Aldrin’s checklist had the rendezvous radar switch in a position that fed the AGC data it did not need. The radar was tracking the command module still in orbit, in case of an abort. During this phase the processor was already running at nearly 85 percent of capacity, and the extra traffic pushed it to the edge.
The overload was not a useful flood of measurements. It was an electrical fault. The radar’s angle sensors were excited by one 800 Hz reference while the computer used another, and the two were never phase-locked, so the antenna appeared to jitter constantly. That phantom motion generated spurious counter-increment requests, as many as 6,400 per second on each of two channels, and every one stole a memory cycle. The MIT post-flight analysis put the added load at about 13 percent, just enough to prevent every scheduled task from finishing on time.
The codes themselves said as much. A 1202 meant “executive overflow, no core sets”; a 1201 meant “no vacant areas”. The computer was announcing, in its own terse vocabulary, that it had run out of room to track everything it had been asked to do.
The Executive detected that jobs were not finishing in their allotted time slots. Rather than seize up, it triggered a software restart, cleared the low-priority tasks, and re-launched the critical ones: guidance, throttle, and the astronaut display. The whole cycle took a fraction of a second. From Armstrong’s perspective, the DSKY (the display and keyboard unit) blinked, the alarm code flashed, and the landing continued. The computer restarted itself roughly five times during the descent. Each time, it kept flying.
On the ground, the calls came fast. Computer specialist Jack Garman, working a back room, had a handwritten cheat sheet of alarm codes under the plexiglass on his console, and he confirmed that as long as the alarm was not continuous, the AGC was recovering. Bales, who weeks earlier had called an unnecessary abort in a simulation over a similar alarm, relayed the “go” up the loop. Five program alarms fired in four minutes, and every one was cleared.
Don Eyles, one of the young MIT programmers who wrote the lunar landing software, has described in detail how the restart architecture was originally designed for hardware transients (cosmic ray hits, power glitches) and how it turned out to protect against software overload too. The AGC’s failure mode was, by design, “keep going”.
The cause was traced quickly, because the same computer still had to lift the crew off the Moon. Engineer George Silver worked out the radar interface phase problem, and before ascent Mission Control instructed Armstrong and Aldrin to leave the rendezvous radar circuit breakers pulled so the overload could not repeat.
How you fit a Moon landing in 72 kilobytes
The other half of the answer is ruthless compression of what “flying to the Moon” actually requires. The AGC did not simulate the solar system. It did not render graphics. It solved a small set of well-defined problems: read the inertial measurement unit, integrate acceleration into velocity and position, compare against a target trajectory, and fire thrusters or throttle the descent engine to close the gap.
Numbers were stored in fixed-point rather than floating-point format to save cycles. Trigonometric functions used polynomial approximations tuned to just enough precision for the job. Position was tracked in a coordinate system centred on whichever body dominated the local gravity (Earth, then the Moon), so the computer never had to carry huge numbers. When the crew needed to know something, they typed a two-digit “verb” and two-digit “noun” into the DSKY: Verb 16 Noun 65, for example, continuously displayed the AGC’s elapsed clock time in hours, minutes, and seconds. There was no operating system prompt, no file system, no user accounts. Every byte earned its place.
The flight software itself, called Colossus for the command module and Luminary for the lunar module, is now on GitHub, transcribed from scans of the original assembly listings. Reading it, the discipline is obvious. Comments like “TEMPORARY, I HOPE HOPE HOPE” and “NUMERO MYSTERIOSO” sit alongside code that navigated a quarter of a million miles with an error budget measured in metres.
Why the comparison to a greeting card chip is fair, and also misleading
A modern musical greeting card typically uses a small microcontroller with a few kilobytes of ROM and a few hundred bytes of RAM. In raw memory, it really is in the same ballpark as the AGC. A modern smartphone has roughly a million times more RAM and clocks several thousand times faster.
But the AGC was not trying to stream video or run a browser. It was solving a narrow physics problem in hard real time, with an operating system that gracefully degraded under load, on hardware rated to survive vacuum, vibration, temperature swings from -20°C to 70°C, and radiation outside Earth’s magnetic field. It was built from around 2,800 integrated circuits, each a Fairchild dual three-input NOR gate, among the first practical uses of silicon ICs anywhere. Apollo essentially bootstrapped the commercial integrated-circuit industry by buying them in bulk when nobody else would.
Strip away the memory sizes and what is left is a distinction between what a computer has to do and what it merely can do. Given a problem small enough to state precisely, and a scheduler smart enough to protect the critical work, four kilobytes was enough. And when the alarms lit again at 2,000 feet, with the fuel running down, a boulder field sliding past the window, and Armstrong’s pulse at 150, the machine kept flying, because someone, years earlier, had decided that “keep flying” was the only acceptable failure mode.
