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.
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"
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.
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).
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.
> 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.
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.
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.
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.
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]
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"?
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.
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...
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!
- 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
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
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.
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!
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.
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 .. ;-)
ALARM_AND_ABORT.agc - http://www.ibiblio.org/apollo/listings/Comanche055/ALARM_AND...
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...