Sunday 15 December 2013

Commodore 64 Diagnostics Cartridge

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

I've finally got a replacement for my desoldering station, after giving up on my original supplier and going elsewhere. Now I can catch up on all the jobs which are likely to need a lot of desoldering, and have been old hold whilst I've been waiting. Here we have another Commodore 64 to repair. The initial fault was a black screen.
I went straight to the usual culprit and, yes, it was the PLA. Desoldering station working well, removed, socked and replaced that. The PLA was verified as faulty in another machine, and a working PLA brought this back to life (well, sort of).
This is actually the later CSG 251064-01 which seems to be more reliable than the original MOS 906114-01. There was now something to show on the screen, but it was random garbage
Just to side track for a moment, on the subject of random garbage. I remembered years ago finding a good demonstration that the random number generation on this sort of computers wasn't as random as you might think. There is an example in one of the Spectrum + user guides which shows some 'random' coloured blocks.
If you type it in, you also get random coloured blocks, but exactly the same random coloured blocks as shown in the book!
This is due to the Spectrum's psuedo random number generator being seeded in exactly the same default way. Always remember to choose a suitable seed your random number generators - a trap for young players as Dave Jones might say.
Anyway, back to the Commodore 64. At some time in the past, two of the DRAM chips have been replaced. This always starts the alarm bells ringing, particularly when they are different speeds. I thought it might be a good time to use the Commodore 64 Diagnostic Cartridge and see if it could pick out the faulty chip. I had been using a bit of a hack using a 2764 EPROM, but I thought it might be time to make a neater one. I got a couple of game cartridges and had a look inside.
The Omega Race one on the right looked the best bet as that was a simple 8K chip.
Desoldering station on call again, nice clean removal of the original Omega Race chip.
These 24 pin chips are not compatible with the standard 27 series EPROMs (like the 2764 I had used which is 28 pin, 8K), so I used the same type of MCM68766 24 pin 8K EPROM I had used to replace a VIC20 Kernal ROM.
The Diagnostics program ran, and highlighted problems with 4 of the DRAM chips, the mess on the rest of the screen is due to the memory fault.
Time to change the DRAM. More desoldering, at least it's a good test.
I installed sockets for the DRAM chips and tried various combinations. It seemed there was actually only one chip at fault, but when that was present, it caused another three to report failure. I'm not sure if this is a deficiency in test program, or something to do with the mixed timings and manufacturers (which I normally try to avoid).
After further testing, I decided the best option was a fresh set of DRAM chips.
Retesting with the new DRAM, all was well.
I've made up a suitable label for the cartridge, stuck over the original, so if I ever feel the urge to go back to Omega Race, I can.
That's now part of the testing toolkit, ready to test the next one.
The new desoldering station has passed with flying colours, time will tell if I get the same issues with tip deterioration as I did with it's predecessor.

2022 Update: After much experience, I now replace any of the Micron chips with the MT logo on as so many of them fail, it's better to replace the lot.

Saturday 30 November 2013

Commodore 64 PLA Replacement

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

As I have mentioned before, the Achilles heel of many vintage computers are custom chips. These PLA (in Commodore terminology) or ULA (in Sinclair terminology) chips were a way to reduce cost and size by combining the functionality of a number of logic chips into a single package. Sometimes doing simple address decoding (as in many Commodore machines) and also generating sound and video (as in the case of the ZX81 and ZX Spectrum, Acorn Electron etc.).
The trouble with these is they tend to run hot and eventually fail, and replacements they haven't been produced in the last 20 years, the so lead to the demise of many machines.
Over the years, many methods have been used to replace these. The Sinclair ones contain a lot of functionality, so replacement is quite complex, as in my ZX81 Clone.
The Commodore ones are a lot simpler and are mainly address decoding. So the inputs are the address lines, and the outputs are a series of enable lines. So for this address range, enable this chip, for that address range, enable that chip, and so on. There isn't any state or anything more complicated than a simple truth table.
Many people have suggested an EPROM could be used to replace this, the one I followed was here (in German) The pinouts aren't exactly the same, so a few pins need to be redirected. I built a simple adapter for this.
I used a wirewrap socket, pushing it part way through and then soldering it, before cutting of the pins and soldering the remainder two holes to the left as the EPROM socket
Finally adding the 4 wire links.
Here we have a Commodore 64 which is working except for the PLA. It has been tested with a working PLA, and all is well, so time to try out the replacement PLA.
I used a one time programmable version EPROM (an Atmel AT27C512CR-45PU), as these seemed to offer appropriate timing of 45mS, and others had reported success with these.
First off, it looked promising, the system ran for several hours. However, I noticed the SID had been getting rather hot. I went back to a working PLA and ran it for a further couple of hours and the SID ran as normal (which is still hot, but not as hot - must get an IR thermometer). I think this is related to the timing issues. It is possible that certain combinations of outputs may be enabled at the same time during the short time the EPROM is in its intermediate state before the data lines settle down. There is no timing element or enable mechanism to stop this happening.
So, it looks like this isn't a viable long term solution. I think I'm going to try building a replacement with a couple of 20V8 GALs next.

