Communication Breakdown (Part 2)

After resolving the issues with the TKA serial port (well, at least in theory until the replacement chips arrive) I turned my attentions to the TTY serial port.  Neither transmit nor receive functions were working at all; specifically:

• Transmitting of data via TPR and related opcodes fails.  No data is sent, and the "TTY Output Status" flag (used by the TSF/TSN opcodes) never gets set.
• Receiving data via RSF and related opcodes fails (what gets read is always zero).  The "TTY Input Status" flag (used by the RSF/RSN opcodes) is always set.

I started my investigations with the Transmit side of things.  I had a hunch that something might be wrong with the clock signal based on the behavior of the Output Status flag; since it was never getting set after a Transmit operation, the Transmit board's state machine was clearly not running properly.  This state machine is clocked by a 5Mhz signal generated from a crystal oscillator on the Receive board, and then divided down by a 16-bit counter on the Transmit board.

The full Transmit Board Schematics

Looking at the above schematic, you can see that there are four 74161 4-bit counters at the lower left:  This is the aforementioned 16-bit counter.  The 74161 at A3 has both its Clock and Enable inputs (pin 2 and 10) connected directly to the 5Mhz clock (pin 67 of the card edge), so it gets clocked at 5Mhz.  The other three are clocked by the "Carry Out" signals of the preceding counter in the chain:  A3, B3, and C3 have their "Carry Out" signals (pin 15) tied to the Enable inputs of the next counter in the chain.  D3's Carry output is connected to the "Shift Clock" logic (see the upper-middle of the schematic) and this logic controls the three 7495 4-bit Shift Registers at C1, C2 and D2 that contain the byte being sent plus up to two stop bits.  Each time the Shift Clock signal clocks, the next bit is shifted through pin 10 of D2 and sent over the wire.

Thus, the 16-bit counter formed by the 4 74161s is used to divide down the 5Mhz clock into a clock rate suitable for RS-232 communications.  The divisor is user-configurable (via soldering iron).  The inputs to the 74161 (TT0-TT15, see the lower left of the schematic) are brought in from another board, pictured below:

The "Comm Speed Select Board"

The orange wires on the right each control a single bit of the input to the 16-bit counter, either "High" (1) or "Low" (0) as designated by the etching at the top of the board.  The above board's wired value is 57203.  Each time the 16-bit counter overflows (reaches 2^16, or 65536), it will be reloaded with 57203.  This means that for every clock from the 5Mhz input, 65536-57203 (or 8333) clocks must take place before the 16-bit counter overflows and clocks the Shift Clock logic.  5,000,000 divided by 8333 comes out to 600.02, which is two times the expected 300 bits per second rate.  I believe this is because each output bit is actually transmitted for two divided clock cycles before a shift takes place but I have not confirmed this.

Back to the investigation:  The 5Mhz clock signal looked fine, so I traced the signal down the chain. The carry outputs from A3, B3, and C3 looked fine, but D3 never changed.  Well, that would explain quite a lot, if the divided clock never runs then nothing at all will ever happen.

I replaced the 74161 at D3 with a spare and the Imlac was now able to transmit again!  On to the Receive logic.

The programming-level issue with the Receive logic was kind of the inverse of the Transmitter's problem:  The "Data Ready" flag was always set, even when nothing had actually been received.  Reading from the Receiver always came back as all zeroes.

The full Receive Board Schematics

On a hunch I decided to start looking at the problem by examining the data getting clocked into the 74161 shift register at C4 (see the lower-left of the above schematic).  It was all "1"s, all the time -- so the Receive logic thought it was constantly receiving a stream of "0" bytes over the wire.  The shift register input comes out of the 7408 AND gate at B2, which combines the current loop and EIA (RS-232) inputs.  The inputs to the 7408 were fine, but the output was always high.  I replaced the 7408 at B2 and the Receiver started working again.  (Ok, not quite -- the same bits are stuck off as with the TKA Receiver until the new 74H52s arrive and are they ever taking their sweet time to get here...)

So, the Primary (TTY) serial port is working again!  That wasn't too painful at all.  Next time I'll look at the Keyboard input, but until then: Earn good money selling Grit!