Alps / Genovation KPX-17

[MMcM]

Following on the recent conversion of some external numpads built by Mitsumi for Toshiba and Compaq that minimized space by only having a mono sub-mini audio jack, I dug around in the work pile for other interesting approaches from around the same time, the early '90s. One such is to use connectors that the laptop already had: almost all PCs around then would have had serial and parallel ports. And so did the super-heavy laptops.

Here are two variations of the Alps / Genovation KPX-17, one serial and one parallel.

KPX-17S-case.jpg (301.87 KiB) Viewed 3907 times

KPX-17S-back.jpg (188.81 KiB) Viewed 3907 times

KPX-17P-case.jpg (184.58 KiB) Viewed 3907 times

KPX-17P-back.jpg (376.82 KiB) Viewed 3907 times

Each variant came in two colors, black and ivory, making for a total of four products.

The switches are complicated cream Alps. The matrix is a separate module, KP-17, manufactured by Alps.

KP-17-switches.jpg (293.96 KiB) Viewed 3907 times

With its convenient connector, it's easy enough to interface directly to the switch module.

KP-17-converter.jpg (397.61 KiB) Viewed 3907 times

I used a Pololu AStar Micro, since it has ten data pins on one side, making it easy to solder on a compatible header. The combination would fit back into the original case, if one wanted.

Other than using RS-232 levels instead of TTL, the serial version is like many other keyboards of the time. Each key sends a unique 7-bit code which also changes depending on the state of the Num Lock LED. Num Lock both toggles this LED and sends a code. There does not appear to be any way to change the LED state using the serial line. Which means that it might be more convenient to assign Num Lock to a layer of its own if the main keyboard also has a Num Lock key + LED. There are no break codes.

A converter needs a level converter like the MAX232 or MAX3232. These are available as breakout boards with a D-sub connector, which works nicely with a smaller ATMEGA32U4 like the Piksey Atto.

KPX-17S-converter.jpg (824.21 KiB) Viewed 3907 times

The parallel version is much more interesting. The controller board is made by Genovation.

KPX-17P-top.jpg (239.41 KiB) Viewed 3907 times

KPX-17P-bottom.jpg (224.46 KiB) Viewed 3907 times

The whole external keypad was also sold with Genovation branding as the Micropad 621.

A DB-25 has eight more conductors than the keypad has keys. Even if you allow that eight of those are all ground, that's still one more. So if it weren't for the parallel port interface, they could be separate switch signals.

The board was evidently designed to work with an original output-only parallel port. Which makes sense from the date and that it was not associated with any specific laptop model.

The first issue is power. A parallel port does not have any supply voltages, expecting that both the computer and the printer are powered. Oddly enough, this is very much the same problem as the "one-wire" Mitsumi keypads had. The solution here is to connect each of the data lines to a diode and current-limiting resistor and connect all of those to a common Vcc for the circuit. Provided that a majority of the data lines are kept high all the time, the small bit of logic is powered. That will inform the protocol.

Someone had the job during manufacture of using a rotary tool to deface the tops of the active chips, which are presumably 74-series TTL. This makes it hard to say exactly what the part numbers are, but not what they do. They clearly include a de-mux and a counter. Two of the counter signals go to parallel data pins. Several others go to the de-mux. Which suggests that one strobes a data line to advance a row or column number. Likewise several other data pins go to the matrix, making them the column or row. (Turns out, by experimentation, that they are column and row, respectively.)

Only two parallel status lines are connected back to the parallel port, SELECT and ERROR. So one of those, or both, is how you tell when the key at the current position is pressed. (Turns out it's ERROR. SELECT seems to signal that any key was pressed, but that's not important if there is a scanning loop.)

The converter just needs a Teensy and a DB-25, with an output data port PORTB and the two input pins. Keeping those separate from RX means that a single board with enough connectors could do both KPX-17S and KPX-17P.

KPX-17P-converter.jpg (1.04 MiB) Viewed 3907 times

The predefined QMK firmware variants build them separately, though.

[Rayndalf]

Would a convertor like this work with a serial mouse or trackball? I have an M13 and some other boards with integrated trackballs that I'd love to use over USB, but I can't find a commercial Serial to USB convertor marketed for pointing devices.

[MMcM]

Would a convertor like this work with a serial mouse or trackball? I have an M13 and some other boards with integrated trackballs that I'd love to use over USB, but I can't find a commercial Serial to USB convertor marketed for pointing devices.

A converter like this, yes. But all the details will be different.

Can you say a little more about what you have, exactly? I am a little confused because I would have imagined that an M13 with trackball would interface as a PS/2 keyboard and a PS/2 mouse. But what you have is serial? Is that for both the keyboard and mouse?

[Rayndalf]

Would a convertor like this work with a serial mouse or trackball? I have an M13 and some other boards with integrated trackballs that I'd love to use over USB, but I can't find a commercial Serial to USB convertor marketed for pointing devices.

A converter like this, yes. But all the details will be different.

Can you say a little more about what you have, exactly? I am a little confused because I would have imagined that an M13 with trackball would interface as a PS/2 keyboard and a PS/2 mouse. But what you have is serial? Is that for both the keyboard and mouse?

I should be more clear, I have 3 keyboards with pointing devices that connect with DIN5 AT + Serial (?) Instead of dual PS/2. The one that I traced had only 4 or 5 wires actually connected to the DB9 plug. These plugs appear identical to serial mice of the era, but convertors for serial mice are surprisingly hard to find.

[MMcM]

I have 3 keyboards with pointing devices that connect with DIN5 AT + Serial (?) Instead of dual PS/2.

Ah, okay. I get it now.

I believe that QMK has the necessary protocol handlers for both, so it should just be a matter of a proto-board with both connectors and maybe extra power and then some copy and paste software.

If I can find one like that cheap enough on eBay, I might even give it a shot.

[Rayndalf]

