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

[gonzobizarro]

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.

[kelvinhall05]

Maybe try a Soarers on a modern PC?

[TheInverseKey]

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

[gonzobizarro]

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?

[MMcM]

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.

[gonzobizarro]

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.

[gonzobizarro]

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).

[gonzobizarro]

MCU is not advancing the address lines. It just keeps getting first byte off the EPROM (04, as seen in the dump binary we got off of te EPROM). ALE and PSEN signals from MCU look good, but it just keeps asking for the same byte all over. Ordered a replacement 8039-11 and will post an update when it arrives.

[MMcM]

Oh, this is encouraging. Please do post the binary file and/or disassembly someplace. (Some kinds of attachments are allowed here, but perhaps not those.)

4 is a strange place to be fetching all the time, so trying a replacement MCU seems like a solid idea.

When reset, the program starts at 0, where you'd normally expect to find some kind of JMP instruction. So falling through that far seems unlikely.

External interrupt goes to 3. But,

1. You have to enable it after reset, so the program would need to run enough to do that.
2. If there were an interrupt routine, it'd probably JMP, too and that's a two-byte instruction. 4 would be the second half of that instruction.
3. INT would also have to be low. I imagine you already checked that RESET and/or INT aren't accidentally grounded.

[gonzobizarro]

Perhaps I was not precise enough - the MCU sets the address line at 0 (or it doesn't and it's just "default" value) and then receives value from byte at address 0 in the EPROM.
This value is binary 04, and disassembler translated it to part of an initial JMP instruction.
Below is first few lines from the disassembled eprom dump binary - first byte at address 0 is, as you wrote, a JMP instruction.
Starting at fourth address (so F803 below) is indeed an interrupt handler as you wrote:

Code: Select all

				;	Size:		2048 bytes
				;	Checksum:	A45C
				;	CRC-32:		CF9370FB
				;	CPU:		Intel 8048 (MCS-48 family)
				;
					org	0F800H
				;
F800				LF800:
F800 : 04 10 		"  "		jmp	L0010
				;
F802 : 00 		" "		nop
F803 : 15 		" "		dis	i
F804 : 25 		"%"		en	tcnti
F805 : 93 		" "		retr
				;
F806 : 00 		" "		nop
F807 : C5 		" "		sel	rb0
F808 : AD 		" "		mov	r5,a
F809 : 23 EC 		"# "		mov	a,#0ECH
F80B : 62 		"b"		mov	t,a
F80C : 64 17 		"d "		jmp	L0317
				;

I've uploaded complete files here.

Our MCU never advances past asking for contents of memory at address 0.

Neither the reset nor interrupt pins on the MCU are grounded.

We did all tests with 5V supplied to keyboard (not connected to computer). Would this matter for the MCU to start up?

[MMcM]

Got it. Sorry for misreading what you said earlier.

If RESET being asserted all the time has been ruled out, then I guess, yes, wait and see how a new MCU does.

[gonzobizarro]

Got it. Sorry for misreading what you said earlier.

If RESET being asserted all the time has been ruled out, then I guess, yes, wait and see how a new MCU does.

I will report back after the replacement chip arrives from the Big Rock Candy Mountain. Thanks again MMcM!

[gonzobizarro]

A small update: while we wait for the new MCU, my friend had an idea to run the code we got off the EPROM on an Intel 8048 processor emulator software. It seems to load and run as intended, scanning ports etc.

[gonzobizarro]

Just so we can close this case - replacing the 8039-11 MCU on the keyboard fixed it. It also revealed further issue with intermittent key press registration, which was easily fixed with a solder iron - most of the switches had broken solder points due to how the switch backing plate and the PCB board flex against each other. Keyboard works with later AT computers as well.

Thank you everyone, especially MMcM, for your assistance.