This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

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

Effective way to display almost random RGB(222) on NES?
by on (#160460)
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.
Re: Effective way to display almost random RGB(222) on NES?
by on (#160463)
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.
Re: Effective way to display almost random RGB(222) on NES?
by on (#160465)
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".
Re: Effective way to display almost random RGB(222) on NES?
by on (#160467)
greatkreator wrote:
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.
Re: Effective way to display almost random RGB(222) on NES?
by on (#160468)
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)

Quote:
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.
Re: Effective way to display almost random RGB(222) on NES?
by on (#160469)
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.
Re: Effective way to display almost random RGB(222) on NES?
by on (#160470)
You can get something similar to RGB with the RGB121 trick.
Re: Effective way to display almost random RGB(222) on NES?
by on (#160472)
greatkreator wrote:
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.
Re: Effective way to display almost random RGB(222) on NES?
by on (#160474)
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)?
Re: Effective way to display almost random RGB(222) on NES?
by on (#160475)
greatkreator wrote:
What result can NES produce to display for example and "RGB222" array of almost arbitary values?

I guess something like this?
Attachment:
2015-12-10_random-pixels.nes [16.02 KiB]
Downloaded 101 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
Re: Effective way to display almost random RGB(222) on NES?
by on (#160476)
It seems it's standard possibilities. Isn't it?
I cannot see the 8x1 "colorness".
Re: Effective way to display almost random RGB(222) on NES?
by on (#160477)
greatkreator wrote:
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?
Re: Effective way to display almost random RGB(222) on NES?
by on (#160478)
greatkreator wrote:
It seems it's standard possibilities. Isn't it?

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

Quote:
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.
Re: Effective way to display almost random RGB(222) on NES?
by on (#160479)
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 (:
Re: Effective way to display almost random RGB(222) on NES?
by on (#160482)
tokumaru wrote:
greatkreator wrote:
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...
Re: Effective way to display almost random RGB(222) on NES?
by on (#160483)
Well, if you want to take the route of letting the mapper do all the dirty work, then sure, you can get full screen 60 fps video. I wonder if a mapper could write to palette RAM fast enough to update a significant number of colors during hblank, so palettes could be changed without the need for blank scanlines.
Re: Effective way to display almost random RGB(222) on NES?
by on (#160484)
tokumaru wrote:
Well, if you want to take the route of letting the mapper do all the dirty work, then sure, you can get full screen 60 fps video. I wonder if a mapper could write to palette RAM fast enough to update a significant number of colors during hblank, so palettes could be changed without the need for blank scanlines.


CGRAM is internal to the PPU, so you can't just expand it the way you can expand the VRAM (i.e. 4-screen mirroring or ROM nametables) And having a mapper write to it via $2005-2007 implies bus mastering, which isn't supported by the NES either.
Re: Effective way to display almost random RGB(222) on NES?
by on (#160485)
True...
Re: Effective way to display almost random RGB(222) on NES?
by on (#160487)
Alternatively, my 16x1 palette zones demo.

AWJ wrote:
And having a mapper write to it via $2005-2007 implies bus mastering, which isn't supported by the NES either.
If you really wanted to be terrible, you could have the NES emit a series of LDA $20FF,X instructions (with X=8) and generate address bus conflicts (driving A0..A2 and R/W from the cartridge at relevant cycles) to make the write speed fast enough to fit in hblank (2 writes / 5 cycles, so 8 writes = 20 cycles = 60 pixels)
Re: Effective way to display almost random RGB(222) on NES?
by on (#160489)
lidnariq wrote:
Alternatively, my 16x1 palette zones demo.

AWJ wrote:
And having a mapper write to it via $2005-2007 implies bus mastering, which isn't supported by the NES either.
If you really wanted to be terrible, you could have the NES emit a series of LDA $20FF,X instructions (with X=8) and generate address bus conflicts (driving A0..A2 and R/W from the cartridge at relevant cycles) to make the write speed fast enough to fit in hblank (2 writes / 5 cycles, so 8 writes = 20 cycles = 60 pixels)


Correct me if I'm wrong, but in order to write to CGRAM in mid-frame I believe you have to do the following:

write $2001 to turn off rendering
write the CGRAM address to $2006 (two writes)
write your color data
write $2005 and $2006 to fix up the nametable address (four writes)
write $2001 to turn on rendering again

That's eight writes worth of overhead before you've written a single byte of actual color data. Even with your dirty pseudo-bus-mastering trick, the overhead alone uses up all the HBlank time.
Re: Effective way to display almost random RGB(222) on NES?
by on (#160490)
Don't need to write $2005, you're not changing the fine X scroll. Just seven writes: 2001/2006/2006/2007/2006/2006/2001 ... at least as long as you're ok with clearing the MSB of fine Y scroll.

Also, the very first write to $2006 can happen well before you disable rendering.
Re: Effective way to display almost random RGB(222) on NES?
by on (#160498)
AWJ wrote:
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...

You could look at the WIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIDE Boy.

Image
Is Star Fox "on the Super NES"?
Re: Effective way to display almost random RGB(222) on NES?
by on (#160504)
lidnariq wrote:
Don't need to write $2005, you're not changing the fine X scroll. Just seven writes: 2001/2006/2006/2007/2006/2006/2001 ... at least as long as you're ok with clearing the MSB of fine Y scroll.

Also, the very first write to $2006 can happen well before you disable rendering.


That Indiana Jones title screen is very nifty. So it's just barely possible to squeeze in one color update per scanline if you use perfectly cycle-timed code and also force HBlank to start a little early.

Combined with a hypothetical mapper that can sync with the PPU MMC5-style and feed an arbitrary data stream to it, you could pull off something analogous to 93143's SNES hicolor bitmap technique. 4 colors per 8x1 pixel sliver, 13 colors with one of them replaceable per scanline. No tile count limit either, hell, no real "tiles" at all because the mapper is just feeding arbitrary data to the PPU (presumably ignoring the address bus completely except for syncing purposes). Since the mapper is doing all the work, animating full screen at 60FPS is no problem either! You just need a ridiculous amount of precalculated data (both the actual bitmap/attribute map data, and 6502 code for the palette updates)

But, again, the need for a hypothetical mapper that goes well beyond the capabilities of even (expensive and rarely used) MMC5 makes me question whether this really counts as "doing it on the NES". The analogy to SuperFX and SA-1 doesn't entirely hold because at least those were actually produced and used in real games during the console's commercial lifetime.

Another thing I just thought of: does MMC5's PPU syncing even still work if you extend HBlanks the way Indiana Jones does? Doesn't the syncing rely on a particular access pattern that occurs during HBlank? Your hypothetical mapper might need a different PPU-syncing method from MMC5, one that's specifically designed for this rendering technique. That takes you even farther away from "using the NES" and closer to tepples' "put a TV tuner in a NES cartridge and hook up your XBox" territory...