2600 and 5200 palettes compared

[Thomas Jentzsch]

I think the z26 palette is just about the closest of the emulator palettes, at least as far as the hues go-- but the colors don't get bright enough; there should be a greater range in contrast from the lowest luminance to the highest luminance.

Luma is calculated based on a given "middle" value in z26.

 

/* note: RGB values are for the $x6 color */

unsigned char NTSC_RGB_table[] = 
{
120, 120, 120,		/* (00) <120,120,120> grey */
128, 144,   0,		/* (10) <128,144,2>   gold */
163, 117,  19,		/* (20) <163,117,19>  yellow orange */
183,  97,  64,		/* (30) <183,97,64>   yar's bright orange */
185,  78, 104,		/* (40) <185,83,124>  pink */
175,  68, 173,		/* (50) <175,78,173>  purple */
153,  71, 206,		/* (60) <153,81,211>  blue purple */
124,  81, 213,		/* (70) <124,91,228>  atlantis right blinker blue */
97,   97, 207,		/* (80) <97,107,217>  blue */
75,  112, 188,		/* (90) <75,122,188>  light blue */
64,  126, 150,		/* (a0) <64,136,145>  atlantis turquoise */
64,  139, 108,		/* (b0) <64,144,103>  green blue */
75,  145,  70,		/* (c0) <75,145,65>   light green */
91,  141,  45,		/* (d0) <91,141,45>   yellow green */
112, 130,  40,		/* (e0) <112,130,40>  orange green */
130, 120,  40		/* (f0) <130,120,44>  light orange */
};

unsigned char set_luma(int luma, int val)
{
val += luma*20 - 60;
if (val<0) return 0;
if (val>255) return 255;
return(val);
}

void NTSC_Palette()
{
int chroma, luma, red, green, blue, i;

for (chroma = 0; chroma <=15; chroma++)
	for (luma=0; luma<=7; luma++)
		for (i=0; i<3; i++)
			PCXPalette[chroma*3*8 + luma*3+i] = set_luma(luma, NTSC_RGB_table[chroma*3+i]);
PCXPalette[0] = 0; PCXPalette[1] = 0; PCXPalette[2] = 0;
}

So maybe set_luma() should be improved.

[Kr0tki]

Interesting. In your picture hue 15 is somewhere between hue 1 and 2. And hue 15 is even closer to yellow than hue 1. Other palettes show hue 15 somewhere between hue 14 and hue 1. Most games I know about use hue 1 for yellow, maybe because it is more predictable?

 

Hm...

 

Maybe supercat's theory is right. Atari set up the consoles so that hue 1 = hue 15. Maybe with the instruction of an intentional little deviation, so that they could better claim to have 128/256 colors. And depending on into which direction this deviation was introduced, we either get are more green or red tint for hue 15. Which would explain the pretty different palettes existing.

 

Does that make sense?

 

In the Atari 2600 Field Service Manual there is a chapter (see page 3-9 or 35th page of the PDF) about setting the VCS colours properly. On the screen filled with horizontal colour bars, the lowest two bars are hue 1 and hue 15. It is said in this manual that the VCS is adjusted properly if these two colour bars are IDENTICAL! There is a potentiometer on the 2600 motherboard to adjust the colours. So we may accept is as verified, that while variations are common, it is intended that hue 1 = hue 15.

 

With the GTIA the situation is different. As far as I know, there is no such potentiometer on the 8bit's mainboard; moreso, the GTIA Technical Sheet explicitly defintes the timings which are used to generate colours, thus excluding the possibility of manually adjusting them. BUT, these GTIA timings introduce a slight variation between hues 1 and 15; computing the angles of hues in the YIQ colourspace shows that hues 1 and 15 are NOT equal. And indeed they aren't; Emkay has stated somewhere on these forums, that on XLs/XEs connected to a TV by S-Video the difference between hue 1 and 15 is noticeable.

Edited October 9, 2008 by Kr0tki

[Thomas Jentzsch]

So we may accept is as verified, that while variations are common, it is intended that hue 1 = hue 15.

But then, why does the Stella Programmer's Guide call hue 1 "gold" and hue 15 "light orange" if they are supposed to be the same?

 

