Re: Color Reference of NTSC Formula?

["Bryan Parkoff" <nospam@nospam.com>]

"Mark McDougall" <msmcdoug@no.spam.iinet> wrote in message 
news:44ce2ef7$0$1469$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
> Bryan Parkoff wrote:
>
>> It is only a question why Deep Red appears in the left of this pixel. The
>> answer might be two zero bits between one bit because of no luminance.
>
> Here's what *I* understand about colour artifacting, although I've never 
> studied the specifics on the Apple 2 in any detail. So take this with a 
> grain of salt..
>
> As you know, colour (chrominance) is encoded as a phase shift from the 
> colour burst reference modulated on top of the monochrome signal 
> (luminance).
>
> In an ideal world, this colour component might consist of a sine wave 
> whose phase can change instantaneously for each 'pixel', and by any 
> multiple of an infinitesimal amount. Naturally, circuits have bandwidth 
> limits as does the transmission spectrum so the phase changes have a 
> finite 'resolution' and the phase can't actually change instantaneously. 
> Obviously, these limitations still allow a reasonable quality picture to 
> be displayed.
>
> The Apple II (as did other computers of that era) generate what should be 
> analogue video signals using digital approximations. Indeed, the very 
> reason computers have discrete 'pixels' is a by-product of this fact, 
> whereas a TV picture raster line has no such horizontal delineation.
>
> You can, for example, crudely approximate a sine wave using a simple 
> square wave of the same frequency. If that square wave is passed through a 
> low-pass filter, the higher frequency components are filtered out and the 
> resulting output more closely resembles a sine wave.
>
> Now, you can't change the phase of a sine wave using a square wave of the 
> same frequency. But if you chose, for example, a frequency 4 times higher, 
> and approximated the sine wave using 4 consecutive 1's followed by 4 0's, 
> then the resulting square would be exactly the same, but you can now vary 
> the phase by +/- 45 degrees by inserting or removing an extra 1 or 0 into 
> the stream.
>
> It gets more complicated when you start moving away from 4 consecutive 1's 
> and 0's. For example, if you toggled 1's and 0's every two clocks (rather 
> than 4), then you'd think that you've simply doubled the frequency of the 
> colour signal. However, colour is encoded as a phase shift - it's not 
> frequency modulated - so that, and the fact that the decoder is band 
> limited - means the decoder 'sees' the 'double frequency' as a constantly 
> changing phase. You'd no doubt end up with groups of repeating pixel 
> colours.
>
> Also, the resolution of your 'clock' also limits how *quickly* you can 
> encode phase changes. If your stream changes from 0 to 1, the value is 
> held at 1 for the entire pixel, and the decoder can't 'see' how the 
> waveform is going to vary in future, so your next pixel is limited in some 
> way by the colour of the previous pixel. Depending on your clock 
> resolution, it may take 2 or more pixels to get from 1 colour to the next.
>
> I don't know the specifics of the frequencies involved on the Apple 2, but 
> I *suspect* the artifacting is a result of being able to change the phase 
> of the signal by +/- 90 degrees only? Can anyone confirm?

Hello Mark again,

    Apple II family uses the osc crystal chip that is 14,318,180 MHz.  14MHz 
is divided by 4 to show 3.58MHz for color reference.  Only load/shift 
register can transmit one bit and zero bit through the serial cable to the 
NTSC monitor at 14MHz.  NTSC monitor displays monochrome pixels because it 
sees pulse by pulse (bit by bit) stream like luminance.  With color 
reference (3.58MHz) is activated, it catches each group of four pulses to 
paint one out of 16 color pixels.

>
> Hopefully I haven't sold you a crock of sh*t here... I'm pretty sure it's 
> the gist of the mechanism if not 100% accurate.
>
> So if you want to understand how to 'emulate' artifacting I think you need 
> to understand both (1) how colour is encoded on NTSC/PAL and (2) how the 
> apple generates the video signal.

    Yes, I understand perfectly for Apple II video when I studied from the 
Understanding the Apple II manual.  The problem is that I have hard time to 
understand how YIQ, color circle, and other formula when I try to convert or 
translate NTSC pixels to RGB pixels.

Bryan Parkoff