Another palette test

[rainwarrior]

I wanted a palette test ROM that would work with FCEUX, and I couldn't find one digging around so I made a new one.

This displays the regular palette on the top, and lets you play with emphasis/greyscale bits for the palette on the bottom. You can also toggle the "forbidden black" $0D color.

I tested it on a bunch of different emulators, and on my NTSC NES. It should presumably work with Dendy. The PAL version of the ROM has only been tested in emulators.

Further down in this thread, there are two other useful programs:

• color_test.nes - a simpler full-screen colour test
• capture_nes_palette.py - a script for compiling palettes from test captures

Edit: added PAL version. 2018-7-26

Palette test video capture

[Eugene.S]

Thank you, RainWarrior.
It's very valuable ROM for emphasis bits test.

[rainwarrior]

In response to a request in another thread, I've made a simple ROM for displaying a full-screen colour. (No special tricks, should run on any NES, NTSC or PAL or whatever.)

You can select any of the 64 entries, toggle emphasis and greyscale bits, and hide the display if you just want a full screen of a single colour.

Color test screenshot

color_test_screenshot.png (1.61 KiB) Viewed 36562 times

[Eugene.S]

Rumata gave me RP2C07-0 - PAL PPU chip of NES French version
(PPU itself output is standard composite signal, but finally converted to RGB by special decoder on French NES mainboard)

So, i've installed it to my Hybrid/Dendy famicom:


https://youtu.be/jY8Jb1uQEcc

Red/Green Emphasis bits are swapped.
Waiting for decap this chip soon.

P.S. I will give this chip to decapper man very soon, tomorrow or day later.
I can do some tests for today, if you want it.

About you first ROM:

I would not expect it to run properly at all on a PAL NES, but I think it will work with Dendy.

It work perfect on Dendy.
But looks top-shifted when i run it on "Dendy CPU + PAL RP2C07-0" bundle. The upper part is out-of-screen.

[feos]

Implemented this swap for PAL filter in the latest fceux revision. I wonder if we shall do it for PAL/Dendy region mode in general.

[gutomaia]

Hi.

I've just took a closer look on the palette example. It's seens, by reading the code, that there is a missing 'test.chr' file, due to lines 24 and 25 on palette.s file.

; CHR ROM
.segment "TILES"
.incbin "test.chr"
.incbin "test.chr"

Congrats for the demo

[rainwarrior]

Sorry about that, added it to the ZIP.

[gutomaia]

No problem at all. Just trying to help!

[rainwarrior]

Inspired by some recent discussions about PAL vs NTSC, and Mesen's awesome event viewer debug feature, I decided to make a PAL version of the palette test ROM (see OP above).

I don't have a PAL machine, so it's only been tested in emulators. Please let me know if you're able to verify that it works on real hardare.

[FrankenGraphics]

Cool! Will be back home in a week. if noone has verified it until then, i'll check.

[rainwarrior]

Trying to make it easier to take palette samples for research, I've written a python program to take the average of rectangular samples from images captured from the palette.nes ROM above, and compile them into 512-entry palettes. Run the ROM, capture 8 images (one for each emphasis setting), and then run this python script to compile the palette.

For reference, I compared my two machines (Front loader NES, and an AV modded Famicom) against two capture devices I have (Diamond VC500 composite capture device, and Framemeister XRGB mini to Avermedia LGX HDMI capture device). This is not to provide any kind of definitive palette, just a few reference points for "opinions" these devices had about how the composite colours should be converted to RGB. Capture devices obviously aren't the end of the story, but they're at least something that can be measured in a semi-automated way like this.

Four reference captures I took with the program and hardware I have at hand.

By the way I forgot to turn on 0D for these samples, but I'm not sure if that's better or worse for the results. With some devices the presence of the sub-zero black causes the device to renormalize, which could have thrown things off if I had been using it.