1. What the Apollo 11 guidance computer calculated during the 12-minute descent to the Moon
During the approximately 12 minutes of descent, the guidance computer performed calculations to slow the spacecraft. It reduced the orbital speed of about 3,800 mph (6,100 km/h) to a landing speed of about 2 mph (3 km/h). This process involved incorporating measurements from the landing radar, continuously adjusting engine output, directing the ship's orientation, and updating displays [3].
In the first phase of the descent, known as P63, the sole purpose was to reduce horizontal speed [2]. To determine engine output, the computer first calculated the mass of the ship. Knowing the mass allowed it to use the acceleration measured by accelerometers to find the necessary thrust correction for the guidance equations [2].
Astronauts interacted with the computer using the DSKY (Display and Keyboard). By entering two-digit numbers representing a "verb" and a "noun," they could issue instructions or view data [4]. The guidance equations were translated into program code by Don Eyles and Alan Klumpp at MIT, a task that took three years [3].
2. How little rewritable memory the Apollo Guidance Computer had
The Apollo Guidance Computer (AGC) had two types of memory. It had 2,048 words of rewritable core memory and 36,864 words of read-only core rope memory. Each word consisted of 15 bits plus 1 bit for parity checking [1][5].
Excluding the parity bits, the rewritable side held about 30,000 bits (2,048 × 15 = 30,720). The read-only side held about 550,000 bits (36,864 × 15 = 552,960). By word count, the read-only memory was 18 times larger than the rewritable memory. Conversions to modern units vary by source, so we show the figures in words and bits [1][5].
According to NASA records, the AGC weighed 70.1 pounds (about 32 kg) and had a clock speed of about 1 megahertz [4]. With only 2,048 rewritable words, the computer could "remember" very little at once. Large programs were stored in the read-only side, while only a few numbers were changed. This imbalance matters again in the story of the alarms below.
3. How the Apollo computer's programs were stored in wires woven through magnetic cores
In core rope memory, passing a wire through a small magnetic core represented a 1, while bypassing the core represented a 0. A single core could correspond to up to 192 sense wires, and one core held data for 12 words. This allowed more information to be packed into the same weight. Once made, it could not be rewritten [6].
The core ropes were manufactured by Raytheon in Waltham, Massachusetts. The weavers were women recruited for their sewing skills, which they had learned in the local textile industry [7]. The process involved passing wire through a needle and moving between two sides of a board to create a specific pattern [7]. Wiring one module took about 8 weeks [6].
Because the program was literally woven into wire, it could not be changed. Software had to be finalized before weaving began. A mistake in how a wire was passed could not simply be edited away later.
4. The five alarms that sounded during the Apollo 11 descent
During the Apollo 11 descent, alarms sounded five times. The mission elapsed times were 102:38:22, 102:39:02, 102:42:18 (a 1201 alarm), 102:42:43, and 102:42:58. The entire sequence lasted about 4 minutes and 36 seconds [10].
The cause was the position of a switch. According to the computer's designers, the position of the switch for the rendezvous radar (a different radar from the landing radar) caused the computer to repeatedly schedule processing for radar data that did not exist. This unnecessary work used about 15% of the available computing time when processing was at maximum speed [1]. Conservative estimates at the time suggested about 13%, so reading it as "just over 10%" is safe [1].
Afterward, radar data entered, and the astronaut added a monitor display (V16N68). This reduced the computing margin to less than 10% [1]. With such a small margin, there was not enough time to handle new tasks. The alarm indicated that the computer was running out of room for more work. So, what did the computer do next?
5. How the computer restarted and kept only the most important tasks running
According to the NASA Apollo Lunar Surface Journal, after restarting due to the alarms, the computer resumed critical tasks like controlling the descent engine and updating the DSKY display. It did not resume the mistakenly scheduled extra radar processing [8].
Programmer Don Eyles explained that the restart recreated only the most recent one of the accumulated tasks and discarded incomplete "fragments." This mechanism was originally designed for temporary hardware glitches, but it also served to shed load when the software was congested [2].
In her recollections, MIT engineer Margaret Hamilton described the software design. High-priority tasks could interrupt low-priority ones, and every process had a unique priority. The 1201 and 1202 alarms interrupted the normal display, prompting the astronaut to check the radar switch and informing mission control of the situation [9]. Hamilton's writing is her personal recollection of a team effort; it should not be read as one person saving the mission alone.
6. Why mission control gave a "Go" to continue the landing despite the alarms
MIT engineers had thoroughly tested the restart function. It is reported that mission control knew this [11]. Guidance officer Steve Bales gave the "Go" call. Charlie Duke in mission control told astronaut Armstrong that the alarms were "Go" [10].
At an altitude of about 500 feet (about 150 meters), Armstrong switched to mode P66, which is close to manual control. In P66, the computational burden was lighter. From entering P66 until landing, a period of about 2 minutes and 20 seconds, the Lunar Module was piloted without any alarms [2]. The altitude figure is an approximation based on MIT News reports [3].
7. How you can practice deciding which tasks to drop, using an evening to-do list
Try writing down five evening tasks on paper, such as homework, a bath, brushing teeth, preparing for tomorrow, and reading a book. Number them 1, 2, 3... from most important to least. On a day when you are short on time, you drop the tasks with the higher numbers. Thinking about what problems arise from dropping them helps you understand why the AGC assigned priorities to its work. These tasks can be imaginary.
One question remains. What if a task you dropped later turns out to be necessary? The designers had to decide what to keep and what to shed before the flight. This question seems connected to the fact that the core rope memory could not be rewritten.