TMK IBM PC Keyboard Converter

[hasu]

My fIrmware can still have a silly bug or room to improve but I'd suspect its power line first. I'm not totally sure power voltage drop causes  serious problem like these.

I checked again a few things again, I’m not doing any power shenanigans.

Soarers converter works without issue, I swap the fw to TMK and have issues.
I’ve tried on 2 different XT keyboards both built around the same time using two different ProMicros. Same issues.

I belive you can't get 5V at RAW on Pro Micro and you need to use VCC pin with J1 solder bridged. (It seems liek most of cheap Pro Mciros come without the solder bridge) I'm NOT sure that voltage of power matters, though.

It would be helpful if you can see whether there are any difference with 5V when you have time.

[acid2000]

J1 on the pro micro is for voltage select. 3V vs 5V.

I’m running a 5V pro micro.

Running at 3v is way out of spec for an XT. In the past I’ve run accidentally on 3v and they won’t come up.
Even if they did (by tapping of the usb power) you would be driving a 5V GPIO with 3V, it would probably work but would be a PITA to set up.

Run your ProMicro at 5V.

[hasu]

J1 on the pro micro is for voltage select. 3V vs 5V.

I’m running a 5V pro micro.

Running at 3v is way out of spec for an XT. In the past I’ve run accidentally on 3v and they won’t come up.
Even if they did (by tapping of the usb power) you would be driving a 5V GPIO with 3V, it would probably work but would be a PITA to set up.

Run your ProMicro at 5V.

No, I'm not referring 3.3V Pro Micro.

Did you check the wiki page?
Beleive me, you will get only 4.6V typically from RAW pin even if you are using 5V version Pro Micro.
You should be able to confirm this with multimeter easily, or this can be evident from its schematic also.

To get proper 5V you have to do both two things below.
1) Make solder bridge on J1
2) Use VCC pin to give keyboard power , not RAW pin

https://github.com/tmk/tmk_keyboard/wiki/Pro-Micro#j1-solder-bridge

[Maledicted]

J1 on the pro micro is for voltage select. 3V vs 5V.

I’m running a 5V pro micro.

Running at 3v is way out of spec for an XT. In the past I’ve run accidentally on 3v and they won’t come up.
Even if they did (by tapping of the usb power) you would be driving a 5V GPIO with 3V, it would probably work but would be a PITA to set up.

Run your ProMicro at 5V.

No, I'm not referring 3.3V Pro Micro.

Did you check the wiki page?
Beleive me, you will get only 4.6V typically from RAW pin even if you are using 5V version Pro Micro.
You should be able to confirm this with multimeter easily, or this can be evident from its schematic also.

To get proper 5V you have to do both two things below.
1) Make solder bridge on J1
2) Use VCC pin to give keyboard power , not RAW pin

https://github.com/tmk/tmk_keyboard/wiki/Pro-Micro#j1-solder-bridge

I suppose that could explain why all of my Pro Micros only intermittently worked with TMK, but Teensies work fine. I'll have to look at that.

I do still plan on flashing back to your most recently posted modified TMK firmware by the way, it was just getting late last night. Is there any sort of sniffing we could try to do on a computer that natively works with the beige label Z-150 to figure out how/why?

Also, maybe if you could point me to what values to play with, and what you think the general threshold may be, I could tweak the timings myself?

[acid2000]

I’ve bought a Teensy 2.0 from an official distributor.

This will be the last time I give this a go. I hope it works.

[hasu]

J1 on the pro micro is for voltage select. 3V vs 5V.

I’m running a 5V pro micro.

Running at 3v is way out of spec for an XT. In the past I’ve run accidentally on 3v and they won’t come up.
Even if they did (by tapping of the usb power) you would be driving a 5V GPIO with 3V, it would probably work but would be a PITA to set up.

Run your ProMicro at 5V.

No, I'm not referring 3.3V Pro Micro.

Did you check the wiki page?
Beleive me, you will get only 4.6V typically from RAW pin even if you are using 5V version Pro Micro.
You should be able to confirm this with multimeter easily, or this can be evident from its schematic also.

To get proper 5V you have to do both two things below.
1) Make solder bridge on J1
2) Use VCC pin to give keyboard power , not RAW pin

https://github.com/tmk/tmk_keyboard/wiki/Pro-Micro#j1-solder-bridge

