Re: Difference in luma-chroma delay of C64/C128 compared to standard S-video

From: Marko Mäkelä <>
Date: Mon, 4 Sep 2017 20:03:53 +0300
Message-ID: <20170904170353.idmwuwr5can3i4nj@hp>
On Sun, Sep 03, 2017 at 12:18:38AM +0200, Mia Magnusson wrote:
>Den Sun, 3 Sep 2017 00:10:38 +0200 skrev Gerrit Heitsch
>> On 09/02/2017 11:58 PM, Mia Magnusson wrote:
>> >
>> > But isn't this even how the clock in a C64 is already? We know that
>> > the h-sync frequency is wrong to avoid some PAL dot crawl. (Dot
>> > crawl is kind of a feature of PAL...).
>> I thought dot crawl happens if pixel clock and color clock are not in
>> sync? Like on a ZX Spectrum. With the discrete PLL in the C64 (and
>> later the 8701), dot clock and color clock are in sync and that
>> prevents dot crawl.
>Yes, but AFAIK a correct PAL clock cannot be evenly divided to get a
>correct PAL h-sync. (you need fractions in the divisor). Thus dot crawl
>in a correct PAL signal.
>15625 * 284 = 4437500 = too high
>15625 * 284 = 4421875 = too low

As far as I understand, the UltiMax attempted to get this right, by 
having a separate 8 MHz dot clock crystal in addition to the 14.318181 
MHz NTSC clock. The Wikipedia article implies that dot crawl can occur 
on NTSC as well. If I remember correctly, this issue (for the UltiMax) 
was mentioned on this list several years ago.

I wonder if the decision to derive the dot clock from the chroma clock 
(14318181 Hz/14 or 17734472 Hz/18) was made in the name of reducing 
costs, or in the name of making the video output look nicer.

Maybe the UltiMax was developed mostly independently of the Vic-20, and 
later on this single-crystal trick was copied from the Vic-20 design to 
the Commodore 64?

Did anyone try to run a C64 with an independently clocked dot clock?  
How did it look like?


       Message was sent through the cbm-hackers mailing list
Received on 2017-09-04 18:00:03

Archive generated by hypermail 2.2.0.