PAL chroma merging?

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.

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)

1) Yup, it's all uniform.
2) Yes (not that surprising, this one?)

Good observation, and a well made test ROM.

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):

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).


Happy to see somebody else besides me using it.

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)

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).

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.

Can you explain to me why you call the filter [0.5 0.5 0], isn't [0.5 0.5] equivalent?

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?

I assume the phase shift is easier to see if the filter has an odd number of taps.


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.

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)
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½.
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:

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?

OK, yeah I understand now.


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.


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.


Yes, I'd say so.


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:

Attachment:

21-22.png [ 5.97 KiB | Viewed 10713 times ]

(It's not that visible to the naked eye, though, as you too mentioned.)
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.

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:

Here's what it approximately looks like on PAL NES (just a mockup, but verified on both of my displays):

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.

I threw together another small test:

This test simply has a palette of 3 colors (+ black background) and displays all 9 possible combinations. In this case the palette is $21, $26, $2B.

Emulator screenshot (Nestopia):

Photo of my TV screen (Samsung HDTV):


EDIT: Changed test to NROM, seems I made it MMC1 by mistake.

Sorry for the bump, but a few questions:

How would this look on a CRT? Given the NES was designed to be played on a CRT, it seems like a fitting question to ask.

Is this 'trick' exclusive to the PAL region? Or could it be reproduced on NTSC systems/TVs as well?

CRT vs LCD is orthogonal to the question I've posed here. Only after the incoming signal is converted to RGB do the differences between LCD and CRT matter.
In practice, it's exclusive to PAL. PAL specifies color recovery by using a delay line of precise length and using the additive and subtractive interference between the current and delayed color signals, while NTSC specifies color recovery by using a PLL to demodulate QAM and different bandwidths for the orange-vs-blue and green-vs-purple axes.

A few modern NTSC sets add a comb filter to attempt to exchange some vertical color resolution in exchange for horizontal, but the results are harder to predict, vary more from set to set, and may sometimes be disabled for sufficiently non-standards-compliant inputs (such as from a NES). TVs that use a "3d" comb filter would be ludicrously difficult to drive in a predictive fashion, especially given the NES's limited palette.

The results are (mostly) the same on my CRT. There are some rare color combinations that the CRT and HDTV don't seem to agree on, IIRC one of them produced a greyish tone on my HDTV, but some actual color on my CRT. Probably a detail of how the filter is implemented.

...

Does anybody have a good idea how the chroma merging could be simulated in AviSynth? I guess it should be something like 1) convert to YUV (or YCbCr, strictly speaking) 2) separate the Y, U and V planes 3) scale the U and V planes by 0.5, and blend them with a shifted version of themselves 4) combine back to YUV.

Using the frames from the video you'd posted, I did the following in gimp:
- Rescale nearest-neighbor down to 288 scanlines high
- Colors / Components / Decompose / YCbCr ITU R470
- Select the Cb layer; Filters / Generic / Convolution Matrix / the matrix that looks like
and enable normalization
- Repeat the same for the Cr layer
- Colors / Components / Compose / YCbCr ITU R470Is this consistent with what you see?

I'd also tried using a diagonal delay (the NES's scanline is too long), but I didn't really notice an appreciable difference. I guess any difference probably requires that it operate on the modulated chroma signal, not the baseband components.

Suddenly I'm thinking of "Owner of a Lonely Heart".


Warner Music

Not sure if related, but I noticed that when playing Batman on PAL NES (CRT TV), in the very beginning of level 2-1 parts of the background graphics changed colors as the screen scrolled vertically (when jumping up to the platforms with wall jump, and coming down again).

Has anybody else from PAL land noticed the same happening with Batman?

I didn't notice that with Batman, but I clearly remembering seeing that in Kid Icarus. It changed so much I was sure the game wrote to the colour emphasis bits, before verifying in an emulator that actually it doesn't.

You could get around it if you only scrolled vertically in increments of 2. That'd fix background flashing, but sprites would still have the same issue unless you locked their (display) Y position to increments of 2 as well. I don't think this would have a HUGE effect on gameplay.

Yeah I tested Kid Icarus now as well, and it's very noticeable there right from the beginning.

I'm surprised I haven't seen this mentioned anywhere before.

Anyone willing to take a scope to the PAL NES's composite output while running test ROMs to see what signals it's really outputting?

There is also an artifact on NTSC where there are false colors on color boundaries. I think it happens when a tv signal has uneven chroma sidebands. I think it's mostly an RF problem.

