Communication Breakdown (Part 1)

Now that I have the Imlac's CPU and memory running well enough to attempt running basic diagnostics, my plan of attack for the rest of the work is roughly as follows:

1. Investigate the functionality of the Imlac's I/O devices, and get them working again where necessary.
2. Use the I/O devices to upload more advanced diagnostics from a PC.
3. Repair remaining CPU issues
4. Repair remaining Memory issues
5. Get the Display Processor working properly
6. ...
7. Profit!

I've spent a few evenings over the last week or so working on step #1 in my nefarious plan.  My Imlac has four I/O devices fitted: Two asynchronous serial ports (RS-232 or Current Loop), one synchronous serial port, and the Imlac Keyboard input.

In order to move onto step #2, it will be necessary to have at least one of the two async serial ports working, though unless I find a good reason I'd like to take the time to make sure that both of them are working.  The synchronous serial port is interesting but I don't have anything else that can talk to it (and I have no documentation for it either) so it's going to go untouched for the time being.

Testing the keyboard input isn't strictly necessary at this point but since I'm looking at the I/O devices I might as well cover it.

To test out the basic functionality, I coded up a couple of quick test programs to exercise the serial ports' "transmit" functionality.  For the "primary" (TTY) port this is:

0  TCF      ; 001042
1  LDA      ; 100041
2  TPR      ; 001041
3  TSF      ; 002100
4  JMP 3    ; 010003
5  JMP 0    ; 010000

and for the "secondary" (TKA) port this is:

0  IOT 242    ; 001242

1  LDA        ; 100041
2  IOT 241    ; 001241
3  IOT 224    ; 001224
4  JMP 3      ; 010003
5  JMP 1      ; 010000

The above programs continually read the contents of the console Data Switches into the Accumulator and transmit them over the serial port.  The TTY port was completely unresponsive, and the program would sit in the loop at 3/4 forever waiting for the transmit to complete.  However, the TKA port happily transmitted data -- and at 9600 baud.  I was expecting 300, so this was a nice surprise.

Since the TKA port could transmit, I decided to see if the receiving end was working as well and I coded up the below:

0  IOT 242    ; 001242    ; clear xmit
1  IOT 232    ; 001232    ; clear rcv
2  LAW 0      ; 040000    ; clear AC
3  IOT 204    ; 001204    ; skip on rcv
4  JMP 3      ; 010003
5  IOT 231    ; 001231    ; read
6  IOT 241    ; 001241    ; xmit
7  IOT 224    ; 001224    ; wait for xmit
10 JMP 7      ; 010007
11 JMP 0      ; 010000    ; again! again!

This waits for a byte to be received, and when it is, it retransmits it back, effectively "echoing" it back to the source (a laptop PC in this case).

This did not work so well.  Numerous bits were apparently stuck off (sending a lowercase 'a' (0x61) would echo back an '@' (0x40) to the PC).  Strangely, and for reasons I still do not understand, running the PC at 300 baud worked fine in both directions.  This threw me off for quite awhile and I do not yet have a rational explanation for how this could possibly work, as the TKA port is clearly wired at 9600 baud (and I've verified this baud rate via investigation with my oscilloscope).

I thus spent quite a bit of time looking over the Async Receive Board (board 327 in the schematics).  Weirdly, everything looked fine -- the data coming in looked fine, the clocks were clocking, the shifters were shifting, the buffers were, you know, buffering...  At the last stage of the output from the board there is a set of 7403 open-collector output NAND gates and at this point the data turned into garbage.  Replacing the 7403s made no difference.

The outputs from the 7403s are wired into a simple "bus" of sorts, used as one of several inputs to the Accumulator register.  The other end of this bus is on the "Accumulator & Input Mixer" boards, occupying slots 219-222 (4 bits each).  These boards have a set of pull-up resistors to complement the open-collector outputs on the I/O boards themselves.  Other I/O devices use this bus to allow reading a single word of data into the Accumulator, and only one I/O device is supposed to put data on this bus at a time.

So the thought occurs:  Well, maybe another device has gone crazy and is using the bus when it shouldn't be?

The answer to that turned out to be "no."  I removed other applicable I/O devices (which were the TTY serial port and the synchronous serial port) and the behavior remained.

I was stuck here for awhile, and I was completely distracted by the anomolous "works fine at 300 baud" behavior.  I spent a lot of time looking at signals on the logic analyzer.

It occurred to me that I could try swapping the "Accumulator & Input Mixer" boards around to see if the stuck bits moved around.  This seemed unlikely to make a difference, since I was sure the problem was with the bus; but sure enough, swapping boards 219 and 220 for 221 and 222 caused the behavior to change -- now only one bit was stuck (bit 6).  So the problem wasn't with the bus after all, though I'll have to add the odd readings I was getting on the logic analyzer to my list of unsolved mysteries...

At this point, it was clear the problem was on the Input Mixer side of things, and there weren't too many places the problem could be.

The Accumulator's ALU inputs

As a representational sample, the I/O bus input for bit 11 comes in on pin 64 of board 221 (shown above, bottom left.)  This is tied to the input on the 7400 NAND gate, which passes through a 74H61 before being combined at the 74H52 and sent to the ALU.

Investigating with the Logic Analyzer (which is quickly becoming my favorite device in the universe) showed that the 7400 was fine, but the outputs from the 74H61 at E4 were incorrect.  Similar discoveries were made on the other 3 Input Mixer boards, and at the end of the day, three of the eight 74H61s across all four boards had one or more outputs stuck low.

Of course, I have no replacements for these on hand (nor do any local electronics stores), so I've placed an order for some new ones and they should arrive in a few days.  Once they get here, the TKA serial interface should be working correctly again.

With that problem solved, I could now turn my attentions back to the unresponsive TTY serial interface, but that is another story, and shall be told at another time...