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. 

Looking at power in the AGC and at the DSKY interface

RESEARCH TOWARDS RESTORING AN APOLLO GUIDANCE COMPUTER

Power within the AGC

The AGC is powered by the main 28V DC bus of the spacecraft. It provides filtering for the 28V and distributes it out to signal conditioning and other interface boxes connecting the AGC to the inertial management unit, telemetry and other systems. Within the AGC, power supplies produce 14V DC and 4V DC. The 14V is needed for the memories, while the logic runs on 4V.

Two different 4V supplies are produced in the AGC. The one connected to most logic modules is called 4SW, because it is switched off when the AGC is put into standby (a very low power mode). The other 4V goes to the few parts of the AGC which must run all the time. For instance, the clock oscillator, divider, and scaler produce timing signals used by the IMU, telemetry and other systems, so it must produce those even when the AGC is in standby. 

DSKY, the visible interface

The DSKY is the portion that was visible to astronauts and the public. It provides a set of glowing numbers, some pushbuttons and caution/warning lights. One DSKY is mounted on the main panel of the Command Module, between the CM pilot and mission commander seats. The other is down in the lower equipment bay of the CM, near the AGC tself and to the optics used to take celestial navigation readings to keep the intertial navigation aligned properly. On the LM, a single DSKY is mounted on the central control panel.

There are three main portions of the DSKY. The bottom 1/3rd has a matrix of pushbuttons, a main block 5 across by 3 down, with two vertical buttons on each side of the main block. The upper left has a set of 12 caution or warning lights, rectangular panels with text on them that would light up in white or yellow. The upper right has an electroluminescent panel that displays three signed five digit numbers on the bottom half, a two digit verb and two digit noun  side by side above that, and a two digit 'program number' displayed on the top.

The electroluminescent section used 250V 800 Hz AC to excite the segments to glow green, at 5300 angstroms. The high voltage was switched through many small relays inside the display, allowing the AGC to use a low DC voltage to switch the high voltage AC to the display elements. It took 37 relays just to power one of the signed five digit numbers.

The caution and warning lights were ordinary 5V DC incandescent bulbs, driven through relays that in turn were powered by the AGC. Status lights had a white background while caution/warning lights glowed in yellow.

The main keyboard section had the 15 main buttons, providing +, -, the ten digits, Proceed, Clear and Key Release. The two vertical buttons on the left are Verb and Noun. The two vertical buttons on the right are Enter and Reset. The 19 buttons are encoded in a 5 digit keystroke value and monitored by the AGC.

The keyboards were back-lit by 110V AC 400 Hz lights, making use of the standard AC bus of the spacecraft. 

Looking at the AGC Block II core rope memory structure

RESEARCH IN ADVANCE OF RESTORING APOLLO GUIDANCE COMPUTER

Rope memory

The read only memory (called fixed memory in the AGC) was constructed of core rope. This is a technology that is actually different from the read/write core memory that most know. For one, it does NOT use small ferrite cores nor does it depend on cores retaining the state of the stored bit.

The cores used in rope memory are larger steel bobbins wound with a thin magnetic tape. These are large enough to allow many wires to be threaded through the center of the bobbin. Data is stored by the simple process of threading a wire, for a 1 bit, or bypassing the core to reflect a 0 value.

The process of reading the core rope contents is similar to regular core memory, but not the same. To read a particular bit, select lines are chosen to magnetize the bobbin. First, the bobbin is set by a current in one direction, then the current is reversed causing the magnetic flux in the bobbin to flip.

Any and all sense wires threaded through the bobbin will have a pulse generated as the bobbin flux flips. The sense amp reads this as a 1 value. If a sense wire for a bit is not threaded through the bobbin, it does not see a pulse thus the amp records it as a 0 value.

Since a core rope module for the block II AGC supports 6K words of 16 bit memory, there are quite a few bits involved - 98,304 in all. At one extreme, you could build a huge bobbin that allows up to 98,304 sense wires to fit through the center. Then, regardless of the word address, you set and reset the one bobbin to generate all the values on the wires. Switching the many sense wires is the main complication and requires a lot of circuitry.

