Request for screen captures from NTSC Ataris

[Kr0tki]

OK, so I've analysed some of the NTSC screens. Here I'll show you the results for Hias' first screenshot.

 

The following image shows the screenshot being split into three channels of the YUV colour space:

 

First, the Y channel. It proves that luma values are constant for all hues (well there are slight discrepancies in the dark region, but they are the result of YUV->RGB conversion of the TV card).

 

The brightness is spread mostly linearly, with one notable exception: the difference between luma 7 and 8 is much smaller than differences between other consecutive lumas. We are lucky, however: in the specification of the CGIA(!!!) chipset there is a section that lists voltages for all luma values. In that list there is the same discrepancy - the difference in voltages for luma 7 and 8 is smaller that all others. So, emulating luminance properly should not be a problem.

 

Second, the U and V channels. U and V values also are constant for all luminances - the exception being regions marked red. However these regions are again a result of YUV->RGB conversion of the TV card - the RGB colour space is different from the YUV one and some colours are cut off. I've checked that it holds true for palettes generated by pseudografx in another thread, so there's nothing to worry about.

 

So, to sum up, the results are:

1. For each luminance, the Y value is constant for all chrominances

2. Y values are non-linear, but they conform rather accurately to the voltages in CGIA.PDF

3. For each chrominance, the U and V values are constant for all luminances

All above results are also true for Larry's and Cybernoid's NTSC screenshots, and also for some PAL screenshots from another AtariAge thread - however I haven't looked into Hias' PAL screenshots yet.

 

So the only thing left unknown is how are the U and V channels generated by GTIA - I'll look at it further in a couple of days. It appears that colors are spread evenly for NTSC GTIA, but I don't expect nice results for PAL screenshots.

[Rybags]

Maybe the closeness of values 7/8 luma was planned to try and compensate for the voltage drop due to way luma is generated via the resistor network... not that it would have helped much.

 

Isn't UV simply generated via delaying the colourburst crystal's signal within GTIA?

And, does GTIA have some mechanism of creating the sine wave or is that done externally?

 

Does saturation vary dependant on luma? Or do higher luma values always produce a washed-out look?

Edited April 10, 2009 by Rybags

[Kr0tki]

Isn't UV simply generated via delaying the colourburst crystal's signal within GTIA?

Yes it is, but there are still a few unknowns:

- Are the differences between consecutive colours equal? As GTIA.PDF states, they should be, but it can be seen with a naked eye, that for PAL screenshots it's not true.

- Is the amplitude of U and V signals equal? If it is not, then different hues would be saturated differently.

And, does GTIA have some mechanism of creating the sine wave or is that done externally?

I don't know, but it makes no difference for me now.

Does saturation vary dependant on luma? Or do higher luma values always produce a washed-out look?

U and V values are constant for each chorminance in all lumas; and it is a feature of NTSC (and PAL) that when you add more luma and don't change the colour signal, the result will be brighter, but less saturated. So yes, higher lumas are always washed-out, on all GTIAs and all TVs.

Edited April 10, 2009 by Kr0tki

[edward1024]

Here is a screen capture from the composite output of a stock NTSC 800XL:

 

 

And from a stock 130XE:

 

 

I captured the output in DV video format using a Canopus ADVC-100 and then extracted individual frames with Photoshop Elements.

 

I also posted these captures and related information at: http://www.bernerfam.com/erb/atari-colors/

[a8isa1]

Hello,

 

I'm trying to recreate the colours generated by NTSC Ataris, in order to improve the Atari800 emulator's video output quality; and I want to make it as accurate as possible. I am well aware of previous threads in this topic; I've even contributed to some of them. I'm also aware of a routine posted in this thread, that aims to recreate the NTSC colours. However that routine was based on only one NTSC screenshot, and that's not enough to consider it accurate. Additionally, the aforementioned screenshot contains a certain irregularity in its colours, and I'm not able to develop a mathematical basis for it.

 

So I'd like to ask those of you who own NTSC Ataris and have access to a video capture device, to make some screenshots for me I've attached a program (in BASIC and as a DOS file) that generates a 256-colour screen. Please make a screen-grab of that program running and post it here.

 

Now I've heard that modern PC video capture cards may not synchronise properly to Atari video output, and may produce unstable display. As long as some colour info is retained, such display would still be useful for me, so please post it anyway. Also provide some additional information if possible: computer model, whether it's GTIA or CTIA (yeah right), was it modified to S-VIDEO output, ClearPic or whatever.

 

Based on gathered screenshots, it might then be possible to develop an accurate colour generation.

I had forgotten how bad my TV card (Norwood Video, with Conexant 2388x chipset) really is with A8 output. It can't even stablize the output from your program. You wouldn't have been able to use the output if it had worked. At least I tried to get you a sample.

 

