I have been reading documents on the PPU and its EXT pins. I gather that a second PPU can be connected to the master one to make an image instead of a plain background color. I have some questions:

What does the master PPU "do" with the 4-bit value it gets from the EXT pins?What does the slave PPU output to its own EXT pins?Did any commercial games actually use 2 PPUs, either to create parallax scrolling or otherwise?

EXT0 through EXT3 are inputs, and specify an extra 4bpp layer, chosen from the first 16 colors in the PPU palette. This layer only shows in places where both the sprite and background layers are transparent.

The backdrop is any pixel where the background is transparent and no opaque sprite pixel is drawn. A PPU with $2000 bit 6 = 0 enters "receive EXTBG" (aka "master") mode. This replaces any backdrop color with the 4-bit color index received on the EXT pins. This can display any color in CGRAM $3F00-$3F0F and is the only way to display the colors in $3F04, $3F08, and $3F0C while rendering is enabled. The sprite colors ($3F11-$3F13, $3F15-$3F17, $3F19-$3F1B, $3F1D-$3F1F) cannot be reached through EXTBG. On the Famicom and NES, this value is fixed at 0, causing $3F00 to appear in all backdrop pixels.

A PPU with $2000 bit 6 = 1 enters "send EXTBG" (aka "slave") mode. This always draws the backdrop from $3F00 but sends the low 4 bits of the CGRAM address on the EXT pins. If these are connected to a PPU set to receive EXTBG, the receiving PPU cannot tell whether, say, $0A means background color $3F0A or sprite color $3F1A. But mods acting as an external color encoder, such as the NESRGB and Hi-Def NES, intercept PPU communication to make the PPU send EXTBG and set the palette to black background and white sprites. This way, the mod can read bit 4 from composite output and bits 3-0 from EXT.

If you're trying to wire two NTSC PPUs into one system, you have to ensure that writes to $2001 go to both PPUs at once. Otherwise, if rendering is enabled on one and not the other, they will fall out of sync by one pixel every two fields, or 30 pixels per second, because the NTSC PPU skips the resting dot between the pre-render line and line 0 in every other field if rendering is enabled but doesn't skip it if rendering is disabled.

There are two practical ways to wire them up.

PPU1 sends, PPU2 receives: PPU2 generates the composite output based on its 25-color palette. PPU1 sprites appear with background palettes. If EXT0 and EXT1 are swapped with EXT2 and EXT3 between the two chips, displaying $3F04, $3F08, and $3F0C is possible for a total of 28 colors.

PPU1 sends, PPU2 sends, external encoder chip: You essentially have the functionality of a PC Engine SuperGrafx. Both PPUs are set up as for NESRGB or Hi-Def NES (black background, white sprites), and the encoder receives the EXT and composite output signals from both PPUs, multiplexes them using configurable layer priority, and encodes the output as a composite, S-Video, or component (YPbPr or RGB) signal. Up to 49 colors are possible. Super NES-style color math is possible, treating PPU1 and PPU2 as sub and main screens. Color math can even be limited to specific color indexes, as in Genesis highlight/shadow mode.

You can't have both PPUs send and then mix the composite output directly because their color subcarriers may not be aligned.

Having some extra hardware mix the signals sounds pretty cool, because at that point you could implement other cool enhancements, such as 8x8 attributes, more palettes, a bigger (RGB?) master palette...

The main issue then would be finding the time to update twice the amount of VRAM each frame. Things are already pretty tight with games only having to do 1 sprite DMA and scroll a single background layer, doing twice the work is completely out of question. A dual PPU setup would require some sort of generic DMA functionality in order to be usable.

Having some extra hardware mix the signals sounds pretty cool, because at that point you could implement other cool enhancements, such as 8x8 attributes, more palettes, a bigger (RGB?) master palette...

The main issue then would be finding the time to update twice the amount of VRAM each frame. Things are already pretty tight with games only having to do 1 sprite DMA and scroll a single background layer, doing twice the work is completely out of question. A dual PPU setup would require some sort of generic DMA functionality in order to be usable.

Assuming a motherboard with one CPU and 2 PPUs were made, it would be hard to use sprites on the 2nd PPU, because the CPU is hardwired to write sprite-DMA to $2004. Unless another chip/register swaps between both PPUs at $2000-$3fff, in this case it'd be possible to do sprite DMA for both chips, but mapping the second chip elsewhere in the address map sounds more natural. In that natural case, the only way to get sprites on the 2nd chip is to write each sprite to its register, which is horrifying slow and won't even work properly anyway.

I don't think scrolling is much of a problem because typically only one playfield would scroll with actual level data in it. The other layer could be used for backdrop and/or text.

Thank you for the interesting answers. I take it then that there were no actual applications of dual PPU systems back in the day? It's a shame since it might have meant that emulators today would have supported this setup, giving programmers an extra layer to play with

As far as I'm aware, RGB PPUs (2C03, 2C04, 2C05) don't have EXTBG functionality because they use the EXT pin for their RGB output. Besides, they operate independently, displaying to two different screens.

I see, I don't know anything else that's using Nintendo's PPU (besides PC-10 which are also using RGB PPU). I guess the pins were designed for mixing in external video or something, but ended up never being used on any hardware.

Who is online

Users browsing this forum: No registered users and 5 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum