Apollo Guidance Computer

After three years I have started back up on this project.  When I left off the display board and backplane were complete and the memory board was partially complete.  The idea was that the board under test would be moved to the last slot of the board stack.  The realization that all three boards would have to be debugged simultaneously led me to the conclusion that the board configuration would have to be modified.  This has been the first issue to attack before getting back to then fun of wiring chips together.  The new plan is to have all four boards exist in one plane that will eventually be placed into a frame, probably hinged down the middle.  The boards will still need to be connected with various ribbon cables.  The data cables defined before will remain the same, only their location on the boards will change.  The display cables will change quite a bit since there will no longer be a backplane.  A portion of the existing backplane was cut off.  This will become a breakout board that plugs onto the bottom of the existing display board.  Each group of pins relates to displaying things like registers and control pulses.  These pins have been grouped into either 8, 16 or 20 bits.  Each of these connectors route to only one other board.  The other three boards will have these display connectors on the bottom edge instead of the huge backplane connector as before.  This simplifies things significantly.  The display board will have the LEDs face out and the other three boards will have the wire wrap side face out.  

This is the configuration that makes the most sense.

The memory board has been rewired for this new configuration.  The control board only had connectors and those have been relocated.  The only mod that the display board needs is the power supply connector moved to the other side of the board.  You can see that I am working on the breakout board that will connect to the underside of the display board.  

Once the breakout board is complete I will connect the memory board to the display board and start the process of re-verifying the wiring to date on the memory board.  I stopped wiring the memory board when the realization hit me that without the display board, debugging was getting too hard.  

I have created an initial set of schematics for this sub-system, but have not yet started wiring it up.

Here are design notes that help understand the schematics.

Central Registers: The Central Registers module implement the A, L, Q and Z registers along with implementing the ANDing, ORing and XORing of the A register with the Channel bus. The four central registers have numerous sources of data and various control pulses that perform specific functions. This is all straight forward logic.

The Z register has logic to perform the Z15 and Z16 command pulses. These pulses set the Z register to 040000 and 0100000 respectively.

The WALS command pulse is not simplistic.

Part of the central registers is the logic read from and write to the channel bus. This logic involves ANDing, ORing and XORing the contents of the A register with the bus data. To simplify the design and the chip count, four 74LS181 ALU chips are used. These chips have a 4-bit mode select. The Mode Control is set high to inhibit internal carries. The A data is set to the contents of the A register while the B data is set to the contents of the channel bus. The write to the channel bus is either a straight pass through, A anded with the channel data or A ored with the channel data. The read from the channel bus also can perform an xor of the data. Note that the instruction indicators are logic low. The following table defines the operations and the mode control values.

WS0 = !WAND

WS2 = !WOR

WS1 = WS3 = High

RS0 = !RAND

RS1 = High

RS2 = !ROR + !RXOR

RS3 = !READ + !RAND + !ROR

Arithmetic Logic Unit: This module is the most complex of the modules requiring the most design effort. The X, Y, U and B registers are implement in this module. There is also a pseudo C register which is simply the 1's compliment of the B register. The X and Y registers have numerous control pulses to load them with various values. The X and Y registers feed four 4-bit adder chips used to add their values. The output of the adders is contained in the U register.

The U register's bit 16 is either the output of the ALUs or the sign bit (bit 15) extended into bit 16 if RUS is asserted.

The end-around carry bit logic is rather complex as the multiply uses 2's compliment arithmetic where everything else in the computer uses 1's compliment arithmetic. The sub-sequences can disable the end-around carry. The end-around carry is disabled during a multiply using the NEACON and NEACOF. This value is stored in a 1-bit register.

The X register has five control pulses that generate six outputs. These include B15X which generates an octal 060000, PONEX which generates an octal 000001, PTWOX which generates an octal 000002, a combination of PONEX and PTWOX which generates an octal 000003, MONEX which generates an octal 177776 and ZERO which zeros the X register. A bit table in MSB first format is as follows.

The only bits with any complexity are bits 1 and 2. Their equations are as follows.

1 = !M1X + (P1X + P1X P2X)

2 = M1X + (P2X + P1X P2X)

The U and B registers feed four 4-bit ALU chips that can perform a number of combinational logic sequences. The output of the ALU chips go directly to the Write Bus. The pulses that drive the ALU logic include the RB, RC and RU. The following equations are required and numbered for reference. WB is the Write Bus.

if RC then

	if RA then WB = A + B  (A in WB) 	: 0

	else WB = B				: 1

if RB then WB = B				: 2

if RU then

	if RC then WB = B + U			: 3

	else if RB then WB = B + U		: 4

	else WB = U				: 5

Equation 0 is implemented separately due to the fact that the A value is contained within the Write Bus. The ALU chip has four control bits. The following table identifies the control bits required to implement the equations.

This can all be translated into a truth table used to define the values of the four ALU control bits. The S0-3 values are defined as a hex value.

Using Karnaugh maps, the following equations were generated.

0 = (B !C) + (A !B C)

1 = (A !C) + (!A B C)

2 = (A !B C) + (A B !C)

3 = (!A B C) + (A B !C)

There are three sequence portions that are duplicates and only need to be implemented once. These sequences are (A !B C), (!A B C) and (A B !C).

As if that weren't enough, the ALU implements six control pulses that ORes fixed values on the write bus. These are R1C, R15, R6, RB1, RB2 and RSTRT. The following table shows the values that are associated with each pulse.

Most of the bits are either 0 or 1 if R1C is asserted. The exceptions are bit 12 which is also 1 if RSTRT is asserted along with bits 1, 2, 3 and 4.

I have drawn initial schematics for this sub-system, but have not started wiring it up.

Here are design notes that help understand the schematics.

