Hi,
Some of you may remember from the new Model F megathread that I have made my own keyboard firmware (USB and key processing implementation from scratch), which also supports the new Model F keyboards. Anyway, one ambition I've had for this firmware was PS/2 output, since I'm also into retrocomputing and would like to use a "Model F" keyboard on vintage computers.
Well, I seem to have finally managed to do it: it just needs two free GPIO pins on the microcontroller, which the xwhatsit/wcass controller has (even conveniently located on a 6-pin header on the side), and either a PS/2 cable/connector wired directly to those, or (what I did) those pins can be wired to the USB connector's D+/D- pins and then one of those old passive USB to PS/2 dongles from the 90's can be used to share the same connector. (The dongles often came with early USB mice, and have the picture of a mouse on them, but they are just passive adapters and the PS/2 mouse and keyboard don't differ electrically at the connector.)
I tested it on a real IBM PS/2 as well as on my own earlier PS/2 to USB converter (yeah, it makes no sense to output PS/2 only to convert it back to USB, but for science (and debugging)), and commercial PS/2 to USB converter. After some initial mistakes and breaking out the logic analyzer (that I seldom bother to use, but really should do more), I think I have a pretty much complete emulation of the IBM Model M PS/2 keyboard that I used as reference, including all three keysets (many commercial keyboards don't even bother to support keyset 3 because Windows doesn't use it (probably because keyboards don't implement it), but I think Linux might benefit).
It's GPLv3 open source of course, but highly experimental at this point. Still, if anyone here would be interested in using it, e.g., for retrocomputing or some other use where it would actually get some testing, I would be delighted to help you set it up. Easiest would be for one of the AVR-based "Brand New Model F Keyboards" where I can tell you exactly where the wires for the PS/2 need to go, but it should in theory work on any AVR-based keyboard that is supported by QMK if you feel comfortable finding the pins on the PCB and soldering to them in case there is no easy-access pin header like on the Model Fs. (I would need to first port the keyboard support from QMK to my firmware, but that should be relatively easy, as I've set up a compatibility layer that takes the key matrix and LED/RGB/EEPROM/etc. access from QMK as is, and then replaces their USB and keycode/layer/macro handling completely with mine).
I made new Model F output PS/2
-
Arkku
- Location: Finland
Thanks! My PS/2 implementation itself is open source, so it should only take about 100 lines of code to use it on Leyden Jar. (I will probably implement Leyden Jar support in my own firmware as well, once I get my hands on one of the Leyden Jar controllers. I much prefer my firmware's key mapping and USB implementations to those of QMK.)
But the PS/2 code itself is very isolated, so if you want to take `ps2_output.c` and the supporting headers, and `usb2ps2_keys.c` for the scancodes, you just need to replace `kk_ps2_avr.h` with an ARM equivalent (<100 lines of simple code), and then have something in the main loop call `ps2_output_task()` and the thing that sends keypresses and -releases to USB needs to instead call `ps2_press_key(usb_keycode)` and `ps2_release_key(usb_keycode)`. That's pretty much it.
There are a ton of special cases in PS/2, so I had AI generate very extensive unit tests for them based on various implementation notes (e.g., Microsoft's PS/2 documentation from around the year 2000), and then even more by recording the raw output of various corner case keystroke sequences from an IBM Model M PS/2, so I"m not fairly confident that my implementation should match the Model M.
BTW, may I ask how do you plan to handle the PS/2 5V levels with RP2040, which AFAIK is not 5V tolerant, at least officially? The first solution that comes to mind is to just pull it up to 3.3 V on your side and let the host pull it to 5 V (as it will) on theirs, but that might prevent autodetection of the host (which is normally easy because the pull-ups are on the host side) and/or sharing the USB connector. But I am not an electrical engineer, so curious to know if you have found a solution for this?
But the PS/2 code itself is very isolated, so if you want to take `ps2_output.c` and the supporting headers, and `usb2ps2_keys.c` for the scancodes, you just need to replace `kk_ps2_avr.h` with an ARM equivalent (<100 lines of simple code), and then have something in the main loop call `ps2_output_task()` and the thing that sends keypresses and -releases to USB needs to instead call `ps2_press_key(usb_keycode)` and `ps2_release_key(usb_keycode)`. That's pretty much it.
There are a ton of special cases in PS/2, so I had AI generate very extensive unit tests for them based on various implementation notes (e.g., Microsoft's PS/2 documentation from around the year 2000), and then even more by recording the raw output of various corner case keystroke sequences from an IBM Model M PS/2, so I"m not fairly confident that my implementation should match the Model M.
BTW, may I ask how do you plan to handle the PS/2 5V levels with RP2040, which AFAIK is not 5V tolerant, at least officially? The first solution that comes to mind is to just pull it up to 3.3 V on your side and let the host pull it to 5 V (as it will) on theirs, but that might prevent autodetection of the host (which is normally easy because the pull-ups are on the host side) and/or sharing the USB connector. But I am not an electrical engineer, so curious to know if you have found a solution for this?
-
Rico
- Location: France
Thank you very much for your feedback !
I will look at how you implemented the integration to your QMK like firmware and also the HID scancode to PS2/AT scancode conversion.
For the PS2 protocol I started basing my work long time ago on an open source project that implements it specifically for the RP2040 using PIOs:
https://github.com/No0ne/ps2pico
My goal is to integrate the PS2 feature in my VIAL fork and be able to easily shift from USB connectivity (to be able to tune keys/macros/layers with VIAL app) to PS2 by connecting the USB cable either to the Leyden Jar controller or to the PS2 daughterboard.
As for handling the 5V, I made a specific daughterboard that connects in place of the solenoid, it is described in my Gihub repository here (have a look at the end of the readme):
https://github.com/mymakercorner/Leyden_Jar
This daughterboard have 5V/3.3V level shifters for both clock and data lines.
And the 5V goes to the 3V3 voltage regulator to correctly power the Leyden Jar.
I will look at how you implemented the integration to your QMK like firmware and also the HID scancode to PS2/AT scancode conversion.
For the PS2 protocol I started basing my work long time ago on an open source project that implements it specifically for the RP2040 using PIOs:
https://github.com/No0ne/ps2pico
My goal is to integrate the PS2 feature in my VIAL fork and be able to easily shift from USB connectivity (to be able to tune keys/macros/layers with VIAL app) to PS2 by connecting the USB cable either to the Leyden Jar controller or to the PS2 daughterboard.
As for handling the 5V, I made a specific daughterboard that connects in place of the solenoid, it is described in my Gihub repository here (have a look at the end of the readme):
https://github.com/mymakercorner/Leyden_Jar
This daughterboard have 5V/3.3V level shifters for both clock and data lines.
And the 5V goes to the 3V3 voltage regulator to correctly power the Leyden Jar.
-
Arkku
- Location: Finland
Interesting about the daughterboard: does the USB-C connector on it only output PS/2 or does it also carry a duplicate of the actual USB? If the latter, how do you detect whether USB or PS/2 is connected to that shared connector?
(re. ps2pico, it is an extremely minimal implementation, as per "pico" name. It probably works fine in practice most of the time, but definitely won't match an actual PS/2 keyboard like the Model M.)
(re. ps2pico, it is an extremely minimal implementation, as per "pico" name. It probably works fine in practice most of the time, but definitely won't match an actual PS/2 keyboard like the Model M.)