The Amiga used a CPU rated for 8 megahertz, but clocked at 7.14 megahertz. What was the reason for this number? I remember it was something to do with a multiple of the frequency of the video circuitry, but I forget the details.
The architecture of most "color computers" of the 70s-80s was very tightly built around the NTSC color video standard.
Almost all of them had a 14.31818 MHz crystal. Note that this is four times the 3.579545 MHz frequency of the NTSC color standard, which was called a "color clock". They divided that crystal frequency to derive their actual clock frequency. For instance
- Apple II was 1.023 MHz (1/14 of crystal, 3.5 color clocks per CPU cycle) and used a 1 MHz rated CPU.
- Atari 2600 VCS was 1.19 MHz (1/12 of crystal, 3 color clocks per CPU cycle).
- Atari 400/800 was 1.79 MHz, (1/8 of crystal, 2 color clocks per CPU cycle) and used a 2 MHz rated CPU.
- Even the IBM PC used this same crystal that everyone else was using, dividing it by 3 for CPU clock (4.77MHz). (But keep in mind memory clock is 1/4 of that, so memory throughput was crystal/12, the same as the Atari 2600 - ha!) Why choose a multiple when video cards had dedicated video RAM and ran on their own clocks? Despite staggering chip-fab capability, the IBM PC team was pathological about using off-the-shelf designs and components. And this "kept the door open" to a future "color computer" design with shared video RAM; which came to fruition as the IBM PCjr.
Why didn't these color-computers just operate asynchronously and run the CPU at max spec, while the video system operated on color-clock? Because memory was at a premium in those days, so they used memory-mapped video. This was dual-ported in the simplest possible scheme**, which required memory clocks be in lock sync with the video system. The Apple II even used the video system to accomplish dynamic memory refresh.
So you see. The Amiga, the last of the machines built with the "color computer" mindset (heh, speaking of another), deliberately chose a CPU speed again divided down from that same familiar crystal, and again lockstepped to the NTSC color clock. This allowed them to leverage all the color-computer design which had come before, rather than having to reinvent the wheel.
It's difficult to imagine, in this day and age of 4k video, gigabytes of video RAM, and VPUs that can mine Bitcoin faster than the CPU... that we were so pious in our worship of the NTSC standard. No longer needing the thing, it was kind of a lousy standard.
** To digress on pre-Amiga-age dual-porting: On the Apple II, the video system got every other RAM cycle whether it needed it or not (hence running half the speed of the Atari), and in classic Wozniak style, he rearranged the memory mapping of video so the video system would also do dynamic RAM refresh). On the Atari, the far more sophisticated ANTIC system interrupted the CPU to take the memory cycles that video needed, as well as dynamic RAM refresh. This meant available CPU power varied between display modes and whether you were in vertical blank (a significant amount of time when the raster was off the visible screen). In a lot of Atari games, the CPU "rode the raster", spending its very limited CPU cycles to prepare changes to colors or sprites that would happen on the next scan line, wait for horizontal-blank, execute on cue, and prepare the next. All the computational work of playing the game happened after it got to a low-attention area like the bottom scoreboard, and the vertical blank period. All this was coded in assembler of course, with painstaking cycle-counting to make sure the operations could happen in the requisite time, given the cycles ANTIC would steal for the video mode you requested.
When color video was introduced in the USA, the horizontal scan rate was set as precisely 15750 * (1000/1001)Hz, i.e. roughly 3579545.4545Hz and the color sub-carrier frequency (also called the chroma clock) was defined as 227.5 times the horizontal scan rate. Many computers of that era use a multiple of the chroma clock as the pixel clock (the Amiga, for example, uses 4x chroma, or 14318181.818Hz).
On systems where video generation shares the a memory bus with everything else, it's generally necessary that a fixed relationship exist between the video frequency and the CPU clock. In the case of the Amiga, the system clock is 1/2 the dot clock (2x chroma), which is a bit faster than some earlier machines, though the 68000 doesn't do as much each clock cycle as some other processors.
Some other typical machines:
- Atari 2600: dot clock=chroma; CPU clock=chroma/3
- Atari 800: dot clock=chroma*2; CPU clock=chroma/2
- Apple II: dot clock=up to chroma*4; CPU clock=chroma*2/7
- Commodore VIC-20: dot clock=up to chroma*8/7; CPU clock=chroma*2/7
- Commodore 64: dot clock=up to chroma*16/7; CPU clock=chroma*2/7
The IBM PC had video memory that was separate from the main memory, and was designed to allow the video clock to be independent of the CPU clock. Nonetheless, the original PC with a CGA card used a dot clock of chroma*4, and a CPU clock of chroma*4/3.
I think you meant 7.15909 MHz.
7.15909 MHz is twice the NTSC color burst frequency (3.579545 MHz). The NTSC color burst frequency is 455/2 times the line rate, the line rate is 262.5 times the field rate, and the field rate is 60 * 1000 / 1001 (59.94 Hz).
On PAL systems that have different field rates, line rates, etc. the CPU is clocked at 7.09379 MHz.
The accepted answer is good, however there is something more that needs to be said here.
No discussion in this kind of detail on the hardware design of the Amiga should pass without some kind of mention of Jay Miner. In addition to leading design on the Amiga, he also designed the 2600, and the Atari 800/400 which (as Harper mentioned) used the same scheme. That's more than half of the designs listed in Harper's answer. This was clearly his go-to design for clocking.
Jay Miner was indisputably one of the fathers of home computing. Arguably the most important one. His contributions should not be forgotten.
It is of course well-known that the signatures of Miner, his dog, and the rest of the development team, are embossed inside the (removable) case top of most Amiga 1000's
Synchronizers, which are required for reliability and signal integrity across any asynchronous clock domain crossings, in any main data path, costs lots of dual-rank registers, which have to be tightly characterized in circuit design and layout. This costs in die area.
Async design also makes testing of the prototype emulator and chips themselves vastly more difficult. Thus making hard-to-find bugs far more likely on any product with such an aggressive design schedule.
Easiest way out was to run all the wide fast paths (CPU, memory, BLIT, NTSC video) off the same derived clock edges.