New FINAL Prosystem NTSC Palette file

[Underball]

See Attached.

 

First image is the new palette.

 

Second is what the old one I did looked like.

 

much better true color gradation here.

 

I have posted the updated ProSystem source files for incorporation into the source files.

NTSC-Final_01-07-2010.zip

New_7800_palette_source_files_Jan_2010.zip

Edited January 7, 2010 by Underball

[Shannon]

Ugghh I just went thru the process of updating a7800x (based on MESS) with the new "old" palette and redoing my screenshots.

 

Guess I'll add this to my todo list that has been piling up lately for some odd reason.

[Kr0tki]

Underball,

 

Some time ago I have preformed a detailed analysis of the way the Atari 8-bit GTIA generates colours in NTSC. The analysis resulted in changes to the Atari800 emulator, which add several nice new features. The emulator now generates its palette dynamically, based on user-specified parameters like contrast, brightness, colour saturation, tint etc. This gives results much more similar to the real Atari colours than a palette-based approach.

 

Sine 7800 MARIA generates colours in much the same way as GTIA, you might want to look into Atari800's CVS repository and port that new features to ProSytem. The result would be nicer, I think. Atari800's colours.c and colours_ntsc.c modules (and the Display Settings menu in the emulator) are the place to start.

[Underball]

Underball,

 

Some time ago I have preformed a detailed analysis of the way the Atari 8-bit GTIA generates colours in NTSC. The analysis resulted in changes to the Atari800 emulator, which add several nice new features. The emulator now generates its palette dynamically, based on user-specified parameters like contrast, brightness, colour saturation, tint etc. This gives results much more similar to the real Atari colours than a palette-based approach.

 

Sine 7800 MARIA generates colours in much the same way as GTIA, you might want to look into Atari800's CVS repository and port that new features to ProSytem. The result would be nicer, I think. Atari800's colours.c and colours_ntsc.c modules (and the Display Settings menu in the emulator) are the place to start.

I actually incorporated your changes to the atari800 palette in PSPatari with coder ZX-81 a while ago.

 

However, The way the Prosystem emulator uses the palette is altogether different from how atari800 does even before your changes, and it would have to be re-written, which wouldn't necessarily be a bad thing, but is beyond my capabilities as a coder.

 

All I really did here was hack around with the palette file in a hex editor trying to match values I had from a real NTSC 7800 screenshot taken from a console running the color demo on a CC2.

[Underball]

Ugghh I just went thru the process of updating a7800x (based on MESS) with the new "old" palette and redoing my screenshots.

 

Guess I'll add this to my todo list that has been piling up lately for some odd reason.

 

Sorry.

 

Actually, this shouldn't effect screenshots really at all as I don't believe any of the existing games use any of the particular colors I adjusted. I just wanted the gradation to be accurate and it wasn't before.

[Kr0tki]

However, The way the Prosystem emulator uses the palette is altogether different from how atari800 does even before your changes, and it would have to be re-written, which wouldn't necessarily be a bad thing, but is beyond my capabilities as a coder.

OK, I understand.

 

But anyway you still might want to build Atari800 from CVS - an option has been added in the Atari800's Display Settings to export the current palette to a file, so it could save you some work.

[Underball]

However, The way the Prosystem emulator uses the palette is altogether different from how atari800 does even before your changes, and it would have to be re-written, which wouldn't necessarily be a bad thing, but is beyond my capabilities as a coder.

OK, I understand.

 

But anyway you still might want to build Atari800 from CVS - an option has been added in the Atari800's Display Settings to export the current palette to a file, so it could save you some work.

 

That would be really cool. Problem is, my atari800 source is all hacked up to work on the PSP, not a clean atari800 source, and my compile environment is tailored to the PSP only.

 

It would be a whole lot of work getting the current CVS to compile as I'd have to set up an entirely new compiling environment for the win32 version of atari800.

 

Any chance you could spit out a palette file for me?

[Kr0tki]

that's actually not an easy task, since - well, I don't know what contrast, saturation etc. you'd want

 

So I tried to match the output of Atari800 with the screenshot You've provided. I've noticed two things:

- Kinda strange, but hue 1 on 7800 is not hue of the colorburst signal. Specification of GTIA clearly states that hue 1 is the colorburst signal, so I wonder why in MARIA it's not the case;

