phaseflip in tv_drv_010?
mpark
Posts: 1,305
Several Hydra source files contain this comment:
' colors are in reverse order from parallax drivers, or in order 0-360 phase lag from 0 = Blue, on NTSC color wheel
' so code $0 = 0 degrees, $F = 360 degrees, more intuitive mapping, and is 1:1 with actual hardware
I didn't know what it meant... until tonight, when I discovered that tv_drv_010 XORs the palette with $f0f0f0f0 (in NTSC mode), thus reversing the phase (and causing me to lose a couple of hours figuring out why my graphics driver was producing the "wrong" colors).
Anyone know why tv_drv_010 does what it does?
' colors are in reverse order from parallax drivers, or in order 0-360 phase lag from 0 = Blue, on NTSC color wheel
' so code $0 = 0 degrees, $F = 360 degrees, more intuitive mapping, and is 1:1 with actual hardware
I didn't know what it meant... until tonight, when I discovered that tv_drv_010 XORs the palette with $f0f0f0f0 (in NTSC mode), thus reversing the phase (and causing me to lose a couple of hours figuring out why my graphics driver was producing the "wrong" colors).
Anyone know why tv_drv_010 does what it does?
Comments
Here are my current thoughts on phaseflip, based on a cursory reading of tv_drv:
In PAL mode, the phase has to alternate every line (that's what PAL means), so having phaseflip alternate between $f0f0f0f0 and $00000000 every scanline·and XORing palettes with phaseflip makes sense.
In NTSC mode, phaseflip doesn't change every scanline, but in interlaced mode it appears that it does change between fields (so even fields have phaseflip = $f0f0f0f0 and odd fields have phaseflip = 0 or vice versa), so maybe because of the half-scanline you need to flip phases (on a per-field basis). One of these days I'll experiment with that.
I'm kind of convincing myself that phaseflip is reasonable, but I have to wonder why they didn't invert the phase of phaseflip --·that is, make it $00000000 where it's $f0f0f0f0 now (and vice versa). If they had, then the colors produced by the Parallax driver would match·my (and presumably Dennis's)·barebones non-interlaced NTSC driver, and would have resulted in, as Andre states,
Andre'
For non-interlaced NTSC (262 lines), the color burst phase is rising on even lines (where sync is lines 4,5,6) and falling on odd lines.
For interlaced NTSC, the color burst phase is rising on even lines & falling on odd lines for the two fields, then falling on even lines & rising on odd lines for the next two fields.
However, most NTSC TVs will accept any phase burst. Active color is always WRT burst. (I think the four field sequence is only necessary for VBI data like CC where which field the data is on is important.)
PAL switches the V phase every line. On even lines burst is 135 degrees (where U is 0 and V is 90), and on even lines it is 225 degrees. On the Prop (using native color generation) if burst is color 0 then blue will be color 9 on even lines and color 7 on odd lines. (i.e. even color = burst + offset, odd color = burst - offset) There's a similar field pattern for burst phase, but it's relative to U and my head hurts thinking about it. But as long as the color phase relative to the burst phase is correct then you should be okay. Non-interlaced PAL must be an even number of lines (typically 312) or you lose color. (NTSC isn't restricted, but it doesn't change the number of lines displayed.)