IBM LPFK reverse engineering

Philip Pemberton classiccmp at
Wed Aug 20 17:40:57 CDT 2008

Michael B. Brutman wrote:
> Protocol: 9600,O,8,1 with no handshaking
> Commands (shown in hex)
> 0x01: Reset: Similar to the power on reset. Leaves the LPFK in the 
> 'disabled' state with all indicators off.

Confirmed: blinks the LEDs on for a second, then off. Keypad disabled afterwards.

I've also confirmed that I made a mess of the pinout... There are two grounds, 
two +5Vs, receive and transmit. The connector is an 8-pin shielded Mini-DIN. 
The LPFK has a socket, the cable has a plug. Here's the revised, and working 
pinout, pins shown looking into the front of the LPFK socket or the back of a 
solder-type Mini-DIN line plug:

   __   __
  /  |_|  \
| 8  7  6 |
| 5   4 3 |
  \  2 1  /

PCB pads:

    [ 33uF  ]==:

o---[ R ]---o

8 7 6 5 4 3 2 1

Pinouts are:
   1   GND
   2   GND
   3   VCC (+5V)
   4   VCC (+5V via PUR?)
   6   RxD (INPUT TO LPFK)
   7   NC (no connection)
   8   NC (no connection)

My current hardware config is a MAX232 and an FTDI TTL-232R-WE wire-ended 5V 
LSTTL USB-to-RS232 cable. The MAX232 converts from RS232 to/from TTL, and the 
TTL-232 converts this to USB while also providing a +5V power supply for the LPFK.

> 0x06: Read configuration: Upon getting this byte the LPFK responds with 
> 0x03. Helpful for determining if the LPFK is active on a serial port.
> 0x08: Enable: Tells the LPFK that it may process and send keystroke data 
> to the host machine.

Looks good to me:

 > send 0x01
 > send 0x06
 > recv 1
rx: 03
 > send 0x08
 > recv 8
rx: 00 01 02 03 04 05 06 07

Keys seem to be numbered from left to right, top to bottom. Top-leftmost key 
is 0x00, the one to its right is 0x01. The key at the end of that row is 0x03, 
then the keys on the row below are numbered 0x04 thru 0x09.

> 0x09: Disable: Keyboard input is disabled. The LPFK will still respond 
> to Reset and Read Configuration

And 0x08 turns it back on again.

> 0x94: Set Indicators: This command is followed by four more bytes which 
> is a bitmap that represents the indicator lights on the keys. If the bit 
> for a key is turned on, the light will be turned on. If the bit for a 
> key is 0, the light will be turned off. Keys are numbered from 0 to 31.

It's nice to finally see the LPFK light up :)

Packet format: 0x94 aa bb cc dd
{aa,bb,cc,dd} can be considered to be a string of bits, chunked into bytes.

Bit 7 of 'aa' represents key 1 (scancode 0x00)
Bit 6 of 'aa' represents key 2 (scancode 0x01)
Bit 1 of 'aa' represents key 7 (scancode 0x06)
Bit 0 of 'aa' represents key 8 (scancode 0x07)

Bit 7 of 'bb' represents key 9 (scancode 0x08)
Bit 0 of 'bb' represents key 16 (scancode 0x10)

Bit 7 of 'cc' represents key 17 (scancode 0x11)
Bit 0 of 'cc' represents key 24 (scancode 0x17)

Bit 7 of 'dd' represents key 25 (scancode 0x18)
Bit 0 of 'dd' represents key 32 (scancode 0x1F)

This was nice and easy to figure out. Makes a very nice change from MPEG 
transport stream section decoders and table parsers :)

> 0x00 to 0x1F: Keystroke: The corresponding key on the LPFK was hit. These
> responses are only sent when the LPFK has been enabled using the Enable
> command.

It's probably worth noting that the LPFK doesn't auto-repeat, nor does it send 
a separate key-up/key-down scan code. Depending on your POV, this is either a 
good thing or a bad thing :)

It does tend to suffer from key-bounce a little though.

> 0x80: Retransmit: The LPFK sends this if there was an error on the last 
> Set Indicators command and it wants the host machine to retransmit it.

The only error I've been able to provoke is a timeout. If you don't send the 
complete Set Indicators command within ~500ms, the LPFK times out, flushes the 
receive buffer and waits for you to resend the command. The 0x80 (Retransmit) 
repeats every second until you either resend the Set Indicators command, or 
send a 0x01 Reset command instead.

I'm not sure if a parity error will also cause a Retransmit status code to be 
transmitted -- anyone care to try?
 From what I can gather, the LPFK ignores any bytes that have an incorrect 
parity bit. So if the Retransmit command goes through and one of the LED state 
bytes gets munged along the way, the LPFK will ignore the munged byte and the 
packet will be 4 bytes instead of 5 (command + 3 status, instead of command + 
4 status). That will more than likely trigger the timeout.

> All of this is also written up at 
> for the good of the greater 
> public.

Though in fairness the message you posted here is probably going to be more 
permanent :)

 > Now I need to figure out how to run 9600 bps on a PCjr ..  it
> doesn't like anything over 2400.  (4800 or 9600 might be ok, as it just 
> is one byte being received.)

I've scrapped my plan of cutting apart this LPFK to do the PCB scans. I think 
it would be a much better idea to track down a broken LPFK, strip it for 
parts, then keep the spares for other LPFKs and drop the PCBs on a scanner.

Million dollar question: does anyone have a broken LPFK to spare? I'm only 
after the PCB, and maybe a few spare keycaps if they are easily removable (I 
haven't tried yet).

> I have a blank overlay and a CADAM overlay that labels the keystrokes. I
> will probably scan the blank shortly so that people can download and make
> their own.

I'll look forward to that. I'm trying to think of a serious use for the LPFK 
but I'd still like to see what the keypad overlays look like.

Interestingly enough, I did a quick search on CADAM and found this -- 
<>. It seems to be a mini version 
of the LPFK without the blinkenlites.

I suspect the intention of the LPFK was to allow users to rapidly switch from 
one function to another in complex CAD software. As for the LEDs, generally a 
lit LED is taken to mean "this is switched on", so I suspect those were 
probably used to indicate which functions/modes were active at a given time.

Although there's nothing inherently wrong with lighting up the options you can 
choose instead, I'd have thought lighting up the keys corresponding to the 
active functions would have been more useful. Though it might be useful as a 
training aid I suppose...

classiccmp at

More information about the cctech mailing list