fsakura probably knows most of this, but here is a little PPU primer for others as I understand it.
Making a discrete video generator for a "toy" 6502 console is something I've batted around in my head recently as well. From what I understand, the purpose of the NES PPU was to save bandwidth and space by only being able to control the position of 8x8 pixel tiles, which carry information about palette entries. This saves bandwidth by only needing to upload indices into specific tiles to the PPU, which then uses it's internal digital logic to figure out which pixel within the tiles is to be displayed on screen.
I would argue that tile format graphics, instead of a full VGA framebuffer, serves the 6502 well to save space and bandwidth. However, it seems a bit overkill to mimic an entire PPU in discrete components. You would need some way to convert the tile format (which is obviously not a linear framebuffer) in VRAM (preferably dual port) for the background and sprites to linear format, figure out priority (which sprites and BG tiles are in front of which?), create a separate line buffer of RGB components, and then iterate through the RGB components within the line buffer and convert to composite.
The NES PPU cheats at NTSC- it uses a lookup table of ones and zeros to figure out which color/hue is at which phase relative to colorburst. Here is a contrived example:
Code:
Entry 0: 000000111111
Entry 1: 000001111110
Entry 2: 000011111100
If you clock out each bit of the LUT at a constant frequency, you get a square wave output. If the clocking frequency is the some multiple of the colorburst frequency (I think it's 12 times colorburst 3.58*12= ~42MHz), the bits at which the ones begin and end determine the phase; the pattern loops a number of times until the electron beam has moved a sufficient amount. In fact one of these LUT entries is in fact used to generate the colorburst signal! Consequently, the output color information is a square wave instead of a sine wave. The magnitude/saturation is calculated using the high nibble of an internal register- I'm not sure how the value is converted to analog. I would suggest skipping that step and use an RGB encode such as the
AD725 to generate the NTSC video.
If you defer the NTSC encoding to an external chip, I suspect you would have some luck doing PPU emulation in a microcontroller. Start tile conversion and priority calculations one scanline before Vblank ends, like the real PPU, VERY QUICKLY output the calculated RGB values to display to a RAM linebuffer, and have a counter IC iterate through that RAM and upload to a DAC. The DAC feeds into the NTSC encoder. The microcontroller should also provide sync, although I recall Daryl/8BIT talking about a 7400 series TTL chip that can output encoding signals (which is still made!).
TLDR: Probably can be done, but not easy, and not minimal component.
Login
Register
FAQ
Search
