Restoring an Apollo Guidance Computer, part V

RESTORATION OF APOLLO GUIDANCE COMPUTER

Background of this AGC

The owner of the AGC, Jimmie Loocke, was browsing through a scrap metal recycler's warehouse in search of some parts for a project when he spotted a large pile of surplus NASA items that he recognized. Among them the AGC! On the spot, he bought two tons of the material for scrap metal prices and hauled it home.

In an odd twist of fate, Jimmie had worked for a contractor that was performing thermal tests of the Apollo spacecraft at the Manned Spaceflight Center in Houston. His job was to control the thermal profile of the test chamber as they checked out the response of a Lunar Module to the expected thermal conditions in space and on the surface of the moon.

NASA bought some test versions of the LM in addition to the machines that were used on flights. This AGC was installed in LTA8, test article 8. LTA8 is on display in the Johnson Space Center (formerly MSC), but the AGC from inside it was sold off by General Services Administration.

This is a block II AGC, the type used on all the manned flights. It was number 14 of the 15 prototypes built by Raytheon, which is why it has only two modules that are potted. We are very fortunate to have a machine that is identical in wiring and logic to the production machines but have access to the circuitry in all the unpotted modules.

The AGC is hermetically sealed and sat with an internal nitrogen atmosphere for decades before its recent opening by the owner and by Eldon Hall, the lead designer of the computer, Mike Stewart and now the restoration team who are volunteering their efforts to get this historic artifact in full glorious operation once again.

Addition of erasable memory to the tool and further traces

Mike added in the Verilog to provide erasable memory for the AGC, wired up the additional lines to the AGC backplane, and now the computer is running long sequences of instructions with almost every one acting as expected.

The use of breadboards, jumpers with pins and the large mess of wires running between AGC and tool is likely the cause of the sporadic misbehavior. At least we would consider the wiring to be the most likely cause of the occasional misbehavior and not yet suspect a defect in the AGC.

It was great to watch hundreds of instructions execute with the correct results as the AGC ran the Aurora restart code from o04000 until glitches in data returned from the tool caused the stream to diverge.

Design of final DSKY after testing of the prototype

The prototype unit testing last week uncovered some weaknesses in the design that need correction. The AGC and DSKY design refer to the least significant digit of each display as digit 1, but the prototype numbered the digits left to right starting with one. The method of flashing the Verb and Noun displays stressed the MAX7219 chips which drove the seven segment modules.

We have a milled aluminum case that is very close if not exactly the dimensions of a real DSKY, into which I will build the DSKY substitute. It won't be an actual replica of the gate by gate and relay by relay design, but is intended to appear similar and behave the same as far as the user and AGC are concerned.

It would be very hard to achieve a full gate by gate replica, in part because the electroluminescent panel on the right side of the DSKY is unobtainable. That obviates the need for 250V 800 Hz power which is what the relays switched to the various EL panel segments, making the internal construction different from the real DSKY.

In the prototype, I used three MAX7219 chips each on a separate module that I bought online. I did this for speed, since I had just a bit over one week to cobble this together and wanted to skip any assembly and design steps I could to speed things up. In a real design, those three chips would be strung together on one serial chain, but the prototype used three independent chains.

Since a MAX7219 supports eight 7-segment displays, I apportioned the DSKY digits among the three by using the first five digit positions for a register, two more digits for one of the Verb, Noun or Program displays, and ignored one position. For example, Register 1 and Verb were on one of the boards.

My first cut at blinking the Verb and Noun digits, while maintaining a very tight loop in the Arduino, was to use relays to interrupt the common cathode wires to those four 7-segment modules. A 555 timer set at 1.5Hz was gated through an IC to fire the relays on an off the shelf eight relay module.

This approach didn't seem to sit well with the two boards hosting these displays, which began to exhibit odd behavior that suggests I fried the MAX7291 chips. It worked initially but after about 20 minutes of operation, everything went downhill.

I might make use of a newer driver chip, the MAX6955, which can blink individual 7-segment modules without the Arduino doing more than initiating the state and rescinding it. I will also chain these together to make use of a single serial link.

I found that the design could be reading a command word from the AGC surrounding its change, because of the quick and dirty use of the digitalRead() method which is slow and non-atomic. By directly accessing AVR registers in the Arduino I can see all 15 bits at one time. Lastly, when I see a non-zero value coming in from the AGC, I will delay 5ms before sampling again to eliminate the risk of reading a glitched word.

Fitting in the aluminum case will require sourcing and placing 7-segment and 14-segment displays more precisely and fitting everything tightly on a PCB. I found green colored display modules that are close enough to the actual DSKY size that they will appear almost full sized and fit across in the allotted space.

The prototype used a cheap membrane switch array but I need to support the large square button format of the DSKY in the final version. I may need to construct the buttons and related mechanism myself, embedded a microswitch inside to actually read the contacts. More research is needed on this.

Discovery about potting materials used on the erasable memory module

After some archive detective work by Mike and Ken, we are of the opinion that the potting material that we need to open to repair the wire break is not RTV-11, but Stycast 1090, an epoxy resin. Different solvents or methods will be needed to make a small hole for our repair work.