The name for hue 15 indicates that it shouldn't have any green but some red tint instead.

[Kr0tki]

Sorry, I didn't know there was another official document contradicting this.

Edited October 9, 2008 by Kr0tki

[Thomas Jentzsch]

Sorry, I didn't know there was another official document contradicting this.

It's from 1979, written by Steve Wright and always worth a read.

[+Mitch]

Here's a 7800 screenshot from ProSystem using the latest palette update.

 

Mitch

[Thomas Jentzsch]

Here's a 7800 screenshot from ProSystem using the latest palette update.

Compared to other good(?) palettes hue 15 seems too much red. Even hue 14 isn't greenish anymore.

[Kr0tki]

It's from 1979, written by Steve Wright and always worth a read.

 

Yeah, I know, that's the guy who has made vertical scrolling in Championship Soccer, because he hadn't known that it was impossible on the VCS Seems the lack of knowledge is notorious for him - he also didn't know that his VCS was off-colour while writing the guide

[SeaGtGruff]

Here's the palette I cobbled together using Color Space, Color Pic, and Paint, displayed side-by-side with one of my 7800 screenshots. I flipped the cobbled-together palette around so the brightest values are alongside the brightest values of the 7800 screenshot:

Interesting. In your picture hue 15 is somewhere between hue 1 and 2. And hue 15 is even closer to yellow than hue 1. Other palettes show hue 15 somewhere between hue 14 and hue 1. Most games I know about use hue 1 for yellow, maybe because it is more predictable?

On every Atari 2600, XL, XE, and 7800 I've ever owned, hue 15 *always* had a greenish tinge to it, possibly somewhere between hue 14 and hue 1-- but it was also browner than hue 1, which seems to argue for being somewhere between hue 1 and hue 2. The nice thing about the idealized 27-step palette I put together is that hue 4 is closest to red, hue 8 is closest to blue, and hue 12 is almost a perfect green, which seems to fit what I've read about those hues. (I've always felt that hue 9 *looks* closer to pure blue than hue 8 does, but that's my subjective opinion.)

 

Hm...

 

Maybe supercat's theory is right. Atari set up the consoles so that hue 1 = hue 15. Maybe with the instruction of an intentional little deviation, so that they could better claim to have 128/256 colors. And depending on into which direction this deviation was introduced, we either get are more green or red tint for hue 15. Which would explain the pretty different palettes existing.

 

Does that make sense?

The problems I have with that theory are that (1) every Atari I've ever owned shows hue 15 *different* that hue 1, sort of a greenish brown-- kind of a "sickly" looking brown, really-- and (2) the field service manual describes a color bar test. I've never seen the color bar test in action, but the fact that there's such a thing at all seems to argue that there was a definite target palette that Atari was aiming for-- which doesn't mean that hue 15 must have been different than hue 1, but they were definitely different on every Atari I've ever owned.

 

What seems weird to me is that the GTIA information I posted last night indicates there are two or three step values-- about 27, 24, and 45(?) degrees-- depending on the voltage sent to the VDEL pin of the GTIA. The 27 step should produce the hues I posted last night-- *if* they start with hue 1 = colorburst-- but the 24 step should produce more of an ideal palette in the sense that the hues would be more evenly spaced around the color wheel with no overlap at the end.

 

Michael

[SeaGtGruff]

In the Atari 2600 Field Service Manual there is a chapter (see page 3-9 or 35th page of the PDF) about setting the VCS colours properly. On the screen filled with horizontal colour bars, the lowest two bars are hue 1 and hue 15. It is said in this manual that the VCS is adjusted properly if these two colour bars are IDENTICAL! There is a potentiometer on the 2600 motherboard to adjust the colours. So we may accept is as verified, that while variations are common, it is intended that hue 1 = hue 15.

