20 Aug
2008
20 Aug
'08
3:40 p.m.
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?)
5 TxD (OUTPUT FROM LPFK)
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
http://brutman.com/IBM_LPFK/IBM_LPFK.html 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 --
<http://www.cadam.com/ccd_products_keypad.htm>. 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...
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/