Without a PC-Engine, and not wanting to use SNES due to problems, I was wondering how to create a VDP/PPU?
VT-03/Onebus is a way, But I need something better, like a Do-It-Yourself project, All I need is parts to make the upgrade for the NES PPU,
Also, If I'm doing this, Emulation is required to replicate the features, But the current emulators are too messy or in a language too hard for me to look at.
Assistance is appreciated.
Fact: The following consoles are currently having to be upgraded by people in Atariage - the ColecoVision, Atari 7800 and the 2600, But the NES might happen to need a boost!
What are you trying to do exactly? Add support for "graphics packs" that draw instead of the original tiles? Upgrade the NES to 4-bit graphics? Pipe two PPUs together for two graphics layers? Design a new backward-compatible PPU in Verilog and throw it on an FPGA?
I can assure you that creating a new PPU will be a much bigger problem that whatever you are currently facing with the SNES. If the NES PPU isn't enough for you, just don't use the NES, get over whatever problem you have with other platforms and use those.
Even if by a miracle you were able to "upgrade" the NES PPU, what would be the point if you were the only one with such an upgraded console? Nobody would be able to play your game(s). On the other hand, lots of people have perfectly good SNESs.
If you used a VT-03-based hardware clone with cartridge slot, then you wouldn't be the only one with that console. You also haven't done anything yourself either

my SNES stuff is gonna continue, it seems.
See the SNES Thread for more,
Case closed right here.
A simple upgrade that would be easy to implement is having 16 sprites per line. There is enough time to fetch 16 sprite patterns, Nintendo just used 8 sprites to cut transistor count.
psycopathicteen wrote:
A simple upgrade that would be easy to implement is having 16 sprites per line. There is enough time to fetch 16 sprite patterns, Nintendo just used 8 sprites to cut transistor count.
That and there'd be more gate delay when trying to compute priority from twice as many shifters. That's why the Super NES, which allows 34 slivers (but only 32 actual 8x8 pixel sprites), uses a line buffer instead of a separate shifter for each sprite.
I beleive it is possible to have a second background layer if you double up the speed of the sPPU memory accesses, but the issue is where would you put the registers to control the second layer?
Maybe one of the 12 unused cartridge pinouts could be used as a switch between "NES" and "special NES" games. In "special NES" games, registers $2008-$200f control BG2.
I've been upgrading the nes PPU for my Megaman project on the PCE for some time now. I ran into a few problems for the sprite upgrades. Mostly when I give the PPU larger sprite sizes. The PCE has 10bit sprite X and Y coords and 0 for both = -32, -64. So you can smoothly scroll sprites to the left side of the screen (and right too). Megaman does the drop cell method for the left side, and uses the last 8 pixel non display edge on the right in conjunction with drop cell. I've replaced all Megaman metal tile frames with single 32x32 hardware frames.
Anyway, the method I came up with to fix this problem of 8bit coords for X/Y with larger sprites - was to add onto the sprite DMA function. There's a shadow sprite buffer that the DMA reads from. The shadowed 4 bytes given additional attributes/features to the corresponding 4 OAM bytes in the real buffer (for whatever $4014 points to). For X/Y corrds, each additional byte is a signed offset to be added to the original 8bit coord. The other bytes give more subpalettes and more 'banks' for the cell number, etc. The upgraded DMA routine zeros out the values in the shadow buffer as it reads them, to keep compatibility with the original PPU specs. The idea is to have both old sprite definitions and new sprite definitions existing on the same screen at the same time. I currently have the shadow buffer in area that would normally not be used by NES (it might be mirrored area, but I use $1800 in the logical address range).