I disagree. What it says is "R211 (R213 on the 2600A board) should be adjusted so the bars immediately above and below the reference line are within one shade of each other. Proper operation of the unit is indicated by being able to make this adjustment and by consistent color within the entire span of each bar on the screen. Minor glitches on the edges of the color bars are acceptable. Leave this test on for at least ten seconds in order to catch any intermittent problems, such as a bar momentarily changing colors or blanking out." It does *not* say to adjust R211/R213 so that the two lowest bars are "IDENTICAL." They should be "within one shade of each other"-- which I think implies, since it did *not* say "the same as each other," that they should be different, yet close to each other. It doesn't specifically say what "within one shade" means, but I take it to mean that the difference between those two bars should be *less* than the difference from one hue to the other for most of the other bars. And it also says thhere should be "consistent color within the entire span of each bar on the screen," so that's a *second* criterium that must also be met.

 

Michael

[Thomas Jentzsch]

It does *not* say to adjust R211/R213 so that the two lowest bars are "IDENTICAL." They should be "within one shade of each other"-- which I think implies, since it did *not* say "the same as each other," that they should be different, yet close to each other. It doesn't specifically say what "within one shade" means, but I take it to mean that the difference between those two bars should be *less* than the difference from one hue to the other for most of the other bars.

Interesting. That would explain why some consoles have a more greenish and some a more reddish tint for hue 15.

[Kr0tki]

I admit, I might have it misinterpreted.

 

So, the "right way" would be to actually emulate the R211/213 knob instead of creating a "perfect" palette, wouldn't it?

[Thomas Jentzsch]

So, the "right way" would be to actually emulate the R211/213 knob instead of creating a "perfect" palette, wouldn't it?

Good idea. Are there any other variables?

[Kr0tki]

I haven't found any other in the Field Service Manual. However TV set's brightness, contrast, colour saturation and hue controls are other variables I find significant. While not directly related to VCS, these controls would be mandatory if one wanted to adjust the emulator to "look exactly like the real thing".

Edited October 10, 2008 by Kr0tki

[Thomas Jentzsch]

I just read this interesting article about NTSC color generation.

 

It seems that due to technical limitations, the NTSC color generation is pretty complicated, e.g. with saturation limits for certain colors. Maybe someone with more understanding of the matter than me can have a look at it and tell me, if and how this might have influenced the Atari palette generation.

[SeaGtGruff]

I haven't found any other in the Field Service Manual. However TV set's brightness, contrast, colour saturation and hue controls are other variables I find significant. While not directly related to VCS, these controls would be mandatory if one wanted to adjust the emulator to "look exactly like the real thing".

I agree. Any palette on an emulator is going to be highly idealized, because of the way the NTSC signal naturally tends to produce slight color fluctuations ("Never The Same Color"), as well as the fact that the potentiometer or whatnot might be set differently from one console to the next, as well as the differences in the TV settings. I'm not worried too much about trying to emulate the TV's settings-- any decent computer monitor should have a way to adjust the RGB, brightness, and contrast. But adding a way to adjust the palette by emulating the turning of the potentiometer would be cool-- and I guees it would be nice to have a brightness and contrast to go with it, for adjusting the gray levels.

 

Michael

[Thomas Jentzsch]

-----------------------------------------------------
|TIA|Color Space|	   ColorPic		|   Paint   |
|---|-----------|-----------------------|-----------|
| H |Phase Angle| H | S | V | R | G | B | H | S | L |
|---|-----------|-----------|-----------|-----------|
|H01| + 033.000 |070,255,255|213,255,000|047,240,120|
|H02| + 060.000 |049,255,255|255,208,000|033,240,120|
|H03| + 087.000 |027,255,255|255,116,000|018,240,120|
|H04| + 114.000 |353,255,255|255,000,030|235,240,120|
|H05| + 141.000 |316,255,255|255,000,189|210,240,120|
|H06| + 168.000 |282,255,255|180,000,255|188,240,120|
|H07| - 165.000 |262,255,255|093,000,255|175,240,120|
|H08| - 138.000 |243,255,255|014,000,255|162,240,120|
|H09| - 111.000 |222,255,255|000,076,255|148,240,120|
|H10| - 084.000 |198,255,255|000,178,255|132,240,120|
|H11| - 057.000 |160,255,255|000,255,169|107,240,120|
|H12| - 030.000 |123,255,255|000,255,014|082,240,120|
|H13| - 003.000 |095,255,255|108,255,000|063,240,120|
|H14| + 024.000 |076,255,255|187,255,000|051,240,120|
|H15| + 051.000 |056,255,255|255,238,000|037,240,120|
-----------------------------------------------------