I suppose that could explain why all of my Pro Micros only intermittently worked with TMK, but Teensies work fine. I'll have to look at that.

If you can confirm that  the lower voltage power of Pro Micro affects any keyboard this would be worth sharing with the community and I would make a thread for this Pro Micro topic.

I do still plan on flashing back to your most recently posted modified TMK firmware by the way, it was just getting late last night. Is there any sort of sniffing we could try to do on a computer that natively works with the beige label Z-150 to figure out how/why?

Also, maybe if you could point me to what values to play with, and what you think the general threshold may be, I could tweak the timings myself?

It would be great if you can tweak code and test it in quick turnaround.

To get my current working source code repo from github.com run commands below, this is needed just once.

Code: [Select]

git clone -b ibmpc_z150at_fix https://github.com/tmk/tmk_keyboard.git
cd tmk_keyboard/
git submodule update --init
cd converter/ibmpc_usb/

Then, just run 'make' command to build firmware in 'tmk_keyboard/converter/ibmpc_usb/' directory.

Code: [Select]

make
You will find firmware file 'ibmpc_usb.hex' in the directory.

The current firmware should work with Z-150 AT until you press CapsLock, NumLock key.
Let me know one you can get this working on your side.

[acid2000]

I bridged J1 in my Pro Micro, very little changed.

Teensy should arrive in the next few days. If it doesn’t work with that then it’s TMK otherwise it is the Pro Micro.

[acid2000]

So I got the teensy 2. Wired it up with 1k pull ups and I still have problems.

I’ve attached the results of holding down Q for about 1m. You can see the incorrect key presses at the end.

Given I’ve now changed the hardware can we agree that this is a bug in TMK?

[hasu]

So I got the teensy 2. Wired it up with 1k pull ups and I still have problems.

I’ve attached the results of holding down Q for about 1m. You can see the incorrect key presses at the end.

Given I’ve now changed the hardware can we agree that this is a bug in TMK?

Thanks for the test. Can you attach it again or just post it with code tag?

[Maledicted]

I haven't touched anything else with TMK yet, but I got one of those Monoprice adapters in. I initially didn't bother trying one since I literally bought every single design that looked different from one another in their listings and tested them previously. None worked, at least 2-3 ended up looking exactly the same as each other even though they didn't in the listing, and the Monoprice one actually looks a lot like most of those ones that matched.

The Monoprice adapter did, in fact, end up working with the beige label Z-150 though. Same thing as the first firmware you got working with it. 100% function other than the lock lights not illuminating.

[hasu]

I haven't touched anything else with TMK yet, but I got one of those Monoprice adapters in. I initially didn't bother trying one since I literally bought every single design that looked different from one another in their listings and tested them previously. None worked, at least 2-3 ended up looking exactly the same as each other even though they didn't in the listing, and the Monoprice one actually looks a lot like most of those ones that matched.

The Monoprice adapter did, in fact, end up working with the beige label Z-150 though. Same thing as the first firmware you got working with it. 100% function other than the lock lights not illuminating.

The Monoprice adapter did lock lights for other AT keyboards?
And it can handle F7 key correctly? This post on Deskthority referred the key.

https://github.com/tmk/tmk_keyboard/wiki/IBM-PC-AT-Keyboard-Protocol#monoprice-ps2-converter-bluecube

[Maledicted]

I haven't touched anything else with TMK yet, but I got one of those Monoprice adapters in. I initially didn't bother trying one since I literally bought every single design that looked different from one another in their listings and tested them previously. None worked, at least 2-3 ended up looking exactly the same as each other even though they didn't in the listing, and the Monoprice one actually looks a lot like most of those ones that matched.

The Monoprice adapter did, in fact, end up working with the beige label Z-150 though. Same thing as the first firmware you got working with it. 100% function other than the lock lights not illuminating.

The Monoprice adapter did lock lights for other AT keyboards?
And it can handle F7 key correctly? This post on Deskthority referred the key.

https://github.com/tmk/tmk_keyboard/wiki/IBM-PC-AT-Keyboard-Protocol#monoprice-ps2-converter-bluecube

You are a hawk. Good call on F7. It does not work with the Monoprice adapter. I'm pretty sure that it worked with straight ps2 on the HP. The lock lights do work with the NEC APC-H410EA I tested with, and so did F7.

