Hardware Basics Part 1 - Tick Tock, know your Clock
- Hardware Basics Part Part 1 - Tick Tock, know your Clock!
- Hardware Basics Part Part 2 - A complicated relationship
I see clocks everywhere - what is all this?
Have you ever wondered why NTSC and PAL Commodore C64 have a different total number of available screen lines or why the NTSC model has a faster system clock rate? Do you know what a clock rate actually is? If not, then the next two articles are a great opportunity for you to shine in the next discussion on the architecture of 8-Bit computers.
Y1 - the heartbeat of the Commodore C64
It all starts with Y1. Y1 is a crystal oscillator that uses the mechanical resonance of a vibrating crystal to create a signal with very precise frequency. Our Y1 Crystal in the Commodore C64 delivers a frequency signal of 14.31818MHz (NTSC) respectively of 17,734475MHz (PAL). This signal is also called the Color Clock.
Why Color Clock? Why did Commodore use crystals which generate exactly either of those two frequencies? When you divide 14.31818 by 4 you get 3.579545 and when you divide 17.734475 by 4 it results in 4.433618. Do those numbers eventually ring a bell already?
3.58Mhz is the color subcarrier frequency for the NTSC system while 4.43MHz corresponds to the color subcarrier frequency for PAL. Those frequencies are responsible how colors are displayed on our each TV systems. So that's the Color Clock.
An integrated C64 circuit called a Dual Voltage Controlled Oscillator further generate a 7.88MHz (PAL) respectively 8.18MHz (NTSC) Dot Clock from this signal. Of course you wonder what a Dot Clock is.
A Dot Clock defines how many pixels can be drawn on the screen per each refresh. It is just simple math of the numbers of raster lines multiplied by the system refresh rate multiplied by the number of available pixels per each row. The properties of the C64 screen and the respective color standards lead to the required Dot Clock Rate which the Oscillator will generate for us.
PAL: 50.125Hz (refresh rate) * 504 Pixels * 312 Lines = 7.88MHz
NTSC: 59.826Hz (refresh rate) * 520 Pixels * 263 Lines = 8.18MHz
This difference between PAL and NTSC systems leads to the problem that certain routines written for a PAL C64 may run 20% faster on a NTSC system while NTSC routines seem to be 16% slower on PAL. That is especially notable when comparing many SID musics composed on one machine but played back on the other, e.g. in games or intros. Interesting enough, while you would assume that this is a problem of the past, I want to remind you that many videogame console titles from Japan or the US where often not satisfactory adapted for the PAL market. Many PAL games, e.g. on Nintendo 64 ran 16% slower than the NTSC version of the same game on a US or Japanese Console - the reason is sloppy work on adapting to the PAL standard.
Back to the C64. Luckily many demos and a few games make sure they detect the underlying system correctly and change routines and timing in the code respectively. The common approach for commercial games was to create two versions of a product for NTSC and PAL markets though. This explains why there were so many PAL-Fixes for games across systems in the old days. PAL system owners wanted to play the latest US-Games when they were released and not wait for adapted versions released 6+ months later. Nowadays it is not a problem anymore as HDMI and 60HZ are standard for TVs and supported by all current generation consoles.
So we have come from the Color Clock to the Dot Clock and the final destination would be the System Clock which defines a CPU Cycle. The C64 is an 8-Bit Machine. This limits it to display 8 Pixels per each CPU cycle. One CPU-cycle corresponds therefor to 1/8 of the Dot Clock. Let's confirm this.
PAL: 7.88MHz / 8 = 0.985Mhz
NTSC: 8.18MHz / 8 = 1.023MHz
This seems to be right with what we read about the system clock rates on Commodore C64 NTSC and PAL machines.
Congratulations! You are now able explain why the C64 has a certain system clock rate and that one period of this rate corresponds to a CPU Cycle which is the time required to put 8 pixels to the screen. Let's do one more calculation to complete the picture!
How many CPU cycles do we need to generate one line of Pixels and how many CPU cycles are therefor theoretically required per each screen refresh? We know that 8 Pixels can be drawn per Cycle and we know the number of pixels per line - so this is all easy now.
PAL: 504 Pixels / 8 = 63 Cycles per Line * 312 Lines = 19656 total CPU Cycles
NTSC: 520 Pixels / 8 = 65 Cycles per Line * 263 Lines = 17095 total CPU Cycles
Those are also numbers you might have encountered already somewhere - even on this site.
Why is all this important in the first place?
It is first of all a good prelude to the next part which will further dissect the system clock rate and its origin in a delicate relationship between the VIC-II and the CPU 6510. We will soon learn that 63 available cycles per to be generated raster line on PAL respectively 65 cycles on NTSC machines turn out to be insufficient for certain VIC-II tasks which results in side effects you should be aware of - side effects that will usually be notable in demos and games.
-act