NES with two PPUs

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

User avatar
tokumaru
Posts: 11643
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

NES with two PPUs

Post by tokumaru » Sun Jan 13, 2013 1:21 am

In [url=http://forums.nesdev.com/viewtopic.php?p=106055#p106055]this post[/url], viletim wrote:The EXT port is normally an input for pixel data (as palette indices) but can be set as an output by setting the appropriate bit in the PPU's control register (0x2000).
Wait, so at some point Nintendo planned on connecting 2 PPUs together so that one of them could generate an extra background plane? That's really interesting. I mean, unfortunately we wouldn't get more colors, but a second background plane for parallax effects or huge enemies/bosses would be very welcome.

I wonder how they intended to setup the hardware for this... each PPU would probably have its own memory, but would each be controlled by a different CPU also?

BTW, I don't mean to hijack the thread, I just found the existence of these EXT pins really interesting. Excited about the RGB output too.

tepples
Posts: 21936
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: RGB output from composite PPU

Post by tepples » Sun Jan 13, 2013 7:19 am

tokumaru wrote:I wonder how they intended to setup the hardware for this
Decode separate PPUs to separate address ranges perhaps?

User avatar
tokumaru
Posts: 11643
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: RGB output from composite PPU

Post by tokumaru » Sun Jan 13, 2013 2:28 pm

tepples wrote:
tokumaru wrote:I wonder how they intended to setup the hardware for this
Decode separate PPUs to separate address ranges perhaps?
What do you think would be the easiest memory range to map the second PPU to? Then you could control both PPUs with the same CPU. Updating 2 independent scrolling planes would require even more careful VBlank time management, but it could make games look more dynamic (although not more colorful). A second plane of sprites would certainly help a lot too, even if they had to use the background palette.

Damn, now I kinda want to try hooking 2 PPU together and make programs to use them. Well, I probably don't have the hardware knowledge to do it, but if someone else does it and emulators start supporting that setup, I'll definitely want to code something.

tepples
Posts: 21936
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: RGB output from composite PPU

Post by tepples » Sun Jan 13, 2013 2:55 pm

If you want to make a wannabe SuperGrafx, perhaps the most obvious place to put the PPUs would be $2000 and $3000. But then you'd have to somehow arbitrate which one gets access to which VRAM when.

User avatar
tokumaru
Posts: 11643
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: RGB output from composite PPU

Post by tokumaru » Sun Jan 13, 2013 3:10 pm

tepples wrote:If you want to make a wannabe SuperGrafx, perhaps the most obvious place to put the PPUs would be $2000 and $3000.
How is the decoding done on the NES? I'd have to modify it to have each PPU use half of the range that's currently dedicated to a single PPU. The new PPU would need its own 2KB (or 4KB) of VRAM for name tables, as well as RAM for pattern tables, since it wouldn't be able to access the CHR on the cart. I guess it should be fairly easy to make a "kit" with all of these chips (PPU + RAM + decoder) on a board that you could install on any console...

BTW, these EXT pins are setup as inputs by default, right? Because maybe it would be bad if both PPUs were trying to output data to these pins before the CPU had a chance to configure them.

tepples
Posts: 21936
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: RGB output from composite PPU

Post by tepples » Sun Jan 13, 2013 3:57 pm

From the wiki:
Setting bit 6 causes the PPU to output pixel values to the EXT pins - since the EXT pins are grounded on an unmodified NES, doing this is discouraged as it could potentially damage the chip whenever it outputs a non-zero pixel value (due to it effectively shorting VCC and GND together). Clearing bit 6 causes it to instead read values from the EXT pins; since they're grounded, this simply causes background pixels to use palette color 0 as expected.
Existing games clear bit 6, which sets the PPU to treat these as inputs. You'd need pulldown resistors on these lines in case a game doesn't enable the second PPU at $3000.

But another problem is that unless rendering is enabled at exactly the same time on both PPUs, they might fall out of sync because of the skipped dot in every other field's pre-render line.

User avatar
mikejmoffitt
Posts: 1349
Joined: Sun May 27, 2012 8:43 pm

Re: RGB output from composite PPU

Post by mikejmoffitt » Sun Jan 13, 2013 5:02 pm

tepples wrote:From the wiki:
Setting bit 6 causes the PPU to output pixel values to the EXT pins - since the EXT pins are grounded on an unmodified NES, doing this is discouraged as it could potentially damage the chip whenever it outputs a non-zero pixel value (due to it effectively shorting VCC and GND together). Clearing bit 6 causes it to instead read values from the EXT pins; since they're grounded, this simply causes background pixels to use palette color 0 as expected.
Existing games clear bit 6, which sets the PPU to treat these as inputs. You'd need pulldown resistors on these lines in case a game doesn't enable the second PPU at $3000.

But another problem is that unless rendering is enabled at exactly the same time on both PPUs, they might fall out of sync because of the skipped dot in every other field's pre-render line.
Wait, so if I was to tie any of the EXT pins high, I would expect to see things on-screen? I might tear apart my Famicom Twin and screw with that later.

User avatar
tokumaru
Posts: 11643
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: RGB output from composite PPU

Post by tokumaru » Sun Jan 13, 2013 5:20 pm

tepples wrote:But another problem is that unless rendering is enabled at exactly the same time on both PPUs, they might fall out of sync because of the skipped dot in every other field's pre-render line.
I guess that as long as you do all the enabling/disabling of rendering at a safe distance from the skipped dot and keep both PPUs either on or off you'd be OK. If you don't plan on using the other PPU all of the time, instead turning all rendering off disable only the background and put the sprites off-screen.

Now that I think of it, 2 sprite DMAs would eat nearly half of the available VBlank time, leaving not much time to update 2 scrolling planes, specially when scrolling vertically as well as horizontally. CHR-RAM animations start to become prohibitive too. Screw it, I'd like to try this anyway.

User avatar
mikejmoffitt
Posts: 1349
Joined: Sun May 27, 2012 8:43 pm

Re: NES with two PPUs

Post by mikejmoffitt » Sun Jan 13, 2013 6:29 pm

Could it be configured such that one PPU handles every even sprite and the other handles every odd one, effectively allowing 16 sprites on one line to be displayed?

User avatar
tokumaru
Posts: 11643
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: NES with two PPUs

Post by tokumaru » Sun Jan 13, 2013 6:42 pm

As I understand it, what comes out of the EXT pins is a 4-bit palette index for each pixel being rendered, with no differentiation between background or sprites. When this data goes into the other PPU, it gets rendered only on transparent areas, and always using the background palette. This means there are some limitations on sprite usage. For one, they will always be behind the topmost background and sprite layers, second, they will always use the background palette.

Not ideal, that's for sure, but they can still be used for items and animated level details while the primary sprites are used for more important objects. But yes, it should be possible to have 16 of them in one scanline.

Someone please correct me if I'm wrong.

ccovell
Posts: 1011
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

Re: NES with two PPUs

Post by ccovell » Sun Jan 13, 2013 6:44 pm

The bigger problem is (same as the SGX dealt with it) if you have a slave PPU, all sprites on the slave are behind the master BG. So if you have a background on the master PPU, it'll obscure those extra 8 sprites per scanline.

The SGX solved this problem with an extra chip that allowed you to configure the priority of the 2 BGs and 2 sprite layers.

User avatar
tokumaru
Posts: 11643
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: NES with two PPUs

Post by tokumaru » Sun Jan 13, 2013 7:14 pm

ccovell wrote:all sprites on the slave are behind the master BG
Which is why I said I wouldn't use them for general game objects, but only for things designed not to go behind the master background.
The SGX solved this problem with an extra chip that allowed you to configure the priority of the 2 BGs and 2 sprite layers.
Unfortunately I don't think this would be possible in this case...

If you decide to stick to a single scrolling background plane, you can use the master BG only to draw big objects/enemies or add more detail to the slave BG, reducing the chances of completely hiding slave sprites with it.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: NES with two PPUs

Post by blargg » Sun Jan 13, 2013 9:40 pm

I love the idea of actually hooking up a second PPU and seeing how well this works. It's like the plot in Jurassic Park where they revive old DNA and see something never seen.
tokumaru wrote:Now that I think of it, 2 sprite DMAs
The 2A03 wouldn't know about the second PPU so $4014 would always go to the primary PPU.

User avatar
tokumaru
Posts: 11643
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: NES with two PPUs

Post by tokumaru » Mon Jan 14, 2013 4:29 am

blargg wrote:The 2A03 wouldn't know about the second PPU so $4014 would always go to the primary PPU.
Holy shit, I forgot that the DMA was a CPU feature! Well, maybe we should "bankswitch" the PPUs then, instead of mapping one to $2000 and the other to $3000... Or keep them both mapped that way but also allow the second PPU to be seen at $2000 just because of sprite DMA. Having to stick to $2003/$2004 would be a worse limitation than the sprites being behind the primary layers or being background-colored IMO.
Last edited by tokumaru on Mon Jan 14, 2013 4:32 am, edited 1 time in total.

User avatar
Bregalad
Posts: 7871
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: NES with two PPUs

Post by Bregalad » Mon Jan 14, 2013 4:31 am

OK,
this sounds very interesting. So they PLANNED to allow 2 background layers, and then CANCELLED this feature ?!? I can't belive this ! It would have mande the NES at least as good as the Mega Drive.

Post Reply