In search of a PAL region reference palette

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

Moderator: Moderators

User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: In search of a PAL region reference palette

Post by rainwarrior »

Drag wrote: Thu Mar 30, 2023 12:51 pm I think I know what's happening: my palette generator now includes the hue shift that occurs on the lighter rows of the palette (the "row skew" setting, also in radians). Row skew is applied like this: hue += rowSkew * rowNum.

On default settings, the third row from the top (rowNum = 2) gets an additional hue adjustment of -0.174 (-10°), plus whatever you entered in the "hue" setting. This skew is different between revision E (-2.5°) and G (-5°), and is probably also different on PAL PPUs.
So, that's a phenomenon I haven't heard of before. What would cause a skew for each row? Is there a theoretical explanation? Is there a discussion thread about this anywhere?

So, default settings, then set to SMPTE, and rowskew of 0. First hue 0, then hue -0.262 (15 degrees):
drag0_drag15_SMPTE_rowskew0.png
drag0_drag15_SMPTE_rowskew0.png (5.09 KiB) Viewed 1966 times
And then like the previous comparisons, 0 degrees, thefox's capture, 15 degrees:
20row_drag0_thefox_drag15_SMPTE_rowskew0.png
20row_drag0_thefox_drag15_SMPTE_rowskew0.png (2.39 KiB) Viewed 1966 times
In this configuration, the captured hue is always closer to the 15 degrees palette.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: In search of a PAL region reference palette

Post by lidnariq »

rainwarrior wrote: Thu Mar 30, 2023 2:02 pm So, that's a phenomenon I haven't heard of before. What would cause a skew for each row? Is there a theoretical explanation? Is there a discussion thread about this anywhere?
Output impedance varies by DAC output tap. Combined with parasitic capacitance this causes a variable delay. As a result hue changes by very roughly 5 degrees per luminance step on 2C02G, and 2.5 degrees on 2C02E.

Here's an old thread: viewtopic.php?p=186297#p186297

If you look at TheFox's video capture, you can see this is also true on PAL PPUs - it's just that "proper Telefunken" decoding on PAL conceals this error, as long as colors are more than one scanline tall.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: In search of a PAL region reference palette

Post by NewRisingSun »

That is right -- the original PAL patent calls this effect "differential" phase distortion where the hue (in angles) changes as a function of brightness, and that PAL decoding with a delay line eliminates it.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: In search of a PAL region reference palette

Post by rainwarrior »

lidnariq wrote: Thu Mar 30, 2023 2:17 pmIf you look at TheFox's video capture, you can see this is also true on PAL PPUs
TheFox's capture video that I found only displays colours from row $20. Is there another video that I missed? It would be great to get a complete set rather than just the one row.
lidnariq wrote: Thu Mar 30, 2023 2:17 pm"proper Telefunken" decoding on PAL conceals this error, as long as colors are more than one scanline tall.
So the NTSC version is subject to this row-skew effect, but PAL effectively isn't.

Drag's generator's default setting have NTSC with hue at -0.1 (5.7°) and a row skew of -0.087 (5.0°). Was -0.1 was chosen because this delay effect is already ~5° for the $00 row, and gets stronger from there?

With this in mind, comparing the default as SMPTE (top), with 15° hue (-0.262) and 0 row skew (bottom)...
drag_SMPTE_default_vs_hue15_skew0.png
drag_SMPTE_default_vs_hue15_skew0.png (5.01 KiB) Viewed 1921 times
So, with that model, row $20 is practically identical. The strongest difference is in the darkest row $00, and even that is only 10°... it's starting to seem like the hue differences between NTSC and PAL should be almost negligible? The PPU with 2.5° skew might be a little more different, but it seems that either way the difference between the two is significantly reduced by the skew effect.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: In search of a PAL region reference palette

Post by lidnariq »

Nevermind! I misremembered what was in that demo ROM. You're right: it only shows the effects of the different delays forwards and backwards for the $2x colors.

PAL is resilient to these errors ... if colors are more than one scanline tall.

I've since used web.archive.org to recover most (but sadly not all) of the attachments in the other thread, including Hardwareman's pictures of Pino's demo showing that the amount of delay depends on the specific PAL PPU (including famiclones)
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: In search of a PAL region reference palette

Post by Drag »

The default settings have historically been what most closely matches what my eyes think my Panasonic CRT TV from the 2000s is showing me, when I try to match it against whatever my current computer screen at the time is. That's why the default settings aren't all 1.0 or 0.0, and why they've subtly changed over time. :P

The fact that the hue setting I agreed with was almost the same as the row skew setting is just coincidence, but thinking about it more, it makes sense that the first row might already be skewed by the effect.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: In search of a PAL region reference palette

Post by rainwarrior »

lidnariq wrote: Thu Mar 30, 2023 4:51 pmPAL is resilient to these errors ... if colors are more than one scanline tall.
For the purposes of a single palette approximation it seems appropriate. (I suppose we could use 2 palettes for cheap hanover bars?)

Otherwise we'd probably want to simulate the actual alternating lines and chroma merge.
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: In search of a PAL region reference palette

Post by Quietust »

rainwarrior wrote: Wed Mar 29, 2023 3:43 pm
Individualised wrote: Wed Mar 29, 2023 3:19 pmPAL PPUs have extra grey colours???
No, that's just Nintendulator's palette generator. It's a debugging-oriented emulator, so possibly Quietust wanted them to be distinct for some diagnostic reason.
Right now, the PAL palette in Ninendulator is hardcoded because I didn't have a set of reference voltages with which to make a "proper" generator (like what I have for NTSC) - I don't remember where I got it from, but I intend to get rid of it.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
Post Reply