It is currently Sun Aug 18, 2019 8:21 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 50 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
 Post subject: NES with two PPUs
PostPosted: Sun Jan 13, 2013 1:21 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11397
Location: Rio de Janeiro - Brazil
In this post, 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.


Top
 Profile  
 
PostPosted: Sun Jan 13, 2013 7:19 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21558
Location: NE Indiana, USA (NTSC)
tokumaru wrote:
I wonder how they intended to setup the hardware for this

Decode separate PPUs to separate address ranges perhaps?

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Sun Jan 13, 2013 2:28 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11397
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sun Jan 13, 2013 2:55 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21558
Location: NE Indiana, USA (NTSC)
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.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Sun Jan 13, 2013 3:10 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11397
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sun Jan 13, 2013 3:57 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21558
Location: NE Indiana, USA (NTSC)
From the wiki:
Quote:
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.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Sun Jan 13, 2013 5:02 pm 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1348
tepples wrote:
From the wiki:
Quote:
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.


Top
 Profile  
 
PostPosted: Sun Jan 13, 2013 5:20 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11397
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject: Re: NES with two PPUs
PostPosted: Sun Jan 13, 2013 6:29 pm 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1348
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?


Top
 Profile  
 
 Post subject: Re: NES with two PPUs
PostPosted: Sun Jan 13, 2013 6:42 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11397
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject: Re: NES with two PPUs
PostPosted: Sun Jan 13, 2013 6:44 pm 
Offline

Joined: Sun Mar 19, 2006 9:44 pm
Posts: 1001
Location: Japan
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.

_________________
http://www.chrismcovell.com


Top
 Profile  
 
 Post subject: Re: NES with two PPUs
PostPosted: Sun Jan 13, 2013 7:14 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11397
Location: Rio de Janeiro - Brazil
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.

Quote:
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.


Top
 Profile  
 
 Post subject: Re: NES with two PPUs
PostPosted: Sun Jan 13, 2013 9:40 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
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.


Top
 Profile  
 
 Post subject: Re: NES with two PPUs
PostPosted: Mon Jan 14, 2013 4:29 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11397
Location: Rio de Janeiro - Brazil
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.

Top
 Profile  
 
 Post subject: Re: NES with two PPUs
PostPosted: Mon Jan 14, 2013 4:31 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7736
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 50 posts ]  Go to page 1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Majestic-12 [Bot] and 2 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group