Sharp X1 Turbo

[MMcM]

This keyboard is for a Sharp X1 Turbo.

Sharp-X1-case.jpg (452.76 KiB) Viewed 8754 times

This particular model, DSETK0011CE00, has green Alps, so it is nice enough to type on, but thankfully not yet a target for those harvesting switches. The lock keys are physically locking; there are no indicators.

Sharp-X1-back.jpg (525.61 KiB) Viewed 8754 times

The cable terminates in a 3.5mm audio plug. There is a clever hole in the back of the case for holding this when not plugged into the computer, so that it doesn't just flop around.

The protocol over the single output line is a special bit serial encoding, using pulse widths to distinguish 0 and 1 data bits and header bits. It is mostly described at X1センター.

At heart, this is an ASCII keyboard. However, the protocol events include the current state of the CTRL, SHIFT, カナ, CAPS LOCK, and GRAPH shift keys. Moreover, it sends a general no-key event when the previous non-shift key is released.

Additionally, the keyboard has a slider switch on the side labelled A - B. When in B mode, which was designed for games, the keyboard sends an additional report on the exact state of 24 of the keys (Q W E A D Z X C 7 4 1 8 2 9 6 3 ESC 1 - + * HTAB SP RET) as a bitmask.

Here are normal key reports:

x1-turbo-A-shift-T.png (56.93 KiB) Viewed 8747 times

Here are game mode reports interleaved with them:

x1-turbo-B-ESC-H-TAB-Q.png (58.24 KiB) Viewed 8747 times

This is enough to build a converter implementing a USB keyboard.

Sharp-X1-converter.jpg (484.76 KiB) Viewed 8754 times

The non-trivial part of the conversion is inferring the key that was pressed from the ASCII code in the key event.

• The character set is normally JIS X 0201.
• 7-bit characters are ASCII, except ¥ for \ and ‾ for ~.
• The number pad keys proper send the same characters as the number row, but with a "ten-key" bit to distinguish.
• The F keys are ten-key versions of some top-row letters, with F6-F10 being SHIFT F1-F5.
• The arrow keys are ten-key characters in the ASCII control character range.
• Other command keys like HELP and COPY have the eighth bit set.
• In B mode, the kana codes are shuffled around in a way that I do not recognize. For example, the L リ key sends D2 and not D8. Perhaps this is for compatibility with the encoding of some other system.
• Keys like INS DEL and CLR HOME, which have two legends, send different ten-key control characters when SHIFT is pressed.
• BREAK and SHIFT BREAK are also distinguished (SHIFT BREAK is ten-key CTRL-C).
• The GRAPH key with normal keys sends characters with the eighth bit set, but in the unused part of the JIS codepage. Presumably these were suitable drawing shapes in the default font, as in most early PCs.

An effective strategy for this is to use the extra bits to determine which of several lookup tables to index with the ASCII code.

Things that are not quite clear from the above referenced document are:

• There are no start bits separate from the header bits.
• The header bits are backwards: the CTRL shift bit is the last bit sent, not the first. Things are complicated because the ASCII code that follows is sent in big-endian order.
• The last bit in the game key reports is for either RET key, the main one or the numpad one. Only the regular key report distinguishes them, by means of the ten-key bit.

There is still ghosting in game mode. If Q W and E are held down and HTAB is pressed, five bits appear in the report, including SP.

The document suggests that the X1 (not Turbo) had a keyboard using an earlier version of the protocol and not sending reports when only the shift states changed. It is not clear from my reading whether they still sent anything on key release. Nor have I seen one of these keyboards.