Commodore 64 - Restoration and Upgrade Log

Soldato
Joined
22 Oct 2002
Posts
8,434
Location
Near Cheltenham
ITEM: C64 Breadbin, advertised as good condition but has a rolling RF image that looks 'black' with a hint of a white line or something. offered with third party tape deck, joystick, psu and RF switch.. £60 delivered, mainly based on condition in the photos'

rUKY9wFh.jpg

Immediate thoughts:
- Looks OK, not too bad, no major cracks or anything, the joystick handle rotates, so assume that's broken, and the tape deck is hilariously vintage/cheap.. almost worth keeping since everyone has a Commodore tape drive/dataset
- slightly yellowed C64 but not took bad.
- Tape drive is hilariously yellowed...

Plans:
- Fix it obviously!
- Clean/Retrobrite at some point
- YUV Mod to allow RGBtoHDMI to work with it
- get some proper joysticks (something modern with some form of adapter)
- Maybe get an original Commodore dataset.
 
To start fault finding, the first thing was to just switch it on!


Initial power on via the Retroscaler 2x (S-Video to HDMI at the moment):
mJvmApbl.jpg
That is a black screen with a vertical white line, pretty much as expected.

So then opened it up to take a look:
Found the centre case screw just turned, so knew it'd have the standoff broken:
RYP6IeRl.jpg
It's still on the screw, so could be salvaged.

And the state of the PCBA?
RUHnTHxh.jpg
another 'eeeeewwwwww'..

Overall view of it isn't too bad:
d5rWrr3h.jpg
Bit of oxidisation on the tuner (will no doubt be disappearing so not a problem!) and very dirty, with minor tarnishing of the cassette port (which shows it clearly had a lot of 'action')

I removed the SID chip since it's not needed yet and don't want to damage it..

Following several videos of 'black screen' I particularly like Noels Retro Lab's approach..
- Check PSU (9v AC + 5v DC)
- Check 12v and 5v regulators on the bottom right
- Check +5v / 9v AC on user port

So promptly set about that, and then 'pfft'.. My DMM probe slipped when measuring the input voltage (pin 1) of the 12v regulator, blowing the glass fuse (1.5A 250v).
Looking around I found my collection of glass fuses, but they are the much smaller ones, so I grabbed the nearest (1.6A) and did a nice bodge:
nzy1ecSh.jpg
That will tide me over until some larger fuses arrive tomorrow.

I then repowered and checked, everything was fine, same as before... Phew...

So I pulled the cover off the VIC-II and found some handiwork:
0F8Sspjh.jpg

Someones replaced the PAL clock cystal and creatively grounded it.. so looked like a good place to start
(I also took the opportunity to just use the anti-static brushes and the mains powered air duster (love that thing!) to give it a quick blast..)

Following Noel's fault finding sequence, I started looking at the clocks around the place
Colour Clock - Bang on 17.73Mhz so that oscillator is OK!
Pixel Clock - 8 Mhz
PLA Clock in/out - 1Mhz
6510 CPU Clock - 1Mhz

So they all check out..

