Effective way to display almost random RGB(222) on NES?

[greatkreator]

What is the most effective way to display almost random RGB(222) array on NES?
What result can NES produce to display for example and "RGB222" array of almost arbitary values?
I am not (yet) from NES/SNES world so I ask such unintelligent questions! However I will improve.
I know that NES is able to use tile data directly from ROM - thus it's not a problem to display any combinations using one palette for them all.
But what is the most effective way to squeeze as much as possible colors for such full tile reload each frame?
As far I know I read that it's possible to produce 4 colors for 8x1 block of pixels.
The purpose to know what is the most effective combination possible: N colors x (WxH) x FPS

Thanks a lot! Once again sorry for the stupidity of a noob.

[lidnariq]

The NES natively works in the HSL colorspace. While the total library of colors is 432 (54 colors generated by the PPU directly; 8 different alternate palettes controlled by the CPU), there are significant restrictions on placement.

[greatkreator]

Yes I am aware of HSL. I just simplified the question because usually random pixel arrays named as RGB.
Actually as far I know NES's HSL values quite closely resembles 2-bit per channel RGB.

Yes I read about those restrictions. That's why I am trying to ask some experienced NESers who did something like that. Consoles have the standard possibilities but always they can be "extended".
Like the raster effect, tile map data, palette data switch "on the fly".

[lidnariq]

Actually as far I know NES's HSL values quite closely resembles 2-bit per channel RGB.

No, not even close.

The NES basically gives you boolean saturation, so there's minimal ability to display things that are neither fully saturated nor fully greyscale.

Additionally, there's no ability to update the NES's palette in the middle of a frame without turning off the display temporarily, so you basically only have 25 colors to work with.

[AWJ]

First of all, the NES doesn't speak RGB at all. A 6-bit color RAM entry on the NES is 2 bits of luminance + 4 bits of hue (with 0 meaning white/grey, 1-12 meaning blue->magenta->red->yellow->green->cyan, and 13-15 meaning black)

As far I know I read that it's possible to produce 4 colors for 8x1 block of pixels.

It's normally 4 colors for every 16x16 block of pixels, and one of those colors has to be a common background color over the entire screen.

You're limited to 4 3-color palettes for the background and 4 3-color palettes for sprites (plus the common background color). Changing color RAM in midscreen requires turning off the display (otherwise the PPU address space is not accessible at all outside VBlank) and waiting for HBlank (otherwise you get visible snow). The CPU isn't nearly fast enough to turn the display off, change some colors, and turn the display on again within a single HBlank, so a midframe palette change effectively requires leaving at least one blank line in the middle of the screen.

By using custom cartridge hardware (i.e. MMC5) you can circumvent the 16x16 block limit (that's where the wildly optimistic "4 colors per 8x1 block" that you've been told presumably comes from) but the color RAM limitations are fundamental to the hardware.

[lidnariq]

The most technically impressive color demos for the NES are blargg's Flowing Palette demo and neilbaldwin+blargg's Litewall demo.

Notice that even though these are very large palettes, they're very low resolution, and the CPU has no free time to do anything else at all.

[tokumaru]

You can get something similar to RGB with the RGB121 trick.

[tokumaru]

As far I know I read that it's possible to produce 4 colors for 8x1 block of pixels.

This is possible with hardware upgrades only (i.e. a mapper in the cartridge). The only commercial mapper that increases color resolution is the MMC5, which can do 4 colors (actually 3 colors + global background color) per 8x8 block. Some tests have been made with 8x1 color resolution, but no mapper with that feature has been made available yet.

[greatkreator]

Thanks for the demos! Impressive!

But from the technical point of view 3 colors + background is real for each 8x1 pixel block using fullscreen and 60 fps (if such a mapper will appear some day)?

[JRoatch]

What result can NES produce to display for example and "RGB222" array of almost arbitary values?

I guess something like this?

2015-12-10_random-pixels.nes

(16.02 KiB) Downloaded 143 times

Apologies for the dummied out code in it. I was just working on my project, and I decided to whip this up in 10 minutes

[greatkreator]

It seems it's standard possibilities. Isn't it?
I cannot see the 8x1 "colorness".

[tokumaru]

60 fps

No, definitely not 60fps without more help from the mapper. Without DMAs or anything to automate memory transfers to VRAM, the VRAM bandwidth on the NES is pretty lame. Without forced blanking, you can realistically update 200 to 250 bytes per frame, and a name table alone is 960 bytes (32x30 tiles). In addition to that, a color resolution of 8x1 would greatly increase the amount of attribute data, which is normally only 64 bytes.

It is possible for a mapper to speed up VRAM transfers, but again, a mapper with this feature hasn't been made available yet.

Could you explain to us WHY you need something like this? In the SNES thread you said it was for something like FMV but not exactly... Are you trying to render a game in software or something like this?

[tokumaru]

It seems it's standard possibilities. Isn't it?

Looks like it. Random patterns, random name table, random attribute table, random palettes.

I cannot see the 8x1 "colorness".

You won't see that in any emulator. Like a said, a mapper that does this doesn't exist yet, and emulators don't emulate things that don't exist.

[greatkreator]

I guess I am able to produce such a mapper.
The only problem video hardware limitations.

I would like to have FMV injections in my games.
They just impressed me too much in the childhood (:

[AWJ]

60 fps

No, definitely not 60fps without more help from the mapper. Without DMAs or anything to automate memory transfers to VRAM, the VRAM bandwidth on the NES is pretty lame. Without forced blanking, you can realistically update 200 to 250 bytes per frame, and a name table alone is 960 bytes (32x30 tiles). In addition to that, a color resolution of 8x1 would greatly increase the amount of attribute data, which is normally only 64 bytes.

Since we're already requiring a custom mapper, obviously you'd put the nametables and attribute tables in ROM (one of the only things MMC5 can't do, oddly enough) Or better yet, dual ported CHR RAM and a CPU on the cartridge with direct access to it.

The only question that remains at this point is whether a cartridge full of custom hardware pumping arbitrary data to the PPU with no 6502 intervention really qualifies as doing something "on the NES". Ah, if only that Hellraiser game hadn't been cancelled...