There is much speculation by some, as to how the flight computer aboard the Apollo missions managed to get men to the moon when it had just a tiny fraction of the computing power of something like a modern smartphone.
But this is quite misleading as there was not one solitary computer controlling the Apollo craft, there were 4 computers and no fancy touch screens, GUI’s or other things in a typical computer of today to waste resources on.
The first of the 4 computers was the Saturn Launch Vehicle Digital Computer or LVDC, this got the rocket from the launch pad to earth orbit.
Then there was the Apollo Guidance Computer or AGC, this is the one which most people think of. There were in fact, two of them, one in the Command Module to get from the earth orbit to the moon and back again. The second was in the lunar module that would control the landing and then the ascent back to the command module and docking.
The fourth computer was one which was never used on any mission because it would control an emergency abort and ascent should something happen during the descent to the moons surface like the landing computer failing or they ran out of fuel.
The Apollo Guidance Computer wasn’t as dumb as many make it out to be. As time when by in Apollo’s development, the tasks that it was meant to do increased in both number and sophistication, this, in turn, created ever more issues with the limited resources available.
One of the biggest problems was the limited amount of memory due to the technological limitations of the time, this meant that the programmers had to make use of every single byte available.
The AGC also had a unique operating system. Systems like UNIX, Linex, Windows and Apple iOS are in control and share time out to the programs. In the AGC, the programs controlled how much time they got depending on how important they were. So that in the case of an emergency, the highest priority programs would get most of the time and non-essential operations were dropped to free up resources which became the basis of mission critical system for all manned mission afterwards.
The computer had a performance somewhere around that to that of the first generation of personal computers like the Apple II, commodore 64, ZX Spectrum that would arrive 10 years later in the late 70’s.
It had 2k of RAM and 36k of fixed storage magnetic rope core memory, which was woven by hand and took months to assemble, so any software bugs were literally woven into the system.
A comparison between the Apollo Guidance Computer and say an iPhone 6 is tricky because the AGC was not a general purpose computer. It was built for a very specific task, had a unique operating system and with the 48-year gap in the technologies used, we can only really get very rough estimates.
The Apple iPhone 6 uses the ARM A8 processor which has about 1.6 billion transistors in it, the AGC had just 12,300. The iPhone 6 has 1Gb of RAM, about 488,000 times the AGC and in this one, 128Gb of non-volatile storage or about 3.5 million times the AGC.
As for performance, the iPhone 6 is somewhere between maybe 4 and 30 Million times faster than the AGC depending on what type of calculations are being done and if you include the iPhone’s GPU it would be even more.
So, if you had to fly back to the moon in an Apollo craft and given the choice, would you trust your life to a couple of iPhones in place of the AGC’s?, because you would actually have more computing power in just one of them than the whole of NASA had during all the Apollo missions.
However, if your iPhone crashed you would be in big trouble, whereas the ancient AGC was designed to recover from crashes or overloads and continue by itself, in essence, it was designed to be crash proof, something that is needed in mission critical situations.
The problem we have here is the context in which we see the Apollo computer today. We are now surrounded by computers, hugely more powerful and we don’t give them a second thought.
It’s very difficult for most people who are not computer engineers or assembler language programmers to imagine how you could do anything with such limited resources.
What we forget is that at the time of the design in 1962, this was to be the first embedded computer. It was a huge leap forward in miniaturised computing. From something the size of a large room to the size of a briefcase.
It would also be giant leap forward for software programming and the first time that software would be used for real-time problem solving that would be key to the entire mission, if it failed then people could die.
But its development was far from easy. It’s said that if the designers had known then in 1961 what they learned later or had a complete specification when given the contract to make it, they would have most likely concluded that it would just not have been possible with the early 60’s technology.
The contract for the design, development, and construction of the Apollo guidance, navigation system and software was given to the Massachusetts Institute of Technology , MIT in August, 1961 instead of NASA’s normal computer contractors, IBM.
But there were no specifications given in the contract because no one at NASA really knew what the requirements for an Apollo computer would be at that early stage.
As the project developed through the 1960’s, it became apparent not only that the task was going to be much more difficult that they first considered but by the mid to late 60’s the problems in the computer’s development were in danger of sinking the entire Apollo program if they couldn’t get the AGC to work.
By the time of testing in 1966 for the ill-fated Apollo 1, it became apparent that bugs in the software meant that the AGC couldn’t be relied upon to solely do the navigation course calculations as it was not accurate enough, something that could put the craft into the wrong orbit when it returned to earth.
It was decided that IBM mainframe computers on the ground would make the course calculations and send them to the AGC in the command module to be implemented. This way, known limitations could be worked around with much more powerful ground based computers and the results then sent to the AGC.
However, the Command module had to be capable of working independently if the ground link was broken like when it was flying behind the moon or if someone tried to jam the signal. So using a combination of the inertial guidance system and built in Sextant to check the star positions, they could still navigate without a ground data link.
As for the lander, the round trip delay of 1.5 seconds for the signals to get to the moon and back to earth would have been too long for ground control to remotely land the descent stage because the feedback needed to be in real time.
To this end, the descent stage AGC would work with the landing radar and the astronauts to land on the moon. This led to the Apollo 11 landing almost being aborted when a design bug in the landing radar, which had been left on standby during the descent in case of an emergency abort, created a flood of signals that overloaded the AGC and setting off computer error code alarms just before the landing.
Due to the AGC’s design, instead of crashing or locking up, like we maybe expect our iPhone or normal computer to do, it dropped all but the most important tasks, before then restarting itself.
This was not a fault, it was called RESET Protection, the AGC was designed so that all of the current data it was working on was stored. This meant it could be turned off and on again or reset at any time and it would just continue to work from where it left off, a bit like when your PC goes into sleep mode and then come back again but much, much quicker.
These features saved the mission from aborting and allowed Armstrong to control the orientation of the lander whilst the AGC controlled the descent to a successful landing.
Its things like this that made what is now about as powerful as the microcontroller in a toaster get men to the moon and safely back again, 6 times.
It also created a paradigm shift not only in space exploration but computing for the future….
Comments
Thanks for this high quality video and the good explanation. In this custom audio edit I did of the Apollo 11 lunar landing, you can hear the flight controllers and “back room” computer specialists working on the computer problem throughout the landing. A key person was 24-yr-old Jack Garman, credited with saving the mission.
4MB .mp3: https://docs.google.com/file/d/0B68EcQJkG9eeaDl6UnR0T3pWbGc/edit
Rough transcript inc’l background: http://forum.nasaspaceflight.com/index.php?topic=35230.msg1229852
Garman receiving awards for his quick thinking: https://joema.smugmug.com/Aerospace/Jack-Garman-and-Apollo-11/
Thanks for the post, I think Garman was the newest youngest member but was tasked with writing much of the landing routine software which is why he knew what the 1201 & 1202 errors where when they occured.
Jack wasn’t a programmer, but a NASA engineer who supported the Guidance Flight Controller during missions from the Flight Dynamics Staff Support Room. He worked with MIT engineers during mission training simulations to understand how the AgC functions during flight operations, including the purpose and nature of the alarm codes. Also, the trading simulator did not represent the spurious rendezvous radar signals, so the 11 crew did not experience the situation during training activities, alone or with the the Houston flight controllers and support staff.