I flashed back to the first TMK firmware that that allowed full function sans the lock lights and confirmed that F7 works fine with the beige label Z-150 that way.

[hasu]

Maledicted,

Can you try this firmware with Z-150 AT and post hid_listen log?

https://raw.githubusercontent.com/tmk/tmk_keyboard/80a172448cebce73d232746ea0f8bd05934cb88c/converter/ibmpc_usb/binary/ibmpc_usb_atmega32u4.hex

I like to know if it shows 'PRT:11' instead of 'PRT:10', the firmware can recognize Z-150 AT specific protocol now.
Also press CapsLock to see how it goes in log.

Code: [Select]

Waiting for new device:.......
Listening:


TMK:a709d822/LUFA


USB configured.

Keyboard start.
I428 wFF rFA A1433
PRT:10 ISR:FE90 rAA W1785 R2286
ID:0000(2) S2286 L2286 r29 rF0 r29


[Maledicted]

Maledicted,

Can you try this firmware with Z-150 AT and post hid_listen log?

https://raw.githubusercontent.com/tmk/tmk_keyboard/80a172448cebce73d232746ea0f8bd05934cb88c/converter/ibmpc_usb/binary/ibmpc_usb_atmega32u4.hex

I like to know if it shows 'PRT:11' instead of 'PRT:10', the firmware can recognize Z-150 AT specific protocol now.
Also press CapsLock to see how it goes in log.

Code: [Select]

Waiting for new device:.......
Listening:


TMK:a709d822/LUFA


USB configured.

Keyboard start.
I428 wFF rFA A1433
PRT:10 ISR:FE90 rAA W1785 R2286
ID:0000(2) S2286 L2286 r29 rF0 r29


Alright, interesting results with this one. I flashed your new test firmware and now all 3 lock lights flash on, flicker, and then shut off whenever pressing caps lock or scroll lock. Until the lock lights shut off again, the keyboard doesn't respond to key presses, but resumes doing so after they do shut off. It does the same thing, in all regards, if I press l press caps lock on another connected keyboard. Pressing num lock works like the first working firmware in that it toggles num lock, but the lights do not react. I can type immediately after pressing this lock key.

I noticed that, sometimes, pressing caps lock will lock up the whole board and I have had to pres caps lock on another keyboard to return functionality to the Z-150. In these cases, the board doesn't seem to send any output related to having pressed caps lock to the computer until pressing caps lock on another keyboard and pressing a key, in which case it belatedly sends both.

This is the result of connecting the Teensy with the keyboard attached, and then pressing caps lock:

Keyboard start.
I250 wFF A1253
ERR:17 ISR:6A90
PRT:11 ISR:0000 X1755 rAA W2198 R2699
ID:0000(2) S2699 L2699 r58 wED
ERR:11

[hasu]

Alright, interesting results with this one. I flashed your new test firmware and now all 3 lock lights flash on, flicker, and then shut off whenever pressing caps lock or scroll lock. Until the lock lights shut off again, the keyboard doesn't respond to key presses, but resumes doing so after they do shut off. It does the same thing, in all regards, if I press l press caps lock on another connected keyboard. Pressing num lock works like the first working firmware in that it toggles num lock, but the lights do not react. I can type immediately after pressing this lock key.

Can you post the whole of log outputs during this process?

I guess the keyboard seems to wait for signal or something after the covnerter tries and fails to send 'set LED' command. I don't know why NumLock  behaves diffrently from other Lock keys, though.

I noticed that, sometimes, pressing caps lock will lock up the whole board and I have had to pres caps lock on another keyboard to return functionality to the Z-150. In these cases, the board doesn't seem to send any output related to having pressed caps lock to the computer until pressing caps lock on another keyboard and pressing a key, in which case it belatedly sends both.

Another 'set LED' command caused by another keyboard may recovers from lockup somehow.

[hasu]

Updated firmware.  commit:7cf306 2020-06-03

Chages since the last update commit:42b7bf:
- Improvement for XT protocol, especially for genuine IBM 83-key keyboard. The converter now should work well with them.
- Fix signaling on how to send command in AT protocol. Realforce 101 failed to receive 'Set LED' commands occasionally.
- Various improvements for compatibility and error recovery

[hasu]

Updated 'Keymap Editor' to add support for hidden keys of IBM AT 84-key.

