A Brief Tour through the Schematics Part II: Instructions

Instruction processing in the AGC is quite complicated. It had a 15-bit word length, with 3 bits used for the opcode and 12 bits used for the address. This gives us 23 = 8 instructions, and allows us to address 212 = 4,096 words of memory, right?

Nope. In reality, the computer supported 34 instructions, and had 2,048 words of erasable memory and 36,864 words of fixed memory. The memory addressing was handled by a somewhat complex banking scheme, which I’ll cover in a later post. But what about the instructions?

R-700 boils it all down into one somewhat confusing diagram in figure 3-6:


Bits 13, 14, and 15 make up the 3 base opcode bits. An extra internal bit could be set by executing the EXTEND instruction. The extend bit acts essentially as just a fourth opcode bit — when it’s set, an entirely different set of instructions is selected from. These are called the “extracode instructions”. At the end of every instruction (except INDEX), the extend bit is reset back to zero. (As a result of this behavior, interrupts are inhibited while the extend bit is set).

EXTEND itself is actually not one of the 8 base instructions either; it’s in a different class known as “implied address instructions”. The premise behind implied address codes is that not all addresses make sense with all opcodes. The first 7 addresses in erasable memory aren’t actually used for RAM; the AGC maps internal registers to these addresses. I’ll go into more details in the next installment, but for now I’ll just say that not all of them are 15 bits long. The computer normally has no issue executing instructions directly out of registers in the memory map (to the instruction loader, they appear to just be in memory, after all), but this really only works for registers that are the same size as an instruction word. EXTEND, therefore, is actually assembled as “TC 00006”, transfer control to memory location 6, which contains one of these stubby registers. Knowing that this request can’t be right, the computer instead executes EXTEND.

There are other instruction/memory combinations that don’t make sense. Recall that the AGC has two types of memory: erasable (which can be modified) and fixed (which can’t). Instructions that modify memory, therefore, don’t make any sense when supplied with fixed memory addresses. Look at how the address for an instruction is encoded in figure 3-6: erasable memory is accessed only when bits 11 and 12 of the word are 0. Again, we can use this to our advantage: if bits 13-15 (and the extend bit) indicate an erasable instruction, we know bits 11 and 12 won’t be in use for the address, so we can use them as more instruction bits. In this situation, these bits are called the “quarter code”, because they select from 4 possible instructions for each erasable “general” opcode.

We can take this concept even further when dealing with I/O instructions. I/O is done through “channels” that don’t exist in the main address space (again, more on this later). There’s only 63 of these, which leaves plenty more room in the instruction word for encoding the instruction. In practice, only bit 10 of the instruction was used for this. Figure 3-6 calls this a “channel” instruction.

Now, onto decoding.

While an instruction is executing, the instruction to be executed next is loaded into the internal B register. Upon instruction completion, the new instruction is transferred out of the B register and split into two separate registers — the S register, which receives bits 1 through 12, and the SQ register, which receives bits 10 through 15, which is enough to decode the instruction using all of the above rules.

With all of that background, here’s a top-level look at Module A3, the SQ Register and Decoder.


Page 1 contains the SQ register itself, the extend bit, and first-stage decoding logic that maps the three base opcode bits into eight signals representing the eight possible combinations, and similar logic for the two quarter code bits. It also has a bit of interrupt inhibition logic that interacts with the extend bit stuff.


Page 2 contains the next step of instruction decoding. This is where instruction selection actually happens. Here the eight opcode signals, four quarter code signals, extend bit, and SQ bit 10 are combined to create many more signals, essentially one for each instruction. Output signals from here are named after the instructions themselves.

The next step in the instruction processing chain is Module A4, the Stage Branch Decoding Module. The first page contains the stage and branch registers themselves:


The stage registers STG1, STG2, and STG3 are used to select which phase of an instruction is being executed for multi-MCT instructions. The branch registers are used to handle conditions for branching instructions.

Page 2 of the Stage Branch Decoding module appears to combine the outputs of these registers with the instruction selection logic of the SQ Register and Decoder module in a manner similar to the cross point generators.