- there are several irregularities in your screenshot (f.e. why is hue 14 so close to hue 15?) - I'm assuming they are not in the source signal from MARIA, but are introduced by your TV.

 

Anyway, here's a palette that is the best match I could create. Note that lumas 0 and 15 are not pure black and white. It is intentional - that way colours in luma 0 and 15 are rendered correctly.

 

So, maybe MARIA produces colours differently that GTIA anyway?

7800ntsc.act.zip

Edited January 9, 2010 by Kr0tki

[Trebor]

I'm always interested in this topic and here's my take on the matter. First and foremost, thanks to Underball and Kr0tki for their interest in this area. Let's do some comparisons using the Xenophobe title screen as a reference point.

 

Here is what it should/suppose to look like per MobyGames:

 

Here is the Kr0tki Palette:

 

Here is the default palette in ProSystem 1.3:

 

Here is Underball's latest Palette:

 

My personal experience and reference on the actual console displays colors extremely close to Mobygames and similar to the ProSystem/Underball palette with slightly more color saturation. Kr0tki's palette is definitely too pink/red at least respecting whatever codes are being referenced in the Xenophobe title screen.

 

As a side note, MobyGames does show excellent colors for their 7800 captures which come closest to my experience on the real 7800 with just slightly less color saturation. Take the Ms. Pac-Man captures for example:

 

http://www.mobygames.com/game/atari-7800/ms-pac-man/screenshots/gameShotId,55285/

 

Now *that* is how Ms. Pac-Man looks on my 7800 (With some additional color saturation and color bleeding). Hopefully, one day we will have true NTSC color emulation implemented in Atari 7800 emulators...

 

http://www.fly.net/~ant/libs/ntsc.html

 

Until then, I do appreciate the work done regarding this area of emulation. I wish I knew how to program/code. Perhaps someday I may take a crack at it...lol.

 

-Trebor

Edited January 9, 2010 by Trebor

[GroovyBee]

This is the only information I can find on MARIA colour generation :-

 

"The COLor circuitry uses an analog input voltage (the DEL pin) to adjust an internal multi-tap shift register delay line. The chroma sub-carrier for NTSC is a 3.58MHz clock divided down from the 14.32MHz SYSCLK and controllably phase-delayed to any of 15 angles (0 to 336 degree) with respect to the colorburst signal which is output after each horizontal SYNC pulse. The chroma sub-carrier for PAL is an external 4.43 MHz COLCLK, with the color bursts generated at +/- 132 degrees (internal delay-line taps 2 and 13) with 180 deg. (yellow) at tap no. 15."

 

@Kr0tki: Any chance of a 7800 PAL palette?

 

@Trebor: The MobyGames images for Xenophobe are taken from an emulator. Its not the same one as ProSystem because it doesn't appear to have the same DLI display bug.

[Kr0tki]

This is the only information I can find on MARIA colour generation :-

 

"The COLor circuitry uses an analog input voltage (the DEL pin) to adjust an internal multi-tap shift register delay line. The chroma sub-carrier for NTSC is a 3.58MHz clock divided down from the 14.32MHz SYSCLK and controllably phase-delayed to any of 15 angles (0 to 336 degree) with respect to the colorburst signal which is output after each horizontal SYNC pulse. The chroma sub-carrier for PAL is an external 4.43 MHz COLCLK, with the color bursts generated at +/- 132 degrees (internal delay-line taps 2 and 13) with 180 deg. (yellow) at tap no. 15."

That's the same like GTIA, at least in NTSC. So hue1 is indeed the colorburst phase. It would mean that Underball's TV (or his 7800) has incorrect tint setting (colorburst is more greenish than his hue 1).

 

@Kr0tki: Any chance of a 7800 PAL palette?

 

First you guys provide screenshots from a real PAL 7800, then we could talk.

 

As for NTSC: in this thread I've posted a tool, "palgen_ntsc", which generates NTSC GTIA palettes based on user-given parameters for contrast, brightnesss, saturation, etc. Give it a try.

[Trebor]

Underball's TV (or his 7800) has incorrect tint setting (colorburst is more greenish than his hue 1).

 

 

Don't know if I would call it "incorrect". They match pretty close to what I see on both a CRT 27" TV as well as a LCD HD 32" set.

 

This person's capture from the real system and TV...

[between 18-24 seconds]

 

...Also seems to have the same results as seen in the ProSystem/Underball palette, whereas your palette has a red/pink overtone to it, evident in the Xenophobe title screens I posted earlier.

 