OT:

 

Has anyone ever seen output this bad for a TV/capture card? LOL

 

 

It's even worse live!

 

- Steve Sheppard

[Bryan]

Does saturation vary dependant on luma? Or do higher luma values always produce a washed-out look?

 

It does vary, but only because the Atari has no mechanism to keep it constant.

 

Normally, the amplitude of the color signal is proportional to the luminance. If an area of the picture is brighter, then it takes a stronger color signal to produce the same saturation. Since the Atari produces a single color amplitude, you will get unsaturated brights and over-saturated darks.

 

The over-saturation of dark colors is the reason for the color "shadows" around darker colors. Think of this way: If you show color 0, you get black- no luminance. If you display color $10, $20, etc... you get a color and some brightness. This means that the brightness of these colors is an artifact of the color decoding circuit (bloom) and not from the DC level of the luminance. Because the color circuitry is PLL-based and has a slow response time, these dark pixels will not have clear edges but rather will be be poorly defined.

 

You can draw a bright box ($x8) directly above a dark box ($x0) on a black background and see how the lack of a luminance edge affects the clarity of the object.

[Kr0tki]

Hello again, long time no see. I've analysed the screenshots further as promised before, this time reaching a concrete result.

 

For each of the above NTSC screenshots, it is true that the difference between consecutive colours is constant. That means, colours spread evenly on the colourwheel in the YIQ/YUV colourspace. Also, amplitudes of U and V signals is equal in all cases, which makes all colours saturated equally. I don't know if it was obvious, but at least it's confirmed empirically.

 

However, while the colour differences are constant on each machine, they vary between different machines. The range is between 23° and 28°. AFAIK there's a hole on the bottom of each Atari with access to a potentiometer that regulates this colour difference.

 

