What is the deal with colors $22 and $x8 range? LCD vs CRT?

Color $22, most well known for the sky in Super Mario Bros, seems to be one of the most poorly represented colors in most emulators. I have seen it be anything from a deep blue to light purple. Most of the palettes/emulators claiming to be accurate show it as a bluish purple color. If I plug my Nintendo into an LCD display, it shows $22 to be very close the purple color I see on the "accurate" palettes. So I've sort of just assumed that the color is indeed slightly purple and I was just remembering it being more blue when I was a kid... But today I picked up a CRT from the early 2000s.. and boy that sky is undoubtedly BLUE, without any hint of purple! I messed with the color settings and did get the more purple sky, but the rest of the colors seemed off when I did that.

I've also noticed the the $x8 range tends to show up as a yellow-green color in "accurate" palettes as well as on my LCD display. Using $38 for a sky color on my LCD looks like a kinda "puke yellow" color, but it looks great on the CRT, with the brighter shades like $38 and $28 being much more yellow/brown without green.. though the darker $08 is still slightly olive.

I have been working on updating a hack of mine, with one of the goals to update the color choices to look best on a real system with CRT while also looking good on emulators which have accurate palettes. Up until now I've been using puNES and FCEUX with NTSC mode enabled since they seemed close to my LCD, but neither of them look like this CRT i picked up.. in fact some of my original color choices based on FCEUX's original completely non-accurate palette look better than the updated choices. I know in the end it's up to the TV to decide how the colors are displayed, but it's maddening trying to pick the right colors, especially if you would like to use these colors which seem to be the most widely varied.

My biggest problem with palette definitions is FCEUX misrepresenting colour $2D as a lot brighter than i've ever seen it on any tv. If you turn the contrast all the way down, you get something similar to fceux, but then every other colour is also affected by lack of contrast. Given that FCEUX is a very popular emulator, that's problematic for me since i like to use that colour for precicely that usage.

I guess that since many developers stay away from the $xD column for compability issues with some fringe versions (playchoice, vs. system, famicom titler, and famicom tv), it hasn't been a priority. neslib even scrambles $xD into the $x0 column, which makes for a too bright glitch, since the both the $x0 column has intentionally de-aligned brightness values compared to the other columns.

Some thoughts on the OP colours:
It's not a full explanation, but part of it could be that hue is harder to discern for the human eye than brightness, and there is a lot of individual variance in the capability to distinguish hue. Since the blues and greens of the master palette are more finely represented (to the degree of sometimes almost being pointless) than reds and yellows, they are harder to distinguish, and by extension, represent. You can do it mathematically, but once you get into analog or optical territory, it gets hairy.

In my experience, screens and CRT:s especially are swinging wildy in warm/cold balance from model to model. Even my HDTV is a lot warmer than my laptop and secondary computer screen. What falls into a cold green distinction to my eyes on the former may sometimes be jade or teal on the latter ones.

Drag's palette generator shows that a lot of colors are out of gamut, and different TVs will do different things with colors that are out-of-bounds (both in terms of U/V/I/Q or R/G/B). You can play around with this with the various toggles there.

This doesn't even cover the more-recently documented variable phase shift for different brightnesses (causing hue rotation on NTSC and hanover bars on PAL)

It seems everybody has had this moment of connecting a NES to a real CRT, seeing a particular color looking more x-ish rather than y-ish and coming to think that those emulation people got it all wrong --- until they connect the same NES to a different CRT, and coming to realize how inherently variable and unstable the NES' color generation really is. There are just sooo many things going on:

• Even when black and white levels are perfectly normalized, almost all colors will be either clipped at black or at white because the NES outputs overly saturated colors in the first place (as a result of not originating as RGB in the first place)
• Incorrect color burst and sync amplitudes, some of which are used by TV's automatic gain control for video signal normalization, yielding to brightness and contrast far and unpredictably different from ideal normalization, further changing what the effects of clipping will be.
• CRT TVs clipping differently, at least at the upper bound, than digital displays. Simply put, CRT phosphors oversaturate rather than clip. Also, TV displays (CRT and LCD) typically are much brighter than computer monitors, so at a given mid-range setting, overly-bright video levels may not actually clip because there is still headroom upwards, while computer monitors always clip because there is no headroom.
• Amplitude-dependent phase distortion from signal reflections due to poor impedance matching in the NES' video path. This is a general problem of the NTSC television system, but the NES is particularly badly affected. It depends on the electrical characteristics of the TV set, the cable type and length, the PPU and console model, and even the temperature. I've had the same console look different, with identical TV settings, at different times of the day. Not greatly so, but noticeably in the "problem" colors in the $x8 range.
• NTSC TVs either assuming 7.5% or 0% black level setup, changing how much all colors (or at least the $0x ones) are clipped at the lower bound;
• NTSC decoders using idiosyncratic coefficients to correct for the TV having non-NTSC phospors (i.e. every single TV after 1954), or not correcting at all;
• Idiosyncratic user-adjusted Hue and Saturation.

Color $22 is the one color most sensitive to video levels and consequently the amount and type of upper-bound clipping, while the $x8 colors are the colors most sensitive to amplitude-dependent phase distortion and the user-adjusted Hue setting.

As for picking colors, I've found that picking shades only in the same phase column and thus not mixing e.g. $x7 with $x8 is generally a safe choice, and using the $3x colors for anything other than highlights is a bad choice (see Sky Kid, for example). I have often scratched my head at some games' color choices, until I realized that several of them must have been made to look good on the 2C03 RGB PPU rather than the home console. For example, SMB3 uses pinkish $36 as a highlight for $27, which looks ridiculous on the home console, but exactly right in the 2C03. For the home console, you would use $37 as a highlight for $27, which would look overly yellow on the 2C03.

If only I could get our artist to stop using $06 and $07 next to each other or $0A and $0B next to each other. Those are clearly distinct in luminance in the palette he uses (found in "Applying Artificial Intelligence to Nintendo Tetris" and fornaxvoid.com > Resources > Color Palettes, which galleryNES describes as "NESpalette.png - NES palette found on deviantART, by Erik Red". But they're not distinct on an actual NES or in palettes generated using Bisqwit's generator. It's probably the same deal as the problem you mentioned of classic-era licensed devs tuning game palettes for the 2C03 in their developer hardware.




Menus in RHDE have black text on a $38 background. How does that fail?

This failure mode is wholly unrelated to signal reflections; there is no aerial nor transmission line stage inside the NES itself. Nothing inside the NES is high enough frequency and all of the traces inside are too short to tickle this behavior.
So it's a little misleading to say that the variable output impedance is poor impedance matching. It's just because the impedance is variable.
Yes, only because the PPU emits out-of-gamut colors.
No. Reflections are a linear-and-time-invariant error; phase distortion is not. Phase distortion necessarily requires a powered stage.
That's because the temperature of the PPU itself affects the resistance of the DAC that's used in video generation.

that's an interesting thought about developers developing on a different PPU than the one that was in most people's systems.. seems like that would cause all sorts of color problems.

I still don't get why all the "accurate" palettes show $22 as much more purple than this CRT is showing it, and the yellow/brown $x8 column has almost no green in it on this CRT as well. It's frustrating having such a wide range of colors from emulators to TVs. I guess that's just part of NES graphic development, having to accept that the colors will not be the same on all systems. It's hard to pick which one to be the "definitive" color set too, especially these days where most people are likely to play on an emulator.. 10 years ago it was easier, almost everyone used FCEUX, but now people use emulators, virtual consoles and "NES classic" emulator consoles, all of which also display things differently from the original console

But there can be reflections in the cable from the NES to the TV.
I can definitely (slightly) change the displayed colors in the TV by using a different composite video cable. Even if the explanation may be incorrect, the observation is not.
Not just because of that. The picture will be of a different brightness and hue when I connect the Twin Famicom to the TV's front composite socket compared to the back composite socket.

I have to mention that this variability only occurs with the AN-505BK with its RP2C02G PPU. My other Twin Famicom, the AN-500B with its RP2C02E PPU, is very stable across TVs, cable and connection types, and temperature. And no, I don't know if it's the PPU or just the AN-505BK's video path in general that's causing such variability. We're talking about a maximum hue deviation of about 20 degrees.

I mean, the result of reflections looks identical to a comb filter, where the spacing of reflections is the spacing of teeth in the comb filter. As an LTI system, it could certainly adjust colors on edges, but there's really no way to cause "differential phase" distortion without a powered stage (e.g. clipping in the amplifier, as in early NTSC broadcasting stations; or a voltage-dependent resistance as in the 2C02's analog output).

