Jump to content
IGNORED

Need the 256 colors!


Recommended Posts

I created a thread about this subject on where I usually post but now I'm stuck, and no one has a smart answer for me. So I decided to contact the real pros. What I'm trying to find is the real colors of the ATARI 8-bit. I've made my own, and I'm trying to compare. I need someone with the brains to dump the colors, take a snapshot with a cam, and post it here. I've checked the colors in G2F, but they seem off. Someone might confirm with me.

 

My palette is off, but I don't know how off thoe!

117360363720070529225725.png

 

 

G2F's color chooser:

132127803020070530012704.png

Edited by _33
Link to comment
Share on other sites

On the GTIA in 16 color modes, there is one mode with 16 shades (mode 9), and they are very distinct shades of one hue. Since there are 16 hues (mode 11), there are 256 colors to choose from. On the older CTIA, there are 128 colors to choose from, with several graphics modes less.

 

http://www.sonic.net/~nbs/new_and_emu.html

Edited by _33
Link to comment
Share on other sites

The best method might be to reproduce that display on a real Atari then feed it to a video capture card.

 

But, the inherent problem with reproducing colours on a PC monitor is that typically a monitor will display any given RGB value at a lower brightness than a TV.

 

Then you have the additional problem that colour trimmers on different Ataris can fall out of adjustment and cause slight colour variations.

 

Not to mention the fact that PAL Ataris don't produce the same as NTSC. Colour 1 is the same as 15, and Colour 4 I believe is reddish on NTSC but more purple/violet on PAL.

Link to comment
Share on other sites

The best method might be to reproduce that display on a real Atari then feed it to a video capture card.

 

But, the inherent problem with reproducing colours on a PC monitor is that typically a monitor will display any given RGB value at a lower brightness than a TV.

 

Then you have the additional problem that colour trimmers on different Ataris can fall out of adjustment and cause slight colour variations.

 

Not to mention the fact that PAL Ataris don't produce the same as NTSC. Colour 1 is the same as 15, and Colour 4 I believe is reddish on NTSC but more purple/violet on PAL.

 

Thanks for this very nice tip Rybags!

 

I've got the MESS emulator colors now. They seem to give somewhat bright full colors in the lower ranges, but close to what I got in the high ranges. There seems to be some staircase variants (notably in the blues and reds and some yellows... Well a lot of staircase color changes). Your toughts?

 

160540695020070530040213.png

Edited by _33
Link to comment
Share on other sites

If I have time later on, I'll get my real machines out and generate some captures. They're all PAL though - most emulations look best with NTSC colour representations.

 

I'm sure if I scan through the source code of any other Atari 8-bit emulator (Atari 800Plus, done that one also), that it wouldn't match any of the color charts that I posted already, which add to the confusion. Now, with the mention of the PAL colors, it's getting even worse!

Edited by _33
Link to comment
Share on other sites

Aside from possible differences in the way the color output is "tuned" on different Ataris, another issue when using a TV is the way the brightness, contrast, and tint are set-- especially with NTSC Ataris and TVs. Anyway, following is a video capture I made several years ago of a 256-color display. I believe I posted a short Atari BASIC program here a year or two back, to display the 256 colors as in this video capture, and there were a couple of people who posted their own video captures from it on their NTSC or PAL Ataris, so you might want to search this forum for it.

 

By the way, I've always thought that luminances 7 and 8 look virtually identical to each other, whereas the other luminances have a more noticeable "step" between them-- but when you display luminances 7 and 8 side-by-side (as in this video capture), you get a "dark line" where they meet.

 

Michael

 

post-7456-1180499001_thumb.png

Link to comment
Share on other sites

On the GTIA in 16 color modes, there is one mode with 16 shades (mode 9), and they are very distinct shades of one hue. Since there are 16 hues (mode 11), there are 256 colors to choose from. On the older CTIA, there are 128 colors to choose from, with several graphics modes less.

 

http://www.sonic.net/~nbs/new_and_emu.html

 

Correct. I was thinking CTIA when I posted that. But even in a GTIA machine, CTIA modes can still only display 128 diff colors.

 

I never dabbled much in the new GTIA modes to realize that. Other than the 16 hues and shades.

Link to comment
Share on other sites

Aside from possible differences in the way the color output is "tuned" on different Ataris, another issue when using a TV is the way the brightness, contrast, and tint are set-- especially with NTSC Ataris and TVs. Anyway, following is a video capture I made several years ago of a 256-color display. I believe I posted a short Atari BASIC program here a year or two back, to display the 256 colors as in this video capture, and there were a couple of people who posted their own video captures from it on their NTSC or PAL Ataris, so you might want to search this forum for it.

 

By the way, I've always thought that luminances 7 and 8 look virtually identical to each other, whereas the other luminances have a more noticeable "step" between them-- but when you display luminances 7 and 8 side-by-side (as in this video capture), you get a "dark line" where they meet.

 

Michael

 

post-7456-1180499001_thumb.png

 

See, this is what I came up with. And now it's more obvious that the real bugger is nailing down the reds and blues properly in the lower range, since the saturation is high but also the luminence is fairly high. So as the luminence increases, saturation decreases. But it's special in the reds and blues.

 

209981495020070530073015.png

Link to comment
Share on other sites

post-7456-1180499001_thumb.png

 

See, this is what I came up with. And now it's more obvious that the real bugger is nailing down the reds and blues properly in the lower range, since the saturation is high but also the luminence is fairly high. So as the luminence increases, saturation decreases. But it's special in the reds and blues.

 

209981495020070530073015.png

I think your hue 2 is off; it looks yellow, but it should be yellow-orange. Aside from that, it looks like your other hues are pretty close to my video capture, other than the saturations and luminances. And your hue 1 may be a tad too greenish. The literature says that hue 1 is the same as colorburst, and NTSC colorburst is mostly yellow with a definite hint of green.

 

Here's a color wheel I made using a formula I found somewhere, based on hue 1 = colorburst, and the other hues being shifted around the NTSC color wheel by a certain number of degrees. The hues are numbered around the outside of the wheel, and the colors are oriented as close as I could get them to the NTSC color wheel, where colorburst is "due west," red is somewhere around "NNW," etc. I got the colors by using a free program called Colorspace, and rotating the NTSC color space by a certain number of degrees to get a specific value. I don't know how close the hues are to an actual NTSC Atari, but for the most part they look pretty good. I didn't try to get the saturations and luminances, just the hues, to see if the formula I'd found was accurate.

 

Michael

 

post-7456-1180508689_thumb.png

Link to comment
Share on other sites

By the way, the formula I found is more or less as follows:

 

Phase angle = 185.938636363636 + 27.0613636363636 * hue

where hue = 1 through 15.

 

The document I found gave slightly different values, but I tried to calculate more exact values based on the NTSC color clock timings. To use the resulting phase angles with the Colorspace program, I had to convert them to +/- values, e.g., 213 degrees (colorburst) is equal to -147 degrees. This is what I came up with:

 

hue 1 = -147

hue 2 = -119.938636363636

hue 3 = -92.8772727272728

hue 4 = -65.8159090909092

hue 5 = -38.7545454545455

hue 6 = -11.6931818181819

hue 7 = 15.3681818181818

hue 8 = 42.4295454545454

hue 9 = 69.4909090909091

hue 10 = 96.5522727272727

hue 11 = 123.613636363636

hue 12 = 150.675

hue 13 = 177.736363636364

hue 14 = -155.202272727273

hue 15 = -128.140909090909

 

As you can see, the hues span slightly more than 360 degrees, with hue 15 being between hue 1 and hue 2.

 

Here's a screenshot of the Colorspace program, showing the NTSC (YIQ) "color cube" oriented at the angle usually shown on video equipment that's used to check the colors-- i.e., with colorburst at the far left ("due west"), or with the Q axis at 33 degrees, and the I axis at 123 degrees. Once I calculated the phase angles for the hues, using the formula shown above, I changed the "Phi" setting in Colorspace to rotate the YIQ color cube so that the Q axis had a particular phase angle, and then took the color that was "due east" (i.e., a Phi setting of -147 degrees rotates colorburst so it's "due east").

 

Michael

 

post-7456-1180511077_thumb.png

Link to comment
Share on other sites

Is there is a formula to change a 24bit pixel BMP into 1byte APAC pixel color (1 nibble luminance+1 nibble hue)?

I don't know, but if you're able to understand it (much of it is over my head), you could start with this page:

 

http://www.xmission.com/~trevin/atari/video_notes.html

 

I know there are conversion formulas for going from YIQ (NTSC) color values to RGB color values, and I know you also need to take into account the effects of different gamma values between TV sets and computer monitors. Furthermore, although APAC colors are created by effectively combining 16 hues with 16 luminances, the results are different than if you were to display the Atari's actual 256 colors.

 

I was trying to figure out where I'd found the hue phase-shift formula that I posted, and it looks like I'd extrapolated it from some information on this page:

 

http://homepage.ntlworld.com/kryten_droid/...ari_hw/gtia.htm

 

Michael

Link to comment
Share on other sites

Here's another link with information and formulas related to converting from TV color space-- in this case, YUV (PAL) color space-- to RGB color space, with gamma correction taken into account. The discussion is oriented toward the VIC-II (C-64), but the formulas and general discussion ought to be applicable to converting from YIQ (NTSC) color space to RGB color space for the Atari's colors.

 

http://www.pepto.de/projects/colorvic/

 

Michael

Link to comment
Share on other sites

Here's a complete set of YIQ functions in C:

 

http://www.fools-errant.com/~ebeth/ml/proj/hc/lib/color.c

 

What is YIQ? Found info here: http://www.ardenwoodsnd-dvd.com/glossary/glossary_y.html

YIQ (YCbCr - Luminance/In phase/Quadrature phase)

A bandwidth optimized, matrixed, composite video signal format used by NTSC video systems employing separate luminance and two derived blue and red chroma components derived from the YUV format.

The modulated carriers (U) and (V) (phased 90 degrees apart) are what carry the color information in an NTSC-encoded composite color picture. This is called “quadrature”. We call the modulated carriers “I” and “Q” in NTSC ("In phase" and "Quadrature phase"). I and Q are bandwidth-limited differently so they’ll fit into the NTSC transmission spectrum.

 

The human visual system has less spatial acuity for magenta-green transitions than it does for red-cyan. Thus, if signals I and Q are formed from a 123 degree rotation of U and V respectively, the “Q” signal can be more severely filtered than “I” without being perceptible to a viewer at typical TV viewing distance. YIQ is equivalent to YUV with a 33 degree rotation and an axis flip in the UV plane. The first edition of W.K. Pratt “Digital Image Processing”, and presumably other authors that follow that bible, has a matrix that erroneously omits the axis flip; the second edition corrects the error.

 

Since an analog NTSC decoder has no way of knowing whether the encoder was encoding YUV or YIQ, it cannot detect whether the encoder was running at 0 degree or 33 degree phase. In analog usage the terms YUV and YIQ are often used somewhat interchangeably. YIQ was important in the early days of NTSC but most broadcasting equipment now encodes equiband U and V.

 

The D-2 composite digital DVTR (and the associated interface standard) conveys NTSC modulated on the YIQ axes in the 525-line version and PAL modulated on the YUV axes in the 625-line version. (See YUV)

 

I just made the YIQ2RGB in Blitz3D. I don't think I'll have any use for this in particular. I've tried it and found that it won't fix the reds and blues problem that I have...

Function yiq_rgb(y#,i#,q#, r%, g%, b%)
;Y = range [0.,1.]
;I = range [-.6,.6]
;Q = range [-.52,.52]
  red% = ((1.00309 * y) + (0.95485 * i) + (0.61786 * q)) * r
  green% = ((0.99678 * y) + (-0.27071 * i) + (-0.64479 * q)) * g
  blue% = ((1.00850 * y) + (-1.11049 * i) + (1.69957 * q)) * b
  If red < 0   Then red = 0 ElseIf red > 255 Then red = 255
  If green < 0   Then green = 0 ElseIf green > 255 Then green = 255
  If blue < 0   Then blue = 0 ElseIf blue > 255 Then blue = 255
  Return ((red And $FF) Shl 16) Or ((green And $FF) Shl 8) Or (blue And $FF)
End Function

Edited by _33
Link to comment
Share on other sites

95909111420070601061736.png

 

Best I could do so far! Getting tired :(

 

But this is as close as I can imagine. Ive compared colors in GIMP with the sample I got from this forum. ANyhow thanks guys. Any other real 8-bit sample of the 256 color palette would be appreciated.

Link to comment
Share on other sites

Here's a captured screen from my PAL 130XE via it's S-Video output.

 

post-7804-1180692072_thumb.jpg

 

 

I wrote my own program to generate it - it leaves space between the colours and also uses 3 black-coloured Players to help delineate the changes at the borders and between luminence levels 0 and 1.

 

 

Here is the program I used - Zipped ATR - mount it after loading DOS with BASIC, then ENTER "D:COLORBAR.BAS" and RUN it.

 

Colorbar.zip

Edited by Rybags
Link to comment
Share on other sites

post-7456-1180499001_thumb.png

 

Interesting comparing that cap to mine.

 

I've got them both loaded up in Photoshop and checking the colours with the eyedropper and RGB and HSB sliders.

 

Despite being somewhat grainy, the cap from SeGtGruff seems to have perfectly consistent whites, ie - the R,G,B values for each sampled pixel are always the same.

 

Mine seems to have a misbalance - don't know if that's a PAL thing or just the settings on my capture card (I have them at default, other than adjusting interlace compensation and sharpness for a better looking display).

Edited by Rybags
Link to comment
Share on other sites

post-7456-1180499001_thumb.png

 

Interesting comparing that cap to mine.

 

I've got them both loaded up in Photoshop and checking the colours with the eyedropper and RGB and HSB sliders.

 

Despite being somewhat grainy, the cap from SeGtGruff seems to have perfectly consistent whites, ie - the R,G,B values for each sampled pixel are always the same.

 

Mine seems to have a misbalance - don't know if that's a PAL thing or just the settings on my capture card (I have them at default, other than adjusting interlace compensation and sharpness for a better looking display).

If I remember correctly, my capture was made a few years back by connecting my NTSC 8-bit to a VCR, and then connecting the VCR to my computer via a Snappy video capture device. (At the time, the only way I could connect my Atari to video was via the antenna connectors on the RF switch box!) Anyway, I played with the brightness and contrast settings in the Snappy software to get a good picture, from a nice dark black to a reasonably bright white. I kept the tint adjusted "in the middle" so it would be as "pure" as possible, rather than trying to adjust it more toward red or green to get a nice yellow for hue 1. (I'm not sure if I knew it at the time, but hue 1 on an NTSC Atari is said to be equal to "colorburst," which is sort of greenish yellow, but closer to yellow, so it's a good thing I didn't try to adjust the tint to make hue 1 equal a nice-looking yellow!)

 

I'm guessing that you need to adjust those capture card settings to bump up the brightness, and possibly adjust the contrast as well. Unless I'm getting it backward, TV has a higher gamma than computer monitors, so an image that looks good on a TV will look darkened on a computer monitor, hence you need to adjust the gamma, or brightness/contrast, to try to get a better match between the image as seen on a monitor and on a TV.

 

It doesn't help the situation that Ataris have a potentiometer which can be adjusted to modify the color output for the hues; that NTSC TVs have a tint adjustment; that computer monitors also have tint (RGB) adjustments; that all TVs and monitors have brightness/contrast adjustments; that TV sets and computer monitors use different gammas; that different TV sets or monitors may use different phosphors for red, green, and blue; etc. All of these factors tend to make the quest for perfect color emulation something of an "impossible dream." Of course, that shouldn't stop us from trying! :)

 

Michael

Link to comment
Share on other sites

By the way, I was thinking it would be cool to get a vectorscope, connect an Atari to it, have the Atari display each color one by one, and check the results on the vectorscope, to see where each hue is located around the NTSC (or PAL) color wheel. But then I saw how expensive vectorscopes are, which put a definite damper on *that* pipe dream!

 

Michael

Link to comment
Share on other sites

Here's a captured screen from my PAL 130XE via it's S-Video output.

 

post-7804-1180692072_thumb.jpg

 

 

I wrote my own program to generate it - it leaves space between the colours and also uses 3 black-coloured Players to help delineate the changes at the borders and between luminence levels 0 and 1.

 

 

Here is the program I used - Zipped ATR - mount it after loading DOS with BASIC, then ENTER "D:COLORBAR.BAS" and RUN it.

 

Colorbar.zip

 

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.

 

BTW, SeaGtGruff, your Atari is an NTSC?

 

It seems in MESS, they tried to hack in a PAL palette and tried to increatse saturation to give them more lively colors. It's a shame because MESS, like MAME, is supposed to emulate exactly the system, not have a ricer one :P

 

Cheers.

Edited by _33
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...