Good progress completing the DSKY substitute to use while restoring Apollo Guidance Computer

PREPARING FOR RESTORATION OF APOLLO GUIDANCE COMPUTER

Building and testing the DSKY substitute

I had two driver boards for the sign digits, because I naively assumed that was how many I needed. The boards each came with a pair of dual-digit modules. I can't break apart a dual-digit module, thus each dual-digit module has to sit in front of one of the three registers. Based on that, I assumed I needed two boards to drive three dual-digit modules.

After studying the internal layout of the 14 segment display dual-digit module and thinking about what I was using them for, solely to show a plus or minus sign, I realized I could cut the wiring way down. I needed only five wires per dual-digit module, to light the four segments that form the + and -, as well as the one common cathode for the right hand digit in the module.

Dual-digit module and connections to driver board

I cut away the excess wires in my working sign for R3, then began wiring the next two sign modules to the other driver board. Once done, I found that nothing worked. The board was now dead, although it had tested okay back when I removed the dual-digit modules and installed header strips. None of the four digits controlled by the board would light.

It was then that I had my epiphany. The dual-digit module has shared wires for all the segments, plus two common cathodes to light the left and right digits respectively. I could use a single driver board to light all three sign displays. The board handles two different dual-digit displays. The four segment lines from the right hand side of the board went to the dual-digit module for R1 and were jumpered over to the dual-digit module for R2.

Connections to three dual-digit displays to show + and - signs

The right and left common cathode lines went to R1 and R2 dual-digit displays, each hooked to the righthand digit of the dual digit display. Thus, this one board could drive three right hand digits in the three dual-digit displays (and could have driven a fourth if I had needed it). It took five wires to the R3 dual-digit module and six wires to handle the two dual-digit modules for R1 and R2, since they shared the four segment lines between them.

I wired up the first 8 relay module to the Arduino. This will handle the five keycode lines, the key release line, the PRO button line and the KeyRel button line. I hooked up one of the keyboards to test out my decoding of the button presses. All seemed well, as I could see the activation lights for the relays whose bits were set on in the keycode and those light patterns matched the codes that should be emitted for the keys pressed.

I did have a problem because this relay module is activated by a logic LOW from the Arduino. The problem is that I had used pin 13, which is connected on the Arduino board to an LED.

Thus, when the PRO line is in its inactive (HIGH) state, the LED is illuminated, it drops the voltage, and my output to the relay board is indeterminate. I can see the relay board driver LED dimly lit, but it should be off entirely.

Even worse, I had already assigned pin 13 to the flash control for the OprErr indicator. The pin may work fine as a control for flashing OprErr, although the paralleled LEDs (on board and one the caution/warning panel) may cause problems. In reality I am short two pins, for OE flash and for the PRO button.

I was using pins to control the flash circuitry in addition to the wires that lit the LEDs, but I realize this is superfluous. The same wire from the expander module that lights the OprErr LED can be routed to the flasher control NAND gate to enable the flashing, saving a pin. The same pertains to the KeyRel flasher, saving a second pin.

Now, I can reuse one of those pins (pin 12) for the PRO button and have no need to use pin 13 with its inboard LED. All is good in the world again!

I built the breadboard to handle all the flashing control. It has a quad NAND gate and the flasher module attached. The three gates are hooked to expander board 0x20,  pin P0 (OprErr), pin P1 (Verb/Noun flash) and pin P3 (KeyRel).

Wires for triggering OprErr and KeyRel also run to the LEDs on the main breadboard panel. These gate the 1.5Hz to two relays which interrupt the high power to the OprErr and KeyRel LEDs.

Four relays will interrupt the common cathode line between a 7-segment display unit and the driver board when activated. The flasher circuit will activate and release the relay on a 1.5Hz square wave as long as the Verb-Noun-flash line is active. When the Verb-Noun-flash line is inactive, the relay stays open and the common cathodes are controlled by the driver board (lit up).

Caution (left column) and Warning (right column) LEDs

What Caution/Warning panel should look like

My second breadboard panel, a large metal plate with a number of breadboards attached, will hold the sign driver board and the two keypads. Lower down, I will affix the Arduino itself. Other connections, including to the AGC voltage conversion circuit boards, will be made here.

