Apollo 11 commander Neil Armstrong’s tense two-word report came over the loudspeakers at NASA’s Mission Control in Houston, more of a question than a statement as he and and fellow astronaut Buzz Aldrin rapidly descended in the Lunar Excursion Module toward the surface of the Moon. What should they do now? Should they abort or trust the Apollo Guidance Computer to finish its job? They needed an answer, and quick!
Time stood still, then, for a moment in Mission Control, as those present weighed the ramifications of Armstrong’s report. After spending $16 billion dollars of American taxpayers hard-earned money, the efforts of over 400,000 engineers, scientists and technicians, and the deaths of three astronauts (including Gus Grissom, the second American to fly in space) in the tragic Apollo 1 fire, the idea of failure at such a pivotal moment caused the hearts of those in Mission Control to temporarily stop beating.
The Apollo 11 Lunar Lander was hurtling toward the surface of the Moon, and if the guidance computer had crashed so might the astronauts contained within it – not a scenario anyone would ever wish to see played out. “1202 alarm”, Aldrin clarified, reading the error number off of the DSKY, the keyboard and display that served as the astronaut’s interface into the Apollo Guidance Computer, and snapping Mission Control out of its momentary freeze, forcing its members into action. The fate of two astronauts, the Lunar Lander and the future of the entire Apollo program hanged in the balance, and this issue needed to be resolved pronto.
After the Apollo 1 fire NASA had been relentless about drilling its teams, including Mission Control, running simulations of a vast variety of scenarios, including ones involving various failures of the Apollo Guidance Computer.
But perhaps NASA’s aggressive efforts to avoid another disaster had overloaded the minds of its engineers as everyone seemed to be drawing a blank. 1202 alarm? What did that mean? Was it serious or not? What was the computer trying to say? Was the error code just advice or did it require human intervention?
Nobody present at that crucial moment seemed able to remember. No one, that is, except Jack Garman. Jack was hired by NASA in 1966 at the age of 21, and had elected to be assigned to the Apollo Guidance Program section where he worked closely with the Massachusetts Institute of Technology (MIT), overseeing the design of the Apollo Guidance Computer.
“Give us a reading of that 1202 alarm”, came an increasingly anxious voice over the loudspeakers as Mission Control frantically searched its collective minds for an answer.
“That’s okay,” said Garman, and everyone heaved a tentative sigh of relief. But some started to remember that during a previous simulation of the 1202 alarm, Guidance officer (also known as GUIDO) Steve Bales – Garman’s boss – had called for an abort. It was up to Bales now to decide whether to back Garman’s call or contradict it.
Bales had already opted against calling for an abort earlier in the landing after learning the spacecraft was moving 6 m (20 ft) per second faster than it should have been, but the trajectory remained stable and Bales had decided to allow the mission to continue. But could he trust the opinion of his subordinate now?
He asked Garman for clarification, and Garman insisted that if the alarms weren’t constant, the computer would continue functioning. Was he right? What if he wasn’t? Two men could die! The clock was ticking and Bales had to decide.
Bales mind pondered heavily, going back over the history of the guidance project, and Garman’s role in it. One of the first integrated-circuit (IC)-based computers, design of the AGC began in early 1961. Despite traditionally contracting with defense companies, the MIT Instrumentation Laboratory was chosen by NASA to develop it, due to the storied reputation of laboratory founder Charles Stark Draper, known by some as the “father of intertial navigation.” Draper’s interest in flight instrumentation had been borne out of his experiences as a pilot in the 1930s – during the previous decade he had earned a number of degrees from Stanford and MIT including one in electrochemical engineering, and he put his knowledge to use searching for a solution to the problem of accurate aerial navigation.
By using a series of gyroscopes and accelerometers he devised a machine capable of sensing the direction and speed of an aircraft, and then adjusting the plane’s heading appropriately. People were skepical of Draper’s contraption’s ability to navigate to a destination without using visual landmarks or radio transponders, but tests proved that his invention worked, and it became a critical component of US intercontinental ballistic missiles, submarines, military and later commercial aircraft.
NASA hoped that Draper’s expertise would be useful in the design of a flight computer capable of navigating astronauts to –and landing on – the surface of the Moon. But Draper wouldn’t be designing the AGC all on his own – he had an entire team ready to assist him.
One of those team members was Margaret Hamilton. Previous to her work on the AGC, From 1961 to 1963, Hamilton had written software for the giant AN/FSQ-7 computers at the heart of SAGE, the Semi-Automatic Ground Environment project that analyzed information from a large network of radar stations in order to construct a real-time view of North American airspace and use it to determine a potential response against Soviet attack. Despite questions regarding its reliability and the diminishing availability of the vacuum tubes that powered it, SAGE would remain a key component of NORAD’s defense capabilities well into the 1980s, when it would inspire movies such as WarGames (1983).
Software development was a brand-new discipline in the early 1960s – previous computers had simply followed the directions of punch cards or control panels sequentially in real time and the idea of a resident program that monitored inputs and acted appropriately was cutting-edge at that stage. Hamilton was a pioneer in an emerging area – and the Apollo spacecraft was going to need a computer capable of doing nearly everything the 226 tonne (250 ton) AN/FSQ7 did in the space of a single cubic foot!
In order to severely “downsize” a computer which had previously taken up the entire floor of an office building, the AGC’s hardware designers turned to semiconductor technology. Integrated circuits, or “microchips” made of silicon were able to house tiny transistors, which had replaced the comparatively massive vacuum tubes that powered computers such as the AN/FSQ7. They were also lighter, cooler and used much less electricity.
Each chip had two logic gates, and there were 2800 chips in total. It had 2048 16-bit “words” (or 4096 8-bit bytes) of eraseable magnetic memory (which could be modified by programs or manually through the DSKY), and 36 kilowords (72 kilobytes) of read-only “rope” memory (see sidebar) that stored program code. It had a 2.048 MHz crystal clock that was divided in half to produce a 1.024 MHz timing reference (an equivalent to CPU speed).
Hardware-wise the AGC was similar to home computers, such as the Atari 400 or Commodore VIC-20, which would be released over a decade later.
However, rather than using a QWERTY keyboard and a CRT-based monitor, astronauts communicated with the AGC via the DSKY (which they pronounced Diskee), a simple LED and button-based interface that allowd them to view memory locations, edit some of them and, perhaps most importantly, inform them of errors when things weren’t working out the way they were supposed to.
This was especially important since the AGC would need to be able to run multiple programs simultaneously in order to co-ordinate and manage the various aspects of the Apollo spacecraft, and while it could determine which tasks had the highest priority in order to ensure critical functions continued to execute in the event there was too much on the AGC’s plate – a concept that would come to be known as multitasking – sometimes human intervention would be required. Normally, the AGC used an “operating system” (at that time a new term) that consisted of two “god” programs – the first was known as the Exec, which co-operatively managed large applications which ran for extended periods of time, and the second was called the Waitlist, which scheduled shorter jobs that could re-schedule themselves or launch larger programs managed by the Exec.
The computer also featured an interpreter which allowed for non-native, simplified instructions that represented more complex trigonometric, vector and scalar math functions needed for navigational programs, reducing their overall memory footprint. There were two AGCs – one in the command module, which ran software known as COLOSSUS, and one in the lunar excursion module (LEM) whose software was known as LUMINARY.
Understanding how the AGC’s operating system functioned would be key to GUIDO Steve Bales’ decision-making regarding whether the first lunar landing should be allowed to continue. The 1202 alarm displayed on the DSKY suggested that between the Exec and the Waitlist the workload was too high, and in order to ensure that critical functions operated in a timely fashion, some tasks needed to be terminated. However, which tasks the Waitlist had killed were not known to Mission Control – they had to trust that the software knew what was important at that exact moment.
Time was ticking away and a decision was needed – 386,000km (240,000 miles) away from Earth a fragile craft was rapidly approaching the surface of the Moon and they needed to know if they were going to land or potentially crash! Weighing all of his knowledge – the pedigree of the AGC, its design and designers, and the confidence of Garman, Bales concluded that it was safe for the mission to continue, so long as the alarm didn’t continue to go off. Also, attempting to abort and return to the command module with a buggy computer could be just as risky.
The journey to the Moon was not an easy one. After a noisy eleven-minute rocket-ride into orbit at three times the Earth’s gravity (imagine weighing three times as much as you do now!) the combined spacecraft and third Saturn V stage orbits once or twice before burning for six more minutes in the direction of the Moon. Some complicated maneuvers then take place, to “unpack” the Lunar Module and dock it with the Command Module.
The third stage is then discarded and the combined Lunar and Command Modules then make their way to the Moon over the course of two to three days. The only way to return is by slingshotting around the Moon, so the astronauts are effectively stranded inside the spacecraft for the duration – not a pleasant situation to be in, especially during an emergency such as befell the ill-fated Apollo 13 mission.
And so, the landing continued.
However, the alarm went off again! Things became tense once more. But Buzz Aldrin soon realised that the alarm appeared to be directly related to his issuing of a 1668 command via the DSKY, which periodically returned DELTAH, the difference between the altitude as sensed by radar and the altitude calculated by the AGC (if this number became significant then presumably you were in trouble!)
After being given the “go” from Houston after the first alarm, Aldrin had entered 1668 again and another 1202 alarm occurred. The 1668 added an additional 10% to the processor’s workload, which between the assorted programs involved in the landing and the radar tracking of the Command Module (needed in case of an abort) was already around 100%, and so the Waitlist was killing the 1668, considering it nonessential. The 1202 alarm was the AGC’s way of informing the astronauts that it had done so.
But they needed the readout from the 1668 and so several more alarms occurred and several more “go” calls were issued. But the AGC continued to operate and the Lunar Module soon touched down on the Moon’s surface. A post-mission analysis showed that the radar tracking the Command Module wasn’t operating properly and was “stealing” more CPU cycles than it had been estimated to need. But thanks to the designers of the AGC, it had been able to cope, and humanity set foot on the Moon for the first time.
Would you like to see what it was like to use the DSKY and the Apollo Guidance Computer, and imagine that you’re flying through space in the Command Module and/or landing on the Moon in the Lunar Module? Well, there are emulators for everything these days, and the AGC is no exception!
Moonjs is an online Apollo Guidance Computer simulator. It is a port of Virtual AGC, an application that runs on Windows and Linux. There’s also a virtual machine that can run on MacOS X. Each of them runs a copy of the Colossus 249 flight control software that flew on the Apollo 9 command module.
You can use these emulators to experience a simulated launch of a Saturn V rocket (at least from the guidance computer’s point of view), or even a lunar landing!
http://svtsim.com/moonjs/agc.html Browser-based Javascript DSKY Simulation
http://www.ibiblio.org/apollo/ AGC VM, Linux or Windows Applications
http://www.hotto.de/software/lm-simulator.html Lunar landing simulator (needs AGC application)
Be the first to comment