Home

Apollo 11 Source Code on GoogleCode

A blog post announces that some of the source code for the Apollo 11 spacecraft has been put online.

On this day 40 years ago, Neil Armstrong and Buzz Aldrin became the first humans to walk on the Moon. This was quite an achievement for mankind and a key milestone in world history.

To commemorate this event the Command Module code (Comanche054) and Lunar Module code (Luminary099) have been transcribed from scanned images to run on yaAGC (an open source AGC emulator) by the Virtual AGC and AGS project.

Since we LTUers spend a lot of time talking about the highest of the high level languages it's illuminating to see how much was done with so little. The source also shows that flying to the moon is really not that different from the kind of programming most programmers do every day. Note the comments.

VRTSTART	TS	WCHVERT
# Page 801
		CAF	TWO		# WCHPHASE = 2 ---> VERTICAL: P65,P66,P67
		TS	WCHPHOLD
		TS	WCHPHASE
		TC	BANKCALL	# TEMPORARY, I HOPE HOPE HOPE
		CADR	STOPRATE	# TEMPORARY, I HOPE HOPE HOPE
		TC	DOWNFLAG	# PERMIT X-AXIS OVERRIDE
		ADRES	XOVINFLG
		TC	DOWNFLAG
		ADRES	REDFLAG
		TCF	VERTGUID

By James Iry at 2009-07-21 12:59 | Fun | History | other blogs | 69860 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hand Compiled

There is an interesting interview with one of the developers

He mentions that the software was written in a higher level language called MAC (MIT Algebraic Compiler) and then hand compiled down to the assembly code that we can see now on google code.

It would be really cool if the MAC code was available too since that seems to be where most of the actual development of the system happened.

By Lars Oppermann at Tue, 2009-07-21 14:07 | login or register to post comments

Two wrongs don't make a right, but two bugs do.

LUMINARY was never completely bug free. Allan told me about a fascinating series of events that could have easily prevented the first moon landing and might have caused disaster. Allan was the principal designer of the LM's descent guidance program which steered the LM by gimballing and throttling the descent engine. Whenever the computer commanded the engine to increase or decrease thrust, the engine (and LM) reacted after a short time lag. Allan's descent program needed a routine to accurately estimate the new thrust level, which could be accomplished by reading the "delta-V" (change in velocity) measured by the LM's accelerometers. He wrote a short routine that took into consideration, i.e., compensated for, the engine's lag time, which TRW's "interface control document", full of useful information for the programmers, said was 0.3 seconds. It took 0.3 seconds for the LM's descent engine to achieve whatever thrust level the computer might request. The final version of the thrust routine, which was put into the LM, was written by Allan's friend Don Eyles. Eyles was sufficiently enthusiastic about the programming challenge that he found a way of writing it which required compensating for only 0.2 of the 0.3 seconds. The IBM 360 simulator showed Eyles' program worked beautifully. His routine was aboard Apollos 11 and 12 which landed successfully. However, telemetry transmitted during the landings later showed something to be very wrong. The engines were surging up and down in thrust level, and were barley stable. A guy at Johnson Space Center called Allan and informed him that the LM's engine was not a 0.3-second-lag engine afterall. It had been improved some time before Apollo 11's launch such as to lower the lag time to only 0.075 seconds. Correction of this item in the interface control document had simply been overlooked. Once this discrepency was discovered, the IBM 360 simulator was reprogrammed to properly simulate the actual, faster engine. Running on the simulator, Don Eyle's thrust program, with the 0.2-second compensation, exhibited the surging that had occured on the real flights. But here's the most interesting fact: the simulator also showed that had Allan Klumpp chose to "correct" Don Eyles' program by compensating for the full 0.3 seconds that was printed in the document, the LM would have been unstable and Apollo 11 would never have been able to land. By pure luck, Don Eyles was creative enough to write the thrust routine in a way that kept the LM just inside the stability enveloppe and allowed successful landings!

By James Iry at Tue, 2009-07-21 14:23 | login or register to post comments

Wow..

And I thought my job was stressful!

By SamK at Wed, 2009-07-22 10:12 | login or register to post comments

It's interesting...

... but browsing this, there seem to be a few examples of error reporting by alternative-returns from "subroutines" -- "if X works, return to L1, otherwise L2."... (Admittedly in these subroutines aren't re-entrant/can't be called recursively). I guess before you have a stack-discipline for recursion, using continuations is an obvious thing to do... Then again, you can argue whether, in the absence of a stack, they're really subroutines...

By cdtw at Tue, 2009-07-21 21:23 | login or register to post comments

Non-re-entrant Subroutines

It's worth keeping in mind that Fortran is historically a language that supports subroutines without re-entrancy. Although you had a call stack, this was a stack of return addresses for the PC, and not a stack of variables. Although a common extension, recursion was not formally supported until Fortran 90, and even this was via a special keyword.

By Kevlin at Thu, 2009-07-23 09:39 | login or register to post comments

Not necessarily a stack

IIRC, there were some early implementations that didn't even use a call stack; instead, each subroutine would have an associated return address. To call FOO, you would set FOO's return address and then jump to FOO. A cycle in the call graph was Bad News.

By John Stracke at Thu, 2009-07-23 14:24 | login or register to post comments

1201

I searched for "1201", and got something which looks plausibly like the famous error message.

By Richard W.M. Jones at Thu, 2009-07-23 19:43 | login or register to post comments

Highly likely...

Highly likely. It occurs as part of the sequence: 

		TC	BAILOUT1
		OCT	1201		# NO VAC AREAS.
and a bit later on, there's the other unexpected alarm that came up during the lunar descent: 

		TC	BAILOUT1	# NO CORE SETS AVAILABLE.
		OCT	1202
The obvious interpretation is a Transfer of Control to an error-handling and restart routine, 'BAILOUT1', with the following octal word serving as an argument indicating what alarm code to show on the display/keyboard. (BAILOUT1 itself is toward the bottom of ALARM_AND_ABORT.s --- well, better there, I guess, than BURN_BABY_BURN...)
By Robert Thau at Thu, 2009-07-23 23:58 | login or register to post comments

The team behind the Virtual

The team behind the Virtual AGC project have said the emulator is not a flight simulator, but an accurate recreation of the functionality of the computers which were installed in the Apollo vehicles.

By rakesh at Sat, 2010-01-16 06:33 | login or register to post comments