Vintage AT keyboard causing ps/2 errors due to slow clock signal.

[dualrange]

Hi all, this is my first post here but not the first time I've ended up here for help. I've been posting into the void on a keyboard forum and decided I needed some real nerds to help me out. 


I've got a 1992 vintage Focus FK-2001 pc/AT keyboard converted to USB via a pro micro AVR board running the soarer's converter abandonware standard.

I don't have a din->ps/2 converter to test this keyboard out natively, otherwise I would have tried. I am thinking about picking one up though. 

My debugging progress so far is here https://deskthority.net/viewtopic.php?f=7&t=26186&p=492104#p492104

but a short synopsis:

Certain keys apparently grouped by possibly rows or columns work perfect, a lot of keys do not, enough keys its unlikely that all the switches are failing. I borrowed a logic analyzer from work and took a peak at the ps/2 signal. The keys that behave, do just that, but the misbehaving keys are causing the host(pro-micro) to request a resend to the device.

When I looked closer, I found that the clock is averaging about 20% above the max allowable ps/2 spec. I replaced every capacitor I could find, measured the crystal oscillator at the rated 6Mhz that provides a clock to the micro controller that acts as the keyboard driver.

I'm really hoping I'm not seeing a dying keyboard driver because they're basically impossible to find and having written a keyboard driver in the past, I'd prefer to avoid doing it again.

[magic]

Dunno, figure out what are the (raw, untranslated) keycodes that fail and what they have in common.
See if clock and data transitions are aligned correctly.
See if the edges are rising fast. An old trick was to add more pullup resistors on the lines.

See what causes the firmware to request resend. That's some weird stuff.

In principle, a naive bitbanging host wouldn't mind the clock being a bit out of spec if it simply waits for the clock to transition and then samples a single data bit immediately afterwards. Maybe the clock wait timeout is set right at he limit of the spec.

[amyk]

PS/2 is a synchronous protocol so it should be able to operate across a relatively wide range of reasonable clock frequencies, but you may be hitting a timeout in the firmware.

I've got a 1992 vintage Focus FK-2001 pc/AT keyboard converted to USB via a pro micro AVR board running the soarer's converter abandonware standard.

Try a real motherboard PS/2 port. I suspect it may be far more lenient with timeouts.

If I weren't so occupied with work and another analysis currently, I'd help with figuring out whether the firmware is indeed timing out, and how it can be patched to extend the timeout. But trying it with a real standard PC PS/2 port will isolate the problem.

I don't have a din->ps/2 converter to test this keyboard out natively, otherwise I would have tried. I am thinking about picking one up though.

All you need is a roll of wire and a soldering iron... 

[floobydust]

The hypothesis about the clock frequency being the problem might be wrong, and it's a resonator not quartz crystal.

I would look for shorted mux diodes or even a stuck key that would issue alien keycodes. Not a stuck alphanumeric but the alt/function/shift/crtl etc. modifiers.
Open mux diodes, or a broken pcb trace cause an entire dead bank of keys. I find these are the most common failures, electrolytic capacitors as well.
VDD should be up at 5V not 4.75V which seems too low.

[magic]

I bet it's not a dead bank of keys but a dead bank of keycodes which the USB converter fails to recognize for some reason.

Dig into the code and find out what triggers retransmission requests.