https://deskthority.net/viewtopic.php?p=467498#p467498

[Diskfix]

Neat stuff. Will the Elite-C https://deskthority.net/wiki/Elite-C also work?

[suicidal_orange]

Neat stuff. Will the Elite-C https://deskthority.net/wiki/Elite-C also work?

The important thing is the microcontroller chip not the USB connector - it will work

[Diskfix]

The important thing is the microcontroller chip not the USB connector - it will work

Thanks! Just got a elite-c with two broken tracks after desoldering with a newer purpose.

[mrdunk]

Just thought i'd post with one success story and one failure.
In my attic a few days ago i tripped over an old keyboard with a nicer mechanism than what i've been typing on recently.
It's a Key Tronic J980405319.
I think i picked it up around 2000-2001. It was likely a few years old when i came by it.

Since i had a Chinese Ardino Pro Micro in my parts bin which i knew could do HID it seemed like a fun day's hacking.

This keyboard has a little switch on the back with the following positions:
 * AT
 * Enhansed AT/XT


Lots of space inside the case for the Pro Micro and i had to disassemble it any way to give all the mechanical parts a good scrub.


Since my multimeter implied there were already pullup resistors in place in the keyboard ps2 circuitry, i didn't bother adding more.
I also soldered the little 5Volt jumper closed to provide the keyboard with it's required supply voltage.

I'm using the prebuilt binary so far from here: https://github.com/tmk/tmk_keyboard/tree/master/converter/ibmpc_usb/binary

So rather than write the firmware myself, i found this project.
I had this up and running in a few hours (including scrubbing the old keyboard clean).
Good job! 5 stars. Would recommend.

So, debug output:
With the little switch set to "Enhansed AT/XT" it worked first time.
Here's the debug output having typed "qwerty[Enter]":

Code: [Select]

duncan@lapdancer:~/Working/hid_listen/hid_listen$ sudo ./hid_listen
Waiting for device:....
Listening:


TMK:0ab0ebf8/LUFA


USB configured.

Keyboard start.
I421 wFF rFA A1427
PRT:10 ISR:FE90 rAA W1720 wF2 rFA rAB r83 R2226
ID:AB83(2) S2226 wED rFA w00 rFA L2234 r15 qrF0 r15 r1D wrF0 r1D r24 erF0 r24 r2D rrF0 r2D r2C trF0 r2C r35 yrF0 r35 r5A
rF0 r5A
Not as lucky with the "XT" setting though.
I get occasional restarts when the bus is busy. "Num Lock" and "Caps Lock" LEDs flash during the restart.
Here's the debug where i plug in the Kbd with switch set to XT, wait a minute (with no restarts) then press and hold down "a":

Code: [Select]

duncan@lapdancer:~/Working/hid_listen/hid_listen$ sudo ./hid_listen
Waiting for device:........
Listening:


TMK:0ab0ebf8/LUFA


USB configured.

Keyboard start.
I418 wFF A1455
ERR:11 ISR:AAA0
PRT:21 ISR:0000 X1957 rAA W1958 wF2 R2494
ID:FFFF(1)
ERR:11 ISR:AAA0 S2495 L2495 r1E ar1E aar1E aaar1E aaar1E aaa
ERR:20 ISR:3D40 [RST] I8261 wFF A9298
ERR:11 ISR:AAA0 X9800 rAA W9801 wF2 R10337
ID:FFFF(1)
ERR:11 ISR:AAA0 S10338 L10338

One theory i want to test is that internal pull up resistors are in place when the the switch is i the "XT" position...
Maybe the XT spec needs them on the host side?
Next time i have the cover open i will measure this.

So what i have is more than good enough; I don't need the XT setting to work but though this anomaly might interest people here.

[hasu]

Thanks for the feedback.

ERR:20 means timeout when reading from keyboard, the keyboard clocking is a bit slow, perhaps.
Other ERRs are expected for XT keyboard and I don't see no problem there.
And pullup resistors don't seem to be related in this case probably.

Can you try attached firmware? This has prolonged timeout parameter.
 ibmpc_usb_atmega32u4.hex (55.14 kB - downloaded 306 times.)

[mrdunk]

Same same with the linked firmware:

Code: [Select]

duncan@lapdancer:~/Working/hid_listen/hid_listen$ sudo ./hid_listen
Waiting for device:.......
Listening:


TMK:7cf3060a+/LUFA


USB configured.

Keyboard start.
I422 wFF A1459
ERR:11 ISR:AAA0
PRT:21 ISR:0000 X1961 rAA W1962 wF2 R2498
ID:FFFF(1)
ERR:11 ISR:AAA0 S2499 L2499 r1E ar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaa
ERR:20 ISR:3D40 [RST] I30017 wFF A31054
ERR:11 ISR:AAA0 X31556 rAA W31557 wF2 R32093
ID:FFFF(1)
ERR:11 ISR:AAA0 S32094 L32094

ERR:20 means timeout when reading from keyboard, the keyboard clocking is a bit slow, perhaps.

Would that cause the apparent restart of the keyboard though? (The "Num Lock" and "Caps Lock" flashing the way they do at power up.)
Isn't it more likely the keyboard restarting is causing TMK to timeout and so displays ERRL20?

[hasu]

Did that reset happen while holding 'A' key or just when releasing the key?

The converter checks time elapsed to received one byte data for error recovery, keyobard hot plug-in and swap. And it resets the keyobard to recover error when timeout error happens.
Timeout parameter is 1ms with default firmware, 2ms for previous attached one.

But keyboard should not take so long but I may be missing something or the timeout error logic may have bug.

Can you try this attached firmwares below?


This has 3ms timeout check.
 ibmpc_usb_atmega32u4_3mstimeout.hex (55.14 kB - downloaded 290 times.)

And this one without tiemout check.
 ibmpc_usb_atmega32u4_notimeout.hex (54.98 kB - downloaded 292 times.)

[mrdunk]

Did that reset happen while holding 'A' key or just when releasing the key?

While holding it.

And it resets the keyboard to recover error when timeout error happens.

Understood. Thanks.

ibmpc_usb_atmega32u4_3mstimeout.hex
That seems to have fixed it:

Code: [Select]

duncan@lapdancer:~/Working/hid_listen/hid_listen$ sudo ./hid_listen
[sudo] password for duncan:
Waiting for device:..................
Listening:


TMK:7cf3060a+/LUFA


USB configured.

Keyboard start.

PRT:21 ISR:AAA0 I424 wFF A1461
ERR:11 ISR:AAA0 X1963 rAA W1964 wF2 R2500
ID:FFFF(1)
ERR:11 ISR:AAA0 S2501 L2501 r1E ar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1EI Mashed the keyboard for a while after that without problem.

For the sake of completeness,
ibmpc_usb_atmega32u4_notimeout.hex:

Code: [Select]

duncan@lapdancer:~/Working/hid_listen/hid_listen$ sudo ./hid_listen
Waiting for device:............
Listening:


TMK:7cf3060a+/LUFA


USB configured.

Keyboard start.

PRT:21 ISR:AAA0 I422 wFF A1459
ERR:11 ISR:AAA0 X1961 rAA W1962 wF2 R2498
ID:FFFF(1)
ERR:11 ISR:AAA0 S2499 L2499 r1E ar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aara1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aar1E aaar1E aaar1E aaar1E aaar1E aaar1E aar9E a
Again, i can mash the keyboard with no issues.

I wonder if some sort of autoconfiguration would work here?
When you first power on, start with a very long timeout, flash the Capslock LED while reducing the timeout.
When it eventually fails you have a minimum acceptable  timeout so double it and save the value to EPROM for future boots.

Or just pick a value long enough that it seems to work for everyone and allow users to manually modify it.
(I presume going too long here will lead to poor update speed?)

[hasu]

Thanks for the test.
I'll go with the '3ms' timeout and update default firmware in github repo soon later.

In current firmware the converter detects timout error if signal sequence takes more than 1.0ms. But this seems to be too small for the keyboard and some others. I can't remember why I selected the value but it is too small obviously.

Now with '3ms' paramter the converter waits to receive signal for 2.0ms at least. I don't think there is a keyboard that needs more than 2.0ms. Timeout error and its error recovery are intended to minimize possiblity of wrong key input deu to bad wiring, hot plugin or hot swap. So it is better that the parameter is small value as possible.

Automatic timeout parameter tune like that seems to me too complex and overkill for this purpose. I believe there is no large variety of clocking speed among keyboards.

[mrdunk]

I'd be a little worried that there are other keyboards out there that need a longer delay but whose user does not have the experience to contact you.