I installed pin headers and wired up two breadboard PCBs to hook to the 7 segment driver boards for registers R1, R2, Verb and Noun. Some testing confirmed that these worked properly. They will be tucked away to the right of the main board or underneath, the three PCBs plugged into a small breadboard. This small breadboard is there to wire up +5, ground and the three sets of three wires (clock, data and load).

I had a moment of panic when one of the 7 segment driver boards, when mounted on the breadboard PCB, had no connectivity to one pin. Try as I might, I couldn't get solder to flow well enough to establish a connection. Fortunately, I remembered that there are two sides to this board, intended for a quad digit display on each side. The signal for the bad pin (3) was present on the other sides pin 3.

I hooked up both keyboards, all three registers and Verb, Noun and Program. The three sign displays were turned on as well. I ran a test to see how everything worked. Everything was good, so I began to solder things together to make the connections more solid.

Tomorrow I have to solder together 25 circuits to accept an input signal from the AGC and present the result as a 5V TTL logic level to the Arduino. MIT developed this circuit for interfacing to the AGC and it was used by the various contractors such as North American Rockwell and Grumman Aerospace Engineering Corporation who had to tie their systems into the AGC.

It is called a type D circuit in the documentation. AGC signals are 28V for high and 0V for low, with certain expectations for impedance, load and thresholds of the equipment connecting to it.

The D circuit consists of a PNP transistor with its emitter hooked to 28V from the AGC. The input signal runs to the base through a 10K resistor. A parallel combination of a 10K resistor and 0.1uf 50V electrolytic capacitor are connected between the emitter and base. The collector output runs to ground through a voltage divider of a 220K and 47K resistor in series. The center tap is the 5V output to the Arduino or other board.

For signals I will send into the AGC, I am driving a relay board with the Arduino or other board and switching 28V through a series chain of two 510 ohm resistors to the AGC. This provides the 28V input expected by the AGC with exactly the same resistance and structure as the keyswitches in the DSKY.

I began to write a test program for the Arduino Uno that will drive the input lines to my DSKY, in place of the AGC, to test out the behavior. This will have a terse command language to let me set any digit of the displays, the signs, the Computer Activity lamp, the flashing of the Verb and Noun displays, and any of the Caution/Warning lights.

Major progress wiring and testing the DSKY substitute to use with the Apollo Guidance Computer restoration

PREPARING FOR RESTORATION OF APOLLO GUIDANCE COMPUTER

Building and testing DSKY substitute

I got back to work on the Register 3 chain (five digits for R3, two digits for Program, and the R3 sign digit). I had some problems including failure of the top segment on all the displays which undoubtedly were due to wiring errors.

It turned out that the problems were solder faults on the new headers. The conductive barrels that run through the driver board PCB had been pulled out during extraction of the old small display modules. The fix was to solder the pins on to both the top and bottom of the PCB. With that restored, the display worked perfectly.

I had some code changes to make to align the digits properly with the displays, as I had assumed the eight digits were addressed from left to right, 0 to 7, but the order ran from least significant digit on the right, as 0, leftward to the high digit as 7. My register thus use 7, 6, 5, 4, and 3 from left to right and my special two digit associated displays, in this case Program, used 1 and 0 from left to right.

Next up was wiring for Register 2 and its Noun display. I learned to drop the decimal point from the wiring as it is not used in the DSKY. I continued on and wired up Register 1 and the Verb display. All that was missing were the two sign displays.

I decided to relocate the driver boards for the 7 segment displays (total of three boards) and make use of a solder version of a breadboard to ensure good connection of the display boards to the wiring. These three small boards will sit beneath the main breadboard. I have all the wires for the seven active segments and the seven display selection lines routed out to the right so they can reach the new driver boards I am soldering up.

After soldering the first 7 segment driver board to a breadboard PCB and soldering all the wires from the displays, I discovered that one of the pins that selects a display is open. I can't repair it where the driver board sits, so I had to make an ugly hack to my wiring and code to substitute the unused display position on the driver for the dead one.

I moved the wire, hacked the code, and had the everything working well. I shall have to proceed cautiously for the next two driver boards, ensuring that I have full connectivity before I solder on the wires from registers 1, 2, Verb and Noun.

Test of Reg 3 and Prog displays after repair on YouTube

