Sunday, 28 April 2019

Acorn Electron Repair - Part 2 Keyboard

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

This is the second part of the Acorn Electron repair. Last time I got the main board working after it arrived in this state. Looking at this photo, you can see the colour difference between the two halves. I would guess that someone had two Electrons, one with a broken keyboard, and one with a faulty main board, and guess which two halves I have here?
Now it is time to look at the keyboard. The Electron has a very nice keyboard, a metal frame with individual keyswitches soldered onto a single sided PCB. This is connected to the mainboard via a 22 way ribbon.
This is quite unusual, I don't recall seeing this type of cable anywhere else. You can see quite well here how it is constructed as due to the damage, it has started to delaminate.
There are two layers of clear plastic sandwiching some bare copper strips, crimped at each end.
Here the connector is cracked, but just about holding together. In order to test it, I've put sellotape on both sides to try to hold it together.
The back of the PCB has some foam tape to protect the ribbon from the pins on the back of the PCB. With that removed, you can see the where the cable is connected, the fourteen diodes and four resistors. I check continuity through the cable, and most pins were connecting, but there seemed to be the possibility of a couple of shorts where the copper ribbons were close.
I decided to test it with one of my USB keyboard controllers as I know that it is protected against shorts on the pins. On the Electron, fourteen of the pins are connected directly to the address lines, so any shorts could damage the board. (there are diodes to protect the address lines from shorting in operation, but they are on the keyboard PCB, so any shorts in the cable could cause problems).
The keyboard appears to work, but not all the keys, it's a bit intermittent, and there is a danger of shorts, so I think I'll go for replacing the cable. I'm not aware of a supplier of this sort of cable, so I am going for a more easily available alternative.
First off, I removed the cable, and soldered in a pin header to the keyboard. Space is a little tight, so I went for a straight header soldered in at an angle.
The connector on the Electron end is also a pin header, with the same standard 0.1" spacing.
To connect those, I've used Harwin M20 (also called Dupont and various other things) crimps and headers. I didn't have a 22 way, so I used a 20 way and a 2 way.
I tested this again on the USB keyboard controller, and all but a few keys were working.
The ones that were not responding are usually just dirty contacts in the switches. Unless there's a pattern, like a whole row or whole column, in which case check the connections. You can also test this by shorting the two pads for a switch on the back if the PCB, which will effectively press that key.
Where a particular key doesn't work, most of the time they just need to be pressed a few times to brighten up the contacts. If that doesn't help, pull off the key caps with a key puller and give it a quick squirt with contact cleaner. Put the keycap back and press it a few times and they usually come back.
The keys were all now working with the USB keyboard controller, so back to the Electron. That is a straight connection to the main board, but it's fairly tight in there.
In order to make it a bit easier, I've split the ribbon cable into individual wires, so they all lie flat to the side and the case closes fine.
With all that back together and a bit of a cleanup it's working nicely.
The obligatory 10 PRINT program gives the expected results.
Time for a bit of testing.

2022 Update: Did you spot the prototype SD2Elk in one of the photos? I don't think anyone did at the time. The idea was basically add a userport to the Electron and use a BBC Userport SD solution. The worked with a few tweaks to the code, but so much software wouldn't work as it was all originally tape based and didn't work when the disk interface used extra RAM and moved page up. I was looking at various solution to that, but finally ditched the project when I saw that someone else had released something along similar lines. I was unsurprised to see a review from Chinnyvision which basically concluded that none of the games he wanted to play worked for exactly the reasons given above.