Not really related, but today I noticed that the emphasis bits don't work the same on PAL NES as they do on NTSC NES. For example red emphasis on NTSC NES functions as green emphasis on PAL NES.

Haven't tested it thoroughly yet.

Now that is weird!

Noah's Ark is a PAL game that uses blue emphasis combined with the grayscale bit to flood the level with water. I can't really remember if I tried that game in NTSC mode/consoles, but I've certainly never seen the water being any other color.

If red and green are swapped, blue might still be the same, though.

Yeah that's it, red and green are swapped, blue is the same.

A photo from a TV screen showing a version of blargg's full palette demo hacked for PAL:

(From top to bottom 000, 001, 010, 011, 100, 101, 110, 111)

Is this the same problem the Dendy has?

Didn't Dendy have a problem that it showed green emphasis or whatever when all of the emphasis bits were on? If so, that doesn't happen on PAL NES. "All bits on" makes the palette darker as on NTSC (as evidenced by the photo and well, there being several PAL region games that use the screen darkening trick).

The Dendy generates a PAL signal, so it's likely that it is indeed the same issue. Don't forget that some clones don't get the APU duty cycles right, so this could be something that happens on clones and not the genuine thing, just like that.

But are the changes made to the PPU by Steepler's ASIC supplier to make a PAL signal the same changes that Nintendo made, or were different choices made by different engineers with different priorities? I know the Dendy CPU is different from the PAL NES (/15 instead of /16), and the Dendy PPU's timing is different (vblank at 291 instead of 241), for maximum compatibility with Famicom software.

Dunno. How do you even clone something like this, anyway? It could be that official PAL Famicoms have the red/green bits swapped and since that's what got cloned, that's what shows up on Dendys. Or, it could be that they don't and the cloner got things mixed up somehow, or swapped it to avoid patent infringements or something goofy like that.

Which version of the palette test ROM is that? Because I've got 2 versions which have different layouts and different emphasis orders:

1. "version 2", where each color section is upside-down ($30/$20/$10/$00 top-to-bottom) and emphasis is ordered White,Blue,Magenta,Red,Yellow,Green,Cyan,Black (000,100,101,001,011,010,110,111)
2. "optimized version", where each color section is right-side-up ($00/$10/$20/$30 top-to-bottom) and emphasis is ordered White,Red,Green,Yellow,Blue,Magenta,Cyan,Black (000,001,010,011,100,101,110,111)

Your image seems to be using color layout #1 but emphasis layout #2, which is a bit confusing.

Here's the ROM:
NOTE: This ROM is just a quick hack from the original. It's not optimized in any way to minimize flicker/wobble. Also it doesn't display the full palette (some colors are cut out from the right).

The source is based on the download from http://wiki.nesdev.com/w/index.php/Full_palette_demo

Another game where this is very noticeable is Elite. Those single pixel wide wireframe figures on a black background showcase the alternating even/odd scanline color perfectly.

Here is "Full NES Palette Viewer - Optimized Version by Blargg (PD)" photo captured on custom-made Dendy (UA6538 PPU, Famicom AV PCB):

It'd be better to use the forum's attachment feature for images.

I've attached images

Eugene, any chance you could take a picture of thefox's or my chroma merging tests? I'm curious whether the Dendy PPU's as peculiar as the 2C07.

Ok, I will try. Is this tests work on punes dendy mode timings?

There's no raster effects, so it should work fine regardless of 2C02/2C07/Dendy.

A word of caution about my test: it looks like I made it use MMC1 for some reason that I can't remember, but omitted doing any mapper initialization (wtf?). It was probably an accident, so I've attached the same ROM as NROM into the original post.

Uh, Sunrise is coming, so too much glare on TV-screen

Interesting, looks like Dendy PPU's color generation is indeed different than in 2C07.

Are the colors on the bottom left and bottom right the same?

Do you mean palblend test?
Bottom-right is more violet than bottom-left.

Here is new, more accurate capturing via AverMedia tuner (thanks to HardWareMan):

Blarrg's Full Palette viewer:
composite: http://hwm.us.to/famimusic/Capture/6538 ... posite.png
s-video: http://hwm.us.to/famimusic/Capture/6538 ... Svideo.png

Kinopio's test:
composite: http://hwm.us.to/famimusic/Capture/6538 ... posite.png
s-video: http://hwm.us.to/famimusic/Capture/6538 ... Svideo.png

Merge test:
composite: http://hwm.us.to/famimusic/Capture/6538 ... posite.png
svideo: http://hwm.us.to/famimusic/Capture/6538 ... Svideo.png

Palblend test:
composite: http://hwm.us.to/famimusic/Capture/6538 ... posite.PNG
s-video: http://hwm.us.to/famimusic/Capture/6538 ... SVideo.PNG

Are these shots from a different version of the Dendy PPU than the ones from before? In this case the color generation seems to be the same as in 2C07.

Yes, this is different PPUs

My PPU is:
UMC UA6538
9051-bs
813410
http://forums.nesdev.com/download/file. ... &mode=view

HWM's PPU:
UMC UA6538
9051-bs
611510
http://hwm.us.to/famimusic/Capture/6538 ... posite.png

This is so strange. There are similar chips.

Unless different TVs are decoding the signal differently. Could you try the two revisions on the same brand of TV or tuner card?

Yes you are right Tepples.
I've just replaced my PPU to 611510 revision, like HardWareMan have.
And my TV shows this picture like 813410 revision

Given the Avermedia pictures, I wonder if plugging a 2C07/Dendy straight into S-video luma would give us enough information to reverse engineer what's going on?

Or maybe there's already enough image in the "Kinopio's test: s-video" picture?

It's a little unfortunate that 13.5 MHz ÷ 4.43MHz is only ≈3. Makes it a little more difficult to determine what's going on solely by inspection instead of rigorous measurement.

I can do more (clickable):


I can disconnect chroma pin to get pure B&W picture with color subcarrier on it, but I think reducing saturation is more than enough. Anyway, these pictures has no most imported part of puzzle: color burst. Because PAL/NTSC decoders adjust their PLL with color burst and then compare phase shift of subcarrier in scanline. So at this pictures we see only relative phase shift between different colors.

I'd like to see how all $1x colors mix with a neutral gray $00 on alternating scanlines. Should I write a quick test ROM for this?

Yes, you can write it. I and HardWareMan both have InviteNESes flashcartridges to test it.

here is updated version of Kinopio's palette viewer
It work stable on NTSC/PAL/Dendy timings:
download/file.php?id=14270

Yes, please.

"Your message contains too few characters."

Any *.NES file?

Looks like you forgot to include the binary, tepples, so here it is.

Here's a really crappy photo of my CRT TV (2C07 PPU). From what I can tell, it looks like colors match up so that evenHue = oddHue+2 (with wrap around, of course). E.g. the even scanline of $15 is the same hue as odd scanline of $13. (Looking at the TV the colors match up better than in the photo.)

Which is funny, because in HardWareMan's cap it's quite clearly evenHue = oddHue+1.

It's my Dendy on PAL CRT (UA6538 PPU)

Oops, my bad. There are two places I need to change the binary's filename when I import the project template: makefile and zip.in. I forgot the latter.

So it looks like Dendy does this aspect right and PAL NES does it half-@$$, just as with the CPU clock divider. Anything I need to add in a second version of this test?

