Last Summer, after a delay of mere 38 years, I finally acquired my first Commodore VIC-20, or VC 20 as it was called in Germany. Not all parts of the machine are in their original state as the connoisseur will notice on first sight. I don’t care too much about that because I didn’t want it as a collector’s item but as a technical gadget to play around with.
My first VIC-20, freshly supplied with a donor keyboard.
First thing I had to do to even test the machine was to make a new video cable to connect it to a monitor. The pin-out of the A/V jack differs from that of the C64: there is a Vcc output where the luminance signal should be and there is no S-Video output.
Last year, I acquired my first VIC-20 and when I discovered that someone shared the Gerber files for a fairly recent version of the Final Expansion 3 (english) for that machine on Github, I decided to set out and build one of those, of course. The FE3 might be a story for a later post, though. Because in order to build that cartridge, I first had to find an affordable way to program the ATF1504 CPLD that is used here.
The ATF1504 CPLDs turned out not to be not as “new” as the seller claimed.
The original external power supply for the Commodore 64 comes in different forms but they all have one thing in common: With increasing age they are prone to failure and when they finally break they are likely to destroy the precious computer they were powering.
An original PSU for the Commodore 64.
The power brick for the Commodore delivers both 9V AC and 5V DC, the latter being produced from 9V AC with a voltage rectifier and a linear voltage regulator. While this voltage regulator is generally very reliable, it has to operate at the upper limit of its specification which takes its toll after decades of use. When the regulator finally breaks, it tends to short internally, thus supplying the sensitive TTL ICs inside the C64 with up to 9V instead of 5V since there is no integrated over-voltage protection.
Cartridges for the C64 provide either 8K or 16K of ROM that will replace parts of the memory visible to the CPU when plugged into the expansion port. Either 8K or 16K, that is all the Commodore can see directly on a cartridge. Then there is an auto-start mechanism implemented in the Kernal that can be triggered to execute code contained in that ROM when the machine is powered on or reset. Jani features an excellent article about how to create such simple cartridges on his site which I have linked to before.
A simple ROM cartridge: the OpenC64Cart.
I’ve covered the PLA and the question how to replace a broken one before. First, when I repaired one of my C64 from back in the day, needed a quick replacement, and used an EEPROM on a simple adapter board. In a follow-up post I used a simple circuit suggested in a talk by Eslapion to test this PLA replacement for glitches and found plenty. Last but not least, I created a replica of the Super Zaxxon cartridge also to be used for testing the PLA. There is a lot more information online on this topic like the excellent Post on Breadbox64.
The broken PLA from a C64 mainboard.
A quick market survey on RAM expansions for the C64
The Commodore 64 features a whopping 64kB of RAM, hence its name. Most of this is actually usable at least when programming in assembler. While this used to be quite a lot when compared to competitors in the market, even back in the day there were different external RAM extensions. Some of the popular “freezer” cartridges like later versions of the Action Replay or the Super Snapshot feature some additional RAM of their own.
Commodore started selling their RAM Expansion Units (REU) in 1985 when the C128 came out. The REU was actually quite sophisticated, with its own controller — the MOS8726, REC — that provides fast memory-transfer by DMA.
The Kernal is the low-level “operating system” of the Commodore 64. The functions it provides are the basis for higher level routines in Basic and most other software running on Commodore’s 8-bit machines. In case of the C64 it comes in the form of an 8k ROM chip or as part of a 16k ROM chip in later versions. So the good news is, the Kernal is immune to corruption though any kind of malware. The bad news is, there is no easy way of updating or replacing it although Commodore’s original Kernal leaves a lot of room for improvement.
Kernal ROM from a C64.
An Award Winning Board
Today, I’d like to share some brief news and updates on multiple topics. First up is some exciting news. Last year, when I created and shared the Pi1541io layout I had those boards made by PCBWay and I entered their 2nd annual design contest on a whim with the popular revision 4 of the Pi1541io. And what do you know? Shortly before Christmas, I received an email from Eric of PCBWay who is letting me know that my board actually won first price in the category Most Popular Designs! Continue reading
A while back — following the repair of a C64 — I posted about testing the PLA replacement that I had used. In the great video on that topic shared by MindFlareRetro, Eslapion mentions two possible tests for a PLA replacement. One of these I covered in my post back then. The other test involves using a Super Zaxxon game cartridge.
Due to the unique way of bank switching implemented by that module, it seems to be particularly vulnerable to glitches produced by PLA replacements. Less-than-perfect replacements tend to produce crashes or skewed graphics when running that game. Continue reading
Last year I created my own rendition of the SD2IEC, dubbed the SD2IEC Pluggable. Version 1.0 left some room for improvement and recently I found the time to take on a new revision. Version 2.0 is even closer related to the design published by Shadowolf while maintaining the “pluggable” layout with the pass-through tape connector.