PAL chroma merging?

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

PAL chroma merging?

Post by lidnariq »

Do any games (or modern demos) for NES explicitly (ab)use the PAL-specified scanline chroma blending? I mean the bit where PAL's chroma goes through a [0.5 0.5 0] vertical filter.

There are definitely examples of games for consoles that had a more vibrant career in PAL-land, such as Mayhem in Monsterland for the C64.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: PAL chroma merging?

Post by lidnariq »

Here's a really simple program I wrote to test for PAL chroma blending. Left/right moves between digits of colors, up/down changes value.

As I understand it, on an actual PAL TV:
1- The areas of horizontal lines (when on an NTSC NES) should be a uniform color so long as the brightness is constant (i.e. all the colors involved have the same $30s bits)
2- The thing in the middle of the screen should be of an actual circle.

Is anyone willing to verify for me?
(edit: added simulated screenshot)
Attachments
palblendpreview.png
palblendpreview.png (10.7 KiB) Viewed 18625 times
palblend.zip
(2.71 KiB) Downloaded 706 times
Last edited by lidnariq on Thu Feb 20, 2014 2:45 pm, edited 1 time in total.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: PAL chroma merging?

Post by thefox »

lidnariq wrote:Here's a really simple program I wrote to test for PAL chroma blending. Left/right moves between digits of colors, up/down changes value.

As I understand it, on an actual PAL TV:
1- The areas of horizontal lines (when on an NTSC NES) should be a uniform color so long as the brightness is constant (i.e. all the colors involved have the same $30s bits)
2- The thing in the middle of the screen should be of an actual circle.

Is anyone willing to verify for me?
1) Yup, it's all uniform.
2) Yes (not that surprising, this one?)

Good observation, and a well made test ROM.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: PAL chroma merging?

Post by lidnariq »

I figured while I was making something that was supposed to test a PAL-only feature, I might as well actually design it to look good on the PAL NES!
One question to verify my understanding: If the interleaved colors are entirely opposites (e.g. $21 and $27, say), is the resultant color grey? (i.e. U=V=0)

And the source (uses knes):
Attachments
palblendsrc.zip
(4.79 KiB) Downloaded 670 times
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: PAL chroma merging?

Post by thefox »

lidnariq wrote:I figured while I was making something that was supposed to test a PAL-only feature, I might as well actually design it to look good on the PAL NES!
One question to verify my understanding: If the interleaved colors are entirely opposites (e.g. $21 and $27, say), is the resultant color grey? (i.e. U=V=0)
Nope, that doesn't happen. $21 (on bottom) and $24 (on top) seem to combine to something close to grey (as do $22 + $25, and so on, but as the numbers increase, the grey shifts towards some color). $11 (bottom) and $15 (top) also produce a darker grey. If the colors are switched (top<=>bottom) the color changes.

EDIT: Small clarification to terminology here: by "bottom" I mean the color on the bottom of the wheel, "top" is either of the colors on the top the wheel. In the automated test, the "bottom" color would be the right one.

I have a USB capture card (which I haven't used in a while), so at some point I could throw this ROM at it (or maybe make an automated version that cycles through colors before that).
And the source (uses knes):
Happy to see somebody else besides me using it. :)
Last edited by thefox on Thu Feb 20, 2014 10:52 am, edited 2 times in total.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: PAL chroma merging?

Post by lidnariq »

Here's an automated version. Half a second per pair, only rotates between colors $20 through $2e for each half, so a full cycle will take about two minutes. This time I've thrown in a preview of what I think (hope?) it's supposed to look like. (Of course, who knows whether nestopia's palette is right: it's introduced some luma error here; or whether Gimp's YCrCb R470 is the right color space to do the chroma blending in)
Attachments
preview.png
preview.png (6.07 KiB) Viewed 18700 times
automated+src.zip
(5.65 KiB) Downloaded 675 times
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: PAL chroma merging?

Post by thefox »

Here's the video on YouTube: http://www.youtube.com/watch?v=1FyjeFvb34Y. Unsurprisingly, YouTube messed up the video by scaling it down.

Here's the original video on Dropbox (156 MB, losslessly compressed with ZMBV i.e. the DOSBox codec): https://www.dropbox.com/s/13oxoo7kmuyl6 ... 2-zmbv.avi.

If possible, you should download the original file from Dropbox, as it seems like their video player uses an internally converted version. Also note that half of the scanlines on the video are redundant because of deinterlacing done by the capture dongle. Aspect ratio is also wrong (or at least different than on my CRT).

You probably know this already, but to recap and as a note to self and others:

The obvious first thing that can be seen from the uncompressed video is that even the "normal" colors aren't uniform when displayed by this USB capture dongle. But this fact makes it very easy to see how the even and odd scanlines from the "uniform" colors on left and right are combined to form the color on the bottom (and why the order of the colors on the bottom matters).
blowup.png
blowup.png (13.06 KiB) Viewed 18658 times
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: PAL chroma merging?

