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.