How They Built the Software of Apollo 11

LinuxScribe tips a piece up at Linux.com with inside details on the design and construction of the Apollo 11 code. There are some analogies to open source development but they are slim. MIT drafted the code — to run on the Apollo Guidance Computer, a device with less grunt than an IBM XT — it had 2K of memory and a 1-MHz clock speed. It was an amazing machine for its time. NASA engineers tested, polished, simulated, and refined the code. "The software was programmed on IBM punch cards. They had 80-columns and were 'assembled' to instruction binary on mainframes... and it took hours. ... During the mission, most of the software code couldn't be changed because it was hard-coded into the hardware, like ROM today... But during pre-launch design simulations, problems that came up in the code could sometimes be finessed by... computer engineers using a small amount of erasable memory that was available for the programs. The software used a low-level assembly language and was controlled using pairs or segments of numbers entered into a square-shaped, numeric-only keyboard called a Display and Keyboard Unit... The two-digit codes stood for 'nouns' or 'verbs,' and were used to enter commands or data, such as spacecraft docking angles or time spans for operations." Reader Smark adds, "The Google Code Blog announced today that the Virtual AGC and AGS project has transcribed the Command Module and Lunar Excursion Module code used during the Apollo 11 moon landing. The code is viewable at the VirtualAGC Google Code Page."

Proper Old Skool

[Goth Biker Babe]

As some one old enough to enter raw hex in to a hex keypad on a machine with an LED display having hand assembled the code in the back of her math exercise book during a math lesson (when I should have been learning stats) this doesn't sound too different.

Apollo 15

[MichaelSmith]

...was the first flight to land in terrain where the descent trajectory had to be designed to avoid high altitude terrain. By that I mean they had to fly over a mountain, then into a valley for the landing.

The terrain model in the PNGS had five vectors in memory to represent terrain. Back in those days, RAM was expensive.

Calculating trajectories for Apollo program

[bAdministrator]

http://embedded.com/columns/technicalinsights/218401508?pgno=1 [embedded.com]

"Calculating trajectories for Apollo program"
"Jack Crenshaw describes what he and team members did to research trajectories for the Apollo missions."

Re:Proper Old Skool

[MichaelSmith]

It was amazing they did so well on Apollo. The only real guidance screw up was on Apollo 11. Every other landing was spot on. Apollo 12 had been targeted for the middle of surveyor crater and was dead on when Pete Conrad got his first look at the landing sight. He had to fly manually to avoid the target.

Re:1 MHz != 1000 Hz

[commodore64_love]

You're wrong. Only RAM or ROM is measured in base 2, due to the innate binary nature of computers (they measure in multiples of 256, 512, 1024, 2048, et cetera). Clock speed is independent of that and measured in base 10 such that 1 megahertz == 1000 hertz.

Anyway:

This Apollo computer has specs almost identical to ancient 1970s home technologies like the Atari VCS/2600 (1 megahertz, 2K ROM) or an Atari 400 computer or a Commodore VIC-20 (1 megahertz, ~8K RAM). That gives you a rough idea of how "weak" the computer inside Apollo truly was.

Interesting story on the virtualAGC page

[cluke]

Next time you think you have a tight deadline:

"Final exam (for the advanced student)
Prior to the descent of Apollo 14's LM to the lunar surface, a short in the LM control panel caused the abort switch to be triggered intermittently. If this actually happened during the landing, an abort would have automatically occurred (meaning that the lower stage of the LM would have been jettisoned and the upper stage would have blasted back into space). No landing would have been possible, and the astronauts would have faced the grave situation of needing rescue by the command module. It was therefore necessary, in the orbit or two before descent, for the some of the software designers to work out a fix for this problem that allowed a software lockout of the abort switch during the initial phase of the descent, but also allowed reenabling the abort switch later in the descent, in case the astronauts needed to use it. They did, in fact, work out such a fix. Your mission, should you choose to accept it, is this: Work out such a fix and send it to me. Remember, your fix can only involve erasable memory, since the core-rope containing the program cannot be altered. The fix needs to be keyed in at the DSKY by the astronauts. You have about 90 minutes to figure it out. Go!"

http://www.ibiblio.org/apollo/index.html#Final_exam_for_the_advanced_student_ [ibiblio.org]

NASA on software development for the space shuttle

[Gyske]

A few years ago I read an excellent article on how NASA develops software for the space shuttle. It focuses on the development process. The article is quite long, but well written, informative and entertaining. Read it here: http://www.fastcompany.com/magazine/06/writestuff.html?page=0%2C3 [fastcompany.com]

Re:Proper Old Skool

[Anonymous Coward]

The problem with Apollo 11's guidance wasn't the equpment, it was the moon. Look up MASCONs. Essentially, the moon's density varies from spot to spot and these differences in density changed the gravitational force affecting the LM during its descent. This, in turn, added errors that couldn't be accounted for, pre-flight.

What they did on subsequent flights was to use radar doppler data on the LM as it came around from the backside of the moon to determine the difference between the expected flight path and the actual flight path. Once they had this data, they updated the LM's guidance computer to correct for this effect.

One trickiness is that the state vector of the LM was a 6-tuple. Rather than update the state vector, they figured out that they could just update the range to the landing site by updating 1 number.

Google search for Emil Scheisser. He's the guy who figured this out.

Word != Byte

[jspenguin1]

The Block II AGC had 2,048 WORDS of memory, not 2,048 bytes. A word on the AGC is 15 bits + 1 bit parity. So, the AGC actually has 4 KiB of erasable memory, or 3.75 KiB not counting parity.

Also, keep in mind that this was just data memory, not program memory. A lot of early 8-bit micros loaded their programs into RAM from cassette or paper tape, so the total memory available for data is reduced.

The AGC had 36 KWords of read-only program memory which was woven into core-rope memory by the same "little old ladies" that sewed the suits together.

Supergeek Builds Homemade Functional AGC

[Anonymous Coward]

This guy wins the ubergeek crown of all time. He actually built a fully functional version of an AGC [klabs.org] out of discrete IC chips. Granted, it is not a true AGC clone, since the exact chips could not be procured in 2000-2004, but he did build a functional workalike of the AGC out of individual TTL chips, and wrote two software emulators, and got his modernized hardware reproduction AGC to run actual original AGC machine code software.

Re:Fake

[icebike]

Not powerful in any meaningful sense. Just incredibly robust and failure tolerant.

Some might remember the 1202 alarm when the LEM commander had to take over manual control and land the LEM because, according to the mainstream press, the computer crashed.

Well, it turns out it was not quite that simple. Human error led to the computer reaching a PLANNED restart point. This restart was essentially instant, dumping tasks it could not handle due to missing data, and picking up where it left off.

Aldrin, due to the closeness of the landing decided to take over manually as he had trained to do hundreds of times in the simulator.

But the computer did not fail, it restarted, as programmed, and was back on line long before he even got his hand off the switch.

  http://history.nasa.gov/alsj/a11/a11.1201-pa.html [nasa.gov]