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.

Monday 2 December 2013

USB Keyboard PCBs


I've been making a lot of USB Keyboards recently, and have been using a variety of controller boards. The older ones used ATmega328P microcontrollers on matrix board (as seen here as a ZX Spectrum Plus USB Keyboard)
The later ones used modified Arduino Leonardo boards with ATmega32U4 microcontrollers (as seen here as a ZX81 USB Keyboard).
This is fine for ZX81 and ZX Spectrum USB Keyboards, where the 8 pin and 5 pin connectors for the ZX81 fit perfectly, and the ZX Spectrum ones be can be added by extending one...
... or both of the connections.
However, it is a bit of a problem for Commodore 64 USB Keyboards 
and Acorn Electron USB Keyboards,
which have a single longer connector. I have been using Arduino shield prototyping boards plugged into the Leonardo to wire up the 22/24 pin keyboard connectors.
I thought it was about time I came up with a better solution, so I've designed a PCB for my USB keyboards.
It's not a particularly complex board, basically it has the ATmega32U4, a selection of USB connectors, an ICSP connector and the rest of the ATmega32U4 pins are taken out to a 22 pin header for connecting various keyboards. My surface mount soldering isn't the best, so I took the easy option of using through hole for the rest (although some of the package size choices could have been better).
I've also added a three pin LED connector for Commodore cases (using SCK from the ICSP header so it will flash during upload and testing.
These can now support Commodore 64, Commodore 16 and Commodore Vic20 USB Keyboards,
as well as the Acorn Electron.
They seem to have turned out very well, so based on these, I'm now putting together a ZX81 / ZX Spectrum version which should be available soon.
So, if you fancy a vintage computer upcycled into a USB keyboard to use with your PC / Mac / Laptop / Tablet / Raspberry Pi / whatever, then Contact Me, or buy one direct from my Etsy Store.

2023 Update

USB Keyboard Controller Kits are available from my Sell My Retro store:

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