XT/AT/PS2/Terminal to USB Converter with NKRO

[flipkey]

writing a blank config, followed by unplugging and re-plugging the converter, should do it.

I tried that, but hid_listen still reports Mode: AT/PS2

I wonder if this is a quirk of the ATmega32U4.

[Arakula]

Could you please post the complete hid_listen output (i.e. start hid_listen, then plug in the converter)?
It would be interesting which keyboard ID, if any, gets reported, as this determines the mode.

[flipkey]

This what it says now, after writing an empty config and re-plugging:

Code: Select all

    Listening:
    wEE rEE wF2 rFA rAB r83 
    remaining: 0000
    Keyboard ID: AB83
    Code Set: 2 (extended)
    Mode: AT/PS2
    wED rFA w00 rFA

This is what it said (according to my notes from a few days ago) before I started experimenting with the "force" command:

Code: Select all

    Keyboard ID: 0000
    Code Set: 1
    Mode: PC/XT

Obviously, the Keyboard ID field is different now. Is that what the auto-detection uses to choose a protocol mode? Or, does protocol auto-detection happen first, and enable keyboard ID detection?

I'm a little surprised that writing a blank config didn't revert it. Perhaps re-flashing the firmware would do that?

[Arakula]

First, SC tries to determine what it got. It does so by setting everything up for AT/PS2 communication, then sends out a "Hello echo!" to the keyboard (that's the "wEE" in your listing). If it receives an Echo response (the "rEE" in your listing), it then sends out a "Who you?" to the keyboard (that's the "wF2" in your listing). Then it waits for a response. The following can happen ...
1) nothing; no echo. Then it assumes to be connected to a PC/XT keyboard and switches to that mode. Also what happens if no keyboard is connected at all.
2) an echo response plus acknowledgement (the "rFA" in your listing), but nothing else. If so, it's most likely an AT keyboard.
3) an echo response plus acknowledgement, followed by 1 or 2 bytes keyboard ID (that's what you got - "rFA rAB r83") which means it's an Extended keyboard in AT/PS2 mode. Depending on the received ID, it tries to guess whether it is a codeset 2 keyboard (yours is - AB83 is an ID typically used by an Enhanced keyboard) or codeset 3.

If "force" is configured, however, it is applied instead of all of the above and overrides Soarer's automatic detection. This, by the way, also inhibits determination of the keyboard ID, so "ifkeyboard xxxx" can't really be used in config files if "force" is set.

The "wED rFA w00 rFA" part in your listing, BTW, means "turn off all lock LEDs", in case you're wondering.

If communication did not work correctly a few days ago, but obviously does now, I suspect a slighly problematic connection, cable, or a failing controller in the keyboard. That might also be the reason for the "F7 floods" you experienced before changing the firmware. Time for re-capping, maybe?

[Edit:] tried to sharpen my description's precision quite some times; hope it's good enough now.

[flipkey]

Thanks for the description of the protocol; that's good information to have in general, and explains why removing the force command from my config doesn't revert to XT mode.

If communication did not work correctly a few days ago, but obviously does now, I suspect a slighly problematic connection, cable,

It seems unlikely given that the problem disappeared completely as soon as I wrote a config containing the force command. I suppose that could be merely coincidence. I'll consider this possibility if the problem reappears.

or a failing controller in the keyboard. That might also be the reason for the "F7 floods" you experienced before changing the firmware. Time for re-capping, maybe?

I was testing with two different variants of the keyboard, bought more than a few years apart, and I don't recall seeing different results between them. That suggests to me that it's not a failing component in keyboards. (Unless there actually was a difference that I simply didn't notice; I'll try to remember to check next time I pull the other one out of storage.)

For now, it's working beautifully.

[DDD80]

Hi! I have gotten inte some problems with my IBM F keyboard. It is a XT with the larger connector, and I thought it would be possible to make it work. I have used QMK before when I converted an old keyboard buth that was a bit simpler since the keyboard was found in the database at QMK.

I have also bought a ItsyBitsy (that was the one I could buy at a local store), but it has a Atmega32u4 chip so I think it will work. However, I have forgotten how to do this and when I read the this thread people at the end are saying that the old documents from Soarer might be too old to use.

But I suppose on the other hand that there has to a simple way of doing this, either with some Arduino or with QMK, I just have difficulties to getting started. Does anyone here know how to do? Otherwise I will just read through the thread, but a tip would be a little bit faster...

[AngryCockroach]

I use the original XT controller with a Arduino Pro Micro and Soarer Firmware. Works quite well.

Do you still have the original controller installed?
Do you have Windows, Linux, Mac (Intel or Apple CPU)?