Author Topic: Apollo Guidance Computer code now available  (Read 13707 times)

Offline molesworth

  • Mars
  • ***
  • Posts: 349
  • the curse of st custards
Apollo Guidance Computer code now available
« on: July 11, 2016, 10:38:52 AM »
I'm sure I'm not alone in being fascinated by the computer technology used for Apollo* (and other missions, manned and unmanned), so I was pleased to find out that the source code for the AGC has been uploaded onto GitHub.

Here's a link to the original article - http://qz.com/726338/the-code-that-took-america-to-the-moon-was-just-published-to-github-and-its-like-a-1960s-time-capsule/
And here's a link to the source on GitHub - https://github.com/chrislgarry/Apollo-11

Enjoy...  ;D


* - quite probably a childhood fascination with space technology and computers is what spurred me into a career in software  :)
Days spent at sea are not deducted from one's allotted span - Phoenician proverb

Offline onebigmonkey

  • Uranus
  • ****
  • Posts: 1607
  • ALSJ Clown
    • Apollo Hoax Debunked
Re: Apollo Guidance Computer code now available
« Reply #1 on: July 11, 2016, 12:17:14 PM »
OK, where's the 1202?

Offline JayUtah

  • Neptune
  • ****
  • Posts: 3814
    • Clavius
"Facts are stubborn things." --John Adams

Offline JayUtah

  • Neptune
  • ****
  • Posts: 3814
    • Clavius
Re: Apollo Guidance Computer code now available
« Reply #3 on: July 11, 2016, 03:25:47 PM »
See also line 146 in the same file.  That's the 1201 alarm.  Note from the comments that they are variations on the same error.  The 1202 alarm comes from having filled up the core-set table, roughly equivalent to the process table in a modern OS.  It represented the EXECUTIVE's (the AGC equivalent to the kernel) knowledge of a job being executed.  The 1201 alarm on line 146 arises when a program tries to obtain a range of erasable memory to use for its variables.  The problem in each case, as you probably know, was the failure of real-time tasks to complete on time and exit, which in turn was caused by an abundance of counter interrupts from the rendezvous radar.  In the mode selected at the time, the radar's 800 Hz power supply signal was not in phase with the AGC's reference 800 Hz signal, thereby causing double the number of interrupts.
"Facts are stubborn things." --John Adams

Offline bknight

  • Neptune
  • ****
  • Posts: 3132
Re: Apollo Guidance Computer code now available
« Reply #4 on: July 11, 2016, 05:46:00 PM »
That pesky landing radar :)  o what did they do to the program to eliminate those two alarms?
Truth needs no defense.  Nobody can take those footsteps I made on the surface of the moon away from me.
Eugene Cernan

Offline ka9q

  • Neptune
  • ****
  • Posts: 3014
Re: Apollo Guidance Computer code now available
« Reply #5 on: July 11, 2016, 06:00:03 PM »
They fixed the peripheral hardware bug that triggered the problem. There really was no way to fix it in the software itself, except maybe to disable the interrupt entirely when it's not expected.

Offline JayUtah

  • Neptune
  • ****
  • Posts: 3814
    • Clavius
Re: Apollo Guidance Computer code now available
« Reply #6 on: July 11, 2016, 06:08:36 PM »
That pesky landing radar :)  o what did they do to the program to eliminate those two alarms?

Rendezvous radar.  The gist was to have it operating during the landing, so that in case of an abort the LM would know where the CSM was immediately and wouldn't have to wait for the radar to warm up and start sending good data.  Having the radar in that mode was a late, and relatively untested, addition to the flight plan.  It wasn't known at the time that it would cause the unsynchronized radar electronics to send interrupts at twice the rate.

It's unclear what software changes if any were implemented between Luminary 1A and Luminary 1B; the mission report just informs us that spurious interrupts would not be processed.  It goes on to say that with the radar selector switch in anything but the computer-control mode, the radar angle registers in the control electronics would be zeroed and not cause interrupts, so it's likely this is how the problem was fixed.  It's a better solution anyway than trying to special-case the software.  It's my understand that the Apollo 11 tweak -- keeping the rendezvous radar "hot" -- would still work, but simply not send data to the computer until the radar mode selector switch is set to LGC.  The computer would then immediately begin receiving good data.
"Facts are stubborn things." --John Adams

Offline ka9q

  • Neptune
  • ****
  • Posts: 3014
Re: Apollo Guidance Computer code now available
« Reply #7 on: July 11, 2016, 06:26:57 PM »
The problem was a remarkably subtle one. Like so many bugs, it's obvious in hindsight only.

