Restoring Apollo Guidance Computer, part III

RESTORATION OF APOLLO GUIDANCE COMPUTER

Developing tool to substitute for both fixed and erasable memories

Having a computer with no RAM or ROM is a recipe for boredom. Since we have to wait until we can x-ray the erasable module before we start opening up the potting near the break and repairing the wiring, we needed an alternative way to exercise the computer.

Mike had a work in progress to use connector A52, the ground maintenance connector, to do this job but it requires a connector that we don't have. The AGC uses mini-WASP connectors which are unobtainable, thus we would need custom manufacturing of a replacement.

Using the NASA sourcing control documents (SCD) from the NARA archive, we can exactly specify the shape and dimensions of this very non-standard connector. We are hopeful that we can get the main spacecraft/DSKY connector A51 and the maintenance connector A52 produced because a high technology connector company is offering to do this to sponsor our work. It will take some time to receive such a connector.

In the meantime, Mike adapted his FPGA based design to connect via backplane pins. This would watch for addresses and the strobe signal that normally triggers a core read (two strobes, one each for fixed and erasable memory). It would store the entire 36K contents of core rope and host the entire 2K of RAM on the board, feeding the appropriate word to the AGC at the correct time.

The first cut of this would only implement fixed (core rope) memory and serve as a proof of concept before wiring in the lines to update RAM as needed to emulate erasable memory. We wired it up and connected it to the AGC for our first test.

Nothing happened. The board didn't appear to see any addresses or control signals. The interface chips that we were using, chips that work fine converting between 3.3 and 5 volt systems, weren't working for the AGC.

Logic level challenges hooking up the memory substitute tool

The RTL logic used in the AGC, while defined as ranging between 0 and 4V for logic 0 and logic 1, produce much lower voltages for a logic high. We see valid 1 bits with voltages as low as 0.8 volts at the inputs, which is just too low for the MOSFET based level shifter we were using.

Since the actual voltages were lower, not anywhere near 4V, we then tried wiring the AGC directly to the 3.3V level FPGA pins but that didn't work either. LVCMOS logic levels define the lowest valid high as a bit higher than 2 volts, so nothing would register.

Thus, we have to build discrete level shifter circuits to make sure that a 0.8V or higher input will give a crisp high output into the FPGA.

Building lots of interface circuits between memory tool and AGC

There are 26 input lines, each requiring one transistor and three resistors for its interface. After wiring up the interface circuits and connecting them between AGC and FPGA, we did successfully see all the signals from the computer. Using pull up resistors and open drain output mode on the FPGA, we can drive in the data signals to the AGC just fine.

FPGA tool with level shifter circuits, attached to AGC

Testing the DSKY substitute tool using a pattern generator

Marc set up his pattern generator to drive my DSKY substitute while we worked on a few wiring and power issues. We improved its operation quite a bit, although more work is needed to avoid glitches on input from the AGC and to fix suspected damage to some of my control boards.

Testing out DSKY with pattern generator

I think the trauma of moving it on the plane and resulting shorts and dislodged wires caused a few chips to fry. It will come home and be improved, tested and then a final version of the hardware will be built.

There are some places where I need to shift to direct access of the AVR chip registers, bypassing the Arduino functions such as digitalRead(), in order to see all 15 bits from the AGC at one time.

Testing the memory substitute tool

Marc had to leave with his large logic analyzer before we got the memory substitute tool working, leaving us with oscilloscope traces as a diagnostic snapshot into the processor. Still, that gave us enough to see what words we were proving to the AGC. Coupling that with the listings of the Apollo software that are running let us verify both the tool and the AGC operation.

There are a few bugs in the tool right now, so that after a short burst of correctly delivered words, the tool messed up then went into a hung state. Nothing systemic or difficult. Given a bit of time to clean things up and test, this tool should be reliably feeding core rope contents to the computer.

Now, to the more important question. Did the computer work properly? Admittedly we have a small sample, only a few dozen instructions running in any test shot, but it would seem that the AGC is flawlessly executing everything it receives. This includes complex behaviors like inhibiting interrupts, extend mode processing, and use of the ALU within instruction execution.

Without the erasable memory support wired up, eventually the code would go awry even if the tool keep feeding fixed memory data perfectly.  Once the tool is whipped into shape and the erasable memory support is turned on, we should be able to run the Apollo software at least to the point where it requires some input from the spacecraft or the DSKY.

Checking out first few instructions executed by AGC

TO BE CONTINUED