Convergent Technologies and Negative Serial


25 Dec 2019, 20:29

Converting this keyboard with lots of early '80s styling:
convergent.jpg (314.46 KiB) Viewed 1213 times
  • Metal case
  • Giant coiled cable
  • Big bezel (okay, medium for the time)
  • Green navigation legends
  • Stepped keycaps for some of these (but not for Lock)
  • Some odd action verbs (even including ACTION itself)
  • Eight keys with led indicators
  • Lowercase f-key legends
  • ¢ ½
It uses Micro Switch SD-series switches and so feels pretty good. HaaTa has one, but with a couple missing keycaps; this is complete.

All the tech specs are online, even a schematic. The only snag is that it uses negative polarity (idle low) TTL serial for the two communications lines.

The Sun keyboards were like that, too. The easiest way to deal with it is just bit-bang the serial protocol; it's only 1200 baud (Convergent is 1221, but close enough). That's what the QMK converter does. But it seems unsatisfying to waste the MCU's UART.

Second choice is add an inverter. That's what I did with my Sun keyboards some years ago after looking at the TMK predecessor of that one. (Honestly, now that the QMK build modularity is a lot better, I could probably just customize some macros to use UART serial and flash the QMK code onto my existing hardware, letting me retire another repo.)

In the meantime, the newer Teensy's with 32-bit ARM have UARTs with control registers to invert serial on chip. The Teensy LC (Cortex-M0) is even cheaper than the classic 2.0. Unfortunately, it's a non-starter because the I/O pins aren't 5V tolerant. But the Teensy 3.2 (Cortex-M4) is and that's what's on the Perma-Proto in the photo.

There don't seem to be any examples of using serial with ChibiOS in QMK. Moreover, there don't seem to be any working examples of using serial with ChibiOS period. There are lots of snippets in the forum, where the author also appears to be super-responsive. So, in the end, some experimentation and inspection of the source was needed.

The Kinetis contributed port of ChibiOS has a fairly minimal serial HAL layer. It doesn't expose the polarity registers, so they have to set by hand and not in the SerialConfig.

It took a while of nothing working to figure out that one must mux the UART pins explicitly through the PAL module. In Teensyduino, this just happens in Serial1.begin. But in ChibiOS, sdStart only configures the UART itself. (It also took a while to figure out that leaving INIT- unconfigured was a bad idea instead of actually driving it high.)

The working result is here.


30 Dec 2019, 19:17

Another project where I find myself wanting a slightly more powerful UART.

A Micro Switch ST-series board from 1987.
sc-37225-top-2.jpg (434 KiB) Viewed 1084 times
The keycaps are dye-sub and if it weren't for those APL legends (and proofreader's Insert and Delete and randomly stepped keys), I probably would have given this one a pass.

It has the usual Honeywell SC-23181 decoder for the membrane matrix. Its choice of an Intel MCS-48 processor is an 8048.
sc-37225-bottom-2.jpg (356.63 KiB) Viewed 1084 times
I have no idea what this board belongs to; this particular one looks to have been a spare and never used. Searching for the various catalogue numbers doesn't turn up anything, either. Does anyone recognize it?

There is an 8-pin ribbon connector with one pin broken off and two pins both labeled 6. That goes to ground; maybe one connector was meant for the chassis and another for the terminal's ground. Another pin is Vcc. Two come from a buffer: those must be the outputs. One goes to a Schmitt trigger inverter and has a pull-up resistor. And the last to one of the 8048's control pins. The remaining IC is a one-shot.

Focusing on the outputs, here is the A key.
a-key.png (27.1 KiB) Viewed 1084 times
And here is the B key.
b-key.png (27.04 KiB) Viewed 1084 times
That kind of looks like the PS/2 protocol: a clock that goes low for each bit. A start bit that is always high and eight data bits. But no stop bits. Which is too bad. One can decode PS/2 using an AVR's UART in synchronous external clock mode. But there is no way to configure it for zero stop bits (since that doesn't make sense for async mode -- how would you start looking for the next start bit).

