XT to 5251 Converter

[Rayndalf]

The IBM 5251 is historically significant and collectible, but also cursed with a beamspring keyboard. The price of this keyboard continues to rise but paradoxically the price for keyboardless terminals seems to be dropping. I've been eyeing a 5251 terminal lately (in no small part due to inmbolmie's excellent work in adapting these terminals to work with a USB host device), but like most people I can't afford a 5251 keyboard

Luckily the layout of the fullsize 5251 keyboard proved to be massively influencial on the Datamaster and the first set of Model Fs, and by extension PC clones of all kinds copying the success of the 5150. Converting an XT keyboard to interface with a 5251 terminal seems like a natural solution to the missing keyboard problem. If supporting AT protocol as well can be done simply that would allow the use of essentially any PS/2 keyboard with the 5251.

Based on my current understanding the converter would have 2 roles. First it provides keyboard input which is converted to 5251 protocol and attached using a DB25 connector. Second it would recieve the 8.5V out and solenoid trigger from the 5251 terminal to activate an onboard beeper to replace the solenoid of the 5251 keyboard.

XT to 5251 converter diagram.png (6.98 KiB) Viewed 5259 times

I've been able to get most of the pinout for the DB25 connector (by crossreferencing kbdbabel and a couple of the documents on bitsavers) and the IBM manuals describe the scan codes as well. The layout/version of the 5251 keyboard is set with jumpers and that the terminal can read, but I believe that can be achomplished in software.

kbd_connector_ibm5251.png (10.73 KiB) Viewed 5259 times

1. Cable Check A
2. Click (Solenoid Trigger)
3. Scan Code Bit 1
4. Data Strobe
5. Scan Code Bit 4
6. Scan Code Bit 5
7. Scan Code Bit 6
8. Break Code Bit 0
9. Scan Code Bit 7
10. Unknown
11. +8.5V (Solenoid power)
12. Unknown
13. -5V DC
14. KB Ident Bit 0
15. KB Ident Bit 1
16. Scan Code Bit 2
17. Power-On Reset
18. KB Ident Bit 2
19. KB Ident Bit 3
20. + Delay Strobe
21. Cable Check B
22. Scan Code Bit 3
23. Ground
24. Ground
25. Vcc +5V

5251 keyboard layout and scan codes SY31-0461-3_5251_Display_Station_Models_1_and_11_MIM_Jul79.pdf

(175.85 KiB) Downloaded 105 times

I feel like this is all the "information" I need to proceed, but I have limited programming experience. How would I go about coding a microcontroller to read an XT keyboard, convert those scancodes to ones the 5251 understands and spit those out along a DB25 cable? Any help would be greatly appreciated!

[Muirium]

You need to understand both the protocols your converter will need. Riffing from your slip of the tongue at the end: AT and XT are incompatible precisely because they are different protocols. Otherwise those jacks and pinouts are exactly the same. Protocols matter.

Pinouts are a necessary first step. But next you need to figure out the logic. The brave souls who have done this kind of thing—who could offer you real advice!—use a logic analyser and oscilloscope to work out exactly what's going on. Without a 5251 keyboard of your own, this will be extra tricky.

I've got a 3276. Naturally, I pulled the original controller and cable out, and keep them aside. Perhaps someone with a 5251 could spare you theirs? Once the controller is plugged in and powered up, you could simulate keys by touching its sense pads. (Or is the polarity reversed on beamspring, so you'd need to uncover them to represent pressed keys?)

[Rayndalf]

I've tried to find an unwanted 5251 controller and cable, but unsurprisingly everyone with a 5251 seems reasonably attached to those parts even if they aren't currently using them and don't plan on buying a 5251 terminal either...

I know that the 5251 uses 8 bit parallel serial with a strobe but I don't know what that means outside of that fact that each pin carries a different bit. Similarly I also don't know how often the keyboard checks keyboard identity (just on start up?) or what are cable check A and B used for outside of a single test procedure. I'll have to rely on someone who has a 5251 if I need to be sure.

More generally I don't know how converters receive data from a XT keyboard and successfully break that into scancodes. I've looked at the source code for TMK and I'm having a really hard time making sense of it. Working from an existing program that interprets XT and just modifying what it actually does with that data seems logical, but I don't know shit. If anyone does I'm eager to learn.

[Muirium]

Seems a bit daft of them. I'd let you have mine if I had one! My 3276 controller and cable is available for anyone seriously considering that project.

As for the task ahead: this signal analysis stuff is not easy. Without the original hardware or fully detailed documentation on the protocol itself, it may be an impossible task.

[Weezer]

You can actually use any usb keyboard, just plug it into the computer you're running the python script from. You lose the real time feedback of seeing the characters you type, but it's fully functional otherwise.

[Rayndalf]

You can actually use any usb keyboard, just plug it into the computer you're running the python script from. You lose the real time feedback of seeing the characters you type, but it's fully functional otherwise.

Oh cool. I didn't realize that worked that way!
I already have a 5291 keyboard I can convert to USB that would be perfect as far as layout and key labels.

I still think a keyboard converter might be useful though.

[listofoptions]

this protocol is relatively simple and fairly well documented, no snipping from me though, too many pages from http://bitsavers.org/pdf/ibm/5250_5251/ ... _Jul79.pdf
you should look at pages 65-92 (pdf pages not page numbers)

the basic process seems to be:
check to see if the strobe delay pin is low, if it is wait until its high, else dump scanned byte over the connection and pull the strobe pin low, wait until the strobe delay pin goes low, then pull the strobe pin high grab the next buffered byte, repeat

as for at/xt there exists converters already, i would assume you could modify the code from tmk/qmk to do the trick. those iirc dump scancode bytes into a ring buffer, once we have the ring buffer its a matter of grabbing that byte, converting it to the byte codes the 5251 wants to see (listed in the bitsavers book) and performing the above protocol (if ive understood it, and thats a bit if)