Remove the keyboard from the bottom of the computer cover.
Remove the cable.
Remove the metal clip grounding the foil cover to the keyboard.
Wipe over the foil cover and set it aside.
Blow out the keyboard.
Remove the key caps with puller. The spacebar requires two sturdy pairs of long nose pliers
Store springs.
Wash keycaps in warm soapy water using a soft toothbrush to scrub and allow to dry.
Once dry, wipe over once more with a damp cloth.
Blow off the residual loose dirt from the keyboard assembly
Desolder the caps lock switch.
Remove the pcb screws.
Clean the pcb with paper towel and IPA.
Remove and store the caps lock switch (2 little levers).
Store the barrels and keypads.
Scrub the key frame in warm soapy water. Blow off and allow to dry.
Wash the barrels in warm soapy water and allow to dry.
Scrub the cable in warm soapy water, blow out, and allow to dry.
Put the rubbers in a container and shake off as much dust as possible.
Clean both sides of rubbers with cotton buds and IPA.
Put the barrels back in the key frame and insert the rubbers.
Clean them again.
Re-coat rubbers with conductive coating.
Inspect carefully for lint and remove.
Reassemble.
Test with harness and meter.
The conductive coating has to be mixed and then used within a couple of days so it makes sense to do both keyboards at the same time.
I did start with the second keyboard because it was in an awful state.
This is the first keyboard (from the cleaner machine).
The contacts were coated using a CircuitWorks Rubber Keypad Repair Kit. This kit is quite expensive and a bit laborious to apply, but it does the job. It looks like it’s using a silver paint. The key resistances were very low. There was enough in a kit to easily do the 140 or so keys.
The shift lock keys was not working. While looking for a replacement online I found a video where the author had worked out how to open the switch by twisting the terminals, so I thought it was worth having a look inside. It was filthy – I’m not sure how this much ick could get inside a switch with no significant orifice.
It was built like a puzzle. Cute little mechanism with lots of pieces. After a clean, things looked better.
There is a spring as well – fortunately it was still in the parts container!
It took a while to reassemble it. The pins screw through the contacts to create a hole and contacts at the same time. I added some aluminium foil to make sure the contact was still good. I was relieved to find that the switch was working.
Testing just requires a keyboard cable from the computer and a jig which joins all the columns to all the rows. Then each key can be tried. This can be done before putting all the key caps on by turning the keyboard upside down and pressing upwards. Otherwise, without the caps and springs, all the keys are activated at the same time.
Both cards have significant corrosion and were very dirty.
The process was as follows:
Wash in soapy water. Scrub with toothbrush. Blow off and allow to dry.
Inspect and gently remove socketed ICs (one had corroded on to a socket).
Apply soapy vinegar, rinse.
Apply soapy vinegar, rinse. Blow off and allow to dry.
Apply de-oxit to corroded legs and leave for 24 hours.
Clean legs with wire brush on Dremel.
Clean with soapy water. Blow off and allow to dry.
Most ICs have oxidised legs. The legs on socketed ICs can be easily checked for integrity – in some cases, a small nudge was sufficient to make them fall off. It’s harder to check those that are directly soldered. It appears that in many cases the plating has been penetrated and is prone to flaking. I attempted to re-tin some ic legs, but the solder would not take even with lots of flux – I suspect the material required electroplating and that’s not happening. De-oxit is probably the only practical way to protect them. Of course, they could all be replaced, but that will be time-consuming and will risk damage to the PCB.
The MC3446 line drivers (for the IEEE-488 bus) are located near one of the case openings. One had legs corroded through. The others were in poor shape. They have been replaced with new ICs and sockets.
The PCBs are in generally good condition. The edge connectors had lost some plating, but the oxide has been removed with deoxit and the copper re-tinned.
On the second board, a damaged socket was replaced. I favour machined sockets, but this board never used them and the sockets that have been added in the past are either zero insertion force or dual wipe (the originals are probably single wipe).
The wire to the piezo was missing, so it has been replaced.
The configuration links in the middle of the board were untidy and used the wrong gauge wire. They have been replaced.
Other links have been made with wire wrap. The wires were unnecessarily long, making them vulnerable to breaking. The posts were too high, so they were prone to bending. The posts were cut down and the wire wrap redone.
Apply metal filler, wait to dry, and then sand smooth with detail sander
Sand the remainder of the paintwork
Apply etching primer to all bare metal
Mask the labels
Apply 2 coats of satin black paint on both sides.
Reattach feet with screws.
Remove paint around the ground stud.
The process for the monitor frame was similar, but the colour is a pale green and, because it was gloss, I had to coat it with a satin clear coat. I messed this up in a couple of places by applying too thickly – it’s very hard to see how much is on! The colour match is not great, but only a small section of the frame is visible, so I didn’t get too concerned. I removed paint at the earth point.
The transformer baseplate was similar again, but it was originally galvanised and only partially painted. I used a zinc paint where it was previously unpainted, and then masked and used satin black for the other areas. I removed paint around the two inside screw holes to allow for a solid ground.
I powered up with sockets empty and checked voltages. All good.
I added socketed devices. Three legs fell off one 6520 so that had an impact – particularly on the keyboard. I replaced the 6502 which had a weak leg and one 6520 which had lost three legs.
On power up there was a chirp which suggested some life.
I added the monitor and was relieved to get a picture, although clearly it hadn’t booted.
I tried the card from the first unit (also with a replacement 6502 for the same reason). It was less successful – no chirp and no picture, so it wasn’t getting as far. For now, I’ll stick with Board 2 – at least the ROMs have checked out.
My joy at the monitor working was short-lived, as it stopped working within 30 minutes. It produced quite horrible squiggly lines on the screen. I was unable to find any posts that described the effect and therefore the cure, so I checked the board over as best I could. All the transistors looked ok. The yoke coils seemed to be good. The flyback seemed ok. The usual suspect resistors were ok.
I was looking for a video that showed testing of the board without CRT connection, and in the process found a repair that involved diode D754 and the adjacent capacitor C754.
I found diode D754 was a 10 ohm resistor, and when I checked D253 one leg fell off. The faults may be related, or maybe not. I replaced the original VO6E diodes with 1N4004, which have the same voltage rating and slightly better recovery. I checked the capacitor and it seemed ok. I see a recap in this monitor’s future, though.
Following the replacement, the monitor was back working. I turned it all off and called it a night. It worked for a while the following day, but D754 then became a 2 ohm resistor. This time I replaced it with a diode with a higher reverse voltage limit 1N4007 (1kV rather than 400V) and I also replaced the C754. I had a 400V cap rather than the original 250V. I checked the voltage at the diode. It seems ok.
Back to the original problem …
I made up a PETTEST rom using a 2732 EPROM. This requires an adapter because the pinout does not quite match the ROM pinout. Three pins cut (from a socket): 18,20,and 21, and two wires added: pin 20 of the ROM socket to pin 18 of the 2732, and pin 18 of the ROM socket to pin 20 of the 2732.
Then look at this website http://www.6502.org/users/andre/petindex/crtc.html and scroll to the bottom. You will find a spreadsheet called PET_CRTC.xls. Open this up and you will (hopefully) find a match for your EDIT ROM.
Use the values from the spreadsheet.
The CRTC registers are numbered from 0 through 17 (decimal) – a total of 18 numbers. The numbers in the spreadsheet are already in hexadecimal.
The CRTC initialisation table starts at byte offset 5 in my PETTESTER EPROM image. Hand-edit the 18 bytes using your EPROM programmer tools and burn the EPROM.
By adjusting the parameters you can set the PETTESTER to initialise the CRTC for 40/80 columns, 50/60 Hz frame refresh rate and for the number of raster lines per character displayed.
Just one problem – I don’t have the part number for the edit ROM because it’s an EPROM and the label was illegible. I do have an oscilloscope though, so I measured the vertical and horizontal scan frequencies – 50Hz and 20kHz respectively.
That makes it look like the last 6 lines in the spreadsheet, but I have not been able to match my edit ROM with any of the candidates. Tricky. This may take some experimenting. I started with the first one, and it worked – well, the video worked – but the video ram test failed. Using the scope, I could see it looping the video ram.
Several video RAM chips seemed not to be working – again, using the scope I could see variation between bits written and bits read.
Two 74LS244s also seemed to be bad because the input didn’t match the output for reads and/or writes. I replaced the ICs using sockets. They are FCT parts for now. The board is not easy to work with – difficult to remove solder from holes.
What I did notice was that having replaced the socketed video rams (two are unsocketed) and the 74LS244s, I was able to get every second character of the sign-on message using the normal edit ROM.
I replaced all the VRAM including the sockets and this resolved the missing characters.
But, I still didn’t have a cursor. Also, the pettest still didn’t seem to operate as expected – I never resolved this.
I tried swapping over the other PIA and the VIA with spare parts but no joy. The first PIA had already been swapped over due to corroding pins. A general poke around showed that a lot was going on, but I eventually found some indeterminate outputs on the bottom PIA and this turned out to be a poor connection at pin 1 VSS. I bent the pin in to put a bit more pressure on the single wipe contact and joy was had.
The full 32k of ram seems to be detected. There is one socketed chip in each RAM bank. Pulling the chip from the first bank causes the machine to not start. Pulling the chip from the second bank causes only 16k to be reported. Presumably there is at least a simple RAM test that has determined that all the RAM is OK.
At this point I wished that I had a working keyboard, but I had been putting them off because of the tedium involved in painting the contacts. Instead, I put a little piece of foil on a cotton bud and used it as a stylus.
This is positive, but the IEEE-488 drivers need to be replaced and the remaining single wipe sockets could easily cause problems in the future.
This gave me the necessary motivation to finish the keyboards. Which now work well.
I had tried the unit one board previously, so I knew that it was not working. I had previously replaced the processor because the legs were corroded. (Later I tried cleaning it up, but it still did not work.) I also replaced the GPIB buffers as they were also corroded.
I did the set to work of the Unit 1 board in the already completed Unit 2 chassis.
The screen was not scanning, so I disconnected it.
There are lots of things that could go wrong, and this board is a little more challenging than the other one because most of the larger ICs are soldered down. This makes it difficult to just swap them out. On the plus side, the socketed ICs tend to be more corroded than those that are soldered in.
The power supplies were good, the clock was good, and the reset was good.
The most likely cause of failure was RAM, but there had been no RAM failures on the other board. I probably should have just replaced the lot, but you don’t learn much doing things that way and the thought of cutting out 16 RAM chips didn’t fill me with joy. I did it the hard way.
It’s relatively easy to see when the ROMs are accessed. The 6502 resets to FC00, which is in the kernal (sic) ROM. The webs suggested that the kernal calls an initialisation routine in the Edit ROM at E000.
The vector at FC00 jumps to FD16. The call to E000 is made at FD1B just after the stack is initialised. This listing shows the edit ROM, but there are many edit ROMs.
This one seems to match reasonably well with the 50Hz 80 column ROM used in this board:
Using this I could use the scope to read the address lines on the ROM one at a time to get the address. (it’s moments like these when a logic analyser would be handy but there’s not much that can’t be done with a good scope and some time.) I added a reset button (between UD16-2 and ground) and the timing is repeatable with respect to the reset (which can be conveniently picked up on pin 40 of the processor). This is partly because the system is so slow (1us per bus cycle) that there is time for both an access and a refresh. Not all machines are so deterministic.
CAS cycles (R10) identify accesses to RAM. Accesses to VIA/PIA are trickier because they use multiple chip selects. They are tucked into the E800 to EFFF space next to the Edit ROM, which is only 2k. The other ROMs are nominally 4k.
I looked for where the processor seemed to lose its way and used ROM addresses to work out where execution was in the ROM.
Suspecting RAM I looked for the first time there was a critical RAM read eg a subroutine return which I expected to be two back to back reads – it turned out to be three. Similarly, I expected a call to be two writes, but they are always one read and two writes. I still don’t understand this, but maybe the penny will drop one day.
Sure enough, the first return was just before the processor went rogue. Checking the call and the return showed that the data read from RAM was very different to that written. Very different. Either there were a lot of dead RAM chips or something more systematic going on.
I got good at reading the data (during CAS for a write and valid at the riding edge for a read and also the row and column addresses – valid at the falling edge of RAS and CAS respectively. Everything looked good, so I concluded that nearly all the RAM chips were duds. And that proved to be the case. After replacement of the lower 16k the machine came to life with a garbled display that looked a little like a sign on message but not quite. (I checked the sync timing before reconnecting the monitor.)
After replacing the video RAM, the display improved but was still not right. It changed with a wiggle of the character ROM. After cleaning the legs (it is socketed) the display was good. I could type in and run a program.
I tried some pokes and peeks in the second 16k. It also had many failures, so it needed the same tedious treatment. Once the second bank of RAMs was replaced, it worked.
Although the machine was doing quite well there was no chime and there were also issues detecting the datassette button presses. That sounded like a VIA problem. I replaced it and all was good.
I connected up the disk drive, and I was able to get a directory listing.
The 4116 datasheet did indicate that the power should be sequenced correctly to avoid damage. In particular, the -5V rail should power up before the others and power down after the others. I checked just to be sure.
Having worked over the metal work and CRT I moved processor board one into its chassis.
Initially nothing appeared on the CRT. The first problem was the spring which contacts the ground surface of the tube. It was a little oxidised and bent. After cleaning and adjusting it was fine. The display was quite dim though even with the sub-bright and bright at their max. The issue was that the 400VDC supply was only 200V. This was because R253 had gone open circuit. I have replaced it, but it may be a symptom of a bad capacitor – there’s quite a lot of commentary on it on the web eg:
