Source code for the Apollo 11 Guidance Computer | Hacker News Reader

Source code for the Apollo 11 Guidance Computer

ibiblio.org

311 pointscarljoseph67 comments

There are some pretty great comments in here:

ALARM_AND_ABORT.agc - http://www.ibiblio.org/apollo/listings/Comanche055/ALARM_AND...

    TC       WHIMPER    -1   #  YES.  DON'T DO POODOO.  DO BAILOUT.

From the Guidance Computer Data Cards -http://www.ibiblio.org/apollo/CMC_data_cards_15_Fabrizio_Ber...

"POODOO abort, does software restart (ENEMA) and "GO TO POOH" (flashing Verb 37) unless "AVERAGE G" is running then only software restart"

From THE_LUNAR_LANDING.agc - http://www.ibiblio.org/apollo/listings/Luminary099/THE_LUNAR...

    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
    034091,000244: 
    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

P68 Landing Confirmation section of coding asks the astronaut to load V06N43 (verb/noun) with a great comment of " Astronaut: Now look where you ended up"

I like the note at the top of http://www.ibiblio.org/apollo/listings/Luminary099/BURN_BABY...

At the get-together of the AGC developers celebrating the 40th anniversary of the first moonwalk, Don Eyles (one of the authors of this routine along with Peter Adler) has related to us a little interesting history behind the naming of the routine.

It traces back to 1965 and the Los Angeles riots, and was inspired by disc jockey extraordinaire and radio station owner Magnificent Montague. Magnificent Montague used the phrase "Burn, baby! BURN!" when spinning the hottest new records. Magnificent Montague was the charismatic voice of soul music in Chicago, New York, and Los Angeles from the mid-1950s to the mid-1960s.

The source code is here: http://www.ibiblio.org/apollo/listings/Comanche055/. We changed the url to the top-level page which provides an overview.

Edit: see subthread below.

Hmm.

To me, the appeal of the original link was that, with one click, I could see the entire annotated-with-original-comments source of any part of the AGC. That was really exciting. A simulator (to me at least) is a lot less interesting ... and it's certainly an objectively very different kind of thing. (I for one wouldn't have even bothered clicking the current headline if I hadn't been looking for the original post's comments, which I had seen earlier.)

I'm not against curation in general -- it's a crucial aspect of HN, perhaps the crucial aspect. But I do think this particular case was a bit odd.

Ok, that's pretty persuasive, especially since most of the comments here are about the code. We changed it back.

Not quite sure why this links to the code, and not the top level which has a lot more useful information (such as the simulator needed to run the code).

http://www.ibiblio.org/apollo/

There's some more information here: http://googlecode.blogspot.co.uk/2009/07/apollo-11-missions-...

That's great - I actually came here to say "this is cool in an abstract way but what the fuck am I looking at? I'd love to learn a little bit more about the system". Turns out space folks are great at sharing knowledge!

By the way, last night I read the radio transcript from the time Neil and Buzz exited the lunar module: http://www.hq.nasa.gov/alsj/a11/a11.step.html (that site has loads of other Apollo transcripts too). It's annotated and has links to pics and videos. Fascinating.

>Turns out space folks are great at sharing knowledge!

I've read that one of the problems a new moon-or-beyond space program would have is that we are so far removed from the Apollo program that all institutional knowledge that was gained is gone because most of the engineers on those projects have passed away.

On the other hand, how much of that institutional knowledge is still useful? Certainly some of it is, but I think experience with the F1-B shows that new knowledge, like 3-D printing, means that parts of the old knowledge aren't needed.

I am a mechanical designer by profession and just want to point out that even I who use a 3D printer on a daily basis can't think of any other manufacturing method it has made completely obsolete. It is more like just another tool in my tool belt that adds another way to make something. As with any tool it has it's advantages and it's drawbacks and will only make sense to use it in certain scenarios.

Certainly. That's why I said "parts" and not "all".

What I meant is described in slightly more detail at http://arstechnica.com/science/2013/04/how-nasa-brought-the-... , in the section "3D printing goes to space"

> Using state of the art manufacturing processes where possible actually reduces cost—even if a newer manufacturing method is more expensive, the cost reductions gained from the design simplifications more than tip the scales. In particular, Dynetics and PWR are using techniques like selective laser melting and hot isostatic pressing (HIP) to "grow" entire complex engine parts out of metal powders. The Dynetics team is focusing as much as possible on reducing welds and joins, and therefore reducing assembly and manufacturing.