When all is said and done, we’ve now selected the subsequence of control pulses to be executed during the current MCT.

The last step is to combine our instruction selection with the time pulse signals T01,T02,…,T12 from the Timer module to generate the actual control pulses. These are basic microinstructions that mostly interact with the core registers — things like “WA” (Write the value on the write bus to the A register) or “NISQ” (load a New Instruction into the SQ register). This work is done in Module A5, Cross Point Generator NQI, and Module A6, Cross Point Generator II. These modules implement a “control pulse matrix”, which outputs the logical product of the time pulses and subsequence selectors.

R-393 Figure 2-3 contains a pretty good diagram of what all of this looks like in a block diagram:


Note that this is for the Block I AGC, so some details are not quite the same as what I discussed above, but it’s pretty close.

That’s it for now. Next up in the tour are the central registers!

A Brief Tour through the Schematics, Part I: Timing

Before I start digging into the guts of the logic, I’m going to give a top-level overview of the architecture, paired with where things are in the schematics as I currently understand them. In this first part, I’ll go over timing.

Figure 3-3 from R-700 contains the basic clock architecture of the Block II AGC:


The source for all timing in the AGC was a 2.048MHz crystal oscillator, contained in aptly named Module B7 – Clock Oscillator. The output of this module, the CLOCK signal, enters into the “Pulse Forming Divider Logic”, which makes up the majority of Module A2, page 1:


This logic puts out four phases of 1.024MHz, used as the main clock for the AGC, as well as the fundamental control pulses RT (read time), CT (clear time), and WT (write time).


Page 2 of of the Timer Module contains the ring counter shown in Figure 3-3, plus start/stop logic gating the time pulse generator.


Page 3 contains a 12-step ring counter, generating the main time pules signals of the computer, T01 through T12. One iteration through the 12 time pulses is called a “Memory Cycle Time”, or MCT. During an MCT, a single Fixed or Erasable memory access could be performed. The breakdown of memory timing throughout an MCT is shown in R-393, figure 3-1:


Furthermore, instructions are defined as subsequences of control pulses that execute each time pulse. For example, here is the time pulse sequence of the TC (Transfer Control) instruction, from AGC4 Memo #9:tc_pulse_sequence

It triggers control pulses during time steps 1, 2, 3, 6, and 8. Unlike TC, most instructions take two or three MCTs to fully execute.

The output of the 5-step ring counter (or rather, its subsequent divide-by-2 circuit) flows into Module A1, the Scaler Module.


This is page 1, but page 2 looks pretty much identical. It generates all of the power-of-two sub-frequencies of its 102.4kHz input (51.2kHz, 25.6kHz, etc…) down to 0.390625Hz. These are used in the I/O interfaces, and during operation in standby mode. Some of them drive counters in the INOUT modules that operate as timers for the software to use.

Last in our timing discussion is Module A14, Memory Timing and Addressing.


Page 1 of the Memory Timing and Addressing module contains the “timing” portion. I’m guessing it effectively implements the timing considerations shown in R-393 figure 3-1, but I haven’t spent much time looking at this one yet.

Next up: instruction processing!

Interpreting the Schematics

On first look, the schematics for the AGC are pretty hard to follow. Aside from some pullup and pulldown resistors in the restart monitor, the available Tray B modules like the oscillator and power supply, and the Tray A interface modules, they consist essentially entirely of NOR gates.

There’s a few peculiarities with the NOR gates used. Two types of NOR gates appear on the schematics. The first type is just a standard NOR gate:


The second type is almost exactly the same as the first; it’s called a “fan in gate”, and the only difference between it and the standard nor gate is that the the power pin on chips used for fan in gates is left disconnected. It is represented as a NOR gate with a black nose:


Fan in gates are used in three different ways throughout the schematics. The first, and by far the most common, is the function for which they are named: to increase the fan-in (i.e., the number of inputs) of a NOR gate. This is done simply by connecting the output of a fan in gate to the output of a regular NOR gate. Here’s a simple demonstrative example from the RUPT Service module:


Here, a six-input NOR gate is constructed using a NOR gate and a fan in gate. The principles behind this behavior are quite straightforward, given the design of the integrated circuits.


As one of the first integrated circuits ever produced, the Block II NOR gate is quite simple internally, composed of only 8 resistors and 6 bipolar junction transistors per IC (this type of circuit is known as RTL, Resistor-Transistor Logic). The above image shows the layout of one of the two NOR gates contained within each chip. Here, pin 10 connects to the power supply; pin 5 connects to ground; pins 6, 7, and 8 are the inputs of the NOR gate; and pin 9 is the output. This configuration is known as open collector: the upper (“collector”) pins of the three transistors are tied together and connected directly to the output pin of the IC. And in this, case, the resistor connecting the power pin to the rest of the circuit can be considered an internal pull-up resistor, so the external pull-up normally seen with open collector circuits isn’t (usually!) needed.

Given all of that, it’s easy to see how fan in gates work. Here’s an internal view of the above 6-input NOR example: fan_in_internals

As you can see, connecting a fan in gate to a NOR gate effectively just adds three more transistor-resistor input circuits to the NOR gate! The fan in gate’s power pin is left disconnected because otherwise the pull-up resistance would be halved. Neat, huh?

The second function performed by the fan in gates is common module outputs. It’s very closely related to the first; conceptually, it’s the same thing. The basic idea is that there’s nothing forcing a fan in gate to be close to its connected NOR gate. Indeed, there’s no particular reason why the two can’t be on different boards. This means that two completely separate modules can both drive the same signal. An example of this is the treatment of the read bus in the RUPT service module:


Here a fan in gate is being used to drive read bus line 14, with no connected NOR gate anywhere in the module. The main source of this signal is actually in four-bit module A11, here:


Note that RL14/ is facing right like an input here.

The third and final application of “fan in” gates isn’t actually for fan in expansion at all; it’s for interfacing with electrical ground support equipment (EGSE). Throughout the computer are gates like this one in the timer module:


Unlike RL14/ above, MT01 isn’t actually used anywhere in the computer proper. Therefore, instead of receiving power from any connected NOR gate, this gate would normally remain completely unpowered. Instead, this signal and those like it are routed to the “test connector” on the front of the computer. You can see that on this great image of an opened up AGC from Autopilot on Wikipedia:

Opened Apollo Guidance Computer
By Autopilot (Own work) [CC BY-SA 3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons
The main piece of EGSE that was hooked up to the test connector was “the Monitor”. The Monitor was more or less like a JTAG debugger for the AGC. It allowed for displaying the contents central registers, stepping through instructions, setting breakpoints, displaying or modifying arbitrary memory locations, and displaying the contents of the write bus.

Anyways, the majority of the unpowered signals that run out to the test connector begin with the letter “M”, like the MT01 example above — presumably short for “Monitor”.

E-1880: A Case History of the AGC Integrated Logic Circuits shows how these signals can be used in equipment like the monitor:


The main feature here is the pull-up resistor to +V on the interface side. Note that this resistor is effectively no different than the one connected to pin 10 inside the chip — the only difference is who’s supplying the power. So these gates remain completely unpowered during flight, drawing almost no current — but as soon as you plug an EGSE device into the test port, these gates are provided power and start producing useful signals. This is an extremely useful characteristic, since power was so precious; it allowed for lots of debug circuitry to be included without incurring major power draw penalties.

Somewhat late in the program (after the flights of Apollo 11 and Apollo 12), a new special module was designed to help with diagnostics during flight. Information for debugging on orbit was limited; if any one of a number of alarms occurred, the computer would simply indicate “RESTART”, without any insight into which of the alarms had caused it. The new module, called the “Restart Monitor”, was a small module that was plugged into the test port for the duration of the flight. It allowed for computer software to read the specific alarm that had caused a restart from I/O channel 77 (more on that later). And luckily, we have the schematics for it! It just so happens that the MT01 signal shown above is one of the ones used by the Restart Monitor:


As expected from the E-1880 diagram, there’s a 3.3k pull-up resistor on the line before it’s used in any logic.

There’s one last peculiarity that’s common in the schematics. In addition to increasing the fan in of a NOR gate by attaching fan in gates, it’s also possible to increase the fan out of a gate by attaching parallel powered NOR gates. Any given NOR gate output can drive 5 connected inputs, and this number can be increased by 5 for each connected parallel gate. Here’s a fan out expansion for T02/ in the timer module:


From this, we can safely assume that T02/ is driving more than 5 inputs. But we need to be careful. There’s also no reason fan out expansion gates can’t be in other modules; and with board real estate being limited, it appears that indeed sometimes these fan out expansion gates were moved to less populated modules. Module A-24, INOUT VII, also includes some fan out gates for T02/:


So in reality T02/ is probably driving more than 15 inputs.

Armed with all of this knowledge, we can now start doing more in-depth looks at the design of each of the logic modules. But first, I’m going to give a higher level functional breakdown of larger chunks of the schematics. Stay tuned!

Project Overview

Fourty-six years ago, man first walked on the moon. Onboard each of the two spacecraft used to get there was an innovative computer, called the Apollo Guidance Computer. It was one of the very first computers ever built using integrated circuits, and was constructed almost entirely out of NOR gates. It’s often said to be less powerful than pocket calculators; indeed, it had a 1.024MHz clock rate (executing one instruction every 12-36 ticks on average), ~4 kilobytes of RAM, and ~72 kilobytes of program memory.

There were two versions of the Apollo Guidance Computer: Block I and Block II. The Block I computer was used on the unmanned Apollo 4 and 6 flights; Block II AGCs were used on all manned missions. Architecturally, the two were quite similar. The primary differences were the integrated circuits used, the amount of memory, and the number of instructions.

A couple years ago I came across John Pultorak’s account of his successful effort to build a replica of the Block I AGC. I’ve always wanted to build a physical computer, and being a space geek this seemed like the perfect project. Pultorak’s election to build a Block I computer was based one two things: it was older (he initially wanted to build a Gemini computer), but more importantly, the best released document describing the computer’s architecture is R-393: Logical Description For The Apollo Guidance Computer (AGC4), which goes into pretty extensive detail about the Block I design.

However, since then, most of the original schematics for the Block II have become available. Since the Block II computer is what actually flew to the moon, it’s much more interesting to me. So, I’ve decided to build a Block II AGC, using these schematics along with R-393 and some other documents that have bene released. I’ll be making a special effort to stay true to the original schematics where possible. Like Pultorak, I’ll be using 74xx parts (probably 74HC series), but for the most part, it’ll be all NOR gates. This may change in the future if the number of parts gets too overwhelming, but even then it will be only logic simplification rather than any sort of radical change.

The schematics are missing most of the B modules, but that’s okay — tray B housed erasable and fixed memory, analog alarms, and oscillator. The erasable memory was Magnetic Core and the fixed memory was Core Rope. Both involve thousands of wires passing through tiny ferrite cores — something I don’t want to spent my time building (yet!). Instead, my versions of these tray B modules will house small, modern RAM and ROM chips, with the necessary circuitry to interface with the memory timing & addressing module in tray A.

Along with the schematics, the best available documents are:

  • R-393: Logical Description For The Apollo Guidance Computer (AGC4) – A rather in-depth description of the Block I architecture. It has some really nice block diagrams, including a data flow diagram (with bus sizes) and a good clock chain diagram. It goes into great detail about all of the internal registers and control pulses.
  • R-700: MIT’s Role in Project Apollo, Volume III: Computer Subsystem – A slightly higher-level overview focusing on the Block II computer, written around the time of Apollo 15. This details a lot of the differences between the two versions. It also goes into a lot of detail about EGSE at the end, which should be quite useful.
  • AGC4 Memo #9 – Block II Instructions – Probably the best available source about the instructions available on the Block II computer. Importantly, it contains descriptions of all of the control pulses, as well as a breakdown of which control pulses are fired at each time step for each instruction.

More posts to follow detailing my current status and some initial circuit studies!