Can you explain how you get from phase angle to HSV, please? I found information how to translate HSV into RGB etc., but how the phase angle related to them is unclear.

[SeaGtGruff]

Can you explain how you get from phase angle to HSV, please? I found information how to translate HSV into RGB etc., but how the phase angle related to them is unclear.

Well, I didn't do it myself, but there are formulas to do it. I plugged the phase angle into the Color Space program, grabbed the screen and pasted it into Paint, removed everything except the line (or ray, or vector, whatever you want to call it) extending from the center of the color wheel/cube to its edge in the "9 o'clock" direction, stretched the line vertically 5 times 5 times 5 times (from 1 line tall to 125 lines tall), and used the ColorPic program to identify the outermost color's HSV and RGB values. Then I flipped the color wheel/cube over to look at it from the opposite side in Color Space (so the center is black instead of white), and repeated the process to get another line of the same hue, but this time ranging from the pure hue to black, instead of from the pure hue to white. Then I pasted the two lines end-to-end to get the final bar that goes from black to pure hue to white.

 

Also, I should warn you that my "phase" values aren't really YIQ phase values.

 

The NTSC signal uses-- or *originally* used-- the YIQ color space (I gather it now uses the YUV color space, but I'm not sure about that).

 

Let's start by looking at a vectorscope graticule:

 

(from http://en.wikipedia.org/wiki/Vectorscope)

 

Video technicians use this circular thingy with a color bar display to help them adjust a video monitor so the colors are correct-- basically, they try to get the lines to hit as close to the centers of the boxes for the different colors, as shown in the following picture:

 

(from http://www.tek.com/Measurement/App_Notes/N...ctorscope.html)

 

In the YIQ color space, the I axis measures an orangish-red component. Note how the I axis of the graticule runs from roughly the "11 o'clock" position to the "5 o'clock" position, where "11 o'clock" is between red and yellow, closer to red, and "5 o'clock"-- labeled "-I" to indicate that it's the negative side of the axis-- is between cyan and blue, closer to cyan.

 

On the other hand, the Q axis measures a purplish-blue component. Note how the Q axis runs from roughly "2 o'clock" to "8 o'clock," where "2 o'clock" is between blue and magenta, closer to magenta, and "8 o'clock" is between green and yellow, closer to green.

 

The graticule has tick marks around its edge, each tick marking 2 degrees. 0 degrees is at the "3 o'clock" position, 90 degrees is at the "12 o'clock" position, 180 degrees is at the "9 o'clock" position, and 270 degrees is at the "6 o'clock" position. These degrees aren't labeled as such, but we can see that this is where they are by considering that the different colors are said to have the following angles:

 

magenta =  60.7 degrees
red	 = 103.5 degrees
yellow  = 167.1 degrees
burst   = 180   degrees
green   = 240.7 degrees
cyan	= 283.5 degrees
blue	= 347.1 degrees

 

(from Digital Television Fundamentals By Michael Robin, Michel Poulin)

 

So the Q axis has its positive end at 33 degrees, and its negative end at 213 degrees; the I axis has its positive end at 123 degrees, and its negative end at 303 degrees; and colorburst is at 180 degrees.

 

Now let's look at the Color Space program and see how we can look at the YIQ color space. When we start up the Color Space program, we get this little window:

 

 

Click on the Color menu and select Color spaces:

 

 

This gives us another little window:

 

 

We click on the Color space dropdown box and select YIQ:

 

 

Then we click on the 3D visualization menu and select 3D color space:

 

 

This gives us yet another window:

 

 

This is what we want, but it doesn't look the way we want it to, so we need to adjust the view a bit. First we click on the Visualization menu and select Display axis to turn off the YIQ axes and the grid:

 

 

 

Then we make the color cube "solid" by clicking on the Visualization menu and selecting Colors properties:

 

 

That gives us another little window:

 

 

We click on RGB cube alpha and change it to 1.000 (which is as high as it will go):

 

 

Then we close that little window. Now the YIQ color cube is starting to look better:

 

 

Now we just need to orient it so it lines up with the graticule. To do this, we click on the Visualization menu and select Camera window:

 

 

This gives us the following little window, which we'll push to the side so it doesn't cover up any of the YIQ color cube:

 

 

First we click on Theta and change it to -90.000:

 

 

This changes the color cube as follows:

 

 

We also uncheck the Perspective box, to make the color cube "flat":

 

 

 

Now all we need to do is change the Phi setting to rotate the cube. If we set Phi to 33.000, it will rotate the Q axis to 33 degrees, making the color cube line up perfectly with the graticule:

 

 

 

 

So now colorburst is at the "9 o'clock" position, or 180 degrees. In my tables, I've called it "phase +33.000" because that's what we have to put in the Phi box to put the colorburst where it belongs. Thus, the values I've given in my tables are *not* the real phase angles of the different hues, but rather are the angles we must rotate the Q axis to for those hues to be positioned at "9 o'clock," if you follow me. We can get the actual phase angles by subtracting the Phi angle from 180, then adding 33 to the result-- or in other words, by subtracting the Phi angle from 213-- and normalizing the result to an angle between 0 and 360 (Color Space uses negative numbers for angles over 180, but it's more common to use positive angles):

 

-----------------------------------------------
|TIA|Color Space|							 |
|---|-----------|-----------------------------|
| H | Phi Angle |	Conversion	 |  Phase  |
|---|-----------|-------------------|---------|
|H01| + 033.000 | 213.000 - 033.000 | 180.000 |<-- 180.0 = colorburst
|H02| + 060.000 | 213.000 - 060.000 | 153.000 |
|H03| + 087.000 | 213.000 - 087.000 | 126.000 |
|H04| + 114.000 | 213.000 - 114.000 | 099.000 |<-- 103.5 = red
|H05| + 141.000 | 213.000 - 141.000 | 072.000 |<-- 060.7 = magenta
|H06| + 168.000 | 213.000 - 168.000 | 045.000 |
|H07| - 165.000 | 213.000 + 165.000 | 018.000 |
|H08| - 138.000 | 213.000 + 138.000 | 351.000 |<-- 347.1 = blue
|H09| - 111.000 | 213.000 + 111.000 | 324.000 |
|H10| - 084.000 | 213.000 + 084.000 | 297.000 |<-- 283.5 = cyan
|H11| - 057.000 | 213.000 + 057.000 | 270.000 |
|H12| - 030.000 | 213.000 + 030.000 | 243.000 |<-- 240.7 = green
|H13| - 003.000 | 213.000 + 003.000 | 216.000 |
|H14| + 024.000 | 213.000 - 024.000 | 189.000 |
|H15| + 051.000 | 213.000 - 051.000 | 162.000 |<-- 167.1 = yellow
-----------------------------------------------

Remember, the above table is based on two assumptions: (1) that hue 1 is equal to colorburst, and (2) that the phase step between each hue is exactly 27 degrees. In the screens I captured from my 7800, hue 1 wasn't exactly equal to colorburst, so assumption #1 may be faulty, although it does conform to what's been stated in the documentation for the Atari's colors. And the assumption that the phase step is equal to exactly 27 degrees is just an approximation obtained from the ns delay values that have been documented for the GTIA chip. If we can modify the phase step by fiddling with the potentiometer, then all bets are off.

 

My own feeling is that-- ideally speaking-- hue 4 should be the closest to pure red, hue 8 should be the closest to pure blue, and hue 12 should be the closest to pure green. That would mean that hue 4 is ideally equal to 103.5, hue 8 is ideally equal to 347.1, and hue 12 is ideally equal to 240.7, with hue 1 presumably being equal to 180 (colorburst):

 

hue 01 = 180.0

hue 04 = 103.5

hue 08 = 347.1

hue 12 = 240.7

 

hue 04 - hue 01 = 103.5 - 180.0 = 283.5

360.0 - 283.5 = -076.5

-076.5 / 03 = -25.5 ideal phase step to make hue 4 pure red

 

hue 08 - hue 01 = 347.1 - 180.0 = 167.1

360.0 - 167.1 = -192.9

-192.9 / 07 = -27.5571428_571428 ideal phase step to make hue 8 pure blue

 

hue 12 - hue 01 = 240.7 - 180.0 = 060.7

360.0 - 060.7 = -299.3

-299.3 / 11 = -27.209_09 ideal phase step to make hue 12 pure green

 

The average of these three ideal phase steps is -26.7554112_554112. But if we want the average of the variations for hues 4, 8, and 12 to be 0, then the ideal phase step would be -27.0809523_809523:

 

H04_diff = 180 - 3 * Step - 103.5 = 76.5 - 3 * Step

H08_diff = 180 - 7 * Step - 347.1 = 192.9 - 7 * Step

H12_diff = 180 - 11 * Step - 240.7 = 299.3 - 11 * Step

 

H04_diff + H08_diff + H12_diff = 0

76.5 - 3 * Step + 192.9 - 7 * Step + 299.3 - 11 * Step = 0

568.7 - 21 * Step = 0

21 * Step = 568.7

Step = 27.0809523_809523

 

That would give us the following phase angles. (To convert these to Phi values for Color Space, subtract them from 213.)

 

H01 = 180.000 <-- 180.0 = colorburst

H02 = 152.919

H03 = 125.838

H04 = 098.757 <-- 103.5 = red (off by -4.743)

H05 = 071.676 <-- 060.7 = magenta

H06 = 044.595

H07 = 017.514

H08 = 350.433 <-- 347.1 = blue (off by 3.333)

H09 = 323.352

H10 = 296.271

H11 = 269.190 <-- 283.5 = cyan

H12 = 242.110 <-- 240.7 = green (off by 1.41)

H13 = 215.029

H14 = 187.948

H15 = 160.867 <-- 167.1 = yellow

 

-4.743 + 3.333 + 1.41 = 0

 

What's interesting is that if we divide this ideal step by 360, then multiply it by the ns length of the NTSC color subcarrier cycle, we get 21.015201142185269169396153523138 ns-- remarkably close to the 21 ns step in the delay values for the GTIA chip. This puts hue 4 a tad toward magenta, and puts hue 15 close to yellow but on the orange side.

 

Anyway, we can convert from the YIQ color space to the RGB color space, or from YIQ to YUV, or YUV to RGB, or YIQ to HSL, etc., using formulas that can be found on the internet. I didn't want to try to tackle those formulas, so I just used Color Space to rotate the color cube-- plus, that made it easy to grab a horizontal line from the color cube so I could see what the colors for the different angles look like.

 

If you try to use a formula to convert the "ideal" phase angles given above to their RGB equivalents, you might need to use YUV to RGB rather than YIQ to RGB, since the phase angles are actually based on the YUV axes (because the YIQ axes are rotated 33 degrees counterclockwise from the graticule angles, whereas the graticule angles are lined up with the YUV axes). Also, you can't convert an angle directly to an RGB value, because the angle is a vector consisting of many points, and you'd need to pick one specific point before you could convert it to an RGB value. I used the point at the end of the vector, or at the outermost edge of the color cube, which has a pure hue. Other points along the same vector would have different RGB values. Basically, you'd need to use some kind of trigonometric functions to convert a point on the vector to its equivalent YUV (or YIQ) grid coordinates, then you could convert the YUV (or YIQ) grid coordinates to RGB values.

 

All of this tends to make my head hurt, which is why I prefer to just use the Color Space program.

 

Michael

[Thomas Jentzsch]

Thanks Martin for your explaination. Even though I can only partially follow your explainations, I think I finally understood and found a way for palette calculation myself now.

 

I am using the YIQ format which is (or was) the base for NTSC. Here we also have a phase angle, which defines the values for I and Q. Y is the luminance.

 

Based on a initial angle of ~150° (found by experimenting) for hue 1 and steps of -27°, I get a palette with colors very close to the one you described.

 

The biggest problem left is the range for Y, which is defined as [0..1]. While colors look different with lower values, with higher values, the resulting RGB values tend to become saturated more and more. This results into bright colors where especially blue isn't clearly seperated anymore. I suppose there has to be given a limit. Also my palette is showing much less washed out bright colors than other palettes.

| H|  R   G   B|  R   G   B|  R   G   B|  R   G   B|  R   G   B|  R   G   B|  R   G   B|  R   G   B|
|--+-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+
| 1|  9  50   0| 46  86   0| 82 123   0|119 159   0|156 196   0|192 232   0|229 255   0|255 255   0|
| 2| 84   7   0|121  43   0|157  80   0|194 117   0|231 153   0|255 190   0|255 226   0|255 255   0|
| 3|141   0   0|177   0   0|214  36   0|251  72   0|255 109   0|255 145   2|255 182  38|255 219  75|
| 4|167   0   0|203   0   0|240   0  11|255  36  48|255  73  84|255 109 121|255 146 157|255 182 194|
| 5|156   0  70|192   0 107|229   0 144|255  16 180|255  52 217|255  89 253|255 126 255|255 162 255|
| 6|111   0 187|148   0 224|184   0 255|221  16 255|255  52 255|255  89 255|255 126 255|255 162 255|
| 7| 42   0 255| 79   0 255|115   0 255|152  36 255|188  73 255|225 109 255|255 146 255|255 183 255|
| 8|  0   0 255|  0   0 255| 37  36 255| 73  73 255|110 109 255|147 146 255|183 182 255|220 219 255|
| 9|  0   7 239|  0  44 255|  0  80 255|  3 117 255| 39 153 255| 76 190 255|113 227 255|149 255 255|
|10|  0  50 144|  0  86 180|  0 123 217|  0 160 253|  0 196 255| 29 233 255| 65 255 255|102 255 255|
|11|  0  81  17|  0 118  53|  0 155  90|  0 191 127|  0 228 163| 15 255 200| 51 255 236| 88 255 255|
|12|  0  95   0|  0 132   0|  0 168   0|  0 205   0|  1 242  33| 37 255  69| 74 255 106|111 255 142|
|13|  0  88   0|  0 125   0|  0 161   0| 19 198   0| 55 234   0| 92 255   0|128 255   0|165 255  37|
|14|  0  62   0| 19  98   0| 56 135   0| 93 171   0|129 208   0|166 245   0|202 255   0|239 255   0|
|15| 61  22   0| 97  58   0|134  95   0|170 131   0|207 168   0|243 205   0|255 241   0|255 255   0|

Check the last columns.

 

So obviously it takes more than just simple YIQ calculation to get a good palette.

Edited October 11, 2008 by Thomas Jentzsch

[SeaGtGruff]

So obviously it takes more than just simple YIQ calculation to get a good palette.

Yes, the hue is only part of the picture-- only one-third of the HSV or HSL description.

 

Michael

[Thomas Jentzsch]

Yes, the hue is only part of the picture-- only one-third of the HSV or HSL description.

I had hoped for 50% regarding the 2600?

[+grafixbmp]

I haven't read every posting on this topic but one thing I found out long ago is that there is no true conversion from the way TV's present color on the screen to the ways computers deal with color. TV systems and photography deal with the Y Cr Cb form of color and with computers they are RGB. When converting from Y Cr Cb to RGB some of the color is lost. The range for the first is larger than the RGB system. The wiki has the equasions which many of you know already. This info might help some pr may just be repeats of what you guys already know.

 

http://en.wikipedia.org/wiki/YCbCr

 

I read through some of the post and with regards to the YUV, this is similar but not exact to the way a TV phisicaly creates it's color. YUV is the human preception of the color with a bit more simplification.

 

In order to get the true setings of an actual TV I would recomend using the Y Cr Cb color space as this is the traditional standard or Y Pr Pb for analog broadcasting. Both of these are technicaly the same.

Edited October 11, 2008 by grafixbmp

[supercat]

Hasn't supercat (or?) posted several times that, since getting 24 degree spacing exactly is hard and requires special equipment, that mostly they adjusted the pot so that 15==1? Or some such?

 

I believe my suggestion was that to allow easy calibration, one should display a rainbow of colors $Ex $Fx $1x $2x and try to adjust so that the gap between $Fx and $1x seemed to match the others.

 

The color generator in the TIA is a sequence of logic gates that are designed to operate fairly slowly. The chroma oscillator drives the first one, which drives the second, which drives the third, etc. The speed at which the gates operate can be altered by changing a biasing voltage which is controlled by the pot. So the effect of the pot is to increase or decrease the difference between the 15 color phases.

[SeaGtGruff]

Hasn't supercat (or?) posted several times that, since getting 24 degree spacing exactly is hard and requires special equipment, that mostly they adjusted the pot so that 15==1? Or some such?

 

I believe my suggestion was that to allow easy calibration, one should display a rainbow of colors $Ex $Fx $1x $2x and try to adjust so that the gap between $Fx and $1x seemed to match the others.

 

The color generator in the TIA is a sequence of logic gates that are designed to operate fairly slowly. The chroma oscillator drives the first one, which drives the second, which drives the third, etc. The speed at which the gates operate can be altered by changing a biasing voltage which is controlled by the pot. So the effect of the pot is to increase or decrease the difference between the 15 color phases.

What I'd like to understand now is how the luminance works. I think I saw some information about it in either the Stella list from years ago, or a post here in AtariAge from Curt Vendl about a year ago-- but so far I haven't been able to figure out what all the numbers meant.

 

Michael

[Kr0tki]

The biggest problem left is the range for Y, which is defined as [0..1]. While colors look different with lower values, with higher values, the resulting RGB values tend to become saturated more and more. This results into bright colors where especially blue isn't clearly seperated anymore. I suppose there has to be given a limit. Also my palette is showing much less washed out bright colors than other palettes.

| H|  R   G   B|  R   G   B|  R   G   B|  R   G   B|  R   G   B|  R   G   B|  R   G   B|  R   G   B|
|--+-----------+-----------+-----------+-----------+-----------+-----------+-----------+-----------+
| 1|  9  50   0| 46  86   0| 82 123   0|119 159   0|156 196   0|192 232   0|229 255   0|255 255   0|
| 2| 84   7   0|121  43   0|157  80   0|194 117   0|231 153   0|255 190   0|255 226   0|255 255   0|
| 3|141   0   0|177   0   0|214  36   0|251  72   0|255 109   0|255 145   2|255 182  38|255 219  75|
| 4|167   0   0|203   0   0|240   0  11|255  36  48|255  73  84|255 109 121|255 146 157|255 182 194|
| 5|156   0  70|192   0 107|229   0 144|255  16 180|255  52 217|255  89 253|255 126 255|255 162 255|
| 6|111   0 187|148   0 224|184   0 255|221  16 255|255  52 255|255  89 255|255 126 255|255 162 255|
| 7| 42   0 255| 79   0 255|115   0 255|152  36 255|188  73 255|225 109 255|255 146 255|255 183 255|
| 8|  0   0 255|  0   0 255| 37  36 255| 73  73 255|110 109 255|147 146 255|183 182 255|220 219 255|
| 9|  0   7 239|  0  44 255|  0  80 255|  3 117 255| 39 153 255| 76 190 255|113 227 255|149 255 255|
|10|  0  50 144|  0  86 180|  0 123 217|  0 160 253|  0 196 255| 29 233 255| 65 255 255|102 255 255|
|11|  0  81  17|  0 118  53|  0 155  90|  0 191 127|  0 228 163| 15 255 200| 51 255 236| 88 255 255|
|12|  0  95   0|  0 132   0|  0 168   0|  0 205   0|  1 242  33| 37 255  69| 74 255 106|111 255 142|
|13|  0  88   0|  0 125   0|  0 161   0| 19 198   0| 55 234   0| 92 255   0|128 255   0|165 255  37|
|14|  0  62   0| 19  98   0| 56 135   0| 93 171   0|129 208   0|166 245   0|202 255   0|239 255   0|
|15| 61  22   0| 97  58   0|134  95   0|170 131   0|207 168   0|243 205   0|255 241   0|255 255   0|

Check the last columns.

 

So obviously it takes more than just simple YIQ calculation to get a good palette.

Your palette is actually fine. Atari would generate palette similar to yours with the TV set's saturation turned to the maximum. Take the saturation variable into consideration while computing.