Jump to content

Photo

Need the 256 colors!


58 replies to this topic

#26 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Fri Jun 1, 2007 6:06 PM

Hi Rybags! Could it be possible to print this screen without the black bars? That should help do a 1 on 1 comparison with my palette and SeaGtGruff's.


You can try this program if you want... sorry, you'll have to type it in (but it's short), or maybe you can import it into an emulator as a "list" file from your hard drive:

10 REM * DISPLAY ALL 256 COLORS
11 GRAPHICS 9:FOR V=0 TO 15:COLOR V
12 FOR N=0 TO 4:PLOT 5*V+N,0
13 DRAWTO 5*V+N,191:NEXT N:NEXT V
14 D=256*PEEK(561)+PEEK(560)
15 FOR N=1 TO 16:READ V:POKE D+V,143
16 NEXT N:FOR N=0 TO 25:READ V
17 POKE 1664+N,V:NEXT N:POKE 512,139
18 POKE 513,6:POKE 546,128:POKE 547,6
19 POKE 53248,40:POKE 53249,208
20 POKE 53261,255:POKE 53262,255
21 POKE 53266,0:POKE 53267,0
22 POKE 54286,192
23 GOTO 23
24 DATA 16,28,40,52,64,76,88,102,114
25 DATA 126,138,150,162,174,186,198
26 DATA 8,72,169,0,133,203,104,40,76
27 DATA 95,228,8,72,165,203,24,105,16
28 DATA 141,26,208,133,203,104,40,64

By the way, I don't think I set the vertical blank vector using the "proper method" in this version of the program, so it will more often than not run correctly, but once in a while it starts up kind of funky if the VBV gets set during the VBI or something like that.

Also, here is a thread where we were talking about the colors a while back:

http://www.atariage....s...st&p=956481

And here are some screenshots of other people's Ataris running my little program, from that thread:

PAL http://www.atariage....s...st&p=956712

PAL.png

NTSC http://www.atariage....s...st&p=956766

NTSC.png

BTW, SeaGtGruff, your Atari is an NTSC?


Yes, it is. :)

Michael

#27 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,230 posts
  • Location:Australia

Posted Fri Jun 1, 2007 7:53 PM

With the program I supplied, make the following changes to have no gaps between the colour bars:

Line 60 change "TO X+3" to "TO X+4"
Line 140 change "POKE 53249,206" to "POKE 53249,208"
and remove line 150.

Edited by Rybags, Fri Jun 1, 2007 7:53 PM.


#28 _33 OFFLINE  

_33

    Space Invader

  • Topic Starter
  • 14 posts

Posted Fri Jun 1, 2007 10:36 PM

When you look at how the NTSC signal demultiplies the red/green/blue as it goes further in the bright areas, it's no wonder that the ATARI palette is so hard to emulate and that the emulator boys just make their own riced/tweaked/pimped color sets. It's as if you can actually wheel down the values in 360° and see how the canon spreads the colors around. You'd need a heavily complex HSL routine that works with SIN / COS / ATAN to be able to properly give the right RGB of those. Otherwise it's just gonna look too linear, like mine.

BTW SeaGtGruff, is it possible that within your screen capture, that it shows you're ATARI gives a small angles in the colors, probably aroud 25° or so? I've read that on the NTSC it is normal, but can't be sure. It's not hard to do in programming, but I don't know if I should worry about that. Basically the way they explained it, is that as further you go in the palette, the hue chooser moves slightly to position itself for the next 16 color cycle. So in essence, you'd have an angle of about 25-27°, if I understand properly. Also I've noticed that yours has a step of about 25.5° per hue, instead of the 27° or so that some others suggest.

The PAL ones don't seem to have these issues...(? from screenshots anyway.)

Edited by _33, Fri Jun 1, 2007 10:46 PM.


#29 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Fri Jun 1, 2007 11:28 PM

When you look at how the NTSC signal demultiplies the red/green/blue as it goes further in the bright areas, it's no wonder that the ATARI palette is so hard to emulate and that the emulator boys just make their own riced/tweaked/pimped color sets. It's as if you can actually wheel down the values in 360° and see how the canon spreads the colors around. You'd need a heavily complex HSL routine that works with SIN / COS / ATAN to be able to properly give the right RGB of those. Otherwise it's just gonna look too linear, like mine.


