AT Protocol issue with Comp Key keyboard.

[PaulW]

This worked! -- that's interesting -- I wonder if that's an issue with docker or the docker configuration files... either way might be a good idea to put that work around in the build instructions for the time being?

Thanks for the help!

I have a "Comp Key" keyboard mech with an AT/XT switch -- the AT signaling is not quite AT and the XT signaling is bog standard. SO I figured I would use this project to make a profile to use the keyboard.

Originally posted by @lindoran in https://github.com/PaulW/rp2040-keyboard-converter/issues/6#issuecomment-2426335357

[PaulW]

@lindoran could you please check against the following branch?

https://github.com/PaulW/rp2040-keyboard-converter/tree/stop_bit_test

I've removed the validation check for now against the Stop bit, as this is the only thing I can initially identify which may be causing the issue if it is indeed following the method used by the Z-150 where the Stop Bit is LOW and not HIGH when receiving data from the keyboard.

Also, if you have a USB to TTL Serial adaptor (or another way to interface), please can you connect to GPIO pins 0 and 1 (TX and RX) on your WaveShare RP2040-Zero, as this will allow you to read the output to try and understand where the AT protocol may be failing.

[lindoran]

I might not get a chance to check for a bit of time depending on how much time I get at the bench this week. I am currently splitting my efforts between launching an open hardware project and playing around with the keyboard. I'll definitely have some time over the weekend. I have an oscilloscope and a logic analyzer so we can probably check out signals that way too the biggest issue Is I don't actually have the native computer motherboard that goes with it, and probably will never have it. What I bought was just the case, keyboard mech and floppy drive. The motherboard and graphics card all fit inside the keyboard, kind of like an Amega 500 but a 386. Generally speaking it does seem to be initialized like an AT keyboard so it should work, it just doesn't -- that being said I haven't tried with an actual AT motherboard -- so I'm not 100% if it should work that way either... I couldn't get it to work with PS/2 either.. The stop bit issue is a good place to start as any.

On Tue, Oct 22, 2024, 8:02 AM Paul Bramhall @.***> wrote:

@lindoran https://github.com/lindoran could you please check against the following branch?

https://github.com/PaulW/rp2040-keyboard-converter/tree/stop_bit_test

I've removed the validation check for now against the Stop bit, as this is the only thing I can initially identify which may be causing the issue if it is indeed following the method used by the Z-150 where the Stop Bit is LOW and not HIGH when receiving data from the keyboard.

Also, if you have a USB to TTL Serial adaptor (or another way to interface), please can you connect to GPIO pins 0 and 1 (TX and RX) on your WaveShare RP2040-Zero, as this will allow you to read the output to try and understand where the AT protocol may be failing.

— Reply to this email directly, view it on GitHub https://github.com/PaulW/rp2040-keyboard-converter/issues/7#issuecomment-2429226239, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQIK5ZHMKF5JRQ2JGFQJMCTZ4ZEFHAVCNFSM6AAAAABQMOAEKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRZGIZDMMRTHE . You are receiving this because you were mentioned.Message ID: @.***>

[PaulW]

No worries, honestly just raising the issue is enough to get me putting a bit of thought into it! I can only test as much as I can with what I have currently, so it's good to know when something isn't quite right with something else! I did do some reading on what your board was for as good as I can and it looks like a really interesting piece of kit!

[lindoran]

Paul,

So I got a chance to look at this - I just dropped the test build for the model F onto the dev board and flipped it into AT mode -- just to make sure I was getting the same results I was getting with my PS2 cable and interface... wouldn't you know now it works (mostly -- the key map is wrong so some keys don't work.) but where the keys line up its fine. So now I am assuming its something with the initial initialization (or) some other discrete incompatibility when plugged with an adapter into a PS/2 port. As a matter of fact, I am typing this with the key mech and it is quite responsive. So that being said, it appears the issue is when plugged into a PS/2 port it doesn't work, but plugged into the rp2040 keyboard converter its fine. I did go back and try the mech on a much older ps/2 port on my PS/1 2155 and the keyboard is less responsive there (virtually no response at all). It might also be power availability some other issue like that. The internal header only has 4 pins hooked up and the reset pin on the keyboards MCU is tied to an RC network so it just resets 1x with power on and the bi-directional reset command is what resets it.. I had a look at the actual output stage of the keyboard and it has a open collector buffer inverter (like usual) and pull up resistors to VCC. values for the pull ups look quite low - 2K. That's not super unusual but would draw a lot more current than say a 4.7k pull up if the line were pulled low and the edge rate would be super fast. I suppose it COULD be just a simple case of not enough power at the +5v pin in the thin client and the PS/1. but the mech itself only draws like 80mA according to my bench top power supply... So its kind of a good news bad news thing. Good news is it works. But I don't think its the stop bit in this case because it just responds to the interface exactly like a Model F would.