Tuesday, July 19, 2016

Techy Tuesday - Take a Look at the Apollo 11 Source Code

And the guidance computer that ran it.

This story has been in a few places this week, but my link is to Design News.
Chris Garry, a former NASA intern, has uploaded the full source code for the Apollo 11 flight computer to GitHub, a popular site where programmers share code and tips, and it's proven to be a nice slice of nostalgia in more ways than one.

The software for NASA's Apollo Guidance Computer (AGC), which was installed on Apollo command modules and lunar modules, was developed in the 1960s at MIT. At the time nothing for what NASA was trying to do existed so the team from MIT had to code the entire thing from scratch. To do so they created their own version of Assembly language as well as a method for storing computer programs called “core rope memory”, which at the time offered greater storage capacity.
How much memory?  The computer contained a blistering 37 Kilobytes of memory.  For those of you younger than 40, that's .000037 Gigabytes or 1 millionth of the storage in a 32 Gig smartphone.  That's OK because it is a form of core memory, and each byte required tiny ferrite cores be woven into place, so building 37K bytes is a pretty difficult accomplishment. According to the Wiki:  
Contrary to ordinary coincident-current magnetic-core memory, which was used for RAM at the time, the ferrite cores in a core rope are just used as transformers. The signal from a word line wire passing through a given core is coupled to the bit line wire and interpreted as a binary "one", while a word line wire that bypasses the core is not coupled to the bit line wire and is read as a "zero". In the AGC, up to 64 wires could be passed through a single core.
The Apollo Guidance Computer and its display. 

The overall code required was quite a bit larger than 37K; the article quotes an estimate of 2 Megs.  Because that's such a severe size constraint, the engineers relied on switching programs and only running what was needed for a particular part of the mission.  Planning for the unforeseeable, they developed the ability for the code to swap less important tasks for critical tasks.  You may have read (or remember!) that during the last few minutes of Apollo 11's landing approach, the computer started flooding its display with warning messages.  This was intentional and probably saved the landing. 
Due to an error in the checklist manual, the rendezvous radar switch was placed in the wrong position. This caused it to send erroneous signals to the computer. The result was that the computer was being asked to perform all of its normal functions for landing while receiving an extra load of spurious data which used up 15% of its time. The computer (or rather the software in it) was smart enough to recognize that it was being asked to perform more tasks than it should be performing. It then sent out an alarm, which meant to the astronaut, I'm overloaded with more tasks than I should be doing at this time and I'm going to keep only the more important tasks; i.e., the ones needed for landing ... Actually, the computer was programmed to do more than recognize error conditions. A complete set of recovery programs was incorporated into the software. The software's action, in this case, was to eliminate lower priority tasks and re-establish the more important ones ... If the computer hadn't recognized this problem and taken recovery action, I doubt if Apollo 11 would have been the successful moon landing it was.
The code was written by a group at MIT who was literally "going where no man has gone before", at least in the software sense.  At some point, they took this publicity photo of a printer dump of the entire source code listing, alongside Margaret Hamilton, director of Apollo Flight Computer Programming at MIT's Draper Laboratory, and source of the previous quoted paragraph. 
Continuing our story, this code was never "lost", but it's about 50 years old and time takes its toll on any form of storage, including printouts.  Do you have any cassette tapes from the Commodore 64 era, or 5 1/4" floppies from your first 8088-based PC?  It's like that.  Efforts have been going on for some time to preserve this code.
Back in 2003 MIT scanned the physical pages of the AGC code and made them available. But Gary Neff, an airline pilot from Colorado saw how unreadable some of the pages were and decided to reconstruct the code himself. It popped up in a few other places, like on a Google blog from 2009, but Neff's work mostly languished in Internet obscurity until Garry found it and uploaded it to GitHub, where it has found new life among programmers poring over the code and suggesting ways to improve and change it.
Users scanning over the source code have found the coding comments peppered with jokes, asides, and even references to popular songs, Shakespeare, and cultural events of the time.
One of the online sources I came across was surprised that software engineers left jokes in the code comments.  A sure sign they never worked around any!

The code, though, is a monument to great thinking, excellent resource management, and the best of what geeks can do.  I hope it lives forever on GitHub.


  1. So many years ago I can't even remember when I worked on an IBM 1401. It had a 2K memory. The trick was to write a program that fit in the 2K that did what you wanted to AND to make everything more complicated would also read the card input at max speed (I think it would either read 400 or 200 cards a minute. The trick was to write a short enough program so you initiated the read cycle fast enough to hit that 400 card/minute cycle otherwise it defaulted to 200 CPM.

    But about decade before that I worked on a behemoth that had just over 64K but it had a small test memory (24 commands) which was wired by hand to run small quick programs. Two words/commands in test memory were programmed with switches on the front panel. The trick was to write something meaningful in 24 commands.

    Another story about that first computer is that I was actually a computer repair person not a programmer. But in order to even work on them you had to be able to program them in machine language of course. Machine language was tough and I can remember when I was introduced to an "assembler" language. I was in awe, and so excited. I could now write big programs without trying to keep everything in my mind as I wrote it. Then there was the programming languages like COBOL and Fortran, I was in hog heaven. Ahh, back then it was fun. Eventually it became drudgery.

    1. At work, there are systems that are almost fifty years old.
      We stitch them together to keep them running.
      Sometimes we spend days researching dusty old books trying to understand how these systems work.
      It's actually a lot of fun.

    2. Although I wrote very few programs, I worked on some early micros, PDP-8/11 vintage. That was 10 years after Apollo. We'd key in the programs on the front panel switches - in octal. We had a paper tape punch, so we could write stuff and punch the tape. We'd load the paper tape reader's routine with the front panel switches, then use the reader to load the real program.

  2. Great story, thanks for posting it.

    I still (and always will) remember watching the landing as it happened on my little Sony TV-500U, the "Tummy TV".

    What amazing times we lived through....

  3. And it must be synchronicity that you're posting this now.
    Tomorrow is the forty seventh anniversary of the moon landing.
    I have long been fascinated by the computer language and hardware that was used to make that voyage.

    1. I think that's why Design News ran the piece.

  4. My former brother-in-law, Dr. Richard Sweet, was a software engineer who left Xerox with the group that started Adobe. He was an incredible chef, made his own furniture (quality woodworking), volunteered with Habitat for Humanity helping to build houses, and was an all around nice guy. I heard he married another engineer after he finally got shut of my gold-digging sister. He would never have survived _that_ experience (marriage to my sister) if he hadn't had a world-class sense of humor.

  5. Thanks Graybeard. Fascinating history.

  6. The first computer I worked on was the Marine Tactical Data System, an offshoot from the Naval Tactical Data System (which has an amazing story behind it, see http://ethw.org/First-Hand:No_Damned_Computer_is_Going_to_Tell_Me_What_to_DO_-_The_Story_of_the_Naval_Tactical_Data_System,_NTDS ). The storage was a drum, covered with many fixed read and write heads. There was no computer language that I was aware of. The programs were modified by entering the bits in a row of switches; the readout was a row of incandescent lights. Only one kind of integrated circuit was used, a shift register. All the rest of the logic was implemented with discrete diodes, resistors and transistors. Imagine a 6" x 7" card with six AND gates on it.

    The system was essentially a truck-based AWACS, used for performing intercepts and other flight control tasks.

  7. I'm old now and some twenty years ago, I had the privilege to work with the Jim Smith, who wrote in octal, programmed the first satellite dishes and satellite simulators, a real pioneer in the space industry, he built what had only barely begun to be understood. And a real Colorado cowboy at heart, salute !