Just minutes before the first human landing on the Moon, on July 20, 1969, the Eagle lunar module's computer began emitting unexpected alarms. First 1202 appeared. Then, another 1202. Closer to the surface, came 1201 and new 1202. There were five occurrences during the descent. Neil Armstrong and Buzz Aldrin didn't have a ready answer for those codes and asked Houston for an evaluation.
The short answer to what happened is this: The Apollo Guidance Computer was overloaded, but it had not stopped working. Its software detected that it was lacking resources to accommodate all tasks, initiated recovery procedures, and resumed essential work. In Houston, controllers followed the trajectory, interpreted the alarms and concluded that the descent could still continue.
In practice, three layers worked together:
- the computer received a greater processing load than expected;
- the software detected the excess, recovered and preserved the priority functions;
- the Houston team verified that the system continued to guide the Eagle correctly before authorizing the landing to continue.
It is precisely this combination that makes alarms 1201 and 1202 more interesting than the simplified version that “the computer almost crashed”.
What did alarms 1201 and 1202 mean
The two codes belonged to the same family of problems: an Executive overflow, that is, a situation in which the computer's executive system was unable to reserve the necessary resources to start another task.
Apollo's software worked with temporary areas of memory associated with running jobs. Among them were the so-called core sets and the VAC areas, for vector accumulator. When a new task needed to be started, the system looked for available space for it.
The codes distinguished which resource had been exhausted:
- 1201: there was no VAC area available;
- 1202: there was no core set available for the new task.
The preserved source code of the Luminary program itself shows 1201 associated with the lack of VAC areas and 1202 with the lack of core sets. This is important because the numbers did not describe a general computer breakdown. They were specific diagnoses produced by the executive system when it recognized that its work queue had exceeded a predicted condition.
Why the computer was overloaded
A common explanation is that the rendezvous radar was on and sending unnecessary data to the computer during landing. The basic idea is correct, but it leaves out an important detail: turning on this radar was not simply an error by Armstrong or Aldrin.
In the mission's technical debriefing, the astronauts explained that the rendezvous radar was turned on according to a configuration that had been used in procedures and simulations. Keeping it available made sense because the equipment would be needed if the descent was aborted and the lunar module had to rejoin the command module Columbia.
Further technical analysis by Don Eyles, one of the engineers who programmed the lunar module landing software at the MIT Instrumentation Laboratory, was more specific. According to him, there was an uncorrected problem in the interface with the rendezvous radar. Certain electrical conditions caused the system to generate unnecessary activity for the computer, a phenomenon known as cycle stealing. Eyles calculated that this consumed approximately 13% of the processing time available during descent.
Thirteen percent seems little until one considers that the landing program already used a large part of the available capacity. The computer continued to perform its normal navigation, guidance, control and display tasks while the radar system consumed additional cycles. Tasks began piling up faster than they could be completed.
So the alarms arose.
The detail changes the interpretation of the episode. This was not simply “too much data” in a generic sense or an astronaut pressing the wrong key. It was an interaction between hardware, electrical interface, operating procedures and a machine that was already operating close to its intended limit.
What the software did when it lacked capacity
This is where the story stops being just about computer limitations and becomes about software architecture.
The Apollo Guidance Computer used a priority-driven executive system. Not all work was equally important. Maintaining orientation, navigation and control of the spacecraft took priority over tasks that could be postponed or restarted without immediately putting the vehicle at risk.
When the executive encountered the condition that produced a 1201 or 1202, he did not simply freeze waiting for space. The software triggered its recovery mechanism, restarted execution, and resumed selected programs from protected restart points. Critical tasks returned; jobs that had contributed to filling the queues did not all need to be rebuilt in the same way.
It is more accurate to say that there were controlled restarts of the software than to say that the computer “crashed and came back”.
It is also inaccurate to imagine that the machine made an abstract decision to “save the landing”. Priorities and recovery mechanisms had been defined and tested by engineers. During the mission, the computer simply executed this architecture: it detected the lack of resources, flagged the problem and resumed execution according to rules already incorporated into the system.
The result was an early and sophisticated form of controlled degradation. When faced with excessive load, the system did not need to treat each function as equally indispensable.
Where does Margaret Hamilton come into this story
Margaret Hamilton's contribution needs to be explained without turning a collective effort into the work of a single person.
In 1969, the development of the Apollo flight software was carried out at the MIT Instrumentation Laboratory, an institution that later became the Charles Stark Draper Laboratory. Hamilton led the laboratory's Software Engineering Division and the team responsible for the embedded software for the command and lunar modules.
NASA later highlighted among its contributions and those of its team concepts related to asynchronous software, priority scheduling, end-to-end testing and mechanisms capable of dealing with unexpected situations during the mission.
This does not mean that Hamilton personally wrote every routine associated with alarms 1201 and 1202. The Apollo software was the result of the work of many engineers. Don Eyles wrote key parts of the descent program; Peter Adler worked on the lunar module flight programs; other experts developed the executive, restart routines, navigation, guidance, and interfaces.
Hamilton's role is more correctly understood as leadership of a software organization that needed to deliver an embedded system capable of operating in real time, with extremely limited resources and no possibility of physical maintenance during a lunar mission.
The Apollo 11 alarms ended up providing a concrete demonstration of why detection and recovery mechanisms were so important.
What Houston had to decide in just a few seconds
A good recovery mechanism was not enough. Armstrong and Aldrin still needed to know if the alarm allowed the landing to continue.
After the first 1202, Armstrong asked Houston for an interpretation. A few seconds later, CAPCOM Charlie Duke transmitted the authorization to continue. The audio and transcript of the mission record the rapid transition between the crew's request and the response that the flight was authorized to proceed at that alarm.
Behind the short communication was a chain of decision.
Jack Garman, a NASA engineer supporting the guidance team, had prepared a list of possible computer alarms. When Steve Bales, in charge of guidance in the control room, received 1202, Garman recognized the condition as a temporary overload that, in that context, did not automatically require an abortion.
Bales combined this information with what the controllers observed in telemetry: the trajectory remained coherent and the guidance system remained working. The recommendation went through the flight control structure, and Duke transmitted the “go” to Eagle.
When 1201 came along, the reaction was even quicker because Houston already knew it was the same general type of overload. The transcript records almost immediate confirmation that the crew could continue.
This helps correct another simplification: Houston didn't ignore the alarm because he blindly trusted the computer. The controllers accepted the continuation because they understood the significance of the condition and, at the same time, observed that the essential parameters of the landing remained normal.
Buzz Aldrin also reduced the load during the descent
The crew didn't just wait for decisions from the ground.
After one of the 1202s, Aldrin noticed that the alarms seemed to coincide with a request from a particular computer screen, the command Verb 16 Noun 68. This display presented useful information for the descent, but added another small demand to an already overloaded system.
Instead of insisting on consultation, part of the monitoring began to be carried out on the ground. Houston could provide information the crew needed without requiring the same interaction with that display during the critical moment.
This change did not eliminate the root cause of the problem, which remained related to the radar interface, but it did reduce an avoidable demand while alarms were being managed.
Armstrong had to deal with the computer and the terrain at the same time
The alarms had an operational consequence that goes beyond electronics: they consumed the crew's attention.
In the subsequent debriefing, Armstrong explained that the period in which he would normally be more intensively assessing the terrain and landing point was partially occupied by the need to monitor alarms, confirm that the vehicle remained controllable, and assess whether an abort would be necessary.
When he was finally able to pay more attention to the outside, Armstrong realized that the point to which the system was taking them was close to an area covered by rocks and a large crater. He then took greater control over the final phase of the descent, entered the P66 program, and guided the Eagle past the unsuitable terrain before landing.
This performance also fits into a trajectory that began long before Apollo 11. Armstrong had a background in aeronautical engineering, worked as a researcher and test pilot for NACA/NASA and participated in both the piloting and engineering aspects of programs such as the X-15. Neil Armstrong's technical background helps to understand why he was able to treat an experimental machine not just as a pilot, but as part of a system that needed to be constantly evaluated. This previous journey is the subject of the related article “Neil Armstrong before the Moon”.
This does not diminish the role of the computer or Houston. On the contrary: the landing worked because different responsibilities remained connected. The machine performed guidance and control; Aldrin monitored instruments and computer; Armstrong assessed the flight and terrain; Houston saw telemetry and brought together experts who knew what the alarms meant.
The problem was understood before the Eagle left the Moon
The technical work did not end when the lunar module touched down.
After landing, teams from NASA and MIT investigated the source of the overload. The behavior of the rendezvous radar became one of the main clues. Before liftoff from the lunar surface, Houston changed procedures to prevent the same type of load from affecting the computer during the ascent. Among the instructions given to the crew was to keep the rendezvous radar circuit breakers open at times when their operation was not necessary.
The response, therefore, occurred in two stages. During landing, the priority was whether Eagle could continue safely. After landing, the priority shifted to understanding the cause and preventing it from reappearing on takeoff.
What alarms 1201 and 1202 actually demonstrated
Apollo 11 didn't reach the Moon because its computer never encountered a problem. It arrived despite a problem because different layers of the system were able to detect it, absorb it and make coherent decisions.
The hardware had clear limits. The radar interface managed to consume an unexpected portion of the processing. The software recognized that its execution resources had been exhausted and triggered the recovery predicted by the engineers. Houston knew how to interpret these signs in context. Armstrong and Aldrin continued to assess whether the ship was still responding as it should.
Therefore, codes 1201 and 1202 are not just a curiosity in the history of computing. They show an idea that remains central to critical systems:it is not enough to try to prevent every failure; You also need to design the system to recognize abnormal conditions, preserve essential work, and allow qualified people to decide what to do next.
On the Apollo 11 landing, this is exactly what happened.
