Atari800win Plus Default Colors?

[+Larry]

V4.0 Beta 7

I posted this in the Emulation section, but no takers thus far. Since we have quite a few emulator users here...

 

The default colors don't look correct. I can get the background an acceptable shade of blue, but the foreground/text is too dark. Has anyone achieved a pretty good combination of Gr. 0 color and luminance on this emulator? If so, what are your settings?

 

Thanks,

Larry

[Irgendwer]

V4.0 Beta 7

I posted this in the Emulation section, but no takers thus far. Since we have quite a few emulator users here...

 

The default colors don't look correct. I can get the background an acceptable shade of blue, but the foreground/text is too dark. Has anyone achieved a pretty good combination of Gr. 0 color and luminance on this emulator? If so, what are your settings?

 

Thanks,

Larry

 

See

 

http://www.atariage.com/forums/index.php?s...4916&st=575

 

CU

Irgendwer

[Bryan]

I made a version 3.1 palette since I liked how things looked in that version:

palette.zip

[+Larry]

I made a version 3.1 palette since I liked how things looked in that version:

 

Thanks for the replies. I tried the external palette, but that doesn't solve the issue I perceive. Here are a couple of screen shots that show what I'm referring to.

 

 

Probably this would have to be changed in the emulator code. My point is that I think the luminance values are incorrect as written. And there may be good reasons for the way they appear, but seems like it would be a "nice to have" setting in the emulator to be able to change the "contrast."

 

-Larry

[Bryan]

Ahh... what you want is probably a Gamma setting. Gamma deals with the linearity of signal to brightness. PC monitors tend to be fairly linear (for graphics), which leads to a duller look than TV's. You could simulate this with a custom palette.

[+Larry]

Ahh... what you want is probably a Gamma setting. Gamma deals with the linearity of signal to brightness. PC monitors tend to be fairly linear (for graphics), which leads to a duller look than TV's. You could simulate this with a custom palette.

 

After reading about the file characteristics of the .ACT (palette) file, yes, a custom palette should work. I'll try editing yours and see where that leads. If I'm successful, I'll post the results.

Thanks,

Larry

[pseudografx]

I suggest checking this thread: http://www.atariage.com/forums/index.php?s...07853&st=40

...and trying the .act I made out of the models developed there (currently only for PAL).

[+Larry]

I suggest checking this thread: http://www.atariage.com/forums/index.php?s...07853&st=40

...and trying the .act I made out of the models developed there (currently only for PAL).

 

Thanks for the info and link!

 

On my NTSC system, the PAL palette is somewhat dark and shifted toward green.

 

However, I have started experimenting with it using a HEX editor. I think it is possible to write a Q&D BASIC program to automate making changes to the palette, after I get some sense of what changes work properly. We'll see.

 

Since you have already worked with the palette, can you confirm that the file is arranged as

 

(Start of file)

 

Color 0; Lum 0 (RGB)

Color 0; Lum 1 (RGB)

...

...

Color 15; Lum 15 (RGB)

 

(EOF)

 

Thanks,

Larry

Edited December 23, 2007 by Larry

[pseudografx]

Since you have already worked with the palette, can you confirm that the file is arranged as

 

(Start of file)

 

Color 0; Lum 0 (RGB)

Color 0; Lum 1 (RGB)

...

...

Color 15; Lum 15 (RGB)

 

(EOF)

 

Thanks,

Larry

Yes, this is the correct order.

[+Larry]

Since you have already worked with the palette, can you confirm that the file is arranged as

 

(snip...)

 

Thanks,

Larry

Yes, this is the correct order.

 

Thanks. This is on this week's "to-do" list.

 

-Larry

[+Larry]

Some progress and a question:

 

First, I found several external palettes in the Atari800Win "Palette" folder. Of these, the Xformer.act palette looks closest to what I think the colors should look like, but still not quite right. By bumping up the white level in the palette controls, I can brighten the foreground and background a bit, making it closer to "correct." But I still cannot come close to the text brightness on the real Atari -- the emulator is always much darker.

 

I'd still like to still bump up the luminance, especially in the default BASIC/DOS Gr. 0 colors. So I think that means that I would need to increase the (0-255) values of RGB in the palette file.

 

The default background color held in location 710 is 148. That is color 9 (blue-green) + a luminance value of 4 (9*16+4=148).

