SeaGtGruff Posted June 2, 2007 Share Posted June 2, 2007 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.com/forums/index.php?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.com/forums/index.php?s...st&p=956712 NTSC http://www.atariage.com/forums/index.php?s...st&p=956766 BTW, SeaGtGruff, your Atari is an NTSC? Yes, it is. Michael Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 2, 2007 Share Posted June 2, 2007 (edited) 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 June 2, 2007 by Rybags Quote Link to comment Share on other sites More sharing options...
_33 Posted June 2, 2007 Author Share Posted June 2, 2007 (edited) 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 June 2, 2007 by _33 Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted June 2, 2007 Share Posted June 2, 2007 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 Quote Link to comment Share on other sites More sharing options...
Olivier Galibert Posted June 11, 2007 Share Posted June 11, 2007 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); } Quote Link to comment Share on other sites More sharing options...
Olivier Galibert Posted June 11, 2007 Share Posted June 11, 2007 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); } Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted June 12, 2007 Share Posted June 12, 2007 Thank you for those screenshots and formulas! Michael Quote Link to comment Share on other sites More sharing options...
Allas Posted June 13, 2007 Share Posted June 13, 2007 (edited) 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 June 13, 2007 by Allas Quote Link to comment Share on other sites More sharing options...
pps Posted June 14, 2007 Share Posted June 14, 2007 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). Quote Link to comment Share on other sites More sharing options...
Allas Posted June 15, 2007 Share Posted June 15, 2007 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 ??? Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted June 15, 2007 Share Posted June 15, 2007 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 Quote Link to comment Share on other sites More sharing options...
Olivier Galibert Posted June 20, 2007 Share Posted June 20, 2007 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. Quote Link to comment Share on other sites More sharing options...
Allas Posted June 20, 2007 Share Posted June 20, 2007 (edited) Yes, just I'll try to do a example in this way. Edited June 20, 2007 by Allas Quote Link to comment Share on other sites More sharing options...
_33 Posted June 21, 2007 Author Share Posted June 21, 2007 (edited) 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); } 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 June 22, 2007 by _33 Quote Link to comment Share on other sites More sharing options...
Wilbert Posted June 24, 2007 Share Posted June 24, 2007 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 24, 2007 Share Posted June 24, 2007 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. Quote Link to comment Share on other sites More sharing options...
_33 Posted June 24, 2007 Author Share Posted June 24, 2007 (edited) 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 June 24, 2007 by _33 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted June 26, 2007 Share Posted June 26, 2007 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.com/forums/index.php?s...&hl=palette I think it can be easily tweaked for adjusted palettes. Quote Link to comment Share on other sites More sharing options...
pps Posted June 29, 2007 Share Posted June 29, 2007 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. Move__em.zip Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 29, 2007 Share Posted June 29, 2007 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. Quote Link to comment Share on other sites More sharing options...
pps Posted June 29, 2007 Share Posted June 29, 2007 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. Quote Link to comment Share on other sites More sharing options...
xulchris Posted June 29, 2007 Share Posted June 29, 2007 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; Quote Link to comment Share on other sites More sharing options...
pseudografx Posted October 8, 2007 Share Posted October 8, 2007 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); } 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. OlivierPAL.zip Quote Link to comment Share on other sites More sharing options...
dwhyte Posted October 15, 2007 Share Posted October 15, 2007 (edited) 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 Edited October 15, 2007 by dwhyte Quote Link to comment Share on other sites More sharing options...
pseudografx Posted October 15, 2007 Share Posted October 15, 2007 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 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). Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.