I know that when you look at certain colors (hues) in the Atari's palette, it looks like their tint changes slightly as their brightness or luminance changes, which looks like it must be incorrect. For example, hue 8 (NTSC) starts out at luminance 0 looking like a rich, deep blue, but as the luminance goes up you start seeing tinges of deep purple in it. Yet when you look at the NTSC/YIQ color cube, you can actually see that this is correct.

I think that where emulator programmers and palette pimpers (thanks for giving me that term!) go astray is by trying to determine a linear type of RGB formula for the gradients between the hues and luminances, as you suggested. The only way to match the colors accurately is to duplicate the manner in which the real hardware generates the hues-- by shifting the phase around a color wheel. As you say, this will require using trigonometric functions, but it will also require keeping the shape of the color space in mind-- it isn't circular, but looks like a mutated hexagon, or a block (not really a "cube" as it's called) seen from an angle.

BTW SeaGtGruff, is it possible that within your screen capture, that it shows you're ATARI gives a small angles in the colors, probably aroud 25° or so? I've read that on the NTSC it is normal, but can't be sure. It's not hard to do in programming, but I don't know if I should worry about that. Basically the way they explained it, is that as further you go in the palette, the hue chooser moves slightly to position itself for the next 16 color cycle. So in essence, you'd have an angle of about 25-27°, if I understand properly. Also I've noticed that yours has a step of about 25.5° per hue, instead of the 27° or so that some others suggest.


I was trying to figure out the angle the other night, and it does look close to about 25.5 degrees-- but it's kind of hard to say, especially if people start tinkering with the potentiometer to adjust the colors. I'll post an explanation of how I've tried to reconcile the timing values, as given on certain web pages, with the corresponding phase shift angles, because I think it's pretty interesting.

The PAL ones don't seem to have these issues...(? from screenshots anyway.)


I think the video capture that I posted from my NTSC Atari, and the one Allas posted from his NTSC Atari (with the "factory settings," before he tinkered with the potentiometer), actually look very similar to each other, aside from the fact that I had adjusted the brightness and contrast on my Snappy to try to get a better gradient for the luminances. Likewise, the captures that have been posted from PAL Ataris also look pretty consistent with each other. The NTSC and PAL captures look distinctly different from each other-- but then, NTSC colorburst and PAL colorburst are different from each other, so if the palette starts at the colorburst phase angle (for hue 1), and then steps around the "wheel" by a certain number of degrees per hue, then we should expect to see differences.

Michael

#30 Olivier Galibert OFFLINE  

Olivier Galibert

    Combat Commando

  • 3 posts

Posted Sun Jun 10, 2007 6:37 PM

Measuring on the first NTSC screenshot of the thread, there is a 25deg step for every color starting at -58. Interestingly enough, -58+25=-33, which is the colorburst angle iirc.

8bits-value to rgb conversion:
[codebox]void gtia_ntsc_to_rgb(u8 val, u8 *rr, u8 *gg, u8 *bb)
{
int cr = (val >> 4) & 15;
int lm = val & 15;
int crlv = cr ? 50 : 0;

double phase = ((cr-1)*25 - 58) * (2 * M_PI / 360);

double y = 255*(lm+1)/16;
double i = crlv*cos(phase);
double q = crlv*sin(phase);

double r = y + 0.956*i + 0.621*q;
double g = y - 0.272*i - 0.647*q;
double b = y - 1.107*i + 1.704*q;

*rr = clamp( r);
*gg = clamp(g);
*bb = clamp(b);
}
[/codebox]

gtia_ntsc.png

#31 Olivier Galibert OFFLINE  

Olivier Galibert

    Combat Commando

  • 3 posts

Posted Sun Jun 10, 2007 6:46 PM

On the PAL one, it's 25.7deg (360/14) starting at -15.

[codebox]void gtia_pal_to_rgb(u8 val, u8 *rr, u8 *gg, u8 *bb)
{
int cr = (val >> 4) & 15;
int lm = val & 15;
int crlv = cr ? 50 : 0;

double phase = ((cr-1)*25.7 - 15) * (2 * M_PI / 360);

double y = 255*(lm+1)/16;
double i = crlv*cos(phase);
double q = crlv*sin(phase);

double r = y + 0.956*i + 0.621*q;
double g = y - 0.272*i - 0.647*q;
double b = y - 1.107*i + 1.704*q;

*rr = clamp( r);
*gg = clamp(g);
*bb = clamp(b);
}
[/codebox]

gtia_pal.png

#32 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Mon Jun 11, 2007 10:14 PM

Thank you for those screenshots and formulas! :)

Michael

#33 Allas OFFLINE  

Allas

    Stargunner

  • 1,103 posts
  • Location:Lima - Perú

Posted Wed Jun 13, 2007 9:37 AM

Thanks for the formulas.

I see its a little hard to reverse the formula. I think a formulas type: rgb_to_gtia_ntsc() and rgb_to_gtia_pal() is necessary.

What means M_PI in the formula?

Edited by Allas, Wed Jun 13, 2007 9:50 AM.


#34 pps OFFLINE  

pps

    Dragonstomper

  • 771 posts
  • Location:Berlin, Germany

Posted Thu Jun 14, 2007 12:15 PM

Thanks for the formulas.

I see its a little hard to reverse the formula. I think a formulas type: rgb_to_gtia_ntsc() and rgb_to_gtia_pal() is necessary.

What means M_PI in the formula?



what about mathematics pi also known as 'Kreiszahl' (circle number).

#35 Allas OFFLINE  

Allas

    Stargunner

  • 1,103 posts
  • Location:Lima - Perú

Posted Fri Jun 15, 2007 5:44 AM

Thanks for the formulas.

I see its a little hard to reverse the formula. I think a formulas type: rgb_to_gtia_ntsc() and rgb_to_gtia_pal() is necessary.

What means M_PI in the formula?



what about mathematics pi also known as 'Kreiszahl' (circle number).


A simple PI 3.1416 ???

#36 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Fri Jun 15, 2007 6:43 AM

A simple PI 3.1416 ???

Yes, it's just a variable that is set to the value of pi. Typically, any formula working with degrees of the circle and involving trigonometric functions will need to have pi in it somewhere, so it's common to define a variable or constant for the value of pi-- to the highest degree of precision that is allowed-- since it's more convenient to just say "pi" throughout the program than to have to type out a long string of digits each time. :)

Michael

#37 Olivier Galibert OFFLINE  

Olivier Galibert

    Combat Commando

  • 3 posts

Posted Wed Jun 20, 2007 4:24 AM

I see its a little hard to reverse the formula. I think a formulas type: rgb_to_gtia_ntsc() and rgb_to_gtia_pal() is necessary.


You can't reverse the formula mathematically since it goes from two dimensions to three. You have to make an approximation, and for that I suspect the best way is simply to precompute the 256 colors and then pick up the "nearest" one, according to whichever distance formula you want. That even allows you to do error propagation if you try to convert images instead of single colors.

#38 Allas OFFLINE  

Allas

    Stargunner

  • 1,103 posts
  • Location:Lima - Perú

Posted Wed Jun 20, 2007 9:31 AM

Yes, just I'll try to do a example in this way.

Edited by Allas, Wed Jun 20, 2007 9:32 AM.


#39 _33 OFFLINE  

_33

    Space Invader

  • Topic Starter
  • 14 posts

Posted Thu Jun 21, 2007 3:57 PM

Cheers to Oliver Galibert! Great work right here finding an algorythm to determine the ATARI colors!

Measuring on the first NTSC screenshot of the thread, there is a 25deg step for every color starting at -58. Interestingly enough, -58+25=-33, which is the colorburst angle iirc.

8bits-value to rgb conversion:

void gtia_ntsc_to_rgb(u8 val, u8 *rr, u8 *gg, u8 *bb){  int cr = (val >> 4) & 15;  int lm = val & 15;  int crlv = cr ? 50 : 0;    double phase = ((cr-1)*25 - 58) * (2 * M_PI / 360);  double y = 255*(lm+1)/16;  double i = crlv*cos(phase);  double q = crlv*sin(phase);  double r = y + 0.956*i + 0.621*q;  double g = y - 0.272*i - 0.647*q;  double b = y - 1.107*i + 1.704*q;  *rr = clamp( r);  *gg = clamp(g);  *bb = clamp(b);}

gtia_ntsc.png



