Full 410-Color NES Palette Demo

Full 410-Color NES Palette Demo
by blargg on 2006-03-11 (#10631)

I liked Loopy's PALTEST demo and extended the concept to show all ~410 colors on screen: (2 grays + 12 colors) * 4 brightness levels * 8 emphasis bit settings + 1 black about 39 duplicates. It came out pretty nice:

full_nes_palette.nes

I took a different approach of keeping PPU rendering off and manually refilling the palette at the proper time mid-scanline. I spread the spectrum horizontally and first tried vertically cycling through the four brightness levels for each emphasis combination. I noticed that I could get a smoother light-to-dark transition if I instead cycled through each emphasis combination for each brightness.

UPDATE: I wrote a color counting program using nes_ntsc and it only counted 410 unique colors (using 8 bit resolution for the red, green, and blue components). Adjusting brightness and contrast didn't affect this number by more than a couple of colors.

by Celius on 2006-03-11 (#10637)

Nice Demo! Too bad it only works on Nintendulator. FCEUXD wouldn't play it correctly. I loaded it in FCEUXD, and I was like "This can't be the demo, this is crap." Because it showed like 3 different blues on screen at once. Do you think this would work on real hardware? It seems very buggy. Maybe a little more precise scanline counting would be good, if you can do that.

by NewRisingSun on 2006-03-11 (#10638)

Quote:
FCEUXD wouldn't play it correctly. I loaded it in FCEUXD, and I was like "This can't be the demo, this is crap." Because it showed like 3 different blues on screen at once. Do you think this would work on real hardware?
In case you haven't noticed, Nintendulator is the more accurate emulator. It also works on Nestopia 1.27, by the way.
Quote:
Maybe a little more precise scanline counting would be good, if you can do that.
Why would he modify working code to work with a particular suboptimal emulator?

by Celius on 2006-03-11 (#10640)

NewRisingSun wrote:
Quote:
Maybe a little more precise scanline counting would be good, if you can do that.
Why would he modify working code to work with a particular suboptimal emulator?

No, no, no. That's not what I meant. Because there is obvious off-time scanline counting, blargg should count scanlines more precicely. Well, when I think about it, he did a really nice job of counting, because if it was off time, the color blocks would be scrolling down off screen. I don't know. It just isn't very pretty, because scanline counting is hard. But all those colors on screen at once is really awesome. Just looks a little fuzzy in some places. And I have noticed that Nintendulator is far more accurate.

by Quietust on 2006-03-11 (#10641)

The problem with FCEU is that it only supports three "colour emphasis" modes at once on the screen: "no bits", "all bits", and "some bits" (i.e. any other combination, but only the first one it encounters).

by Bregalad on 2006-03-11 (#10642)

It doesn't work under Nestopia for me. Since Nintendulator don't run on my PC but only on the family's PC (because mine is way too slow), I cannot test it yet.

by Quietust on 2006-03-11 (#10643)

Bregalad wrote:
It doesn't work under Nestopia for me. Since Nintendulator don't run on my PC but only on the family's PC (because mine is way too slow), I cannot test it yet.

You don't need a fast computer to see this demo - even 1fps is enough to see the result.

by Bregalad on 2006-03-11 (#10645)

You're right. It seems very shacky. Why not use a standard method for horizontal palette chaning an use tricky tricks only for vertical palette changing ? It sounds much more reasonable to me.

by tepples on 2006-03-11 (#10647)

Bregalad wrote:
Why not use a standard method for horizontal palette chaning an use tricky tricks only for vertical palette changing ?

Because you can only do vertical palette changing on a small number of colors at once before hblank time runs out.

by baisoku on 2006-03-11 (#10649)

Disregard the noise, blargg. Nice work. Ditto for the RGB mixing page.

by Memblers on 2006-03-11 (#10653)

This is really cool. It made me think of all kinds of crazy stuff, like someone could theoretically draw a picture like this on a cart that has no CHR memory at all. Couldn't it select colors in a given pattern rather than cycling through them all? (Why someone would do that is a whole other thing, but anyways.. CopyNES TV display maybe? heheh).

by blargg on 2006-03-11 (#10655)

Hahaha to all who try this on a puny emulator. I developed it on my NES and it is not at all buggy (but it is a hack in the good sense); where do you think the screenshot came from? Not my emulator, ha! It's using the CPU to do all pixel timing, not the PPU, so the edges of colors are ragged by three pixels. If timing weren't perfect the image would roll and be skewed horizontally. To those who suggest I use normal palettes and tiles, this would add glitches on a whole scanline between colors, as with Loopy's PALTEST.

Memblers wrote:
It made me think of all kinds of crazy stuff, like someone could theoretically draw a picture like this on a cart that has no CHR memory at all. Couldn't it select colors in a given pattern rather than cycling through them all?

I was thinking of exactly this. The main problem is getting the data out fast enough. This demo uses 6 CPU cycles (18 pixels) per horizontal strip. You could put the data on the stack and quickly pop it all off, widening the strips to 24 pixels, or put the data in zero page and widen the strips to 21 pixels. Both would still limit you to 256 pixels until the buffer needed to be refilled, giving about 22 scanlines of data. You could unroll everything into special-purpose code, giving you 14 strips across with full vertical resolution, using. Too bad I only have enough devcart memory to display about 100 lines like this. I should try making a picture convertor and demo for this. It could even change the emphasis each line, giving access to hundreds of colors.

by NewRisingSun on 2006-03-11 (#10656)

Inspired from reading those articles about Color Dream's "Hellraiser" cart, I have always wondered about such a thing: putting a custom CPU with the actual game code and PPU on the cartridge, and all the 6502 program does is feed the picture data from the custom CPU/PPU to the NES, and controller input from the NES to the custom CPU; the custom PPU would output a 7-bit color code (4xNES color + 3xEmphasis) for each and every pixel, which the NES program then writes into the NES PPU's palette register.

Of course, that wouldn't work because of the speed issue, as explained previously, unless the cartridge hardware could somehow change the PPU's palette register directly, without using the 6502 CPU.

by blargg on 2006-03-11 (#10658)

Here's one with an earlier color arrangement that I like better, since it's clearer what's going on and each color rectangle is more distinct:

full_nes_palette2.nes

As before, run on a NES or an accurate emulator.

by Jagasian on 2006-03-13 (#10737)

blargg wrote:
where do you think the screenshot came from? Not my emulator, ha!

Honestly, it is really becoming hard to tell, considering your recent work. Can you prove that screenshot is not taken from an emulator?

by blargg on 2006-03-13 (#10747)

Quote:
Can you prove that screenshot is not taken from an emulator?

That got a big laugh out of me. Can I even prove it's from any NES, emulated or real? If you trust others here, you could have them take a screenshot of it running on their (Copy)NES systems.

I suppose the most reliable proof if you don't have the ability to run it on a NES is to post the source code. I need to change my setup to cc65 or some standard assembler rather than mine.

Maybe it's time someone set up the web-connected NES tester where you can upload your ROM and see screenshots/hear an audio recording of it. It'd be pretty easy to figure out whether it's an emulator, heh.

by baisoku on 2006-03-13 (#10753)

blargg wrote:
I suppose the most reliable proof if you don't have the ability to run it on a NES is to post the source code. I need to change my setup to cc65 or some standard assembler rather than mine.

I was able to run it through NESrev to get X816 compatible code.

by WedNESday on 2006-03-14 (#10759)

Quote:
Can you prove that screenshot is not taken from an emulator?

I reckon blargg created the picture in MS Paint one night when he was bored.

by blargg on 2006-03-14 (#10761)

Quote:
I reckon blargg created the picture in MS Paint one night when he was bored.

I reckon someone is having trouble getting it to work in his emulator.

baisoku wrote:
I was able to run it through NESrev to get X816 compatible code.

To save you from an uncommented disassembly of the ROM, here's the source code (and iNES ROM) to a really optimized version I just wrote that assembles to only 148 bytes of machine code (it doesn't even read anything from RAM).

full_palette_opt.zip

I used NESASM since it was handy and allowed a single source file. It might not run properly even on Nintendulator, due to the subtle NMI timing trick I used (it will shake horizontally more than the earlier ROMs if the emulator doesn't handle NMI timing properly). I also had to change the direction of brightness to work with the optimization. I was hoping to get it under 128 bytes. Oh well.