Ok, so:
A PAL scanline is "supposed" to be exactly 1702.5 master clock cycles, or 283.75 chroma cycles.
The 2C07 (and it looks like UA6538 also, given HardWareMan's pictures) scanlines are 1705 master clock cycles long, or 284 1/6 chroma cycles.
We see the expected repetition of phase every 6 scanlines.

What's weird is, as far as I can tell, adjacent scanlines of all hues really shouldn't be ≈the same phase, and yet they seem to be.

Maybe a useful test would be to exchange the solid grey scanlines in tepples's test with some fixed color? That way we should be able to say that hue phase X on even/odd scanlines is the same as hue phase Y/Z on odd/even scanlines? Obviously will only be visible on the luma-only signal.

I'll take this as a feature request to let the user change the background palette between $00 and any color $11-$1C. Is that what you want?

Sure?
I guess that's not all that different from the original test I made, although it lets you compare more colors simultaneously.

Exchange this.

Here we go.

What did you use to take the photo? In my experience phone cameras tend to be good at taking photos of CRTs (apparently you need a crappy camera to take a good pic of a CRT, who would have thought)

iPhone 4

I will upload new test pictures at evening today

Well, I took out my old monitor, which is used in the 90's. Do not look at the geometric distortion - I'll fix them later. The main feature of this monitor is that it is PAL decoder built on a good old TDA3510. This "warm tube" analog PAL decoder that utilizes the 64mks delay line. Therefore, the result really depends on the content of neighboring scanlines. In the new digital decoders, each scanline can be processed separately, although Avermedia shows almost identical to TDA3510 results.
UMC UA6538:

HA6538:

I've tested dendy on 2 different PAL CRT TV-sets.
Here are palphase and palblend tests:

Dendy's UMC UA6538 PPU on SAMSUNG CK-5341TR PAL CRT

Dendy's UMC UA6538 PPU on SONY TRINITRON KV-21LT1K PAL CRT (looks like it has more significant phase offset)

The bottom-right square of "pal-chroma-merge test" looks yellow on KV-21LT1K,
but it really brown on CK-5341TR:

Well, I fixed my monitor, replacing all dried up capacitors. Then made the chroma decoder setup procedure using a test signal generator and oscilloscope. The main problem was in the LC contour matching of the delay line. So here's what I've got:

Despite the small jalousie effect in some colors (need to more accurately adjust the LC contour of delay line and the LC contour of color subcarrier) is still colors are the almost same. So the xx6538 Dendy's PPU color coding is correct.

OK, so you're saying that the systems output the correct phases/hues on each scanline, but each individual TV's decoding has some phase shift on alternating scanlines, relying on it to be averaged out after filtering? Seems like that would certainly make the most sense, given the different results we've seen from different TV sets when using the same console.

It's unfortunate that this would also mean that this artifact cannot be reliably exploited. Nevertheless, it might be useful to emulate it (with configurable phase shift).

Well, it's pretty logical. There's also a purely digital circuit and a set of frequencies is clearly limited. It does not matter that the frequencies are not multiples of the scanline frequency, the color burst is taken from the same frequency source.

I've been thinking. With regards to the PAL. The system uses a delay line. It is designed for exactly 64mks (15625Hz for PAL systems). Thus, if the frequency of the scanlines is slightly changed, the delayed scanline will not be exact to the desired phase, causing color artifacts.

So I did some capturing with my Famicom AV and Pinnacle USB capture device (+iuVCS tool). And it appears chroma is very well merged at some level again, and again white and black aren't affected. Grey is weird, in the curcle test it's untouched as well, while the palphase test shows how it is merged with the colors.

Circle video (the device rescales to 640x480, and then applies some sort of interlacing, so I reduced it internally, let me know if it matters):
http://rghost.ru/8YkDyvGgJ

The images aren't deinterlaced though.



Does NTSC stuff even matter in this case anyway?

NTSC doesn't do any vertical chroma subsampling, if that answers the question...

Anyway, the bit where "black" and "white" appear to not suffer from chroma subsampling happens because the subsampling only happens on the U and V components, and out of gamut colors are clipped back into gamut.

Say you had a screen full of alternating scanlines of
- black (Y=U=V=0) and
- yellowish (Y=0.5, U=-0.5, V=0)

Chroma subsampling would turn those into:
- black (Y=0, U=-0.25, V=0)
- greyish-yellow (Y=0.5, Y=-.25, V=0)

Then when you convert those to RGB values to drive the (conceptual) electron beams with, you'd get
- black (R=0, G=0.098, B=-0.483) which is probably clamped to (R=0, G=0.098, B=0) (#001B00)
- greyish-yellow (R=0.5, G=.598, B=0.017) (#809804)

And I'm skipping gamma correction, because that's a pain. But it doesn't affect U and V values, just Y and the colorspace transformation.


I understand that you're trying to figure out how to do something equivalent given RGB input and lookup tables, and to first-order approximation is seems like white and black are just not affected, but I'm just not all that certain that you can do this accurately without converting back to YUV.

Does it mean the tuner does it on its own? It kind of allows to choose what it receives, several types for NTSC, PAL and SECAM, some of them are grey, some have clear moire even with composite output, I might assume it doesn't affect what it generally does to chroma. It doesn't seem to accept it losslessly though, YUY12 is the primary option, the only other being I420.

Yeah, a multi-standard receiver would have to do something substantially different between SECAM and PAL, so doing a third different thing for NTSC is plausible.

But people have applied NTSC, PAL, and SECAM color modulation to almost every underlying monochrome video standard:english wikipedia article with analog video standards table ( russian wikipedia article with same table ) ; many won't produce sensible (or any) colors for an arbitrary other-system and/or other-modulation color input.

NTSC's closest equivalent in the digital world would be YUV422, while PAL and SECAM are closer to YUV420. That it won't give you that is annoying :/

Palette test roms mirror (*.nes binaries)