What I find funny thoe, is that on the TIA emulation over at MAME/MESS, I don't know if it's M. Galibert that modified the code and created a monolitic TIA driver:
PALETTE_INIT( tia_NTSC ){	int i, j;	static const double color[16][2] =	{		{  0.000,  0.000 },		{  0.144, -0.189 },		{  0.231, -0.081 },		{  0.243,  0.032 },		{  0.217,  0.121 },		{  0.117,  0.216 },		{  0.021,  0.233 },		{ -0.066,  0.196 },		{ -0.139,  0.134 },		{ -0.182,  0.062 },		{ -0.175, -0.022 },		{ -0.136, -0.100 },		{ -0.069, -0.150 },		{  0.005, -0.159 },		{  0.071, -0.125 },		{  0.124, -0.089 }	};	for (i = 0; i < 16; i++)	{		double I = color[i][0];		double Q = color[i][1];		for (j = 0; j < 8; j++)		{			double Y = j / 7.0;			double R = Y + 0.956 * I + 0.621 * Q;			double G = Y - 0.272 * I - 0.647 * Q;			double B = Y - 1.106 * I + 1.703 * Q;			R = pow(R, 0.9) / pow(1, 0.9);			G = pow(G, 0.9) / pow(1, 0.9);			B = pow(B, 0.9) / pow(1, 0.9);			if (R < 0) R = 0;			if (G < 0) G = 0;			if (B < 0) B = 0;			if (R > 1) R = 1;			if (G > 1) G = 1;			if (B > 1) B = 1;			palette_set_color_rgb(machine,8 * i + j,				(UINT8) (255 * R + 0.5),				(UINT8) (255 * G + 0.5),				(UINT8) (255 * B + 0.5));		}	}}

As you see, this doesn't use any SIN / COS nor the PI value. A much simpler version in fact for calculating the ATARI colors.

EDIT: I've found that the code in the MESS emulator generates exactly the same table as it has been posted here. The previous code doesn't work for me.

Edited by _33, Thu Jun 21, 2007 7:49 PM.


#40 Wilbert OFFLINE  

Wilbert

    Space Invader

  • 12 posts

Posted Sun Jun 24, 2007 4:18 AM

PALETTE_INIT( tia_NTSC ){	int i, j;	static const double color[16][2] =	{		{  0.000,  0.000 },		{  0.144, -0.189 },		{  0.231, -0.081 },		{  0.243,  0.032 },		{  0.217,  0.121 },		{  0.117,  0.216 },		{  0.021,  0.233 },		{ -0.066,  0.196 },		{ -0.139,  0.134 },		{ -0.182,  0.062 },		{ -0.175, -0.022 },		{ -0.136, -0.100 },		{ -0.069, -0.150 },		{  0.005, -0.159 },		{  0.071, -0.125 },		{  0.124, -0.089 }	};	for (i = 0; i < 16; i++)	{		double I = color[i][0];		double Q = color[i][1];		for (j = 0; j < 8; j++)		{			double Y = ( j + 1 ) / 15.0;			double R = Y + 0.956 * I + 0.621 * Q;			double G = Y - 0.272 * I - 0.647 * Q;			double B = Y - 1.106 * I + 1.703 * Q;			if (R < 0) R = 0;			if (G < 0) G = 0;			if (B < 0) B = 0;			if (R > 1) R = 1;			if (G > 1) G = 1;			if (B > 1) B = 1;			palette_set_color_rgb(machine,8 * i + j,				(UINT8) (255 * R + 0.5),				(UINT8) (255 * G + 0.5),				(UINT8) (255 * B + 0.5));		}	}}

What about this?

It makes the colors less vibrant and has a bit of a 'tv feel' to it. I don't know how close it is to the real thing though, because I don't have an NTSC unit.

The same kind of change can be applied to the PALETTE_INIT( tia_PAL ) function too.

#41 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,230 posts
  • Location:Australia

Posted Sun Jun 24, 2007 4:59 AM

Has anyone generated a "reverse lookup" yet to translate RGB to Atari H/L values?

Really, only 9 bits of RGB info would be needed, but it would probably need some trial and error to decide whether to truncate or round to reduce the RGB to 9 bits.

#42 _33 OFFLINE  

_33

    Space Invader

  • Topic Starter
  • 14 posts

Posted Sun Jun 24, 2007 1:52 PM

What about this?

It makes the colors less vibrant and has a bit of a 'tv feel' to it. I don't know how close it is to the real thing though, because I don't have an NTSC unit.

The same kind of change can be applied to the PALETTE_INIT( tia_PAL ) function too.


I like that, with this little touch, it seems to lift the bottom colors up a bit and add an extra curve in the lum that I feel it reflects more the real machine:
R = pow(R, 0.9);
			G = pow(G, 0.9);
			B = pow(B, 0.9);