I don't know about that [1].

'NASA engineer here. I think it's actually kind of ludicrous to claim that we have somehow "lost" the technology of the Apollo program.'

1: https://news.ycombinator.com/item?id=7304980

Thanks. We changed to that from http://www.ibiblio.org/apollo/listings/Comanche055/.

Edit: persuaded to change it back. See https://news.ycombinator.com/item?id=8066666.

Reading the comments is fun...and a bit scary:

    TC   BANKCALL      # TEMPORARY, I HOPE HOPE HOPE
    CADR STOPRATE      # TEMPORARY, I HOPE HOPE HOPE

http://www.ibiblio.org/apollo/assembly_language_manual.html

Descriptions of instructions, opcodes, number encoding, etc

"arranged for by Deborah Douglas of the MIT Museum"

That's my wife's boss; the source material is still sitting on my wife's desk!

Do the famous 1201 and 1202 error codes make an appearance here? My assembly skills aren't good enough to find them, I'm afraid.

They do! They're in EXECUTIVE.agc (search for OCT 1201 and OCT 1202).

Those error codes mean "No VAC Areas" and "No Core Sets", respectively. Core sets were the basic task control blocks, including each task's entry point, priority, flags, some memory for temporary variables, and a few other things. VAC (Vector Accumulator) areas were a bit more interesting. Most of the real guidance code was not actually written in AGC assembly because it was so primitive and limiting. So, they created the "Interpreter" (INTERPRETER.agc) that's essentially a little virtual machine, that had its own assembly language (complete with mathematical and vector operations). Interpreted tasks needed more than the 7 words of temporary variables provided by the core sets, so they also allocated these VAC areas for more storage.

Those error codes showed up on Apollo 11 because of a weird electrical power phasing bug, essentially causing the radar to generate thousands of "interrupts" (actually cycle stealing operations) every second. With all of this additional work, the AGC didn't have enough time to finish its low priority tasks. And since those tasks hadn't exited by the time they were expected to, when the executive attempted to kick off new tasks, it found that no core sets or VAC areas were available, and sounded those program alarms.

Hadn't heard about this but found this link. Great story:

http://www.dailykos.com/story/2012/08/25/1124164/-Neil-Armst...

# Page 1220

# IDLING AND COMPUTER ACTIVITY (GREEN) LIGHT MAINTENANCE. THE IDLING ROUTIEN IS NOT A JOB IN ITSELF,

# BUT RATHER A SUBROUTINE OF THE EXECUTIVE.

I'm cursed to see spelling errors immediately, and obvious bugs only after hours of frustration.

http://www.ibiblio.org/apollo/listings/Comanche055/PINBALL_G...

>Filename: PINBALL_GAME_BUTTONS_AND_LIGHTS.agc

Can someone explain what this is? I doubt they had an actual game of pinball in their guidance computer.

It appears to be the code for the controls:

# THE KEYBOARD AND DISPLAY SYSTEM PROGRAM OPERATES UNDER EXECUTIVE

# CONTROL AND PROCESSES INFORMATION EXCHANGED BETWEEN THE AGC AND THE

# COMPUTER OPERATOR. THE INPUTS TO THE PROGRAM ARE FROM THE KEYBOARD,

# FROM INTERNAL PROGRAM, AND FROM THE UPLINK.

I think it's just someone with a sense of humor.

>I think it's just someone with a sense of humor.

Yeah I think that's the only explanation for it literally saying "GAME".

A rather dark one if "PINBALL GAME" could be interpreted as describing the expected outcome of a lunar landing ;)

PINBALL (something flashy with buttons) was a demo. And that demo got us to the moon:

"Apparently, nobody had yet arrived at any kind of software requirements for the AGC's user interface when the desire arose within the Instrumentation Laboratory to set up a demo guidance-computer unit with which to impress visitors to the lab. Of course, this demo would have to do something, if it was going to be at all impressive, and to do something it would need some software. In short order, some of the coders threw together a demo program, inventing and using the verb/noun user-interface concept, but without any idea that the verb/noun concept would somehow survive into the flight software. As time passed, and more and more people became familiar with the demo, nobody got around to inventing an improvement for the user interface, so the coders simply built it into the flight software without any specific requirements to do so."[1]