Clock: At the heart of the Clock module is a 4 MHz crystal that is divided into four non-overlapping 1 MHz clock signals; CLK1, CLK2, CLK3 and CLK4. This allows the read data to be placed on the bus before the write signals latch the data into the registers. The clock signal can be replaced by a 555 monostable multi-vibrator chip with a variable resistor to provide a slower, variable clock for debugging purposes. The output of these two sources are used to create the two clock pulses.

The two clock signals are generated using two J-K flip-flops. The following table shows the states of the two flip-flops and their meaning. The first flip-flop (FFA) has its J & K inputs tied high, putting that flip-flop into a toggle mode. The Q output of the first flip-flop feeds the J/K input of the second flip-flop (FFB). This puts the second flip-flop into a hold/toggle mode. The Q and !Q outputs of both flip-flops are ANDed together as follows.

Scalar: The Scalar module successively divides the first clock pulse in half using six 4-bit counters. Three clock pulses are pulled out of the scalar. The F10 output is a 100 Hz clock pulse used to drive the time counters. The F13 output is a 12.5 Hz clock pulse used in the TPG module. The F17 output is a 0.78125 Hz clock pulse used in the TPG module. These can also be manually generated for debug purposes. Note that a 2.048 mHz crystal is not available, so a 2.0 mHz crystal will be used. This means the real time clock will not be exactly accurate, but close enough.

The first 4-bit counter divides the 1 MHz clock pulse by ten, resulting in a 51.2 kHz clock pulse. The next five 4-bit counters count down and therefore divide the 51.2 pulse by two.

Timing Pulse Generator: This module is a state machine used to sequence through the timing pulses that make up a memory cycle. There are 12 timing pulses plus two additional pulses to perform startup and two pulses to perform debugging. These 16 timing pulses are cycled via a 4-bit counter. Most state changes occur via the clock 1 pulse unless the system is being debugged. In this case there are state change equations that drive the state machine.

The timing pulse generator is driven by CLK1 which is delayed so the write bus can be written to before the TPG changes state.

There are a number of state changes that are numbered and listed below. Note that moving from TP1 through TP12 is performed via the counter which free runs if the CET input is 1.

The logic driving this implementation depends heavily on the 74LS161 counter chip. There are two inputs that drive the logic. The first one is the PE or NPE pin. When set low, data is loaded from D0-D3. This data sets the next state to TP1. When NPE is set high, the logic is controlled by the CET pin. The CET pin, when set low operations are put on hold. When high, the chip counts once per clock pulse. The following table shows each state and what these pins need to be to move to the next state.

The equations that need to be implemented to drive the NPE and CET pins is as follows. Note that the equations derive the negative because the zeros are the simplest to implement.

NPE = (WAIT * TPG_6) + (TP12 * TPG_3) + (TP12 * TPG_2 * (!TPG_3 + !TPG_4))

