Pixel/Palette Flickering For More Colors

[strangenesfreak]

The Hellraiser cart flickers pairs of colors together to fake more colors. There's a project in Brad Taylor's development guide that flickers between pairs of palettes to fake more palettes. I thought of a mapper that had the ability to combine both methods, or maybe even allowed flickering between 3 palettes/pixels, although that might be too uncomfortable for the player. Pixel flickering would be by checkerboard patterns and palette flickering would be by 8x1 pixel silvers to reduce the flicker as much as ossible. That would help simulate many more colors than usual. Would this be feasible to design on a PowerPak?

Maybe a whole screen palette could be simulated by flickering between 2 or 3 palettes, allowing for a custom PPU design inside the mapper to work with this pseudo-screenpalette. Perhaps that would allow "porting" of other system PPUs into the mapper, modified to work with the pseudo-palette. But would that be too big to fit inside the FPGA, too complicated to design to be practical, or too flickery or limited to be comfortable to use? Would these enhancements be just plain overdoing the graphics?

[tepples]

It would probably take a comparable amount of work to make a TV encoder from scratch, emitting proper NTSC signals through a DAC, vs. to make a TV encoder that emits an NES pixel stream.

[strangenesfreak]

To add on the pseudo-screenpalette idea, I also thought about the mapper outputting 2-3 pixel pattern consisting of colors of the same luminance to cause luma/chroma crosstalk, resulting in different hues.

It would probably take a comparable amount of work to make a TV encoder from scratch, emitting proper NTSC signals through a DAC, vs. to make a TV encoder that emits an NES pixel stream.

Does that mean that it would it be easier to design your own custom PPU instead of porting and altering another existing system's PPU?

[tepples]

It depends on what you mean by "port and alter". If you have a PPU/VDP design in silicon (either ASIC or FPGA), it would probably be easier to make the design emit an NTSC signal directly than to make it emit an NES compatible bitstream.

Notice that the Sega 32X accessory took this approach: the Genesis VDP graphics are routed through the 32X hardware, and the 32X graphics are drawn on top, rather than having the 32X pump pixels through the Genesis cart slot.

Wide Boy and Super Game Boy are special cases. They were practical because the Game Boy's output bit depth wasn't very high. Wide Boy 64 and Game Boy Player were practical because the N64 and GameCube were capable of shoving 15bpp video over a high-speed port.

[strangenesfreak]

If you have a PPU/VDP design in silicon (either ASIC or FPGA), it would probably be easier to make the design emit an NTSC signal directly than to make it emit an NES compatible bitstream.

Exactly how would the NTSC signal emitted reach to the NES? I'm a little confused, since there's no Video In pin or something like that on the cart connector pinout. Would the PPU directly emit the NTSC signal, then something else convert and buffer it to NES cart-compatible data?

[kyuusaku]

No, you'd have a special cartridge which inputs video from the console and outputs video to the TV (like the 32X). I see two options:

1) Design a mapper like MMC5 which keeps track of rendering and places stuff on the PPU data bus at the right time (kinda difficult)

or

2) Design your own renderer which locks to the NES's video and overlays another layer (very difficult)

[strangenesfreak]

Ok, I think I'm starting to understand now. So would such a special cartridge need an extra wire and adapter to connect its own TV out to the NES's wires to the TV? How much would it cost to install a TV out wire from the cartridge; would it be cheap? Could this 32x-like TV out concept be applied for audio too?

[tepples]

But by now, you're just using the NES as a 6502 CPU, 2 KB of RAM, and a gamepad. You're headed toward Theseus' paradox, and you might as well make your own console at this point

[strangenesfreak]

But by now, you're just using the NES as a 6502 CPU, 2 KB of RAM, and a gamepad. You're headed toward Theseus' paradox, and you might as well make your own console at this point

Heh, I can see your point. I could see ways to use audio and/or video genlocking without entirely replacing the PPU and APU, although it would probably be difficult to genlock with the cart and NES PPU and APU.

