The Famicom/NES PPU’s Pass-Through Graphics Capability

It’s not well known (but is becoming better known) that the NES’s PPU graphics chip has an unutilized feature. It has a way to pipe graphics into it from another PPU, giving the two chips a combined output. The Famicom and NES both ground out the pins that would allow using this interesting feature, making it impossible to use without desoldering and some other changes, but Youtuber decrazyo performed the necessary modifications (5 minutes) and thus made a system capable of hardware parallax scrolling, 128 sprites with up to 16 per scanline, and additional color flexibility.

The existence of this feature implies that the PPU was intended for greater things at some point in its development. A lot of the limitations of classic hardware end up being due to economic and complexity tradeoffs prevalent at the time of their making. I find it intriguing to imagine the PPU’s chip designers anticipating a future where it could have been daisy-chained like this.

Behind the Code: About the NES’ Sprite Capabilities

Displaced GamersBehind the Code series doesn’t get new videos often, but they’re always great. This one is more technical than usual, but I don’t think it’s really all that technical. It’s about how the NES processes and renders its sprites, particularly explains why there’s a eight sprite per scanline limit, and even reveals a couple of games that use that limit to produce special effects!

The gist: while each scanline is being prepared for display, the NES’ PPU looks through the entries for the machine’s 64 hardware sprites in order, finds the first eight that will display on the current line, and copies their attribute data to a small area of internal RAM. There is only space there for eight sprites, so, the NES cannot display more than eight sprites in a single scan line. Any later sprites in the primary attribute data won’t have room to be copied, and so the PPU won’t be able to display them.

One thing it notably doesn’t cover, however, is how games implement priority shuffling to cause sprites to flicker instead of not display at all. The video suggests that that might be coming in a future video….

NES Sprites, OAM, and the Battle for Priority – Behind the Code (Youtube, 19 minutes)