...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.