Post by tepples »

that the scanline period doesn't bear the same relationship

I wonder how much of this is due to the 15602 Hz horizontal sync vs. the standard 15625. The standard PAL scanline is 283.7516 periods of the 4.43361875 MHz color subcarrier. The NES scanline is slightly longer: 284.1667 periods. For one thing, these chroma-blending filters may depend on the correct scanline period.

Another issue is that the 2A07 might not even be outputting the same color on each scanline. The part of the 2A07's color encoder that negates the phase on odd scanlines might have been implemented cheaply. That would need an oscilloscope (or a decap of the 2A07) to test properly.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: PAL chroma merging?

Post by thefox »

lidnariq wrote:I mean the bit where PAL's chroma goes through a [0.5 0.5 0] vertical filter.
Can you explain to me why you call the filter [0.5 0.5 0], isn't [0.5 0.5] equivalent?
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: PAL chroma merging?

Post by thefox »

Also, on http://wiki.nesdev.com/w/index.php/NTSC_video it says "PAL alternates the broadcast sign of the V component, so on PAL every odd scanline will use the appropriate opposite phase—e.g. phases 5-C are respectively replaced with C-5.", why not 5-B and B-5?
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: PAL chroma merging?

Post by tepples »

thefox wrote:Can you explain to me why you call the filter [0.5 0.5 0], isn't [0.5 0.5] equivalent?
I assume the phase shift is easier to see if the filter has an odd number of taps.
it says "PAL alternates the broadcast sign of the V component, so on PAL every odd scanline will use the appropriate opposite phase—e.g. phases 5-C are respectively replaced with C-5.", why not 5-B and B-5?
The PPU outputs hues in units of 30 degrees. Neither 135 nor 225, the standard phase values for PAL colorburst, is a multiple of 30. First I'll need to see on a scope what the 2C07 is actually outputting for the colorburst and for the picture proper.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: PAL chroma merging?

Post by lidnariq »

thefox wrote:Can you explain to me why you call the filter [0.5 0.5 0], isn't [0.5 0.5] equivalent?
To indicate the filter is causal. Also what tepples said: to indicate there's a net half-unit delay vertically (that I assume was precompensated for in broadcast TV)
thefox wrote:why not 5-B and B-5?
PAL's colorburst is at -U+V and -U-V, and we know those have to be two of the phases the 2C07 can put out.
So to get the required 90° phase swing, the two phases have to differ by 3, so the PAL phase reversal will require reflection about some halfway point.
Most sources I've found state that the 2C07's shade 8 is oranger than the 2C02's, so pure hue -U on PAL should be shade 8½.
thefox wrote:Aspect ratio is also wrong (or at least different than on my CRT).
I wonder if they're sampling at 13.5MHz (BT601 for NTSC) instead of 14.75, and saying "eh, good enough" ? The aspect ratio I'm seeing here is 440x478px, or .92 ... and 13.5/14.75 is also .92.

Anyway, here's a cropped version of (frames 74 and 278 of) the video, showing it failing at PAL blending:
reversed.png
reversed.png (28.43 KiB) Viewed 18629 times
I'm pretty certain the capture card isn't doing any chroma merging at all: e.g. shades $21 and $22 looks good while shades $22 and $21 look awful, and as you pointed out, when you zoom in the individual scanlines extend unchanged from the outside two halves of the pie chart.

Are the colors otherwise representative, even without the chroma merging?

Given what we've seen here, would you say that the 2C07 produces a insufficiently PAL-compliant signal to allow the use of chroma blending?
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: PAL chroma merging?

Post by thefox »

lidnariq wrote:
thefox wrote:why not 5-B and B-5?
PAL's colorburst is at -U+V and -U-V, and we know those have to be two of the phases the 2C07 can put out.
So to get the required 90° phase swing, the two phases have to differ by 3, so the PAL phase reversal will require reflection about some halfway point.
OK, yeah I understand now.
thefox wrote:Aspect ratio is also wrong (or at least different than on my CRT).
I wonder if they're sampling at 13.5MHz (BT601 for NTSC) instead of 14.75, and saying "eh, good enough" ? The aspect ratio I'm seeing here is 440x478px, or .92 ... and 13.5/14.75 is also .92.
My capture thingus allows selecting multiple resolutions: 480x576 (the default, obviously wrong AR), 176x144 (wrong AR), 640x480 (produces the expected aspect ratio, but the picture is resized down from the height of 576 producing artifacts), 720x576 (wrong AR), 352x576 (wrong AR).