The luminance value for GR. 0 foreground is held in (shadow) location 709. The default value is 202 on my NTSC system.

 

So in order to bump up the text luminance in the Atari800Win+ palette, I *think* that I need to increase the RGB values in location 202*3=606, 607, and 608 in the palette file.

 

I did that and as best I can determine, nothing much happens to the luminance. (Maybe a little bit brighter.) It almost looks like the 0-255 scale for RGB is not correct. i.e. in order to achieve significant levels of brightness, something is missing.

 

Perhaps someone can comment on what I'm seeing.

 

-Larry

[Bryan]

If you made that screenshot of the XE, then that should be the basis for making a palette. Put an object on the screen of a particular color, then examine the screenshot in a graphics program to see what the RGB values are.

 

Heck get that 256 color demo and digitize that. Then you can extract all of them at once.

[+Larry]

If you made that screenshot of the XE, then that should be the basis for making a palette. Put an object on the screen of a particular color, then examine the screenshot in a graphics program to see what the RGB values are.

 

Heck get that 256 color demo and digitize that. Then you can extract all of them at once.

 

Hi Bryan-

 

Thanks, that's a good suggestion, and I'll do it. My vague recollection is that the RGB values shown in PC graphics programs go much larger than 0-255 (two-byte values). If so, that would explain why A8W+ is "dark." I have Adobe Photoshop Elements, so I'll re-install that and give it a try.

 

-Larry

[Urchlay]

My vague recollection is that the RGB values shown in PC graphics programs go much larger than 0-255 (two-byte values). If so, that would explain why A8W+ is "dark." I have Adobe Photoshop Elements, so I'll re-install that and give it a try.

 

Photoshop stores more than 8 bits per color, but most (all?) PC video cards only actually display 8 bits per color (RGB, 24-bit, or 32-bit with an alpha channel). The extra precision in Photoshop is used to avoid roundoff errors, and possibly for very expensive printers that can do more than 8 bits per color (assuming they exist, I don't know). Making an emulator use more than 8 bits per color wouldn't help because unlike Photoshop, the emulator isn't doing math on the colors, it's just displaying them.

 

The thing about emulator palettes is that there are so many other factors that can affect the perceived colors:

 

- Monitor make/model and type (CRT vs LCD, analog vs digital video)

- Monitor brightness/contrast/gamma/color-temperature settings

- For some video cards, color calibration and gamma settings in the driver

- Even the cabling might make a difference, for analog SVGA

 

Also, when you're comparing the emulator's video to the Atari's, you're seeing the Atari displayed on some sort of monitor/TV, which also has its own set of color/brightness/tint/etc controls... not to mention, the different A8 models have wildly different video output (800, 1200XL, early/late model 800XL, XE all have different displays, compare them & see). Then there's RF vs composite vs s-video... and the fact that the Atari has a color adjustment that can get out of whack... even the Atari power supply voltage can affect the colors. What looks like a "real Atari" depends on what you're used to.

 

I guess what I'm saying is that you'll never design the One True Palette that will make everyone's emulator look like the real thing. The best you can do is build a palette that makes your emulator (running on your PC setup) look like your Atari... but give that palette to someone else, and it will look wrong to him unless he's got exactly the same Atari and PC hardware, with all the settings set the same way.

 

It doesn't mean you should stop trying, it just means your solution will probably only work for you (which is why the emulators support user-defined color palettes in the first place).

 

Forgive me if I'm telling you what you already know... I spent much time beating this particular horse before I found out it was dead

[+Larry]

My vague recollection is that the RGB values shown in PC graphics programs go much larger than 0-255 (two-byte values). If so, that would explain why A8W+ is "dark." I have Adobe Photoshop Elements, so I'll re-install that and give it a try.

 

Photoshop stores more than 8 bits per color, but most (all?) PC video cards only actually display 8 bits per color (RGB, 24-bit, or 32-bit with an alpha channel). The extra precision in Photoshop is used to avoid roundoff errors, and possibly for very expensive printers that can do more than 8 bits per color (assuming they exist, I don't know). Making an emulator use more than 8 bits per color wouldn't help because unlike Photoshop, the emulator isn't doing math on the colors, it's just displaying them.

 

The thing about emulator palettes is that there are so many other factors that can affect the perceived colors:

 

- Monitor make/model and type (CRT vs LCD, analog vs digital video)

- Monitor brightness/contrast/gamma/color-temperature settings

- For some video cards, color calibration and gamma settings in the driver

- Even the cabling might make a difference, for analog SVGA

 

Also, when you're comparing the emulator's video to the Atari's, you're seeing the Atari displayed on some sort of monitor/TV, which also has its own set of color/brightness/tint/etc controls... not to mention, the different A8 models have wildly different video output (800, 1200XL, early/late model 800XL, XE all have different displays, compare them & see). Then there's RF vs composite vs s-video... and the fact that the Atari has a color adjustment that can get out of whack... even the Atari power supply voltage can affect the colors. What looks like a "real Atari" depends on what you're used to.

 

I guess what I'm saying is that you'll never design the One True Palette that will make everyone's emulator look like the real thing. The best you can do is build a palette that makes your emulator (running on your PC setup) look like your Atari... but give that palette to someone else, and it will look wrong to him unless he's got exactly the same Atari and PC hardware, with all the settings set the same way.

 

It doesn't mean you should stop trying, it just means your solution will probably only work for you (which is why the emulators support user-defined color palettes in the first place).

 

Forgive me if I'm telling you what you already know... I spent much time beating this particular horse before I found out it was dead

 

Hi Urchlay-

 

Thanks for your input, and yes, I agree with all of the factors that you mention. Certainly "color" as well as "beauty" lies in the eye... (for many reasons).

 

My main issue is the brightness of the higher luminance values, and in particular the luminance of Graphics 0 text. Since I rarely play games and only work with text-based programs in the emulator, the text color (luminance) is important to me.

 

Since you have already flogged this horse, you may be able to help me. Here is my line of thinking:

 

The shadow registers for Gr. 0 are 710 (background) and 709 (foreground/text)

 

The default Gr. 0 colors are 710 = 148 (Blue-green; luminance of 4) and 709=202 (green; luminance value of 10)

(I also have no clue why Atari chose 202, since it is the luminance value of 10 for color 12 (Green), but any color value should produce the same results so long as it has a luminance value of 10.)

 

Now, when running the emulator, I can POKE 709 with 12 and things look a quite a bit better. POKE it with 14, and it is quite pleasing to my eye.

 

How then can I change an external palette to accommodate my sense of "color correctness?"

 

The way I approached this is that since the default luminance value is 202, then this would be taken from the 202nd position in the palette. The palette is 768 bytes long, 256 * 3,

so I think that I would need to modify values palette values 606, 607, and 608 to "brighter" values, e.g. closer to 255. So since this represents a default luminance of 10, I actually took the higher values in the same group (of 0-15) and moved them *down* to positions 606, 607, and 608 in a Hex editor and saved the changes.

 

But somehow this must be wrong, since I could not get anything like the brightness that I see by simply POK(E)ing higher luminance values into location 709.

 

Does this approach/line of thinking seem correct?

 

Thanks,

Larry

[Urchlay]

The way I approached this is that since the default luminance value is 202, then this would be taken from the 202nd position in the palette. The palette is 768 bytes long, 256 * 3,

so I think that I would need to modify values palette values 606, 607, and 608 to "brighter" values, e.g. closer to 255. So since this represents a default luminance of 10, I actually took the higher values in the same group (of 0-15) and moved them *down* to positions 606, 607, and 608 in a Hex editor and saved the changes.

 

But somehow this must be wrong, since I could not get anything like the brightness that I see by simply POK(E)ing higher luminance values into location 709.

 

Does this approach/line of thinking seem correct?

 

It sounds like it should work... possibly you were off by one position, in the hex editor? Try running one of those 256-color simultaneous demos with the original palette and again with your modified one, should be able to spot which color(s) you actually changed.

 

I'd sooner edit the OS ROM and change the default color there... modifying the emulator's palette would mess up anything (game, demo, etc) that happened to use color value 202. Changing the ROM default probably wouldn't affect any games/demos, since they pretty much all set the color registers to something other than the defaults.

 

For the XL ROM, the default COLOR1 value is at $FB09 (offset $3B09 if you're using a hex editor on "atarixl.rom"). On the 800, it's at $FEC2 (offset $1EC2 in atari800.rom). Whatever you put in this location is what the OS will set COLOR1 (aka GR.0 text luminance) to, at boot, or whenever the GRAPHICS command is executed.

 

One minor fly in the ointment is that the XL self-test will think the ROM is bad, if you change it without changing the stored checksum... but this won't hurt anything (you'll just see red bars in the memory test, if you should decide to run it). I just tried editing byte $3B09 of atarixl.rom (changed it to $CF) and ran it with the Atari800 emu, and BASIC comes up fine, with nice bright text.

[+Larry]

It sounds like it should work... possibly you were off by one position, in the hex editor? Try running one of those 256-color simultaneous demos with the original palette and again with your modified one, should be able to spot which color(s) you actually changed.

 

I'd sooner edit the OS ROM and change the default color there... modifying the emulator's palette would mess up anything (game, demo, etc) that happened to use color value 202. Changing the ROM default probably wouldn't affect any games/demos, since they pretty much all set the color registers to something other than the defaults.

 

For the XL ROM, the default COLOR1 value is at $FB09 (offset $3B09 if you're using a hex editor on "atarixl.rom"). On the 800, it's at $FEC2 (offset $1EC2 in atari800.rom). Whatever you put in this location is what the OS will set COLOR1 (aka GR.0 text luminance) to, at boot, or whenever the GRAPHICS command is executed.

 

One minor fly in the ointment is that the XL self-test will think the ROM is bad, if you change it without changing the stored checksum... but this won't hurt anything (you'll just see red bars in the memory test, if you should decide to run it). I just tried editing byte $3B09 of atarixl.rom (changed it to $CF) and ran it with the Atari800 emu, and BASIC comes up fine, with nice bright text.

 

That is a great suggestion, but it brings up two other questions:

 

Do you also know the ROM location code of the default background (color2) for Gr. 0 for both the XL and the 800? (I'd love to also change the very-dark Omnimon colors.)

 

And do you know how the XL OS Rom checksum is calculated? It would be nice-to-have to also "fix" the checksum.

 

-Larry

[Urchlay]

Do you also know the ROM location code of the default background (color2) for Gr. 0 for both the XL and the 800? (I'd love to also change the very-dark Omnimon colors.)

 

They're stored in a table in ROM... add one to the COLOR1 location to get COLOR2. That's for the 800 and XL though, no idea whether Omnimon uses a table (though it probably does), or where it's stored (could be the same place, doesn't have to be though).

 

You could always find out the default colors for Omnimon for COLOR0 through COLOR4 (708-712), and search for those 5 bytes in sequence in the Omnimon ROM... could do it in a PC language, reading the omnimon.rom file, or in Atari BASIC or whatever, reading the emulated machine's ROM.

 

And do you know how the XL OS Rom checksum is calculated? It would be nice-to-have to also "fix" the checksum.

 

According to "Mapping" appendix 12...

 

Bytes 49152-49163 ($C000-$C00B) are used to identify the com-

puter and the ROM in the $C000-$DFFF block:

 

Byte Use

49152-3/C000-1 Checksum (LSB/MSB) of all the bytes

in ROM except the checksum bytes

themselves.

 

...

 

Checksum and identification data for the ROM area

57344-65535 ($E000-$FFFF--see 49152, $C000 for more

information):

...

65528-9/FFF8-9 Checksum, bytes (LSB/MSB)

 

It doesn't actually say how the calculation is done... but a little experimentation reveals that it's a simple checksum, modulo 65536. You add all the bytes from $C002 to $DFFF, and keep the bottom 16 bits... except if you're doing it on the Atari itself, the ROM at $D000-$D7FF actually appears at $5000-$57FF (only when you enable the self-test bit in PORTB though).

 

For the high half of the ROM, you basically do the same thing for location $E000-$FFFF, except you skip $FFF8 and $FFF9 (the checksum bytes).

 

However... you're doing this for emulator use... but if you've got the SIO patch and/or H: devices enabled, the self-test will fail anyway! The emulator's OS patches don't update the ROM checksums, so even with an unpatched atarixl.rom, the ROM self-test shows red bars in Atari800 unless you disable the emulator's patches and let disk I/O take forever

 

IIRC, you're a BASIC programmer, so here's my attempt to do it in Atari BASIC. Try not to laugh, I haven't used BASIC in many years...

 

10 POKE 106,80:GRAPHICS 0:REM Set RAMTOP to $5000 so the self-test ROM won't confuse BASIC
20 IF PEEK(54017)>128 THEN POKE 54017,PEEK(54017)-128:REM enable self-test ROM (map $D000-D7FF to $5000-$57FF)

30 ? "Checking $C000-$DFFF..."
40 SUM=0:FIRST=49154:LAST=53247:GOSUB 1000:REM $C000-$CFFF
50 FIRST=20480:LAST=22527:GOSUB 1000:REM $D000-$D7FF (remapped to $5000)
60 FIRST=55296:LAST=57343:GOSUB 1000:REM $D800-$DFFF
70 ROMSUM=PEEK(49152)+256*PEEK(49153)
80 GOSUB 2000

90 ? "Checking $E000-$FFFF..."
100 SUM=0:FIRST=57344:LAST=65527:GOSUB 1000:REM $E000-$FFF7
110 FIRST=65530:LAST=65535:GOSUB 1000:REM $FFFA-$FFFF
120 ROMSUM=PEEK(65528)+256*PEEK(65529)
130 GOSUB 2000

140 ? "Press RETURN to exit...";:GET #16,K
150 POKE 54017,PEEK(54017)+128:GRAPHICS 0:REM disable self-test ROM
160 END

999 REM Checksum an area of memory, from FIRST to LAST, running total in SUM
1000 FOR I=FIRST TO LAST
1010 SUM=SUM+PEEK(I)
1020 IF SUM>65535 THEN SUM=SUM-65536
1030 NEXT I
1040 RETURN

1999 REM Print results
2000 ? "  Calculated checksum: ";SUM
2010 ? "  Stored checksum: ";ROMSUM
2020 IF SUM=ROMSUM THEN ? "  Checksum OK"
2030 IF SUM<>ROMSUM THEN ? "  Checksum BAD"
2040 RETURN

 

Hm, that was kind of fun, it's been a while... Guess it's like riding a bicycle, it comes back to you.

 

Might as well include an ATR image too: rom_checksum_atr.zip

 

If you run that on a real 800XL with the stock OS ROM, or in an emulator with SIO and H: patch disabled, you should get "Checksum OK" for both blocks. With the SIO/H: patch, it'll fail, just like the built-in self test. Not sure what happens if you run it with Turbo BASIC (does PEEKing ROM show you the real contents of ROM, or the RAM-under-ROM that Turbo BASIC is using?)

[+Larry]

Hi Urchlay-

 

Thanks, that is superb, and *greatly* appreciated.

 

The BASIC code is great - yep, I'm pretty much stuck in BASIC; dabble in ACTION! when forced by speed; and only capable of very small ML routines. BASIC is so user-friendly!

 

Thanks again,

Larry

[Urchlay]

yep, I'm pretty much stuck in BASIC; dabble in ACTION! when forced by speed; and only capable of very small ML routines. BASIC is so user-friendly!

 

Back in the late 1980s I was really happy to have Turbo BASIC XL. I wrote a ton of stuff in plain BASIC, then learned Pascal and C on PCs... which kind of ruined Atari BASIC for me: no while loops, no if/then/else, no procedure/function arguments or return value, no local variables... Turbo BASIC at least has some of those.

 

I probably would have *loved* Action if I'd been able to afford a copy back then. Instead I learned 6502 assembly, and still use it for the little bit of Atari 8-bit and 2600 code I write these days (DASM cross-assembler; am spoiled by modern machines, wouldn't ever want to actually write/edit code *on* the 8-bit!)

 

On the other hand... writing that bit of BASIC checksum code was kind of fun.

[+Larry]

A brief follow-up...

 

I now have a nice, bright emulator (text) screen.

 

When I first ran the checksum program on my real hardware, I was getting "BAD" checksums. That's odd! At first, I suspected my Black Box of somehow corrupting the results, but then reasoned that it was more likely Basic XE, since it replaces part of the OS with its math pack. Ditto Turbo Basic, which corrupts both tested segments. Probably some others, too, such as SDX (?), depending on how it is configured.

 

I did thoroughly read that section of appendix twelve in Mapping the Atari -- there is so much good info in that book.

 

This thread produced some really good info for me thanks to Urchlay -- thanks again!

 

-Larry