I thought as a good way to genlock with the NES PPU without leaving it most to waste, maybe a mapper could just generate sprites, while the NES PPU could just generate the BG. The PPU's sprite rendering isn't exactly the best it could've been - the 8 sprite limitation causes OAM flicker in lots of games, but the PPU's BG rendering enhanced with something like ExAttributes isn't as bad. Hardware genlocking with audio may not be necessary, aa mapper could just fire interrupts and load data for a game to write to $4011 at a certain frequency instead. I've read that Memblers's Squeedo mapper does this. But that would not allow the triangle to have volume control and may complicate IRQs for split-screen effects.

[tepples]

I thought as a good way to genlock with the NES PPU without leaving it most to waste, maybe a mapper could just generate sprites, while the NES PPU could just generate the BG. The PPU's sprite rendering isn't exactly the best it could've been - the 8 sprite limitation causes OAM flicker in lots of games, but the PPU's BG rendering enhanced with something like ExAttributes isn't as bad. Genlocking with audio may not actually be necessary, as a mapper could just fire interrupts and load data for a game to write to $4011 at a certain frequency; I've read that Memblers's Squeedo mapper does this. But that would not allow the triangle to have volume control and may complicate IRQs for split-screen effects.

An interrupt controller, possibly assisted by the video genlock circuitry, might help solve both problems if the audio mixer is clocked at scanline frequency. But then you'd have to do the sprites in the external PPU, as there would be no time to do 513-cycle DMAs. The 14 cycle overhead of entering and exiting an interrupt handler might cause problems as well.

[kevtris]

The Hellraiser cart flickers pairs of colors together to fake more colors. There's a project in Brad Taylor's development guide that flickers between pairs of palettes to fake more palettes. I thought of a mapper that had the ability to combine both methods, or maybe even allowed flickering between 3 palettes/pixels, although that might be too uncomfortable for the player. Pixel flickering would be by checkerboard patterns and palette flickering would be by 8x1 pixel silvers to reduce the flicker as much as ossible. That would help simulate many more colors than usual. Would this be feasible to design on a PowerPak?

Maybe a whole screen palette could be simulated by flickering between 2 or 3 palettes, allowing for a custom PPU design inside the mapper to work with this pseudo-screenpalette. Perhaps that would allow "porting" of other system PPUs into the mapper, modified to work with the pseudo-palette. But would that be too big to fit inside the FPGA, too complicated to design to be practical, or too flickery or limited to be comfortable to use? Would these enhancements be just plain overdoing the graphics?

Aaah the hellraiser cart. Not to threadjack, but I'm pretty sure it never existed as described, and nothing they claimed it could do would be possible. (or if it was, just a small subset).

Since the PPU stores the palette internally, you cannot change it very often, usually at blank and if you're REALLY GOOD sometimes during rendering (see: micromachines).

I have seen a pic of the hellraiser cart on their sell sheet for it that they handed out at one of the CES or similar. I gave it to tsr at some point to scan, but I don't think it ever got scanned.

Anyways, they had a clear pic of the cart in the ad, and it didn't look very complicated. The Z80 was clearly visible, as were a few ROMs, and some 74245's and things. There was no other really complex hardware on there that would help video rendering at all. It just seemed to be a Z80 acting as a coprocessor with some basic I/O to the NES, so they were using it maybe to perform calculations.

The Z80 definitely isn't fast enough to bankswitch or do video rendering in real time, so going by the pic, it can only really be a coprocessor.

[tepples]

The Z80 definitely isn't fast enough to [...] do video rendering in real time

Tell that to ZX Spectrum owners or Game Boy owners (Faceball 2000). The setup could have involved rendering to VRAM.

[strangenesfreak]

When you're genlocking with cart PPU and NES PPU video with RF output, how would you get the NES's audio output from a top-loader NES to mix with video? Would it be even possible, since the top-loader does not have A/V nor does it have an expansion port?

[tepples]

When you're genlocking with cart PPU and NES PPU video with RF output, how would you get the NES's audio output from a top-loader NES to mix with video?

The same way you get component video out of a newer GameCube: you send it back and get the older model. As far as I can tell, the top-loader NES is rare enough that it shouldn't matter.

[strangenesfreak]

What kinds of extra electronic parts would be needed to reduce noise from the cart PPU video output - resistors, capacitors?

If one wanted to mod a PowerPak cart for some wires for this genlocking, how would you define FPGA pins for those wires to connect with?

With an original Famicom, when using genlocking with the RF output, would you mix the cart PPU video with the NES audio from the Audio Out pin from the expansion port?