Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
My Commodore 64 is running quite slow, and my friends want it to be faster, thus overclocking it. But no one knows exactly how to do that. With our current "modern" stuff, nothing seems to help my retro computer get any faster. Naturally I suggested changing the crystal that controls the timing, and of course I was greeted with a series of complaints of ruining the device.
How can I get some more juice out of (overclocking) my Commodore 64?
The basic principle behind overclocking is that if you speed up a clock, everything that runs from that clock will go faster. But there are some parts of your computer that you don't want to speed up, and NTSC (or PAL) video output is one of them.
In order for C64 output to be displayed correctly on an NTSC/PAL monitor, it needs to be sent to the monitor at a very specific rate (the rate at which your computer sends needs to match the rate your monitor expects to receive). Speeding it up or slowing it down will make it difficult or impossible for your monitor to maintain sync.
This leads to a problem on the C64, because the same clock is used to drive both the CPU and the VIC video chip. The end result is you can't speed up the CPU clock without also speeding up the VIC clock, and speeding up the VIC clock will affect your display. So for practical purposes overclocking isn't really an option.
What is an option is to use a faster coprocessor, a completely separate processor that can access the same memory. Such a processor would need to include a circuit that separates the internal CPU clock from the memory access clock, so that the CPU can go faster without affecting memory access time (which needs to stay the same to avoid colliding with VIC chip memory accesses).
Modern PCs are much more suited to overclocking because busses are designed to allow components running at different speeds to work together, via sets of 'request' and 'ready' lines. It's expected in such busses that faster devices will need to wait for slower ones. Overclocking is then simply a matter of taking hardware that runs at 'less different' speeds, and making it run at 'more different' speeds instead. Since modern designs already make allowances for different speed devices to work together, this typically works fine.
The C64 memory bus is designed to have only 2 participants, the CPU and the VIC chip and they must both run at exactly the same speed because the 'bus protocol' is very simply 'take turns'. There are no allowances or features in the design to allow one to run faster than the other. This reduced the cost to manufacture the computer, but also made it harder to mod.
To get a faster operation there are several "extensions" around, which are either connected to the extension slot or replacing the CPU on its socket working like a coprocessor. CMD's SuperCPU, Flash 8, and one project from the c't computer magazine (a German one) reborn as follow-on project LTC64. They have all in common using a WDC 65C816 CPU, a 16-bit expanded version of a 65C02. With some luck a program or game runs even on such a plain 6502 (without any dirty 6510 opcodes) and can handle the faster timing. In hard cases you can switch back to the 6510-only mode.
The above mentioned problem with VIC and I/O access is solved differently. However, they have to slow down the clock for access the "lower" address space (VIC accessed RAM). Some optimization with making this window smaller and using a pipelining method or caching is often implemented to minimize slow down phases. The 16-bit CPU with 4 to 20 MHz is running on its own memory with fast access. ROM/EPROM is usually copied into a shadow RAM area simulating a ROM.
There are some other extensions, based on an FPGA architecture, replacing the whole C64 on an extension card (Turbo Chameleon 64) allowing to speed up the stuff into a 10 MHz region. Here you have all illegal opcode, too. The compatibility to existing software is much better.
It's doable if you have a lot of time, decent electronics skills, and some good test kit to figure out how the VIC video chip and the 6510 share the address and data bus. If I remember correctly, the 6510 reads/writes in one part of the clock cycle, and the VIC chip reads in the other part.
I know this because in 1990 a friend and I made a 4Mhz accelerator board for my Commodore 64 using many of the principles laid out in other answers. We used 2x32kb static RAM chips, a 4MHz 6502 derivative (can't remember which now, but it's still sitting in my parent's attic), and about 4-5 PAL chips to control all the logic.
We removed the 6510, plugged in the board we built to where the 6510 used to sit, and spliced a wire to the video clock (16MHz, which itself is divided by 16 to provide the CPU clock), which was then divided by 4. On every read cycle, the 4Mhz capable 6502 would directly read from the static RAM, and on every write cycle (the circuitry to synchronize clock cycles was very tricky) the 6502 would write to the static RAM AND the main board using the 1MHz clock (whether the RAM there, or special registers, whatever). Essentially, it was what we call today a cache.
It worked.... sort of. We could see programs running at about 3.5x regular speed for maybe a couple of minutes, but we could also see the screen filling up with random characters, indicating that something was corrupting memory. Inevitably, the programs crashed. We think that the VIC chip was somehow attempting read cycles that weren't quite synchronized with our clock cycles, but couldn't find a logic analyzer fast enough to figure out what was happening.
I still think this approach could work if you have modern test equipment, but it's months and months of work.
