May 2019

Finally, a working keyboard

As promised I got the new, simplified keyboard interface working this weekend. This means that COLE-2 can now operate as a fully standalone computer; no serial console needed. Of course, it’s still not terribly useful, because the only thing in ROM is the system monitor, but it’s a good start!

Overall I am very happy with the new design. It’s more or less what I described in my last post, with one small exception. In the new version, pressing one of the toggle keys (CapsLock, NumLock, and ScrollLock) is still handled inside the AVR. When a key down on one of those keys is detected, it will toggle the LED state, and then send the BIOS either a key down or key up code, depending on the new state of the LED. In other words, as far as the BIOS is concerned, the toggle keys are just regular modifier keys, albeit ones with longer-than-normal key down times.

Mouse and game pad support are not yet implemented, though the new firmware is driving both PS/2 ports now. These features, and some improvements to support hot plug and device detection, are on my list for future development.

With the keyboard finally working I’m going to bite the bullet and start cleaning up the BIOS. Specifically, I need to nail down a formal API and drive model so that I can start working on the OS and the BASIC interpreter application. We’ll see how that goes. 🙂

Updates from AVR Land

Well it took about two weeks longer than I had planned but I finally have a PS/2 keyboard implementation!

My design places the bulk of the processing on the AVR itself; it decodes the variable-length PS/2 scan codes and translates them into single-byte key codes. The AVR sends all key-down events to the BIOS along with the modifier key state at the time. The key codes it sends are a super set of ASCII; codes with the high bit set are special keys that don’t have an ASCII equivalent (such as the Fn keys). It also maintains the keyboard LEDs when the user presses one of the toggle keys (Caps Lock, Scroll Lock, and Number Lock).

The Bad News

Unfortunately, my design is not very reliable.

The first problem is that I see odd garbage key presses occasionally. The AVR PS/2 receive code does not yet check the parity bit, so it’s quite possible these key presses are due to transmission glitches.

The bigger problem, however, are the hard freezes. After enough typing on the keyboard the system will eventually freeze until I reset the AVR. When this happens the AVR is still working; pressing any of the toggle keys such as Caps Lock will properly update the LEDs. That means the AVR is successfully receiving and decoding keys, and is able to send commands to the keyboard. The breakdown appears to be in the communication link to the rest of the system.

Back to the Drawing Board

My current implementation was an interesting experiment, but I feel like it may just be too fragile to ever be fully reliable. I need something simpler, even if it means making some sacrifices. So I’ve come up with a new design.

My new design is focusing on the keyboard, mouse, and game pads (yes, I’m moving those back to the AVR). Here’s a rough diagram:

The data link to the VIA has been reduced to a unidirectional link driven by a 74HC595 shift register. This frees up six pins and allows me to move the PS/2 clock lines onto the INT0 and INT1 lines (PD2 and PD3). These two lines give me more reliable detection of clock signal transitions. It also means there are enough free lines to move the game pad support back onto the AVR.

In this updated design the AVR will still decode the PS/2 scan codes into key codes, but it will no longer act on any of them; instead they will just be fed directly to the BIOS for further processing. Mouse data will come to the BIOS preceded by a special prefix byte, and the AVR will continuously scan the game pads and present those as key up/down codes as well.

BIOS to AVR Communication

If you’ve been paying attention you may be wondering what happens to the keyboard LEDs now, since all of the key state processing has moved to the BIOS and there’s no reverse comm channel in my diagram. I have two ideas for this; one is to use the VIA’s shift register, and the other is to use the second channel on the system UART.

Using the VIA shift register would give me a moderate-speed channel back to the AVR, over which I could then send commands to either the keyboard or mouse. I have no other plans for the shift register so this could make good use of some otherwise idle hardware. The draw back, however, is that it does not support any sort of framing or error checking so even one missed bit would throw the whole thing permanently of out sync. Since I’d be implementing the AVR side entirely in software I cannot rule out missing a bit here and there.

The UART channel is my preferred choice at the moment. I would be giving up the second serial port, but I would end up with a much more robust link. The framing bits would keep the link in sync, and the AVR has a hardware UART built-in so I wouldn’t even need to implement anything in software other than a handler for the data.

SPI

In all of this talk about the new design I’ve neglected to mention the hardware SPI functionality. I was fully prepared to sacrifice this feature in the name of simplification and reliability, but when I started thinking about hooking the AVR up to the UART I realized i can still have my SPI. Indeed this may actually be a better solution than my original design; I already have fully interrupt-driven serial support in the BIOS, and so long SD card block reads and writes can be streamed to and from the AVR entirely in the background. It’s sort of like a poor man’s DMA.

Next Steps

I’ve already implemented most of the hardware changes for this design (everything is done except the serial link). I’m also 75% of the way done with the AVR firmware changes. By this weekend I should be able to type on the keyboard again, hopefully with greater reliability than before.