UPDATE:
I've has good results with EPROMs and a capacitor to alter the timing slightly, also a nicer PCB

Sunday 17 November 2013

Rusty VIC20 Restoration

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

Sometimes it seems you can never tell what you're going to get from ebay. This one looked to be a nice, non-yellowed VIC20.
However, all was not good with the photo of the rear of the unit.
Oh dear, looks like this has been sitting in water and the screws had rusted
I was expecting this to be over the whole board, and the thing would be a write off.
However, it seemed to be limited to the edge of the board, to the screws and the metalwork.
I wondered if it could be saved, so I took out the board and had a go with a solution of vinegar and water.
It seemed to clean up very well, so I removed the metalwork and a few discrete components and cleaned up the rest of the board.
Most of the board cleaned up quite well. I later reflowed the solder on those tracks to get rid of the remainder of the corrosion.
The metalwork was quite corroded, so I replaced it with a shield from a scrap board.
Now that all the corrosion had been cleared up, I was back with a VIC20, ready to test.
Black screen. Oh dear. Well, now onto the usual VIC20 repair routine. Nothing was running hot (apart from the VIC as usual), reset was happening, the clock was running, and the keyboard was being scanned. So I hooked up a 1541 disk drive and tried some 'blind' disk commands. So even though the screen was showing nothing, typing

LOAD "$",8

resulted in disk access. So this was going to be an easy one. The machine was running, just the display that wasn't happening. So, it was the VIC or the possibly the video memory. Neither of those were socketed, so I tried the VIC first, removing the old chip and replacing it with a socket and a known working chip
Powered it back up and voila, one ready screen.
After that, it was onto giving the case a good clean and sorting out the rusty end panel.
All reassembled, it cleaned up rather well.
It's one of the whitest VIC20's I've seen
A nice addition to the collection


Saturday 26 October 2013

Commodore 64 DRAM Repair

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

I have a Commodore 64 in for repair at the moment that is showing some intermittent memory faults. For once, it doesn't seem to be the PLA. The same fault has been seen with a working PLA and the PLA from this unit working fine in a test C64 board.
There is evidence of a historic memory repair. Some time in the past it looks like 4 of the DRAM chips were replaced.
In the process, a couple of tracks must have been lifted as there were a few wire mods on the back of the board.
Looking at the replacement chips, all four of them are different makes and part numbers, and are different again from the four remaining original chips! The data code of the original chips and the rest of the board is 1983, the new ones look to be around 1986. I don't know if they were done one at a time, or if the repairer couldn't find two the same.
The way these are used is that each of the eight 4164 chips is 64K by 1 bit, which together make the 64K by 8 bits required. The originals were NEC D4616C-2, and the replacements were a KM4164A-15, a TMS4164-15NL, a Hitachi HM4864P-2, and an OKI M3764-20RS. All 5 parts are compatible with the standard 4164 part, but their timings are different. I always try to match the part number, manufacturer and if possible the date code, so that they perform the same so there are no timing glitches caused if one chip is marginal faster or slower than another.
In order to test this further, I removed all the chips and replaced them with sockets, repairing the previously damaged tracks.
I then installed a matched set of working 4164 chips (TMS4164-15NJ) and away we go, the Commodore 64 is working again. 38911 bytes free as their should be.
The chips I removed have all separately tested as working, I think it was just a slight difference in timing or a bad connection on one of the repaired tracks. The assortment of chips will be useful to keep though, to add to my collection of assorted DRAM chips used to find matching replacement chips for future repairs.