At another extreme, you could provide one bobbin per every bit, installing 98,304 bobbins and obviously requiring a very large volume to hold them all. There is no space advantage to this method over regular read/write core.

Where core rope shines is in its ability to put more than one bit in a bobbin, unlike regular read/write memories that use one core per bit. This gives it quite a volume advantage over the same amount of regular core memory.

The particular tradeoff between sense amplifiers, bobbins and number of wires through a bobbin center that was chosen by the MIT designers for the final core rope module is to install 512 bobbins in a module. Two modules together make up a rope, although they are not combined in any way to form a single logical rope.

To select a particular word, we divide up the address range to select one of the 512 bobbins - 9 bits are used for this. We then select which of 12 strands of the sense wires are tested - another 4 bits for this, generating 6,144 unique total locations when combined with the bobbin.

A module selector takes 1 bit, picking which of the two 6K modules are desired. The choice of which of the three logical ropes, units of 12K words, takes another 2 bits Thus, 16 bits of address information pick out a word.

This addressing could range up to 64K but only 36K is physically implemented. 1/4 of the address range for strands is unused (12 strands selected by a 4 bit address), and 1/4 of the rope count is unused (3 ropes selected by a 2 bit address).

The machine architecture only has 12 bits for addresses and by definition, if the top two bits of the address start with 00 then the data is in the erasable (read/write core memory) module. Thus, of the 4096 addresses that can be generated in an AGC instruction, 1K refer to the erasable and only 3K are left for the fixed (core rope).

The last 2K of address range is directly assigned to two 1K blocks of rope, starting at octal 4000, but the second 1K range is switched to any of the 36K implemented in fixed memory based on the value in the register which holds the index of the 1K block.

This bank switching register only supports 5 bits for addressing, choosing among 32K blocks of fixed memory. To get to the remainder, the AGC implements yet another technique, a super-bank bit that switches the top end blocks. The super-bank bit is assigned in channel 7.

When the value in the FBank register is 0 to 23, it selects banks 0 to 23 without regard to the super-bank bit. However, when the FBank has 24 to 31 in it, the super-bank bit adds 8 to the number. That is, super-bank=0 then 26 in FBank selects bank 26. If super-bank=1, then 26 selects bank 34.

Physically, the AGC has six core rope modules installed, each supporting 6K words. The addressing logic for reading fixed memory has to select which rope, which module in a rope, which bobbin in a module, and which strand woven through the bobbins; This strand of 16 wires drives the 16 sense amplifiers to produce the output word.

Looking at read/write core memory used in AGC Block II

RESEARCH FOR APOLLO GUIDANCE COMPUTER RESTORATION

Erasable Memory cycle and timing

The main oscillator is divided in half to produce a 1.024 MHz main clock which steps through a 12 stage ring that constitutes the memory cycle of the machine. The memories are based on magnetic cores, thus the process of reading also resets the core to zero and a second half of the cycle must write back the value to restore it into the memory - or a changed value to store into the location replacing the old value.

By the beginning of the sixth step of the ring, the contents of a memory location, either the erasable or fixed memory, is available on the bus for use. By the beginning of the 9th step, a value in the register is latched to be written out to the same memory address if it was in erasable memory.

The erasable memory consisted of lithium ferrite core stacks, manufactured by either EMI or RCA. Addressing of the memory makes use of bits 0 to 11 of the instruction word. If bits 11 and 10 are both zero, this indicates that we are accessing the erasable memory.

The memory scheme of the AGC is complicated. The 2K of memory is implemented as 8 banks of 256 words. When address bit 9 and 8 are both 1, we are referring to a bank indirectly, depending on the contents of the BBank register to select which of eight banks to use. When the high two bits are not both on, then we are directly addressing banks 0, 1 or 2 depending on the value of bits 8 and 9.

This means that from the CPU standpoint, we have only 1K addresses to select. Addresses from 0 to 767 are directly hooked to the first three banks of the physical core plane, while addresses from 768 to 1023 are hooked to one of the eight banks based on the contents of the BBank register

Physically, the core stack is a sandwich of 128 planes, each having an array of 16 x 16 cores, all folded tightly in a small space. We can look at each logical bit plane independently to understand addressing, thus we have only 8 small planes to consider,

The eight total small core planes can be thought of as an array of four across and two down. In the Y X signals run vertically through two small core planes. Y signals run horizontally through four small core planes. They intersect in only one plane.

 The address bits 0, 1 and 2 are used to select one group of eight cores out of eight such groups in the X selection lines. Two groups of eight fit on each of the small core planes, thus we have four planes across in the X direction.

Address bits 3, 4 and 5 will select one of eight of the cores in the group  thus the combination of all six bits selects one of the 64 X rows of cores. This activates an X row in both of two small core planes, which will be distinguished by the Y selection line that activates in only one of the two selected planes.

Address bits 6 and 7 select one of four groups of 8 lines in the Y direction. Bank selection logic picks one of the eight lines in a group, thus one of the banks of 256 words. Selecting 64 X and 4 Y lines with the regular address bits 1 to 7 picks which of the 256 works you want in a bank. The 4 Y lines each represent 8 physical lines, the other end of which is determined by the bank select to finalize on one of the 32 physical Y lines in the array.

There are eight banks, picked by the bank selection logic using bits 8 and 9. This works in a special way. If bits 8 and 9 are 00, 01 or 10, this selects the first three banks. If bits 8 and 9 are 11, it looks at the BBank register and uses that value to select which of the eight banks to use.

Inhibit drives run through each core in each plane, so that we can inhibit the setting of each plane individually. A sense wire runs through each core in each plane and allows detection of the case where a core is reset to 0 but was previously magnetized as a 1.

The memory stack is folded to fit best in a rectangular solid shape, its steering diodes are put on top and the entire contents are encapsulated in a wide module (B12) that will plug into tray B.

Miscellaneous notes on AGC design from my research

APOLLO GUIDANCE COMPUTER RESTORATION NOTES

Connectors

All the connectors on the Apollo Guidance Computer were constructed of the Malco mini-WASP components. These were individual pins, male and female, set in a small rectangular nylon insulator with a circular base. Individual holes were drilled in a metal chassis for each pin position, the nylon with its pin was pressed into the hole, and the holes were arranged in lines with .125" spacing.

The male pins looked like a small standard screwdriver blade. The female pins were a tuning fork shape, at right angles to the male blade. The male slide into the fork with the two tines pressing onto the male to make contact.

Female 'tuning fork' pin

Male 'screwdriver blade' pin

The nylon insulators had a circular bottom section to press into a hole in metal, with a squared off top section and a center hole into which the pin was pressed.

Female insulator body

Male insulator body

It was quite common to build multiple lines of connectors, side by side, to form arrays such as the 24 by 4 connector for core rope modules to attach to the rest of the AGC. The largest connector was the main connection between the AGC and the rest of the Apollo spacecraft. It had 360 of these pins installed in an array, a pair of 180 pin halves.

Connectors but from the predecessor block I version of the AGC

Interaction with the rest of the spacecraft

The AGC was connected to many other parts of the spacecraft. The most visible connection to people was the DSKY, the display and keyboard module that the astronauts interacted through to control the software on the AGC. However, the system was quite central in the operation of the spacecraft and interacted with many subsystems.

The inertial guidance unit or IMU provided a stable platform that would maintain its orientation in space in spite of movement or rotations of the spacecraft. Driven by gyroscopes, this platform would would hold its position as the IMU rotated around it in three dimensions. The pivots, called gimbals, had measuring devices to indicate how the spacecraft pivoted around the stable member, plus a motor that could force the platform to pivot on the gimbal.

The motors forced the stable member to pivot on the three gimbals until the member was oriented in a desired direction. This was done on the ground by uplinks from Launch Control and during flight from mission control, but the most important method of forcing the member to a known position was by use of a star sighting mechanism in the lower bay of the Command Module.

