First-Hand:Hacking Apollo's Guidance Computer
Submitted by Walt Whipple
Command Module Testing
During the period February 1967—May 1969, I was employed by Raytheon’s Space and Information Systems Division in Sudbury, Massachusetts, the manufacturer of the Apollo Guidance Computer (AGC). After factory training in the Apollo Guidance and Navigation (G&N) system, two Raytheon engineers and a manager were assigned to AC Electronics, the manufacturer of the Apollo Guidance and Navigation System, to support ground test of the Apollo Command Module (CM) by North American Aviation in Downey, California. Virtually every component of the Command Module was sensed and/or controlled via a computer I/O channel in the 512 pin connector. The second such connector only allowed control of the computer circuits via the test console in the lab. Thus we had a central role on every fault investigation during ground test of the Command Module. As the testing came to a close, I was transferred back to Massachusetts to teach the Apollo Guidance and Navigation training course for field engineers.
Fundamental Strength
The computer had two types of memory, read-only program memory consisting of wires through or around magnetic cores (“ropes”) and read-write data memory consisting of conventional core memory. During ground test, a test version of the program memory was installed. Changing the program memory required replacing the many modules containing the ropes; modifying any location required re-manufacturing the many modules, a process of months duration. The computer logic was implemented in small scale integrated circuits consisting of two 3-input NOR gates per chip. Both the conventional core memory and the NOR gates were vulnerable to transient spikes due to impact with random particles expected in the space environment. Therefore, a fundamental design criterion was that mission programs be continued with minimal disruption in the face of many such impacts. Two mechanisms dealt with this criterion. First, the detection of anomalous behavior would cause the software to branch to the restart routine that would reinitialize data memory. Second, while a mission program was running (as indicated by the contents of location 67), the restart routine would execute several instructions and then restart the mission program rather than reinitialize data memory. It would then be up to the mission program to do any re-initialization of its own data. Implementation.
The contents of location 67 would be added to the following program memory instruction and the resulting instruction (operator/operand) would then be executed. The base program memory instruction was followed by the rest of the restart program. Three results of this modified instruction were possible: 1) with location 67 zero, continuation to the following restart program instructions, 2) with location 67 set to a mission program address, branch back to the executing mission program, and 3) with location 67 set to anything else, execution of any instruction/operand pair.
Weakness
In the latter case, this occasionally resulted in jumping to a location that would eventually result in another restart. Once this erroneous loop started, it would never end due to location 67 being resident in magnetic core data memory. No mechanism existed to break this loop except when the computer was connected to the computer test set in the laboratory.
When this lockup occurred during test of the command module, the impact on testing was severe due to the location of the computer in the command module, under the gyroscope of the Guidance and Navigation System. The gyroscope had to be removed for access to the computer, the computer had to be removed and transported to the lab test set, location 67 zeroed, the computer transported back to the command module, the computer re-installed, the gyroscope re-installed, and the gyroscope re-aligned. This process took approximately 48 hours while the entire command module test team waited. Motivation. Since ordinary restarts re-initialized data memory, the necessary data for fault analysis was destroyed once the restart executed. Simple faults anywhere in the command module were difficult to analyze because no data was available other than the computer inputs. Data collection was hampered because there was no memory or i/o channel dump, just laborious hand recording of octal numbers, location by location.
Exploitation
We reasoned that the data collection problem could be solved with a memory and i/o channel dump procedure triggered by placing a number related to the address of the procedure in location 67, a computer “hack”. On every restart without a mission program running, this would execute the memory dump program which would dump the data and then return to finish the restart procedure. We then found that the built-in telemetry routine could be redirected to transmit this data via telemetry to the ground station. This hack of the Apollo Guidance Computer was so helpful in fault analysis that it became a standard part of Command Module testing at North American Aviation.
The restart program was written in absolute octal machine language since no assembler was available in the field. The entire program was manually entered via display/keyboard (DSKY) assembly, five octal digits at a time, using keys designed for astronauts wearing heavy gloves. The penalty for a data entry error was a potential lockup with the attendant 48-hour delay!
Back to Human Space Travel Primary Sources
