In my last post VT100 RAM Fault I reported progress on fixing my VT100, getting past a RAM fault, but I left it with a fault where the keyboard constantly clicked the speaker. I knew the keyboard was OK because it works with my VT102.

The Basic Video Board communicates with the keyboard using RS232. There is a UART on the Basic Video Board and another UART in the keyboard. The firmware sends commands to the keyboard using a status byte that is described in the technical manual. The status byte controls the speaker click, the LEDs and the scanning for keypresses.

I wondered if the firmware was not operating correctly, perhaps trying to signal an error. I found a wonderful page that annotates the firmware really well. It looked like perhaps the firmware was getting into a loop trying to sound the speaker. The firmware uses a counter in the BC register to sound the speaker at the start and I could see from address traces that while it is doing this the vertical frequency interrupt is occurring. The interrupt routine saves the BC register on the stack and it looked like perhaps the RAM was not working correctly and corrupting BC. However some further analysis with the logic analyser showed that the RAM was working correctly at that stack location. While tracing the execution of the firmware I also found that it is detecting an NVRAM failure.

I moved on to look at what data the UART is sending out to the keyboard. I set up the logic analyser to capture the parallel inputs to the UART (labelled XD0-XD7 on the schematic) and triggered on the rising edge of LD XD. The data I saw being sent seemed completely reasonable. It initially sent 0xA0, which clicks the speaker on start up, and then it went into a cycle of sending 0x20 with the odd 0x60, which means it is turning on the on/off line LED and scanning for key presses. This seems perfectly normal and expected.

I then used the logic analyser on the UART in the keyboard to see what it was receiving. This data did not correspond at all to what the UART on the Basic Video Board was being asked to send, it was garbage. Clearly this implicated the UART on the Basic Video Board. I checked the components between the UART output and the final output on the keyboard port and they seemed OK.

Because I have jumped to incorrect conclusions many times before I decided I would do what I could to verify this. My Rigol DS1054Z oscilloscope is capable of capturing RS232 data. First of all I made sure I had it setup correctly by using it on a working VT102. I found that I needed to set a bit rate of 7866bps, I had to set the non-default polarity, and most significant bit first. With this I was able to capture reasonable data from the VT102, although it wasn’t perfect, the timing seems to vary a bit so I got framing errors after which the data would appear wrong for a bit and then correct itself. I also checked the clock signal to the UART on the VT102, it was variable, sometimes around 126KHz and sometimes 106KHz, which I guess accounts for the framing errors I saw.

I then used the oscilloscope on the non-working VT100. The clock signals to the UART mirrored those of the VT102, but the data captured by the oscilloscope being sent down the wire was completely different.

I also tried to use a HP4957A protocol analyser, but this wouldn’t let me set a custom bit rate, so I was not very successful with it.

At this point I decided I didn’t have much to lose so I replaced the UART (marked D3-6402-9) with another one.

I am pleased to report that this cured the constant keyboard clicking. So now I have two problems left. The main one is that there is nothing displayed on the screen, I don’t see any glow from the cathode on the CRT, so possibly there is a fault on the video monitor board. This will be the next thing I look at. The other problem is the possible failed NVRAM, but I think I will look at that if I can fix the lack of a display first.