Various questions about the color palette and emulators

Various questions about the color palette and emulators
by JimDaBim on 2012-06-20 (#95704)

Hello,
I've got some questions about the NES and since they're rather technical, I guess this forum here is the right one for me.

OK, here are my questions:

Why does every NES emulator have a different color palette?
Isn't it possible to design the definite palette? I understand that different TVs have different color adjustments and therefore look differently. But that's the same with computer screens and still, every picture file, be it BMP, JPG, GIF or PNG etc. has definite, "objetive" color values. Yet, all NES emulators define their colors individually.
Why is that the case? How were the colors transferred from the NES to the TV?

Wouldn't the following be possible:
Take an NES ROM that displays all the various colors.
Copy it on a cardridge.
Put it into a real NES.
Show that demo NES game on a TV.
On the same TV, show a PC bitmap file that includes various colors.
Look which of the bitmap colors look identical to the NES colors.
And so, you have the RGB value for the NES colors.

Is there any color palette that comes closest to the display of an actual NTSC TV screen as it "usually" looks like?

Where did they get the colors from when they published some of the NES classics for the Game Boy Advance for Game Cube or the Wii Virtual Console? And do these games even have the same color palette among each other? So, does "The Legend of Zelda" for the Game Boy Advance has the same colors as "The Legend of Zelda" for Game Cube?

I've heard that Nestopia is cycle-accurate? What's the practical difference to emulators that are not cycle-accurate? For example, I never hear about FCEUX being cycle-accurate, so what is it instead?

What would you say is the best/most popular emulator for the NES?

In FCEUX, there is an option called "NTSC Color Emulation". If you check it, the colors change from the default palette. So, does that mean that the default palette in FCEUX is based on a PAL TV? That wouldn't really make sense to me. Isn't FCEUX an American product? The default screen resolution is the NTSC one, the default speed is the one from NTSC as well. If you want PAL resolution or speed, you have to explicitly check it. So, why aren't the NTSC colors chosen by default?

Re: Various questions about the color palette and emulators
by tepples on 2012-06-20 (#95705)

JimDaBim wrote:

Why does every NES emulator have a different color palette?

Because everybody's TV is calibrated differently. Do you know what the brightness, contrast, color, and tint knobs do on a TV?

Quote:

But that's the same with computer screens and still, every picture file, be it BMP, JPG, GIF or PNG etc. has definite, "objetive" color values.

At what color temperature? With yellow boost on or off? Sure, there's an "objective" standard to which studio monitors are calibrated, but various "image enhancement" methods implemented in TVs sold to the public make live-action footage look "better" at the cost of deviating from this standard. Should an emulator be emulating an NES connected to a studio monitor or an NES connected to a home TV?

Quote:

Wouldn't the following be possible:
Take an NES ROM that displays all the various colors.
Copy it on a cardridge.
Put it into a real NES.
Show that demo NES game on a TV.

So far, you've described running Loopy's palette demo on a PowerPak.

Quote:

On the same TV, show a PC bitmap file

For one thing, most PCs can't output video to a standard-definition television. A scan converter adds its own coloration to the signal. But what I have done is run my PowerPak and Nestopia side-by-side using picture-in-picture on a Vizio VX32L.

Quote:

Where did they get the colors from when they published some of the NES classics for the Game Boy Advance for Game Cube or the Wii Virtual Console? And do these games even have the same color palette among each other? So, does "The Legend of Zelda" for the Game Boy Advance has the same colors as "The Legend of Zelda" for Game Cube?

The gamma of the display of the original Game Boy Advance system is very, very dark, much darker than that of a TV or a PC monitor.

Quote:

I've heard that Nestopia is cycle-accurate? What's the practical difference to emulators that are not cycle-accurate? For example, I never hear about FCEUX being cycle-accurate, so what is it instead?

An emulator is cycle-accurate if all operations on the CPU, PPU, and APU take exactly the same number of cycles that they take on an NES. Pretty much all popular emulators have a cycle-accurate CPU, but the PPU and APU aren't quite as accurate in every emulator. There are corner cases of timing that are still being figured out, such as what happens if the CPU and PPU start a fraction of a cycle out of sync, or what happens when sprites are being moved at the same time sampled sound is being played.

Quote:

In FCEUX, there is an option called "NTSC Color Emulation". If you check it, the colors change from the default palette. So, does that mean that the default palette in FCEUX is based on a PAL TV?

A lot of the default color palettes shipped with emulators are based on old guesses that happened to look good at the time, not based on any theory of how the NES generates its signal. The NTSC NES picture contains artifacts on fine details, which may color the player's perception of particular colors.

by JimDaBim on 2012-06-20 (#95719)

Thanks for the answers.

tepples wrote:
Should an emulator be emulating an NES connected to a studio monitor or an NES connected to a home TV?

I would say the emulator should emulate the NES in a way that the image on the screen looks exactly like if you connect an actual NES to that same screen.
Sure, a TV screen has brightness and all that stuff. But those things are there anyway. If you connect a PC to a screen, you still could adjust the screen. But the thing that I don't understand about emulators: Why do two emulators look differently, even on the same screen? Why is the hardware-related issue of screen adjustment even a topic in the emulator software? Doesn't the NES send its color information as RGB values, just like a computer or a DVD player also sends them as RGB values?
Sorry if I sound naive. I don't really know how anything of that works. I just write those things to understand it better.

tepples wrote:
So far, you've described running Loopy's palette demo on a PowerPak.

So, do you have an actual palette file with the results that can be loaded into an emulator?

tepples wrote:
An emulator is cycle-accurate if all operations on the CPU, PPU, and APU take exactly the same number of cycles that they take on an NES. Pretty much all popular emulators have a cycle-accurate CPU, but the PPU and APU aren't quite as accurate in every emulator.

So, Nestopia is an emulator that actually does the PPU and APU accurately?

By the way, this is a bit off-topic, but do you know if MAME is cycle-accurate in CPU, PPU and APU?

tepples wrote:
The NTSC NES picture contains artifacts on fine details, which may color the player's perception of particular colors.

I guess you just described the NTSC filter, that option where you can make the image look like on an old TV. The option that is choosable next to special effects like HQ2x and Scale2X. But I was just talking about the option that can be found in the menu under "Config", "Palette", not the one in "Config", "Video", "Special Scaler".
If you check it, the colors slightly change. But I would have assumed that the default colors are for NTSC anyway.

By the way, do you know why waiting for VBlank and double buffering doesn't work in FCEUX when you disable the hardware acceleration (which is necessary so that the image looks pixelated and not blurry), but VSync works fine in Nestopia, even without bilinear filtering? With the default settings, I just don't get FCEUX to scroll smoothly. (It always looks as if a horizontal line is moving from bottom to top.) I would need one of those sync methods, but they are completely ignored as soon as I disable hardware acceleration.

by Disch on 2012-06-20 (#95720)

Quote:
Doesn't the NES send its color information as RGB values, just like a computer or a DVD player also sends them as RGB values?

No. Not at all. Nothing on the NES is RGB. This is probably what is leading to your confusion.

This is what it sends to the TV:
http://wiki.nesdev.com/w/index.php/NTSC_video

Understand it? Me neither. Neither do most other emu authors. Hence the inconsistency. Emulating output with an RGB palette (while inaccurate), is easy and works well enough. Which is why so many emus do it.

Quote:
So, do you have an actual palette file with the results that can be loaded into an emulator?

Many people have done the whole "take a screenshot of the video from a TV and make a palette off of it" to get a "100% accurate" palette.

The problem is:

1) output on everyone's TV is different, so any RGB value you pull from a screen capture is going to be wrong.
2) The signal the NES sends to the TV "blends" nearby colors. So a gray pixel isn't always gray if it's drawn next to a different colored pixel.

Quote:
So, Nestopia is an emulator that actually does the PPU and APU accurately?

There are several accurate emus, but NEStopia and Nintendulator are generally considered to be the most accurate. Although no emu will ever be 100% accurate.

Quote:
I guess you just described the NTSC filter,

That's the thing.. NTSC isn't really a filter, it's an output signal. The NTSC "filter" is actually emulating how the video signal gets sent from the NES to the TV. It's not just blurring the image to make it look like a TV.

by tepples on 2012-06-20 (#95723)

JimDaBim wrote:
If you connect a PC to a screen, you still could adjust the screen.

The "color" and "tint" are actually controlling the conversion from composite to RGB and thus don't apply to a PC. As Disch said, the NES generates the signal directly in the composite domain.

Quote:
Doesn't the NES send its color information as RGB values

The PlayChoice does; the NES doesn't.

Quote:
tepples wrote:
An emulator is cycle-accurate if all operations on the CPU, PPU, and APU take exactly the same number of cycles that they take on an NES. Pretty much all popular emulators have a cycle-accurate CPU, but the PPU and APU aren't quite as accurate in every emulator.

So, Nestopia is an emulator that actually does the PPU and APU accurately?

Nestopia and Nintendulator have more accurate timing than a lot of other emulators. But there's a reason I still use FCEUX on my 10" laptop: it's accurate enough for making game logic, and it runs at full speed even on an Atom CPU.

Quote:
do you know if MAME is cycle-accurate in CPU, PPU and APU?

MAME isn't one emulator; it's several hundred emulators, one for each supported arcade system board. Are you asking whether the PlayChoice driver in MAME is accurate?

Quote:
I guess you just described the NTSC filter, that option where you can make the image look like on an old TV.

The NTSC filter simulates an NES; everything else simulates a PlayChoice. A PlayChoice has a 52-entry lookup table from NES color numbers to RGB values, which it sends through three DACs to a standard-definition RGB monitor. An NES has only one DAC, and it generates a composite signal directly by rapidly alternating between the signal level for $00, $10, $20, or $30 and the signal level for $0D, $1D, $2D, or $3D. And as Disch pointed out, different TVs decode them differently.

Quote:
But I was just talking about the option that can be found in the menu under "Config", "Palette"

Those are theoretically the color in the middle of a flat area. Different people eyeball the colors differently.

by JimDaBim on 2012-06-20 (#95740)

Well, the whole color topic seems very complicated, but thanks for your help.
Is this only an issue on the NES? Or are the color palettes like for the Super Nintendo or other consoles that non-definite too?

tepples wrote:
The PlayChoice does; the NES doesn't.

So, shouldn't the colors of the PlayChoice be the basis for any emulator since those are basically the same games?

Since you use FCEUX, how do you make it scroll smootly? If I don't use any sync method, it will update the screen in a way that I always see a horizontal line going from bottom to top. But for some reason, the sync methods only work with enabled hardware acceleration (which I don't want since in this case, modern graphic cards use bilinear filter for stretching).

tepples wrote:
Are you asking whether the PlayChoice driver in MAME is accurate?

No, that was a completely unrelated question from the NES. I thought that cycle-related stuff works equally in every game in MAME. In my case, the original "Street Fighter II" would be of interest here.

tepples wrote:
Those are theoretically the color in the middle of a flat area. Different people eyeball the colors differently.

Sorry, I still don't get it. Especially the relation between the two palettes:

This the default palette in FCEUX:

And this is the "NTSC Color Emulation" palette:

If the second image is NTSC color emulation, what is the first image then? PAL color emulation? Unlikely, since it's an American emulator and all other options are by default set on NTSC, not on PAL. So, how can the first palette be called? And why isn't the NTSC color emulation enabled by default?

Last time, you said:
tepples wrote:
But what I have done is run my PowerPak and Nestopia side-by-side using picture-in-picture on a Vizio VX32L.
Did you save the color palette you devised with that method?

by tepples on 2012-06-20 (#95743)

JimDaBim wrote:
Is this only an issue on the NES? Or are the color palettes like for the Super Nintendo or other consoles that non-definite too?

It's mostly a problem with consoles from the NES era and earlier. Every console video chip since the Genesis has generated an RGB signal and encoded that to composite, though the encoding has its own artifacts, especially on the TG16 and Genesis.

Quote:
So, shouldn't the colors of the PlayChoice be the basis for any emulator since those are basically the same games?

There are a couple browns that are noticeably wrong on the PlayChoice compared to how TVs interpret them, but yes, emulators should have a PlayChoice palette as one choice.

Quote:
Since you use FCEUX, how do you make it scroll smootly?

By putting the ROM on a CF card and inserting it into a PowerPak. I use FCEUX for developing and an NES for play-testing.

Quote:
But for some reason, the sync methods only work with enabled hardware acceleration (which I don't want since in this case, modern graphic cards use bilinear filter for stretching).

Perhaps you can tell your video card to use a different kind of filtering. Or perhaps you can enable software pre-filtering. I know VisualBoyAdvance has the "Simple 2x" filter that can be applied before the texture is sent to the video card.

Quote:
I thought that cycle-related stuff works equally in every game in MAME.

Different boards are understood to different degrees.

Quote:
Sorry, I still don't get it. Especially the relation between the two palettes

I'd bet a single TV could display both the "NTSC Color Emulation" palette and something close to the default palette simply by turning the color, brightness, and contrast knobs. The default palette is darker and more saturated, which would mean the "Color" knob is cranked up and "Brightness" and "Contrast" down somewhat.

Quote:
Did you save the color palette you devised with that method?

No. It was years ago, and the computer with which I did that has long since been totaled. My TV isn't even on the same floor as a computer capable of running Nestopia.

by Drag on 2012-06-20 (#95745)

This is what I use, and it's the result of me having Loopy's palette demo on my PowerPak, plugged into my Panasonic CRT television, while twiddling around in Nestopia's NTSC palette generator until I came up with something that looked as close as I could get.

Believe me, I've tried, I've looked at literature, written scripts, messed with matrices, played with clipping, but the simple fact is that YIQ isn't the same as RGB, and CRTs that use YIQ are capable of displaying colors that are actually outside of the RGB range. For example, I can't get color 22 to look correct, no matter what I do, because it uses a blue value that is brighter than what's possible with RGB, so no matter what, it's going to look washed out and dull.

However, designing NES graphics, I've been able to use this palette, and the results on the NES, using my specific television, are extremely close.

And yes, color 08 is that dark on my TV, it's darker than the darkest gray, but lighter than black. Most LCD tvs won't display it correctly unless I play with the settings.

Color xC is really strange, it's cyan, but as you get darker, it gets more blue, and again, I tried to match it as close as I could with the generator.

by kyuusaku on 2012-06-20 (#95749)

In general MAME drivers can be considered some of the least accurate emulators. Almost all video hardware is "high-level" emulated, and the titles with line interrupts instead of a foreground layer are emulated with pseudo-line accuracy at best. I understand that some drivers are receiving more modern emulation treatment, but as a general rule MAME developers are working "blind", they have ROM dumps that they have to make run, but don't have access to the hardware to perform tests so they reverse engineer the hardware via the game code. MAME is a very helpful tool when you need to see a rough implementation of a system, but I do not trust even the tiniest details to be completely correct.

Fortunately with most arcade hardware there is little consequence of inaccurate video or audio emulation because they are often separate subsystems which under no circumstances influence the state of the CPU/game.

by JimDaBim on 2012-06-20 (#95753)

tepples wrote:
Quote:
Since you use FCEUX, how do you make it scroll smootly?

By putting the ROM on a CF card and inserting it into a PowerPak. I use FCEUX for developing and an NES for play-testing.

I was actually talking about the scrolling when you play a game, not about programming the scrolling in a self-made game. The way the image refreshes in an emulator looks faulty unless you use back buffering or vsync.

tepples wrote:
Perhaps you can tell your video card to use a different kind of filtering. Or perhaps you can enable software pre-filtering.

Neither the graphic card, nor FCEUX seems to offer something like that. And I can't believe that this issue never came up during the development process of the emulator. I mean, what does double buffering and vsync have to do with hardware acceleration anyway? Maybe I should ask one of the developers for that.

I've got two more specific questions:

I've often read about the fact that the NES doesn't have a proper yellow in its palette. When I saw the FCEUX palette, I thought that the value at (9,3) looks quite alright:

Sure, it's not perfect, but it's good enough to display for example blond hair. Then I saw this, the Nestopia palette:

And here, this color is actually green. Which would also explain why they used the color at (8,3) for Pac-Man and not the one at (9,3).

So, I know that this all has to do with color adjustment, but how would the color at (9,3) "usually" look on an NTSC screen? Is it yellowish or really a lemon-like green?
(Interestingly, both "Ms. Pac-Man" games use the color at (9,3) which means that Ms. Pac-Man looks greenish on Nestopia.)

The title screen of "Metroid": Again, on a "normal" NTSC TV screen: Is the ground supposed to look more like brown or more like green?

by lidnariq on 2012-06-20 (#95756)

JimDaBim wrote:
So, I know that this all has to do with color adjustment, but how would the color at (9,3) "usually" look on an NTSC screen? Is it yellowish or really a lemon-like green?
(Interestingly, both "Ms. Pac-Man" games use the color at (9,3) which means that Ms. Pac-Man looks greenish on Nestopia.)

The title screen of "Metroid": Again, on a "normal" NTSC TV screen: Is the ground supposed to look more like brown or more like green?
PAL aficionados, back in the day, would joke that NTSC stood for "never the same color". Please take that to heart — there isn't a single normal or correct color for any given output from a NES. Different TVs will reproduce those colors in all different ways.

Theoretically, the 8s column of the screen is the color of the NTSC colorburst, and should be pure color -U in the YUV colorspace. I made a graphic a few years ago of the NTSC colorwheel superimposed on NTSC's YIQ color axes on a vectorscope with the NES colors called out:
Attachment:

SMPTE_color_bars_on_NTSC_vectorscope_w_nes.jpg [ 49.26 KiB | Viewed 11860 times ]

by tokumaru on 2012-06-20 (#95757)

JimDaBim wrote:
I was actually talking about the scrolling when you play a game, not about programming the scrolling in a self-made game. The way the image refreshes in an emulator looks faulty unless you use back buffering or vsync.

I think tepples meant he doesn't care about the tearing because he doesn't use FCEUX for playing, just for debugging. By playing on on an actual console he doesn't get any tearing.

JimDaBim wrote:
And here, this color is actually green.

I guess this is just a side effect of the YIQ (or similar) color representation. The hue can easily shift depending on the monitor/TV.

Quote:
(Interestingly, both "Ms. Pac-Man" games use the color at (9,3) which means that Ms. Pac-Man looks greenish on Nestopia.)

This just comes to show that developers back then also suffered with the way the colors change from TV to TV. They were as clueless as we are concerning how each color should actually look.

by JimDaBim on 2012-06-20 (#95761)

Thanks a lot for all your help. I guess, after reading all this, that Nestopia, and not FCEUX, will be the correct choice for me when it comes to playing NES games.

by 3gengames on 2012-06-20 (#95769)

FCEUX has the best looking colors compared to my flat screen to me for sure. Nestopia is WAYYYYY too bright, at least the one I use. 1.39 is my nestopia version.

ETA:Just tried 1.40, the colors are darker, but they just look a little off. I don't think NESTOPIA is that good of a emulator for color accuracy. Like how vNES went with the "100% right" colors and made it look like complete shit.

by ccovell on 2012-06-20 (#95785)

JimDaBim wrote:
So, shouldn't the colors of the PlayChoice be the basis for any emulator since those are basically the same games?

You would think, but the RGB PPU (Playchoice one) likely was produced after the original composite one. They also are a bit different in some areas, so a few Famicom and NES games actually will display worse on an RGB PPU:

by Drag on 2012-06-20 (#95791)

Colorburst is a greenish-yellow color, look for yourself.

The wiki states that colorburst is hue 8, but on my TV, hue 8 is marigold (turning brown when it gets darker), with hue 9 looking more like colorburst. I don't know how it was determined that hue 8 is what the NES uses for colorburst, but I have to disagree. On every TV I've tested, and every NES palette I've seen, hue 9 looks like the colorburst color.

Like I said before, that palette I've posted is the absolute closest thing I can get to what my TV shows.

Re: Various questions about the color palette and emulators
by nocash on 2012-08-30 (#98834)

Quote:
You would think, but the RGB PPU (Playchoice one) likely was produced after the original composite one. They also are a bit different in some areas, so a few Famicom and NES games actually will display worse on an RGB PPU: http://www.chrismcovell.com/images/Fami ... erence.jpg

That's a nice interesting picture! But why are the two color "D" gray-scales (at the bottom) of the RGB palette missing? Is that correct?
Other info that I've found about the RGB palette suggests that color "D" does have three gray-scales (one more gray-level than the NES does have).

Oh, and about the different RGB palettes in general: I've tried to figure out what they are in this NESemdev thread: viewtopic.php?p=93681#p93681 - I ended up with a theory what they might be, but I wasn't able to confirm if it's correct. Here's a summary of what I've found out and what's still unclear:

According to Kevin, there are 13 different RGB PPUs. But I couldn't find any useful info on the "RP2C03G" and "RC2C05-05" chips (what games/consoles are using them, do they exist at all?)

That bit-for-bit palette dumps for ALL 13 RGB PPUs are very ominous, too. Did anybody ever saw those 13 dumps? According to MAME, there are only 5 different palettes: 4 special palettes for 4 special PPUs, and 1 standard palette for the other 9 PPUs. I am not too sure if that is corrent. Kevin is somehow suggesting that there might be different variants of the standard palette.

For the ID bits in the "RC2C05-01..05" series, I've figured out IDs for three chips. For the other two chips it's still unknown what ID values they have (if any).

Re: Various questions about the color palette and emulators
by joat on 2012-08-30 (#98856)

I'm not sure about the PC10/etc... ppus, but I loaned him my collection of RP2A04's (VS ppus) to analyze back in the day. When I get a chance I'll go thru my backups to see if he sent me palettes for them or any other information.

Cheers,
Michael

Re: Various questions about the color palette and emulators
by ccovell on 2012-08-30 (#98857)

Some VS Unisystem games have custom PPUs with custom palettes, but for the RGB PPUs that are out there (PC-10, Sharp C1, Titler) I'd bet 1000 yen that they all have the same palette and quirks as in my picture. And yes, colour ranges $xD are all black, causing some games to show differences. See here: http://playoffline.wordpress.com/mod/rgbppu/

The bigger problem is that games that use colour emphasis to darken the screen make the screen completely white on an RGB PPU. A shame...

Re: Various questions about the color palette and emulators
by joat on 2012-08-31 (#98858)

Blah, can't actually find the 2c04 files, but I did find IRC logs from when he was dumping palettes. At least one file he sent was named 2c04_001.pal if you see that somewhere. Another note: Q was playing with the results from the measurements, so the arrays in Nintendulator are almost certainly accurate.

I also found a ZIP with some 2c03 and 2c05 files, in the raw 3 bpc format (there's a readme inside with details):

Quote:
2C03B.PAL - RP2C03B from a Playchoice 10
2C03BM.PAL - RP2C03B, with monochrome bit set
2C0503.PAL - RC2C05-03 from a Gumshoe Vs. machine
2C0503M.PAL - RC2C05-03, with monochrome bit set

Cheers,
Michael

Re: Various questions about the color palette and emulators
by nocash on 2012-08-31 (#98862)

Quote:
Another note: Q was playing with the results from the measurements, so the arrays in Nintendulator are almost certainly accurate.

Are that nintendulator palettes released somewhere? Btw. one confusing thing: In 2006, nintendulator announced this new feature: "Added dark grays to the 14th column of the Playchoice-10 palette." But, if that was wrong, then it may have been removed meanwhile.
EDIT: They are released (it's an open source emu). It does have 5 rgb palettes (but maybe that's right, and the 13 rgb-ppus really have only 5 different palettes). The 5 palettes are found in the gfx.cpp file: the four special VS palettes, and one standard "PC10" palette... which does have the extra grays.

Quote:
can't actually find the 2c04 files, but I did find IRC logs from when he was dumping palettes. At least one file he sent was named 2c04_001.pal if you see that somewhere.

Nope, can't see that anywhere - google finds nothing.

Quote:
RP2C03B and RP2C05-03 palette data - palette_kevtris.zip

Many thanks!
The kevtris palette dumps are looking as nice & detailed as expected. Do you think there'd be any chance that kevin would agree to release the remaining palette dumps? I tried to, but I can't contact him. The forum PM's are still pending unread in outbox, and the comcast.net address on his webpage is blocking emails from freemail providers.

EDIT: After looking closer into the palette_kevtris.zip files: The two palette dumps in the zip are both exact copies of each other - well, that makes sense as both chips should have a "standard" palette.
And compared to MAME's "standard" palette: They are exactly same - except that MAME has those additional grays. Don't know where those grays come from - either it's an emulation bug, or there are really some chip variants that do have extra grays... or they appear only under certain conditions, like only for OBJs but not for BG or so.

Quote:
See here: http://playoffline.wordpress.com/mod/rgbppu/

Neat. The bottom-most picture with the composite-vs-rgb comparision is nice... shows all the ups (clearer picture) and downs (distorted colors and missing gray) of the RGB ppu.

Re: Various questions about the color palette and emulators
by nocash on 2012-09-02 (#98936)

I've contacted Quietust (nintendulator author), here's his reply about the extra grays: I added them for "compatibility" reasons - namely, so you could use the PC10 palette with non-PC10 games without some grays becoming black (and messing up the game's graphics).
So, the extra grays are a myth, nothing to do with real hardware. Dunno why MAME has them, too. But looks as if they adopted the palette from the nintendulator source code.

Also asked Quietust about Kevin's 13 rgb palette dumps (I thought somebody mentioned he got those dumps from him), but he couldn't help there.

joat, what collection of VS PPUs do you have? (just the chip-names). According to the "NES 2.0" format there are 13 VS ppus. But the "RP2C03B" is almost certainly used only in PC10 (and famicom titler and special tv sets maybe) but not in VS system. And of the remaining 12 VS ppus - I have my doubts that the "RP2C03G" and "RC2C05-05" do really exist. There are a bunch emulators "supporting" them (presumably based on the "NES 2.0" format specs), but other than that there aren't any webpages ever mentioning those PPUs.

Re: Various questions about the color palette and emulators
by joat on 2012-09-02 (#98938)

The ones I have are:

RC2C03B
4A4 28
*unmarked heatsink* (probably Tennis (MDS-TE) as I have a set of eeproms for it with no PPU)

RC2C03C
4A2 10
Duck Hunt (MDS-DH)

RP2C03B
4B3 59
Duck Hunt (MDS-DH)

RP2C04-0001:
various datecodes
Hogan's Alley (MDS-HA)
Pinball (MDS-PN)
Gradius (MDS-P-GR)
Baseball (MDS-BA)

RP2C04-0002:
Golf (MDS-GF)

RP2C04-0003:
Soccer (MDS-SC)

Regarding some of the other palettes, I did some digging after the last post, and I haven't seen anything to support the existence of RPC2C05-05 either.

List of all PPUs that I could find with google image search or have seen in person:

RC2C03x (x is least B, C)
RP2C03x (x is at least B, C, maybe G? - Kevtris mentioned it as B and G, wondering if this is a typo for C, no pictures of a G found)
RP2C04-0001
RP2C04-0002
RP2C04-0003
RP2C04-0004
RC2C05-01
RC2C05-02
RC2C05-03
RC2C05-04
RC2C05-99 (Sharp Titler)

plus bog standard:
RP2C02x (NES NTSC) (x is at least B, C, D, D-0, E-0, G-0, H-0)
RP2A07x (NES PAL) (x is at least blank, A)
RP2C07A-0 (NES FRA PAL)

Note: I found a zip called vspal.zip, which has 8 palettes in it (vs_001..vs_004, and a second set with emph that are 8 times longer, so they have an entry for each emphasis bit combination). It's attached but I don't know if this ZIP came from Kevtris or elsewhere. The date stamp is about right though.

Cheers,
Michael

Re: Various questions about the color palette and emulators
by nocash on 2012-09-02 (#98955)

Nice ppu list. Thanks! I didn't knew about the RP2C03C and RC2C05-99 chips. Yes, Kevin's "G" might have been a mistyped or misread "C". Maybe his "-05" actually meant "-99". But I am not sure if it's possible to do SUCH a typo Maybe if he was having the "Fifth RC2C05" chip in mind.

Are you sure Duck Hunt is using RC2C03C and RP2C03B? This page http://www.johnsarcade.com/nintendo_vs_ppu_info.php page lists RC2C03B instead of RP2C03B.

RP2C03B would be the Playchoice PPU (but maybe it was also used in VS games).
RP2C03C appears to be used in Sharp C1 TV Sets (and maybe used elsewhere, too).

Guess there is no known way to decipher those "4A4 28" date codes, or is there some formula?

Meanwhile, Quietust has found some of Kevin's dumps, and uploaded them here http://www.qmtpro.com/~nes/misc/kevtris_palettes.zip the package contains 11 color dumps, and for some reason, only 10 "monochrome" dumps.
The three color+mono sets beginning with a "2" in the filenames are duplicates (they have been apparently renamed to names beginning with "C2" and "P2" to separate between "RC2xxx" and "RP2xxx" chip names). Aside from the changed filenames, some of them also contain slightly different 8:8:8 bit RGB values - but the actual 3:3:3 bit values are really exact dupes.
So, in total, the .zip contains dumps for 7-and-a-half-PPU (the "half" one only as "color" dump).

The .pal files are ascii text files with 512 lines per file, which is making it not too comfortable to read them. I've made a small tool that squeezes the data into 4 lines, with 16 colors per line, and with the emphasis stuff removed.
Before removing emphasis, the tool has verified that the emphasis area contained expected values (=the normal colors, with emphased R:G:B components changed to "7") (the emphasis verification passed for all 11 color dumps and all 10 mono dumps, so the emphases is apparently working the same way in all PPUs, and there's no valuable info lost when removing that part of the dumps).
Anyways - here are the .PAL files in squeezed form:
Code:
C2C03B.PAL (=RC2C03B, early "standard" palette variant)
333,014,006,326,403,503,510,420,320,100,031,040,022,000,000,000
555,016,027,407,507,704,700,630,430,140,040,053,044,000,000,000
777,357,447,637,707,717,740,750,660,340,070,276,077,000,000,000
777,547,657,757,747,755,764,772,773,552,473,276,467,000,000,000
C2C03BM.PAL
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000
333,333,333,333,333,333,333,333,333,333,333,333,333,333,333,333
777,777,777,777,777,777,777,777,777,777,777,777,777,777,777,777
777,777,777,777,777,777,777,777,777,777,777,777,777,777,777,777

C2C03C.PAL (=RC2C03C, normal "standard" palette)
333,014,006,326,403,503,510,420,320,120,031,040,022,000,000,000
555,036,027,407,507,704,700,630,430,140,040,053,044,000,000,000
777,357,447,637,707,737,740,750,660,360,070,276,077,000,000,000
777,567,657,757,747,755,764,772,773,572,473,276,467,000,000,000
C2C03CM.PAL
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000
333,333,333,333,333,333,333,333,333,333,333,333,333,333,333,333
777,777,777,777,777,777,777,777,777,777,777,777,777,777,777,777
777,777,777,777,777,777,777,777,777,777,777,777,777,777,777,777

P2C03B.PAL (=RP2C03B, normal "standard" palette)
333,014,006,326,403,503,510,420,320,120,031,040,022,000,000,000
555,036,027,407,507,704,700,630,430,140,040,053,044,000,000,000
777,357,447,637,707,737,740,750,660,360,070,276,077,000,000,000
777,567,657,757,747,755,764,772,773,572,473,276,467,000,000,000
P2C03BM.PAL
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000
333,333,333,333,333,333,333,333,333,333,333,333,333,333,333,333
777,777,777,777,777,777,777,777,777,777,777,777,777,777,777,777
777,777,777,777,777,777,777,777,777,777,777,777,777,777,777,777

C2C05_3.PAL (=RC2C05-03, normal "standard" palette)
333,014,006,326,403,503,510,420,320,120,031,040,022,000,000,000
555,036,027,407,507,704,700,630,430,140,040,053,044,000,000,000
777,357,447,637,707,737,740,750,660,360,070,276,077,000,000,000
777,567,657,757,747,755,764,772,773,572,473,276,467,000,000,000
C2C05_3M.PAL
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000
333,333,333,333,333,333,333,333,333,333,333,333,333,333,333,333
777,777,777,777,777,777,777,777,777,777,777,777,777,777,777,777
777,777,777,777,777,777,777,777,777,777,777,777,777,777,777,777

P2C04_1.PAL (=RP2C04-0001) (first special VS palette)
755,637,700,447,044,120,222,704,777,333,750,503,403,660,320,777
357,653,310,360,467,657,764,027,760,276,000,200,666,444,707,014
003,567,757,070,077,022,053,507,000,420,747,510,407,006,740,000
000,140,555,031,572,326,770,630,020,036,040,111,773,737,430,473
P2C04_1M.PAL
755,755,755,755,755,755,755,755,755,755,755,755,755,755,755,755
357,357,357,357,357,357,357,357,357,357,357,357,357,357,357,357
003,003,003,003,003,003,003,003,003,003,003,003,003,003,003,003
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000

P2C04_2.PAL (=RP2C04-0002) (second special VS palette)
000,750,430,572,473,737,044,567,700,407,773,747,777,637,467,040
020,357,510,666,053,360,200,447,222,707,003,276,657,320,000,326
403,764,740,757,036,310,555,006,507,760,333,120,027,000,660,777
653,111,070,630,022,014,704,140,000,077,420,770,755,503,031,444
P2C04_2M.PAL
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000
020,020,020,020,020,020,020,020,020,020,020,020,020,020,020,020
403,403,403,403,403,403,403,403,403,403,403,403,403,403,403,403
653,653,653,653,653,653,653,653,653,653,653,653,653,653,653,653

P2C04_3.PAL (=RP2C04-0003) (third special VS palette)
507,737,473,555,040,777,567,120,014,000,764,320,704,666,653,467
447,044,503,027,140,430,630,053,333,326,000,006,700,510,747,755
637,020,003,770,111,750,740,777,360,403,357,707,036,444,000,310
077,200,572,757,420,070,660,222,031,000,657,773,407,276,760,022
P2C04_3M.PAL
507,507,507,507,507,507,507,507,507,507,507,507,507,507,507,507
447,447,447,447,447,447,447,447,447,447,447,447,447,447,447,447
637,637,637,637,637,637,637,637,637,637,637,637,637,637,637,637
077,077,077,077,077,077,077,077,077,077,077,077,077,077,077,077

P2C04_4.PAL (=RP2C04-0004) (fourth special VS palette)
430,326,044,660,000,755,014,630,555,310,070,003,764,770,040,572
737,200,027,747,000,222,510,740,653,053,447,140,403,000,473,357
503,031,420,006,407,507,333,704,022,666,036,020,111,773,444,707
757,777,320,700,760,276,777,467,000,750,637,567,360,657,077,120
P2C04_4M.PAL
(missing)

The three 'normal "standard" palettes' are identical. But the 'early "standard" palette' in the RC2C03B chip is a bit different (at least I think that that chip is older/earlier than the others).

Oh, and the "vspal.zip" file... the 192-byte format looks like the MAME palettes, but's using 8bit values (00h..FFh), whilst MAME uses 3bit values (00h..07h). However, the 8bit numbers are looking same as in Kevin's 10240-byte .PAL text files (I have only compared the first handful of numbers in the first file though).

Re: Various questions about the color palette and emulators
by tepples on 2012-09-02 (#98956)

Might the RC and RP chips be the same thing from different fabs?

So we have official palettes for 3bpc environments such as a port of an NES game to the Sega Genesis. Are the RGB palettes from Animal Crossing GCN and the Wii Virtual Console dumped?

Re: Various questions about the color palette and emulators
by nocash on 2012-09-02 (#98957)

Quote:
Might the RC and RP chips be the same thing from different fabs?

The "R" might be for Ricoh (as in Ricoh's RP5H01 PROM; used in Playchoice and NSS cartridges). Don't know what "C" and "P" are for. But no, they aren't the same, RC2C03B and RP2C03B have different colors in them). EDIT: "C" and "P" seem to mean Ceramic and Plastic package. EDIT2: Or rather not, "P" is used on both Plastic and Ceramic chips... and the different colors might be due to a corrupt dump.

Quote:
So we have official palettes for 3bpc environments such as a port of an NES game to the Sega Genesis.

You can convert them to any color depth. Best by multiplying the 3bit value by 9248h (=1001001001001001b), then right-shifting the result until reaching the desired number of color bits. The VS and PC10 palettes aren't very close to the NES palette. They are useful for reproducing quirks in VS/PC10 games, but I would avoid using them for real NES games.

Quote:
Are the RGB palettes from Animal Crossing GCN and the Wii Virtual Console dumped?

What are that? Official NES emulators from Nintendo? Might be interesting to see that palettes. I wouldn't recommend to use that palettes for anything though. Nintendo usually gives a shit about authentic colors (just look at the different "standard" palettes above, or at the LCD palettes that changed in each and every revision of their GBC/GBA/NDS handheld line).

Re: Various questions about the color palette and emulators
by joat on 2012-09-02 (#98962)

Cool, I'm glad Q found the rest of the palettes.

Quote:
Are you sure Duck Hunt is using RC2C03C and RP2C03B? This page http://www.johnsarcade.com/nintendo_vs_ppu_info.php page lists RC2C03B instead of RP2C03B.

Quite sure:

Regarding deciphering the date codes, unfortunately I don't have any idea on them, and a quick web search didn't find any contemporaneous Ricoh chips that might have had similar code formats.

Cheers,
Michael

Re: Various questions about the color palette and emulators
by tepples on 2012-09-03 (#98967)

nocash wrote:
The VS and PC10 palettes aren't very close to the NES palette.

Yet the Famicom Titler, as I understand it, uses the same PPU.

Quote:
Quote:
Are the RGB palettes from Animal Crossing GCN and the Wii Virtual Console dumped?

What are that? Official NES emulators from Nintendo?

Yes. Animal Crossing has several unlockable NES games, and Virtual Console is the official emulator bundled with NES games purchased from Wii Shop. Super Smash Bros. Brawl also has time-limited demos of NES games inside.

Quote:
the LCD palettes that changed in each and every revision of their GBC/GBA/NDS handheld line).

Perhaps Nintendo started giving a dang around the DS Lite, whose colors are just like those of Game Boy Player and PC based emulators.

Re: Various questions about the color palette and emulators
by nocash on 2012-09-03 (#98969)

Quote:
Yet the Famicom Titler, as I understand it, uses the same PPU.

Nintendo's RGB PPU standard palette is roughly-close to the NES PPU palette, but not very-close. They did apparently try to make a palette that looks like a NES, but they didn't do it very well.
There aren't any known dumps for the RGB PPUs used in Sharp Titler and Sharp C1, there is some (small) chance that they have a different and maybe more accurate palette in there.

I've compared kevin's dumps for the standard palette and the 4 special palettes with the MAME ones: They are exactly same, except that MAME is having those three unreal extra-grays in there.

And the "early" standard palette in RC2C03B. The only difference to the "normal" standard is that Green.Bit1 is missing in each Fourth color (color 1,5,9). Looks more like a BUG as than a cosmetic change. No idea if it's a real hardware bug that exists in all RC2C03B chips, or if it's coming from a damaged RC2C03B chip, or if it's just a corrupt palette dump.
If it's a real hardware bug, then there should be some visible difference when running a palette-test-screen program on RC2C03B compared to running on RC2C03C/RP2C03B/RP2C03C/RC2C05-0x.

Quote:
Cool, I'm glad Q found the rest of the palettes.

Me too. I didn't expect them to show up anymore. I wonder if the remaining dumps will show up, too. Btw. did somebody email kevtris and ask if he still has them? (with my freemail account I am only getting a "mail delivery blocked for spam" response)

Re: Various questions about the color palette and emulators
by AWJ on 2012-10-03 (#100699)

I was the one who added those palette pseudo-ROMs to MAME some time ago, and yes, I copied them from Nintendulator because I couldn't find Kevtris's original data anywhere on the web at the time. I had no idea the Nintendulator PC10 palette had been hacked to add the extra greys, and I seem to have unwittingly propagated a great deal of confusion as a result. Apologies all around.

Re: Various questions about the color palette and emulators
by exdeath on 2012-10-03 (#100709)

NES output has a very digital like quality to it with very discrete and large color phase changes. Should be possible to reference on a NTSC vectorscope to get the exact NTSC colors, but then you have multiple standards for converting NTSC to RGB so which one then?

NES doesn't have a palette; the pixel color is just a lookup into a phase selection for a native NTSC output.

At first I freaked out about not having RGB on NES for my Sony PVM monitor like I do for everything else, but its actually a very good composite signal vs other systems.