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?
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.
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.
tepples wrote:
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?
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.
tepples wrote:
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?
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)
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?
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
tepples wrote:
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.
strangenesfreak wrote:
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.
strangenesfreak wrote:
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.
kevtris wrote:
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.
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?
strangenesfreak wrote:
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.
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?
??? Cart video output? If you mean peeking at the data bus, that's digital so there's no noise.
You definitely don't want to do DSP on RF video or even any video DSP with the Powerpak, it's so not equipped for that (needs ADC, DAC and RGB encoder). The reason why the 32X was feasible was because the MD outputs RGB, probably has a derivative of the pixel clock on the cart connector and IIRC the sync signals too.
You could do a Delta-sigma audio expansion output though with an output + resistor + cap (formed as a low pass filter) using the 20Mhz clock. That could be mixed in with the normal audio output using resistors.
If you really want special video, what you could do is at the start of vblank, write the mapper to tell it to count down to active video where it would overlay it's video by switching between two synced composite signals. There wouldn't really be any processing, but it would still require something other than Powerpak and still be nearly pointless IMO.
kyuusaku wrote:
You definitely don't want to do DSP on RF video or even any video DSP with the Powerpak, it's so not equipped for that (needs ADC, DAC and RGB encoder).
Would it be practical to install a small PCB or similar inside the cart containing a video processor+DAC genlocking with the NES's video, and assign more pins from a PowerPak FPGA to communicate with the video processor? Maybe not, since the extra board might be hard to fit inside the cart, and could be very messy to put inside...
Would it be just better to use the flicker methods mentioned in the first post in this thread instead of genlocking?
I would stick with the palette trickery because attempting the genlock thing is pretty insane.
I made some demos to (sort of) demonstrate the palette-filckery concept, showing a "whole" palette made by using pixel dithering + 2 palette flickering. You will need an emulator with NTSC artifact support (such as Nestopia) to see more colors than an emulator without. You can see more
here.
Or you can just download it (you
must right-click on the link and use "Save Target As", "Save Link As", or similar on the link)
http://strfr.freehostia.com/downloads/2frame.zip
Which of the following would you guys think would be the best?:
1. Attribute Flicker for Extra Palettes: Have a mapper flicker between palette pairs for extra palettes, alternating within 8x1 pixel silvers (in BG and/or sprites).
2. Pixel Flickering for Extra Color Depth: Have a mapper flicker between two or three colors (in checkerboard/diagonal patterns) of the same palette for extra colors in the palette (in BG and/or sprites).
3. Ideas 1 + 2: Have a mapper do both at the same time.
4. Tile-Based Layers: Have a mapper help render layers (and pseudo-sprites) by tiles (or 8x1 pixel silvers - allowing for smooth vertical scrolling). Usually, horizontal scrolling can only be as smooth as by 8 pixels, due to NES limitations. The mapper can also support smooth by pixel horizontal scrolling over monochromatic areas 8x1 pixels or greater. Combinable with ideas 1 and/or 2. If the whole screen needs horizontal scroll, the PPU's horizontal scroll register could be used.
5. Whole Screen Palette Flicker: Have a mapper render its own pixels and colors - through using a whole screen psuedo-palette made by swapping between two (or three) fields of alternating patterntable pixels and 8x1 pixel attributes. Is two or three the better here?
EDIT: Reworded ideas 4 and 5 a bit to be more clear.
I just remembered something that would help your palette demo: keep PPU rendering disabled until after vblank ends (like Battletoads does). This will result in the artifact pattern going through three different phases for a given pixel (over three frames), rathern than alternating between two. This might make your effect look better. In Nestopia with the NTSC filter enabled you should be able to tell when you're enabling the PPU late enough in the frame (examine Battletoads first to see the distinctive dot crawl pattern you get).
Definitely idea 4. Multi-screen scrolling sounds awesome, however the problem is that 8 horizontal scrolling pixels shoul remain the same color, and that handsome hardware would be required for this. However, vertical scrolling could look fine, and this sounds far better than anoying flickering.
blargg wrote:
I just remembered something that would help your palette demo: keep PPU rendering disabled until after vblank ends (like Battletoads does). This will result in the artifact pattern going through three different phases for a given pixel (over three frames), rathern than alternating between two. This might make your effect look better. In Nestopia with the NTSC filter enabled you should be able to tell when you're enabling the PPU late enough in the frame (examine Battletoads first to see the distinctive dot crawl pattern you get).
I just tried that (
http://strfr.freehostia.com/downloads/serial.nes, you MUST right and do Save Target/Link As or copy inside the browser)...and it looks even more of an acid trip!
While I could probably fix some of the color's weird diagonal effects, I wouldn't be able to control some of the others'.
I reworded ideas 4 and 5: they were a little awkwardly written; see my previous post in this thread.
EDIT: I added a demo demonstrating tile-based parallax scrolling, see the site
here, or download it at
http://strfr.freehostia.com/downloads/choppy.zip - you need to right click on the link and do Save Target/Link As or copy in the browser. What do you guys think about the demo?
I can't open any of your links or download any of your files, even when doing as you say, and every other possible ways I can think of.
And I'm kinda interested in seeing your stuff. Is there any chance this host is blocking IP's or something?
I doubt my host is blocking IPs...you might want to try to access the
webhost itself, if that doesn't work, then I'm sorry - I'm not sure what's happening for you.
I did upload the files:
This is the group of demos with the palette-flickery concept, showing a "whole" palette made by using pixel dithering + 2 palette flickering. You will need an emulator with NTSC artifact support (such as Nestopia) to see more colors than an emulator without.
This is a version of one of the demos from above - but the screen is turned on after 10 scanlines to change NTSC dot crawl.
And this is a demo showing tile-based parallax scrolling, press left or right to scroll in that direction. This has source included, but the others don't.
EDIT: Changed parallax scrolling demo download to include the nes file.
EDIT 2: Changed the parallax scrolling demo
again to include an extra file required for compilation.
The tile-based parallax scrolling demo (choppy) doesn't have an .nes file. Since I don't have your compiler and don't want to download it, make one for us and put it up here.
Oh, whoops!
Ok, I updated both the site download and the Mediafire download:
http://www.mediafire.com/?71ic2mxhncz
I also did a couple of more, check the
website or download here:
This is a couple of demos showing a drawing based on pattern table pixel flickering for extra color depth.
This is a group of demos showing a drawing based on using a whole pseudo-palette made from flickering between two "real" palettes and dithering.
EDIT: Changed all the files to include a file necessary for compilation.
I can't seem to be able to access your webhost no matter what I do. Does anyone else have this problem? The mediafire links work perfectly though. Just got the new stuff, I'll check it all out now.
I noticed how blargg's 3-phase NTSC demo turned white pixels into cyan, magenta, and yellow. I tried experimenting with this using a single grey palette ($0f, $2d, $10, $30), and it turned out to be a pretty decent looking palette. You can see
here. Download
here. I think I now see why blargg suggested to turn on the PPU late...;)
Using 3 pixel dithering patterns, that would allow for 20^3 = 8000 colors; but that would include very crude dithers such as those putting black and a little of (what the PPU digitally sees as) white together. The 20 figure was from the distinct 3-pixel combinations from the 4 colors of the palette; the ^3 was from the three dot crawl phases (cyan-ish, magenta-ish, yellowish).
Tokumaru, if you still have problems, you might want to try
proxyhustle.com; see if that works.