More Imlac Progress

After looking at the Power Supply Regulator schematic I decided to live with my hack to the P/S READY signal for awhile and spend some more time debugging the CPU.  I'll return to the power supply later (much, much later) but for now it runs well enough without it to do some other investigations.

Let's see... where did I leave off two months ago before I was sidetracked by the supply issue?  Oh yeah:

Any instruction that references a memory location (either a read or write) will end up causing its contents to be incremented by one. 

So, I put on some MST3K ("Diabolik," -- deet deet dah!) and got to work.

There's only so many things that can reasonably cause this behavior.  The Memory Buffer control board (for bits 8-15) has a single input explicitly to enable this behavior.  This is used for ISZ instructions and indirect increment register (memory locations 10-17) accesses.  Thus it seems reasonable to assume that this signal is being raised inappropriately, likely for every instruction but only impacting those that actually touch memory during their operation.

I whipped up a quick program to test the behavior, meant to be single-stepped through while watching on the logic analyzer:

0 CAL    ; 100011
1 ADD 3  ; 064003
2 JMP 1  ; 010002
3 000001 ; constant to add to AC

Verifying with the logic analyzer showed that the increment input to the Memory Buffer was indeed high.  On the Memory Buffer schematic (Board 213) this is the "C(MB)+1 => C(MB)" signal and it's generated by board 207 (The "CP, MB, & MA Cntl" board).

I checked the logic on Board 207 and it was clear that one of the inputs, the "ISZ & EXEC" signal was being raised when it clearly shouldn't have been (the CPU was not executing an ISZ instruction). This signal is generated by Board 226 (the "Instruction Register & Decoder" board).  The related portion of the schematic is below:

The portion of the Instruction Decoder responsible for the ISZ instruction

The Imlac uses a pair of 7442 BCD to Decimal decoder chips in a clever way to decode instruction words; an ISZ instruction causes D6 on the 7442 to go low.  Testing revealed that the 7442 was fine, but the input to the 7420 at A1 (pins 12 and 13) looked very very odd:

Odd ISZ signal behavor, GRAPHICALLY PORTRAYED!!!!

As you can see, once EXEC (measured at pin 9 at A1) goes low, the ISZ signal (as measured at pin 12 at A1) does a fun little jitter before it finally decides for some reason to go high.  This shouldn't happen since the ISZ signal from the 7442 isn't changing.  Based on this, it's a fair guess to suspect that the 7404 at D3 between the 7442 at C3 and the 7420 at A1 has basically gone insane.

After replacing the 7404, the test program executed as expected.  Huzzah!

At this point, the CPU seems to be working pretty well, though I will have to spend some time going through all the instructions to look for anomalies.

Since things were looking up, I decided to do a basic test of the memory.  I assembled a quick program (very similar in behavior to the one I used on the 8/L):

00    060031  ; LAC Value   ; Load test value
01    120030  ; DAC I Addr  ; Store it
02    160030  ; LAC I Addr  ; Read it back
03    070031  ; SUB Value   ; Compare with test value
04    002001  ; ASZ OK
05    000000  ; HLT         ; Memory does not match, halt
06    030031  ; ISZ Value   ; Test next value
07    010000  ; JMP Start
10    030030  ; ISZ Addr    ; Value overflowed, test next Address
11    010000  ; JMP Start
12    004100  ; LAW 100     ; Start over at 100
13    020030  ; DAC Addr
14    010000  ; JMP Start

30    000100  ; Addr
31    000000  ; Value

As an aside, you might notice how much shorter this is than the 8/L test program even though the two operate in exactly the same way -- 21 words for the 8/L vs. 14 for the Imlac.  The Imlac's instruction set is a bit more rich than the 8/L's due to the wider instruction word, allowing for more compact code.  You may also notice a problem with this program -- it tests the entire 16-bit address space (64K) which of course I don't have (and no Imlac ever had), so it'll halt once it runs off the end of installed memory (8K in my case).  I was going to correct this, but it became clear pretty early on that a fix could wait.

Running the above program has revealed that there are a few problems with the core memory.  Most addresses test out fine but there are a few here and there that fail sporadically.  Some fail under test but seem to behave fine from the front panel, some seem to have a few bits stuck off at all times.  In general, these bad addresses are not contiguous and are spread all over the address space without any apparent pattern.

This could point to improper alignment (which would not surprise me in the least given the original state of the memory boards) or there could be actual physical defects.  I pray it is not the latter, as these sorts of defects are basically impossible to repair.

I will have to do a deeper analysis of the failures to see if patterns emerge (indicating failures with address decoding or X/Y drivers).  I also need to read through the documentation to see what alignment and diagnostic procedures it recommends.

I think that's probably enough for this evening.  Until next time...