My recently bought C64 breadbox came with the power supply which looks like a shim. The DIN connector only has 4 pins. Unfortunately it was broken somehow and since it is pured in resin it couldn’t be repaired easily (at least by me).
Looking for a replacement I found a lot of places which state the original C64 power supplies as unreliable and often responsible for a broken C64. Better would be a “new” switching power supply which was handmade and barely available these days.
I also read that the C128 has a switching power supply which delivers the same Voltage (9V~ and 5V-) as needed by the C64 but with a different power connector (square). So, why not use a C128 power supply for a C64?
I got my hands on a used C128 power supply from ebay. Unfortunately it was broken too. But the C128 power supply isn’t pured in resin and can be opened easily by removing four screws. After looking a little closer and doing some measurements the fix was quite easy by replacing the fuse on the primary side (the C128 power supply uses two fuses, both slow blow: one 315mA on the primary side and one 1.4A on the secondary side (AC)).
Okay, the power supply worked again but how to replace the square connector by the DIN one for the C64? I’ve got a few male DIN connectors but fiddling with it wasn’t m first option. Why not use the power cable from the original power supply? The shim was easy to open if you use a screw driver and a little force on the small end of the box. Even the plastic pins in the resin came out easily. Below a picture of the open C64 power supply with the DIN power cord already desoldered:
I was in the mood of messing with real hardware beside all the fpga stuff. Since I’m interested in retro hardware I bought a C64 breadbox from ebay.
The shell was pretty okay but unfortunately all that I could see on the screen was the message “out of memory error in 0”.
Fortunately that seems to be a common problem and the web is full of repair tips. The DRAM seems to be at fault and after 30 years it might make sense to replace it.
The best is to replace all chips but there are quite a few tips on how to detect which chip might be broken. If you see random characters on the screen you might determine which bit isn’t okay and which chip is responsible for it.
The output of my C64 was fine and all I could see was the error message. I decided to replace all eight RAM chips and put the new ones in precision IC sockets. This way I could easily swap them if necessary.
Now its time to get the solder iron and the desoldering pump to remove the solder and the chips. But that wasn’t so easy as I thought. I first added solder again to reflow the solder and then removed it with the pump. Even though it looks like I was able to remove a lot of solder I couldn’t remove the chips. The main problem were the connections vcc and ground. The circuit paths are so thick that they suck away all the heat.
As I didn’t want to keep the RAM chips I cut through all pins with a side cutter. Afterwards it was easy to remove most pins from the board but still the vcc and ground pins gave me problems. I heated it up for seconds which isn’t good as all capacitors in the near went really hot. Fortunately the ceramic capacitors could take a lot of heat and thus they still worked afterwards.
Soldering the IC sockets was easy. Afterwards I put in the new DRAM chips which I got from ebay. And guess what. My “new” C64 worked on the first try! 🙂
I’m still not completely happy with the mockingboard implementation but one can play with it and if it doesn’t work nicely just turn it off (it’s off per default).
Skyfox starts playing music but hangs later which doesn’t happen when the mockingboard is turned off. Another bug is that from time to time I just hear statics and a new recompilation under Quartus fixed that. So something with the timing might not be okay. I’ve added a .sdc file which made it a little bit more stable but I’m open for hints on how to stabilize it.
I fixed another issue which annoyed me lately. When doing a reset the Apple II preserves it memory and software is able to alter the reset vector. At memory $3F2 and $3F3 the reset address is stored and when altered a reset brings you to the prompt (at best) or just hangs somewhere and you can only turn off the MiST. If $3F4 would be a random value and not the XOR between $A5 and $3F3 the Apple II would “think” its a cold boot and starts the Autostart ROM.
I just set $3F4 to zero when the cold boot option in the osd is pressed and the Apple II resets and tries to start from disk.
After the Saturn RAM expansion I’ve looked around for an easy follow up project which I could do in my little spare time. The mockingboard looked like an reasonable addition since the used components where already available as hdl sources (beside the speech chip). I found several schematics for the board which differed slightly. I’ve started with the mockingboard clone by Bill Garber:
Pretty quick I heard the sound effects of the mockingboard system disc (mockingboard1.dsk, youtube). Unfortunately only effects could be heard. It was quiet when it should play the music or the effect when the text scrolls up.
After some fiddling with the clocks and connecting the IRQ line to the processor the Apple resets to the monitor prompt when the text should scroll up. I spend many hours on debugging with different clocks but I didn’t find the cause. Later on I noticed that it always happens when the VIA dropped the IRQ line. Afterwards it was never raised again.
As usual Signaltap was quite a help. The Apple manual (Understanding the Apple II) stated that the reset vector for the IRQ routine is at $FFFE and $FFFF. For my rom it shows $FF59 and looking around I found that it means it jumps right away to the monitoring prompt, *gotcha*.
But what does it mean? I found a quite useful discussion about here: mockingboards. It looks like that on Apple II without the autostart rom the IRQ reset vector should be at $FA86 and on Apple II+ at $FA40. $FF59 is the jump address for RESET on an Apple II. So there’s something wrong with my rom. I’ve changed the IRQ routine to $FA40 ($FFFE=40, $FFFF=FA) and voila it worked and music was played.
It’s still a little wonky and need more debugging (skyfox crashes, no sound on GI Joe) but this could also be some bad disk images.