C64 async color encoding

Other Computers and Game Systems

Moderator: Moderators

User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

C64 async color encoding

Post by eslapion »

I noticed long ago the color encoding on the C64 was generated by the same clock source as the dot clock and this has a detrimental impact on the image quality.

When I bought a C64DTV in 2005, I noticed it had a great quality TV signal even if it only had a composite output. I noticed then the color encoding was asynchronous relative to the dot clock. The old idea resurfaced...

Now, discussing with a friend about the 8701 clock generator, it occurred to me I could make one that uses two independent oscillators to ensure async color encoding and so I did. I love the result!

The funny thing is I now know what to do to encode the colors for PAL compatibility on an NTSC system and inversely.
Be normal.
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: C64 async color encoding

Post by groepaz »

and inversely
so you did manage to invert the colour-carrier phase every other line by changing the clock frequency?
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: C64 async color encoding

Post by eslapion »

groepaz wrote:
and inversely
so you did manage to invert the colour-carrier phase every other line by changing the clock frequency?
On the VIC-20, the dot clock and the color carrier are both generated from a single clock signal fed to the VIC-I. On the VIC-II, they are completely independent and they come from 2 different pins. For this reason, this is not something you could do on the VIC-20.

The color carrier phase being inverted or not every other line is a result of the way the 8701 generates the dot clock out of the color carrier (17.7344MHz on PAL, 14.31818MHz on NTSC). Since the 8701 generates one out of the other from the same crystal, the relation between the two is just like the gears in a car's transmission. The same cogs come back at the same place at every few turns.

However, if you use two different oscillators which each have +/-50ppm error then the color carrier phase will be slightly different by a few degrees (or ns) at every single scanline and different on every displayed jiffy. The dot clock and the color carrier become completely unrelated and this means color encoding is no longer at a fixed position on screen relative to the displayed pixels. The resolution boost is quite apparent.

I don't have a 17.7344 oscillator right now so I tested this on NTSC only. However I do have a PAL C64 and I will try to get it to work with a PAL dot clock and an NTSC color carrier.
Be normal.
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: C64 async color encoding

Post by groepaz »

but you do realize what Phase Alternating Line means?
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: C64 async color encoding

Post by eslapion »

groepaz wrote:but you do realize what Phase Alternating Line means?
Yes I do.

But one really has nothing to do with the other.

AFAIK, the PAL VIC-II takes the color clock, divides it by four and then generates 3 other clock signals shifted by 90 degrees and then uses these in different proportions to generate the colors. On odd lines, it uses these 4 signals as is and on even lines, it inverts the 1st one which is used to generate the other 3.

If you use an independent oscillator for the color clock then the color encoding becomes async relative to the dot clock but it changes nothing to the inversion or not of the color carrier from one line to the next.

On an ideal PAL system, the color encoding is shifted by a perfect 180 degrees from one scanline to the next. In reality, the oscillator responsible for the generation of the color carrier always has a bit of error relative to the video signal, extremely small and unnoticeable from one line to the next but cumulative over time and this results in no two consecutive frames having its color carrier at exactly the same phase on the overall image. This error actually contributes to improve picture resolution.

On the C64, since the crystal that generates the dot clock is the same as the one generating the color carrier then they are synchronized with one another and no error occurs. The color carrier becomes a sort of immobile grid fixed over the display ; a real TV signal isn't fixed like that at all.

I suspect you're confusing two very different things here: The phase alternating color carrier has an effect from one line to the next. The independent oscillator for the color clock has an effect which only becomes noticeable from one jiffy to the next. An error of only +/-50ppm is less than negligible over the way color is encoded from one line to the next.
Be normal.
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: C64 async color encoding

Post by groepaz »

The point is that you wont magically make an NTSC VIC output PAL just by changing the clock
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: C64 async color encoding

Post by eslapion »

groepaz wrote:The point is that you wont magically make an NTSC VIC output PAL just by changing the clock
Of course not, that's not the point.

