Power-Up Palette Values

Power-Up Palette Values
by WedNESday on 2005-10-23 (#5775)

Can we all agree that the best values to have in palette memory when a ROM is loaded is either $0D, $0E or $0F? That way the screen won't flash grey for the first frame or two. I know that all NES's had pre-set values and some say that different colours would flash up, so I think that for neutrality reasons and for best results having a totally black palette on ROM load would be best. I don't believe that any game relies on the palette entries to run, but does anyone else?

by blargg on 2005-10-23 (#5785)

Why introduce (possible) inaccuracy when your emulator can simply display a black screen until the game writes to palette entry 0? If I have a free moment I'll modify my emulator to scan a few thousand ROMs to find if any read from the palette before writing to it.

by WedNESday on 2005-10-23 (#5786)

I don't believe that doing so would make the emulator inaccurate. Waiting for a game to write to Colour 0 would be inaccurate, but setting all Palette values to a black colour would not effect any games (or is highly unlikely). Why do you think it would be wrong?

by tepples on 2005-10-23 (#5790)

Or you could just blank the screen for the first 5 frames. Many TVs, when they receive a new signal, take a split second to grab the vsync; you'd be emulating that behavior of a TV.

by blargg on 2005-10-23 (#5792)

Quote:
I don't believe that doing so would make the emulator inaccurate.

If no actual NES ever power-up with the proposed palette values, then it is inaccurate, since code can be written which behaves differently in an emulator, but consistently on all NES units (assuming that palette entry 0 is never black on any NES unit).

Quote:
Waiting for a game to write to Colour 0 would be inaccurate, but setting all Palette values to a black colour would not effect any games (or is highly unlikely).

That seems backwards to me. You're proposing to use palette values that can be detected by code running on the emulator. My proposed solution (and tepples') have no effect on accuracy as code cannot detect it, short of asking the player whether the screen flashed a color at power-up.

My idea is to keep a boolean flag for palette entry 0 (or one for each entry, if you want to be thorough) that is clear at power-up and set the first time a write to that entry occurs. Then in your "PPU rendering off" code you use black in place of palette entry 0 if this flag is false.

As to the likelihood of a game relying on power-up palette values, that can be replaced with certainty by either scanning all NES ROMs, or writing a ROM that specifically reads palette entry 0 at power-up and crashes if it's set to black (assuming that no actual NES powers up with that value). :)

Update: I wrote a tool and had it scan about 3400 ROMs for reads from a palette entry before it was written (stopping after one minute if none occurred). Only Bandai Golf read from a palette entry before writing to it, but it ignored the value. So, if you're emulating NES games, it probably doesn't matter (but I don't have every ROM so I can't be sure). If you're emulating NES hardware, the values at power-up matter.

In case the power-up palette test ROM I released is relevant here, that merely checks whether the palette matches that of my NES, which would obviously fail on NES units which have different power-up values. I personally don't think that all the test ROMs I've released (and am going to release) are worth making an emulator pass unless the prime goal is accurate hardware emulation.

by tepples on 2005-10-23 (#5801)

One frontloading NTSC NES I've owned blinked between $0D blacker-than-black and what definitely looked like $00 gray as the default color $3F00; my current frontloader blinks between $0D blacker-than-black and some shade of yellow. It's likely that during those PPU revisions where power-on filled the RAM with unique values (like the wave RAM on classic Game Boy units), at least some units had $xF. Specifically, $3F has all bits set, which is a common initial value for memory cells.

And it's true that some inaccuracies (such as >8 sprites on a line) are useful to implement for user experience's sake, but there should be at least one accuracy-über-alles emulator for each host platform on which NES software development takes place. Currently all there is is Nintendulator for Wintendo.

by Bregalad on 2005-10-24 (#5816)

Well, my NES blinks with a color nearly black, but not exactly black, but it's a dark grey, definitely darker than $00 is. I think it should be color $2d or $1d maybe.
The reason because each NES turn on with a different value is simple, just take two NAND gates and mont them in /R/S flip-flop (the exits of each gate goes on the entry of the other gate, respectively, and the second entry is the /R or /S signal), and watch what is at the exit of one of the two gates. Be sure to tie both /R and /S high, and turn the power up. You can't say if your exit will be on high or low states, because both are rignt. But you can turn the power on and off as many times as you want, you'll most probably always get the same state on power up. By changing the componants making your flip-flop (the gates), this power up state may change, but it'll be usually the same for the same componants.
Because RAM chpis containing data for palettes are nothing else than a huge amount of flip-flops, all bits can be neither one or zero at power up.

by WedNESday on 2005-10-25 (#5871)

Bregalad wrote:
...all bits can be neither one or zero at power up.

Erm, doesn't that defy the rules of logic?

by Bregalad on 2005-10-25 (#5890)

Not really. Consider a NAND gate, that just turn on when the power went up.
One of the inputs is tied high, so don't care with it. The other input is tied to the output of the parealel gate making a flip-flop effect. You can't know if this signal will be considered to be high or low, because just before both gate didn't work because the alimentation voltage wasn't high enough, so the output can't really be used as a know state. Now, this unknow number is ANDED with 1, so there is no change, and then inverted. Once this is done, this output will go trough the other NAND gate, and be inverted on it's output. So this loop continues as long as both /R and /S inputs are high, making memory state. In practice, it will be more often 1 than 0 on power up for an unknow reason, but it can be 0 as well.

by Quietust on 2005-10-25 (#5897)

I suppose it be pointed out that the PPU palette data is stored in dynamic RAM; even if it IS initialized at powerup, if it doesn't get refreshed (due to turning off rendering, for example) then it will degrade to some other indeterminate pattern.

by Bregalad on 2005-10-25 (#5900)

Ah, I did't known of that.
That means that my flip-flopy theory doesn't apply to the NES' palette at all, because it wouldn't be made with those. But the principle is the same, unknown value at power up, but additionally unknown value if it isn't read for a while. If you don't use particular color on the screen (for example you have no sprites using another palette than palette 0), may the unused colors become inacurate ?

by WedNESday on 2005-10-26 (#5934)

Since we've already established that the palette contains different values on power-up, I still have to ask the same question again. If you leave the palette alone the screen will flash grey for a frame or two, which I think is best corrected by my first idea of filling the palette with 0x0F on a ROM load. I know that some of you may not agree with that idea, but I think that it is the best solution. Some of you may cry 'but that is not accurate!', but since there is no single solution I think that my way best.

Agreed?

by Bregalad on 2005-10-29 (#6060)

Scince there is any color at power-up, it definitely is wrong to say that black is innacturate. If the palette can be either pink or yellow, why not black ? Mine is nearly black, anyway.

by Guest on 2005-10-29 (#6070)

I kind of like seeing the screen flash a light color (my nes is blue) before the game starts. On my television, I can see the effect in pretty much every game, and I think an emulator should emulate this effect as it is what the original console did. If the idea is to mimic the console, this aspect shouldn't be ignored simply because it doesn't look as good (there are lots of in-game glitches that don't look as good but are still emulated - why make an exception for this one?).

by Bregalad on 2005-10-29 (#6072)

Anonymous wrote:
I kind of like seeing the screen flash a light color (my nes is blue) before the game starts. On my television, I can see the effect in pretty much every game, and I think an emulator should emulate this effect as it is what the original console did.

YOU did notice that effect because yours is blue, but I didn't notice something really funy myself, having a dark grayed console.

To be the most accurate, the best option would be to make the player choise it's own initial colour, while this would be totally useless and wasty on the other hand. Most emulators have $00 as the default palette. I think that ANY walue is accurate, scince every NES has a different color.

by blargg on 2005-10-29 (#6078)

Quote:
To be the most accurate, the best option would be to make the player choise it's own initial colour

Hah, I love this. That way you can have it match the very color your NES displayed (assuming you had one back in the day).

Quote:
Most emulators have $00 as the default palette.

I've noticed that the Game Genie uses gray as the background color when starting the original code.

Quote:
I think that ANY walue is accurate, scince every NES has a different color.

This can't be true, otherwise you could claim that a particular NES is inaccurate because it has one particular instead of the others. Maybe an uncollapsed quantum wave function of a NES would satisfy this. :)

As for the palette values at power-up, we've established that they are not consistent on different NES units, that none of 3500+ games rely on the initial values, and that being dynamic RAM, the first entry might start out as 0x0f. Each emulator author can make his own decision as to what is "best", but it's silly to try to have everyone here agree on something subjective (that being what tradeoffs to make between accuracy and enhancement).

by blargg on 2005-11-07 (#6342)

I just realized that you don't need to keep a flag for each palette entry, just a second "rendering" palette that you use for actual rendering but that the emulated code can never read from. At power-up, fill this palette with black ($0f) and fill the normal palette with whatever accurate power-up values you're using. Then when you have a palette write, write to both palettes. This way black is used until a particular palette entry is first written, then its normal color is used. The change is very minimal:

Code:
char palette [0x20];
char rendering_palette [0x20]; // added
char initial_palette [0x20] = { ... }; // initial palette values at power-up

void power_up()
{
memset( rendering_palette, 0x0f, 0x20 ); // added
memcpy( palette, initial_palette, 0x20 );
}

void write_palette( int addr, int data )
{
palette [addr] = data;
rendering_palette [addr] = data; // added
}

int read_palette( int addr )
{
return palette [addr];
}

void render_graphics()
{
...
int color = rendering_palette [index]; // changed
...
}