The Apollo missions had technology no more complicated than a pocket calculator.

From link here, there's an information about Apollo Guidance Computer (AGC)

The on-board Apollo Guidance Computer (AGC) was about 1 cubic foot with 2K of 16-bit RAM and 36K of hard-wired core-rope memory with copper wires threaded or not threaded through tiny magnetic cores. The 16-bit words were generally 14 bits of data (or two op-codes), 1 sign bit, and 1 parity bit. The cycle time was 11.7 micro-seconds. Programming was done in assembly language and in an interpretive language, in reverse Polish.

So, I've stumbled upon some source code when I researched what was up there, and I've noticed great comments (eg. TEMPORARY, I HOPE HOPE HOPE)

# Page 801
        CAF TWO     # WCHPHASE = 2 ---> VERTICAL: P65,P66,P67
        TS  WCHPHOLD
        TS  WCHPHASE
        TC  DOWNFLAG

The actual programs in the spacecraft were stored in core rope memory, an ancient memory technology made by (literally) weaving a fabric/rope, where the bits were physical rings of ferrite material. "Core" memory is resistant to cosmic rays. The state of a core bit will not change when bombarded by radiation in Outer Space.

Virtual Apollo Guidance Computer (AGC) software is also on GITHUB!

Some part of documentation is here.

Another sample of source code with great comments.

033911,000064: 32,3017    06037        FLAGORGY        TC       INTPRET      #  DIONYSIAN FLAG WAVING

    034090,000243: 32,3241    13247        BZF      P63SPOT4               #  BRANCH IF ANTENNA ALREADY IN POSITION 1
    034092,000245: 32,3242    33254        CAF      CODE500                #  ASTRONAUT:     PLEASE CRANK THE
    034093,000246: 32,3243    04616        TC       BANKCALL               #                 SILLY THING AROUND
    034094,000247: 32,3244    20623        CADR     GOPERF1                               
    034095,000248: 32,3245    16001        TCF      GOTOP00H               #  TERMINATE
    034096,000249: 32,3246    13235        TCF      P63SPOT3               #  PROCEED        SEE IF HE'S LYING

    034101,000254: 32,3251    04635        TC       POSTJUMP               #  OFF TO SEE THE WIZARD ...
    034102,000255: 32,3252    74126        CADR     BURNBABY

My question here is this:

  • How were the teams writing this much code able to make it functional given the tools at the time?

Because if you compile so much code that was used on Apollo 11... it'd take days, even weeks. I seriously doubt that programmers back then left everything to happen by chance.

  • 4
    I had a fairly significant edit in order to make this hopefully more on topic. I think it's a fascinating question and one I'm hoping people are able to answer effectively!
    – enderland
    Dec 9, 2015 at 15:40
  • 3
    Read Hackers and The Mythical Man Month. There is quite a bit of material in there - I'm not sure it will fit in an answer in here.
    – user40980
    Dec 9, 2015 at 15:42
  • 2
    The "Tag - Question" style question titles are discouraged on Stack Exchange. Please leave the title as it is.
    – user40980
    Dec 9, 2015 at 15:52
  • 4
    There was no compile/fix cycle like your question suggests. You didn't create a rope memory, test it and then redo it if it didn't work; you got it right the first time. Dec 9, 2015 at 16:09
  • 7
    @RobertHarvey you HOPE HOPE HOPE you get it right the first time.
    – user40980
    Dec 9, 2015 at 16:12

4 Answers 4


There was a lovely documentary I'm trying to chase down about John 'Jack' Garman had to "invent" a "a priority-scheduled multiprogramming operating system". This may have been related to the lander module though. The story was that when you were landing the lander, you better give priority to guidance because other things, like the temperature in the cabin for the next 15 seconds, didn't really matter if you crashed and burned. On the first shot they overloaded the computer and alarms started happening because some subroutines were not getting executed. There were too many loaded, but thanks to the priority concept, which Garman foresaw and built in because he thought it was a good idea, the low priority routines didn't bog down the higher priority landing routine.

Watching the documentary at the time, I was struck about how it was like doing a major refactoring on the code without telling management and almost getting fired because you were late on what you were supposed to be working on. In this case however, the refactoring came to light when reason for the alarms was investigated. (And management was still pissed! :-)

Some links:

No, a “checklist error” did not almost derail the first moon landing


How They Built it: The Software of Apollo 11

NASA Johnson Space Center Oral History Project Edited Oral History Transcript

