nesdev.com

I wonder whether that has anything to do with the tint bits, which attenuate the signal during those phases. Or it might have something to do with eight phase units (eight half cycles of the master clock) equaling one pixel, causing intermodulation between the pixel clock and chroma subcarrier.

Yes.

Supposedly, nothing. Macrovision uses a DC offset during the back porch this to defeat VCRs' AGC. However, this does imply colors when routed through a VCR will be different. (Depending on the VCR, possibly only in recordings, or possibly all the time).

If anything were to happen, it would the AGC behavior I mentioned, with displacing black level up and so increasing contrast and darkening already dark colors. There should be no phase dependence.

The voltages on the wiki are colorburst low: 1V, colorburst high: 1.712V, black: 1.3V, and the average of the first two is 1.356V. So it sounds like yes, there's a slight DC offset.

Well, it's 8-bit digitized RGB that uses 0-255 to represent some range brightness for each component. The brightness of 255 isn't absolute. TVs use RGB as well, converting RF/composite/component into RGB before the amplifiers. At that point, they are voltages from 0 to some maximum, which can be mapped to the 0-255 range. Analog electronics have limits as well, and so do phosphors, they're just working well within the limits. I believe that later CRTs did some digital processing on the signal, so they may very well have digitized each component (R, G, B) into some number of bits. It would be indistingishable if they used enough bits. Also remember that the gamma-to-linear conversion occurs mostly at the phosphors, so the digitized version would have favorable non-linearity that gave more precision in darker tones where the eye is more sensitive to smaller differences.

I always wondered the same thing too. Does a smaller colorburst make colors more saturated or less saturated?

A smaller colorburst would likely make the picture more saturated, because the saturation levels in the picture will look bigger when you compare them to the smaller colorburst amplitude.

So my next challenge is that I don't know what exact saturation the colorburst is supposed to represent. In my app, a "sat" of 1.0 is basically a color explosion at the moment, so I know that's not correct.

For now, I've updated the palette generator. Some of the new tweak settings are from suggestions. The hue was me, because even though a hue tweak of 0.0 should represent the exact hues being sent, it still doesn't look right unless I shift them by -0.15. Your mileage may vary.

A CRT TV technically has a "gam" of 2.2, and it does help a little bit for some of the darker colors, but it seems to mess everything else up right now. Meh.

Also, if anyone has a better suggestion for gamut mapping (converting the out-of-gamut colors to in-gamut colors), I'm open to suggestions.

Edit: If anyone's interested, this is what I've been using on my NES for comparison. It's based on the older PALTEST.NES demo floating around here, but I needed to have the colors all touching each other. I tried to minimize the flickering glitches as much as I could. No emphasis toggling support though, sorry.

Depends on the television.

The last DSP-based ones scaled luma by the size of the sync pulse (scaling the entire input such that sync-to-blank was 40IRE), separate out chroma, and scale that such that the colorburst is also 40IRE peak-to-peak.
I believe the older analog sets only scaled everything according to the sync pulse. (Since NTSC was amplitude modulated, some kind of compensation for the distance to the transmitter is needed).
Many sets don't do this scaling for composite input, however.

OTOH, the 2600 has two variants, one which transmits its colorburst at the same amplitude as the rest of the color, and the other which attenuates the amplitude for the colorburst (ties /BLANK to CHROMA through a 680Ω resistor); I don't recall people have mentioned variation of saturation between the CX2600 and the CX2600A or the various mods (which largely seem to ignore /BLANK).

That could easily be because nobody noticed or cared about it. However, I haven't thrown out the possibility that the colorburst is mainly used for its phase and nothing else. If a picture is too saturated, you can just twist the saturation knob, so it's plausible.

Scaling the entire signal level by the sync pulse works well for RF because RF uses negative modulation, where sync is the highest signal level. Composite uses positive modulation, so it's less helpful there.

I too have been assuming that color burst is for phase.

I was using the R, G, and B primaries as defined by the FCC, but the FCC defines those primaries with a white point of C. I've been using a slightly different white point so that the gray colors looked correct, and not bluish.

If anyone is versed in the CIE color space: In order to use a different white point, can I move the R, G, and B primaries the same amount as I've moved the white point?