[1] http://www.ibiblio.org/apollo/ForDummies.html

Seems to have been part of the user interface

https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Softw...

  A set of interrupt-driven user interface routines called Pinball provided keyboard and 
  display services for the jobs and tasks running on the AGC. A rich set of user-accessible 
  routines were provided to let the operator (astronaut) display the contents of various 
  memory locations in octal or decimal in groups of 1, 2, or 3 registers at a time. 
  Monitor routines were provided so the operator could initiate a task to 
  periodically redisplay the contents of certain memory locations. Jobs could be 
  initiated. The Pinball routines performed the (very rough) equivalent of the 
  UNIX shell.

IIRC, pinball was also used for uplinks from the ground to the computer. From what I understand, such uplink commands simply consisted of a series of button presses to send to the computer, sent faster and more reliably than the astronauts could press the buttons themselves.

Reading some of the comments its a reasonably close analogy WRT the UI where its not allowed to go to sleep while it's still got something to say or think about. So the buttons and lights of a pinball machine keep flashing while there is at least one ball in play.

This is well commented code, for assembly.

The difference between a haphazard device driver, a bootloader by a ragtag group of hackers and a space capsule is national pride and lives at stake. ;-)

We should encourage software to be written as if it will one day fly in space.

Feature creep?

Wow. This is really impressive: assembler, real-time systems in space, mission-critical equipment, software that protects lives, etc.

Maybe that is too much, causing those writing the next "date finding" app to feel incompetent after reading this.

But at least we will know we are standing on shoulders of giants.

Nice Documentation. I liked this line: 058113,000352: 11,3037 77656 UNIT #PROBABLY UNNECESSARY.

Plus ca change...

https://github.com/search?l=c&q=%22PROBABLY+UNNECESSARY%22&r...

It's of cause fun to have this code to look at, but is it really useful? I don't mean it in a condescending way, but is this actually someone at, say SpaceX, looks at and goes: "Oh so that's how they did that"?

I don't think so. I believe that code is really tightly coupled with the hardware and at least some part of it covers unique cases.

However, these LoC have been written almost 50 years ago! That's truly fascinating.

It would be cool to frame and display one them, like one for Automatic Maneuvers.

http://www.ibiblio.org/apollo/listings/Comanche055/AUTOMATIC...

Probably not. Why?

- Today's processors and capabilities run circles around those of the Apollo. It might be interesting to know how they calculate a square root, not today.

- They have more sensors and inputs and have to think of new and advanced ways of making it all work together

It's useful in the same way that a historical text is useful -- to see where we came from.

It's achingly beautiful to the pocket protector set (me!).

This source code, for example, contains the very first Kalman filter ever used - Kalman was invited over to Moffett field to give talks about his paper, which led to his theory was used in LM code. But I think everyone is very aware of the state of the art at the time, and things have advanced a lot since then. It is impressive to see them cramming that into such a limited processor. But, 'whatever' as to that aspect of it. This is a historical artifact of an amazing feat based on cutting edge research in mathematics/control theory.

Wasn't it the PGNCS that had the Kalman filter? See my comment nearby which confused it with AGC.

It is my understanding that the AGC is the computer within the PGNCS. Terminology varies, as the last link below from NASA notes.

So far as I can tell, the AGC maintained the state vectors for the KF. Ground control would run batch mode least squares solutions, and pass it on to the LM, where the updates to the state vector would be applied by hand. I freely admit to not having worked through the code, but I believe the state vector update computations occur here: http://www.ibiblio.org/apollo/listings/Comanche055/MEASUREME...

sources: http://www.ieeecss.org/CSM/library/2010/june10/11-Historical...

http://en.wikipedia.org/wiki/Apollo_Guidance_Computer

http://en.wikipedia.org/wiki/Apollo_PGNCS http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/2009001...

Thanks, that helps. I've always wondered what the variables of the state vector were -- position, velocity, etc. it appears from the link that it could be a 6x6 of those two (position, velocity in x, y, and z), or a 9x9 when including radar/landmark bias. Now I know!

