Rust on the metal can be dealt with either by mechanical or chemical removal (or both).

Those circuit boards look like they have a *lot* of corroded traces. It's likely repairable, but would be a tedious job to do so.

Shponglefan wrote on 2026-02-22, 23:13:

Rust on the metal can be dealt with either by mechanical or chemical removal (or both).

Those circuit boards look like they have a *lot* of corroded traces. It's likely repairable, but would be a tedious job to do so.

Yes, that was the backside of the keyboard. Probably 90% of it was like that, at that point you are just building a new keyboard instead of repairing one imo.

First thing I'd do about the ROM is ask in CCTAK "Classic computer collectors mailing list" - I'm sure somone there has an 11 and might be able to read the ROM content for you.

Never had an 11 - had a 4 and a 10 ... somwwhere along the way someone sent me source code to "Kypro-4 BIOS" - never looked at it much ... but it is up on my site. Depending on how similar the 11 is to a 4 - might be a place to start if you want to try and "make" something... (don't recall - BIOS might not be ROM content on CP/M .. could be a set of OS drivers)

If some of the keys work, then whatever the keyboard is using for a controller is still good. Worth checking with a multimeter if the non-working keys make contact (and you could try shorting the connections and see of the computer sees a key)

If enough of they keys themselves work (or you can find a "new" key that fits the tops)... and if you can make out where the traces would be, you could make a new circuit board - this could be laying out and making an actual PCB, or if you can clear away enough of the corrosion, reuse the existing one and tack wires key to key to replace the connections. Or do the same with a large protoboard after drilling holes for the keys... fortunately keyboards are simple!

Alesia wrote on 2026-02-22, 22:58:

... Suspected Bios/ROM issue ...

Curious why you suspect the ROM? There are lots of other reasons it might not try to boot.
Worth scoping the ROM select and see if it get accessed multiple times immediately after power-on/reset ... you should also be able to look at address lines and see if the code "wanders off" (usually happens with ROM errors)

Often when a ROM goes bad due to age, it's fairly obvious - lots of bits will be flipped, text will have obvious errors etc. (not all bits fail at the same time)

Have you tried reading it and seen what it's content looks like?
Been a long time since I looked at how a Kaypro starts, but most system ROMs have a checksum which the system tests at startup and aborts if it doesn't match... Usually not a complex function, a bit of disassembly should tell you how to calculate and test it (this test is usually done early on - also look for "ROM bad" type message and see if you can find the code that references it) once you figure out how it's tested, you can verify it independently.

Also, If it's an EPROM, as they begin to fail with age, they sometimes read "correctly" at lower supply voltages (this is the reason EPROM programmers in "FAST" mode do the programming at higher than 5v ... to make sure the device is "good and programmed").

DaveDDS wrote on Yesterday, 04:27:

Curious why you suspect the ROM? There are lots of other reasons it might not try to boot. Worth scoping the ROM select and see […]
Show full quote

Alesia wrote on 2026-02-22, 22:58:

... Suspected Bios/ROM issue ...

Curious why you suspect the ROM? There are lots of other reasons it might not try to boot.
Worth scoping the ROM select and see if it get accessed multiple times immediately after power-on/reset ... you should also be able to look at address lines and see if the code "wanders off" (usually happens with ROM errors)

Often when a ROM goes bad due to age, it's fairly obvious - lots of bits will be flipped, text will have obvious errors etc. (not all bits fail at the same time)

Have you tried reading it and seen what it's content looks like?
Been a long time since I looked at how a Kaypro starts, but most system ROMs have a checksum which the system tests at startup and aborts if it doesn't match... Usually not a complex function, a bit of disassembly should tell you how to calculate and test it (this test is usually done early on - also look for "ROM bad" type message and see if you can find the code that references it) once you figure out how it's tested, you can verify it independently.

Also, If it's an EPROM, as they begin to fail with age, they sometimes read "correctly" at lower supply voltages (this is the reason EPROM programmers in "FAST" mode do the programming at higher than 5v ... to make sure the device is "good and programmed").

The only reason I suspected it was because the boot ROM chip has it's light shield/cover removed (was not fallen off or otherwise in the case) It's been a while but I looked up the chip and it was a UV erasable chip, that combined with the no boot w/ no errors and the light cover being removed gave me the impression it had been wiped intentionally. I did look at getting a ROM reader/writer but a T48 kit is expensive enough I have to plan a month or two ahead of time to afford it, so it just hasn't happened. I don't think the character ROM is corrupted as a reset of the system causes all characters to flash on screen as the CRT resets and those characters seem to be all drawn correctly. It also has it's protective sticker.

I'll look into the mailing list, but I think the keyboard is going to be the wall with this project, designing a replacement myself is so far beyond my knowledge base that it's unlikely I'll ever attempt it. Maybe if the community figures out clone PCBs to be printed I could do that and move switches over/get new switches but with how far gone the current one is, repair isn't an option and doing a completely manual rebuild would be a massive time and money dump I just can't commit to.

Typical EPROMS (UV erasable ROMs) of that era had a glass cover built into the chip to allow UV light in to erase, and usually an opaque sticker over that (to avoid incidental UV light exposure)

When you say "light shield/cover removed" - do you mean just the sticer/cover over the chip, or has the glass part of the actual chi been damaged/removed (if the latter, they you're SOL) - if the former, know that EPROMS need a fairly strong/constant exposure to UV to be erased. I have a couple EPROM erasers which are florecent UV bulbs with run within an inch of the top of the chip (ie: very strong UV light) and it still takes at least an hour to fully erase a chip! - Before I had them, I tried direct sunlight and couldn't erase even after leaving out every day for over a month!

I'm assuming this chip was somewhat shielded inside the system where light levels would have been be very low?

Systems of that era typically used a direct memory mapped video screen. Sometimes with a "soft" controller (like the 6845), sometimes with a hard-wired "always on" one. Immediately at boot, the system would 1) program the video controller (if used, and if so no video characters would appear till this is done) and 2) clear the video memory to all spaces (blank - until this is done the video display shows whatever ramdom characters the RAM powered up with)

I'd look at all the larger chip on the mainboard and figure out it any of them is a video controller...

When you say "all characters flash" do you mean that you briefly see a screen of random characters which then goes blank (normal)

If there's a video controller, the presence of these characters means the controller IS being set up.

Going to blank means the system IS clearing the vido memory to spaces.

This suggests to me that system ROM is actually running (at least long enough to do these things) - had it been intentionally erased, then neither of these would happen.

It was not uncommon for these old systems to NOT output any text until they had booted.... I know the floppy drive is damaged, but have you connected it? - you should see it activate if the system gets far enough to try booting.

--------------------------------------------------

BTW, If you feel like "building something"....

Back in the 1980s I designed an EPROM programmer which could handle the most common EPROM types of the time (2716, 2732, 2754, 27128, 27256) - I still use it today (over 40 years later)

I used to sell the design, but I'm pretty sure that (like all my products) I've posted the design on my site for free now.

--------------------------------------------------

If you can clean away enough the the corroison to avoid "unintentional contacts" it wouldn't be hard to tack on wires to make the needed connections. I've done this for a few old systems over the years...

What exactly is the boot ROM chip?

Chances are it's small... IIRC CP/M itself contained "BIOS" drivers to access the hardware incl. disk... The ROM was kept small because 1) bigger ROMs were expensive/not-available, and 2) unlike PC BIOS, this address space was not used after boot (so why waste more than you had to)

To give an kind-of extreme example... my Altair had an early "NorthStar" single-density floppy disk card - it contained a boot "ROM" (hardware, not an EPROM) which was a whopping 256 bytes in size. It contained a subroutine to read 1 sector off the disk, and mainline code to use that routine to read a sector from the disk into RAM and jump to it. Needless to say it did not output any messages at any time (it didn't even know how to talk to the RS-232 terminal - which could differ from system to system)

That "new" 256 bytes would then (using the ROM subroutine) read the NorthStar OS into memory and launch it.

The only "boot messages" you got were:
1) The disk light coming on ment it was trying boot.
2) Failure of the OS to start ment "boot failed".

DaveDDS wrote on Yesterday, 11:59:

Typical EPROMS (UV erasable ROMs) of that era had a glass cover built into the chip to allow UV light in to erase, and usually a […]
Show full quote

Typical EPROMS (UV erasable ROMs) of that era had a glass cover built into the chip to allow UV light in to erase, and usually an opaque sticker over that (to avoid incidental UV light exposure)

When you say "light shield/cover removed" - do you mean just the sticer/cover over the chip, or has the glass part of the actual chi been damaged/removed (if the latter, they you're SOL) - if the former, know that EPROMS need a fairly strong/constant exposure to UV to be erased. I have a couple EPROM erasers which are florecent UV bulbs with run within an inch of the top of the chip (ie: very strong UV light) and it still takes at least an hour to fully erase a chip! - Before I had them, I tried direct sunlight and couldn't erase even after leaving out every day for over a month!

I'm assuming this chip was somewhat shielded inside the system where light levels would have been be very low?

Systems of that era typically used a direct memory mapped video screen. Sometimes with a "soft" controller (like the 6845), sometimes with a hard-wired "always on" one. Immediately at boot, the system would 1) program the video controller (if used, and if so no video characters would appear till this is done) and 2) clear the video memory to all spaces (blank - until this is done the video display shows whatever ramdom characters the RAM powered up with)

I'd look at all the larger chip on the mainboard and figure out it any of them is a video controller...

When you say "all characters flash" do you mean that you briefly see a screen of random characters which then goes blank (normal)

If there's a video controller, the presence of these characters means the controller IS being set up.

Going to blank means the system IS clearing the vido memory to spaces.

This suggests to me that system ROM is actually running (at least long enough to do these things) - had it been intentionally erased, then neither of these would happen.

It was not uncommon for these old systems to NOT output any text until they had booted.... I know the floppy drive is damaged, but have you connected it? - you should see it activate if the system gets far enough to try booting.

--------------------------------------------------

BTW, If you feel like "building something"....

Back in the 1980s I designed an EPROM programmer which could handle the most common EPROM types of the time (2716, 2732, 2754, 27128, 27256) - I still use it today (over 40 years later)

I used to sell the design, but I'm pretty sure that (like all my products) I've posted the design on my site for free now.

--------------------------------------------------

If you can clean away enough the the corroison to avoid "unintentional contacts" it wouldn't be hard to tack on wires to make the needed connections. I've done this for a few old systems over the years...

The floppy drive was doing a seek test, but I had not considered swapping in another as I never got the "Kaypro 10 v x.xx xxx" splash screen. It's inclusion or exclusion did not change the fault symptoms, and I figured the seek test was probably performed by the floppy controller and not the mainboard. I could be completely wrong though. As for the rom I'm talking about, it's unlabelled on the Kaypro 10 technical manual's chip listing, but it's U42 in the lower right quadrant of the board right under the J9 connector. I did do a quick unscientific heat test and only the CPU and CRTC were getting warm (but not hot.) Every other chip was stone cold. The fact that the video is being blanked properly (?) is good though. I never got a boot failure message or any other indication that the POST/BOOT was failing aside from the forever blinking cursor. I do have a drive I can pull from another machine to test if you think it might do something, sadly I don't have a spare to just donate to the Kaypro. 5.25" 360k drives push over $100 in my area for some reason so I'm pretty slim on them.

Floppy controllers don't normally do "seek tests" .. The PC bios does a "seek test" to see if the drive is 40 or 80 tracks (Step out 45 tracks - enough to hit the stop on a 40 track drive), then seek back 44 tracks & see if the TrackZero sensor comes on)

Normally a drive steps to track 0 under control of the bootloader to access the boot track which is almost always track 0. Since the bootloaded doesn't know what track the drive was "left at", this almost always means step until track-zero sensor comes ON. (useful test - manually position drive to about 1/2 way and see if it homes head at startup)

As I said before, there may not be error messages ... A "splash" screen (if it exists) might be displayed by the OS as it boots.

Is the BOOT ROM in a socket? - If yes, remove it (which will guarantee the startup code won't run) and see if you still get drive seeking and screen clear after flash of random characters?
I'd guess no which will mean the boot rom was running before - if yes, it means the subsystems do more than was "usual" in that era.

Alesia wrote on Yesterday, 15:14:

... unlabelled on the Kaypro 10 technical manual ...

So.. do you have schematics? If so, count the address lines going to the ROM to determine its size! Also, how many pins?