Apollo 11's Guidance Code Is Still Worth a Close Read

Every July, right around the anniversary of the landing, the Apollo 11 guidance computer source climbs GitHub's trending page again. The repo — roughly 70,000 stars and counting — holds the assembly listings for Comanche 055 and Luminary 099, the programs that flew the Command Module and Lunar Module in July 1969. Most people star it, skim BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc, chuckle, and move on.

That's a mistake. This codebase is one of the few genuinely great free case studies in real-time embedded design, and the parts worth studying aren't the jokes.

What you're actually looking at

First, provenance, because the GitHub framing obscures it. Chris Garry uploaded this in 2016, but the hard work happened years earlier at the Virtual AGC project, where Ron Burkey and collaborators transcribed the code by hand from scans of an MIT Museum hardcopy — a printout Margaret Hamilton signed off as "Colossus Programming Leader" in March 1969. The trending repo is a snapshot of that transcription. The living archive is virtualagc/virtualagc, which has since captured Luminary and Colossus revisions for nearly every mission, plus the Abort Guidance System and even the Saturn V's LVDC software.

That distinction matters if you want to do more than read. Virtual AGC ships yaYUL, an assembler that turns these listings back into rope-memory binary images, and yaAGC, a cycle-accurate emulator that executes them — with a simulated DSKY so you can punch in V37N63 and fly a powered descent on your laptop. The famous repo is the museum postcard; Virtual AGC is the museum.

The machine forces the interesting decisions

The AGC had 2,048 fifteen-bit words of erasable core memory and 36,864 words of fixed rope memory, executing around 85,000 instructions per second at 55 watts. Those constraints produced three design moves that still read as sophisticated today.

The Interpreter. Navigation math needs vectors, matrices, and double precision — luxuries a 15-bit machine can't afford in native instructions without blowing the memory budget. So the MIT team built a virtual machine: a compact interpreted language for the guidance equations, trading execution speed for code density. Roughly half the flight software is written in it. Open LUNAR_LANDING_GUIDANCE_EQUATIONS.agc and you're not reading raw AGC assembly; you're reading bytecode for a VM designed in 1965 because ROM was hand-woven and every word cost money. Anyone who's squeezed firmware into a cheap microcontroller with a size-optimized interpreter is walking a path this team paved.

Priority scheduling with graceful degradation. The Executive scheduled jobs by priority against a fixed pool of "core sets"; the Waitlist handled short time-driven tasks. When Eagle's rendezvous radar — left in the wrong switch configuration — started stealing roughly 15% of the CPU during the landing, the Executive ran out of job slots and threw the now-famous 1201 and 1202 alarms. The response wasn't a crash. BAILOUT triggered a software restart that dumped low-priority work and reconstructed the important jobs from restart tables (see FRESH_START_AND_RESTART.agc), keeping guidance, navigation, and Armstrong's displays alive. Hamilton's team had been told this machinery was overkill. It's the reason the landing continued instead of aborting.

Strip the moon dust off and this is load shedding: bounded resources, priority-based admission, checkpoint-and-restart, degrade the dashboard before you degrade the control loop. We reinvented all of it for distributed systems in the 2000s and gave it new names.

Immutability as discipline. Rope memory was woven at Raytheon, largely by women threading wires through magnetic cores by hand — a months-long manufacturing step. Once woven, the program physically could not change. That's the original immutable deployment, and it dictated the culture: exhaustive simulation, obsessive review, error budgets negotiated before "freeze" meant something you could hold. It's no accident Hamilton spent the era popularizing the term "software engineering" — she was arguing the discipline deserved the same rigor as the hardware it shipped inside.

The comments are the culture

The humor everyone screenshots is real and verifiable. The BURN, BABY, BURN header cheerfully credits DJ Magnificent Montague for the catchphrase. The DSKY interface lives in PINBALL_GAME_BUTTONS_AND_LIGHTS.agc — the crew's entire UI, modeled on the only interactive machine anyone had a mental model for in 1966. A hack near the landing code is annotated TEMPORARY, I HOPE HOPE HOPE. And since 2016, the GitHub issue tracker has accumulated deadpan bug reports about Apollo 13's oxygen tanks.

But read past the jokes and the comments do what great comments do: they explain why. Scaling decisions, timing assumptions, which registers a routine clobbers, what happens across a restart. On a machine where a mistake ends a mission on live television, the documentation density is itself a lesson.

How to actually study it

Don't read linearly. Pick the descent path: start at THE_LUNAR_LANDING.agc in Luminary 099, follow into the guidance equations, then read the Executive and FRESH_START_AND_RESTART.agc with the 1202 story in mind. Then clone Virtual AGC, build with make, and run Luminary under yaAGC — watching the DSKY throw a 1202 you caused yourself teaches more about overload behavior than any postmortem write-up.

The repo also quietly demonstrates something nice about open source as preservation: contributors have spent a decade submitting PRs that fix transcription typos against the original page images — code archaeology with a review process.

My take: the annual trending spike is earned, but starring it is the least interesting thing you can do. Fifty-seven years on, this is still one of the tightest examples we have of engineering under constraints that couldn't be negotiated away — no patches, no retries, 4 KB of RAM, and a landing to make. Most of what we call resilience engineering today is in here, in 1960s assembly, signed off by hand.