If i interpret your explanation correctly it is very unlikely there would be a valid reset after the first few keystrokes.
Also if my keyboard is within the average range, the actual reset takes ~200ms (I'm guessing here but it's a long time).
I don't see much advantage in keeping this number low.

A statistician would probably draw a bell curve around the examples you know about and tell you about the probability of the examples you don't...
Would there be any harm in taking the longest example you have proof of (3ms) and doubling it to catch the untested edge cases? So 6ms.

I have a friend who i haven't talked to in too long that has loads of classic video game equipment. I might send him an email and see if he has any XT keyboards in his collection we can test on... I can send him a pre-programmed board.

As for the actual value of the timeout, it's your project so your choice.
It works well for me as it is.
Thanks for the cool project!

dunk.

[hasu]

Timeout parameter I'm refering is used when receiving data and is not used for keyboard reset.
Its timer starts when receiving start bit and ends with stop bit.

For reference these pics show waveforms of AT/XT keyboard signal, which takes around 1ms to send one byte data.
https://github.com/tmk/tmk_keyboard/wiki/IBM-PC-XT-Keyboard-Protocol#waveforms
https://github.com/tmk/tmk_keyboard/wiki/IBM-PC-AT-Keyboard-Protocol#waveform

[mrdunk]

Thanks for the links; They were simpler times....

Timeout parameter I'm refering is used when receiving data and is not used for keyboard reset.

Yes, but i thought you reset the keyboard if there was an error:

The converter checks time elapsed to received one byte data for error recovery, keyobard hot plug-in and swap. And it resets the keyobard to recover error when timeout error happens.

So if there's a timeout after 1ms (or 3ms on my keyboard) the keyboard gets reset and isn't usable for (guessing a number here) ~200ms.
Since any receive error now leads to the keyboard being unusable for 100s of ms, i don't see the point in picking an aggressively small number for the timeout.

Imagine the scenario where someone's keyboard repeat rate is 10 chars per second (or 100ms between characters).
While holding the "a" down, an error occurs.
With your timeout set to 1ms you notice the error, reset the keyboard and are ready for input again after 201ms.
If you set the RX timeout to 6ms, you are ready for input again after 206ms.
At a repeat rate of 10, you haven't missed any more characters being sent.
Any additional latency is not a noticeable amount of time for the user. (And the keyboard reset is already giving them a much worse experience anyway.)

Or am i missing something?

Anyway,
if i've not convinced you yet, i'll leave it at that.

[mrdunk]

This is fun: IBM's original technical reference for the XT:
http://www.minuszerodegrees.net/manuals/IBM_5155_5160_Technical_Reference_6280089_MAR86.pdf

The interesting bit for this conversation is page 4.33 "Keyboard Data Output"
It's actually quite vague about the exact timing; It specifies the /length/ of a clock pulse:

During each clock cycle, the keyboard clock is active for 25 to 50 microseconds.

but does not specify how long between cycles.
This make some sense on the resource limited systems of the day but there muts have been /some/ timeout otherwise there would be no way to recover from a keyboard malfunction (like you are trying to do).

I think this reference supports my case for avoiding aggressive timeouts though...
I would think that though wouldn't i?

dunk.

[hasu]

Thanks for the links; They were simpler times....

Timeout parameter I'm refering is used when receiving data and is not used for keyboard reset.

Yes, but i thought you reset the keyboard if there was an error:

The converter checks time elapsed to received one byte data for error recovery, keyobard hot plug-in and swap. And it resets the keyobard to recover error when timeout error happens.

So if there's a timeout after 1ms (or 3ms on my keyboard) the keyboard gets reset and isn't usable for (guessing a number here) ~200ms.
Since any receive error now leads to the keyboard being unusable for 100s of ms, i don't see the point in picking an aggressively small number for the timeout.

The timeout error doesn't(should not) occur while normal usage unless keyobard, converter and wiring are falty.
Those critical faults cannot be recovery with converter firmware anyway, you will have to fix hardware problem or a bug in firmware basically.

And note that bigger timeout parameter increases possiblity of wrong or random key inputs. This is not what we want.

Keyboard reset is not necessarily required for recovery if we don't need hot-swap/plugin support.(I want it though) You can clear internal state of the converter to sync next clock signal from keyboard somehow instead of reset. But in the case of hot-swap/plugin it is inevitable for connection to be unstable temporarily, then timerout or other errors can occur. It requires keyboard reset to recover from those errors.