Note to self for future: use 720x576 for capture, fix the interlacing, AR and lack of chroma merging in post-process.
Anyway, here's a cropped version of (frames 74 and 278 of) the video, showing it failing at PAL blending:
The attachment reversed.png is no longer available
I'm pretty certain the capture card isn't doing any chroma merging at all: e.g. shades $21 and $22 looks good while shades $22 and $21 look awful, and as you pointed out, when you zoom in the individual scanlines extend unchanged from the outside two halves of the pie chart.
Yeah I think it's not doing any chroma merging. Some source stated that some simple encoders may rely on the eye to filter out the hue errors.
Are the colors otherwise representative, even without the chroma merging?
Yes, I'd say so.
Given what we've seen here, would you say that the 2C07 produces a insufficiently PAL-compliant signal to allow the use of chroma blending?
I don't think so. I mean, no matter what kind of signal it produces, the fact stands that my CRT (Samsung 14") and my LCD HDTV (Samsung as well) both are happy to eat the signal and to do the chroma blending (producing uniform colors). So no matter how it actually works under the hood, seems to me like it should be exploitable.

Disclaimer: a lot of guesswork coming up. :)

Assuming that we can trust the capture, it seems like the PPU is outputting separate hues on consecutive scanlines of the same colors. From a quick glance and a comparison to the NTSC PPU palette it seems like, e.g. color $22 produces something close to alternating lines of $21 and $23. However, this doesn't explain why the resulting hues are slightly different e.g. for the case $21-$22:
21-22.png
21-22.png (5.97 KiB) Viewed 18587 times
(It's not that visible to the naked eye, though, as you too mentioned.)[/strike]
EDIT: Struck out because this was a bad example. Even if PPU was using adjacent phases to produce the color, $21 and $22 wouldn't produce the same hue on alternating scanlines ($21 and $23 would). That said, even the case $21-$23 produces non-matching hues on alternating scanlines.

Could it be that PAL PPU intentionally outputs two separate hues on even/odd scanlines, assuming the TV will average them out to produce a hue in-between the two other hues? Why it would do that, though, I have no idea.
Last edited by thefox on Sat Feb 22, 2014 2:55 am, edited 1 time in total.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: PAL chroma merging?

Post by thefox »

thefox wrote:Could it be that PAL PPU intentionally outputs two separate hues on even/odd scanlines, assuming the TV will average them out to produce a hue in-between the two other hues?
Actually, now that I think of it, this is super easy to test with palblend.nes: set every color except the top right one to $0F, set the top right one to (e.g.) $21, and see if the even scanlines get a different color than the odd ones:

Here's what it looks like in an emulator:
emulator.png
emulator.png (4 KiB) Viewed 18585 times
Here's what it approximately looks like on PAL NES (just a mockup, but verified on both of my displays):
nes.png
nes.png (4.25 KiB) Viewed 18585 times
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: PAL chroma merging?

Post by lidnariq »

tepples wrote:The standard PAL scanline is 283.7516 periods of the [PAL] color subcarrier. The NES scanline is slightly longer: 284.1667 periods. For one thing, these chroma-blending filters may depend on the correct scanline period.
A random source I found claimed the delay line is tuned to exactly 283.5 periods of subcarrier ("Monochrome and Colour Television by R. R. Gulati"). Demodulation of color in PAL apparently was originally specified to work by having a bandpass filter at the color subcarrier frequency, running that through a delay line, and adding or subtracting the delayed signal. This implies that the color signal is not only delayed vertically by a half scanline, but also displaced horizontally by a pixel at 576i or so (14.75÷4÷fsubcarrier).

The NES's substantially slower scanlines should cause the delay line to be off by enough to produce a perceptible horizontal displacement of chroma signal; it should be close to 1 whole NES pixel (1.25÷1.5).

As to the actual phase produced by the NES ... I'm kinda lost. I took the frame from the video with colors $21 and $22 and calculated some angles:
Color $21 is made of ... let's say, cyan and periwinkle ... and converting those using gimp's R470 YCrCb filter, I get a Cr and Cb of {-22,+58}/128 (111°) and {-63,+24}/128 (159°), 136° blended.
Color $22 is made of ... periwinkle and lavender? ... and for these I find Cr,Cb of {19,58}/128 (72°) and {-39,58}/128 (124°), 109° blended.
The blended numbers are sufficiently close to the expected 135° and 105°, but I'm really not clear what's going on with the separate pre-blending components.

Anyway, we don't need an oscilloscope, because televisions already have the necessary bandwidth. Taking the composite output of two separate PAL sources (consoles, VCR, whatever) and connecting them to a TV's s-video input (with the NES as "chroma" and displaying a solid color) should let us see what the relative phase is of colorburst relative to the rest of the signal on the line, because clock drift between the two video sources will cause the chroma signal to drift to where the burst signal is visible.

Lacking an s-video port, one could probably even just manage something with some resistors or a capacitor to mix the two video signals together; the only important thing is that it get the synchronization timing from one source and the color from the NES.
Post Reply