Next up was the Luma/Chroma signals on the VIC-II
They look correct for a black screen with a white bar (I can see the sync pulse and a spike, so that's about right).

This one isn't looking 'easy'.. Youtubers at this point start whipping chips out left/right centre and swapping them with known good, or trying them in a good C64..
I don't have that luxury.

So I scoped around address and data lines to see what is what and noticed two things
A13-A15 all have a very regular pattern on them with gaps, almost too perfect and all overlaid precisely. however checking the Memory Map, that's likely in the Kernel ROM space ($E000-$FFFF.)

Then, this:
D0-D3 all have a weird pattern that looks electrically wrong, the 'highs' for some databits are 1.5v..
D55dfiqh.png.jpg
D4-D7 are all what I'd expect (roughly 0-5v)

So ai started looking at things hanging off the those lower databus bits, which is most of the ICs, however it might rule out the PLA since that has no data lines...

On visually inspecting the RAM/ROM ICs I notice one of the RAM chips looks factory but different to the rest:
iGhtYuFh.jpg
U10 has a different screen print, same manufacturer and that soldering looks oxidised and as neat as the others..
So, I thought I might as well whip that out, a chance to try the desoldering station as well!

So, you know when everyone makes it look easy on youtube and you just start having a nightmare of a time!
Well, I was rather hoping the SD915 soldering station that everyone uses would just do the job..
- I reflowed all joints with leaded solder (Crystal 400)
- I set the SD915 at 300C (and also tried 320C)
- I used the stock tip and also the smallest one they provided.

The issue is whilst the holes look clear, the legs aren't quite 'free', a small bit of solder hangs on on the top side of the board:
TYaZd9Dh.jpg
You can see the bottom row has small solder bridges left, and you can see a pad (luckily it's just the end of a via and not attached to a track, that's topside!

I reflowed the joints a few times, tried 320C, a smaller tip, and slowly got most free, i.e. completely 'free' and moving easily..

I am using the 'hold it on loosely for 5 second, move slowly around in circles to make sure the heat transfers through, I can feel the pin moving, then press the button for the vacuum, and it largely gets it all out, but leaves these straggling small bridges.

So I just used a screwdriver to see if the RAM IC would lift with little effort, and surprisingly it almost fell out.

And this is the problem, experience, experience, experience.. I was clearly over doing it and tiny bridges are probably perfectly fine, since I notice many people removing them use a screw driver to lift, so must need a tiny amount of force to break free..
Anyway, no damage, all good, anything with a pad is perfect, and despite ten or so attempts, I've not buggered it up:
gYoEW80h.jpg


After checking all pads/tracks and continuity twice, I powered it up and scoped D3 (the bit U10 is responsible for) and..

Exactly the same!! Bugger..

So I have run out of things I can try at this moment.. I need the diagnostics, dead test cart which is due tomorrow/tuesday
The plan is
- Remove and socket the ROMS
- Remove and socket the RAM
- Remove and socket the PLA
- Maybe remove and socket the CIAs

I'm a bit of a noob to this and my electronics is only entry level, so I've being open minded, it looks like contention on the databus, i.e. two devices trying to put data on the bus at the same time, one with a '1' and the other a '0'
Or it's just a faulty IC that is electrically dragging D0-D3 down.. who knows!

It's fun though..
 
Last edited:
Small update:

I decided to get a bit more experience with the desoldering station ahead of getting the DIP/DIL sockets (should be here tomorrow).
I thought I'd have a go at the ROMS, since all are nicely position alongside each other (3 of them).

Watching some more youtube, I tried the following and seemed to work (all but one small minor issue)

1. Used some paste flux (have a few small tubs from plumbing stuff!)
2. reflowed with leaded solder
3. Used 350C on the desoldering station (and cleaned it out)
3. Did the wiggle whilst heating and then desoldering method (just a 2 seconds of heating/wiggling, then switch the vacuum one with one final wiggle and keep it on whilst removing the iron).

At this point they looked a little better, but still not completely 'free' if you try moving them with tweezers/small screwdriver, so the extra technique that seemed to work:
4. use the soldering iron, placed just on the pin (not the pad) and gently push the pin away from the body of the IC.. no need to go mad, just gently pressure, once that last little bit of solder melts, the pin gently moves to the side, then just remove the soldering iron..

The only issue I had was another tiny pad at the end of a via came off, that was me over wiggling and being more hamfisted, so at least I know the issue! That was one of the set of pins I did not reflow, I thought I'd try 5 pins without reglowing, which seemed OK, but it did seem more awkward 'wiggling' the desoldering station around, so think I'll always reflow as a matter of course..
Drn5Oluh.jpg


And, I checked after removing each ROM if the D0-D3 issue above went away, and
U3 Removed - No real difference
U4 Removed - Big difference!
U5 Removed - no change

With U4 removed, the databus seems better, not quite perfect, it still seems it's got more contention that the D4-D7 lines, but a degree better:
i.e. (as above)
WAS:
D55dfiqh.png.jpg

NOW:
9eN90xph.png.jpg

So the fact that now other accesses on the databus are predominantly 'OK' for the lowest nibble makes me think U4 was buggered (KERNEL ROM) which is plausible..

Of course, the PLA is responsible for memory space addressing logic, so that might also still be a culprit, so I checked A12-A14 quickly and they also seem different, not locked together, so seems to be now reading from a wider range of addresses, which may or may be normal due to the ROM not actually being there.

So, in my naivety, I'm 60/40 that it's the KERNEL ROM (U4)....
The dead test cart will prove that since it bypasses all ROMs anyway.

Just been on the t'inter webz and ordered:
8-in-1 Kernel replacement ROM - £11 ( includes dead Test as 1 of those!)
Plankton EV replacement PLA - £15 (could get regular Plankton of NeatPLA for £11 but I like the idea of the EV version being voltage perfect!)
TOLB Module £10
 
Last edited:
Arrived home and the Multi-Diagnostics cart turned up!

Quickly plugged in, it defaults to the 586220+ diagnostics rom.
- Black Screen still..

So reconfigured it to boot the dead test cart,
Almost immediately 5 flashes on screen, pause, 5 flashes, and so on..
Checked online, that's U10 apparantly.. DOH! That's the RAM IC I removed yesterday.

Luckily the DIP sockets turned up as well, so popped one in:
BygQioCh.jpg

Then re-powered it up.. and..
QWu9Vr7h.jpg

Yey! Progress.. I even popped the SID back in and that's working! so that's CPU/PLA and VIC-II and RAM ICs basically OK..

I retried the 586220+ ROM (diagnostics) but no joy...

Next up was putting sockets in for the 3 ROMs and one by one fitting those and seeing if dead test still works..

And surprisingly, dead test was OK with all 3 ROMs, or maybe that's unsurprising as the dead test cart bypasses the ROMs, what it shows is that any electrical issues with the ROMs is not dragg8ng the bus down when they are not 'selected'..

Hopefully the replacement 8 in1 ROM turns up today or tomorrow and we can go from there.
 
Nice thread :)Think i got my C64 with tape and disk drive in the attic somewhere.Will have to hunt it out to see if it still works
A good time to check it's all working! :)

I'd say from this C64 and the C128D in my other thread, if you could find somewhere to store them in the house, I'd do that, they are all now at that age that oxidisation might start hammering their reliability and make them much harder to repair.
 
Dry and warm in my attic :)
iirc the joystick port started playing up so i took it to 2 different shops.Both said they had fixed it
Ripped me off as it was not fixed so i lost interest in computing for nearly 10 years before i got back into it with a 450mhz system :D
 