The LM rendezvous radar measured antenna angles as well as range and range rate. This being before the modern era of optical shaft encoders, it used angular resolvers, a rugged and venerable old technology closely related to the synchros widely used in WW2 to aim naval guns. (Resolvers are generally 2-phase, synchros are usually 3-phase.)

Resolvers and synchros are a special kind of motor/generator. An AC excitation is fed via slip rings or rotary transformer to the rotor, inducing AC in two (resolver) or 3 (synchro) field windings that depends on the position of the rotor. In a synchro, the field windings are connected to those of another synchro whose rotor is fed from the same AC supply. Nothing happens when you turn on the power until you twist one of the shafts; then the other turns in precise synchronism with the first.

A resolver is similar except instead of driving a second device the induced AC stator signals are digitized and fed into a computer to read the angular position of the resolver shaft. In a 2-phase resolver, one stator signal has an amplitude that varies with the sine of the rotor position and the other with the cosine. Take atan2(cosine,sine) and you have rotor angle.

But this requires that the computer sample the same AC signal powering the resolver and this wasn't the case on Apollo 11. In the specific configuration of the system, for some reason the resolver and the computer were given 800 Hz AC signals from separate oscillators. They were locked in frequency but not in phase, so when they powered up they settled down into one of several (three?) relationships at random.

Turns out that some of these phase relationships posed no problem, but others were such that even a tiny jitter in the relative phase of the two supplies could turn into large changes in the resolver signals, making the computer think that the resolver rotor was turning slightly when it was actually not turning at all. Hence the very high spurious interrupt rate on the computer.
« Last Edit: July 11, 2016, 06:28:37 PM by ka9q »

Offline JayUtah

  • Neptune
  • ****
  • Posts: 3814
    • Clavius
Re: Apollo Guidance Computer code now available
« Reply #8 on: July 11, 2016, 07:13:15 PM »
Nothing happens when you turn on the power until you twist one of the shafts; then the other turns in precise synchronism with the first.

And the control twist was often provided by a mechanical analog computer.  The fire control computers on these warships were works of art.

Quote
[F]or some reason the resolver and the computer were given 800 Hz AC signals from separate oscillators. They were locked in frequency but not in phase, so when they powered up they settled down into one of several (three?) relationships at random.

The radar had three modes:  SLEW, AUTO, and LGC.  SLEW means manual control.  The radar antenna is stationary unless the crew manually operates the shaft and trunnion driver switches.  You would use this to roughly point the antenna in the general direction of the CSM.  AUTO mode is useful when the antenna is pointed close enough to the CSM that its own electronics can maintain a track.  If the CSM drifts off center, the controller electronics can send shaft and trunnion drive commands.

But mostly you wanted LGC mode, in which case the radar was sending range and angle data to the computer via counter interrupts.  Also, the LGC could command the radar antenna by sending shaft and trunnion commands.  Due to mission ops overkill, flight controllers generally knew what approximate shaft and trunnion angles would apply to all the steerable antennas at all times, given the spacecraft orientation, and it was generally easiest for the crew to aim the antenna by switching out of SLEW or AUTO mode into LGC mode and punching in the shaft and trunnion angles read up to them.

But no one entirely trusted the computer, so there were methods of flying both spacecraft that didn't rely on the computer.  And in the case of having to fly a rendezvous under AGS control or (heavens forbid) manual control, there had to be a way of interpreting radar data that assumed the LGC was entirely dead -- including its 800 Hz reference.  Thus in SLEW and AUTO modes, AGS got the range and angle data crammed into it by the separate power supply.  And the cockpit displays were also driven by the same reference signal.  In theory an ascent and rendezvous could be flown by reading off the raw shaft and trunnion angle displays and the range strip.  But I'd bet only Aldrin would have been able to do it.

Why in heaven's name they didn't phase-lock the LGC and radar power supplies to start with, I'll never know.  But I think you are probably on the right track when you note that slightly out-of-phase signals were not considered especially problematic, especially among analog control system designers who were just cutting their teeth on digital controls.

Incidentally I ran into a similar problem in 2002.  A contractor putting together an assembly for us "fixed" a design error by tying two tachometer wires to the same contact pin, from different rotating components.  The "fix" was discovered late enough in the process that I and my best software engineer had to figure out a way to decode the convolved tachometer pulses on the wire.  And yes, as you insinuate, the signals can combine such that there are twice as many pulses as expected, the correct number of pulses (only much longer), or the agonizingly ambiguous case where the falling edge of the outgoing signal combines with the rising edge of the incoming signal.  Luckily these were square wave pulses and we got by until we could justify the expense of reworking the assembly.  I have one of these assemblies on my Shelf of Shame in the office.
"Facts are stubborn things." --John Adams

