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.) ?
-
1It'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.– TommyMay 2, 2017 at 19:45
-
3It 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.– cbmeeksMay 3, 2017 at 15:23
-
1I wonder what was the clock speed of the 6510 for the C64?– Wayne ConradMay 3, 2017 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.– supercatJun 25, 2018 at 23:30
Add a comment
|
3 Answers
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.
-
2The 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...– JoeMay 3, 2017 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
AECsignal, google for "badline". Also see e.g. here. BTW, the Apple II does the same thing, without cycle stealing.– dirktMay 3, 2017 at 5:55 -
4You 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.– wizofworMay 3, 2017 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.– supercatMay 13, 2017 at 17:13
-
3Same here as per @MarkReed; Commodore: A Company on the Edge even recounts that the C128 design team took to mockingly stopping conversations they were in the middle of with the 8563 designer in order to pick up nearby silent phones and put them straight down again, owing to his claim that you didn’t need interrupts because you could just poll for current state.– TommyDec 2, 2021 at 13:12
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:
- 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.
- I/O chips are mostly pinned to 1 MHz.
- 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).
