Further observations on PAL(60) and NTSC
Wuerfel_21
Posts: 5,053
This is a sortof-followup to another post of mine
forum, as far as i can tell, lacks a way to make text bigger, so you'll just get bold all-caps instead
WHAT WE KNOW
MY SETUP
OBSERVATIONS
HAVE YOU (yes, you, the reader) FOUND FURTHER ODDITIES? EXPLANATIONS? CAN YOU CONFIRM MY OBSERVATIONS?
forum, as far as i can tell, lacks a way to make text bigger, so you'll just get bold all-caps instead
WHAT WE KNOW
- NTSC colors can vary (thus the tint control: PAL only TVs lack it. Even my multistandard TV only displays it's on-screen tint control in the menu when it detects an NTSC signal)
- NTSC and PAL prop colors differ
- Generating the PAL color carrier on an 80Mhz Prop is less than perfect due to PLL jitter. This appears to materialize as a faint shimmer in solid colors.
- The Prop's simple color generator is far from perfect: Square wave color carrier, no luma trap
- PAL60 is cool stuff
- NTSC and PAL prop colors differ
- Generating the PAL color carrier on an 80Mhz Prop is less than perfect due to PLL jitter. This appears to materialize as a faint shimmer in solid colors.
- The Prop's simple color generator is far from perfect: Square wave color carrier, no luma trap
- PAL60 is cool stuff
MY SETUP
- DIP Propeller @80Mhz (from 5Mhz crystal)
- Phillips "28PT7156/12R" multistandard consumer-grade CRT TV
- ICS CTV-2116 PAL-only "portable" TV/Monitor (in desperate need of maintenence: geometry varies wildly with screen brightness (bad capacitors?), noticable chroma delay, almost never turns on with all the RGB channels present (can be temporarily fixed by desperate slapping) (loose connection to neck board? Failing heaters?).)
- Custom soon-to-be-released TV driver (NTSC timing is identical to the Ranquest driver, PAL timing is the PAL60 mode I talked about already)
- Phillips "28PT7156/12R" multistandard consumer-grade CRT TV
- ICS CTV-2116 PAL-only "portable" TV/Monitor (in desperate need of maintenence: geometry varies wildly with screen brightness (bad capacitors?), noticable chroma delay, almost never turns on with all the RGB channels present (can be temporarily fixed by desperate slapping) (loose connection to neck board? Failing heaters?).)
- Custom soon-to-be-released TV driver (NTSC timing is identical to the Ranquest driver, PAL timing is the PAL60 mode I talked about already)
OBSERVATIONS
- Two color differences between PAL and NTSC: hue offset and different color space
- NTSC mode's hues can be brought closer to PAL mode (At least on my Phillips TV, with the (on-screen) tint control in the center) by slightly changing the phase of the colorburst -the color carrier reference sent to the TV. Ideally, one'd change PAL's burst phase (due to most existing software being written with the NTSC colors in mind), but that resulted in both TVs being unable to decode the color. In TV.spin-derived drivers, this can be achieved my changing this line:
- NTSC's color space (YIQ) apparently is less uniform: on my Phillps TV, red-ish hues in a rainbow pattern (increasing hue every scanline) appear more saturated than in PAL, green-ish ones less saturated (most noticable on $*A colors). PAL mode appears uniform on both TVs (red,green,blue stripes of uniform brightness). On the Phillips TV, I can actually observe it switching color spaces, as it happens about a second after I switch between PAL and NTSC.
- Tinting the screen by changing the hues of some pixels has interesting results: Vertical stripes are less flickery than checkerboards and it overall works better with PAL60 than with NTSC, despite there being more color cycles per pixel (in my case, 10/16 vs. 12/16). This effect will be included in my upcoming driver's demo program. Stay tuned for that!
- checkerboard patterns in general are less flickery and artifacted in PAL60
- The Propeller's 4bit color phase-accumulator persists between resets and even short power cycles (Thus, different artifacts)!
- When splitting the signal to both TVs, the image becomes darker! (altough this is less apparent on the small TV, as it appears to apply some kind of highpass filter that makes black screens very gray (screens with black/white contrast show true black)) I always thought TVs perfrom automagic gain control based on the difference between sync and blanking levels...
- NTSC mode's hues can be brought closer to PAL mode (At least on my Phillips TV, with the (on-screen) tint control in the center) by slightly changing the phase of the colorburst -the color carrier reference sent to the TV. Ideally, one'd change PAL's burst phase (due to most existing software being written with the NTSC colors in mind), but that resulted in both TVs being unable to decode the color. In TV.spin-derived drivers, this can be achieved my changing this line:
word $02_8A, $02_AA 'burstto this:
word $02_7A, $02_AA 'burstthis is actually fairly odd, as the ideal phase difference between NTSC and PAL is 33° = 1.467 propeller-hue-steps
- NTSC's color space (YIQ) apparently is less uniform: on my Phillps TV, red-ish hues in a rainbow pattern (increasing hue every scanline) appear more saturated than in PAL, green-ish ones less saturated (most noticable on $*A colors). PAL mode appears uniform on both TVs (red,green,blue stripes of uniform brightness). On the Phillips TV, I can actually observe it switching color spaces, as it happens about a second after I switch between PAL and NTSC.
- Tinting the screen by changing the hues of some pixels has interesting results: Vertical stripes are less flickery than checkerboards and it overall works better with PAL60 than with NTSC, despite there being more color cycles per pixel (in my case, 10/16 vs. 12/16). This effect will be included in my upcoming driver's demo program. Stay tuned for that!
- checkerboard patterns in general are less flickery and artifacted in PAL60
- The Propeller's 4bit color phase-accumulator persists between resets and even short power cycles (Thus, different artifacts)!
- When splitting the signal to both TVs, the image becomes darker! (altough this is less apparent on the small TV, as it appears to apply some kind of highpass filter that makes black screens very gray (screens with black/white contrast show true black)) I always thought TVs perfrom automagic gain control based on the difference between sync and blanking levels...
HAVE YOU (yes, you, the reader) FOUND FURTHER ODDITIES? EXPLANATIONS? CAN YOU CONFIRM MY OBSERVATIONS?
Comments
Now look at this decoding function: This turns YUV into RGB. Every TV needs to do this calculation internally.
However, for NTSC, someone at some point juggled some coefficients around: This is not a construction flaw in my TV: It deliberatly switches between these two matrices.
This is the test pattern that i originally noticed the difference on, digitally recreated, to illustrate the "issue".
I wouldn't even really call it an issue, since IMO it makes NTSC graphics look less flat.