Re: Color Reference of NTSC Formula?

[Mark McDougall <markm@vl.com.au>]

Bryan Parkoff wrote:

>     OK.  You used RGB to YIQ formula.  The problem is that you already know 
> Apple IIgs' 16 RGB colors so you put them into RGB to YIQ formula to get 
> degree of color circle.  It is not a problem.  I do not intend to get RGB 
> value for color because I don't want to use Apple IIgs' RGB 16 colors so I 
> use NTSC color.  I decide to follow the bit stream of 14MHz while 3.58MHz 
> color reference is activated.  It is up the color reference to decide and 
> choose which color is to be used by the following bit stream of 14MHz.
>     With the color information from bit stream of 14MHz, the degree of color 
> should be obtained from it through 3.58MHz color reference.  Then, we say 
> that YIQ is per four sub-pixels of whole pixel.  We may want to simulate 
> NTSC screen on RGB monitor.  We need to use YIQ to RGB formula so it will 
> show RGB pixels.  It is what we use NTSC color which it will never be 
> identical to Apple IIgs' 16 RGB color.

Ahhhhhhhhhhhhhhhhh - I think I *finally* understand what you're trying
to do!?!? I've had it backwards all along...

Right, so you want to 'emulate' NTSC output on RGB, using the *exact*
same colours as you'd see on the NTSC monitor, including the
artifacting... right....

Now, 14MHz will allow you generate 4 distinct chrominance values, at
phases 0, 90, 180 and 270 degrees. Presumably you can also generate 4
different levels of luminance, which gives you 4*4=16 different colours.

So I guess the key is to knowing, from the 4 bits that define each
colour, which bits control the phase and which bits control the
luminance, and how. This is something that will be unique to the Apple
2, and not something a generic formula can give you.

Once you know that, you can at least choose the 16 'pure' values
directly from the colour wheel, given your 16 pairs of phase,luminance
values calculated theoretically.

Now the hard part, artifacts. The originating input is generated by
square waves, and low-pass filtered to be shaped more like sine waves.
But they're not perfect, and the phase comparator in the NTSC monitor is
going to 'see' the phase difference drift slightly across each pixel.
The problem is more pronounced when you need to switch the phase 180
from once pixel to the next (opposite sides of the colour wheel). This
is why you get purple/violet fringing on the white for example - it
takes a while for the "true" phase to be seen by the comparator.

To calculate these artifacts I think you'd have to model the filtering
of the square wave and the bandwidth limitation on the phase comparator.
Trouble is, the 'fringing' is an analogue effect and to show this on an
RGB monitor would require several pixels for each Apple 2 pixel. I guess
it's fortunate that we have 1900x1600 monitors these days! ;)

Am I on the right track now?

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266