I installed a vertical breadboard strip to the left of my existing displays, which will hold the ten caution and warning LEDs. I bought another large breadboard panel onto which I will install the timers and relay modules. The driver boards for the three signs (14 segment displays placed in front of registers 1, 2 and 3) will sit on the existing main breadboard.

Some quick prototyping proved the flashing design. When the KeyRel caution light is on, it must flash at 1.5Hz. When the OprErr caution light is on, it must flash at 1.5Hz. In addition, the AGC can request that the Verb and Noun displays flash at 1.5Hz (these are each 2 digit numbers).

I set up a timer module producing 1.5Hz square waves and routed that to three NAND gates which are controlled by the KeyRel, OprErr and flash-verb-noun signals from the AGC. When the signal from the AGC goes high, it allows the 1.5Hz flashing signal to pass through the gate, setting that gate low 1.5 times per second.

The RelKey and OprErr outputs are connected to one relay apiece, those relays interrupting the cathode connection to the connected LED. The flash-verb-noun output drives four relays, each of them interrupts the select signal (common cathode) for one of the four 7-segment displays that comprise the Verb and Noun output. These relays will activate 1.5 times per second when the flasher square wave is passing through the control NAND gate.

I still have to choose a couple of structural or cosmetic approaches to finish this off. First, I need a mounting mechanism for the twin 4x4 membrane keyboards that serve as the DSKY keyboard. These will sit below the display panel (main breadboard panel). Second, I want to create an overlay panel with the legends for the Caution and Warning lights plus the Comp Activity light. I imagine a clear plastic sheet upon which I will print the legends.

My last action of the night was to install the ten LEDs, in two vertical columns of five signals each, that represent the Caution/Warning panel of the DSKY. The left column has white LEDs, for Caution signals, while the right column has yellow LEDs for Warning alarms.

Continuing to construct and test the substitute DSKY for the Apollo Guidance Computer restoration

PREPARING FOR RESTORATION OF APOLLO GUIDANCE COMPUTER

DSKY simulator construction and testing

I tested out my three I/O pin expander boards, used to read 8 input signals from the AGC and to drive 11 LEDs on the display. There are two variants of the chip used on the expander module, TI and NXP, with different addressing. I found the correct addresses and checked out the operation of the circuits.

Next up is some challenging construction - removing the 14 segment alphanumeric display units from the driver board so that I can remotely mount these as signs in front of the three register rows. I built one of the drivers with header pins rather than mounting the two dual-display modules on it, but the other driver had its segments already soldered on.

I used my desoldering gun carefully and hoped to get at least one dual-display module workable with the board using headers and wiring.  I eventually had the dual display modules off but the board holes were just too snug to put in the headers as I did on the other board. For this board, I had to solder on 18 discrete wires which will be routed to the third sign digit. I was successful and tested all three sections proving I had working signs on the three registers.

I had wanted to use large 7 segment displays for the DSKY simulator, but when I bought the combined MAX7219 driver board and displays, the board used quad display modules not individual modules. I think I can figure out how to adjust the wiring to make these work with individual display modules,as I don't want to be stuck with the small displays.

I moved on to the 7 segment driver boards, removing the quad display modules and installing header strips. I was able to successfully test all of these using individual 7 segment display modules.

At this point, I stuck the driver boards for  both 7 segment and 14 segment displays onto my breadboard, then began to install point to point wiring from headers to the individual display segments.

This was a very long involved process, very tedious. Every 7 segment display had to have its 8 segment anodes daisy chained to the others in its group, then the cathode lines were routed to each display. Since the Verb, Noun and Program display digits are electronically hosted on the 7th and 8th digits of the Register 1, Register 2 and Register 3 driver boards, but are not adjacent physically, this meant more ugly wires routed between sections of the breadboard.

I decided to solder wires to the headers rather than use separate connectors, which cleaned up the mess of wires on the breadboard but made it harder to maintain. Too, I figured out some optimizations that allowed me to skip some pins on the headers because they are not active. For example, the sixth display of each register driver board is not implemented - registers have five digits and the associated verb/noun/program display is two digits.

Further, I realized that the headers on the driver board have 24 pins but only 16 are needed. The other eight are duplicates of the segment anode lines. I then turned to the sign driver boards to make a similar optimization but realized I only save two wires over the naive connections so it wasn't a high value effort.