Edited by _33, Sun Jun 24, 2007 1:54 PM.


#43 Wrathchild OFFLINE  

Wrathchild

    Stargunner

  • 1,876 posts
  • Location:Reading, UK.

Posted Tue Jun 26, 2007 5:22 AM

Has anyone generated a "reverse lookup" yet to translate RGB to Atari H/L values?

Indeed, the code can be cut and paste from this thread:
http://www.atariage....s...&hl=palette
I think it can be easily tweaked for adjusted palettes.

#44 pps OFFLINE  

pps

    Dragonstomper

  • 771 posts
  • Location:Berlin, Germany

Posted Fri Jun 29, 2007 3:19 AM

Can anyone help me please?

Since the colors seem to differ a lot between pal & ntsc I try to recognize on which machine my programme runs.

I want to have the lower line to become a status bar. So when there´re no more moves it shold turn to red. Normaly it should be green.

I have two versions attached, where the bar shold have the color.

Since I have no real ntsc machine I can´t test if they´re correct. Please tell me, if so.

Attached Files



#45 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,230 posts
  • Location:Australia

Posted Fri Jun 29, 2007 4:42 AM

Colour 3 is really your only hope.

Lots of programs (e.g. Star Raiders) use Colour 4 for red, which in my experience is always more violet/purple on PAL systems.

For greens/blues, I think both are fairly similar.

Most of the differences are with Colours 1 and 4, although someone might have better info than that.

#46 pps OFFLINE  

pps

    Dragonstomper

  • 771 posts
  • Location:Berlin, Germany

Posted Fri Jun 29, 2007 5:22 AM

Actually I use these colors:

PAL:

32 for red
192 for green

NTSC:

80 for red
240 for green

This is based on the tables shown here.

#47 xulchris OFFLINE  

xulchris

    Stargunner

  • 1,029 posts
  • Location:Area 51

Posted Fri Jun 29, 2007 6:59 AM

I'm able to get nearly perfect colors with the Atari 2600 using MESS' current algorithm and the following modification to luma:

double Y = (j-0.5) / 8.0;


#48 pseudografx OFFLINE  

pseudografx

    Dragonstomper

  • 601 posts
  • Location:Czech Republic

Posted Mon Oct 8, 2007 6:30 AM

On the PAL one, it's 25.7deg (360/14) starting at -15.

void gtia_pal_to_rgb(u8 val, u8 *rr, u8 *gg, u8 *bb){  int cr = (val >> 4) & 15;  int lm = val & 15;  int crlv = cr ? 50 : 0;    double phase = ((cr-1)*25.7 - 15) * (2 * M_PI / 360);  double y = 255*(lm+1)/16;  double i = crlv*cos(phase);  double q = crlv*sin(phase);  double r = y + 0.956*i + 0.621*q;  double g = y - 0.272*i - 0.647*q;  double b = y - 1.107*i + 1.704*q;  *rr = clamp( r);  *gg = clamp(g);  *bb = clamp(b);}

gtia_pal.png

In case anyone is interested, here is a palette file made from the above formula for the Atari800WinPlus emulator. I will do the NTSC version as well as soon as I find some time.

Attached File  OlivierPAL.zip   890bytes   183 downloads

#49 dwhyte OFFLINE  

dwhyte

    Dragonstomper

  • 863 posts
  • Location:Canada

Posted Mon Oct 15, 2007 2:15 AM

Why not try using "Two Fifty-Six" to help you out. It was a basic program released in A.N.T.I.C. Magazine back-in-the-day... I still use this program to help me pick out color values for my A8 stuff...

"Two Fifty-Six" via Gury's site

Posted Image

Edited by dwhyte, Mon Oct 15, 2007 2:17 AM.


#50 pseudografx OFFLINE  

pseudografx

    Dragonstomper

  • 601 posts
  • Location:Czech Republic

Posted Mon Oct 15, 2007 1:36 PM

Why not try using "Two Fifty-Six" to help you out. It was a basic program released in A.N.T.I.C. Magazine back-in-the-day... I still use this program to help me pick out color values for my A8 stuff...

"Two Fifty-Six" via Gury's site

Posted Image

Thanks, but I have my own procedure using a 256 colour screenshot and some Paint Shop Pro magic :-)
Btw. regarding the emulator palette, I'm currently using this new one but since the colours are a bit washed-out to my liking I move the saturation slider in the palette options a bit up (value 140).




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users