According to Wikipedia, the Atari 8 bit series had a 6502 running at ~1.8 MHz.
Why was the clock speed of the 6510 for the C64, which was designed a couple of years later, considerable slower?
Was the main drive to save costs (e.g. lower frequency results in cheaper other components; RAM etc.) ?

  • 1
    It's also slower than the Commodore Vic-20 that immediately preceded it, though only by a little. In the Vic-20's case the ostensibly overrated CPU was underused partly because the clock received is irregular; the shortest phase it has to deal with is that which would normally be implied by a faster clock. There is a difference in necessary rating between a CPU that is permitted to run for every nth cycle of a q Mhz clock and one that runs at a constant q/n Mhz. I can't speak exactly as to the C64 or Atari though, so this is not an answer.
    – Tommy
    May 2 '17 at 19:45
  • 3
    It should be mentioned that the frequency of the Atari clock was based off the NTSC colorburst frequency of 3.579545 MHz. That frequency was divided by 2 to give 1.7897725 MHz.
    – cbmeeks
    May 3 '17 at 15:23
  • 1
    I wonder what was the clock speed of the 6510 for the C64? May 3 '17 at 16:00
  • 2
    @cbmeeks: The Apple II, Commodore VIC-20, Commodore 64, and Commodore 128 all use a clock frequency derived from chroma, specifically chroma*2/7. The Apple II series actually use Chroma*4 as the highest-frequency dot clock which is subdivided by 2 for normal pixels and then by seven to identify byte boundaries; the VIC-20 uses chroma*8/7 as a dot clock, and the C64/C128 use chroma*16/7.
    – supercat
    Jun 25 '18 at 23:30

Somewhat of a guess: 

The C64 always interleaved CPU and graphics RAM access (with additional graphics cycles if necessary), effectively accessing RAM at 2 MHz.

Judging from the ANTIC Timing Diagram, the ANTIC just stole CPU cycles whenever it needed them.

So in both cases you have a RAM access of about 2 MHz, which seemed to have been the limiting factor. So in fact the C64 is not "slower", it's just the cycle distribution that's different.

  • 2
    The VICII chip was driven off the same clock, and would access memory on both sides of the cycle of the 6510 (so basically 2MHz). I can't find a strong enough reference that says that says this is the reason it's clocked at 1 MHz though...
    – Joe
    May 3 '17 at 1:23
  • 6
    @Joe: The 6510 has a two-phased clock, and accesses memory only in one phase. The VIC accesses memory in the other phase (not "on both sides of the cycle", though of course there's one Phi1 phase before and one Phi1 after each Phi2 phase), which is 1 MHz. The VIC also steals extra cycles if needed through the AEC signal, google for "badline". Also see e.g. here. BTW, the Apple II does the same thing, without cycle stealing.
    – dirkt
    May 3 '17 at 5:55
  • 3
    You can judge this looking at C128. Machine has two graphic chips VIC-II and 8563. Former has shared memory, later has dedicated video ram. In C128 mode you can run on at 2Mhz only with 8563. 8563 is not available in C64 mode but you can sill run on 2Mhz by disabling VIC-II video output.
    – wizofwor
    May 3 '17 at 6:20
  • 2
    @wizofwor: The 8563 is available in C64 mode, as is the register to double the speed of the CPU. It's too bad the 8563 never caught on in the embedded-systems world, since it's a nicer architecture than many of the other display designs out there.
    – supercat
    May 13 '17 at 17:13
  • 2
    I don't think I've ever read anyone praising the 8563 before. All I've read is complaints about the double-indirect memory access pattern and the lack of interrupt generation. :)
    – Mark Reed
    Dec 7 '20 at 17:41

Memory chips of the era were limited to an access speed of about 2MHz. On the Atari 400/800, cycles could be given arbitrarily to either the processor or the display hardware. On the Apple II and VIC-20, there are 65 cycles per scan line but half of each cycle is given to the processor and the other half the display hardware, whether it needs it or not. On both machines, screen text is read out while it is being displayed. Since text rows are 8 scan lines high, each byte of screen text will get read eight times per frame (once on each scan line where it appears). The Apple can display a group of seven pixels on each cycle, as it reads only text (character codes) from RAM, while reading character-shape data from a dedicated ROM that has its own connection to the video circuitry and is not mapped into the CPU address space at all (that's the reason you can't change the text-mode character shapes on the Apple). The VIC-20, on the other hand, outputs a group of eight pixels every two cycles. The first cycle of each pair fetches a byte of text, and the second uses that byte to fetch the associated byte of character-shape data, either from ROM or RAM, so that the character shapes can be redefined. Color memory on the VIC-20 has its own dedicated bus so that it can be fetched simultaneously with text memory; the Apple's text mode is black-and-white only, so no color memory is needed.

Things are more complicated on the C64 since the VIC-II chip's output on every cycle is controlled by a byte of text memory (and color memory, which is fetched at the same time) and a byte of character-shape memory. For each row of text, the VIC-II chip will have one scan line where it needs to fetch both kinds of data, using both halves of every cycle to do so (stealing the bus from the CPU); it will then remember the text data that was fetched, so that on remaining seven lines of each text row, it can use its half of 40 cycles to fetch character data associated with the already-fetched 40 bytes of text.

Displaying eight scan lines of text with all eight sprites showing would require fetching 616 bytes of data, but there are only 520 cycles every 8 lines, so there would be no way to avoid having the VIC-II chip steal at least some cycles from the main CPU in at least some circumstances. I don't know how much it would have cost to augment the VIC-II's buffer so that it could fetch 5 bytes of text data during horizontal blank every scan line rather than stealing groups of 40 cycles from the main CPU, but some cycle-stealing would have been needed to support all the sprites in any case.


It's mainly based on VICII's (or generally for memory mapped video adapters) demand together with limitations on access time for RAM and ROM components. VICII has to access the RAM (video character, hires, sprites, RAM refresh) interleaved with the CPU and ROM (character set), as already commented above. Generally speaking:

  1. Faster RAM were a cost problem, because RAM access is twice the speed of the CPU (interleaving access of CPU and video chip): in a single CPU clock cycle two RAM accesses occur. The BBC micro with its 2 MHz CPU needed 4 MHz capable RAM chips which only few vendors could provide.
  2. I/O chips are mostly pinned to 1 MHz.
  3. Dependency to the video chip which has a big demand on RAM bandwidth, but has only interleaved access to RAM (competing with the CPU) but still have to do the RAM refresh.

Later Commodore models like the C16, C116, Plus/4 run with 1.8 MHz CPU speed, faster RAM were common, but even there the video chip (TED) throttles the CPU down while displaying a video frame. Driving the video chip faster would have an overall impact on the system's design: first to mention the need for faster and expensive components, but also thermal aspects on the video chip come into play (VICII, TED seem to be on their limit even with 1 MHz). Commodore's solution if they want to raise the CPU speed were to add a second video chip with separate video RAM (see C128 comments above) or to omit RAM access intensive display modes (hires, sprites, ...) used for the CBM II line (B128, B256 "business" models).

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.