In other words: R' = (.67, .33), G' = (.21, .71), B' = (.14, .08), and the C white point is (.310, .316). If I use a white point of (.314, .330), and the difference between the two white points is (.004, .014), can I add (.004, .014) to my primaries to make: R' = (.674, .344), G' = (.214, .724), B' = (.144, .094)? Or is that an incorrect way to shift the white point?

I can suggest for the emulator to have two modes:

• NTSC mode: Set up the conversion matrix and attenuation amount.
• RGB mode: Set up the 64-entry palette, tint mode, and extra dot mode.

Therefore you have accurate emulation, and you can configure it, and it work both with games meant for NES and NTSC Famicom, and with games designed for RGB Famicom. And you can make it act like a black and white TV set by using only the Y signal in the conversion matrix, in case you want to test if the picture is good on black and white TV sets. And what I suggested also means, you can turn off the attenuation or set it whatever you want, allowing to test how it might look on clone systems with wrong attenuation, to not use it at all, or to use RGB tint bits to see if the game still works in that mode.

_________________
.

Nestopia still can make a more accurate palette than anything my own palette generator can produce.

I don't understand it; I have the three coordinates that represent the exact color a TV's red, green, and blue are. I just want to mix various combinations of various intensities of red, green, and blue. So, I'm mixing the colors in CIELuv space, which is supposed to represent the behavior of mixing differently-colored lights together (like on a CRT for example). I even tracked down the exact hue colorburst is supposed to be.

Why can't I make my palette generator produce the correct colors? Do I need better way to remap the out-of-range colors? What's so hard about this? This should be absolutely everything needed to make perfect NES palettes. :\

To address the out-of-gamut colors, I'm trying out using some rendering intents, and the first one I'm trying is absolute colorimetric.

So basically, the color's RGB is converted to CIEXYZ coordinates (X, Y, Z), and then converted to CIELuv coordinates (L, u, v).
I also have the CIExyY coordinates for the R, G, B primitives (the points on the XYZ graph which give you #FF0000, #00FF00, and #0000FF), which I've converted from xyY to XYZ and then to Luv.

That's as far as I've gotten. I don't know what I'm doing, and I can't find anything helpful from a google search. I don't know what kind of 3D shape the sRGB primaries make; in 2D, they make a triangle, but in 3D, do they linearly connect to the white and black points to make a diamond shape, or is it supposed to be rounder?

Ugh, I'm so confused. Whatever shape it makes, if the color is outside of that shape, then it's out of the sRGB range (meaning R, G, or B is <00 or >FF), and the color needs to be remapped so the point is inside of the shape. If I've interpreted correctly, absolute colorimetry means the out-of-range colors are just brought closer to the white point until they're on the edge of the sRGB's "shape", which means one or more channel is FF.

Not sure if I can help you with the color science stuff yet, but I did have a question. How did you determine that NES uses Y'IQ colorspace instead of Y'UV? To the best of my knowledge, Y'IQ hasn't been used since the 1970s due to decoder cost. And I think you had the in-phase and quadrature-phase components backwards on page 2. Composite color for Y'IQ should be:
C = Q∙sin(ωt + 33°) + I∙cos(ωt + 33°)

For Y'UV:
C = U∙sin(ωt) + V∙cos(ωt)

For Both:
ω = 2π∙fsc
fsc = 315/88 MHz
Colorburst = A∙sin(ωt ± 180°) = -A∙sin(ωt)
A = 20 IRE = 142.8mV

_________________
Ste Kulov
Lead Design Engineer
HD Retrovision
http://www.hdretrovision.com

What does it mean to say that something "uses" a particular color space? The NES merely has particular waveforms that it outputs in response to palette indicies. These consist of either constant amplitude or a square wave of a particular phase between two amplitudes. Game programmers choose indicies based on what colors appear on a TV. They don't choose based on describing the NES circuitry as "thinking" of a particular color in a particular encoding space, outputting the proper phase of wave for it, then the TV decoding the phase and interpreting that as "asking" for a particular color, then converting that to RGB and displaying it.

In that case, the NES "uses" the color space of the TVs with which the artists tested their palette choices. So if we're emulating a TV, we have to know the color space of that TV.