For supporting the C74 project, I felt a need to post something about how clock generation in the C64 works.

;---

First, a picture of the clock generation circuitry taken from a C64 schematic (1982 ?).



Before 1984, a PLL like in the picture was used for generating the dot_clock.
(Looks like this circuitry was replaced by a 8701 clock generator chip in 1984.)
A block diagram of the PLL clock generator:



How it works:
U31 (74LS629) contains two VCOs (voltage controlled oscillators).
One VCO of U31 works as a crystal oscillator, generating the color_clock.
U30 (74LS193) works as an up_counter and divides down the color_clock by 9 (PAL) or 7 (NTSC).
A D_flipflop from U29 (74LS74) divides the U30 output by 2 for getting a neat symmetrical square wave.
The result is the _reference_ for PHI0.

The other VCO from U31 (74LS629) generates the dot_clock, which is divided down by 8 in the VIC-II for generating PHI0.

U32 (MC4044, now out of production) compares the PHI0 _reference_ (generated from the color_clock)
with PHI0 (generated by that VCO and the VIC-II), and is supposed to change the input voltage of that VCO
until PHI0 and the PHI0 _reference_ match.

BTW: the other D_flipflop in U29 (74LS74) is abused to work as an inverter for generating the constant of that U30 (74LS193) divider.
74LS\HC\HCT\AC\ACT74 datasheets don't explicitly state whether the /PRE or the /CLR input of the flipflop has higher priority,
better don't try such tricks at home, kids.

;--

Some background info about what a chrominance subcarrier is and why it has this odd frequency can be found on Wikipedia.
For the C64, I think the calculations look like this:

PAL:
chrominance_subcarrier = 4.43361875MHz
color_clock = chrominance_subcarrier *4
dot_clock = color_clock *2 /4.5
phi0 = dot_clock /8

NTSC:
chrominance_subcarrier = 3.57954545MHz
color_clock = chrominance_subcarrier *4
dot_clock = color_clock *2 /3.5
phi0 = dot_clock /8

Would like to mention, that the crystal might have a 50ppm tolerance or such.
I guess that quite some hobbyists wanted to measure the frequencies in a C64 by using a frequency counter,
and if the last digits of the frequencies are a bit different in the one or other text found in the internet,
please just ignore it and blame those tolerances...

;---

Some more info on the 8701:
ftp://www.zimmers.net/pub/cbm/documents/chipdata/8701.txt
ftp://www.zimmers.net/pub/cbm/documents/chipdata/8701.zip
http://visual6502.org/images/pages/MOS_8701.html

Different revsions of the C64 PCB, looks like the 8701 showed up in 1984, third version, ASSY 250425.
There is a replacement for the 8701 which seems to be based on a 74HC7046 PLL chip.

Edit: 8701R2 dissection is here.

;---

Another interesting PLL chip in the 5..133MHz range might be the CY2302.
Works at 3.3V and 5V.

When trying to generate odd frequencies from a standard crystal (let's say 12MHz), the ICS525-02 might be a good choice.
Works at 3.3V and 5V, Fin = 2..50MHz (5..27MHz crystal), Fout=5..250MHz (at 5V).

There are other chips that might (or might be not) useful, like the SI5351.
But reading the description of how to set those registers in the Si5351 might hurt your brain...
and it's hard to tell something about the phase relation between the chip outputs without throughly testing that chip.

The original prototype had independent clocks for colour and dot/system, but that led to shimmering patterns on the screen. The PLL circuit was thrown in at the last minute before production, to keep the phase relationship between them constant.

The story goes that one of the chips (the 74LS629 I believe) was only manufactured by TI, and TI's home computer was one of the C64's competitors. Tramiel was not happy about this, and demanded that something be done. Since Commodore had a pet silicon foundry, they could just drop the whole function into a custom chip. That's where the 8701 came from.

If you look closely, one half of the 74LS74 is being used in a very strange way. 1CLK and /1CLR are both grounded, so the output on 1Q should always be 0. But it happens that /1PRE overrides /1CLR. If /1PRE is low, then 1Q goes high. If /1PRE is high, then /1CLR takes over and 1Q goes low. It's being used as an inverter. Yes, I did spend hours poring over that schematic when I was a teenager.

This circuit goes inside the shield containing VIC, and they already had half of a 74LS74 in there for dividing the clock. Abusing the other half like this saves adding another chip.

Silicon Labs provide configuration software to generate the register settings, so you don't have to do it yourself. Generating weird clocks is so much easier than it was in 1982!

Same thing here.


Looks like one would have to register for downloading the software, what suddenly had lowered my interest in that chip pretty much.

I still wonder why some companies seem to be doing this...
...and how many hobbyists had signed up over the years as "Mr. Foo Bar from China" by using proxy and a throwaway email address.

...But back on topic.

When implementing something like a C64 in a FPGA, the game changes a bit.

First, when generating a VGA video signal by using a scan doubler instead of just a PAL\NTSC video signal,
there would be no color clock.

Second: the implication of having different clocks (different clock domains that is) in your logic design
inside the FPGA could give you some grey hairs.

Even when having a design with two clock signals, where one clock is generated from the other clock
by just using a multiplexer, there might be timing issues due to the propagation delays.

;---

So for instance in FPGA64 everything just seems to run from a global 32MHz clock,
and there are synchronous enable signals for the individual parts of the design, like for enabling just one Bit shift in the VIC-II
video shift registers, or for the innards of the VIC-II that read a Byte from the data bus once during PHI0=0 and PHI0=1.

(When running a shift register at 32MHz, but enabling the shift operation only for once within 4 clock cycles,
the result would be a shift register effectively operating at 32MHz/4 = 8MHz.)

Of course, the game is a little bit more complicated.

In a PAL C64, the CPU runs at 0.985248MHz.
In FPGA64, the CPU effectively seems to run at 32MHZ/33 = 0.969697MHz, that's 1.578% slower than in a PAL C64.

For instance 64MHz/65 = 0.984615MHz would be only 0.064% slower than in a PAL C64...
but I think the increased clock frequency would make "less efficient use" of the resources in the FPGA.

;---

Making up oscillator frequencies and divider factors for NTSC seems to be less fun.
Also, when choosing one main oscillator frequency and dividing it down by different factors for PAL and NTSC,
it seems that depending on the main oscillator frequency there is a chance of getting PHI0 close to the frequency
for a PAL C64... or the frequency for a NTSC C64... but not both.

Because of those odd PHI0 frequencies and the use of the SEI instruction in some of the software,
in the long run TI$ never would show you an exact time on a C64 anyway.

RS232 emulation maybe isn't too critical...

But it's an interesting question, how much PHI0 could be off from the frequency it is supposed to have in a C64
until a fast loader for the 1541 floppy drive would be getting "the hickups".

;---

Side note:

If one would be out to build something like a TTL implementation of the 6526, and to run the CPU and the 6526 at more than ca. 1MHz,
it would make sense to have a synchronous "count enable" input at the 6526 which enables counters etc. for one PHI2 clock cycle.

With a little bit of additional logic tied to the clock generation circuitry (inspired by FPGA64),
one then could make run them timers at the same speed like in the original C64 to stay software compatible,
while running the 6526 bus interface at the full PHI2 speed.

Edit: same thing for the SID, of course.