An astronaut would rotate the spacecraft to point at a known star, and through an offset scope look at a second known star. The computer would swing the spacecraft to the position it though would place the stars correctly, but the astronaut would then move the craft around until the stars were precisely in the crosshairs of the scope. Pushing a button at this point told the computer what orientation to set the IMU and what location to record for the spacecraft. 

Since gyroscopes are not perfect and drift a bit over time, the stable platform would be realigned periodically using the optics system described above. This set the IMU to a stable reference alignment and synced the computer view with the physical reality.

Three accelerometers were installed in the IMU and recorded the acceleration of the spacecraft on three axes. The computer recorded the accelerations and used them to calculate the change in position of the spacecraft. The combination of the pivot angles from the stable reference orientation and the accelerations in three dimensions allowed the computer to keep track of the spacecraft position and speed.

The computer had a pair of hand controllers that the astronauts used to command changes in the spacecraft position. One would request pitch, yaw or roll around the current position. The other would request translation along one of the axes - move left, move up, speed up, etc.

These hand controller inputs were read by the computer and caused requests to be sent to the Reaction Control System, small rockets that thrust to cause the spacecraft to translate or rotate in space. Thus, the Apollo spacecraft was a fly-by-wire system, with the AGC or a backup SCS system connecting the pilots inputs on the controllers with the RCS jets.

Telemetry was assembled and disassembled by the AGC over the links with the ground. Uplinks could even insert new data into the AGC and was used often during missions. For example, the various burns for navigation, such as Trans Earth Insertion, were calculated on the ground using the Real Time Computer Complex (a pair of IBM 360/75 mainframes) and uploaded to the AGC for execution by the astronauts.

The AGC even had a mode where it could force a takeover of the Saturn IVB computer during launch, if the astronauts or ground decided that the computer navigation inside the Saturn V was malfunctioning. The hand controller would then swing the engine of the SIVB motor and control the duration of a burn, so that an astronaut could hand fly the system if the booster navigation and control failed.

All this with only 360 signal connections from the AGC to the rest of the spacecraft. 

Studying to assist in the restoration of an Apollo Guidance Computer

ASSISTING RESTORATION OF APOLLO GUIDANCE COMPUTER

Background

I was contacted to discuss a restoration of an Apollo Guidance Computer, the block II type that was used on all the manned Apollo missions. Until I have clearance to say more, I can't discuss the location, ownership or other identifying details, but I can post about the AGC itself and the detailed studying I have been doing to prepare for this task.

AGC construction

The block II AGC is a general purpose computer constructed entirely of logic gates (and power supplies and memory of course), no microprocessors. The logic was entirely built with a single IC type, a dual NOR gate, each one triple input. These ICs are RTL, resistor-transistor logic, which preceded both diode-transistor logic (DTL) and then transistor-transistor logic (TTL).

RTL gates are very simple. Each input is coupled through a resistor to the base of a transistor. The emitter is tied to ground and the collector has the output lead and a pullup resistor to the positive voltage source. In the AGC case, this is +4V.

When a positive voltage is presented on the input, the transistor conducts and pulls the output down to almost ground level. When no input voltage, the transistor is off and the output is pulled up to nearly +4V.

The triple input NOR gate has three transistors, with three base resistors, and the collectors all tied together, making use of a single pullup resistor for the output. If any or all of the three inputs has a positive voltage, one or more of the transistors are conducting and pull the output down towards ground, otherwise with all inputs at 0, the output floats up to +4.

These dual-NOR gate chips have two of the above circuits, thus it has six transistors and eight resistors on the chip. It was built in a flat pack, a rectangular flat shape with ten leads arranged five per long side.

The chips are mounted on a multi layer printed circuit board, but welded to the pad rather than soldered. Soldering was not considered reliable enough to use with a machine that has to resist up to 50g of vibration/acceleration.

The multilayer PCB was quite advanced for the time. It was seven layers. This was designed and manufactured in the first half of the 1960s.

The top layer had the pads for the flat pack ICs to be welded, and tabs along the bottom of that layer or interconnects to the board. Next was the voltage layer. In the middle were three layers used for circuit interconnects. A ground layer sat below them and a final interconnect layer was on the bottom of the sandwich.