Anyway, I've managed to create an universal algorithm that generates rather fine approximations of all of the above NTSC palettes. I've attached the source. (Actually it's a modified algorithm from the Atari800 sources.)

 

The program takes a set of variables: brightness, contrast, gamma, saturation, hue, colour difference, black level, and white level, and generates a palette file that can be loaded into an emulator. By painstakingly adjusting the parameters (a semi-automated process involving a magical Excel spreadsheet ) I've managed to create palettes for all NTSC screens; they are also included in the archive. The screenshots of those created palettes are also there, so you can compare them to the real thing without hassle.

 

I think that I've reached my goal. Thanks for your help, guys!

 

Unfortunately, the deal with PAL palettes won't be that easy. I haven't got the slightest idea what's the reason for those irregularities as shown on Hias' images. Anyway that's a whole different topic...

palgen_ntsc.zip

Edited May 12, 2009 by Kr0tki

[SeaGtGruff]

Thank you!

 

Michael

[Cybernoid]

Hello again, long time no see. I've analysed the screenshots further as promised before, this time reaching a concrete result.

 

For each of the above NTSC screenshots, it is true that the difference between consecutive colours is constant. That means, colours spread evenly on the colourwheel in the YIQ/YUV colourspace. Also, amplitudes of U and V signals is equal in all cases, which makes all colours saturated equally. I don't know if it was obvious, but at least it's confirmed empirically.

 

However, while the colour differences are constant on each machine, they vary between different machines. The range is between 23° and 28°. AFAIK there's a hole on the bottom of each Atari with access to a potentiometer that regulates this colour difference.

 

Anyway, I've managed to create an universal algorithm that generates rather fine approximations of all of the above NTSC palettes. I've attached the source. (Actually it's a modified algorithm from the Atari800 sources.)

 

The program takes a set of variables: brightness, contrast, gamma, saturation, hue, colour difference, black level, and white level, and generates a palette file that can be loaded into an emulator. By painstakingly adjusting the parameters (a semi-automated process involving a magical Excel spreadsheet ) I've managed to create palettes for all NTSC screens; they are also included in the archive. The screenshots of those created palettes are also there, so you can compare them to the real thing without hassle.

 

I think that I've reached my goal. Thanks for your help, guys!

 

Unfortunately, the deal with PAL palettes won't be that easy. I haven't got the slightest idea what's the reason for those irregularities as shown on Hias' images. Anyway that's a whole different topic...

 

Excellent work! Your knowledge of video especially of the YUV/YIQ color space is really good. Do you work in the video field?

[Kr0tki]

No I don't, I've just read about it on Wikipedia. Anyway I'm only following others' efforts - a lot of knowledge lies in other threads here at AtariAge.

 

As for the "magical Excel spreadsheet" I mentioned: here it is attached Actually it's not a spreadsheet, but a program that generates spreadsheets (CVS format) for a given screenshot. I've used that program to speed up the analysis of palette screenshots. Details are in README.

palgen_ntsc.zip

Edited May 13, 2009 by Kr0tki

[SeaGtGruff]

As for the "magical Excel spreadsheet" I mentioned: here it is attached Actually it's not a spreadsheet, but a program that generates spreadsheets (CVS format)

Thanks again!

 

I hope someone can use your work to add adjustable palettes into the emulators-- like knobs to turn brightness up or down, contrast up or down, color saturation up or down, change the color tint, adjust the separate red/green/blue levels, and even a knob for adjusting the phase shift value as if we're tinkering with the color pot on the bottom of the Atari.

 

Michael

[Rybags]

Those earlier pics show Atari had it almost perfect on the 400/800, and just made a mess with the XL/XE.

 

I've generally found the later machines to have sharper video output, but piss-poor colour representation.

 

A nice mod (if it was possible ?) would be a circuit enhancement to provide a saturation boost if the luma value was over 8 or so.

[SeaGtGruff]

Those earlier pics show Atari had it almost perfect on the 400/800, and just made a mess with the XL/XE.

I've never had a 400 or 800, just XLs and XEs, so I didn't know there was such a difference between them. Anyway, I used to display the 256-color palette like in the screenshots, then adjusted my TV set's brightness, contrast, saturation, and tint until the colors looked as good as I thought they should be, so maybe that helped compensate for any washed-out colors?

 

But one thing that still makes me feel cheated-- in comparison to the 800's colors-- was the dramatic change they made in the artifacted colors.

 

Michael

Edited May 13, 2009 by SeaGtGruff

[Rybags]

With PAL systems, we got screwed on both counts.

 

Some colours are sufficiently different that some games can look crap due to palette choices.

Artifacting doesn't work like on NTSC, it looks bearable on 400/800, crap on later machines.

[atariksi]

No I don't, I've just read about it on Wikipedia. Anyway I'm only following others' efforts - a lot of knowledge lies in other threads here at AtariAge.

 

As for the "magical Excel spreadsheet" I mentioned: here it is attached Actually it's not a spreadsheet, but a program that generates spreadsheets (CVS format) for a given screenshot. I've used that program to speed up the analysis of palette screenshots. Details are in README.

 

So can you list best 24-bit R,G,B values for GTIA mode 11's colors?

 

I mainly use GTIA mode 9 and use linear 0,16,32,48,64,80,96,112,128,144,160,176,192,208,224,240 for the 8-bit gray scale equivalent but I can see that it uses some nonlinear curve (upper shades seem to be closer together).

[Rybags]

You get that on PCs also.

 

Major difference if you have a transition from 0 thru 31. Barely noticable for 224 thru 255.

[Shannon]

Nice work! Let us know when you have code useable in A800... Or is the current code easily pluggable? If so I can plug it in to use the "normal" values you had listed in the readme. Then I'll add a menu where the user can "adjust" those values as preferred.

[Kr0tki]

Thanks again!

 

I hope someone can use your work to add adjustable palettes into the emulators-- like knobs to turn brightness up or down, contrast up or down, color saturation up or down, change the color tint, adjust the separate red/green/blue levels, and even a knob for adjusting the phase shift value as if we're tinkering with the color pot on the bottom of the Atari.

 

Michael

 

Well, that was my intent from the very beginning. When I have more time, I'm surely gonna send a patch to the dev team.

 

Actually, Atari800 already supports adjustable palette. However:

1. it only works in the SDL version

2. it only works with artifacting set to "NTSC filter"

3. parameters aren't adjustable by a menu, only by means of key combinations (ALT + one of the keys 1 2 3 4 5 6 7 8 9 0 - = [ ] ; ')

4. it's missing the phase delay control

5. the palette is slightly inaccurate.

 

Points 4. and 5. are what I'm addressing in this topic; others - well, anyone can help, the sources are out there.

 

So can you list best 24-bit R,G,B values for GTIA mode 11's colors?

No I can't; you're completely missing the point, which is, to make the palette confgurable. It's obviously impossible to compute a single set of ideal RGB values.

 

I mainly use GTIA mode 9 and use linear 0,16,32,48,64,80,96,112,128,144,160,176,192,208,224,240 for the 8-bit gray scale equivalent but I can see that it uses some nonlinear curve (upper shades seem to be closer together).

You can measure the values from screenshots yourself. Or analyse the given algorithm. The truth is, for most of the screenshots I had to set the gamma parameter to around 0.8-0.9. The value is less than 1; that means that indeed brighter shades are closer together.

 

Nice work! Let us know when you have code useable in A800... Or is the current code easily pluggable? If so I can plug it in to use the "normal" values you had listed in the readme. Then I'll add a menu where the user can "adjust" those values as preferred.

 

Well, there might be some work involved if one wanted to integrate it with the existing code that computes palette in the "NTSC filter" mode (as mentioned above). It would be nice if the same color genertation was used in the "NTSC filter" mode and the normal mode; alas Atari800 isn't working that way right now.

Edited May 13, 2009 by Kr0tki

[atariksi]

...

So can you list best 24-bit R,G,B values for GTIA mode 11's colors?

 

I mainly use GTIA mode 9 and use linear 0,16,32,48,64,80,96,112,128,144,160,176,192,208,224,240 for the 8-bit gray scale equivalent but I can see that it uses some nonlinear curve (upper shades seem to be closer together).

No I can't; you're completely missing the point, which is, to make the palette confgurable. It's obviously impossible to compute a single set of ideal RGB values.

...

 

There must be some ideal best RGBs for the default Graphics 11's 16 colors. The fact that software or images have to be distributed to people that can be anywhere would require using some constant set of colors.

[Kr0tki]

OK, so what would you consider ideal? Do you or me or any one have authority to decide what settings are ideal? There's always gonna be someone for whom the palette is wildly off. And I'm not gonna decide on what palette is the most popular, basing my decision on 9 screenshots; instead I'm making the software configurable so the user can decide on his own.

 

On a side note: You posted your answer while I was editing my previous post; you might want to reread it.

Edited May 13, 2009 by Kr0tki

[atariksi]

OK, so what would you consider ideal? Do you or me or any one have authority to decide what settings are ideal? There's always gonna be someone for whom the palette is wildly off. And I'm not gonna decide on what palette is the most popular, basing my decision on 9 screenshots; instead I'm making the software configurable so the user can decide on his own.

...

It's nice to have configurable software, but I was just pointing at another use-- a standard set of RGBs based on a fixed criterion. Say, using an 800XL with an Amiga 1084 monitor what are the R,G,Bs for the colors in Graphics 11. I would think this has some ideal best RGBs.

 

>On a side note: I've edited my previous post while you posted your answer, you might want to reread it.

 

Okay. So in this case, there must be 16 8-bit shade values which correspond to a worst and best case (if normal case doesn't exist for fixed machines).

[Kr0tki]

It's nice to have configurable software, but I was just pointing at another use-- a standard set of RGBs based on a fixed criterion.

What's the criterion then?

Say, using an 800XL with an Amiga 1084 monitor what are the R,G,Bs for the colors in Graphics 11. I would think this has some ideal best RGBs.

Why would you think so?

Okay. So in this case, there must be 16 8-bit shade values which correspond to a worst and best case (if normal case doesn't exist for fixed machines).

What do you mean, worst and best case?

Edited May 13, 2009 by Kr0tki

[atariksi]

It's nice to have configurable software, but I was just pointing at another use-- a standard set of RGBs based on a fixed criterion.

What's the criterion then?

Say, using an 800XL with an Amiga 1084 monitor what are the R,G,Bs for the colors in Graphics 11. I would think this has some ideal best RGBs.

Why would you think so?

Okay. So in this case, there must be 16 8-bit shade values which correspond to a worst and best case (if normal case doesn't exist for fixed machines).

What do you mean, worst and best case?

 

When they make some game or application they are presuming the colors are good enough to look similar on all the machines. You don't have to use 800XL/Amiga 1084 but that was just an arbitrary decision. Worst/best case for shading meaning values of shades upper bound/lower bound like:

 

0,16,32,48,64,80,96,112,128,149,159,168,179,189,200,213

 

vs.

0,17,34,50,68,83,99,117,138,152,164,173,185,199,212,225

[Kr0tki]

Ah. So you probably should look into README in the program's archive - I've given the default parameters there. The palette produced with those parameters pretty closely matches the official descriptions of colours given in GTIA.PDF; and the luma values are in the range of 16-235, because those two values are mentioned inITU-R Recommendation BT.601, and I liked the output.

[SeaGtGruff]

Thanks again!

 

I hope someone can use your work to add adjustable palettes into the emulators-- like knobs to turn brightness up or down, contrast up or down, color saturation up or down, change the color tint, adjust the separate red/green/blue levels, and even a knob for adjusting the phase shift value as if we're tinkering with the color pot on the bottom of the Atari.

 

Michael

 

Well, that was my intent from the very beginning. When I have more time, I'm surely gonna send a patch to the dev team.

 

Actually, Atari800 already supports adjustable palette.

Yes, but I was actually thinking about the 2600 emulators (and maybe 7800 emulators as well). True, the 2600 has only 128 colors, but they should be the same as the 128 even-numbered colors on the 800 series. So the algorithm should still work for a 2600 emulator, just mask off bit 0 from the color number (i.e., storing color 68 or color 69 into COLUBK should give you the same color, since bit 0 get ignored).

 

Michael