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.
tokumaru wrote:
I wonder how they intended to setup the hardware for this
Decode separate PPUs to separate address ranges perhaps?
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
Bregalad wrote:
It would have mande the NES at least as good as the Mega Drive.
Now that's an overstatement, considering that the Mega Drive can display 61 colors out of 512, uses 4bpp tiles, has way more VRAM, more sprites, scanline counter, etc...The gap would surely be smaller, but it would certainly not be as good.
I always wondered what the deal with the master/slave selection bit was... well, now I know!
To be as good as the Mega Drive, you'd need two PPUs comparable to the VDC of the PC Engine, hence my "wannabe SuperGrafx" comment above.
tepples wrote:
"wannabe SuperGrafx"
This is indeed a much more fitting description for the NES with 2 PPUs.
So, are there any catches regarding this expansion board? Are any components besides the ICs necessary? It would be nice to do this with minimal modifications to the NES itself. We obviously need to unground the EXT pins and connect them to the board, but I'm unsure of what kind of modifications would be necessary to decode the address as necessary (and there's also the possibility of "bankswitching" the slave PPU so it can make use of the sprite DMA).
Using this in combination with the normally unused epxansion port under the NES would be... OMFGAMAZING !
The second PPU is also not restricted to be the NES PPU, it could be another co-processor that would render something completely different using the 16 BG palettes (yes, 16, including the normally unused entries 4, 8 and 12).
Bregalad wrote:
The second PPU is also not restricted to be the NES PPU, it could be another co-processor that would render something completely different using the 16 BG palettes (yes, 16, including the normally unused entries 4, 8 and 12).
Yes, you could use anything that generated 16-color bitmaps. You could basically create a whole new PPU, with several background planes, sprites, rotation... The only drawback would be the 4bpp result. Still, I think that a 16-color image could look more colorful than a 25-color one with the severe color distribution restrictions the NES has. It would still be possible for the master PPU to overlay some sprites on top of it all, and one large object/boss using the background.
I wonder if the master PPU still lets EXT pixels go through when rendering is disabled... If this is the case, you could update at least 4 palette entries per scanline and have a more colorful picture.
But I guess this rout is just too hardcore. I imagine that a device that syncs to the PPU and generates a whole picture would be pretty hard to make, specially with all those graphical features. Two PPUs should be much easier to sync, so I guess that would be an interesting first test.
Are the EXT pins related to how the Famicom Titler handled the subtitling that gave it its name?
mikejmoffitt wrote:
Are the EXT pins related to how the Famicom Titler handled the subtitling that gave it its name?
Famicom Titler has an RGB PPU, and the RGB PPU uses the EXT pins for RGB output.
Quote:
But I guess this rout is just too hardcore. I imagine that a device that syncs to the PPU and generates a whole picture would be pretty hard to make
Yes, but the perspective of turning my NES into something more powerful than the concurencing Sega consoles would bring me some joy, even if it was a bit late ^^
It someone came up with this let's say just after the launch of the Mega Drive, Sega fans would have had their ass kicked
Basically just another "PPU" with it's own VRAM and a single 4BP layer, with scrolling would be great. It could be the "main" layer, and the normal NES PPU would handle the sprites, and the "top" layer used for text, status bar, or whatever else. It would look like the Megadrive really I think, maybe slightly less colours but who cares ?
An addition of several features for the extra PPU, either mode-7, offset per tile, or a second scrolling background, would kick everyone's ass so hard. The only problem is that all of this can't be done only with the expansion port, internal modification to the NES is necessary.
Perhaps Nintendo never acted on this because a lot of the features that a second PPU would provide could be done just as easily with hardware on the cartridge that blasts pixels to the regular PPU. (See: Wide Boy and Super FX.) I still believe it's possible to make a TV tuner for the NES, which would allow Xbox 360 level graphics.
There is the MMC5 route too, Do not forget that Famiclones cannot work with either!
But yes, I agree that better graphics are possible, but due to difficulty and costs, we'd be stuck with the SNES or TG16 for better graphics... as tepples said to me before!
Use the EXT pins to look for the values 0, 4, 8, and C, and use it to drive a multiplexer that selects between the video_out pins of 2 PPUs.
Hypothetically, this would yield 2 video planes with 2 independent palettes, and sprites of the low plane would have their own colors as well.
But then you have the genlock issue twice over. You have to make sure that not only are the PPUs synchronized with respect to frame start but also that they're on the same color burst phase.
Quote:
I wonder if the master PPU still lets EXT pixels go through when rendering is disabled... If this is the case, you could update at least 4 palette entries per scanline and have a more colorful picture.
Nope, it displays the currently indexed palette.
tepples wrote:
But then you have the genlock issue twice over. You have to make sure that not only are the PPUs synchronized with respect to frame start but also that they're on the same color burst phase.
Tie the low PPU's /SYNC to the high PPU's /VBLANK pin, and drive both PPUs with a single clock.
Bregalad wrote:
Nope, it displays the currently indexed palette.
Only when the VRAM address is pointing to $3F00-$3F1F, IIRC. Whatever the reason for the master PPU to be trying to render color 0 is (the whole background uses blank tiles, rendering is off and v is pointing anywhere, rendering is off and v is pointing to $3F00), would the data fed through the EXT pins always show through the transparency?
Drag wrote:
Use the EXT pins to look for the values 0, 4, 8, and C, and use it to drive a multiplexer that selects between the video_out pins of 2 PPUs.
I don't follow... I understand that you want to jump back and forth between the two video outputs, but I don't get how watching for values 0, 4, 8 and C would help with the switch. Colors 4, 8 and C can't even be displayed unless rendering is disabled... What am I missing?
tokumaru wrote:
I understand that you want to jump back and forth between the two video outputs, but I don't get how watching for values 0, 4, 8 and C would help with the switch. Colors 4, 8 and C can't even be displayed unless rendering is disabled... What am I missing?
0, 4, 8, and C are the "transparent" colors. When the high PPU is outputting one of those color indices, switch to the low PPU's video_out. That way, the low PPU's video is seen in the "transparent" areas of the high PPU.
I see... do the EXT pins even output 4, 8 and C though? Since the actual color being drawn is color 0, I imagine that's what goes to the EXT pins, which would make detecting transparent areas even easier.
I must admit that making use of the full colors of both PPUs (for a total of up to 49 colors, with a palette count similar to that of the GBC) sounds awesome!
Detecting 0, 4, 8, or C requires a two-input NOR. Detecting 0 alone requires a four-input NOR.
Even more color is possible with two PPUs configured in output mode and an external video encoder chip that does all the compositing and palette stuff. Imagine setting a certain color as highlight or shadow.
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).
Is the PPU made with the same NMOS technology as the CPU, or is it CMOS technology ?
If the PPU is made of CMOS technology, then this statement is true.
But if it is made of NMOS, there is no PMOS transistors driving the outputs of the chip to the VCC level, only NMOS transistors that acts as resistors (in their linear region), therefore, it will not change anything if you set bit 6 and will not risk to damage the chip.
tepples wrote:
Detecting 0, 4, 8, or C requires a two-input NOR. Detecting 0 alone requires a four-input NOR.
True... I didn't consider the bit patterns.
Quote:
Even more color is possible with two PPUs configured in output mode and an external video encoder chip that does all the compositing and palette stuff. Imagine setting a certain color as highlight or shadow.
Cool idea, but then you lose compatibility with existing games, right?
If the encoder intercepts palette writes the way
that other recent project does, it can retain compatibility. And if you're simulating all the $2000/$2006/$2007 logic to block palette writes so that your bit 4 comparator can work properly, you're already intercepting palette writes.
tepples wrote:
If the encoder intercepts palette writes the way
that other recent project does, it can retain compatibility.
You said both PPUs have to be in output mode, but existing games put the PPU in input mode. You'd have to either patch the games or intercept that too.
The other project has to snoop on $2000 writes to track the VRAM increment bit (1 or 32), and it intercepts palette writes, so it probably already intercepts $2000 writes too.
mikejmoffitt wrote:
Are the EXT pins related to how the Famicom Titler handled the subtitling that gave it its name?
The titler pcb is massive. I wonder if it has an overlay video encoder like the sega 32x.
That it does. The entire left side of the Titler is dedicated to "genlocking" circuitry.
Ideas of enhancing the NES or any other system ultimately lead to realizing you could just use the SNES or whatever system is a generation newer. It's best not to go overboard with trying to enhance a system. Afterall, look what Sega did with the Sega CD and Sega 32X. Not exactly a success. Just an odd curiosity for the most part.
What I find interesting about this particular case is that at some point Nintendo actually had something planned, because the PPU has the pixel input/output functionality intact, it seems. Obviously the NES as we know it would never make use of that because the EXT pins are grounded, but the fact that they're there is very interesting.
I think it's interesting that the fact that the EXT pins are grounded appears to be the reason why color 0 is the universal background color. If you wired a 1 to any of the upper two EXT pins, the background color would be 4, 8, or C. (The otherwise unused palette entries)
So, if someone has a problem NES with a messed-up background color, we now know this is the culprit.
So, I'll restate an earlier question with some variation:
If I untie an EXT pin to ground and start feeding it random high/low signals, will I see garbled crap?
If so, can we utilize it as a crude means of software blitting with some minor hardware modifications to tie the EXT pins to some easily controllable line?
How about some neato audio-visualization?
Experiments pending later tonight...
This thread is awesome
Go hardware peoples, go go go!
So wait a minute... If you ran two PPUs, they would absolutely need to have the exact same even-odd frame sync, otherwise your image would slowly drift horizontally, right?
Which is why practically, I think Visual 2C02 -> netlist extraction -> accurate FPGA PPU would probably be a better option in the long run.
Dwedit wrote:
So wait a minute... If you ran two PPUs, they would absolutely need to have the exact same even-odd frame sync, otherwise your image would slowly drift horizontally, right?
I don't think so, I think you'd just get one of them jittering by
1 pixel2 pixels every vblank. After all, two vblanks is still 178683 pixels total for each of them, so there should be no net drift.
(edit: h/t
blargg)
Dwedit wrote:
So wait a minute... If you ran two PPUs, they would absolutely need to have the exact same even-odd frame sync, otherwise your image would slowly drift horizontally, right?
This alignment issue
has already been mentioned in this thread. Seriously, I don't think that's a big problem at all. Just keep rendering either on or off in both PPUs, being careful to make the switch away from the skipped dot.
lidnariq wrote:
Dwedit wrote:
So wait a minute... If you ran two PPUs, they would absolutely need to have the exact same even-odd frame sync, otherwise your image would slowly drift horizontally, right?
I don't think so, I think you'd just get one of them jittering by 1 pixel every vblank. After all, two vblanks is still 178683 pixels total for each of them, so there should be no net drift.
Wouldn't it jitter by two pixels, since
both PPUs would be jittering the opposite direction at the same time? You'd get a single-pixel jitter if one never skipped a pixel, and the other did every other frame.