Imagine the scenario where someone's keyboard repeat rate is 10 chars per second (or 100ms between characters).
While holding the "a" down, an error occurs.

Again the timeout error is exceptional and should not happen unless your keyobard and converter are good enough. If you see the error you will have to fix something, such as bad wiring, firmware bug, faulty hardware, or  etc....

With your timeout set to 1ms you notice the error, reset the keyboard and are ready for input again after 201ms.
If you set the RX timeout to 6ms, you are ready for input again after 206ms.
At a repeat rate of 10, you haven't missed any more characters being sent.
Any additional latency is not a noticeable amount of time for the user. (And the keyboard reset is already giving them a much worse experience anyway.)

Or am i missing something?

Anyway,
if i've not convinced you yet, i'll leave it at that.

I'm not sure about this part, you mean 6ms timeout is better?
Anyway, I think you don't have to worry about that.


You can check codes here if you are still interested.

How to detect timeout error:
https://github.com/tmk/tmk_keyboard/blob/master/tmk_core/protocol/ibmpc.c#L248-L267

Check error and keyboard reset(initialize):
https://github.com/tmk/tmk_keyboard/blob/master/converter/ibmpc_usb/ibmpc_usb.c#L131-L146

[hasu]

NIce find. I can't remember I checked this before.

That descriptions in 4.32-4-33 is really useful to grasp how XT protocol works.
(Some clone XT keyboards are clearly not compliant to this, though.)

This is fun: IBM's original technical reference for the XT:
http://www.minuszerodegrees.net/manuals/IBM_5155_5160_Technical_Reference_6280089_MAR86.pdf

The interesting bit for this conversation is page 4.33 "Keyboard Data Output"
It's actually quite vague about the exact timing; It specifies the /length/ of a clock pulse:

During each clock cycle, the keyboard clock is active for 25 to 50 microseconds.

but does not specify how long between cycles.
This make some sense on the resource limited systems of the day but there muts have been /some/ timeout otherwise there would be no way to recover from a keyboard malfunction (like you are trying to do).

Right, XT has no error detection and recovery like that, keyboard interface on host side is comprised of discrete only logic ICs and deliberate circuit without microcontroller. I guess you get garbege input on XT computer until reset if you replug keyboard while it is powered.

I think this reference supports my case for avoiding aggressive timeouts though...
I would think that though wouldn't i?

dunk.

I'm still not sure I understand what your concern is exactly.
Ah, you worry about exsistence of keyboard that takes long beyond 2ms to send data? I think it is slight chance but exceptional example can exist even if the specification clearly define the value.

Yes, bigger timeout parameter can support the exceptionally slow keyboard, but not good for most of keyboards. It increases possiblity of missing timeout error.

I think 2ms is safe enough. And it is worth to get error report from user if keyboard like that really exists.

[mrdunk]

Ah, you worry about exsistence of keyboard that takes long beyond 2ms to send data?

Exactly.
My keyboard needs 3ms when switched to XT when we originally thought 1ms was safe.
There are bound to be other edge cases that are worse.

Yes, bigger timeout parameter can support the exceptionally slow keyboard, but not good for most of keyboards. It increases possiblity of missing timeout error.

What would missing the timeout error look like?
I guess one byte would run into the next, resulting in garbage input until the user stopped pressing keys for as long as the timeout value (and the resulting reset).
Resetting the keyboard because of a timeout is only useful at startup; If you reset the keyboard later, while the user is typing, the keyboard reset is as harmful as missing a timeout.

Anyway,
we disagree but that's ok.
This is an edge case which users can inform you about if it is an issue.

One last clarification,
my keyboard worked with your 3ms timeout firmware in XT mode not 2ms. (Just incase you are using my kbd as the longest supported.)

Thanks for the interesting discussion!

[hasu]

Wait, your keyboard should work with the latest firmware,

I updated  github repo with using '3ms' parameter, which means 'timeout error' happens  when it takes more than 2ms.
This is confusing,  but it is how the firmware works in fact due to timer resolution and timeout detection logic.

