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 3835 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 3706 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 3706 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 3706 times
And here is the B key.
b-key.png (27.04 KiB) Viewed 3706 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 3469 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 3469 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 2829 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 2829 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 2829 times
Inside is where it gets interesting.
SGI-top.jpg (879.29 KiB) Viewed 2829 times
SGI-bottom.jpg (814.09 KiB) Viewed 2829 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 2829 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 2823 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 2785 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 2785 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.


16 May 2021, 20:47

Another ST-series keyboard, 113ST13-5-J, this for the Teleray 20HE terminal.
Teleray-20HE-case.jpg (318.4 KiB) Viewed 2182 times
Teleray-20HE-back.jpg (319.08 KiB) Viewed 2182 times
The PCB is SC-15282.
Teleray-20HE-top.jpg (448.08 KiB) Viewed 2182 times
The PCB supports are locking and I didn't want to risk damaging the PCB by trying to take it off them just for a photo.
Teleray-20HE-bottom.jpg (454.3 KiB) Viewed 2182 times
Therefore some of the chips aren't visible here.
Teleray-20HE-side.jpg (277.82 KiB) Viewed 2182 times
But the circuit is more or less clear and when needed it is possible to read what is what using a dental mirror.

The connector is a 4P4C RJ. There is a 5V regulator, so power will be 12V. The two data signals go through inverters, the input one with a Schmitt trigger (7414). So it's bidirectional TTL level serial of some sort, which makes sense given that there are LEDs to control.

Connecting to a scope, it is 4800 baud idle low. Even without pressing any keys the keyboard sends FA all the time.

Again, the 5V tolerant Teensy 3.2 is a good choice for the converter.
Teleray-20HE-converter.jpg (481.14 KiB) Viewed 2182 times
All the keys send unique key press codes, which are simply the key number left-to-right top-to-bottom, and including the six membrane switches without key caps visible in the photo above.

Six of the keys also send key up codes, distinguished by the high bit being set. In addition to the two Shift keys and the Control key, the three rightmost (unlabeled) keys in the top row are locking shifts.

Which means that FA is logically key up for the next key after the bottom-right key, 79. Something harmless for the keyboard to send to let the terminal know it is still plugged in.

The serial signal to the keyboard sets the LEDs, one bit each and skipping the 1 bit, perhaps on account of the righthand power LED, which is always lit. And the 40 bit causes the buzzer to sound. I'm not sure what the remaining two bits do, if anything. I'd sort of hoped that it would be possible to enable key click, but it doesn't seem so.

All of which is just enough for a USB keyboard with inflexible shifts.


06 Jun 2021, 03:11

Sometime around 1984, Convergent changed from a 9-pin D-sub to an 8-pin SDL connector.
Convergent-KM-001-side.jpg (324.03 KiB) Viewed 1729 times
The signals are the same: +5, GND, RESET, DATA OUT, and DATA IN at 1200 baud. A new converter just needs the new connector.
Convergent-converter-SDL.jpg (237.11 KiB) Viewed 1729 times
This keyboard has the same layout as the one at the top of this topic.
Convergent-KM-001-case.jpg (397.95 KiB) Viewed 1729 times
The new design is different enough that Convergent made another PTO design filing for the changes from the previous one.

It is model number KM-001.
Convergent-KM-001-back.jpg (1.09 MiB) Viewed 1729 times
It has KeyTronic foam and foil switches with rubber domes.
Convergent-KM-001-plate.jpg (541.7 KiB) Viewed 1729 times
It's not too obvious from the photo, but this one looks to have had a nasty fall and the plate got bent. A couple of the switch sliders broke, too.