The grey one on the left used a standard G81 keyboard module and the ball is an entirely independent serial device (that happen to share a wire), and I replaced the keyboard PCB already, so that one should be the same as converting a standalone serial mouse (I didn't know QMK also converted serial, but I can give it a shot).

Using one micro controller for both outputs would be great for the other two though. The cable on the M13 is losing its insulation so I think I'll convert it internally and get a new cable.

[Rayndalf]

I didn't realize that commercially available RS232 to USB cords are actually active adapters, so I think I'll try my luck with one of them (I should have room to hide one in the case) and get a small USB hub so I only have one cable leaving the case (and maybe cut holes so the order ports are accessible? Unfortunately the small (2 device) USB hubs designed for prototyping cost as much as the larger consumer ones.

[MMcM]

Okay. I got a NIB Adesso-branded Ortek OEM MCK-106-TB from the '90s. It has four-tab white Alps clone switches and a plastic trackball. So, it's cheap, but clicky. And not the worst keyboard ever; I was able to type this with it.

As I thought, QMK has protocol handlers for both PS/2 and Microsoft Serial Mouse, which was more or less standard. So, the tricky bits are dealt with and it's mostly a matter of Makefile options.

The mouse protocol says to ignore the high bit in the serial data and this keyboard sets it most of (all?) the time. Evidently the mouse used with the code that's there didn't, so a patch was needed to mask that off.

QMK doesn't already have an defined mapping for scan code set 2, which is what "compatible" keyboards use, and which needs special handling for E0 prefixes. TMK has something, but it hasn't been ported. I suppose everyone just uses a regular-old PS/2 to USB converter or Soarer's. But it was easy enough to copy/paste from another keyboard that had even more escapes (up to E2). And that's it for software.

Like you said, it's really two completely separate devices in the same case. Which means that power for the serial mouse needs to be dealt with. Serial mice stole it from the RS-232 RTS and DTR signals, which the computer would assert. A level shifter was already needed to convert RS-232 voltages to TTL: I used a MAX232. I then used the second TTL-to-RS-232 signal to control DTR with a GPIO, since the serial mouse protocol has a handshake using it. And hard-wired RTS to the RS-232 positive voltage. Since a mouse is actually a receive-only device, it might have also worked to wire the first signal to a GPIO as well. Assuming the mouse is okay with its receive line floating. But I thought maybe it would someday be needed for something that did have to-device communication. And changing RTS is only for reset, for which unplugging and plugging works fine.

Here's the converter I built.

PS2-with-serial-mouse-converter.jpg (827.29 KiB) Viewed 3405 times

Since this trackball uses physical switches, it needs essentially zero current. It's possible that a more sophisticated device would need more and maybe that would turn out to be an issue.

There are pre-packaged MAX232 breakout boards, with SMD components. They don't break out the raw voltages, so that would mean going with the two GPIO solution. Breakouts with a DE-9 on the board (male is rarer than female) don't seem to deal with EIA signals other than data flexibly enough, or I didn't find one that looked like it would. Hence the giant capacitors for the charge pumps on this thing.

[Rayndalf]

As I thought, QMK has protocol handlers for both PS/2 and Microsoft Serial Mouse, which was more or less standard. So, the tricky bits are dealt with and it's mostly a matter of Makefile options.

Those Ortek boards look pretty neat.

I tried searching the QMK documentation but I must have totally missed that it had support for serial mice, all I found was talk on connecting two halves of a split board using serial.

So the DB9 header you used is just a connector, all the logic is on the Teensy and the MAX232?

I'm a little too dumb to copy a circuit just by looking, are only 4 pins of the DB9 connector used? If I wanted to make something similar but hardwired (to mount internally) I would just need a QMK compatible microcontroller, and a MAX232? How would I know if I need to use capacitors with my pointing device?

I hate to just throw questions at you, but this looks like exactly the kind on converter I would need, but I'm not (yet) familiar with level shifters or really electrical engineering in general.

I'm sure if I was more experienced I'd be able to use the I2C or SPI interface on a TKC1800 PCB to run the serial convertor as well and eliminate the need for a USB hub to combine the two devices, but a simple internal converter is more than good enough!

[MMcM]

I tried searching the QMK documentation but I must have totally missed that it had support for serial mice, ...

The key bit in rules.mk is:

Code: Select all

SERIAL_MOUSE_MICROSOFT_ENABLE = yes

and then you need to specify how the serial port will work with:

Code: Select all

HARDWARE_SERIAL = yes
SRC += protocol/serial_uart.c

and various macros in config.h to set AVR registers for the USART with baud rate, etc.

So the DB9 header you used is just a connector, all the logic is on the Teensy and the MAX232?

Correct. The Teensy has all the real logic and the MAX232 does voltage adjustment between TTL (0 or +5V) and RS-232 (± 10-ish V). The rest is wires and connectors. I do my conversions outside, keeping the existing connector hardware. But that's just me; there aren't any rules.

..., are only 4 pins of the DB9 connector used? If I wanted to make something similar but hardwired (to mount internally) I would just need a QMK compatible microcontroller, and a MAX232? How would I know if I need to use capacitors with my pointing device?

Connections on the Teensy:

• GND to - rail.
• Vcc to + rail.
• D0 to DIN-5 2 (DATA).
• D1 (INT1) to DIN-5 1 (CLOCK).
• D2 (RXD1) to MAX232 12 (R1OUT).
• D3 (TXD1) to MAX232 11 (T1IN).
• C6 to MAX232 10 (T2IN).

Connections on MAX232:

• 2 (Vs+) to DE-9 7 (RTS).
• 7 (T2OUT) to DE-9 4 (DTR).
• 10 (T2IN) from Teensy C6.
• 11 (T1IN) from Teensy D3.
• 12 (R1OUT) from Teensy D2.
• 13 (R1IN) to DE-9 2 (RXD).
• 14 (T1OUT) to DE-9 3 (TXD).
• 15 (GND) to - rail.
• 16 (Vcc) to + rail.

Connections on DE-9:

• 2 (RXD) from MAX232 13 (R1IN).
• 3 (TXD) from MAX232 14 (T1OUT).
• 4 (DTR) from MAX232 7 (T2OUT).
• 5 (GND) to - rail.
• 7 (RTS) from MAX232 2 (Vs+).

So that's five pins.

Connections on DIN-5 (see http://kbdbabel.org/conn/kbd_connector_ps2.png):

• 1 (CLOCK) from Teensy D1.
• 2 (DATA) from Teensy D0.
• 4 (GND) to - rail.
• 5 (Vcc +5V) to + rail.

Capacitors on MAX232:

• 1 and 3.
• 4 and 5.
• 2 and ground.
• 6 and ground.
• 16 and ground.

The first two are for the charge pumps. What this chip does is take +5V from Vcc and turn it into ±10V. The capacitor is kept charged by the incoming low voltage and then a (fairly) high speed digital circuit samples that to get the higher voltage.

The other ones are to protect against voltage drops as things start using those sources.

If you wanted to save some soldering (and messing with loose capacitors) and go with something prefab like BOB-11189, as I said, I believe the difference is that you'd need to use T1IN from another GPIO, say, C7, and T1OUT to RTS. And leave D3 and TXD disconnected. And then add that second GPIO bit to the SERIAL_UART_INIT macro. I haven't tried this, but I think it will work.

If you're putting the converter inside the case, then the simplest thing is just to leave out the DE-9 connector and still do the RS-232 signal. It's likely that the trackpad is doing TTL (or CMOS) levels itself and then converting to RS-232 at the last minute. So, you could bypass that and go straight. But how to do that would vary from board to board, so it's hard to give more specific advice. Maybe just stick to the (slightly) wasteful conversion to serial and back.

I'm sure if I was more experienced I'd be able to use the I2C or SPI interface on a TKC1800 PCB to run the serial convertor as well and eliminate the need for a USB hub to combine the two devices, but a simple internal converter is more than good enough!

I'm not quite sure what you're trying to hook up here. Is this a Cherry 1800 board with a pointing device that we're gonna Frankenstein with the TKC PCB?

[Rayndalf]

If you wanted to save some soldering (and messing with loose capacitors) and go with something prefab like BOB-11189, as I said, I believe the difference is that you'd need to use T1IN from another GPIO, say, C7, and T1OUT to RTS. And leave D3 and TXD disconnected. And then add that second GPIO bit to the SERIAL_UART_INIT macro. I haven't tried this, but I think it will work.

I don't mind a little soldering, but the breakout board might make things more compact to mount. If I understand correctly if I use a BOB-11189 then some of the connections would be straight from the Teensy to the serial device and others would be wired through the BOB-11189 breakout.

Are most serial breakout boards going to work for this application?

If you're putting the converter inside the case, then the simplest thing is just to leave out the DE-9 connector and still do the RS-232 signal. It's likely that the trackpad is doing TTL (or CMOS) levels itself and then converting to RS-232 at the last minute. So, you could bypass that and go straight. But how to do that would vary from board to board, so it's hard to give more specific advice. Maybe just stick to the (slightly) wasteful conversion to serial and back.

I agree, it's easier to assume that the device works as serial rather than trying to reverse engineer it. Either way I still have to convert it and serial seems easier to work with.

I'm sure if I was more experienced I'd be able to use the I2C or SPI interface on a TKC1800 PCB to run the serial convertor as well and eliminate the need for a USB hub to combine the two devices, but a simple internal converter is more than good enough!

I'm not quite sure what you're trying to hook up here. Is this a Cherry 1800 board with a pointing device that we're gonna Frankenstein with the TKC PCB?

Yeah, the grey metal board was made by another company that used a G81-1800 keymodule installed along side the trackball. Any PCB made to fit a G80-1800 case seems to fit if I widen the hole on the left side. Currently a Leeku 1800 PCB is installed (I bought it assembled and unlike the TKC1800 the switches are aligned), but I also have a TKC1800 PCB that would also fit.

Given how industrial the case is I might install a USB hub in the back, so merging the two devices (keyboard PCB and the trackball) could be done through that. I don't really want to mess with the TKC1800 (it's powerful and has some IO, but proper switch alignment requires a plate.

I also have a trackpoint Model M (M13) that uses AT + Serial instead of dual PS/2, and the dual cable started to disintegrate so I may convert it internally similar to the converter you made for the Ortek (only mounted internally... assuming the M13 has room for even more PCBs).

I'm not sure when I'll be able to attempt these conversions, but the info you've provided is invaluable for people like me (I can solder, but I have basically no idea what I'm doing). Thank you so much for taking the time to explain this stuff so thoroughly

[MMcM]

The mouse protocol says to ignore the high bit in the serial data and this keyboard sets it most of (all?) the time. Evidently the mouse used with the code that's there didn't, so a patch was needed to mask that off.

That's what you need to do when reading 8 data bits with 1 stop bit. But the protocol is actually 7 data bits. A suggestion is for mice to send 7 data bits with 2 stop bits. And hosts to read with 7 data bits and 1 stop bit.

While working on something else, I dug out a serial mouse that's actually 7 data bits with 1 stop bit. Which means 8 bit mode will fail to decode it properly.

The patch isn't needed, but configuring the UART for 7 data bits is. I've fixed it to do that.