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?

  • 2
    Would something like the SuperCPU accelerator c64-wiki.com/index.php/SuperCPU or the Turbo Chameleon 64 c64-wiki.com/index.php/Turbo_Chameleon_64 be a viable alternative for you? Unfortunately, they don't simply speed up the good old C64. They are more of an add on that programs that are specifically designed for can make use of. Apr 20 '16 at 19:20
  • 1
    This question is definitely interesting and on-topic (even though the correct answers may lead into a different direction than you originally hoped), but it could use some pointing out what research you initially performed - that might yield some more upvotes. Apr 20 '16 at 21:00
  • 3
    What would you want to speed up your real Commodore 64 for? Old computers are interesting for what they are, their limitations, speed included. Deviating from common configuration makes what you do less reproducible and reduces impact. In the rare cases when I need a faster old computer, I fire up a software emulator in a modern PC. Most good emulators have an option to run emulated machine at various speeds. See for example VICE, the Versatile Commodore Emulator, 6.4.1 Performance resources May 17 '16 at 15:14
  • @StéphaneGourichon I could see wanting to recreate original accelerator hardware that was available at the time for the purposes of experiencing what using a retro computer with a retro accelerator was like. Using a higher speed option on an emulator isn't really going to give you that same experience as using actual retro (or recreation retro) hardware.
    – mnem
    May 17 '16 at 19:53

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.

  • I've seen a modification that replaced the 1MHz 6510 with a daughterboard containing a 6502 running double-clocked, plus support circuits. I don't know how well it works.
    – Mark
    Apr 20 '16 at 20:36
  • 4
    The C128 had this problem in C64 mode, and Commodore's solution was to allow enabling the 2MHz mode when video output was turned off. My understanding is that C128-compatible programs could do this every vblank for a speedup.
    – rcntxtlztn
    Apr 20 '16 at 21:30
  • Wouldn't you be able to overclock a PAL computer to NTSC speeds? :)
    – SF.
    May 16 '16 at 13:10
  • @SF., yes, if you replaced the PAL VIC-II with a NTSC one, or possibly if you had a PAL monitor that could handle the strange PAL/NTSC hybrid timing that resulted from the overclock.
    – Mark
    May 17 '16 at 18:25
  • 3
    On the C64 you could disable the video chip temporarily to speed up calculations a bit - POKE 53265,PEEK(53265) AND 23 (turn off screen display) and POKE 53265,PEEK(53265) OR 16 (turn on screen display)
    – Joe
    May 18 '16 at 11:36

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.

  • If the memory seen by the external CPU was getting corrupted, that would suggest that you had a race condition when trying to decide whether or not any given cycle should stall. I wonder if adding six 16x4 FIFO chips to hold pending writes would have helped (the 6502 can perform a maximum of three writes every eight cycles, but unless code is stuck doing BRK instructions it would seem unlikely that it could do 16 writes in less than 64 cycles or otherwise manage to fill up the FIFOs).
    – supercat
    Jan 10 '17 at 23:17
  • I'm trying to remember what exactly I did, but if the 4Mhz CPU wanted to do a write, i stretched the "off" cycle a little until the write cycle synchronized with the main board 1Mhz clock and it used that to perform the write, then sped up again. Writing to a 8 bit FIFO (or even a simple register) would have sped things up further for sure, but I think my logic circuits had just enough delay that the edges of the read/write interfered with the VIC - maybe i was 50-100ns off but who knows?. In 1990 even my college engineering lab didn't have good enough kit to tell Jan 13 '17 at 6:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.