It would be nice if we actually had multiple different documented complete A/V paths.

In writing my previous reply, I noticed that the A/V path as drawn here doesn't agree with the fragment I reverse-engineered here... So who knows which revision of the RF modulator Electronix Corp's reverse-engineered schematic corresponds to.

Theoretically the 2SA937 and 2SC1740 as specified in Electronix Corp's schematic have h_FEs somewhere around 250, and they're both operating as emitter-followers. The higher the gain at this stage, the better the emitter-follower is at isolating the variable resistance out of the 2C02's video output. But transistors can lose hFE as they age ... and given the already-visible variability in video paths, I think it's plausible that some consoles are using worse choices for their transistors here.

I assume, given the thing you said right after, you mean that only the AN-505BK switches in this way between the inputs? And other consoles don't?

Out of curiosity, do both sockets have the same 75Ω input resistance?

Reflections themselves may not cause differential phase distortion. But different reflections can cause differently-spaced comb filtering, which will cause different cancellations of original signal components, in turn causing different changes in amplitude, causing different phase distortion in any powered stage on the part of the TV set that displays the signal.

The AN-500B is stable across all TVs, capture cards, cables and sockets that I have tried. The AN-505BK is stable with the capture card, but highly variable when connected to several different Sony TVs. The same Sony TVs show stable colors with other home computers and consoles.

In other words, both the AN-505BK and all my Sony TVs have some kind of electrical characteristic that only together cause phase distortion beyond what I described in that palette thread. I don't know how to measure the impedance of any input or output, but from what I have read, it's not as simple as holding an Ohmmeter to it.

man, phase distortion, I thought that was only something you heard on Star Trek

anyways, I was looking up colors and the color named "periwinkle" or "lavender" appears very similar to the color $22 on many LCD displays. It's a combination of full blue and almost full green and red in equal strength (eg #CCCCFF), but it appears more purple/violet than light blue on LCD.. I don't have a CRT computer monitor but it would be interesting to see if the color appeared differently

How purple that particular RGB color looks will (mostly) depend on your monitor's color temperature, which usually can be set from a menu. At 9300K, it will appear to be light blue, at 6500K, it will appear somewhat purplish.

Has it ever been investigated whether they are, and what non-linearities the circuits outside the 2C03 PPU, that are visible in the schematics, impose?

That and the group delay of an RC circuit varies with frequency, and a cable behaves as a capacitor.

Incidentally, "phase distortion" is used outside Star Trek. It's the name of a Casio synthesizer topology that uses a time-varying piecewise-linear phase modulator with a sinusoidal carrier, optionally ring modulated by a downward sawtooth to cover phase discontinuities, for results that sound somewhere between Yamaha's FM and Roland's subtractive synthesis.

You can see the 2C04's DACs in the upper left corner of the die shots here. I'm having a hard time reading it, but I don't see any reason to think there's a nonlinearity in the die.

I believe it's just the gamma of the picture tube that the whole thing is ultimately connected to.

There shouldn't be any nonlinearities. The output is three emitter followers (the middle stage using emitter degeneration), and an transmission gate + opamp with an extreme lowpass to adjust black level.

Coax does technically have a capacitance per length, but outside of tests specifically designed to demonstrate this, it's misleading to think of it as a capacitor instead of as a transmission line. (Transmission lines are low-pass filters made of an infinite series of inductances and capacitances. In practice, the low-pass corner frequency is quite high, usually at least 1GHz)

