deskthority

As we have discussed here Soarer's converter is not completely compatible to XT keyboard protocol, it works with many of XT keyboards while it doesn't with some of them including Zenith this Z-150 XT and a few rearely boards unfortunately. TMK XT firmware is implemented carefully in conformity with design intention of original IBM XT keyboard protocol to support virtually all of existent XT keyboards, I hope so at least.

TMK XT keyboard converter thread:
https://geekhack.org/index.php?topic=94649.0

For people who intrerested in detail of the protocol this wiki page would be helpful.
https://github.com/tmk/tmk_keyboard/wik ... d-Protocol

1. TMK doesn't use the LED at this point and I don't know about Soarer's.
2. I think it should work if you upload the firmware and connect correctly. Wire connections are compatible to Soarer's converter and you can upload Soarer's firmware to test you wiring, it should 'kind of' work as you described.
3. edit keymap file and compile.
4. yes. Just upload it depding on dev boards. Consult with the board's manual/tutorial you can find it easily with web search.
5. maybe. But I won't do that for a while. You can learn how to build firmware yourself.

I beleive someone more helpful to you comes in.

@Hasu, thanks for replying. As I said in the edits to my post:

I used the PS/2-USB Converter rev. 1 on the Hasu TMK Editor site to generate a modified hex file. I substituted the actual key functions rather than the spatial location of the keys. I uploaded the new hex file into my Teensy 2.0 setup, and it worked! I now seem to have a correctly functioning Z-150 keyboard with my HHKB-ish layout.

However, when I tried this with a Pro Micro using QMK Toolbox, it didn't work. QMK Toolbox showed that the flash was successful, but I could not get any response from the keyboard.

I might try this with a new Pro Micro. On the other hand, because it works with a Teensy 2.0, I may go ahead and make the converter with the Teensy. However, I need to do more typing tests first to be sure that there are no more missed or repeated key presses.

EDIT:

I am typing this on a Zenith Z-150 100-1886 Black Label XT-type keyboard using a Teensy 2.0 and a customized hex file generated using Hasu's online TMK editor. I used the PS/2 to USB rev.1 as a template and revised Hasu's latest XT hex file using the functional definition of the keys rather than their spatial location on the keyboard. I used the teensy.exe program in Windows to upload the hex files to the Teensy 2.0. I tried it out using a breadboard prototype with and without a 1kOhm pull-up resistor between Clock and Vcc and between Data and Vcc. The converter worked both ways, so I decided to simplify and wire it up without the resistors.

I have now done typing tests, and thus far, all the former problems have disappeared. No more unwanted key presses or missed key presses. In addition, the Right Shift no longer intermittently behaves as if it were the Caps Lock key.

Again, I have tried this using a Pro Micro Orihalcon internal converter that had been flashed with Soarer's converter. I used qmk_toolbox.exe to reflash the Pro Micro. The software indicated that the reflash was successful, but I cannot get any response from the keyboard. I think that the apparent discrepancy between the Teensy and the Pro Micro might be due to the different pin assignments.At some point, I might try revising the configuration file, but for the time being, I am going to use the Teensy with the teensy.exe loader software.

More's the pity, because the qmk_toolbox mades reflashing the Pro Micro very easy. You check the Auto-flash box so that it automatically loads the hex file when you reset the Pro Micro by shorting the reset and ground pins. With other software, after shorting the pins, you have 7 or 8 seconds to upload the hex file before it exits from upload mode.

BTW, I have been using Switch Hitter software, a free download from the EliteKeyboards site, as an alternative to hid_listen. This gives you a nice graphical display of the keyboard with each key lighting up as it registers. If chattering is detected, the key lights up in a different color. Switch Hitter is a Windows program, but I found that it runs in Linux with Wine -- the only things that don't work in Linux are the lock-light indicators.

Switch_Hitter Software I am very glad to have gotten a Teensy/Hasu Z-150 converter to work flawlessly. I wish I had discovered this sooner, because I had written off previous Z-150 boards as having bad switches, when the problem might have been the Pro Micro/Soarer converter.

Many thanks to Hasu for his converters, TMK editor, and helpful advice. Thanks also to several others who have posted helpful information on DT, GH, and Github. Much appreciated!!!

If anyone here has a solution to getting the xt_hasu converter working with a Pro Micro on the Zenith Z-150, please let us know.

I am so confused, is there a way to get the beige label to work with an adapter?

zodo wrote: 26 Apr 2019, 05:30 I am so confused, is there a way to get the beige label to work with an adapter?

