IBM XT Converter generally unreliably #635
Comments
|
I've done a lot of work to bottom out the issue. You can find further details here: |
|
Try the TMK binary with 1K pull-up resistors. 9K ohm you are refering here may be too weak and the external pull-up resistors are must-have. You can't depend on chip's internal pull-up's. How we can reproduce the issue? And supply outputs on hid_listen when it happens. |
|
I’m going away for a few weeks. When I get back I’ll provide the output. My QMK ticket has the output of their QMK toolbox tool which has the scan codes. The biggest problem I have with changing the resistors is that it works perfectly fine with Soarers converter ( internal pull-ups alone ). If it was a pull-up problem I should be seeing this all the time with soarers, right. It’s also worth changing the documentation on the converter if 1-10k is no longer recommended. |
|
It would also be great if there was some confirmation that this issue can/can’t be reproduced with the latest codebase. I’ve got two setups, different keyboards and wiring and can see the same on both. Just hold down Q was wait for faults at around 600 characters. |
|
No hurry, take time. TMK emulates how original XT PC handles signals from keyboard as possible and it reads data line at diffrent timing from Soarer's. Weak pull-up resistors may cause problem. At least users have not reported similar issue in the thread so far. You may want to post there to ask people. I don't have 5150 keyobard though, I'll try the 'holding Q' test when I get time anyway. |
|
Tested holding Q for 5 mins and no issue happened in my site. |
|
So i've now changed to 1k pull ups. It seems better but I still have issues. Notice the stray 21's Waiting for device: |
|
Are you sure using genuine TMK firmware? You should see lines following lines with the firmware. Did you omit the lines on your previous post. If you are using the correct firmware I don't have idea now. Post here when you find new clue. And you can press |
|
Yes I’m using the firmware you linked in this post. I cropped stuff out of hid_listen. I didn’t see those other lines in the tool. |
|
Cross posted from the Geekhack forums for completeness. textTyped.txt
|
|
I’ve now complete replaced the wiring and have moved to a teensy 2.0. Very similar issues. |
|
Hello! I am having the same issues too. Tried pull up resistors with a separate power source and without. It works fine with soarers on a teensy 2.0. Usually it'll work for a few seconds, and then jam up. It seems that Ctrl gets stuck on and the f key gets jammed on also. If I hit space after the f key goes nuts, it'll stop, but Ctrl still seems to be jammed. Usually Ill get the phantom key presses even when it is just sitting, but it takes a bit longer. Now, some side notes. I am using a Adafruit Feather ATMEGA32u4 to run this thing. And the only way I could get the converter to not output a device descriptor error on windows immediately was to set the processor frequency to: Which, if I had to take a wild guess, may be messing with the timing of the key codes Then it'll connect properly. That and the bootloader are the only things I've changed from stock code. Here's the output I get from QMK Toolbox HID Console with the caterina bootloader with no interaction: *** QMK XT Keyboard converter (FEED:6512:0001)
*** HID device disconnected (FEED:6512:0001) Heres HalfKay bootloader (same device) with random typing, but not holding any keys: *** HID device connected: QMK XT keyboard converter (FEED:6512:0001)
For whatever reason the halfkay bootloader seems to work better, with it not doing anything while being left alone. Still got phantom key presses during typing, no Ctrl issues thus far, still have the F_CPU set to 8000000. My gut tells my it's a clocking issue somehow.... I'm new to the TMK/QMK world so I'm still figuring this stuff out. Probably an easy and dumb solution. Thanks for any suggestions or help! |
|
Interesting you mention the F key. With my Q test when it faults I get Fs. |
|
Worth also mentioning is that my 5150 has absolutely no reset pin, the header inside is missing the connection. |
|
It is rather remarkable that the letter f shows up. I noticed in a previous bug report acid2000 had this same letter give him fits. |
|
Why F instead of Q? According to the docs XT outputs scan set 1 which TMK takes and outputs as USB. I’ve looked up the Q and F scan codes. I think these are 10 and 21 respectively. If I’m right in binary this is: They have very similar representations in binary, and if F was shifted right then they would be the same. My guess is this is what TMK is doing probably because for some reason it is not reading data at the right time. |
|
XT converter has issue that can miss start bit signal possibly. I think the issue was fixed somehow in IBMPC converter. But I still don't totally know why phantom key press happens without touching keys. Can you test with this a bit old prebuild firmware of IBMPC converter? |
|
BTW, thanks for the help! Everything from "OK there it went" down I used another keyboard for. |
|
No problem! Thanks for your time. |
|
I tested the firmware you linked above. Generally it is much better but I still get an F instead of a Q. I think the error rate has gone from 1/200 keys to about 1/1000. |
|
@i-am-shodan Thank you for the test. On IBM XT keyboards Q(10h) should be read on signal line as below: https://github.com/tmk/tmk_keyboard/wiki/IBM-PC-XT-Keyboard-Protocol#1-ibm-xttwo-start-bits But firmware read the start bit(0) as 1 wrongly, and recognized as F(21h) as if it is on XT Clone keyboards. https://github.com/tmk/tmk_keyboard/wiki/IBM-PC-XT-Keyboard-Protocol#2-clonesone-start-bit The firmware seems to be still slow to read start bit(0) correctly, this is root of this problem. This makes totally sense to me now, though, I optimistically expected that this happens more rarely. The firmware should be fixed to read the start bit(0) correctly and I wan to do that, but it is difficult and time consuming job if it is possible. I added adhoc error check for this problem and I think this works for actual use. I can't test the error check code at all because of luck of IBM XT keyboard in hand, though. But I still don't have clear idea on a lot of ramdom key and phantom key press that reported before, recent code changes may cause somehow. Can you try these firmwares? "A bit old firmware"(which I linked above) with the error check. The latest firmware with the error check. You will see 'XT_ERR' in hid_listen log when the start bit(0) occurs. And the converter should read scan code correctly even with the error. |
|
Thanks for looking into this. I will test the FW tonight or tomorrow. I may end up recompiling them as I need a custom key map. The XT doesn’t have a pause key which makes getting into the bootloader a pain. Worth saying I don’t get any phantom key presses. I tested before (last year I think) and I did then so I think that has been fixed. The only problem I have is misrepresenting a keypress for another. Keep up the good work, feels like it’s one bugfix away from working well. |
|
I would love to know how Soarers converter works around this. It seems to accurately catch the start(0) bit. I tried to reverse engineer the firmware with GHIDRA but without an integrated simulator/debugger it is incredibly difficult to get a handle on how it operates. |
|
OK. So, this is inexperience talking here, but isn't the ATMEGA32u4's internal clock rather inaccurate? From what I was reading it has a sufficiently accurate clock for basic timers and the like, but for anything accurate, it isn't terribly great. (Again, my understanding is rather rudimentary, so this is kinda spitballing) https://hackaday.com/2013/01/03/accurate-timers-with-an-avr/ At the speed that some type and/or holding a button, might the clock get thrown off and miss or mess up the starting bit? I would assume it gets "reset" somehow when there is a break? I'm currently on the old bit firmware with error handling you posted and it just went bonkers. Here's the output: `*** HID device connected: t.m.k. IBM PC keyboard converter (FEED:1BEE:0001)
|
|
My speculation is that Soarer's reads data line at rising edge of clock, it is not difficult to read the start bit and read data as below in that case. IBM XT: start(1), bit0, bit1, bit2, bit3, bit4, bit5, bit6, bit7, stop(0) Reading at rising edge works with IBM XT keyboards and some clones but it is not how original XT host does and won't be compatible with a few clone keyboards. I have tried to emulate XT keyboard interface comprised of TTL descrite ICs as possible but my codes misses out the first start bit. I'll have to polish my ISR code, where its function prologue that pushs regsiters into stack take time. https://github.com/tmk/tmk_keyboard/wiki/IBM-PC-XT-Keyboard-Protocol#host-side-schematics |
|
So I switched to the other firmware you posted and it lasted less than a minute. It kept switching focus off the window as I was trying to type, and then went completely berserk. Once it went off, I didn't touch the keyboard till it stopped. Here's the output of that one: `*** HID device connected: t.m.k. IBM PC keyboard converter (FEED:1BEE:0001)
|
|
OK. I think I get basically what you're saying. I have some reading ahead it looks like! Thanks again for you're help sir! |
|
I think there may be an issue with my keyboard, Soarers is now freaking out. There may be a bad connection in my wiring job. I have my keyboard open for the resistors and i think I may have wiggled one of the wires loose. In light of this, the data may be inaccurate. Probably wait for i-am-shodan before doing anything. Meanwhile, I have some soldering to do. |
|
Sorry about the code formatting thing. This is my first go with posting on GitHub (as you probably can tell) |
|
My prebuild firmwares are compiled with 16MHz configuration and they don't work with Adafruit Feather with 8MHz crystal. Current firmware is written for controller with 16MHz crystal. Use Teensy2.0. |
|
I got an afternoon of running Ethernet, so I'll have to get back to you tomorrow once I get the wiring fixed. |
I’m not sure if this is good news or bad news. I ran both of the firmwares and even checked the version info with the magic+V command to be sure I flashed the right ones. Neither firmwares showed an error! I held down Q for around 3 minutes must of been a couple of hundred key presses. I’m assuming your interrupt handler in these builds is quicker? Do you have any good tests I could run that might trigger it? |
|
Thanks for the test. I believe the interrupt handler works at same timing as before and it still misses catching the start bit(0). It seems like the error checking(and recovery) code works somehow, but it fails to display the error message probably. Good to hear that there is no difference between the two revisions for firmware. I'm working on merging this error checking code into master branch in addition to other updates. |
|
I just updated repository. This is prebuilt firmware file of the latest repo. @i-am-shodan I think the start bit(0) error will happen with holding down Q for a few mins as before. And you will see its error message like |
|
So, after a rewire ( it looks like a loose solder joint was doing some wacky stuff to the converter) I got the keyboard working just fine with Soarers again. I reflashed TMK and held the q button for two minutes. No issues. But as I'm typing this there was something that just popped up in the hid output Ill post here. Ill keep using it and see what else pops up. Thanks again for the help! |
|
So, another bug I found is the Num Lock button throws an error when pushed and the 0 button doesn't output anything outside of hid_listen |
|
I’m now running master with a custom layout but it looks like Num Lock is working AND outputting an error. 0 works for me when NumLock is pressed(but remember I have a custom layout) |
|
@i-am-shodan @DalvikVM The start bit(0) error recovery logic seems to be work well. The The Also can you test for 'keyboard buffer full'(Overrun) error? |
|
Well, I got this as soon as plugged in my keyboard this round. I wonder if theres a short somewhere... |
|
@DalvikVM What is actually your keyobard model number? |
|
Log below, no issues I noticed. Waiting for device: ERR:F0 |
|
I’ve now been running the ibmpc firmware with a custom key map for a day as my main keyboard. Some thoughts:
I would probably get rid of the XT converter source tree just to prevent people trying to use it. |
|
@i-am-shodan @tmk I do believe you are correct. My keyboard came with the cord hacked off and I've been using the wire and end that was left inside the keyboard to attach to the teensy. When I move the wires by the keyboard, it freaks out, so the connector is bad. I've always used the connectors when rebuilding these keyboards, do either of you have a suggestion to replace them? Thanks! |
|
My teensy is hanging off the header inside. The spiral cord was just too heavy for my liking. |
|
Yeah, I think its gonna work now. I forgot to reinstall the ground screw in the main board. It must've had good enough of a connection to function for a while, but finally got loose again when I pulled it apart this time. Thanks for the help, both of you! Would it be hard to add these code changes into qmk? Would it be something I could do? I'm trying to build a bluetooth version with Adafruit's ATMEGA32u4 with bluetooth. QMK has the built in option to use it. OK, I'm lazy, I get it. ;P If its a big deal, don't bother. Here's the key mash: |
|
Here's a pic of what I've got internally btw, if you're interested... |
|
Ok. I'm partway through porting the ibmpc_usb over to qmk. Provided everything goes well I should have a working version soon... |
|
@DalvikVM |
|
Can anyone test fixed firmwares with IBM XT keboard? That log output means that the firmware still misses start bit.
|
|
I'll give it a go as soon as I can. Might be a few days though. Thanks! |
|
So the first firmware looks like it’s fine. I held down Q for about 5 minutes, no issue. The second one has problems. I flashed it twice and couldn’t get a single key out. |
|
Thanks for the test. Did the second one display anything in hid_listen log? It works with my AT keyobards2 |
|
I didn’t see any PRT:23 messages in the log and in the second firmware the teensy didn’t even come up as a USB device. |
|
OK. I'll update firmware in main branch with change of the 1. I can't know why the second firmware doesn't work but |
|
Thank you, guys. Feel free to open new issue if you find any problem. |
I've been doing a lot of testing between Soarer's Converter, TMK and QMK to find what is best for my IBM 5150. This issue is a way of stopping people wasting their time.
By far the most reliable for daily use is Soarer's converter. It seems to have no issues with any of the three keyboards I tested with. TMK & QMK seem to have persistent issue interpreting the protocol correctly. This eventually results in either phantom key presses or stuck keys.
I tried a number of different power supplies to ensure this wasn't a result of undervoltage. The issues persisted.
My recommendation is not to use the XT converter for these keyboards.
The text was updated successfully, but these errors were encountered: