Solving the last of the obvious faults

About time for another update, I'm overdue.  And this'll be a relatively quick one, but there is some good news.

At the time of the last blog post there were three known faults left with the main CPU (at least the faults that can be detected by playing with the front panel and having no memory):

Memory Buffer:  Bit 1 behaves oddly (will only turn on if Bit 0 is also on)
Program Counter: Bit 15 does not load correctly.  Loads as a 1 when set to 0 and bit 14 is incremented when a 1 is loaded into bit 15.  The register increments correctly, however.
Memory Reads:  Bit 1 is always stuck on when a read is done from memory (either from the Diode ROM or from non-existent memory elsewhere).

The Memory Buffer problem turned out not to be a bad 74H52 as I suspected.  After replacing the chip there was no change in behavior.  I replaced the original chip and looked at other culprits.  The real issue was a bad 7495 at B2, which I probably should have noticed to begin with.

The problem with the Memory Reads was clearly not due to any problem with the Memory Buffer register -- moving the boards around did not move the stuck bit.  The only other option was the Memory Output Buffer board, at position 114 (or 111 in the schematic, my machine varies a bit from the schematics in places).  Inputs to the 7403 at C1 looked to be fine, but the outputs were always 1.  Replaced the 7403 and bit 1 was fixed.

I spent some time poring over the schematics trying to figure out the issue with the PC register.  My initial description of the problem is accurate but there's a more obvious one:  The PC that gets loaded is the address switches + 1.  From the schematics, this almost seems to be intentional, but I'm not 100% sure yet.  (And the user manuals I have of course do not cover the operation of the front panel.)

So, two problems are fixed and one problem turns out to potentially not be a problem.  That's pretty good!

I realized I hadn't checked the Display Program Counter register.  This register can be viewed from the Control Console, but cannot be modified with it.  However, it uses the same boards as the Program Counter, so by swapping them around I can do basic testing from the console.  Turns out bit 11 is stuck on on load, but will change on increment.  This indicates that the 74161 shift register and the other chips on the other side of it are probably OK.  Which means that (surprise surprise) the most likely culprit is a bad 74H52 at D1.  And so it is.  Pulled the old chip, installed a new one and everything's golden.

At this point, I discovered another problem:  If the Data switches are set to 0 and a Store or Store Next operation is invoked from the Console, both the Memory Address register and the Program Counter register are incremented by 2 (instead of 1) every time a Read or Store operation is invoked from the front panel.

This is pretty odd behavior, and it took me awhile to track down.  The MA and PC register are basically tied together on Store, so that explains why both are affected in the same way.

The PC register supports an increment operation, which is invoked either under normal program control (i.e. to support normal program execution) or by the front panel (during a Read Next or a Store Next operation).  This increment is performed by the four 74161 counters -- the carry out of the first counter is tied to the "Count" input of the next, and the first counter's "Count" input is tied to logic that controls when increments take place.

If you look at the schematic, this input is provided by the "B, MB, MA, PC Control" board in slot 207.  Tracing the signal back a little ways lead me to the 7410 Triple-Input NAND gate at E4.  There are three inputs to this gate.  One is triggered on the T6 timing cycle from the CPU control, so it's expected that this input would go high during a load or a store.  Another is the output of the "ALU=" signal from the ALU.  Since the Data switches are 0 when this issue occurs, this input will also be high during a load or store (and this explains why the issue only occurs when the Data being stored is 0.)  The last input is the "SAM & EXEC" input from the "Instr. Reg & Decoder" board at slot 226.  There's no reason this output should go high during a load or a store operation -- the CPU is not running, and it is not executing a "SAM" instruction.

So, board 226 looks to be the culprit.  This board uses a pair of 7443 BCD decoders in a clever manner to decode instructions, the "SAM" output is derived from one of its outputs, but the outputs look OK (they are always low).  This leaves only one possibility: the 7404 inverter at B3.  Sure enough, when other inputs on the same chip (there are 6 inverters per chip) changed, the SAM & EXEC output from the chip went high, even though the associated input was also high.  I replaced the 7404 and now Store operations work properly again.

At this point the registers were all behaving properly, so I thought I'd try executing the code in the Diode ROM.  There's no working RAM in the machine, but the ROM should still execute, if the CPU decoding and control logic is functional.  Amazingly, it does appear to be executing correctly -- at least well enough to execute a simple loop waiting for TTY data to become available.  I'll take that as a good sign, and as a good place to stop for the day.

From here, I'm going to need to get the core memory system running so that I can run diagnostic programs in order to test the CPU further.  I'm not expecting that to go smoothly.

That's all for now.  Hm, so much for this being a quick update... Until next time:  Be the ball.