RetroChallenge Day 4: MBC020 video and troubleshooting

A while back, I tested out the video output on my new-to-me SYNERTEK MBC020 ExorBus SBC, and noticed problems with the upper half of the video. I wanted to make sure it was not my LCD monitor that was at issue so, I went out and bought a 9" black and white CRT security monitor to use for further testing. Unfortunately, when I recently went to connect it to the monitor, I could not get the MBC020 to boot anymore!

This is a good excuse to share some troubleshooting tips for these vintage SBCs.

With a multimeter or voltage tester:

1. Check the power rail voltage- this may seem obvious, but is an important first step, especially since these boards usually do not have any power indicators.
2. Verify that RTS or DTR goes low on the ACIA (or high on the serial connector)- This is a very simple check and you don't need an oscilloscope. If RTS or DTR goes low at the ACIA on boot, it indicates that the microprocessor is able to access ROM (to read the firmware) and the ACIA (to configure the ACIA), and is probably running OK. If it does go low but there is no activity on the serial connection then you may have a cable configuration problem, a terminal settings misconfiguration, or a problem with the RS232 driver ICs.
3. Verify that RESET goes high-

With an oscilloscope or logic analyzer:

1. Test clock signal to processor.
2. Test chip select signals to RAM, I/O chips
3. Test data bus and buffers

With this procedure I was able to pretty quickly determine that I had no clock signal to the CPU. After I swapped a few ICs in the circuit around the oscillator with no improvement it became apparent that the crystal was likely at fault. This problem seemed consistent with my nearly 2-year-old son knocking the board off of the dining room table a few months ago. I ordered the crystal and that brings us to now, the first week of RetroChallenge.

---

Replacing the crystal was pretty straight-forward, despite the large amount of solder on the board in that area. I did have to use a small drill bit to completely clean out one of the vias, but no big deal. I really dreaded turning the board on for the first time though. If the problew was something other than the crystal, I would be very stumped and my RC2023/10 would get stalled right out of the gate.

Fortunately, everything came right back to life! The CRT monitor initially showed the same skewed image as the LCD, but after some heavy adjustment to the vertical hold, I ended up with a nice clear display. Although everything seemed to be working, I did notice some spurious "E" characters popping up after a command is completed. I am not sure if this is normal, or some new fault in the board, but I do not recall it happening before.

With everyting up and running, of course I had to mess with video connector and sudddenly I lost video and the terminal stopped responding. I tracked the problem down to a blown 5V fuse on the backplane. I must have short-circuited something. Fortunately, I still have a few hundred fuses left over from when I first built the backplane, so a new fuse and little soldering got it working again. I think I would definitely make the fuses easier to replace if I make another run of these backplanes.

RetroChallenge 2023/10 Preview

This year for RetroChallenge, I think I will focus on some 6502 projects, mostly my Synertek MBC020 ExorBus board. I never got it working correcly as a terminal: skewed video and no keyboard yet. Let's see if I can get all of this working properly! This was supposed to be my project last year before I picked up a Radio Shack Micro Color Computer MC-10.

PS/2 Keyboard - the Retro Way!

I have seen a lot of overpowered PS/2 keyboard interfaces lately: microcontrollers, bit-banged PIAs, PIAs with shift registers. All sorts of complex solutions. Here is my simple contribution, using retro hardware.

It is important to note that the PS/2 protocol is basically just an isosynchronous serial connection with open-collector i/o. Isosynchronous is basically the same as the normal asynchronous serial connection, but there is also a clock signal. To simply implement this protocol, all we need is an ACIA or UART that supports a 1x clock mode and a buffer to make the signals open-collector. The 1x clock requirement rules out the common MOS 6551 (16X clock required), but includes many common alternatives such as the MC6850, Signetics 2651 and Zilog SIOs.

Next, the signals to the keyboard need to be buffered and converted to open-collector outputs. The 74LS05 open-collector hex inverter is a simple choice for this. Since this inverts the signals and the PS/2 data is already at the correct polarity, we need to invert the TX data signal 2x: invert the signal, pull it up, and invert it again. Here is an example for the MC6850:

Sorry for the weird orientation of the schematic; it is part of another project.

Notice that the clock from the PS/2 device is connected to the ACIA as the RxClk, but is also inverted, pulled up and used as the ACIA TxClk. The RTS signal from the ACIA can be used to pull the PS/2 clock low for commands to the keyboard (untested). The data line from the PS/2 device is pulled up and connected directly to the ACIA, while the command data to the keyboard is inverted twice with open collector output.

If you only want to receive data from the keyboard, you can just connect up the clock (to ACIA RxClk) and the data line (to ACIA RxData) through non-inverting buffers (to protect the ACIA). Too simple!

Once you have the data from the ACIA, you will unfortunately need to use a small lookup table to translate the PS/2 keyboard codes to ASCII. A small PROM on the data lines of the ACIA could also work, but you would also need a tranceiver to do writes to the ACIA and a decoder to make sure the data moves through the PROM or tranceiver at the right times.

The one issue with this technique is that when using the 1x clock mode on the MC6850, I think that the the ACIA needs one more clock cycle than the PS/2 protocol provides per byte to indicate that there is a byte available (this could just be an issue with my clock phasing though). As a result, the input buffer full flag does not get set until the start of the next byte. Unfortunately, this means you are always one byte behind the keyboard. That may seem like a non-starter, but in reality, it does not affect much because the proper key code does get sent when the key is released. So every key press/release cycle sends you:

[previous key code]...[key code][break code]

instead of:

[key code]...[break code][keycode]

So, the key code for the current key is available when it is released, or when repeating. Not perfect, but it is much simpler than many of the solutions out there. It definitely needs more testing, and I would love to hear your results. This makes me want to try interfacing with a PS/2 keyboard and a character LCD with a single ACIA.

MC6800 assembly available for a test program: