OASYS and FM Towns

MMcM

04 Sep 2021, 20:20

Both these Fujitsu keyboards are from 1989.
OASYS-case.jpg
OASYS-case.jpg (831.85 KiB) Viewed 1930 times
OASYS-back.jpg
OASYS-back.jpg (831.73 KiB) Viewed 1930 times
FMT-KB105-case.jpg
FMT-KB105-case.jpg (961.24 KiB) Viewed 1930 times
FMT-KB105-back.jpg
FMT-KB105-back.jpg (673.83 KiB) Viewed 1930 times
The FM Towns board, FMT-KB105 / N860-2277-T001, has their distinctive tombstone keycaps and a regular JIS layout. The OASYS board, FACOM6140KA1 / N860-2986-T002, has its thumb shift layout. Both have Fujitsu leaf spring switches.

Similar boards have been discussed here before. Haata has an even more similar one.

I believe that all the Fujitsu keyboards with the unusual 8-pin Hirose HR12 connector have the same interface. In any case, these do.

Only three signals appears to be necessary for a converter.
OASYS-converter.jpg
OASYS-converter.jpg (583.28 KiB) Viewed 1930 times
Power has two conductors for each, and it seemed best to connect both of them, given that the coiled cable is pretty long and the wires are probably pretty thin.

The base interface is 9600 baud TTL serial. However, there is an open-collector driver on the output, which means just connecting to an oscilloscope or even the RX pin on a microcontroller, nothing will show up when pressing keys. (As the signal alternates between high impedance and ground.) The pin needs to be pulled up. Fortunately, that is easy to do on an AVR without an additional external components.

Each event consists of two bytes. The prefix byte always has the eighth bit set and the other byte never does. For the basic part of the protocol, the lead byte has one bit for make vs. break and another (effectively static) for thumb-shift vs JIS. And the main byte is the scan code, pretty clearly derived from the physical positions on some earlier keyboard(s). The highest possible scan code, 7F, is used specially with break to mean all-keys-up. I wish more keyboards had this feature, as it makes keeping in sync much more reliable.

The keyboard does auto-repeat itself (although the converter presumably should ignore this). This necessitates a more complicated protocol for the arrow keys, because the designers wanted to be able to auto-repeat diagonal motion. For these keys, the prefix bytes all have a high nibble of F. And the scan codes (mostly) subtract 4D so that they are 0, 2, 3, 4. This allows for the second protocol byte to contain two of them when following an F9 to indicate diagonal. For example, 34 (or 43, depending on which key was pressed first) means SE.

All of which is easy enough to translate.

Some of the key codes on the OASYS numpad are used for different keys on the FMT. Compare http://m0115.web.fc2.com/oakb102.jpg and http://m0115.web.fc2.com/fmr60kb212.jpg. For instance, 29 is ] } to the left of return on the FM Towns, but the big vertical keypad period on the OASYS. It's possible to have a common keymap deal with this by dispatching on the layout type from the key events.

Which leaves the question of whether it is possible to get the thumb-shift working with a modern system. In kana mode, A alone is う(u), with left shift, を(wo), and with right shift, ゔ(vu). In the JIS layout, A is ち(ti). Having the keyboard emit these hiragana isn't really feasible: Unicode input is an alternate IME, so it doesn't feed the input for the Japanese one. Another possibility would be to send the romaji as key presses. But then the keyboard would need to both switch between kana and alpha mode internally and send the switch code, leading to issues of them getting out of sync. The layout could switch layers based on the Kana LED in the USB report. But the input methods I experimented with don't seem to set that.

On Linux, the ibus-anthy input method supports thumb shifting. By default, the shift keys are assigned to 無変換 and 変換. To keep those available for their normal function, two different codes need to be found. Of the eighteen HID usages associated with conversion / language, only seven make it all the way through the input stack to be available for ibus. So the best I could come up with was LANG1 and LANG2, which are supposed to be for Hangul. Opening anthy prefs, setting the keyboard layout to jp, the typing method to thumb, the thumb layout to Nicola-J with FMV KB231, and then changing the thumb shifts to Hangul and Hanja gets pretty close to entering the three kana variants from each key correctly. For similar reasons, there doesn't seem to be a good code to map 英字 to, though. Of course, I suppose one could always put them on unused function keys, possibly with funny shifts.

User avatar
hellothere

16 Sep 2021, 18:02

As I have too many 8-pin KBs, I'd be very interested in what your pinouts are and the converter you wired up. Can you please post that?

Post Reply

Return to “Workshop”