The PCB is held on with fewer screws than KeyTronic usually does, so luckily it survived unscathed.
KeyTronic-18178-1-top.jpg (1.23 MiB) Viewed 1729 times
KeyTronic-18178-1.bottom.jpg (1.8 MiB) Viewed 1729 times
After cleaning the keycaps, it is very hard to put them back on without access to the other side. Which meant opening it up, even though the foam is still in good enough shape. Originally there was some EMI foil around the circuitry, but I didn't bother to replace it when reassembling.
Convergent-KM-001-EMI.jpg (634.97 KiB) Viewed 1729 times
(Don't tell the Mounties.)

The keyboard protocol is the same as in the original hardware manual and in the patent. It is used to send the same key codes. The startup (after power-on or hard RESET) procedure is a little more complicated: the previously defined soft RESET code is now required to get the keyboard to start sending codes. And before that the keyboard starts by sending a previously unused code 7E (as FE with the end bit on) for a while, followed by B0 and a layout identification code. But this is compatible enough for a single firmware to do the original keyboard as well as this new one.

There was also a version of this keyboard with ITW magnetic valve switches. This can be seen in this current eBay listing for a whole terminal.
Convergent-KM-001-ITW.jpg (156.38 KiB) Viewed 1729 times
(It also looks to have hand-added Arabic legends.)

When Burroughs started reselling Convergent and later acquired the company, this layout became K1 for the B25. Haata has one of the ITW version with Burroughs branding.

The layout then further evolved. Haata also has K2 and K5.

I have some of these later boards as well and have been able to confirm that the same key legends send the same key code even as they change position. Although a variety of switches are used, none of them last thirty years, so the boards all need some repair to get all keys activating. That may be needed to work out all the key codes, or I may be able to combine the results from each of them to infer it.


29 Jul 2021, 01:03

Hey MMcM! I always love seeing new threads from you and, even though a lot goes over my head, I still love reading through your process of reverse engineering and converting keyboards.

The day finally came where I was able to put your knowledge and research into practice! I recently got a CT64-00164 that I cleaned up, and using this thread as a resource, built a converter for. I am typing this message on it, in fact!
CT64.jpg (142.7 KiB) Viewed 1295 times
So I just wanted to extend a heartfelt thank you for all the work and documentation you do for this community!


22 Aug 2021, 04:31

Another case where the advanced UARTs on the 32-bit Teensy's can do work that used to take a bunch of discrete components.

The Coleco ADAM peripherals connect via a shared bus called AdamNet. It is outlined in the Technical Reference Manual. A better scan of the keyboard schematic is also online. The cable is 6P6C.

I am not sure I buy the idea that AdamNet is like a token-passing network. There is a bus master (the computer) and all device traffic is in direct response to a command from the master, like in USB.

In any case, at the end of the day, the bus is a 62.5K baud half-duplex serial line with standard framing, TTL levels, and idle low.

The Kinetis MCU used in some 32-bit Teensy's has a single-wire mode where both input and output use the TX pin. A register bit controls this mux. There is a pull request for TeensyDuino to support this as an serial "format" and have the write methods and transmit complete interrupt switch back and forth automatically. But it isn't all that hard to do manually. These same UART modules also support inverted polarity. And the Teensy 3.2 is 5V tolerant, so it's the way to go.

Notwithstanding that complex stack, the keyboard only sends ASCII characters, with special codes with the eighth bit set for the function keys. There are no key-up transitions and no access to the shift key states.

So it doesn't seem to me to be really useful to make this into a QMK keyboard. (Although there was someone who built something like that in 2015.) What I usually do instead is implement a virtual serial port for a typing test with screen or cu and a small Arduino sketch does that.


15 Nov 2021, 07:05

Converting a Sun Type 3 keyboard got me revisiting how that converter works again.

The existing one, as described above, which originally ran its own firmware project, but now has QMK configured for hardware serial -- there is an inverter -- isn't really suitable for a DA-15.
Sun-45-converter.jpg (576.01 KiB) Viewed 233 times
So I redid it again, this time with a 5V tolerant 32-bit Teensy.
Sun-3-converter.jpg (503.69 KiB) Viewed 233 times
This is more work than it really ought to be, because there is no unified abstraction for serial shared by AVR and Chibios.

Further complicating things is that the converter subproject's directory hierarchy is already taken up for type3 vs type5. So it isn't available for Teensy 2.0 vs Teensy 3.2. Absent a rethink there, it's forced to put the Chibios config files in the keymap directory. Meaning there is at present no command that builds a Teensy 3.2 Type 5 converter, even though all the code is there. Which is a shame.


24 Nov 2021, 05:38

This is a keyboard for a Sperry-Univac UTS terminal.
UTS-case.jpg (1.31 MiB) Viewed 106 times
I believe that this is the so-called Low Profile Expanded Typewriter keyboard.
UTS-back.jpg (1.47 MiB) Viewed 106 times
It is Key Tronic foam and foil. The foam on this particular one (from around 1988) is substantially intact, so I have not yet undertaken replacement.
UTS-bottom.jpg (1.96 MiB) Viewed 106 times
According to this matrix, it was compatible with the UTS-20, -30, -40, and -60. There is an essentially identical board (same model number, one month apart) documented on Bitsavers, where it is named as UTS-10, so presumably it was compatible with that, too. I have no reason to suppose that other keyboards for this terminal series did not use the same interface and protocol. If I am not mistaken, the taller ones used ITW switches.

I am actually not sure what precisely an Intel 60515 is. From the copyright date and the usage, I would guess MCS-48 series, but this is a 48-pin DIP and furthermore the power and xtal pin placement does not seem like others of that series or time.

Also note how the stab for the slim-ass Enter interlocks with the PCB.

It has a DE-9 connector, of which 5 wires are used: +5V power and ground; an input to a TTL inverter, which is then inverted again before going to the controller, and so is presumably some kind of serial input; an output from the controller; and that same output passed through the inverter. That is, it has both idle-high and idle-low serial output. One can pick the one that is needed and avoid problems of the sort that this topic describes. Or perhaps do a differential comparison.
UTS-converter.jpg (502.05 KiB) Viewed 106 times
Experimentation reveals that it is 9600 baud. There is no need for to-keyboard communication to control LEDs or a buzzer, as there are none of either. Just connecting the serial line, that is, pulling up the MCU TX line, is not sufficient to get the keyboard talking. Nor is sending a byte or two. It seems that it will only transmit if it has seen a query from the terminal recently. But it does not seem to care at all what the signal is. I am sending a zero byte periodically. But I also tried just sending square waves at various frequencies around 5kHz and everything worked then, too.

Specifically, it is 1 start bit, 8 data bits, odd parity, and 2 stop bits. Each key press sends two frames, for a total of 24 bits. There are no key release codes, except for a very specific case described below. And no separate transitions for the two shift keys, SHIFT and FCTN. Instead, the state of the shift keys is sent in the first byte, along with the 8th bit to indicate the prefix byte and a bit to indicate key press. The second byte is the unique scan for the non-shift key that was pressed. In short, for normal key presses, the first byte is A0 and the second is the key code.

If a key is held down for a while, a second report is sent, but now with A8 as the prefix. I believe that this indicates the start of auto-repeat. Once in this state, a B0 00 report indicates release, that is, all keys up. Pressing a second key while one is in the held state just sends its regular report and the release does not occur until all are up. Meaning that there can really only be one non-shift key down at a time and only the last one should auto-repeat.

The four arrow keys always send a B0 report, even if not held long enough to cause A8. I interpret this to mean that arrows would have started auto-repeating sooner.

The inflexibility of the shift mapping limits what this can do as a USB keyboard. For simple shell interactions, it is more or less necessary to map FCTN to CTRL and that is what I have done for now. For a different program that won't ever need control characters, it would also be possible to make FCTN a layer shift and get some more commands / macros.

Post Reply

Return to “Workshop”