The Apollo 11 computer alarms are usually told as a thirty-second story: alarms appeared, Mission Control said continue, and the landing succeeded. Don Eyles’s version takes about as long as it should.
Read Tales from the Lunar Module Guidance Computer
Eyles was one of the programmers who developed software for the Lunar Module guidance computer at the MIT Instrumentation Laboratory. His paper, presented to an American Astronautical Society conference in 2004 and expanded online with illustrations and comments, explains the system from the perspective of somebody who had actually lived inside the code.
The famous Apollo 11 alarms are only part of it.
During powered descent, an interface problem involving the rendezvous radar consumed roughly 13 percent of the computer’s duty cycle. The overloaded computer issued program alarms and restarted work in a controlled way, discarding lower-priority tasks while preserving the important ones.
That distinction matters.
The computer was not simply “crashing.” Its executive system was doing something recognizably modern: managing scarce processing time under overload and keeping the critical work alive.
Eyles also describes a less famous problem involving the Lunar Module’s descent-engine throttle control. Erroneous assumptions and a marginally stable control algorithm could produce violent throttle oscillations. His account reaches backward to Apollo 5 and forward through changes made after the early lunar missions, showing how flight software evolved because the spacecraft kept teaching the programmers things the simulations had not.
Then there is the hardware.
The Apollo Guidance Computer worked with 36K words of fixed memory and 2K words of erasable memory. The Lunar Module and Command Module each carried one. Eyles notes that, counted together, the Moon landing was accomplished with about 152 kilobytes of onboard computer memory.
That number is fun trivia until you read what the software actually did.
Navigation. Guidance. Engine sequencing. Displays. Radar interfaces. Crew interaction through the DSKY. Real-time task scheduling. Failure recovery. All while flying a machine that could not be rebooted by walking over to it.
The page matters in 2026 because it is not a retrospective assembled from simplified quotations. It is a technical witness explaining the architecture, mistakes, fixes, naming conventions, people, and operational pressure in enough detail that the old software becomes engineering again instead of mythology.
CacheRat’s 1,967 Ancient Web Domains research list keeps finding pages like this: documents sitting quietly on personal domains that are better than the summaries built on top of them.
Apollo had plenty of heroes.
One of them was a scheduler that knew which jobs could wait.