waiting on bits for the other projects, I got back on the c64 tonight…

The new 8 in 1 kernel ROM had turned up, so plonked that in, turned on and …

Nothing… same black screen issue..
So, one of the 8 ROMS is the dead test, so thought I’d try that, and weird, it’s flashing 8 times, indicating u21 (RAM chip), so I switched the ROM back to the normal kernel and used the external dead test cart..
That booted and was testing, it thinks u21 is OK!

So at this point I’m confused, same code, running from the different locations has different results....
I started to buzz out the address and data lines between cart port, Kernel ROM and external cart, but all are connected..

So I got the oscilloscope out again and had a snoop around..
- Weirdly, when booting externally, the d0-d3 lines have less traffic and look OK, if booting from the kernel ROM socket, even using the dead test cart, D0-D3 have that weird low logic level traffic quite regularly..

So, I went back to the normal kernel and scoped the CS (chip select) lines of ROMs and the RAM address decoders..
- The RAM decoding logic looked OK, nothing weird
- The 3 ROM chip selects though.. only the kernel ROM was being toggled.. but the basic ROM was permanently high, the Character ROM permanently low, which means the character ROM was always enabled and thus it would be in contention on the data bus..

Pulling the character ROM had two effects,
- Suddenly it booted to the blue screen, albeit with weird alternating patterns
- The low chip select was still low..

Great progress!

At this point, considering the ROM chip selects come from the PLA, I quickly socketed the PLA and as luck would have it, the PLAnkton PLA had turned, so put that in and
fired it up, and it booted!

A perfect time to hook up all the diagnostics harnesses and run the full diagnostics checks..
tMiR0sch.jpg

And…



CtEdPnUh.jpg

yay! Another one to a point I can start to think about restoration and modding..

I can see why people struggle with the black screen issue, often it gets confusing and sadly you do need some spares to really rule out PLA and Kernel ROM..
 
Last edited:
Hopefully get some more time on all my computers, just about to button up the C64.

- Recapped the entire board (£5 for a kit)
- Superglue'd two PCB standoffs back on, these had a large surface area and fitted perfectly back from their original position, so hopeful those will 'stick'
- Borrowed some plastic adhesive from work for the case mount that was broken, I tried 3 different adhesives until one looks to have correctly adhered, it is a agressive, so is a one time deal to some extent.. I can see stress lines on the other case mounts, so if this works, wlil be ready for any others failing.


The main focus at the moment is really on trying to get a decent image, it's OK, but the Tuner module in mine is one of the know rubbish ones!
So far it's looking like:
o7mQoL0l.jpg

With the blue on blue it really highlights the ghosting and those scan lines should not be there (I think), the Retroscaler 2X does not have a 'scan line' simulation mode!

The two main aspects to image quality that I'm going to address:

- VIC-II - Mine is an early'ish 6569R3 PAL, so I've ordered a later 8569R2 PAL but this needs an adapter PCBA (already delivered!) so will be interesting to see if it makes any difference
- RF Tuner Module - I believe mine is the well known (for being rubbish) 3403 version so will get a bypass module and get rid of the tuner entirely. I am normally not a fan of mods that remove large chunks of the original, but to keep it relevant on modern displays, I'll have to just do it.

Having to leave teh plastic adhesives 36 hours to really set, I will button up the case tonight, and then maybe try some games via the same PI1541 I mentioned in the C128D thread:
282kAHkl.jpg

I've put a Pi 3B+ in it and got that to a point it's booting nicely and should be good to go!
 
Last edited:
So getting home I have 3 international parcels awaiting, so everything needed to get me to the point of being able to button this up tonight..

The aim was to try an 8539 VIC-II with the requisite adapter PCBA that allows this newer VIC-II to be used in the earlier C64s..

Before: Original 6569 VIC-II: Note the text shadow and really 'bitty' look to the light text....
o7mQoL0l.jpg


8569 VIC-II:
Pv82iGal.jpg

Immediately the text shadowing looked markedly better, and far less lines.... although it did look a touch soft.

So I then swapped back to the original 6359 VIC-II and had a pleasant surprise:

Original 6569, reseated:
23azpmal.jpg

This was much sharper and also has markedly less ghosting than it used to, weird!


The conclusion is that I suspect the socket/pins of the original 6539 where oxidised and causing some slight issues..
I took it out again, cleaned the pins with IPA and a brush, used a smidge of contact cleaner, and used a small bit of metal to just work each pin a bit..
I stupidly did try it before all the IPA/Contact cleaner had evaporated and had a garbled screen briefly, so let it dry and it's still looking like the much cleaner image above.

The dead test cart which has a white background with dark text looked very clean!

Next up was the legendary ARMSID replacement (It's actually for the C128D which seems to have a failed SID), but whilst I had the chance, I quickly swapped it out.
It just worked first time, I'm not sure if it's quieter, but I certainly couldn't hear any difference in tone etc vs the original when using the test carts.. So this is ready for the C128D!

I've just assembled the C64 and have ordered a larger microSD card for the 1541 as it seems the Raspberry Pi 3 is a bit fussy about which microSD cards it seems happy with... the samsung microSD cards seem a bit slow, and browsing the menu on the Pi1541 is painfully slow, I had a 8gb old sandisk card that is much better, so have ordered a 32gb and 64gb card as recommended by people using the Pi1541 which should be here tomorrow!
 
Last edited:
Since some of the other mods on the other computers have been faulty and awaiting replacements, I happened to get an email alerting me the new c0pperdragon VIC-II-DIZER was in stock and shipping, so grabbed one of those..
The main reason is that after warming up, the video quality dips a little on the C64 and connecting to a large monitor, it just looks much worse..

OtyXeMrh.jpg


The actual Vic-II-Dizer is the top PCB, super simple to fit.. The bottom is another RGBtoHDMI board with the correct interface on it, it was all sold together as a kit.

Just needed a PiZero and SD Card.. Foruntately/Unfortunately the BBC B's PiTube was faulty which meant I have a temporarily spare PiZero.

Installing was a breeze as such,
F3eegtIh.jpg


I did use the croc-clips but will solder this shortly as croc-clips feels like a bodge, however it's a 2 minute installation process because of it!
The niggle on mine is having the 240507 C64 Main board, there is R27 (just under the connector with the green/white wires, a potentiometer that sticks up a fair bit) but all that needs is to piggy back everything on another 40 pin socket, so having loads of those it wasn't a problem, but does jack the VIC-II Chip up above the can and the heatsinks stick out a bit (but don't hit the keyboard..

I love the principle of operation on this, the VIC-II-DIZER intercepts writes to the video memory (effectively) and so builds it's own 'shadow' copy of what is therefore drawn to the screen.. it then encodes that (in this case, single signal LumaCode). You can plug this into a compsoite input on a monitor, but will give you the following (borroed from c0pperdragon's installation instructions:
N9vlgFrh.jpg

But once connected to the RGBtoHDMI, it decodes this bit perfectly and out pops a pixel perfect HDMI image that is great on larger monitors (the entire reason for doing this).

So with the Pi1541 loaded up with some games, I just fired it up and wasted an hour playing Jet Set Willy and International Karate.. The 'Boss' Joystick this came with is not the best for this kind of game, so ended up on keyboard (I may use the atari joysticks, or get a competition pro).
mmaPGL8h.jpg

QZm939sh.jpg


I used the Sony surround sound system (to the left of the portable monitor) to get audio, one of the things lack in this setup is audio over HDMI..
I could get an audio injector (~£25) and do that in a permanent install to save using external speakers, but it sounded very good through just modest desktop surround stuff..#

The only odd thing is the colour mappings probably need some tweaking (can all be done in the onboard menu of the RGBtoHDMI, but it's a bit daunting) as the default C64 BASIC screen has grey text when I'm sure it should be border colours, but will post on the forums about this as it's so new..

Next up for the C64? I'm not sure, it's just about there now
- Solder the Vic-ii-dizer wires so they are more permanent.. despite taping, croc-clips just bug me..
- I want a Epyx Fastload cartridge (with reset) button to augment the Pi1541 - You can get all in one Fastload Cartridge with built in Pi1541 but I like the 'old skool' 5.25" floppy design of the Pi1541 I have.. but loading takes an age!
- Look at the competition pro joystick for some of the games, keyboard playing is OK, and what I did as a kid mainly, but playing a few games had me missing a quick digital joystick.. I could try the Atari ones and see how I get on (since they are all compatible).
 
Last edited:
Iirc there used to be a program called something like `Turbo`i used to use back in the day and it at least halved the loading time of games from the 1541 floppy drive :)
Definitely needed, it's funny waiting 2-3 minutes minimum in this day/age..

THe three options seem to be
1. Software Loader - Good in being able to be very selectively applied (some games don't work well with turbo loaders), but extra loading/steps to do for each game
2. New ROM - Can get various fastloader based ROMs so it's baked in at boot, however disabling is not easy and a faff when a game doesn't support it.
3. Cartridge - Will effectively boot as a ROM with Fastloader built in (so similar to just fitting a new ROM), but you can just remove the cartridge if the game doesn't work with it, and it has a reset button built in!

I might try the software loader tonight then, I've got those disk images of it.. I do have a switchable ROM and have tried that already so know the Fastload ROM works well..
 
OK, I've just noticed the JSW screen shot shows an issue:
mmaPGL8h.jpg


The men down the bottom (indicating number of lives) are all wrong, or specifically some of them are the incorrect colour!

The colours should be
White | Red | Cyan | Purple | Green | Blue | Yellow | Orange
Mine are:
White | Blk | White | Purple | Green | Violet| Green | Orange

So really scratching my head this morning, not knowing what the issue is and can't fathom if its the RGBtoHDMI or the VICIIDizer or what..
However looking at it logically, the colours that are wrong give a big clue, if you look at the C64 value for each colour I would say that the second data bit is permanently '0'.. i.e. D2 on the VICII is permanently low.

This means, Yellow (value = 7) would be read as 5 which is Green
Red (Value = 2) would be read as 0 which is black
Cyan (Value = 3) would be read as 1 which is white
Blue (Value = 6) would be read as 4 which is violet

And grey text in stead of border (light Blue);
Light Blue (value = 14) would be read as 12 which is Medium Grey!

I'll check it tonight, considering I had to use a cheap DIL Socket to increase the height, I have a right stack up
-PCBA
-Original 40 PIN DIP Socket
-Cheap 40 PIN DIP Socket
-VICII Dizer 40 Pin Socket
-VICII IC

So will start doing a VICII IC to bottom of PCBA connectivity check..
 
Last edited:
@Demon Would love to know which glass fuses they use. I used to have a good few spare fuses for my C64C that would occasionally blow.
Reminds me of the good old days paper clip resetting for Zzap64 cheat codes and then SYS code to resume.
 
@Demon Would love to know which glass fuses they use. I used to have a good few spare fuses for my C64C that would occasionally blow.
Reminds me of the good old days paper clip resetting for Zzap64 cheat codes and then SYS code to resume.
The bread bin uses 6 x 30mm fast blow fuses, I think the original was 1.6A, I replaced with a 1.5A.

And in an update on the ViC-II-Dizer, after getting some support indirectly from c0pperdragon and IanB from the seller, I was on the right lines, the d1 line of the Color RAM was being attenuated by the VIC-II-Dizer, it looks to be faulty as that pin measures 172 ohms to ground, where as all other data lines are open circuit..
What threw me is d1 of the color RAM is connected to D9 on the VIC-II so initially was looking at the wrong pin!

Hopefully the seller will exchange this one..
 
Last edited:
Ohhh I have my c64 in the cupboard upstairs - been stored in a loft for decades then moved to 'safety' 5 years back...

I've not tried to set it up for fear.of opening Pandora's box... Or checking on Schrödingers cat to find it's dead.. ignorance is bliss for now!!
 
Back
Top Bottom