PAL / SECAM gamut palette test

I started thinking about what would constitute an accurate palette from PAL / SECAM gamut space.
This test is directly from the hardware capable PAL gamut, at 12 equal steps along the possible range.

Row 10 ~ 1F is PAL gamut:
xR-0.64
yR-0.33
xG-0.29
yG-0.60
xB-0.15
yB-0.06
White point D65 (X0.3127, Y0.329)

Then row 0, 2 & 3 are luminance steps based on row 1.

This palette also includes a hack for getting a better 00 ~ 30, 0D~3D range. Reckless!! Use at own risk




Attached is the PAL gamut palette in .aco, .act & .pal formats.
I think I have the .pal file laid out correctly, but not really sure how to convert for FCEUX to test out. If anyone can help?

Why would you do this? If it's intended for use in an emulator it'll just make games that use $20 as white look dull. If it's intended for use in making NES graphics, those colours aren't going to work on the real thing.


The .pal file should have 64 x 3-byte RGB entries (or 512 if including emphasis), so either 192 or 1536 bytes. I don't know how you arrived at 631 bytes.

There is possibly, maybe some utility to having a "standardized" copy of the UM6559 SECAM generator palette, given how much it differs from the standard palette...

(theoretically it's just a luminance ramp, $20 was "meant" to be light grey. Would be interesting to know how it came out on actual PAL / SECAM sets with their differing chrominance. As shown above, $20 is a light grey on SECAM - although that might be the machine - I imagine artists went for $30 as white?)

Can take these out of the final .pal, this is just a test.



The .pal file is output from ASEprite (64 lines plus header), I may be out of my depth here but why does FCEUX need .pal in 8bit colour space?

Opening it with a hex editor I discovered it's a "JASC-PAL" format. Never heard of this one before, but it looks like a simple text file containing a list of decimal triples.

Apparently there's also a Microsoft .pal format that's different.

Anyhow, no I don't know of any converter tool, but you could write a converter in python or some other convenient language in probably like 20 lines.

I'm pretty certain the UM6559 palette (that link) should just be considered Wrong™.

In the 2C02/2C07, colors $00 $10 $20 $30 are "1 2 3 3" and colors $0d $1d $2d $3d are "-1 0 1 2" (and colors $0e $1e $2e $3e $0f $1f $2f $3f all "0"), but in the UM6559 all four columns/rows are "0 1 2 3"

Then it's also very similar to GIMP's and Fractint's palette formats too, and trivially converted to a PPM (type "P3") image.

Those are the two most common .pal formats, FCEUX is custom

Thanks I'll look in to converting to 8bit colour space 3-byte. The FCEUX .pal files are a little confusing (at least to me) in a text editor as there's 12 rows of 8 entries (96 entries) [edit: ah I get it]. Also does anyone know why do they need to be in 8bit colour space?

Jasc palette files seem to originate from JASC PSP, and not a Sony PSP!

Could this be considered a "fix"?

I'll edit the .pal so that it conforms to 2C02/2C07 luminance shifting, could this be considered a "bug"?

Would be interesting to know what the true intention of these $00 ~ $30, $0D ~ $3D were meant to be... I'm totally up for making a palette that conveyed the true intentions of the original hardware.

It's a very simple and natural format used by other NES emulators, though. It's not intended for anything but NES palettes, e.g. there's no header to say how many entries there are supposed to be, because there's only one way to do it, really. I don't think it originated with FCEUX, either.


Oh, so the idea is based on some particular piece of Dendy clone hardware?


In NES games, no, not really. $20 and $30 are supposed to be the same white, and there are practical reasons why you might want to use $20 instead of $30. The main one I can think of is that it makes fading out look more natural when white doesn't persist for an extra step of the fadeout.

Some games prefer $30, some prefer $20. (Some appear to use both, e.g. Jaws.)

Ah good point

It also allows for a slight dim of all palete but whites in, for example, a "P A U S E" sign. If you use $20 in the game and $30 to paint the sign you can dim the whole palette retaining pure white.

I was reading a bit about what "official" games were allowed to use and Jaws is a pretty rare case, apparently developers were asked not to use $30 because it caused problems with some CRT sets as it was "whiter than white" - indeed games would be rejected by Nintendo if they used #30. The same went for $0d as it was "blacker than black" (not sure what damage that could do though). $e & $f range were not allowed either.

Having trouble converting this for FCEUX (as it requires 8bit colour depth), which this is not. The quest ends here

Where did you get this information? I don't think I've ever heard this before...


Blacker than black is a well known issue... It doesn't cause any actual damage, but some TV mistake this color for sync signals, distorting the picture or causing it to "roll".


Again, never heard of this. $0f is widely used for black in homebrew games.

I don't know what your sources are for this but they're completely bogus. (If you'd care to share the source, I'm sure there's people here who wouldn't mind correcting them.)

Again, $30 is the same as $20 by design, so this "whiter than white" idea makes no sense.

Super Mario Bros. uses $0F for black, and $30 for white. (So do a lot of games.) I'm certain that $0E is acceptable too, but I don't have a common example offhand.

I mentioned Jaws only as a weird case that I happened to notice uses both $20 and $30 on the same screen.

Nintendo didn't really have a way to test for and reject $0D either. For example, the common TMNT uses $0D and it made it through all licencing tests and was one of the highest selling games for the system. It doesn't use large amounts of it on the screen, just for sprite outlines, so I don't think it tends to cause the common desync problems, but my point is I don't believe they did any sort of categorical test for the use of $0D.

It is pedantically true that $30 is whiter than white. At 110 IRE, it's 110% of full scale.

However, it's also true that $20 is the exact same brightness, also 110 IRE.

(Via the RF modulator and input on a US TV set they'll turn out even brighter; the sync depth is -37 IRE instead of -40, and black level is 7.5 IRE so the both palette entries will be normalized up to ≈121% of full scale)

May have got muddled a bit in my own limited memory but I read it here:

https://www.gamedev.net/topic/671394-re ... mitations/



Would be great to hear from devs from back in the day if Nintendo had any official restrictions.

It's moderately well attested that Nintendo's "SDK" for the NES was a small pile of badly-translated Japanese documents, just barely enough information to get started.

I really doubt there was any admonition at the time against using the column $D colors ... or really any prohibitions at all.

We even already have a page on the wiki of games that use color $0d, many of which are licensed.