C64 async color encoding
Moderator: Moderators
- eslapion
- ultimate expander
- Posts: 5458
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
C64 async color encoding
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.
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.
Re: C64 async color encoding
so you did manage to invert the colour-carrier phase every other line by changing the clock frequency?and inversely
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
- eslapion
- ultimate expander
- Posts: 5458
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
Re: C64 async color encoding
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.groepaz wrote:so you did manage to invert the colour-carrier phase every other line by changing the clock frequency?and inversely
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.
Re: C64 async color encoding
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.
- eslapion
- ultimate expander
- Posts: 5458
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
Re: C64 async color encoding
Yes I do.groepaz wrote:but you do realize what Phase Alternating Line means?
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.
Re: C64 async color encoding
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.
- eslapion
- ultimate expander
- Posts: 5458
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
Re: C64 async color encoding
Of course not, that's not the point.groepaz wrote:The point is that you wont magically make an NTSC VIC output PAL just by changing the clock
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.
Re: C64 async color encoding
It could be interesting..... (pg51, for example)
http://spectrum.ieee.org/ns/pdfs/commod ... ar1985.pdf
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)
- eslapion
- ultimate expander
- Posts: 5458
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
Re: C64 async color encoding
Ya, on a composite signal, this would restore the "swimming" effect.MCes wrote:It could be interesting..... (pg51, for example)
http://spectrum.ieee.org/ns/pdfs/commod ... ar1985.pdf
Be normal.
Re: C64 async color encoding
but you said "and inversely" - which i doubt will work without the colors being all messed up due to the missing PALOf 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.
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
- Mike
- Herr VC
- Posts: 4841
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: C64 async color encoding
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.
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.
- eslapion
- ultimate expander
- Posts: 5458
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
Re: C64 async color encoding
My 1084 (the old Amiga 1000 model) took in 50 or 60 Hz vertical beautifully.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.
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.
- eslapion
- ultimate expander
- Posts: 5458
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
Re: C64 async color encoding
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.groepaz wrote:but you said "and inversely" - which i doubt will work without the colors being all messed up due to the missing PALOf 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.
I guess we'll see if it works...
Be normal.
Re: C64 async color encoding
yes. damn. i should have remembered - its the UV vector of coursePAL does not invert the phase of the colour carrier on every second line
my guess would be that you get either crazy LSD colors, or a b/w picture. more likely the later.I guess we'll see if it works...
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
- eslapion
- ultimate expander
- Posts: 5458
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
Re: C64 async color encoding
Now that would be great!!groepaz wrote:my guess would be that you get either crazy LSD colors, or ...
My PAL compatible scope and RCA flat panel TV (which is both PAL and NTSC compatible) says Mike is right...groepaz wrote:yes. damn. i should have remembered - its the UV vector of coursePAL does not invert the phase of the colour carrier on every second line
Be normal.