You confirmed the keyboard worked with temp firmware with '3ms' parameter. (https://geekhack.org/index.php?topic=103648.msg2928549#msg2928549) So, I think you are ok with the latest firmware too.

Try the latest firmware. Let me know if it doesn't work.

https://github.com/tmk/tmk_keyboard/tree/master/converter/ibmpc_usb/binary

[mrdunk]

You confirmed the keyboard worked with temp firmware with '3ms' parameter.

Yup. It worked with ibmpc_usb_atmega32u4_3mstimeout.hex .

I'll confirm the latest in github works the same later. (Monday morning here. got work to do debugging networking switch firmware.)

[mrdunk]

I'll confirm the latest in github works the same later.

Confirmed. ibmpc_usb_atmega32u4_3mstimeout.hex working with XT mode as described in previous post.

[teliot]

This works with a DTK SPK 101.

Used the github source, compiled and flashed on to an Arduino Micro with Atmega 32u4 over ICSP.
One of the keys registers as Code 86, KEY_102ND and seems to do nothing. The key has no symbol and is located where the Windows key generally is.
All of the other keys and LED's work correctly.

https://imgur.com/a/eQvHA1I

Thank you for all of your hard work on this!
Had my keyboard working in under 5 minutes

[hasu]

This works with a DTK SPK 101.

Used the github source, compiled and flashed on to an Arduino Micro with Atmega 32u4 over ICSP.
One of the keys registers as Code 86, KEY_102ND and seems to do nothing. The key has no symbol and is located where the Windows key generally is.
All of the other keys and LED's work correctly.

https://imgur.com/a/eQvHA1I

Thank you for all of your hard work on this!
Had my keyboard working in under 5 minutes

Thanks for feedback.
The key is recoginized as ISO key located between left shift and z by converter. You can remap it in keymap editor.

[teliot]

That key is located on the right side under the shift key. This unknown key is something else.

Unmodified It types a <
With shift >
With Ctrl <
With Alt (Last command like up arrow)

[hasu]

That key is located on the right side under the shift key. This unknown key is something else.

Unmodified It types a <
With shift >
With Ctrl <
With Alt (Last command like up arrow)

Check 'Debug' in the first post to check scan codes of the both keys.
Posting its output as is would be useful.

[TheNeonKnight]

Quick couple questions regarding the pull up resistor. I'm no expert when it comes to resistors, would the 1Kohm resistor be better than the 4.7Kohm resistor or vice versa, If so why? Does it have something to do with the length of the cable connected to the controller? Also the resistor is supposed to be connected  from VCC 5v to Clock and Data respectively, correct? Does the resistor have to be 1/4 watt, 1/2 watt? These questions may seem obvious but I'm honestly at a loss on this.

[ivanthetolerable]

Hey, is it possible to change the firmware to change PD0 on the teensy to something else? I found a spare teensy I messed up and destroyed d0 a long time ago..

[hasu]

Possible, but it won't be easy.
I don't think it is worth for us trying it. Just buy new one.

Hey, is it possible to change the firmware to change PD0 on the teensy to something else? I found a spare teensy I messed up and destroyed d0 a long time ago..

[Wumbologist]

Hey Hasu. Can confirm this works on my Z-150 black label. Using a ProMicro.

[hasu]

Great! Thank you for your report.

Hey Hasu. Can confirm this works on my Z-150 black label. Using a ProMicro.

[Wumbologist]

Also, I doubt this is a keyboard even on your radar for this project, but my FK-8000 is almost working with it. The only thing not working is the blank key where LGUI should go.

Chyros describes the issue here at timestamp 5 minutes.

I'm getting the same scancodes as him in Switch Hitter. 0xE2 Win, 0x56 BIOS.

[hasu]

Great.
I think there was no standard scan code for the key in keyboard from that era, and guess it was defined by microsoft after introducing windows 95.

I guess you are using US layout?
It seems the 0x56 is correct for scan code.  In that case the converter should recognize it as 'non-us #'(ISO) key, you will have to change to UK or other ISO keyboard layout on your OS to use the key. Or you can remap the key by editing ISO key on Keymap Editor.

[Wumbologist]

Ah I see. Changed NUBS to LGUI in my keycap.c and now I've got a much more usable layout. Thanks!

[therealding]

I'm getting a lot of key chatter or freezing with this converter vs Soarer's

[uhhuhhuny]

Seems to work for FK-2001 (102 Asian layout) for both AT/XT