CIA timing incorrect and/or inaccurate

[M3wP]

I have been working with the timing on the CIAs and have found that they are not giving the expected results.

For compatibility reasons, the CIA frequencies should be 1.022730MHz for NTSC and 0.985248MHz for PAL however, these are not the determined values. In fact, after testing the exact frequency when running in NTSC timing was indeterminate.

Using my program "Majere", I was able to generate metronome pulses and record these for analysis. The results are as follows:

NTSC

BPM CIA Ticks CIA Freq

110 $2BFF 0.991112
115 $2A13 0.991168
118 $2903 0.991126
120 $2854 0.991072
132 $24AA 0.991130

PAL

BPM CIA Ticks CIA Freq

110 $2B9F 0.982721
120 $27FD 0.982721
132 $245A 0.982721

Majere.zip

The BPM values and associated ticks are accurate to approximately +/- 0.05bpm. Majere counts 48 pulses per quarter note ("beat"). The time per pulse is then 60000000 / BPM / 48 microseconds. The number of ticks required by the CIA for this period should be calculated by its frequency. For PAL, this seemed to be consistent but for NTSC, a constant factor could not be found.

It is likely that this timing issue affects other "devices" using the "1MHz" signal on the MEGA65, including the pitching of the SIDs. The NTSC timing likely requires some kind of correction however, if the timing cannot generally be changed, then the correct values should be formally published. If it is corrected, it is likely that some existing code will need to be patched.

I apologise for the code mess in Majere. I was intending on running it on VICE at some stage.

[gardners]

There is a specific PAL/NTSC 1MHz generation logic in the MEGA65, that is supposed to get these right. From memory, they are also used to generate the composite video signals. It should be fairly easy to just adjust the correction factors to get these right. I'd be surprised if this broke any existing software, as the difference is so small.

But be aware that locking the timing to the HDMI signal requirements and cycles per frame to ensure cpu cycles per frame accuracy. This might be why the values are not exact to C64 values.

Note that real C64 clocks varied by up to 3%, with values around 1% more common, so this is down in the weeds in terms of, say, IEC serial communications. as we are talking about 1 cycle slip per ~500 clock cycles for PAL, for example. The clock in the disk drive will be varying to a much greater degree.

That all said, if the number of CIA ticks per 1MHz CPU clock don't match, that's something that we should look into fixing.

[gardners]

Am I right in understanding that you saw some non-determinacy for NTSC? If so, that is very weird, based on how the clocks are generated in frame_generator.vhdl, which tries to keep the correct number of CPU cycles per video frame. It might oscillate by one cycle per frame, but nothing more.