30
- Vector 4 Keyboard
Vector 4 Keyboard
I have a Vector 4 manufactured by Vector Graphic, Inc. It's an old machine from the 80s that happily still runs. Or at least one out of two I have still runs.
I've been on a long escapade trying to preserve the device as there's very little information archived for it online. This has included adding hard sector and Micropolis support to FluxEngine and hard sector support and async I/O handling to FlashFloppy.
In 2020 I was trying to use the machine and the keyboard wouldn't work. The keyboard has foam pads with one conductive side and the foam had disintegrated. Thankfully other keyboards from the era, much more common than mine, have suffered the same fate and TexElec sells replacements. They are a bit finiky so some keys won't work and I have to reopen the keyboard (with over 20 screws) to fiddle with the pads. But all the keys are currently working. Great.
But the keyboard isn't that great to type on. It works, but pales in comparison to cheap keyboards today. How hard would it be to make an adapter to use a "modern" USB or PS/2 keyboard? The keyboard's operation isn't documented anywhere to my knowledge, but I figured it'd be quick to reverse engineer.
The keyboard connects to the computer with a 6P6C connector, and a board in the machine has helpful labels. The 8P8C connector is on the bottom left; ignore the pin numbers, except pin one.
Following the traces, we get:
Pin Assignment 1 GND 2 GND 3 GND 4 +5V 5 S OUT 6 S IN "S" would clearly mean serial, and there's no separate clock. Maybe it'll be like RS-232. Now let's take a look with a logic analyzer.
Typing is at least mostly a one-way protocol. Pin is high during idle. Comparing for more button presses made the encoding clear. 0 is low, 1 is high. The bit rate is 300 Hz. It starts with a 0 bit, has 8 data bits with LSB first, and stops with a 1 bit. Data bits are ASCII characters. When holding down a key, presses are 71 ms apart. There's no obvious source of queuing, so it'd be hard to have two letters nearer each other. My key presses are buffered, so I guess it is queued on the computer and not the keyboard. I'm not aware of an easy way to overflow that buffer as it seems to be greater than ~30 characters large. Wow. That was easy.
Now can I make a keyboard emulator? I figured I'd start with a Raspberry Pi Zero W to make entering text easy over wireless. Python should be easy, and 3ms timings seem like something it could probably handle. A quick script later and... it doesn't work. Looking at the logic analyzer shows really bad timing. Oh well... let's port it to Go. Surely a quick go program will work. Nope. Still poor timing. Much better. But not good enough. Busy looping and nice levels didn't help. Shucks.
Well, I was wanting a project to use a Raspberry Pi Pico. It has micropython; I wonder what that's like. A quick port to micropython and... it works! The computer displays "KBD error", but the keyboard works regardless.
What's the point of S OUT? Just after cold boot starts the computer sends 0x08 (BS?). But there's no response. Later the computer sends 0x10 (DLE? surely not), the keyboard replies 0xAA, and the computer sends 0x02 (STX?). That exchange seems to be the KBD test and can be triggered separately with a 'T' Test mode instead of the normal HDD or FDD bootup. The keyboard beeps during this exchange. After pressing 'W' to choose to boot from the "Winchester" HDD the computer sends 0x02 (STX?). Also no response. Seems S OUT data is some custom meaning and just uses powers of two. The 0xAA response has alternating bits so is good for testing.
The Raspberry Pi Pico isn't 5V tolerant, so I won't bother any more with S OUT. USB or PS/2 can be for some other day, but it is quite feasible.
In a follow-up post I make the adapter.