CET = (STBY * !TPG_0) + (PWON * !TPG_1) + (SRLSE * !TPG_5) + (WAIT * !TPG_6

Control Pulse Matrix: This module is divided into three sections; CPM-A, CPM-B and CPM-C. CPM-A uses nine EPROMs to house 72 of the original control pulses defined in the original NASA documentation. I created a 16-bit address to define each of the sub-sequence timing pulse control pulses. There can be up to five control pulses defined for each timing pulse. It should be noted that there were minor mistakes in the CPM definition in the original documentation.

The address for the EPROMs are as follows:

Bits 10-16 are identical to what is defined above except for one sub-sequence, PINC. Instead of extending the address, PINC uses an unused code where bits 10-16 are all 1's. The bits are stored and passed around the system as negative logic, i.e. 0 = asserted.

The EPROMs are laid out as a matrix of individual bits, 72 bits per unique address. These bits are inverted, i.e. 1’s complement negative logic. Eight control pulses are defined per EPROM. The first EPROM defines control pulses 1 through 8, the second defines 9-16 and so on until the last EPROM which defines 65-72 control pulses.

It should be noted that the DINC sub-instruction is not implemented. The MOUT, POUT and ZOUT control pulses are only used by DINC, therefore these have been removed from the list and the control pulses have been re-numbered. This gets the count down to 72, which takes the EPROM chip count down by one.

CPM-B takes a few of the control pulses and asserts other, mostly internal control pulses based on the instruction address. These include RSC, WSC, WG, RCH, WCH, RAD and ZIP. The ZIP processing generates WY, RB, RC, WYD, CI and MCRO as follows.

CPM-C asserts control pulses based on the timing pulse of the memory cycle. This drives such things as reading and writing memory values. The state of the TPG cycle drives what control pulses are asserted. The following table is a summary of the control pulses that are asserted for each state and any logic required to assert that pulse. This logic can also be found in the CPM.java code. Some of the more complicated “if” statements are summarized into their own control pulses defined after the table.

TP12:

if SNI register bit is 1 then 
	if IRQ asserted then assert INTR, RPT, INHINT

	else assert RB, WSQ

	assert CLISQ
 if DOTP12 then assert RSTSTG, DCDSUB
 if (runPINC & PreStage reg = 0 & EXT reg = 0) then assert PINC
 if CLREXT register = 1 then clear EXT reg bit & clear CLREXT reg bit

DOTP1 is set if (EXT reg bit = 1 & Stage reg != 2 & subseq != (NDX0/NDX1/NDXX0/NDXX1/DCA0/DCS0/DV0/DV1/DV3/DV7/MP0/MP1/RUPT0))

DOTP4 is set if (GTR7 is asserted & GTR1777 is not asserted & subseq != (DV3/DV7/DV6/DV4))

DOTP6 is set if (GTR1777 is asserted & subseq != (DV3/DV7/DV6/DV4))

DOTP7 is set if (WG/GTR7 are asserted & GTR177 is not asserted & WE is not asserted & subseq != TCF0 or subseq == ADS0/TS0/DAS1)

DOTP10 is set if (GTR7 is asserted & GTR1777 is not asserted & Stage reg != 2 & subseq != TCF0/TC0/BZF0/NDX1/MP1/MP3/RSM3/DV0/DV1/DV3/DV4/DV6/DV7/READ0/WRITE0/RAND0/WAND0/ROR0/WOR0/RXOR0/DXCH0/DXCH1/NDXX1)

DOTP12 is set if (subseq != DV0/DV1/DV3/DV7/DV6)

Notice that some of the signals have a suffix of “a” or “b” or “c”. This designates that more than one chip is asserting that signal. These need to to be ORed together so that there is only one source of the signal.

Sequence Generator: This module contains the staging logic, branching logic, SNI register and Sequence register. In Block I the stage register is two bits. In Block II the stage register was extended to three bits due to the divide instruction. I also needed to add a pre-Stage register to facilitate pre-staging of the divide instruction. I refer to the two registers as the Stage and preStage registers. The next sub-sequence stage is set up using the ST1, ST2 and DVST control pulses. These pulses set the preStage register and during TP12 the preStage register is moved the Stage register using the RSTSTG pulse.

The divide is unique in that it uses the STAGE pulse to increment to the next stage after TP3. The sequence of stages for the divide instruction is not sequentially numeric. It uses a simple routine that implements an inverted end-around carry. The best way to show this is visually. To increment the stage number the bits are shifted left one bit with the end around carry being inverted. This is ingenious because it avoids stage #2 which is reserved for the STD2 sub-sequence, it provides the required 6 sub-sequences and it is easy to implement.

The other interesting aspect of this is that it would normally take six memory cycles to implement the six stages. This was modified such that the DV0 sub-sequence only runs for three timing pulses before the DVST control pulse switches to the next sub-sequence. The next sub-sequence then runs from TP4 through TP12 and then TP1 through TP3. At the end DV4 only has TP4 through TP12 defined. This allows the divide instruction to only take five memory cycles.

The branching register consists of two bits that are set by five test control pulses; TSGU, TSGN, TSGN2, TOV and TPZG. These use simple gate logic to decide if the two branch values should be set. The following equations show how BR1 and BR2 are set. The variables U16, L15 and WB15 indicate the values of those register's bits.

BR1 = (TSGU * U16) + (TL15 * L15) + (TSGN * WB15) + (TOV * WB16)

BR2 = (TSGN2 * WB15) + (TOV * WB15) + (TPZG * GMZ) + (TMZ * WBMZ)

The Sequence Generator decodes the sub-sequence using the opcode, quarter code, channel bit and stage values. To simplify the logic, these are stored in a single EPROM. A number of these sub-sequence values are used throughout the computer to drive logic based on which sub-sequence is running. Some of these values are combined to determine when other internal control pulses should be asserted. The 10-bit input “address” to the EPROM is as follows: EOOOQQCSSS where E = the EXTEND bit, OOO = the 3 bit opcode, QQ = the 2 bit quarter code, C = the channel bit and SSS = the 3 bit stage. The output of the EPROM is a 6-bit number representing the subsequence number defined in the design section.

The instruction decoding address depends on the “don't care” bits of the instruction table shown in the design section being zeroed. The table below lists the bits based on the opcode groups. In code this is an if, else if, else if, else construct.

The resulting logic is as follows:

The three Stage bits are always the stage value.

The EXT, SQ5, SQ4 & SQ3 bits are their normal values unless the Stage value is 2, then the bits are zeroed.

The SQ0 bit is zero unless the Order code is octal 10.

The SQ1 and SQ2 bits are their true values if the Order code is octal 1, 2, 5, 10, 11, 12 or 16. This last equation is the only one that is not simplistic. If the bits are placed in a truth table (see below) are the values that produce a true, then the following equation is derived. As before, the NOT value is shown as an underline versus an over bar. The NOR is represented as a ||.

Result = (!A !C D) + (!B !C D) + (!B C !D) + (A C !D) = (!C !D) || (C D) || (!A B !D) || (A B !C)

Sheet CTL_SEQ_CTL has logic that implements the “if” statements of CPM-C. The naming convention is based on the timing pulse the “if” statement is associated with, such as DOTP1 is the “if” construct for timing pulse 1. The “if” statements are shown below.

TP1 = if (EXTEND == 1 & STG != 2 & !NDX0 & !NDX1 & !NDXX0 & !NDXX1 & !DCA0 & !DCS0 & !DV0 & !DV1 & !DV3 & !DV7 & !MP0 & !MP1 & !RUPT0)

TP4 = if (GTR_7 & !GTR_1777 & !DV3 & !DV7 & !DV6 & !DV4)

TP6 = if (GTR_1777 & !DV3 & !DV7 & !DV6 & !DV4)

TP7 = if (WG & GTR_7 & !GTR_1777 & !TCF0 & !WE)

TP10 = if (GTR_7 & !GTR_1777 & !TCF0 & !TC0 & STG != 2 & !BZF0 & !NDX1 & !MP1 & !MP3 & !RSM3 & !DV0 & !DV1 & !DV3 & !DV4 & !DV6 & !DV7 & !READ0 & !WRITE0 & !RAND0 & !WAND0 & !ROR0 & !WOR0 & !RXOR0 & !DXCH0 & !DXCH1 & !NDXX1)

TP12 = if (!DV0 & !DV1 & !DV3 & !DV7 & !DV6)

Here are additional details you need to understand including the Control Pulse Matrix and the instructions.

The control pulses are the heart of the system. Each instruction has a sequence of control lines that are activated to cause data to flow through the system. Some of the control pulses have a control number in the control number column. These numbers came from the R-700 documentation. Through testing it was discovered there are a few minor errors in the matrix. I found another version that had the correct control pulses. These errors were in the multiply and divide instructions.

The following table is a combination of design and implementation. It lists each control pulse, where it originates and terminates on the hardware diagrams and what function is performed. The hardware diagram names are sub-system followed by module followed by sub-module. The Active State column can have a value of Low or High meaning the control pulse is active low or high, or values of Pulse meaning it is a pulse such as a clock pulse or a value of Bit meaning the value represents a bit value. Most of the control pulses are active low because many of the TTL chip inputs that are controlled are active low. That and many more of the TTL chips are active low logic. The few control pulses that are active high were chosen to be because that resulted in fewer chips required.  Just an FYI, this table formats better on my GitHub wiki page.

ZIP also implies if L15,2,1 are:

The instructions that are executed by the AGC are integral to the understanding of both the hardware and the software. They are described here so as not to clutter the design section. In the following sections, L is the location of the instruction and K is the data address (i.e. the operand) of the instruction. Items in parenthesis preceded by “c” mean the resulting contents of that variable. Items in parenthesis preceded by “b” mean the contents before the operations. The “editing if K is 0020 – 0023” means the bit shifts and rotates occur.

There are both “voluntary” and “involuntary” instructions. The voluntary instructions are the ones that can be coded, compiled and placed in fixed memory to execute. The involuntary instructions are triggered as part of counter interrupts and cannot be coded into a fixed memory program. The only involuntary instruction implemented here is the PINC instruction due to the limited counters implemented.

1. TC K: Transfer Control

This instruction transfers control to address K after placing the return address into Q. The special cases are K = 3, 4 & 6.

c(Q) ← L + 1

1. TC 3: RELINT: Allow Interrupts

This instruction allows the resumption of interrupts after the INHINT instruction.

1. TC 4: INHINT: Inhibit Interrupts

This instruction inhibits interrupts from occurring.

1. TC 6: EXTEND: Extracode Bit

This instruction sets the extracode bit which sets the high order, bit 16 of the opcode. This is used to double the number of available instructions and is used for less frequently used instructions as it requires this extra instruction to execute the extracode instructions.

1. CCS K: Count, Compare & Skip

This instruction is a four way branching instruction. The following describes the four branching conditions. The value assigned to K is called the Diminished Absolute Value (DABS) which replaces A with one less than the its previous value. This allows for a looping count down construct.

c(A) ← DABS[(K)] where DABS(x) = |x| - 1 if |x| > 1 or +0 if |x| <= 1

c(K) ← b(K), editing if K is 0020 - 0023

if b(K) > +0 then no skip

if b(K) = +0 then skip to L + 2

if b(K) < -0 then skip to L + 3

if b(K) = -0 then skip to L + 4

1. DAS K: Double Add to Storage

This instruction adds the contents of K and K + 1 to the A and L registers. If K or K + 1 is 0020 through 0023 then the shifts/rotates occur.

c(K, K + 1) ← b(A, L) + b(K, K + 1)

1. LXCH K: Exchange L and K

This instruction exchanges L with K. The prime tick indicates overflow correction.

c(L) ← b'(K)

c(K) ← b(L), editing if K is 0020 - 0023

1. INCR K: Increment

This instruction increments K.

c(K) ← b(K) + 1, editing if K is 0020 - 0023

1. ADS K: Add to Storage

This instruction adds A to K and the results are both placed into A and K.

c(A) & c(K) ← b(K) + b(A), editing if K is 0020 - 0023

1. CA K: Clear and Add

This instruction places the value of K into A.

c(A) ← b(K)

c(K) ← b(K), editing if K is 0020 – 0023

1. CS K: Clear and Subtract

This instruction places the negated value of K into register A.

c(A) ← -b(K)

c(K) ← b(K), editing if K is 0020 - 0023

1. INDEX K: Index Next Instruction

This instruction modifies the next instruction by adding the operand to the next instruction.

c(K) ← b(K), editing if K is 0020 – 0023

Use [b(K) + c(I + 1)] as next instruction

1. INDEX 0017: Resume Interrupted Program

This is a special instruction that resumes from an interrupted program. c(0017) contains the next instruction.

c(Z) = c(0015)

1. DXCH K: Double Exchange

This instruction exchanges the contents of A and L with K and K + 1.

c(A, L) ← b(K, K + 1)

c(K, K + 1) ← b(A, L), editing if K or K + 1 is 0020 - 0023

1. TS K: Transfer to Storage

This instruction transfers the contents of K to storage.

c(K) ← b(A), editing if K is 0020 - 0023

if (A) has positive overflow, A ← +1, skip to L + 2

if (A) has negative overflow, A ← -1, skip to L + 2

1. XCH K: Exchange

This instruction exchanges the data in K with the data in register A.

c(A) ← b(K)

c(K) ← b(A), editing if K is 0020 - 0023

1. MASK K: Mask

This instruction ORs the contents of K with the contents of A.

c(A) ← b(A) || c(K)

1. READ KC: Read Channel KC

This instruction reads the KC channel into register A.

c(A) ← c(KC)

1. WRITE KC: Write Channel KC

This instruction writes the contents of register A onto the KC channel.

c(KC) ← c(A)

1. RAND KC: Read and Mask

This instruction reads the KC channel and ANDs it with the contents of register A.

c(A) ← b(A) & c(KC)

1. WAND KC: Write and Mask

This instruction writes the contents of register A masked with the contents of KC channel into A and KC.

c(KC) and c(A) ← b(A) & b(KC)

1. ROR KC: Read and Superimpose

This instruction reads the KC channel and ORes it with the contents of register A.

c(A) ← b(A) || c(KC)

1. WOR KC: Write and Superimpose

This instruction writes the contents of register A ORed with the contents of KC channel into A and KC.

c(KC) and c(A) ← b(A) || b(KC)

1. RXOR KC: Read and Invert

This instruction reads the KC channel and XORes it with the contents of register A.

c(A) ← b(A) xor c(KC)

1. DV K: Divide

This instruction divides the contents of A by the contents of K. The quotient is placed in A and the remainder is places in Q.

c(A) ← b(A, L) / c(K)

c(L) ← remainder

1. **BZF K: Branch Zero to Fixed ** This instruction branches to instruction in K if the contents of A is zero else it simply executes the next instruction.

If c(A) = 0 then branch to K.

1. MSU K: Modular Subtract

This instruction performs a 1's compliment subtraction of K from A. A modular subtraction is the difference between two unsigned 2's compliment inputs.

c(A) ← b(A) 0 b(K) where 0 is a modular subtract

c(K) ← b(K), editing if K is 0020 – 0023

1. QXCH K: Exchange Q and K

This instruction exchanges the contents of the Q register and the contents of K.

c(Q) ← b(K)

c(K) ← b(Q), editing if K is 0020 – 0023

1. AUG K: Augment

This instruction augments K which means the value is incremented if positive or decremented if negative.

If b(K) >= +0, c(K) ← b(K) + 1, editing if K is 0020 – 0023

If b(K) <= -0, c(K) ← b(K) - 1, editing if K is 0020 – 0023

1. DIM K: Diminish

This instruction diminishes K which means the value is decremented if positive or incremented if negative.

If b(K) > +0, c(K) ← b(K) - 1, editing if K is 0020 – 0023

if b(K) = 0, c(K) ← b(K), editing if K is 0020 - 0023

If b(K) < -0, c(K) ← b(K) +1, editing if K is 0020 – 0023

1. DCA K: Double Clear and Add

This instruction moves K and K + 1 to A and L.

c(A, L) ← b(K, K + 1)

c(K) ← b(K), editing if K is 0020 – 0023

c(K + 1) ← b(K + 1), editing if K is 0020 – 0023

1. DCS K: Double Clear and Subtract

This instruction moves the negated values of K and K + 1 to A and L.

c(A, L) ← -b(K, K + 1)

c(K) ← b(K), editing if K is 0020 – 0023

c(K + 1) ← b(K + 1), editing if K is 0020 – 0023

1. INDEX K: Index Extracode

This instruction is the same as the non-extracode version except the extracode switch is not reset.

1. SU K: Subtract

This instruction subtracts the contents of K from A. If an overflow occurs, either +1 or -1 is placed into A depending on the type of overflow.

c(A) ← b(A) – b(K)

c(K) ← b(K), editing if K is 0020 – 0022

1. BZMF K: Branch Zero or Minus to Fixed

This instruction branches to the instruction at K if register A is zero or negative, otherwise it continues with the next instruction.

if c(A) <= +0, branch to instruction at K,

else execute next instruction

1. MP K: Multiply

This instruction multiplies the contents of with the contents of K. The results are placed into the A and L registers.

c(A, L) ← b(A) * c(K)

1. PINC: Positive Increment

This involuntary instruction is used to increment a counter by one.

c(CTR) = b(CTR) + 1

This is where I started.  I added the code EPROM and RAM, then started adding various access registers before I became overwhelmed using just my simple 16-bit register viewed.  I realized I needed the Display sub-system so I switched gears and have been working on that.  Here are some pictures of where I am to date.

Even though I have the AGC Code EPROM plugged in, I will probably start with some simpler test programs I have created to test various commands that never seemed to come up in the AGC code.  Some of that code contains the more complicated multiply and divide instructions.  The documentation has good test case scenarios that I used to make sure they are working.

Here are some design notes that help understand the schematics.

Erasable/Fixed Memory: This module contains a single EPROM chip that contain the code which was generated using the modified assembler. This is a 16-bit data by 16-bit address chip that can handle all the code in the Luminary 099 program. There are also two RAM chips that implement the erasable memory.

The single 16-bit EPROM brings some simplification from a chip count, however it is more complicated from an implementation standpoint. The data lines are a bit reversed from what you might expect. The bytes are reversed and I did not attempt to change this as it is easier to read and verify in this configuration. From a hardware perspective, it is a simple matter to switch the byte's data lines. If the address is 0 then the first data word is 1687 hex. Given this, the data lines are as follows.

1 = D7 – D4

6 = D3 – D0

8 = D15 – D12

7 = D11 – D8

The address lines are as you would expect when dealing with the EPROM. For instance, address 4000 octal equals 800 hex which will give a data value of 0004 hex. The S-Record format is what is a bit strange. The data is defined a byte at a time. To see this data value in the S-Record file, double the address value. In the case of 4000, double 800 hex gives a value of 1000 hex. Looking at the S-Record values at this location you will see 00 04 38 2c.

Memory Buffer: This module encapsulates the G register. All data in and out of memory go through this register. The shifting when writing to addresses 20, 21, 22 and 23 occur in this module. Data arrives via the Write Bus and Direct Write Bus. The data read from fixed memory is checked for specific values; all zeros or GMZ, EQ3, EQ4 and EQ6. The EQ pulses check for the TC instructions that translate into the RELINT, INHINT and EXTEND instructions.

The determination of the four specific G register values results are straight forward except the combination of the CYR and SR. All the bits are the same except bits 14, 15 & 16. The table below shows the values.

Parity: This module in Block I was driven by control pulses within the Control Pulse Matrix. In Block II they realized you always generate parity when writing to memory and test parity when reading from memory. I kept the control pulses as internal pulses to drive this functionality. I chose to implement parity for the erasable ROM memory, but not for the fixed memory. It would be easy enough to implement this if you wanted to.

This functionality is implemented using two parity generator chips. This module contains the P register and PALM (parity alarm) single bit register.

Interrupts: This module implements three of the interrupts; the keyboard interrupt along with TIME3 and TIME4. The inhibit interrupts is also implemented in this module. A RPCell register maintains which interrupt has occurred. When an interrupt is processed, this module converts the specific interrupt into the memory address of the code's interrupt jump table. The address equals 04000 + RUPT # << 2. The addresses are (in octal).

4014 = RUPT3(TIME3)

4020 = RUPT4 (TIME4)

4024 = RUPT5 (KBD

Counters: This module implements four of the counters. The implemented counters and their octal addresses are as follows.

TIME2 = 24

TIME1 = 25

TIME3 = 26

TIME4 = 27

When counters TIME3 and TIME4 overflow, they generate an interrupt. When counter TIME1 overflows, it increments the TIME2 counter. The TIME2 counter should never overflow.

A counter address is generated when asked for by the RSCT control pulse. This is the address of the counter to increment (shown above).

I started wiring up the Memory sub-system board and realized quickly that I needed the display board to show the state of the various registers.  I first had to create a backplane to connect the boards into.  The backplane carries all the signals the display board requires.  The display functionality was not part of the original AGC.  This functionality is based on my simulator and what I needed to control the simulation.  The actual computer required data and control signals are routed via ribbon cables on top of the boards.

Here is the backplane.  Notice that I left room for an additional board, just in case.  I had to make all the  connector cables and slots universal so I could move the board under test to the back of the stack to have access  to the wire wrap pins for debugging purposes.

The display panel has LEDs grouped by register.  In the middle of the board is an array of sub-sequences showing which sub-sequence is being executed.  All of the controls that are available on the simulator are available here, including a row of 16 data/address input switches.  I chose to solder this board and the front board of the DSKY.  All remaining boards are wire wrap for easy modification when I make that inevitable mistake.

All the LEDs are wired up and tested.  I am working on the switch logic.  

Here are some of design notes that help understand the schematics.

The backplane is used to route all LED and switch lines between the logic boards and the display board. There are 338 connectors (169 * 2). If a NOT gate is required for the LED to show positive logic, then that is placed on the logic board.

The lines are laid out so that each of the three logic boards (CTL, MEM, PROC) do not have doubled up or overlapping pins. This way only one row of wire wrap terminals are required. It also strengthens the connection as more pins are anchoring the boards. The schematics use global labels to identify connections to the backplane due to the limitations of drawing real estate. The backplane connectors are shown on the interface drawings as single row connectors. The largest connector is 40 pins so multiple 40 pin connectors are required. The global labels on the hardware diagrams are numbered as per the list below.

The pin layouts identify two rows; A & B. The purpose column identifies the subsystem-module purpose with the number of connections in parenthesis. Note: The register and memory switch LSBs are the lower number, the higher number is the MSB. There are two unused pins every 25 pins due to the space required for the backplane ribbon cable connectors. The following tables shows the pin assignments.

Row A:

Row B:

The backplane has enough room in case another chip board is required. No reason to "cut" myself or the ribbon cables short. Here are pictures of the front and back of the board.

CPU Connectors: The J connectors contain the computer connections related to bus data and control pulses. They are designed in such a way that the three rear sub-system boards are interchangeable. This is due to the fact that the “board under test” is in the rear and is easily accessible. This is accomplished by having a connector for each of the slot's ribbon cables on the backplane even though they may not be used by that specific logic board. These connectors are located on the top of the boards. Only two of the ribbon cables extend to the DISP board. These are located on the side of the boards.

The top connections are positioned to the left of the boards. The order is J107, J101, J106, J105, J102 and J100. J107 starts one pin to the right of the edge and there are two unused pins between connectors so the connector cables can fit.

The following table is as summary of the connectors, how many pins, the purpose, the boards requiring the connection and the spares. The pin assignments are left to right for top pins and bottom to top for side assignments.

The following lists each ribbon cable and its pin assignments.

J100: (40 pins) CTL, PROC, MEM

J101: (16 pins) Write Bus

J102: (20 pins) CTL, PROC

J103: (16 pins) CTL, DSKY

>th >Pin

J104: (20 pins) PROC, DSKY, MEM, DISP, CTL

J105: (20 pins) MEM, PROC

J106: (40 pins) CTL, MEM

J107: (16 pins) MEM, CTL

>td >14

DSKY Connectors: The three DSKY boards require interconnections. Given the number of pins required, this board set requires two 40-pin connectors, two 16-pin connectors and one 10-pin connector. The board rows are 47 pins wide so there is plenty of room for the two 40-pin connectors edge mounted across the top. The first connector (J300) contains pins 1-40. The second connector (J301) contains pins 41-80. The third connector (J302) contains pins 81-96. The fourth connector (J303) contains pins 100-115. The fifth connector (J304) contains pins 116-125. There is also a need for power connectors between the boards so they can be separated.

The boards are numbered to ease the decoding. Board #1 is the front board with the keys and display. Board #2 is the middle board with all the display transistors. Board #3 is the main chip board. To better understand this, the first table is a summary of what connectors go between which boards. This is followed by the detailed pin assignments.

The DSKY is a separate physical piece of hardware with a simple interface consisting of the 15-bit channel bus and a handful of control signals.  I built this as a stand-alone piece that started out as two boards and then grew to three boards.  I have tried two different implementations and have finally settled on a third implementation.  This has been slow going as during the pandemic I have been stymied with a shortage of certain chips.  I first tried using only simple TTL chips and it got a bit too complex.  I then discovered an LED driver chip and decided to go with those.  I purchased three of these chips and discovered I needed a fourth and I have been waiting for 6 months for availability to complete this sub-system.

I test this sub-system with a Raspberry Pi driving the data lines.  Here is picture of that setup.

As soon as I get the remaining chips I need I will complete this sub-system.  In the mean time I made a paper model of the DSKY and that sent me down the path of building a better looking model of the DSKY.  See my DSKY Model project for the progress on that DSKY.  Both DSKYs are designed to connect to the AGC.

Here are some of the design notes that will help understand the schematics.  

Keyboard: This module implements 19 switches. These switches are converted into a keyboard code using gate logic that is stored in the Channel 15 register. The keyboard codes, their meaning are defined in the following table.

The keys are pushbuttons that are normally high. A keypress presents a zero to the logic equations. Negative logic presents the easiest solution. All the lines of interest are normally 1. The logic for each of the five code bits is looking for a key to go low. The logic equations utilize 3 and 4 input NAND gates along with 2 and 3 input NOR gates. The results is NOTed. The equations are as follows.

A = (a * b * c * d) + (e * 0) + (f * g * h)

B = (8 * 9 * c * d) + e + (f * g * h)

C = (4 * 5 * 6 * 7) + (f * g * h)

D = (2 * 3 * 6 * 7) + (b * d * e * g) + h

E = (1 * 3 * 5 * 7) + (9 * a * c * e) + h

Notice that some of the portions of the equations are the same. For instance, A, B and C both have the (f * g * h) portion.

Display: The Display module implements the Channel 10 and 11 registers. Channel 10 is used to write data to the 7-segment LEDs two LEDs at a time. Channel 11 is used to light various indicators. Eight indicator are controlled using Channel 11. Another eight are controlled using Channel 10 with a specific relay word.

It should be noted that all the miscellaneous timing pulses using 555 chips are set up as astable multi-vibrators.

Most of the display logic decodes the Channel 10 value which is used to drive the 7-segment displays as pairs of numbers. Each output to this register drives two 7-segment numbers along with the plus/minus signs and a few other indicators. The format of the register is bits 1-5 hold a low digit value (DSPL), bits 6-10 hold a high digit value (DSPH), bit 11 indicates the plus/minus sign (DSPC) and bits 12-15 contain the relay word (RLYWD).

RRRRSHHHHHLLLLL

According to Ron's website, it is unclear how to blank the sign LEDs. There is one that says light the “+” sign and one that says light the “-” sign. Ron chose to display a blank if both values are zero. There is also the case where both may be set. I am not sure if this is avoided in code, but I have decided to handle this as a blank the sign case. The following table shows the possible states and the results.

The relay words and the digits each one drives is listed below.

The 7-segment LEDs and their names are laid out as follows on the DSKY.

A decoder is required to convert from the 5-bit AGC code to a 4-bit hexadecimal number (BCD) that is understood by the BCD to 7-segment decode chips. The following table shows the two formats side-by-side.

The two AGC values need to be decoded side by side, therefore the same logic is repeated twice. This logic uses four 3-8 bit decoder chips with values grouped based on the two high order bits. The outputs are individual lines that represent a numeric value in the table. These are then used as inputs to a pair of 8-3 bit encoder chips to get the required values in hex. The following table shows the table reordered based on the AGC bit values.

The two high order bits of the AGC value designate the chip number (1-4). The three low order bits are fed in as the value to decode. Each output line is given a designation based on the expected output hex value (L1-L15). These values are then fed into one of two encoder chips. One chip generates the values with the high order bit of zero and the other with a value of one. The logic of both chips is negative logic. The “active low” output line from the 74138 chips (Y0-Y7) are fed into the “active low” input lines of the 74148 chips (I0-I7). The resulting hex value is a combination of which chip is being used followed by the 3 digit value.

Now that the data is decoded, each of the value pairs are stored in an 8-bit register. There are 11 registers to store the 21 values. To display the values, a timing pulse is generated that loops through the registers one at a time, feeding the values into 4 LED driver chips. I originally tried to squeeze the logic into three random access ICM7228 chips. The logic proved too complex. Upon reflection, I decided it would be much easier to use the natural address values of the relay words which would require a fourth chip. During the pandemic these chips fell into the category of “out of stock and no estimate of availability”. The only chips that were available were older, obsolete serial access ICM7218 chips. The downside of these serial chips is that the display digit values need to be stored external to the chip. This is because each time a value changes, all the values need to be re-written serially.

The digit enable numbers and their chip assignments are shown in the table below. Note that some addresses are not used, but are required given the serial nature of the chips. Also note that the values need to go into the chip in reverse. The DE column shows the reverse numbering, i.e. the numbering from the Display Control 154 chip.

These LED driver chips require 17 pulses to load them. The first write pulse sets the mode. Since this is the same value for each chip, one pulse will be applied to all four chips. The next 8 pulses set the first two chips data values and the following 8 pulses set the second two chips data values. This logic requires a 5-bit counter. Since there are many 4-bit counters, I chose to add a flip flop to be the fifth counter bit. Since not all the states are required and to take advantage of a single 4 to 16 bit decoder chip, I use the following states.

The OUTDAT pulse is as fast as 1 MHz which is much faster than the 2 Khz cycle timer to update the display and they are out of sync. To get them in sync one flip flop is used to capture the pulse. A second flip flop is then used to sync the signal. This is then used to start the counter and avoid a spurious write pulse. There are also two flip flops to represent the 5th bit of the counter. The first one captures the TC signal from the counter chip. The TC is set when all four bits are one. The next flip flop is set up as a toggle and toggles the next cycle, thereby changing to a one state when the counter goes to all zeros.

The DSKY consists of three boards. The front board is a solder board containing the astronaut facing keyboard, display and indicator lights. The middle board and back board are wire wrap boards. The middle board contains the four LED driver chips and the logic to drive the required data pulses. The back board is the majority of the logic.

Up to this point I have been in my comfort zone, having spent my career as a software developer.  Now it is off into the unknown of hardware development.  The first thing I need is a good schematic drawing tool.  After some research I decided to use KiCad.  It is free, easy to use and seems to be what all the cool kids are using.  

Note that all my schematics are out on my GitHub site at https://github.com/bglasford1 under the AGC Block II Computer project in the schematics directory.  I chose to divide the project into five sub-systems; DSKY, Control, Processor, Memory and Display.  The DSKY sub-system consists of the Keyboard, Display and Indicator modules.  The Control sub-system contains the Clock, Scalar, Timing Pulse Generator, Sequence, and Control Pulse Matrix modules. The Processing sub-system contains the Arithmetic Logic Unit and Central Register modules. The Memory sub-system contains the Erasable Fixed Memory, Memory Buffer, Parity, Memory Address, Interrupts and Counters modules. The Display sub-system contains the Monitor module along with all the LEDs and switches from the Control, Processing and Memory sub-systems.  The basis for splitting the modules up into sub-systems was to group like modules and to evenly divide them onto individual boards based on initial chip count.  

I first had to create some data flow diagrams to visualize how this beast would be wired together and what pieces relate to other pieces.  The data flow diagrams depict how the buses and registers interact with the control signals. The registers and logic blocks are rectangles and the bus drivers are round-tangles. The control signals that drive data into/out of registers and bus drivers are shown. The bus drivers and registers that are activated by the CLK1 pulse are colored green, the ones activated by the CLK2 pulse are colored yellow and the ones activated by the CLK3 pulse are colored cyan. This allows a quick visualization of the multi-stage data flow control during a single timing pulse.

The following data flow diagram shows the overview of the control sub-system which includes the Timing Pulse Generation, Sub-sequence and Control Pulse Matrix modules as well as the Clock and Scalar modules. The Clock and Scalar modules simply create various clock pulses. The Timing Pulse Generation module uses a slightly delayed CLK1 pulse to transition between 12 timing pulse states as well as a few other debug states. The Sub-sequence module maintains the parts that make up the next instruction, to include the stage, sequence and branch values. These along with the timing pulse state are fed into the Control Pulse Matrix module which uses these values to look up the control signals from the control pulse matrix EPROMs. These control signals along with other internally generated signals cause the other modules to perform actions. These control pulses are generated during the rising edge of the CLK1 pulse. The other modules act on the read control signals immediately and delay the write signals until the start of the CLK2 pulse.

The Timing Pulse Generator is a state machine that controls the states a sub-sequence goes through. This includes the start up states and states that allow one to debug the system. Many of the states loop back on themselves, waiting for a specific input to transition them to the next state. Once in the TP1 state, the state machine transitions through to TP12 each clock pulse. The intermediate states are not shown for clarity. At TP12 the state can transition to a wait state if a breakpoint is set or to standby if the standby switch is set or loop back to TP1 if free running. Notice that if none of these states is set it simply transitions to the wait state. The wait state is preceded by the Switch Release state. Under each state name is a number that is the internal numeric depiction of the state.

The following data flow diagram shows the memory logic and how various memory modules interact and how they are controlled by control pulses. The data written to certain values (020, 021, 022 & 023) go through shift registers before being written to the G register. All data moving onto and out of memory goes through the G register.

The following data flow diagram shows how the various modules that make up the Arithmetic Logic Unit interact and how the control pulses manage the logic. The X and Y registers are used as inputs to the adder that adds the two values. The results of the adder and the B register can be manipulated in various ways using a set of ALU chips. The output is considered the U register.

The following data flow diagram shows how the pieces of the Sub-sequence module interact and how the control pulses manage the logic. The Sequence register is the opcode of the next instruction unless a PINC sub-sequence or an interrupt occur. This value along with the Stage register are used to determine the next instruction sub-sequence to run. The branch values are used by the Control Pulse Matrix module to determine the next control signals to assert.

The following data flow diagram shows how the manual switches are used to read data from a given memory location, write data directly the memory bus and to check to see if a breakpoint address has been reached.

The following data flow diagram shows the counter logic. When appropriate, a runPINC control pulse is generated. This signal causes the PINC sub-sequence to run which increments the actual counter. Counters 1, 3 & 4 are incremented every 10 milliseconds when the F10X control pulse is asserted. Counter 2 is incremented when counter 1 overflows. The counter address is generated when the RSCT control pulse is asserted. This address is the address of the counter to increment.

The following data flow diagram shows the interrupt logic. There are three interrupts that can occur; RUPT3, RUPT4 and RUPT5 (keyboard data). The waiting interrupts are saved in the RPCell. When a RRPA control pulse is asserted, the current interrupt address is generated. This is the address of the jump table within the code. Interrupts can be inhibited.

The following data flow diagram shows how the DSKY is used to read data from the keyboard and write data to the 7-segment LEDs and the indicator lights.

I won't show pictures of each of the pages of schematics.  There are over 100 pages.  If you are interested, load up KiCad and give it a try.  Currently the DSKY, DISP and MEM sub-systems are out there.  I have sketched out the CTL and PROC sub-systems but have not yet published them.  Here is one schematic page, the Keyboard.

What sent me down this path was when I was looking for an historically significantly computer to build. I found John Plutorak's implementation of the AGC Block I computer.  This was what I was looking for.  I decided to push the boundary by focusing on the Block II version as that is the version that landed men on the moon.  John built a hardware based simulator, but he wrote it in C and I much prefer Java.  

I built a simulator that runs Block II code and provides a nice GUI interface to execute the simulation.  The input files consist of the following S-Record files; the CPM files, the machine code file and a sub-sequence file.  

Here is a screen capture of the simulator GUI.  Notice that there are sections that simulates the DSKY, namely the Keyboard, Indicators and Display.  The Control section is used to control the simulator.  The help menu has an explanation of how to control the simulation.  You can step through individual instructions, through each sub-sequence or even step through the timing pulses.  After I got a few instructions working I realized I needed to set a breakpoint and let the simulator free run to that point.  You can also break on a specific interrupt or counter increment.  There are Sim States that give you insight into the state of the running simulation.  The remainder of the sections are the actual registers and key memory locations within the computer.  As instructions are executed you can see how each register is affected. This screen is going to translate into a whole lot of LEDs.

As before, all the source code and files required are out on my GitHub site.

Ron provided an assembler and all the available assembly listings.  People went to museums and hand entered the assembly code and verified it by assembling the code and running it through Ron's simulator.  That was a HUGE effort and HUGE thanks to everyone involved in that effort.  

All I did was extend the assembler by adding an option to output the machine code in a Motorola S-record format.  I use this output file as an input into my version of the simulator and as input into my ROM burner to burn the code into an EPROM for the hardware I am developing.

My modifications to Ron's assembler can be found on my GitHub site at https://github.com/bglasford1 Under the AGCBlockIIComputer project there is a YUL directory that contains my modifications.  The original assembler was named YUL because they had a Christmas deadline.  You can recreate the assembler I am using by first downloading Ron's yaYUL code and then adding my modifications to it.