rasteri
DEC VT520 Incompatibility
Hello, I've recently put one of these together (parts ordered from https://retrohackshack.com/product/hidman-usb-keyboard-converter/), for use with a NiZ Plum X87 keyboard and my Digital Equipment Corporation VT520 terminal. Problem is, the mapping is pretty strange - the terminal is recognizing F10 as Print Screen and Ctrl as Caps Lock. The arrow keys don't seem to work either. Esc becomes numlock, and the terminal doesn't even seem to recognize F1-F8.
These older VT5XXs expect a pretty specific keyboard layout when using what DEC dubs a "PC keyboard" (see https://www.manualslib.com/manual/1200903/Digital-Equipment-Vt520.html?page=28#manual).
It's worth noting that the NiZ has a PS/2 mode that I've tested with a passive adapter, and gotten the same results with.
I would like to contribute patches to fix this incompatibility, or even just maintain a fork for this purpose, but I'm not sure where to start. I don't have any other devices that natively use PS/2 (I'm assuming I could get scancodes from the VT keyboard using a passive PS/2 to USB adapter, though).
Any pointers would be appreciated.
I forgot to note this in my original issue. I saw there's a "log HID data" option in the settings - want me to hook the terminal up to a computer, and attach a file after I press every key on the keyboard?
Grab the latest beta version and see if that changes anything - https://github.com/rasteri/HIDman/releases/tag/v1.1.5f
But a HID log would be useful, yeah.
What to do is, enable HID logging, then plug/unplug your USB keyboard so it captures the initialization. Also press some of the keys that are misbehaving (I don't need every key).
Try it again in advanced keyboard mode, too.
Also it would be useful to establish if it's the keyboard or the terminal that has the issue with hidman - if you have a regular ol PC you could try it on that
These are in this order:
- up arrow
- left arrow
- down arrow
- right arrow
- F1
- F2
- F3
- Esc
Unfortunately, I couldn't capture the replug - the VT520 briefly shuts off power through the PS/2 port when it detects a keyboard has been unplugged. Captured using 1.1.5f.
I don't have anything else with a PS/2 input, but my guess would be the terminal. I can test soon if a passive PS/2 -> USB adapter would work, and re-run these tests. If not, I can obtain a machine with native PS/2, but it might take a bit.
Something else notable is that the terminal makes a noise using its built-in speaker when it detects a keypress - the alphanumerics work totally normally and make the noise, but F1-F3 and the arrow keys (among others) don't make the noise, implying the terminal doesn't even know what to do with the signals it's getting.
Ah yeah, even the menu is corrupted. That's definitely an issue with the HIDman<>terminal connection rather than USB
Those PS2-to-USB adapters also produce corrupted output. HIDman does seem to have issues with a number of non-pc PS/2 devices. It's pending investigation, hopefully if I fix the ps2 adapters that'll fix stuff like your terminal too.
Thank you for opening this bug. I am interested in being able to use nicer keyboards with my VT520 and a VT525. I haven't received my adapters yet (based on the hope!) but please let me know if there is any thing I can do to help once I get them.
Is there a chance the hidman is sending the menu text too quickly? I can't keep my vt520 from being corrupted if I use much faster than 9600 baud so I keep it there. I'm sure it would choke if the text were too quick.
Yes that is very possible, the next version of the hidman firmware will have optional rate limiting. Also I've just been generally doing some work around troublesome ps/2 hosts so I think when 1.1.5 is finished it should work better with non-PC hosts
I had forgotten about this for a while. I see 1.1.6 released now. If anyone has any news please post, otherwise when I get a chance I'll test this (and perhaps try limited the data rate) and report back.