4

The Atari 800, in 1979, ran the 6502 at 1.79 MHz. That rounds to 2, and was presumably a 6502A rated for 2 MHz, underclocked.

Why did Commodore keep running their 6502 computers at 1 MHz, even the 64 in 1982?

It wasn't because they didn't care about CPU speed. They made quite some sacrifices to improve it. The 64 has a 40-byte on-chip character cell cache to keep the CPU running during 7/8 of active scan lines. The Vic-20, lacking such a cache, cuts the horizontal text resolution to 22 columns rather than halt the CPU during active scan line.

Granted the Atari did have to halt the CPU during active scan line, because the video circuitry did not leave 2 MHz of bandwidth unused. But Commodore could have run the CPU at 2 MHz in horizontal and vertical blank, and 1 MHz in active scan line. Or just accepted the halt; active scan line was only about 50% of the total time, so the overall performance would be about the same.

I can imagine for the PET 2001, they were in too much of a hurry to get it working at all, and then the rest of the PET line, they didn't want to change any of the timings, to avoid breaking compatibility with peripherals, or with tapes recorded on a previous model. But the Vic and 64 were incompatible anyway. Why not take the opportunity to bump the clock speed?

12
  • 1
    Why does Honda continue to build the Civic while they are able to for F1 engines? Serious, I like to go with some of your speculations, but this is so deep into comparing apples and oranges (Atari is a complete different design) and unfounded by any indication that it doesn't make any sense - not in a CS class about basic system design and even less here.
    – Raffzahn
    Commented Jun 19 at 11:51
  • 3
    @Raffzahn Come on, I know you know better than to post nonsensical comments like that. Atari is a pretty similar design, with a handful of quantifiable differences, of which this is one.
    – rwallace
    Commented Jun 19 at 12:03
  • 1
    @Raffzahn Strictly speaking, 'DMA driven memory system, with the CPU being one of many masters' applies to every computer display except the ZX80/81; the video chip takes over the bus as needed during active scan line, and directly accesses memory. (Well, and e.g. the TRS-80, where video didn't exactly get to 'take over', but I digress.) Is there a difference between the way the VIC-II in badline, and ANTIC, do DMA?
    – rwallace
    Commented Jun 19 at 12:31
  • 2
    @scm Right, that last is the kind of thing I'm ideally hoping for; 'why did they do X instead of Y' questions, sometimes do turn out to be answerable based on finding a technical article, or a later interview with one of the participants. But I'm also interested in technical analysis of the kind you mention. For example, how much more power consumption? And based on previous answers here, it seems memory would by default have been rated for 2 MHz anyway; is that not the case?
    – rwallace
    Commented Jun 19 at 13:58
  • 2
    For one thing the VIC-II was limited to 1 MHz, which is also why the C128 has to run at 1 MHz while the VIC-II is active. Commodore did use the 2 MHz 6502 in the CBM-II systems. Acorn used it in the BBC Micro but their RAM was 4 MHz.
    – Tim Locke
    Commented Jun 19 at 16:49

1 Answer 1

7

6502 was quite cumbersome to be temporarily halted -- if you remember, in C64 VIC starts applying RDY=0 3 cycles before the actual halt is needed, since write cycles of 6502 could not be halted, only read ones and 6502 could emit 3 consecutive write cycles. This makes RDY-halting 6502 for every other cycle (as to run 2MHz CPU on a 1MHz of available memory bandwidth) impossible.

Halting the clock is another option, but then there's a minimum clock frequency requirement of 50 kHz, so halting clock for the duration of char codes/attrs fetch (that happens every 8th line) is again impossible (or nearly that).

Having both (clock halt for running 2MHz CPU on 1MHz memory cycles and RDY halt during char codes/attrs fetching) would be over-engineering with the somewhat noticeable gain of around 60%, estimated without sprite fetches.

7
  • Oh! Now this is interesting! I did not know that about the minimum clock frequency requirement. Yes, just took a look for more info on that, and this substantiates it, apparently otherwise internal registers lose data. reddit.com/r/beneater/comments/efm5pj/…
    – rwallace
    Commented Jun 19 at 14:12
  • 1
    I think the Atari 800 ANTIC starts character fetching early and has enough buffering that it can stall the CPU for twenty cycles (ten character and ten shape), let it run for one, let it stall for twenty, let it run for one, etc. Having a variable lag between the display fetches and display output could complicate things, but probably not too badly.
    – supercat
    Commented Jun 19 at 14:20
  • 1
    Thinking about it, an alternative approach would have been to have the last line of each row and first line of the next be "half-bad" lines. In the first half-bad line, each group of four memory cycles [two character-output times] would run the sequence "left shape, left character, right shape, and available to CPU; during the second, each group would be "left shape; right character; right shape [using newly fetched character]; available for CPU". The 126 cycles/line in PAL could be divvied up into 80 cycles for the text screen, eight groups of 4 active+1 idle for sprites, and 4 DMA+2 idle.
    – supercat
    Commented Jun 19 at 14:46
  • 1
    Using such an approach could have guaranteed that the CPU would be stopped for at most five cycles at a time, but each scan line would have had four unavoidable busy cycles because of DRAM refresh, even when the screen was blanked. That could have been mitigated perhaps with an address that, when written, would force an immediate 4-cycle refresh, whether needed or not, and suppress any later DRAM refresh on that line. With the screen blanked, code that performed such a store at least once every 118 cycles could count on it taking exactly eight cycles, and upon no other cycles being stolen.
    – supercat
    Commented Jun 19 at 14:59
  • 1
    @rwallace, I've made a simple estimation: subtracting 40*200 and another 43*25 cycles from a total of feasible 2*63*312 or 2*65*262 cycles for a 2 MHz 6502, and finally comparing that to (63*312-43*25) and (65*262-43*25) gives me, respectively, +63% and +57% speedup for an imaginary 2MHz case over the real 1MHz.
    – lvd
    Commented Jun 20 at 8:43

Not the answer you're looking for? Browse other questions tagged .