A lot of programs released for the Commodore 64 contained different software for the PAL or NTSC computer. Why did they have different versions of the hardware? Did the software have to be different too?
Add a comment
|
3 Answers
Hardware-wise, the Commodore 64, like most early computers, was synchronized to its graphics output: in the case of the C64, the CPU clock was derived from the timing crystal in the video hardware.
From a game-programming standpoint, the most important timing element is the vertical refresh rate: the 50 Hz (PAL) or 60 Hz (NTSC) rate at which the screen started drawing each frame. A game coded for one frame rate would appear too fast or too slow on the other. Given the limited CPU capabilities of the hardware (you've only got 19,700 or 17,050 CPU cycles per frame), a re-write of the software was often the only way to adapt while still being able to run fast enough.
The C64 additionally had the ability to change the settings of the VIC-II graphics chip from code. Normally this would be done during the vertical-blanking interval, when no signal was being output to the screen, but making the changes during the drawing interval permitted graphical effects (eg. number of colors) beyond the stated specs of the chip -- but this required cycle-perfect timing of the changes, and this timing was different for PAL and NTSC.
-
4My first NTSC C64's VIC-II chip seemed to output 64 cycles per scan line, but when I replaced it (some sprites were a little wonky) the replacement output 65. Was that a design change, or was my VIC-II chip output timing wonky as well as its sprites?– supercatCommented May 10, 2016 at 15:00
-
1@supercat there are old and new versions of the NTSC VIC-II. The old version did 64 cycles per scanline and the new one did 65. The PAL and probably the SECAM version always did 65 as far as I can recall. Commented Aug 4, 2017 at 15:12
-
@Wilson: The emulator I've played with had choices for 65/262 or 65/263, but none for 64/262 which is what my C64 was. On units with 64/262, was the horizontal sync 1.56% fast, or were some cycles longer than others (on the Apple II, for example, each line has 64 cycles that are s 3.5 chroma clocks (977.8ns), and one that's four chroma clocks (1,117.4ns) long? It was visually obvious that each scan line had an integer number if chroma clocks, but I don't know if that was 224, 228, or something else. New ones match the NTSC standard 227.5.– supercatCommented Aug 4, 2017 at 15:17
-
@supercat no idea then. Probably worth asking a question though. Commented Aug 4, 2017 at 16:25
-
If I recall correctly there was a Basic variable holding the current time. On PAL machines that one drifted because the ticks per second was wrong. Commented Oct 2, 2019 at 13:54
The timing of some programs - most notably games - is different due to the different frame rates of NTSC (60 Hz) and PAL (50 Hz). It may also affect the timing of the SID tunes if the SID registers are written during and synchronized to the vertical blanking of the frame.
In addition to what has been mentioned in the other answers, the correspondence between pitch registers and actual sound frequency is not the same for both models.
So when writing a sound engine, a different frequency lookup table has to be used for NTSC and PAL C64s. Failure to do so will result in music being transposed among models.
This also means the extreme lowest and highest pitches available are not the same, so some extreme musical pitches might be available on only one model but not the other.
-
1So that's why the music in Spy Hunter is inaudible on a PAL 64!– Alan BCommented Apr 26, 2019 at 11:42