So this will have to done in the converter code.

As far as I can tell, the second byte is always zero.

The scan codes are arranged logically: digits 20-29; letters 60-79; F-keys 40-4B; special actions (mostly) 50-5F.

Only the shift keys send break codes (high bit set). The two shift keys are distinguished, but not the two alt keys. I suspect this was to keep the shift mask in 4 bits. The 🔒 key sends a make when pressed and a break when released, just like the other shifts. Which really isn't that great for a shift lock. Maybe it was supposed to be a physically locking key? Anyway, I mapped it to control, since that is needed.

The Silent Tactile isn't silent at all because there's a buzzer and the non-shift keys click. Though there is a volume pot. And it might be possible to turn it off in software; I haven't worked out anything about what the terminal can send the keyboard. There aren't any LEDs, so it isn't super important. Of the Option DIP switches, I can only see an effect from two of them. Both cause action keys to invert the ALT prefix: one for the CLEAR key and the other for PA1 and PA2.

Working version here.
Last edited by MMcM on 30 Dec 2019, 20:02, edited 1 time in total.

User avatar

30 Dec 2019, 19:51

Don't know what to say really... other than great job and keep it up!
This stuff is way to advanced for me :mrgreen:

User avatar
[ XMIT ]

31 Dec 2019, 01:23

Neat! I'm tempted to dig out a couple of boards out of storage to see what sort of protocol surprises they hold...


12 Apr 2020, 03:29

Another converter where most of the work is dealing with voltages: the DEC LK201 / LK401.

The keyboard needs 12V power and the signals are 4800 baud RS-423.

I decided to do it two different ways.

First is copying the circuits in the keyboard itself or the VT-220 terminal it plugged into. The schematic for the keyboard is at ... _Oct83.pdf (page 16/21) and for the terminal at ... _Aug83.pdf (page 5/17).

A uA9639 differential receiver converts RX.

A uA9639 driver converts TX. It needs Vcc+ (+12V) and Vcc- (-12V). This can be gotten from the same 12V power source using a DC/DC dual output converter like the RB-1212D.
lk201-teensy-20.jpg (670.75 KiB) Viewed 847 times
Second is taking advantage of the serial levels being sufficiently compatible with RS-232, for which there are simple all-in-one converters such as the MAX232.

One additional advantage of this approach is that by using a 3V converter, such as MAX3232, a Teensy LC MCU can be used.

12V is used solely to power the keyboard.
lk201-teensy-lc.jpg (261.76 KiB) Viewed 847 times


07 Dec 2020, 06:56

MMcM wrote:
25 Dec 2019, 20:29
The Sun keyboards were like that, too. The easiest way to deal with it is just bit-bang the serial protocol; it's only 1200 baud. That's what the QMK converter does. But it seems unsatisfying to waste the MCU's UART.

Second choice is add an inverter. That's what I did with my Sun keyboards some years ago after looking at the TMK predecessor of that one. (Honestly, now that the QMK build modularity is a lot better, I could probably just customize some macros to use UART serial and flash the QMK code onto my existing hardware, letting me retire another repo.)
I finally got to doing this: reprogrammed the Teensy with inverter using QMK configured for hardware serial. And retired the much less flexible code, which is always a great feeling.


28 Dec 2020, 04:00

More fun with UARTs and voltages.

A Silicon Graphics keyboard from 1991.
SGI-case.jpg (293.18 KiB) Viewed 207 times
Other than the four extra LEDs, it's a by-then standard PC layout. The base is steel and the cable quite hefty, if cracking a bit, ending in a DA-15 d-sub connector with a solid metal case.
SGI-back.jpg (282.88 KiB) Viewed 207 times
The switches are Keytronic foam and foil. Thankfully, it's still intact on this board, so it remains okay to type on without any rework.
SGI-base.jpg (379.65 KiB) Viewed 207 times
Inside is where it gets interesting.
SGI-top.jpg (879.29 KiB) Viewed 207 times
SGI-bottom.jpg (814.09 KiB) Viewed 207 times
There's an 8031 with associated 64K EPROM, what I suppose to be a KT custom MOS scanner (22-0958-000), a couple of latches, and a 555 timer for a transducer / buzzer. And then a differential receiver and driver and two(!) 5V regulators.

