Eyles (2004): Tales from the Lunar Module Guidance Computer
Where Hoag designed the system architecture, Battin designed the navigation algorithms, and Hopkins, Alonso & Blair-Smith designed the computer, Don Eyles was one of the people who wrote the actual flight software. He was a programmer at MIT’s Instrumentation Laboratory who authored P63 (braking phase), P64 (visibility/approach phase), and P66 (rate-of-descent manual landing) — the three guidance programs that controlled powered descent from orbit to the lunar surface. He also wrote the throttle control routine and devised the in-flight workaround that saved Apollo 14’s landing.
This paper is his first-person account, written 35 years later for a guidance and control conference. It is not a formal derivation or a system description — it is a war story, told by someone who was there, with enough technical detail to reconstruct what happened and why.
The Programmer’s Machine
Section titled “The Programmer’s Machine”Eyles describes the AGC from the perspective of someone who had to write real-time guidance code on it. Two programming languages were available:
| Language | Designer | Speed | Precision | Use |
|---|---|---|---|---|
| Basic | Hugh Blair-Smith | Fast (~40 ops, single-precision) | 15-bit | Time-critical control loops |
| Interpretive | Charles Muntz | Slow (but compact) | Double-precision vectors/matrices | Navigation math, trajectory computation |
Fixed memory — 36,864 words of core rope in Block II — was physically woven. Once manufactured, it was read-only. Changing a single instruction meant re-weaving the rope, a process with lead times measured in months. Erasable memory was 2,048 words, shared among all running programs with no hardware memory protection.
The practical consequence: the Interpretive language let programmers fit complex vector and matrix operations into a fraction of the code space that Basic would have required, at the cost of execution speed. Descent guidance ran in Interpretive. The throttle control inner loop ran in Basic.
Laning’s Executive
Section titled “Laning’s Executive”Hal Laning designed the AGC’s executive — the scheduler that decided which program ran when. Eyles is specific about what made it work: it was priority-based, not time-sliced.
In a time-sliced (“boxcar”) system, each task gets a fixed window. If a task doesn’t finish in its window, it’s interrupted regardless of importance, and if a window goes unused, the CPU sits idle. In Laning’s design, higher-priority jobs preempt lower-priority jobs immediately. The executive maintained 8 core sets (register save areas for preempted jobs) and 5 VAC areas (vector accumulator blocks for Interpretive code).
The critical design property: when the machine runs out of core sets or VAC areas, it drops the lowest-priority work rather than halting. The system degrades gracefully under overload instead of collapsing. This was not an accident — it was a deliberate architectural choice, and it is the reason Apollo 11 landed.
The Descent
Section titled “The Descent”Three programs, written by Eyles, controlled the Lunar Module from powered descent initiation to touchdown:
P63 — Braking Phase. The descent engine fires to decelerate from orbital velocity. The computer commands throttle and attitude to follow a fuel-optimal trajectory targeting a point approximately 7,000 feet above the landing site. The crew monitors but does not intervene.
P64 — Visibility/Approach Phase. The LM pitches upright so the crew can see the landing site through the window. The Landing Point Designator (LPD) — an angle scale etched on the window — shows where the computer thinks it’s headed. The commander calls out LPD angles; if the target is in a boulder field or a crater, he can redesignate with the hand controller. The computer recomputes the trajectory to the new point.
P66 — Rate-of-Descent (Manual Landing). The commander takes direct control of descent rate using the hand controller — each click changes the commanded vertical rate by 1 ft/s. The computer maintains horizontal velocity and attitude. This is the phase Armstrong flew during Apollo 11, taking over at about 650 feet to avoid a boulder field west of the planned landing point.
During Apollo 11’s descent, the sequence unfolded under stress. Executive overflow alarms (1202, 1201) fired repeatedly during P63 as the rendezvous radar stole CPU cycles. Garman, on console in Houston, recognized the alarms and cleared them — the computer was shedding low-priority work and restarting, exactly as Laning designed it to. Throttle-down from maximum thrust arrived on schedule at the predicted time, which Eyles describes as a critical confidence builder for the flight controllers: it meant the guidance solution was tracking reality. Armstrong transitioned through P64, assessed the terrain, and entered P66 for the final manual descent to “the Eagle has landed.”
Two Problems No One Fully Understood
Section titled “Two Problems No One Fully Understood”Both trace to the same root cause: interface control documents that didn’t match reality.
The Rendezvous Radar
Section titled “The Rendezvous Radar”During Apollo 11’s powered descent, the rendezvous radar was in AUTO/SLEW mode, tracking the Command Module overhead. The ICD specified that the radar’s 800-Hz reference signal would be “frequency locked” to the AGC’s timing. It was — the frequencies matched. But the phases were not synchronized. The coupling drive units (CDUs) that reported radar angles to the computer were incrementing at their maximum rate, trying to track a phantom angle that wasn’t changing. This consumed approximately 13% of the AGC’s CPU capacity.
The problem had been seen before. George Silver recognized it from LM-3 testing. It had been documented. It was never fixed. On Apollo 11, it pushed the executive past its capacity, triggering the 1202/1201 alarms that came within seconds of an abort call.
The specification said “frequency locked.” It should have said “phase synchronized.” One word.
The Throttle Compensation
Section titled “The Throttle Compensation”Eyles wrote the throttle control routine. The ICD specified a 0.3-second engine response lag, and the software included compensation for that delay. But the engine had been improved during development — the actual lag was approximately 0.075 seconds. The ICD was never updated.
The software overcompensated for a lag that no longer existed. By accident, this produced acceptable throttle behavior. Eyles is blunt about the alternative: “If the correct compensation number had been coded, Apollo 11 would not have landed.” With 0.3 seconds of compensation applied to a 0.075-second system, the throttle control loop would have been unstable — oscillating rather than converging.
The system worked because it deviated from its specification.
The Restart That Saved Apollo 11
Section titled “The Restart That Saved Apollo 11”The restart protection mechanism is described in R-393 at the hardware level. Eyles describes it from the programmer’s side.
Programmers registered waypoints at safe points in their code — places where all critical state had been saved to erasable memory. On any restart (hardware fault, watchdog timeout, executive overflow), each job resumed from its last registered waypoint. If multiple copies of the same job existed, only the most recent restarted. Non-critical computations that hadn’t yet registered a waypoint simply disappeared.
This is exactly what happened during Apollo 11’s descent. The executive overflow caused by the rendezvous radar triggered restarts. The descent guidance programs (P63, then P64) had registered waypoints. They restarted and continued. The display routines that were consuming the stolen cycles had not registered waypoints. They vanished. The computer shed what it could afford to lose and kept what it couldn’t.
Eyles’ summary: “Invariably, once working correctly, operation continued seamlessly.”
The restart mechanism was designed years before anyone knew it would be needed for this specific failure mode. It worked because it was general — it didn’t anticipate which overload would occur, only that some overload eventually would.
Apollo 14: 61 Keystrokes
Section titled “Apollo 14: 61 Keystrokes”Before powered descent on Apollo 14, a spurious signal from the abort switch began intermittently triggering the abort monitor. If the signal occurred during powered descent, the computer would execute an automatic abort — firing the ascent engine and abandoning the landing.
Eyles devised the workaround under time pressure on the ground: fool the abort monitor into thinking an abort was already in progress (so it would ignore subsequent signals), then immediately clean up the computer state to continue with powered descent as if nothing had happened. The procedure required 61 DSKY keystrokes, radioed up to the crew by CapCom and entered manually.
It worked on the first attempt. Apollo 14 landed at Fra Mauro.
Eyles notes the difficulty of reconstructing the event decades later: “Perhaps most interesting has been the number of differing versions offered to history.” The institutional memory of a real-time fix, executed under pressure and never repeated, fragments quickly. The code is the only reliable record.
Variable SERVICER — The Road Not Taken
Section titled “Variable SERVICER — The Road Not Taken”Eyles designed an improvement to the guidance cycle timing called Variable SERVICER. The standard SERVICER ran at a fixed 2-second period. Under CPU load, if a guidance cycle couldn’t complete in time, the result was a TLOSS (time loss) alarm. Variable SERVICER would have allowed the guidance period to stretch under load — the computation would still complete, just slightly later, with the guidance algorithm compensating for the longer interval.
Testing proved it immune to high-TLOSS conditions. It never flew. Apollo 17 was the last mission, and the software change board would not approve a major architectural change for a single flight. A working improvement to the system’s overload tolerance was shelved because there was no remaining schedule to absorb the risk of change.
What This Paper Teaches
Section titled “What This Paper Teaches”Eyles fills a gap in the archive that no other document covers. Hoag describes the system from the top. R-393 describes the computer from the logic level. Hamilton describes the methodology that emerged from the experience. Eyles describes the experience itself — what it was like to write P63 in Interpretive, negotiate for erasable memory allocations, debug throttle instability that existed only because a spec was stale, and invent a 61-keystroke patch in real time while astronauts waited in lunar orbit.
The recurring theme is the fragility of documentation. The LM-1 engine arming delay: “nobody told us.” The rendezvous radar phasing: documented but never fixed. The throttle lag: spec never updated. The Apollo 14 workaround: multiple conflicting accounts within a decade. Each is a case where the knowledge existed somewhere but didn’t reach the right person at the right time. The code survived. The context around it did not.