It is very important in the NTSC context that this is differential phase distortion—that some correlated property causes a variation in the amount of phase distortion.

Plus the fact that the colors were clearly chosen for a CRT with phosphors that are less saturated than sRGB, making reds and browns "glow" on a calibrated sRGB display. In Nintendulator-NRS, I assume "1980's receiver phosphors" from the literature and convert to sRGB to make them look bearable.
It's also important in the NTSC/PAL context that the Hue setting of a TV cannot correct differential phase distortion, while the original PAL patent specifically promotes its ability to do so.

Any idea about the console and TV combination resulting in what I have observed?

Not really... if you can dig up a very long cable (at least 10m) to run from the Famicoms to the TV, that would be informative. At that length, the spacing between reflections should be comparable to a pixel width, making reflections visible as luma artifacts instead of doing something to chrominance.

You could also try using cable with explicitly wrong impedance instead. CVBS is almost always over 75Ω cable, but twisted pair as used in ethernet is 110Ω instead.

Sure. Reflections could tickle clipping behavior (and thus phase distortion) at this stage, but...

For something like a TV, where we really do expect a properly impedance matched input, we don't usually need to worry about reactances or nonlinear stages. They're almost always a high-input-impedance amplifier in parallel with proper termination, and so measuring the input impedance is just measuring the resistance.

Measuring the output impedance is more complicated, especially since we're anticipating something changing the impedance as a function of voltage. I can't think of a good way to do this without an oscilloscope.

Non-linearity may not be the right word. What I mean is that many arcade PCBs use resistors for RGB bits that are not perfect multiples of each other. For example, the original Donkey Kong used 1k/470/220 ohm resistors, which yields slightly different bit weights than one would get when merely multiplying values 0-7 with 255/7. It's also not uncommon to use different resistors for blue than for red and green.

I was mostly referring to the fact that levels 0-1 and 6-7 on a Mega Drive/Genesis VDP are spaced much farther apart than, say, 3-4.

Fortunately, non-linearity is the right word here also.

On the 2C04's die, you can see eight total MOSFETs per output, so much like the 2A03's audio DACs, they're as linear as they could manage. (The MOSFET gates are the vertical red lines surrounded by vertical white lines on both sides)

The design is unipolar and appears to be sinking current, so unlike the pull-up nMOSFETs and external the pull-down resistor with the 2A03's audio path there's no obvious source of nonlinearity here.

The PNP-based emitter-follower is probably actually just serving as a straight current amplifier on the RGB PPUs.

The reason color 22 looks purplish is because of the clipping process when going from YIQ to RGB. Color 22 generates an extremely strong blue that is very far out of the RGB range. If you connect your NES to an LCD, and turn the brightness down a bit, as you turn it down, you'll see SMB's sky changes differently before it starts dimming with the rest of the colors. This might also be the explanation for Virtual Console NES games having a dimmed palette.

The phase of hue 8 is identical to the hue of the colorburst signal, which has been documented as being a greenish yellow. My reference CRT displays hue 8 as "simpsons yellow", or marigold. Why? Absolutely no clue, and there's a million different reasons it could be. It could be due to skin tone enhancement circuitry, the hue as a whole might be tweaked slightly, it could be the specific phosphors used in the TV, there's really no way to know unless you can decap the circuitry which translates the YIQ into the voltages for the electron gun, and even then, it's going to be different for every TV.

I was never able to solve why hue 8 is so weird.

Because as pointed out some time ago, color 8 is not exactly color burst phase at all brightness levels as a result of brightness-dependent phase shift. The same applies to color 0x22, although blue clipping does play a role in it as well.

Oh! So there's been more developments? Sorry, I've been out of the loop for a while.

The issue I have with the brightness-skew is that, for me, hue 8 darkens to brown, and hue C darkens to blue, and these are shifts that are in opposite directions to each other, but the numbers seen to suggest that the skew is in the same direction for all hues. Maybe I just need to look at more examples, but I'm not convinced that the brightness skew is the biggest factor in the colors we're seeing.