A printed circuit board was 9 inches wide and just over 1 inch tall, with mounting spots for 60 ICs. Thus, one PCB held 120 NOR gates of logic. The I/O interconnect tabs along the bottom edge of the PCB were in two groups of 40 and a middle group of 58, thus the PCB featured up to 138 connections to the backplane connector. Wires were connected between these tabs and the Malco mini-WASP connectors on the base of the logic module.

The logic module was sealed in epoxy potting, although some testing and development machines were left unpotted for each debugging access. Aluminum modules held two of these PCBs, one per side, with 276 pins of I/O on the bottom. This module plugged into an aluminum tray with a backplane across the bottom.



The backplane had connectors for all the logic modules, up to 240 connections each, with wire-wrap connecting all those pins together. The AGC had two such trays - the logic tray and the memory tray - which were magnesium, bolted together and put on a cold plate, forming a 24 inch by 12.5 inch structure that was 6.5 inches deep. Liquid cooling was supplied to the cold plate to remove the heat during operation.

The AGC was supplied with 28V DC and had internal power supplies to produce the lower voltages, such as 4V and 14V, needed for logic and memory. The main oscillator ran at 2.048 MHz and was used as a common timing source to drive all the attached electronics in the spacecraft.

Memory used ferrite cores. The regular read-write memory (called erasable) was 2048 locations of 16 bit words. The remainder of the memory was read-only (called fixed), built as core rope assemblies. The erasable memory needed space for 32,768 cores to hold the 2K of data, but the design of rope memory provided 36K words with only 3,072 cores.

Each core, which was larger than the lithium ferrite core used with erasable memory, is a different material and had many wires threaded through it  A core could hold 192 bits of information because the actual information storage was the wiring of sense lines. The remainder of the wiring was used to select which 16 of the 3072 cores to flip on and off. If a sense wire ran through that core, it produced a 1 on output while the wires that bypassed cores had a 0 output.

The reality was a bit more complex, because the memory was arranged in six core rope modules of 512 cores each (6K words). Inside the module were four planes of 128 cores each. In reality more than 16 cores would be flipped but selection logic and diodes assured that we picked off only the 16 bits that were desired. No individual core would ever have more than 128 sense lines through it (1 bits assigned).

During testing and software development, various core rope simulators were plugged into the AGC in lieu of the actual fixed memory modules. Some would override the core rope module, others replaced the six modules with plugs connected to the simulator. This allowed testing of software changes before the design was frozen and the Raytheon factor wove the sense lines to form a final rope module.

Teletype model 19 restoration complete; Sherman Tank Bar lives another day

TELETYPE RESTORATION WORK

Model 19 system

Marc and I finished reassembling the model 19, putting on all the last small parts on covers. Marc had carefully hand polished all the label plates so they would look good when reinstalled. Finally, we had every single part accounted for, everything installed and the table ready to power up for testing.

Flipping the switches to provide power to the REC 30 power supply did turn it on, so that after a 40 second warmup it began supplying 120V DC to the table and all components plugged in there.The other switch was flipped, the send and receive jacks of the model 15 put into the TEST socket, and we verified that the unit would successfully print what was typed.

The test power was adjusted a bit high - over 70ma when the current loop should run at 60 - but it all worked. Another model 15 was hooked to the Line1 jack and it faithfully echoed what is produced on the local model 15. The perforator on the model 15 works as well, punching tape as we typed.

The tape that was punched, threaded into the model 14 Transmitter Distributor, allowed us to test whether the TD was hooked up and working properly. It did send out exactly what was on the tape. At this point, Marc only needs to adjust down the test loop current to 60ma and he can make full use of the model 19.

SHERMAN TANK BAR

The life size Sherman Tank bar we made for the Villa Siena fundraiser was given to a different non-profit and will be used again on Veteran's day, Nov 11th, where it will serve as the information booth at Santana Row for the military vehicle event. I am happy to see this bar be of further use before it has to be torn apart and scrapped.