Beige label should run standard AT/PS2 protocol, so any ps/2 to USB converter should work given you also have a passive at to ps/2 cable.

Hiya fellas.,
I made my own converter based on Teensy 2.0 plus Soarer Converter. It works as it should on my both Z-150 Black Label boards but there seems to be a problem with it. Every time i turn off / sleep my computer and turn it back on the keyboard is starting dropping keystrokes and all. Unplugging the USB connector from the computer and plug it back on does the trick but is so damn annoying.

I have tried several hex files so far.
Does anyone know the fix? Thanks in advance.

https://i.postimg.cc/7hdmkZRB/20190712-065951.jpg

For those who are still struggling, Attached is a working firmware for a pro micro.
pins are the same except for the RESET pin. This firmware is configured for pin A1 as the reset pin (the middle cable)

Just as a quick feedback or for anyone that is still experiencing problems: I've had the same struggles with my black label Z-150 and a custom build Soarer's Converter (Teensy 2.0, pull-up resistors & reset line). Talking about stuck keys, or inputs not registering at all. It works flawlessley now with the same hardware configuration and hasu's software. Just follow the instructions on this post: https://geekhack.org/index.php?topic=103648.0
(correct wiring, hexfile from github, key-remap and so on) and your black label Zenith should start working too.

Thanks for your mention on my project.
Yes, it should work with XT Z-150, post in the thread(or here) if you have any problem.

And now it requires testers with *Zenith AT Z-150* to add support for the weird keyboard. The converter can read scan codes from the keyboard but fails to control its LEDs. Come in the thread if you have AT Z-150 and are willing to help me.

Unfortunately I don't own an AT Model. I'd be glad to help if I did...

Another peculiar thing I noticed with the XT Model however is, that the NUM-lock LED turns on everytime I turn the computer off. It doesn't matter wether it was switched on before that or not.

It doesn't change its status when I press the key.
Also the piezoelectric beeper still registers keypresses, even when the computer is powered off.

Could this be a wiring mistake on my part? Or is my board buggered somehow? Maybe something to do with decay of some capacitors? I know I can always just unplug it to eliminate the fault, but I'm lazy and if it doesn't harm the board, why bother?

I've had the same situation when I still used Soarer's software. Anyone else with the same or a similar issue?

I think both issue is normal for the keyboard, not your or hardware fault.

IBM XT keyboard doesn't has any LED indicator and XT keyboard protocol doesn't support it. Some clones have indicators and which are controlled just internally by keyboard itself but they are not controlled from host or converter. In the result the indicator state will become out of sync with host state.

The converter and keyboard continue to work as long as computer can supply power, regardless of computer power state. The beeper can still work in the case. Computer UEFI/BIOS has USB power setting to change this behaviour, perhaps.

the NUM-lock LED turns on everytime I turn the computer off.

Initial Num-lock LED state is "on" when the keyobard starts. I guess keyboard and converter are reset or restart somehow when the computer is powered off.

Is the LED state "on" when plugin the converter and keyboard into computer?

I just tested it and apparently my first obversion was totally wrong. Every keypress, no matter the state of the computer, changes the LED status. Don't know how I got the idea in the first place, I thought I had tested it and all

Like you suggested, the board probably handles it internally, and as long as it is powered the beeper and lights will do their thing. So this "issue" didn't exist on the XT machines back then, since power handling worked differently in those.

Interesting is, that the beeper goes off for every key, except L- & R-Shift, Ctrl, and Alt. Any idea what the reason for that could be?


After boot, the board is always initialized in the Numlock on and Capslock off state (probably switchable in the BIOS menu), so it's very easy to get both indicator LEDs out of sync as you said.

When repowering the board (after unplugging), first the Numlock, then the Capslock LEDs turn on, and then both turn off again, so LED state is always off.

Sorry for the misleading information on my part and thanks for your help.

Interesting is, that the beeper goes off for every key, except L- & R-Shift, Ctrl, and Alt. Any idea what the reason for that could be?

'Alt+Esc' is still available to toggle the beeper even under this situation?
I don't have idea on this and the keyobard to test unfortunately. The converter can't control the beeper and LED indicators on the keyboard baiscally. But I like to improve converter firmware for this if possible. Any insight and suggestion from other owners would be appreciated.

When repowering the board (after unplugging), first the Numlock, then the Capslock LEDs turn on, and then both turn off again, so LED state is always off.

Thanks for the test. Good to know.