Ethan Dicks wrote: I have the RS/6000 drivers, and software that supports the LPFK, and the machine itself, including the official IBM serial interface to talk to one of these. Peace... Sridhar

Mike, Linux seems to deal differently with the DSR signal than Hyperterm on Windoze. I've got some devices around (like UPS and switch management ports, which are likely 3-wire setups) for which I have to force DSR to get minicom or kermit to be useful. Any chance you just have a hardware handshake problem? De

I downloaded Realterm - that was a good tip. I'm on a real serial port (no USB involved) and I still can't make it reset or do anything. However, I did discover that it will respond with Hex 0x03 (single char, ASCII 3) if I hit Ctrl-F. I will compare your pinouts to my notes after dinner ... Mike Philip Pemberton wrote:

Philip, Could you execute a small loop in RAM that iterates the flash and pukes the code byte by byte onto the serial bus ? / steven

Scanning wrote: No -- the 8051 latches the state of the EA (External Access Enable) pin on startup. This is the pin that tells the chip whether to run from internal ROM or from an external ROM. If it's running from ext-ROM, the MOVC instruction won't work (or it'll read It's also a Harvard architecture MCU, so the code and data spaces are separate. You can't just JMP MY_EVIL_ROUTINE_IN_RAM and dump the ROM that way. Princeton (Von Neumann) architecture chips like the 8086 will allow this, and the 8051 will if you wire-OR /PSEN with /RD. It's not really a common configuration though, and only works when the 8051 is being operated as an external CPU. Thanks, -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

Dave McGuire wrote: I'm not 100% sure if my programmer is even following the spec, it's basically a PIC18F452 micro, a 74HC4040 counter and a bunch of resistors. If you've got a proper 8051 programmer, then it might be worth trying it... Meanwhile, I'm buzzing out the PCB, then I'm going to pull some of the larger components and take pictures. If I can get a bit of spare time, I'll see about borrowing the inspection scope and camera at work for a couple of hours to get some decent PCB pics. Scanning isn't going to work, not with the LEDs as tall as they are... -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

They are still available to those who were originally interested. Most of the original list paid and I shipped theirs months ago. Phillip responded recently and I sent his to the UK. Two go in a Flat Rate Priority Mail box, although First class mail is cheaper for overseas most of the time. I have a couple with broke keys that I am willing to strip and provide for experimentation as a bare board if you fry yours in trying. Paxton On Sun, Aug 17, 2008 at 6:03 PM, Dave McGuire <mcguire at neurotica.com> wrote: -- Paxton Hoag Astoria, OR USA

IBM LPFK 6094-020 victims .. It's been a year, but I finally found what I was looking for. Which is good because I was about to go mideval on an AIX 4.3 box to get the data that I needed. ;-) Somebody deep inside the Blue Wall had the docs on a CD-ROM. Here is the quick summary: 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. 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. 0x09: Disable: Keyboard input is disabled. The LPFK will still respond to Reset and Read Configuration 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. Responses from the LPFK: 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. 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. 0x81: OK: The LPFK sends this if the last Set Indicators command was received successfully. All of this is also written up at http://brutman.com/IBM_LPFK/IBM_LPFK.html for the good of the greater public. 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.) Mike

Ethan Dicks wrote: I don't know where the codeninja guy got his information. After all of the research that I've done I don't think that he has a normal LPFK. His came from an engineering department and may have been modified, just like Dave & the guys here were talking about modifying theirs. 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 think in practice the LEDs were used to indicate functions that were toggled on. And as you mentioned, they could also be set to show you what functions were legal/available to select. The only real wrinkle with this protocol is that the host has to 'confirm' each keypress by relighting the entire keyboard. (Their is no way to change just one key - you have to send the entire bitmap down.) It makes sense though - selecting one key could often have a side-effect on what other keys/functions would be available. I decided to be painful to myself and I fired up the PCjr and Zbasic, a crufty old BASIC compiler. Zbasic is nice because it supports a primitive form of structured BASIC, but it's definitely got some bugs in the COM handling code. The PCjr is only spec'ed to handle up to 2400 bps, but for single character transmissions like this it is doing fine. I'm looking forward to running a telnet BBS on it and using the keypad as a combination status indicator/input device. That way I can know how busy the machine is an interact with it in a limited way without turning the monitor on. Evil grin .. each lit button represents a connection to kill. :-) Mike

Michael B. Brutman wrote: First off, thank you Michael! I'll be putting my LPFK back together tonight and wiring it up to the PC for testing. Plan #1 is a quick test program, #2 is a library to control it from a POSIX-type O/S (read: Linux). I was actually thinking about implementing the "Game of Life" on an LPFK to start with, or possibly the old "Lights Out" game. Just to see if it works, of course :) -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

John Honniball wrote: Interesting. The wikipedia article says the game is from 1995. A very similar puzzle, except played on a 3x3 grid and the neighborhood around a move wrapped around the borders, appeared in a Processor Technology publication back in 1977, although its origin is even earlier (see comment below): http://www.sol20.org/articles/access_v1n4.pdf It used the numeric keyboard as the 3x3 pad to control game play. I reconstructed the source code from that publication: http://www.sol20.org/programs/galaxy.asm The comments for it say: ; PROGRAM ORIGINALLY SUBMITTED TO THE ; HEWLETT-PACKARD SOFTWARE LIBRARY IN BASIC ; SUBSEQUENTLY PUBLISHED BY PEOPLE'S COMPUTER ; COMPANY IN SEPT 74 AS "TEASER" ; WRITTEN IN 8008 CODE BY WILLARD I. NICO ; IN BYTE MAY 76 AS "SHOOTING STARS" ; ADAPTED TO 8080 CODE FOR USE WITH VDM-1 ; BY JERRY BACON ; S.I.L. PROGRAMMING LABORATORY ; BRASILIA, D.F. BRASIL ; ; DATE: 14 JAN 77