I had Register 3 and its associated Program display wired up by the end of the day, but have some wiring errors to discover and correct. Tomorrow, when I get this working, I can move on to wiring the other two registers and their related displays.

I have not yet begun to build the LED panel (the location of the caution and warning lights on the DSKY. These include Gimbal Lock, Temp, Operator Error, Key Release, and Program alarms. These are driven by two 8 channel expander modules on the I2C serial chain; the boards are tested and work. Still, they need an LED and a resistor for each of the lights they will drive.

One signal on the expander is actually a control signal to cause the Verb and Noun digits to flash, something I will cause by interrupting the common cathodes of those four 7 segment displays with a relay. The relay in turn will be activated by the timer board that is triggered by this control signal.

Two other timer boards are triggered by the OprErr light and the KeyRel lights, thus these will piggy-back off the wiring to those LEDs.  The timer boards and extra relay module have not yet arrived so this is deferred for a few days.

Building DSKY substitute

PREPARING FOR RESTORATION OF APOLLO GUIDANCE COMPUTER

Building and testing the DSKY substitute

During a trip to Florida with my family, I snuck in enough time to write the code for the substitute DSKY. It will run in an Arduino Mega 2560, not only using every I/O pin on the controller but making use of eight boards connected via serial protocols to control displays and multiplex many signals over a small number of wires.

The 7 segment displays that will show the five digits of registers 1, 2 and 3, plus the two digits of the Verb, Noun and Program, make use of SPI protocol, while all the others hang off a single I2C serial chain. Two boards control the three 14 segment displays that provide the + and - signs on R1, R2 and R3.

Other boards drive the 11 LED indicators, representing the Computer Activity light plus the caution and warning lights. A final board will watch eight discrete signals from the AGC that provide some caution status but also control flashing of the Verb and Noun displays, the Operator Error light and the Key Release light.

Two 4x4 membrane keyboards will provide the 19 keys in approximately the shape and placement of the real DSKY keyboard. 555 timer circuits provide the 1.5Hz flashing rate and some relays provide the interruption to cathodes of the displays which must flash.

I had discovered that the signals coming to the DSKY from the AGC use 28V and 0V as the logic levels; my outputs must also conform to the 28V levels. This means I need some interface circuitry to deal with the voltage difference between Arduino and Apollo DC bus levels.

We chose to implement the exact circuits used in the DSKY as well as through the CM and LM spacecraft, to minimize the risk of damage to the precious AGC. My outputs to the AGC can be accomplished with a relay and resistors, the relay in place of the keyboard switches used in the real DSKY, but the inputs are more complex, involving transistors and other components.

I expect to design and fab out a board using surface mount parts to support the 23 signals coming from the AGC - hopefully I can get this done quickly.

I began testing today, working on the logic and the interfaces to the boards for the displays and keyboards. More tomorrow. 

Working on DSKY substitute to use with Apollo Guidance Computer; investigating the input-output methods of the AGC

RESEARCHING FOR RESTORATION OF APOLLO GUIDANCE COMPUTER

Update to plan for DSKY substitute to use with AGC

I picked up some level shifters that will adjust between the AGC voltage levels of 0 to 4V and either LVCMOS or TTL levels on whatever controller board I use for the project. It allows me to make the choice of controller without regard to voltages.

I had intended to breadboard some key parts before I left for a trip to Florida, but Amazon handed one of my multi-part orders to the USPS who have misplaced it already. So much for Amazon Prime shipping guarantees when they hand the box over to the Keystone Kops for delivery.

Input-output for the AGC

The input-output system for the AGC consists of a set of channels, 15 bit words, that are tied to the external world. The inertial navigation system, thrusters, telemetry, hand controllers, DSKY and other parts of the spacecraft will funnel through the channels.

The way that programs interact with the I/O channels is with IN/OUT instructions that explicitly read or write to the channel address, by interrupts that force a read of a word to place the data in a memory location, or by cycle stealing where counter instructions are forced invisibly into the execution stream to change counters whenever a pulse arrives from outside.

Most input channels simply record the state of a signal in an assigned bit in its channel word, expecting programs to come along and read the channel when they want to look at that information. Two input channels, 15 and 16, will cause an interrupt and begin executing some code when signal data arrives in the channel. The main purpose of this is to accept keystrokes from the astronaut on the DSKY.

Other channels are recording data that must be counted, for example accelerometer (PIPA) changes. The PIPA causes cycles to be stolen to execute an invisible counter instruction which updates the value in a channel. This does not cause an interrupt, so it is up to some program to eventually read the value of the channel to see the acceleration value at that instant.

These counters in channels can be tied to output systems where the external circuitry will apply a pulse to some machinery and then cycle steal to decrement the counter. The program can write a non-zero value to these output channels and go away, knowing that the external machinery will apply that number of actions to its intended target.

For example, the program may decide to torque the gyroscope gimbals a certain number of degrees, moving the stable reference platform to a new desired orientation. The movement is loaded into a counter and the hardware outside the AGC takes it from there, acting until it has decremented the counter to zero.

One channel, 7 has a special purpose. It has a bit assigned to it, the super-bank bit, that augments the value in the Fixed Bank register allowing access to rope memory blocks above the 32K line.

Part of tray A of the AGC consists of interface modules which have circuitry to accept pulses, voltages or other external values, converting them from the outside system and safely delivering the result to the assigned channel word and bit. For output, of course, it converts a 0 to 4V digital signal to an appropriate signal and voltage level to drive the external mechanisms.

Reviewing physical construction of Apollo Guidance Computer

RESEARCHING FOR RESTORATION OF APOLLO GUIDANCE COMPUTER

Physical structure

The AGC body is milled magnesium. It consists of two halves, called tray A and tray B. The logic, memory, interface and power supply modules plug into the trays on the insides, the parts that face each other when the AGC is assembled. The outsides, the outer faces, have wire wrap connections and an outer flat plate with gaskets.

With the plates in place on the two outer faces, the AGC is hermetically sealed and it is left pressurized with nitrogen to keep outside air from entering. Apparently the spacecraft environment has too much humidity, corrosive vapors and other contaminants for reliable operation, thus the AGC is sealed.

One side of tray B has chambers that allow the core rope memory modules to be slid in and removed without taking the rest of the AGC out of the spacecraft or opening it up. Software updates are delivered via new core rope modules (read only memory).

Changes can be frequent, especially when a problem is detected on one Apollo flight and changes are made to accommodate that. Since the pipeline processing Apollo missions was well overlapped, several spacecraft were in process at one time. They might be getting checkout in the Manned Spacecraft Operations Building (MSOB), they might be stacked partially or fully in the Vehicle Assembly Building (VAB), or they might be erect at the launch pad atop the LUT on the pad.

In all those cases, changes may need to be made and swapping without disassembly is a real timesaver. The block I version of the AGC, used only in the unmanned missions, had the ropes installed inside the trays, but an important block II change was to make rope module swaps faster and less disruptive.

Two connectors on the AGC allow connections outside the computer. The primary flight connection, A51, is a 360 pin connector that links the AGC to the rest of the spacecraft. Another connector, the 144 pin test connector is normally sealed with a special cover that loops certain signals between pins, but that cover is removed to hook the AGC up to ground support equipment for checkout. 

Looking at types of code execution in the AGC and designing a DSKY substitute to support testing

RESEARCH IN ADVANCE OF RESTORING AN APOLLO GUIDANCE COMPUTER

Types of code execution in the AGC

The AGC software has several ways to execute code. Some are involuntary and hidden from the programmer. Others vary depending on whether they are real time tasks or batch like programs.

Cycle stealing is used to update counters in the AGC. That is, a pulse arrives to update a counter and this forces a hidden instruction to run at the end of the current instruction and before the start of the next normal program insruction. The hidden instruction increments or decrements the counter.

These counters come from devices like the accelerometers on either spacecraft or the rendezvous tracking radar on the LM. If the rate of pulses are high it can take a significant percentage of the compute cycles. During launch, the accelerations are high and the pulse rate high too. During the Apollo 11 moon landing, flaws in the design of the rendezvous radar caused it to hunt for signal and send a high rate of antenna repositioning pulses to the computer, famously overloading the running programs to trigger the 1201 and 1202 alarms.

Interrupts such as a keypress from an astronaut or the arrival of a complete 16 bit word from the telemetry uplink will force in an interrupt branch and state change at the completion of the current instruction.

Batch jobs are run to accomplish many goals. The astronaut may ask to display the current position of the spacecraft on the DSKY display, for example. More significantly, programs correspond to major mission phases such as descent to the moon or reentry to earth. The astronaut (or mission control via telemetry) can start a program which displays its number on the DSKY and runs in the background.

A number of programs run like this, each having a relative priority to every other running program. The highest priority code runs until it gives up control, exhausts its alloted time or must wait for something, then the next highest code is dispatched. These all contend for CPU resource whenever the AGC is not running involuntary code or processing a real time task.

Real time tasks are tied to one of many timers in the AGC. When the timer 'pops', the task is run head of all the batch programs. Real time tasks are of very limited duration, but might set a variable to allow a batch program to take more extensive action once the real time task finished. Often real time tasks set up future executions by setting a new timer interval.

Thus, in the hierarchy of execution, the AGC handles involuntary code, cycle steals then interrupts, real time tasks, then batch programs with prioritized scheduling.

DESIGNING A FUNCTIONAL DSKY TO HOOK TO THE AGC

Once the AGC begins to work, it will be very advantageous to have a DSKY to display the current program and status. It allows us to request various code to execute by pressing the buttons. We could painstakingly probe the state of all the pins that drive the DSKY to recreate what would be on the panel, and we could drive 0 or +4 on the inputs to simulate keystrokes, but seeing and pushing will be much easier.

I don't have access to a DSKY to connect to the AGC and the last one sold at auction went for over $90,000 meaning it is not likely we will buy one just to interact with the machine. The electroluminescent panel that displayed the output of the computer had a short lifetime.

It's specification was for 2,000 hours of operation and it would have dimmed substantially in less than half of that time. The shelf life was only guaranteed for one year, not fifty. Therefore, a real DSKY might not be usable even if we had it.

NASA required the software coders to find ways of minimizing the number of times they lit up any segment of the display and demanded that ground test crews dim the display for all testing, just to leave the brightness high enough to last through an actual mission.

I decided to put together a quick and dirty DSKY interface. It would set up 21 seven segment displays, use three alphanumeric segment displays to show the + or - signs, and use two 4x4 pushbutton matrices side by side to lay out the 19 active buttons of the DSKY.  An array of ten LEDs will represent the station and caution panel lights.

More than 100 relays would be driving the digit displays, plus others to light the 10 lights on the status panel in a real DSKY. Most of the AGC outputs are inverted, meaning that a logic low (0V) signals activation of a particular light or digit value.

The DSKY delivers 4 bits to select 1 of 12 rows of relays and 11 bits to select the 11 columns of the relay matrix. This controls all the electroluminescent and status/caution output lights. Each digit is encoded with five bits, which I will have to translate into the proper seven segments for my LED digits. Thus, the AGC is providing 15 bits for output and accepting 5 bits for keycode input plus two special signals for PRO and RESET keypresses. The rest of the wires on the DSKY connector are power and ground, basically.

The design needed some clever fan out and fan in mechanisms to make it all work. I need 22 input/output lines to the AGC. Then I need to drive 21 seven segment displays (147 wires) and the plus/minus on the three alpha displays (8 wires) and I need to watch the two 4x4 keyboards (16 wires). The status/caution lights take 10 more lines. This means 181 I/O signals to control the physical side of my DSKY, way beyond the pins available on FPGA, Arduino, BeagleBone, RaspPi or similar controller boards.

I expect to make use of multiplexors and other support chips which connect via I2C bus to minimize pin requirements on the board I use for control. I bought some chips that drive a number of LEDs or seven segment displays and can be chained on an I2C link thus I can drive quite a few digits with just a few wires. In reality, then, I probably can fit within an Arduino Mega and other choices thus the main consideration is voltage compatibility with the AGC

The AGC runs on +4 and 0 volts. LVCMOS devices such as an FPGA or Arduino Due are designed for 3.3V. The TTL compatible devices such as an Arduino Mega will handle the 4V from the AGC just fine but produce 5V outputs that overdrive the AGC inputs. What I need are 5V tolerant inputs on the controller I choose and open collector outputs. Choice of controller type is still open. .

For convenience I will build it with breadboard or breadboard pattern PCBs, since the cosmetics are irrelevant for this project. All that matters is that it will work and we can interact with the AGC through it.