Project Apollo features a near-full implementation of the control panels in the Command Module and Lunar Module, and an increasingly accurate simulation of the internal systems (e.g. electrical distribution, fuel cells). Also the Virtual AGC software is supported, which allows you to run precisely the same on-board guidance software as used by the real Apollo Guidance Computer

http://nassp.sourceforge.net/wiki/Main_Page

Isn't it true that the AGC was initially designed to be the sole navigation computer, but when the implementation did not meet the requirements for accuracy (due to accelerometer and gyroscope drift), they switched to a ground-based radar system? This meant the AGC became the back-up in case the communications system failed. Does anyone know if the AGC was ever used to make a mission-critical decision in the absence of the ground-based radar system?

Edit: I think it was actually the PGNCS that was made back-up [1]. Sorry the comment about Kalman filter had me confused. Apparently PGNCS was still used for maintaining orientation, controlling rockets, and navigation during planned outages.

1: http://en.wikipedia.org/wiki/Apollo_PGNCS

For anyone interesting in learning more about this computer system, I highly recommend _Digital Apollo: Human and Machine in Spaceflight_ by David A. Mindell.

The hardware limitations! The incredibly low bug count! The memory hand-woven by ladies in a factory! I was blown away by the capabilities of the Apollo computer systems. The craft could have been practically unmanned.

Even more impressive, the computers could fly the craft while ALSO being interrupted by and adjusting to human intervention at nearly every step of the process. The pilots and the engineers practically battled over who would be in control of the craft. Fascinating stuff!

If you are into such things, do take a look at the orbiter project (http://orbit.medphys.ucl.ac.uk/) and the NASSP add-on (http://nassp.sourceforge.net/wiki/Main_Page). I spent many an after-school night flying to the moon by punching codes on a keyboard. It was amazing.

edit: Here's a video https://www.youtube.com/watch?v=7VDV6Gdxakc

In MAIN.agc there is a list of bugger words. Not that I know assembly in any meaningful way, but I've never come across this term before.

On Googling, it seems to be something to do with a checksum value?

yep, checksums

I don't know why, but I'm amused by the fact that there's no disclaimer about warranties, express or implied.

Also a lot of of good information in this document: http://www.ibiblio.org/apollo/hrst/archive/1029.pdf

(Much of the Apollo Guidance Computer and software was developed by the MIT Instrumentation Lab, the predecessor to Draper Lab.)

The entire source code was actually woven by wire into memory for the Apollo missions: https://www.youtube.com/watch?v=P12r8DKHsak

Story behind the code:

TALES FROM THE LUNAR MODULE GUIDANCE COMPUTER http://www.doneyles.com/LM/Tales.html

previously: https://news.ycombinator.com/item?id=3888638

https://news.ycombinator.com/item?id=3336584

https://news.ycombinator.com/item?id=6071825

I'm interested what computer languages do they use today for space vehicles?

I place my bet on static-type :D ( joke )

https://news.ycombinator.com/item?id=4339999

WOW ! << Do not use direct or indirect recursion. Do not use dynamic memory allocation after task initialization. >>

I think they should use COBOL, it's built in :)

Those are standard restrictions for embedded real-time systems, especially if the language itself doesn't offer guarantees on tail-call optimization (like the ML family, Erlang and others do). You have to guarantee the behavior of the program, and recursion (especially unbounded memory usage as in many C implementations) can royally screw things up. You may still have infinite loops because of an error in a for loop's terminating condition, but without dynamic memory and exploding stack usage you'll at least have enough memory left to deal with it when the watchdog timer kicks in.

what are bugger codes?

http://www.ibiblio.org/apollo/listings/Comanche055/MAIN.agc....

bugger codes is the AGC term for checksums. (see "Playing with Colossus" on this page: http://www.ibiblio.org/apollo/)

What would it take to make a working simulator from this? Except a whole lot of hardware of course

http://www.ibiblio.org/apollo/index.html

Ron Burkey has a great simulator that uses the actual code ... http://ibiblio.org/apollo/index.html .... here you have an unfinished port of his simulator ( although functional ) for iOS devices ... https://github.com/argaldo/iAGC ... which all of you are greately encouraged to contribute patches .. ;-)

This is awesome!

Tut, where are the supporting unit tests.

OMG. Where's the test coverage?

I'm surprised to see that it was written in HTML.

;)

Reply on news.ycombinator.com