Again, what is really need here is true NTSC color generation/reproduction in Atari 7800 emulators. I guess until then everyone will have an opinion on what is correct and incorrect

 

-Trebor

[Kr0tki]

So then that info on MARIA's colour generation is slightly not exact. Colorburst (which is 180 degrees in YIQ colourspace) is definitely more greenish than MARIA's hue 1.

Edited January 9, 2010 by Kr0tki

[Underball]

Let's clear up a few things here:

 

1. the Mobygames screenshots are from the OLD/original Prosystem palette before I created a new one, which was WAY off NTSC standard. the Red/Magenta push present in it tells me the person who created it used a Panasonic (or equivalent Matsushita product) to guesstimate based on their TV, which clearly needed serious calibration.

 

2. My TV's color is just fine. It's a 27 RCA I calibrated myself with an X-rite colorimiter. I'm also a part time ISF calibration tech/enthusiast.

 

3. Admittedly, the prosystem palette I created isn't exactly what most people will see on their TV's. Teh one in Prosystem 1.3e is also mine. This latest one is a corrected version of it. It's what people would see if their TV's were still in good shape, and properly calibrated and tuned. Most people's TV's are way off proper contrast/brightness and color temp, nevermind suspect color decoding and age/fade issues. This is especially true of older CRT TV's like most of us use for classic gaming. I intentionally punched up the colors a bit, and calibrated it to absolute black, which most TV's, especially older CRTs can't display with 100% accuracy. So really this palette is what it should look like, even though in reality, it's unlikely it ever would.

 

GTIA and MARIA define colorspace in such a different enough way, that neither palette will ever match. We'd be chasing our collective tails trying to get it to.

[Kr0tki]

So then that info on MARIA's colour generation is slightly not exact. Colorburst (which is 180 degrees in YIQ colourspace) is definitely more greenish than MARIA's hue 1.

Sorry for my mistake; phase of the colorburst is 180 degrees in YUV, not in YIQ.

 

 

GTIA and MARIA define colorspace in such a different enough way, that neither palette will ever match. We'd be chasing our collective tails trying to get it to.

I can see that from the screenshots, bu what makes me wonder is that according to GroovyBee's information on MARIA, they both should generate colours in the exact same way.

Edited January 10, 2010 by Kr0tki

[Trebor]

Hey Underball,

 

The Mobygames screenshots are from 2003. The ProSystem emulator was released in 2005. I'm not sure how those screenshots were generated, but don't believe it is possible for them to have been taken with the ProSystem emulator using an older palette. Additionally, MESS never had that color palette and neither did V7800 (Dan Boris'/The first 7800 emulator, AFAIK).

 

Regardless as been mentioned, palette opinions will vary, even greatly at times. The implementation of true NTSC video simulation (Complete with saturation/color, hue/tint, sharpness, brightness, contrast) for the Atari 7800 emulators would be the best route. Some emulators which already feature it are kat5200, Nestopia, ZSNES, bsnes, Kega Fusion, Stella has even started implemented it, and others.

 

In the meantime, I am very grateful for the palette(s) you have provided as they are the best/closest applied thus far to emulation.

 

-Trebor

[Underball]

Hey Underball,

 

The Mobygames screenshots are from 2003. The ProSystem emulator was released in 2005. I'm not sure how those screenshots were generated, but don't believe it is possible for them to have been taken with the ProSystem emulator using an older palette. Additionally, MESS never had that color palette and neither did V7800 (Dan Boris'/The first 7800 emulator, AFAIK).

 

Regardless as been mentioned, palette opinions will vary, even greatly at times. The implementation of true NTSC video simulation (Complete with saturation/color, hue/tint, sharpness, brightness, contrast) for the Atari 7800 emulators would be the best route. Some emulators which already feature it are kat5200, Nestopia, ZSNES, bsnes, Kega Fusion, Stella has even started implemented it, and others.

 

In the meantime, I am very grateful for the palette(s) you have provided as they are the best/closest applied thus far to emulation.

 

-Trebor

Krotki's way of working the colorburst generation in atari800 is great, and defintely the direction to go in I unfortuantely have no idea how to rework it to work within the Prosystem source.

[GroovyBee]

If PAL CC2 users could download the utility here and take a picture/capture of the TV screen it'll start the ball rolling towards a good emulator PAL palette (with kr0tki's help ).