For those that are interested, I saw a packing-wrap bundle of what looked like two LPFKs and another gadget full of big "spinny" dials. This was at the Re-PC in Tukwilla, WA today. AFAIR, the price was under $10. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind.

Michael B. Brutman wrote: 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. Looks good to me: rx: 03 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. And 0x08 turns it back on again. 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 :) 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. 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. Though in fairness the message you posted here is probably going to be more permanent :) 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'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/

Michael B. Brutman wrote: The problem is that the 8051 on the LPFK is copy-protected -- the 8051 has two layers of this: - Encryption table: this is a 32-byte table that is XNOR'd with data as it is read out of the chip. Obviously, this table is write-only... - Lock Bit 1 -- disables further program memory writes. - Lock Bit 2 -- same as LB1, also disables reading from program memory. It looks like LB1 and LB2 have been programmed on the LPFK's 8051. The only ways I can think of to get around this would be to decap it and reset the lock bits, or try various power glitching attacks to try and bypass the protection circuitry. I've no doubt that the latter has been done, just I don't know what magic parameters to use... Pretty much. It seems to expect an init sequence. If I send it the string "SFFFFFFFF" with an LF terminator (as mentioned on the codeninja page), then all the LEDs blink briefly. Nothing after that though, and changing the FFs for 00s has no effect on the LED pattern. At this point, an RS/6000 with the LPFK connection kit would be really useful, but from what I gather they aren't exactly common... All you really need to do is rig a pair of serial ports on e.g. a PC to monitor the RXD and TXD lines on the LPFK, then dump whatever the RS6k sends to the LPFK and how it responds. This is needle-in-a-haystack stuff. Or as my friend just pointed out, the "brute force method" would be to remove the 8051 in the LPFK and replace it with an 8051 derivative running different software. That would involve buzzing out the entire circuit of the LPFK and writing an alternative firmware that *does* accept the Codeninja command set. But is it worth it? You'd still need to swap the 8051 chip... I'd much rather make the original LPFK work with as few modifications as possible. Thanks, -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/

Dave McGuire wrote: Heh, I used to do a lot of 8051 stuff. It was the second (or maybe third?) MCU I used. Started when someone sent me a box of HTEC "Kitty Card" 8032 CPU boards -- these were apparently the things that controlled the old Argos "Premier Points" loyalty card tills. They make great test rigs for 8052 code. As a side effect of all this fiddling, I have four AT89S8252 chips and a couple of Atmel ISP 8052s (AT89S52?). I've also got some Dallas DS89C420 High Speed 8051 parts and the relevant ISP pods. Not very - it consists of: 4x Motorola SN74LS373P latches -- 8-bit tristate latches. Pin 1 (/OE) is wired to what appears to be a common enable. 32x HP QLMP-2541 LEDs 32x membrane keyswitches (6x sets of rubber membranes with matching PCB pads -- 2x 1x4 and 4x 1x6) 1x 74LS00 1x MAX232CPE 1x Intel P80C51BM 1x 11.0592MHz crystal .. and a bunch of passive components Disassembly is easy. Six screws on the bottom, plus one inside holding the ground tag to the metalwork, then the PCB lifts up and out. Reassembly is just as easy. Most chip datecodes are around 1996. LEDs appear to be wired common-anode. A resistor is wired between each LED anode and +5V, and the LS373s drive the cathodes (Qn outputs). I'm guessing the input lines (Dn inputs) are wired common on all the 373s, either D0=>D0 or munged (D0=>Dx, D1=>Dy, ...) The keys appear to be wired into a 4x8 matrix -- for a total of 32 keys. There are eight pull up resistors and four diodes on the matrix. Fair guess that said parts will make it somewhat easier to trace the matrix back to the 8051 pads with a multimeter. I've also found a diode and some other stuff that appears to drive the /OE line on the latches somehow, and also links up to the loopback switch?! Buzzing out the key matrix shouldn't take more than a few minutes. Possibly 4-bit scan output from the MCU via the diodes, and 8-bit scan return, which will be what the PURs are for. I'm still not sure about the wiring around the line driver and LS00, that's still a mystery and will probably involve some component removal and track-tracing to unravel. I'm also looking into power-glitch attacks on the MCU -- apparently a few old 8051 chip revs were vulnerable to having Vcc rapidly dropped to 0V and then restored quickly. This apparently cleared the protection flip-flops and caused the chip to allow code readback. It still doesn't solve the problem of the encryption array, but if there's at least 64 bytes of 0xFF in the ROM, finding the key won't be hard (64-byte sliding window scanner and a quick "if top_half == bottom_half" check should find most of the candidates). That's the problem with straight-XOR, it falls quickly against a known-plaintext attack. That still leaves the problem of getting the code in the first place. Reverse engineering the board and rewriting the firmware may well be easier. Though not easier from the POV that an LPFK will require modification before it's of any use. It's entirely possible to reverse the modification (hint: fit a turned-pin IC socket, and use desoldering wick to remove the old chip!) but I'd still rather not modify it if it's possible to figure out the IBM protocol. Thanks, -- Phil. classiccmp at philpem.me.uk http://www.philpem.me.uk/