Offline ka9q

  • Neptune
  • ****
  • Posts: 3014
Re: Apollo Guidance Computer code now available
« Reply #9 on: July 11, 2016, 10:24:34 PM »
Had they just done all this on a Raspberry Pi, they probably would have had plenty of CPU cycles left even with the spurious RR interrupts...

Offline smartcooky

  • Uranus
  • ****
  • Posts: 1967
Re: Apollo Guidance Computer code now available
« Reply #10 on: July 11, 2016, 10:51:20 PM »
So, are the 1201 and 1202 alarms something akin to a "stack overflow" in a CPU?
If you're not a scientist but you think you've destroyed the foundation of a vast scientific edifice with 10 minutes of Googling, you might want to consider the possibility that you're wrong.

Offline ka9q

  • Neptune
  • ****
  • Posts: 3014
Re: Apollo Guidance Computer code now available
« Reply #11 on: July 12, 2016, 02:15:43 AM »
Sort of. Or malloc() returning NULL.

Offline bknight

  • Neptune
  • ****
  • Posts: 3132
Re: Apollo Guidance Computer code now available
« Reply #12 on: July 12, 2016, 08:25:17 AM »
Had they just done all this on a Raspberry Pi, they probably would have had plenty of CPU cycles left even with the spurious RR interrupts...

Were They available in the late 60's?
Truth needs no defense.  Nobody can take those footsteps I made on the surface of the moon away from me.
Eugene Cernan

Offline bknight

  • Neptune
  • ****
  • Posts: 3132
Re: Apollo Guidance Computer code now available
« Reply #13 on: July 12, 2016, 08:26:19 AM »
....  I have one of these assemblies on my Shelf of Shame in the office.
Just how large is this shelf? :)
Truth needs no defense.  Nobody can take those footsteps I made on the surface of the moon away from me.
Eugene Cernan

Offline JayUtah

  • Neptune
  • ****
  • Posts: 3814
    • Clavius
Re: Apollo Guidance Computer code now available
« Reply #14 on: July 12, 2016, 10:18:33 AM »
So, are the 1201 and 1202 alarms something akin to a "stack overflow" in a CPU?

If you want to compare it to a POSIX compliant system, 1201 would be equivalent, as ka9q has said, to malloc() returning a null pointer.  Systems based on call stacks weren't well known when the AGC was designed, and the AGC had none.  There wasn't any such thing as a stack overflow in that architecture.  The few thousand words of erasable storage were treated as a POSIX heap divided into contiguous fixed-size regions.  All program local variables had to fit within the assigned region.  As the programs were in the non-erasable core rope, code patches had to appropriate one or a portion of one of these regions.  This feature was used on Apollo 14 to hold the software patch to fix the flaky Abort button.

1202 would be more akin to fork() returning -1.  There wasn't as evolved a concept of a process as there is in POSIX, but think of the AGC as having a process ulimit of 6 (AGC) or 7 (LGC).  Those numbers were worked out in testing and represented a very careful allocation of computer resources at each point in the mission.  With the LGC in P63 or P64, no more than 7 task slots ("core sets") were needed and the LGC was operating at 90% capacity.

Keep in mind, however, that this operating system was a brilliant combination of revolutionary, simple, and reliable.  Those 7 core sets were filled in priority order.  So the process denied a process table entry (1202) or an erasable memory allocation (1201) was the lowest priority process that would be running at that time.  And at 90% capacity, the programmers envisioned that either of these alarms might occur momentarily and then go away if the computer load spiked.  Steve Bales' handwritten notes on program alarms bear this out -- the 1201 and 1202 alarms were a problem only if they were persistent.  That would mean a program in the LGC was persistently being starved of attention and might cause a problem later.

The story behind Bales' notes is famous.  During the last MOCR simulation a 120x alarm had been thrown and Bales had mistakenly called an abort.  His backroom guy Jack Garman set him straight, and Bales dutifully recorded it.  And if you listen to the flight controllers' loop during Apollo 11's P63, you hear Bales call "go" on the 1202 alarm, and then say "That's the same thing we had!" referring back to the problematic sim.  He later reported that Garman had been on the spot with the recommendation on the guidance loop while Bales was still skimming his notes to see if 1202 was in the group of acceptable intermittent alarms.  But had they not simulated program alarms, Bales might well have called an abort on Apollo 11 without there needing to be one.  You never know what bit of your training is going to be the one that saves a mission.
"Facts are stubborn things." --John Adams