Brief history of NASA´s Apollo Program Excerpt: Five minutes into the descent burn, and 1,800 m above the surface of the Moon, the LM navigation and guidance computer produced the first of several unexpected "1202" and "1201" program alarms. The computer engineer at Mission Control Center in Houston, Jack Garman, told guidance officer Steve Bales it was safe to continue the descent. These alarms were indications of " executive overflows" , meaning the guidance computer could not complete all of its tasks in real time and had to postpone some of them.

Recalling the 'Giant Leap' Excerpt: We knew what that was and that it should not be happening. But we had designed a system that tried hard to recover from any overload conditions. So I remember hearing [NASA computer engineer] Jack Garman shouting, "Go, go!" And on they went. Then we listened as Neil flew the LEM on and on trying to find a good spot to touchdown. Our new worry was lack of fuel remaining. But finally we heard the contact notice and then, "The Eagle has landed."

Jack Garman Interview

EDIT: Maybe this was the documentary: Apollo 11: The Untold Story (2006)

Cast: John R. Garman ...
Himself - Apollo 11 Computer Engineer (as Jack Garman)

(Among others).

Update: A Hacker From South Africa Just Rescued the First NASA Computer in Space


If I understand correctly, the development process was peer review and experimentation.

The team consisted of people like "Math Doctors" - extremely dedicated, intelligent, passionate, detail-oriented folks whose lives were dedicated to their work. So when I say peer review, I mean many peer reviews over the course of many months (more than a year).

These developers "ran the simulations in their heads", "debugged the software on paper" and worked in groups with many developers looking at the same code over and over until they were convinced it was correct. There were multiple teams - each working on a part of the whole.

My Numerical Methods professor at The Ohio State University (Spring '96) wrote the code that decided when to kick off a stage of the booster rocket. He described the printout being the size of the phone book (So, maybe 2.5 to 3.5 inches thick of 8.5 x 11 inch paper - he didn't describe the font size) of Fortran code.

When convinced, they launched an unmanned missile (rockets technically don't have gyroscopes) with a radio on board that emitted a beep at regular intervals. They listened to the beeps up to the point they expected the radio to impact the moon (crash into it and destroy itself) and stop beeping. They knew that if they missed, the radio would keep beeping long past the calculated time of impact. Impact occurred 15 seconds after the calculated time.

This admitedly anecdotal story are my recollections from an office visit with the doctor. He was very old, and it was a long time ago. This is my best recollection.

  • 2
    He described the printout being the size of the phone book (So, maybe 2.5 to 3.5 inches thick of 8.5 x 11 inch paper Generally, the code was printed in landscape mode with about 55 - 60 lines per page. A ream (100 sheets) of printout paper is about 1.75 inches thick. Feb 15, 2016 at 18:01
  • @GilbertLeBlanc A ream is typically 500 sheets. (sometimes 480)
    – joshp
    Feb 17, 2016 at 7:49
  • @joshp: You're right. 500 sheets of printout paper is about 1.75 inches thick. Feb 17, 2016 at 14:47

The AGC is controlled with verbs and nouns

The Apollo command software is not written in any syntax users would recognize today. Astronauts input commands numerically, with each two-digit number representing a verb or a noun. The verb described the action to be performed, and the noun specified the data to be affected by the verb’s action.

Astronauts hated the verb and noun setup

Ramón Alonso, one of the original AGC hardware developers, said the interface had been invented to impress visitors to their lab, but stuck around for the flights when nobody developed a better interface. Critics said it wasn’t "scientific," and the first astronauts—all elite jet pilots—preferred dials and switches, similar to an airplane control panel.

"The AGC was very slow, but very reliable and very small for that time in the history of digital computers. It was the earliest to use integrated circuits."

The software as it was designed was built basically from scratch by MIT.

You can download and install the Apollo Guidance Computer emulator program on your personal computer, no problem. Here’s what it looks like on Mac OS X.

enter image description here


Like pretty much every other software project, it was done under aggressive deadline and quality pressure. Fortunately a large archive of material from software project manager Howard W. “Bill” Tindall, Jr. is available here.

If you sample the memos, you can get a very good sense of the normal conflict between time, features, and defects. It's worth noting that development proceeded over a number of years like the rest of the project.

Design of the system began in the second quarter of 1961, and NASA installed a Block I version in a spacecraft on September 22, 1965. Release of the original software (named CORONA) was in January 1966, with the first flight on August 25, 1966. Less than 3 years after that, designers achieved the final program objective (http://history.nasa.gov/computers/Ch2-5.html)

I can't find specific references to how the software was created, but given the date I can only assume that much of it was done on pen and paper, with "simulations" done manually. It seems there was a system for loading programs into the AGC with punch cards, presumably for "rapid" testing on the ground without the need to fabricate rope memory.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.