Reviving a Unitek K-150M (K-151?) XT keyboard


21 May 2020, 13:09

Hello fellow keyboard maniacs.

I've just created this account but I have been a passive reader for a good while. I am struggling with reviving this keyboard I acquired some time ago, which I really like and want to save from oblivion. Before I totally wreck it, I thought I better ask the elders..

Patient is what I identified as Unitek (?) model K-150M (says so on the label) or K-151 (printed on PCB). It is a pure XT keyboard (no XT/AT switch) with o/g MX-black switches (one MX-grey under the gargantuan 10x space bar). Thing is built like a tank. It does have 3 lock lights though, unlike original Model F and most clone XT keyboards. It's in very good physical condition overall, but appears dead:


When it's powered, it lights up all three lock lights and does not react to any key presses. I have tested it with my o/g IBM 5160 PC XT machine and it boots up fine, it does not display the 301 error which appears with wrong or no keyboard plugged in, however no keystrokes are registered. Pressing the capslock, numlock etc does not affect the lights on the keyboard either. Keyboard behaves the same with just 5V supplied to it (not connected to any host).

I used a cheap logic debugger and listened to the keybards brain's (an MCS-48 series microcontroller) I/O lines when pressing random keys and it does not seem to talk to the world at all. Chip itself is a 8039P-11 and gets a bit warm to the touch after the keyboard is powered up:


There is an EPROM chip containing what I assume is the keyboard controller microcode.

Does anyone have that particular keyboard or have had experience with it in the past? Based on above symptoms can you tell what could be the problem before I whip out my soldering iron and start replacing stuff at ranom? Is the microcontroller fried, or is the code in the EPROM corrupted (I hope not!)? Could it be the two electrolytic caps are causing that (I would start by replacing these)? Is it an issue with any of the other components (external quartz? mux/demux chips?)?

My first suspect is the microcontroller - should it be getting warm after just couple of minutes?
Perhaps at some point in it's life it got fried by too high voltage (when a PSU died in it's host). If I can't find an exact model for replacement, would other MCS-48 series chips work instead?

Thanks in advance for your help.


22 May 2020, 00:48

Maybe try a Soarers on a modern PC?

User avatar

22 May 2020, 05:53

I had the same issue as well with mine something is off with the clock for sure.


22 May 2020, 10:21

TheInverseKey wrote:
22 May 2020, 05:53
I had the same issue as well with mine something is off with the clock for sure.
Thanks! So it's either the built in clock in the micro controller, or the external quartz visible on the board? Did you manage to fix yours in the end?


22 May 2020, 15:34

The LEDs come up and stay on, right? I imagine they are active low and that will be the power-on state of those ports on the MCU. But it might be worth checking that, since if it has to drive them high, it might be alive.

I imagine any 8039 will do, ignoring the manufacturer and process details.

You shouldn't even need to press keys to see the MCU scanning the matrix.

Unfortunately, my bet is on the UV-EPROM. That it is reversible maybe means it's more vulnerable to decay? I have some that are fine and others that seem to be gone completely.

Can you trigger on ALE and confirm that the program address on the BUS is advancing? Can you trigger on PSEN and see whether it's getting back 00 (or now that I think about it, maybe it's FF when it's empty)?

Caps don't look swollen, so I'd do more logic analyzing before replacing stuff.


23 May 2020, 03:40

Thank you very much MMcM, this is exactly the kind of advice I was hoping to get :) Time for more playing with the analyzer. It'll be few days before I can do it though, but I shall be back with my findings (or further questions).
Forgot to add: yes, the LEDs come on and stay on. Good catch! I'll check what controls power to them and how.


Yesterday, 19:23

So we had some time today and together with my friend we hacked together an ATMega8 based EPROM reader on a breadboard. We successfully dumped the contents of the keyboard's EPROM chip. It seemed to be a valid code (definitely not full of FFs or 00s), and disassembled nicely when fed into DASMx. Therefore I think we can rule out the EPROM or the code inside.

BTW if anyone needs it, and you think it's not going to get anyone in trouble, I have both the raw binary file as well as the assembler listing output from DASMx (sadly no attachments allowed here).

Post Reply

Return to “Workshop”