But I can make a PAL C64 encode its color with an NTSC carrier and it works... I did it. Just have to have TV equipment that supports the wrong refresh rate, good ole CRTs do.
Be normal.
User avatar
MCes
Vic 20 Afficionado
Posts: 457
Joined: Fri Jul 24, 2015 1:19 am
Location: Italy

Re: C64 async color encoding

Post by MCes »

It could be interesting..... (pg51, for example)

http://spectrum.ieee.org/ns/pdfs/commod ... ar1985.pdf
"Two things are infinite, the universe and human stupidity, and I am not yet completely sure about the universe." (Albert Einstein)
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: C64 async color encoding

Post by eslapion »

MCes wrote:It could be interesting..... (pg51, for example)

http://spectrum.ieee.org/ns/pdfs/commod ... ar1985.pdf
Ya, on a composite signal, this would restore the "swimming" effect.
Be normal.
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: C64 async color encoding

Post by groepaz »

Of course not, that's not the point.

But I can make a PAL C64 encode its color with an NTSC carrier and it works... I did it. Just have to have TV equipment that supports the wrong refresh rate, good ole CRTs do.
but you said "and inversely" - which i doubt will work without the colors being all messed up due to the missing PAL
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: C64 async color encoding

Post by Mike »

PAL does not invert the phase of the colour carrier on every second line, it inverts the phase of the red difference signal. That means the colour wheel - red, orange, yellow, green, cyan, blue, purple - is encoded by going clock-wise and then anti-clock-wise on alternate lines. A phase error, which normally would lead to a different colour, is then converted to a much smaller error in the colour saturation.

In no way are you going to emulate this by merely changing the colour carrier frequency. The PAL VIC-II has extra circuitry built in to produce a correct PAL signal.

If anything, a fairly modern display might accept a "NTSC" or "PAL" signal with a wrong colour frequency and/or "wrong" handling of the red difference signal, by checking the colour burst. Most older displays will just produce a B/W output - if they don't choke on the wrong vertical frequency, that is.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: C64 async color encoding

Post by eslapion »

Mike wrote:PAL does not invert the phase of the colour carrier on every second line, it inverts the phase of the red difference signal. That means the colour wheel - red, orange, yellow, green, cyan, blue, purple - is encoded by going clock-wise and then anti-clock-wise on alternate lines. A phase error, which normally would lead to a different colour, is then converted to a much smaller error in the colour saturation.

In no way are you going to emulate this by merely changing the colour carrier frequency. The PAL VIC-II has extra circuitry built in to produce a correct PAL signal.

If anything, a fairly modern display might accept a "NTSC" or "PAL" signal with a wrong colour frequency and/or "wrong" handling of the red difference signal, by checking the colour burst. Most older displays will just produce a B/W output - if they don't choke on the wrong vertical frequency, that is.
My 1084 (the old Amiga 1000 model) took in 50 or 60 Hz vertical beautifully.

I was surprised to see anything at all with a weird setup like that. But now thinking about it, I guess the worst that could have happened is a B/W picture.
Be normal.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: C64 async color encoding

Post by eslapion »

groepaz wrote:
Of course not, that's not the point.

But I can make a PAL C64 encode its color with an NTSC carrier and it works... I did it. Just have to have TV equipment that supports the wrong refresh rate, good ole CRTs do.
but you said "and inversely" - which i doubt will work without the colors being all messed up due to the missing PAL
I haven't tested an NTSC C64 using a 17.7344MHz color carrier but I am curious to see the result when I have the necessary parts.

I guess we'll see if it works...
Be normal.
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: C64 async color encoding

Post by groepaz »

PAL does not invert the phase of the colour carrier on every second line
yes. damn. i should have remembered - its the UV vector of course :)
I guess we'll see if it works...
my guess would be that you get either crazy LSD colors, or a b/w picture. more likely the later.
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: C64 async color encoding

Post by eslapion »

groepaz wrote:my guess would be that you get either crazy LSD colors, or ...
Now that would be great!!
groepaz wrote:
PAL does not invert the phase of the colour carrier on every second line
yes. damn. i should have remembered - its the UV vector of course :)
My PAL compatible scope and RCA flat panel TV (which is both PAL and NTSC compatible) says Mike is right...
Be normal.
Post Reply