The pinout and protocol are explained by a keyboard (7) man page(!). The serial communication is RS-423, like the LK201.

Power is ±12V, which the regulators turn into ±5V. The +5 is Vcc as well as one side of the differential driver, where -5V is the other. Since -12V is needed, it isn't just a matter of a barrel-jack like for the LK201; a power converter will be needed.

The 26LS32 differential receiver is designed to handle a range of ±7V, with the original terminal sending ±5V presumably. It won't fry with 12V, but it's always best to be careful. By comparison, the uA9639C used by the DEC engineers has a operating range of ±15V.

This suggests using a MAX3232, which does a bit below ±6V from the recommended charge pumps, instead of bothering with two sets of power converters for all four (five if you could 3.3V) voltages.

The keyboard serial is 600 baud, eight data bits with odd parity, so eleven bits total per frame. An ATMega32U4 can do this just fine, although Teensyduino doesn't have the neatly packaged implementation that it does for the 32-bit MCUs. QMK never had any abstractions for configuring serial; you always just set the registers directly.

But, once again, the MAX3232 also allows using a 3V MCU.

I started building with a Teensy LC, but it seems that since I did the LK201 converter, QMK and Chibios have bloated a bit and it now runs out of heap space unless the debug console is disabled. Which is probably just fine for a finished job, but pretty important for the development stage.

So I switched to a Teensy 3.2. The default system clock in Teensyduino for this board is 96MHz (overclocked), with the fastest official speed 72MHz. The QMK examples, which I've used as a basis for Chibios-based projects, define a system clock of 48MHz. The UART registers have a 13 bit divisor from the system clock. Which means that for 96MHz, the minimum speed is 733 baud, and for 72MHz 550 baud, and for 48MHz 367 baud. That is, 600 baud doesn't work when overclocked. (And 300 baud won't even with the slower defaults, should some future project ever need that.) It's easy enough to change the CPU speed from the Arduino menu and there shouldn't be any issue with QMK. But just to play it safe, once soldering is involved, I went with UART2, which uses the bus clock instead of the system clock and so buys another factor of two. It doesn't have a FIFO, but that shouldn't be an issue at this slow speed.
SGI-converter.jpg (508.72 KiB) Viewed 207 times
The keyboard has DE-9 connectors on either side for plugging in an SGI serial mouse. The mouse (7) man page describes the protocol. It does not say so, but this is recognizably the same as Mouse Systems serial mice for PCs, except 4800 baud RS-423 instead of 1200 baud RS-232. QMK supports this protocol already.

And the MAX3232 has two pairs of serial signals. And the Teensy 3 MCUs have three UARTs. So it should be just a matter of the proper macros and a couple more wires to include mouse support. And so it is, plus a couple glue routines to adapt the serial input the mouse protocol expects to the Chibios drivers.


28 Dec 2020, 04:51

How to test this mouse support?

I don't have an SGI serial mouse. And the ones for sale right now are all the newer PS/2 kind.

I also don't make a specific effort to collect mice, though sometimes they come with a keyboard, like a non-ADB NeXT. Or are needed for a project like the HP-HIL converter. And I'm not beyond grabbing interesting things from the surplus bin, back when that was a thing in computer stores, back when those were a thing.

Some just got accumulated over the years. I thought I had a Sun mouse, which would actually be pretty close to the Silicon Graphics one, if I'm not mistaken. I think they were both of the sort that needed one of those special metal mousepads with fine lines printed on them. But, anyway, it doesn't seem to be where I thought.

Looking through the PC serial mice, I found one that's actually made by Mouse Systems. But plugging it in and looking at the bytes, it's actually the Microsoft mouse protocol. The packaging says it's PnP; I guess that's what that means. All the other ones seem to be that protocol, too.

Okay, well, I was going to have to convert the baud rate anyway, so there's no reason the translator can't convert the packet protocol, too. They have roughly the same information content.

Just get an Arduino with more than one UART, I thought.

Now, as it happens, the Microsoft mouse protocol is, strictly speaking, only 7 data bits. The recommendation I have seen is to read with 7 data bits and 1 stop bit, or, if only 8 data bits with 1 stop bit is available on the system, just ignore the eighth bit. And to write (if implementing a mouse) with 7 data its and 2 stop bits, so that such a reader will work.

Turns out this Mouse Systems PC serial mouse is 7 data bits and 1 stop bit. A Teensy 2.0 (ATMega32U4) can be configured for fewer than 8 data bits, so it can read it fine. As can most RS-232 ports. But the Kinetsis Teensy's can only do more than 8 data bits. In short, a Teensy LC / 3.2 can't decode this mouse's serial stream properly.

The other PC serial mouse in the same box is some no-name optical one, probably overstock. It decodes fine in Teensyduino, but draws enough current for its optical circuitry that's always running that there isn't enough left over to drive the 4800 baud output line reliably.

Time to shift gears. I could use a Teensy 3.6, which has USB host capabilities, to translate from a USB mouse. I've used one before to have a modern USB keyboard imitate some vintage protocol.

But, instead, I went with a simpler approach and just had the PC do it, by plugging a serial mouse into the hardware serial port and sending the translated signal out a USB serial port which then connects to the side of the SGI keyboard. Here it is beside the breadboard version of the converter itself.
SGI-mouse-translator.jpg (432.02 KiB) Viewed 201 times
And that's enough to confirm that it basically works. As much as is probably possible until I come across a real SGI serial mouse. Or someone else who has both keyboard and mouse gets interested and tries out the converter.


31 Dec 2020, 03:16

Due to the recently discovered space constraint with a Teensy LC, I decided to remake the 3V LK201 converter with a Teensy 3.2 and make sure that works. And, indeed, a small adjustment was needed in the initialization timing. I believe that the faster clock and transmit FIFO meant that it could send off the key-up mode setting sequences before the LK201AA was ready for them. In any case, it's more reliable with a short delay.

Since the MCU costs a bit more, I invested in a Perma-Proto board to hold this one and some real connectors.
lk201-teensy-32.jpg (538.54 KiB) Viewed 163 times
While I was at it, I added a DIN-5 180° too for an Elektronika MS 7004.

The Электроника МС 7004 is a late-Soviet capacitive buckling spring keyboard that seems to be regularly available as NOS from Ukraine. This one is from 1991.
elektronika-ms-7004-case.jpg (411.66 KiB) Viewed 163 times
It isn't just the photo, all the alignments are just a bit off.

Some of the keys are unreliable, though none seem to be actually broken. It's also just about the pingiest thing around.

A similar board was discussed here.

It implements (more or less) the LK201 interface using a КМ1816ВЕ48 (= 8748) microcontroller, a К1102ЛП1 (= uA9637AC) receiver, and a К1102АП15 (= uA9636A) driver. Inside a hatch is an 8-pin header and the keyboard comes with a coiled cable from this to an ОНЦ-ВГ-4-5/16-В, ГОСТ 12368-78 (= DIN 41524) connector.

It came with complete printed instructions, which include schematics. These use octal, which is refreshing.

Most of the key codes are the same.

It adds a fourth LED for the state of Russian / Latin toggle. As expected, this is done with the fourth 20 bit to the existing indicator command. Except that you can't just include it in the same bitmask, but have to send separate 23 220 or 21 220 sequences.

Most importantly, it does not bother to implement the mode set commands, which would allow changing groups of keys to send key-up transitions. Instead, only the shifts, 256 and 257, cause 263. Which means other keys can't be enlisted as modern USB shifts.

Post Reply

Return to “Workshop”