If they had extra pins that they had no use for, I'm sure this would have seemed like a very easy and cheap addition. You take 4 unused pins and add 4 pulldown resistors. Then when you go to draw the background, instead of using index 0, you take the value for the index from those pins.
Maybe they planned to use this in arcade hardware, where you'd have a bigger budget than a home console and could afford two PPUs. Then you'd get more colors, and you could scroll the background layer independently from the foreground layer. I believe they later added support for independent layers on the SNES hardware so this type of thing was probably already in demand from game designers.
It’s a feature that doesn’t take much die space to implement, so if they didn’t need those pins otherwise I don’t see why not to add it. If it turned out that the PPU wasn’t good enough for what developers expected, this would have let them make a quick follow-up console as a stop-gap with little R&D expense required. If you want an actual example of overengineering on the NES, they put a giant custom connector on the bottom of every system that never ended up getting used for anything. They probably wasted at least a couple bucks per unit on that.
They did use the connector on the Famicom multiple times, so it's not a complete waste. They just didn't end up bringing the Disk System or Satellaview stateside.
As the other reply mentions, the connector was used for the disk system in Japan. Nintendo didn't like it because of piracy and reliability issues; and then finally memory mappers rendered it obsolete.
The disk system had a much more powerful audio chip. If you have a Switch, you can hear it on the "Excitebike vs" game that never made it to the US, or you can go on YouTube and look up the opening to the Japanese version of Zelda.
The Famicom didn't even have the connector. It had a standard off-the-shelf 15-pin connector instead, which was mainly used for external controllers. The Disk System instead connected to the Famicom via a RAM adapter that plugged into the cartridge slot. The NES expansion connector was intended to be used for a localized version of the Disk System, but as you mention this was scrapped in favor of cartridge mappers. After this, Nintendo then planned to use the expansion connector for a localized and expanded version of the Famicom Network System modem (see https://archive.org/details/0966961706/page/390/mode/2up ) but this also ended up getting scrapped.
The Disk System RAM Adapter plugged into the cartridge port on a Famicom. The Famicom 15 pin expansion port is just a fancy joystick port (the console is otherwise limited to a pair of hardwired joypads).
The NES expansion port on its own doesn’t seem to have enough lines to support the disk drive, notably it doesn’t have any address lines (CPU or PPU) at all, or the PPU data bus. It seems a bit weird frankly with the choices they made, I’m not sure what it’s actually for, apart from breaking the idea of extra sound chips in cartridges.
It was definitely for the disk drive. The idea was that you'd leave the disk drive plugged into the bottom of the system and then have a separate cartridge with the RAM, drive controller, and BIOS ROM. Somebody recently made a homebrew version that shows roughly how it would have worked, see here if you're interested: https://www.youtube.com/watch?v=0iyQ1N43U-U
The PPU (and variants of it) was used in quite a few arcade machines, in addition to the NES.
I don't know if there were any actual machines that used dual PPUs, but the functionality was likely intended for creating an arcade machine with dual-layer background graphics.
Plenty of old consoles had strange unused features. For example, the Megadrive VDP outputs the palette indices for each pixel in addition to the analog RGB output. This feature was used by the System C board (a Megadrive in an arcade form factor) to attach an external RAMDAC with higher color depth and more on-screen colours, and has been used recently to provide native HDMI output (https://www.megaswitchhd.com/).
There is one obscure product that actually did use the feature. The Sharp Famicom Titler (or Famicom Editor) was a full Famicom that could show an external video input behind the Famicom graphics.
The EXT pins only allow setting the backdrop color to one of the palette values in the master PPU's color palette, so the Titler can't use that functionality to superimpose graphics over arbitrary video. It actually uses an RGB PPU which doesn't even have the EXT pins. Instead, it uses a separate video encoder chip for the video superimposing feature. https://www.nesdev.org/wiki/X0858CE
As far as I'm aware the NES PPU was custom-designed specifically for Famicom/NES products only. There isn't anything else that uses it, so I assume someone at Nintendo thought it'd be cool and that's that.
My real question is: how did Nintendo wind up making the same useless feature twice?
Mode 7 of the SNES PPU has a quirky submode called EXTBG which uses the high bit of each pixel as a priority bit for the sprites. This lets you draw background graphics above sprites in Mode 7 if you so choose. This seems like perfectly ordinary behavior, but the way this is implemented is actually insane.
For context, the SNES PPU-1 implements Mode 7 by individually addressing two 8-bit RAM chips. It has to do this because of memory bandwidth[0] - it puts the tilemap on one chip and the actual pixel data on the other, so it can pipeline the memory reads and just barely fit within the bandwidth limitations of the system. But PPU-2 has a third set of data lines, EXT0-7. When EXTBG is active and the high bit of the pixel is unset, PPU-2 reads color data from EXT0-7 instead of VRAM.
The only reason why this winds up just becoming a priority system, is because Nintendo wired up the second RAM chip's data lines to the EXT0-7 pins, so it reads the same data in either case. But it would work exactly the same as the NES PPU's EXT pins, except the SNES PPU doesn't have a master mode. It is always a "slave"[1] in the terminology of the NES PPU.
In a different world where the EXT pins had been routed to the cartridge port, we could have completely fixed the SNES's biggest limitation: slow DMA. The fastest you can update VRAM is a 2bpp Game Boy sized area of the screen once per frame, or a full-sized area of the screen at 15-30FPS[2]. You'll notice that aligns neatly with the capabilities of the Super Game Boy and Super FX, respectively. Nintendo and other developers got very creative with how they used these chips, but if we had EXT pins on the cartridge bus, that wouldn't have been an issue.
[0] This problem is unique to Mode 7 because, with an affine transform, each pixel requires two unpredictable lookups into a tile map and it's associated tile data. On other modes, the tile can only ever change once per 8 pixels, so less data needs to be read.
[1] God I hate this nomenclature
[2] This is, in fact, a downgrade from the NES. You can actually stream a full picture from VRAM to the PPU and have it change every frame. That's the basis of the trick tom7 uses in the video "Reverse emulating the NES to give it SUPER POWERS!"
Reminds me of a NES that I overclocked when I was around 14 years old. It was the sort of silly thing a nerdy kid would do with too much free time on their hands, and didn't do much to improve the system. Most of the time it caused more issues than it fixed, but it was a good learning experience.
This is far more exciting, since it adds functionality to they system. Maybe I'll dust off my old hacked up NES and do this at some point. If only I had the free time these days.
It was always fun seeing the weird things that would happen with over clocked consoles from the 80's and 90's.
The most notable one I have seen was the performance change on Road Rash on the Genesis/Mega Drive. RR1 & 2 it just speed up the whole game. RR3, it just increased the frame rate and made it a much more enjoyable experience.
Overclocking won't help with sprite flicker. Sprite flicker happens because the PPU will only evaluate the 8 frontmost sprites active on a line.
Sometimes you get sprites disappearing by priority, sometimes the software will alternate active sprites; software sprite disabling in some titles is probably harsher than needed (might flicker when there's more than X sprites on the screen, even if there is never more than 8 on one line)
Should be able to fix a bunch of stuff. Slowdowns, missed frames, etc.
The game only has a limited amount of time to do all of its logic before the VSYNC interrupt forces it to draw to the screen. Game have different ways of handling this, e.g. by rolling back and abandoning the changes, drawing whatever they have, etc.
A faster clock should make it s/t games that don't always get done in time should at least have a better chance.
What? No, how could you have such a disgusting mind!
Kidding :), sad folks downvoted you for the question though. The video breakdown highlights that the name is a joke in this section https://www.youtube.com/watch?v=V2kaV_m4iNU&t=250s but the other 4 minutes are worth watching as well.
There's a nice video demonstration here: https://youtube.com/watch?v=V2kaV_m4iNU
It would have been neat if Nintendo had set this up so the stock unit could have been expanded like this.
> So, if you like my ANES and you want to get a better look at it, check the description for a link to my OnlyFans.
BEEP!
> ...for a link to my GitHub.
Imagine if OnlyFans was a subscription service to see your favorite personalities do electrical engineering and software development! Oooh lah lah!
Or fan modification and testing? Ooo? Bladeless? Let’s talk about the Coandă effect.
OnlyFETs is an exclusionary name, but it rolls off the tongue so closely.
I mean, patreon seems to work that way if my YouTube feed is to be believed
But can it do a better bad apple?
What I'd like to know is: Why did Nintendo allow the PPU to pass along another pixel color, but didn't take advantage of it in a shipping product?
Is this a case of "you ain't gonna need it" overengineering; or was the PPU used in other products. (And thus these pins were used elsewhere?)
They might have been inspired by a similar feature in previous chips, like the external video support in the TMS9918: https://en.wikipedia.org/wiki/TMS9918#External_video.
If they had extra pins that they had no use for, I'm sure this would have seemed like a very easy and cheap addition. You take 4 unused pins and add 4 pulldown resistors. Then when you go to draw the background, instead of using index 0, you take the value for the index from those pins.
Maybe they planned to use this in arcade hardware, where you'd have a bigger budget than a home console and could afford two PPUs. Then you'd get more colors, and you could scroll the background layer independently from the foreground layer. I believe they later added support for independent layers on the SNES hardware so this type of thing was probably already in demand from game designers.
It’s a feature that doesn’t take much die space to implement, so if they didn’t need those pins otherwise I don’t see why not to add it. If it turned out that the PPU wasn’t good enough for what developers expected, this would have let them make a quick follow-up console as a stop-gap with little R&D expense required. If you want an actual example of overengineering on the NES, they put a giant custom connector on the bottom of every system that never ended up getting used for anything. They probably wasted at least a couple bucks per unit on that.
They did use the connector on the Famicom multiple times, so it's not a complete waste. They just didn't end up bringing the Disk System or Satellaview stateside.
As the other reply mentions, the connector was used for the disk system in Japan. Nintendo didn't like it because of piracy and reliability issues; and then finally memory mappers rendered it obsolete.
The disk system had a much more powerful audio chip. If you have a Switch, you can hear it on the "Excitebike vs" game that never made it to the US, or you can go on YouTube and look up the opening to the Japanese version of Zelda.
The Famicom didn't even have the connector. It had a standard off-the-shelf 15-pin connector instead, which was mainly used for external controllers. The Disk System instead connected to the Famicom via a RAM adapter that plugged into the cartridge slot. The NES expansion connector was intended to be used for a localized version of the Disk System, but as you mention this was scrapped in favor of cartridge mappers. After this, Nintendo then planned to use the expansion connector for a localized and expanded version of the Famicom Network System modem (see https://archive.org/details/0966961706/page/390/mode/2up ) but this also ended up getting scrapped.
The Disk System RAM Adapter plugged into the cartridge port on a Famicom. The Famicom 15 pin expansion port is just a fancy joystick port (the console is otherwise limited to a pair of hardwired joypads).
The NES expansion port on its own doesn’t seem to have enough lines to support the disk drive, notably it doesn’t have any address lines (CPU or PPU) at all, or the PPU data bus. It seems a bit weird frankly with the choices they made, I’m not sure what it’s actually for, apart from breaking the idea of extra sound chips in cartridges.
It was definitely for the disk drive. The idea was that you'd leave the disk drive plugged into the bottom of the system and then have a separate cartridge with the RAM, drive controller, and BIOS ROM. Somebody recently made a homebrew version that shows roughly how it would have worked, see here if you're interested: https://www.youtube.com/watch?v=0iyQ1N43U-U
The PPU (and variants of it) was used in quite a few arcade machines, in addition to the NES.
I don't know if there were any actual machines that used dual PPUs, but the functionality was likely intended for creating an arcade machine with dual-layer background graphics.
The RGB PPUs used in arcade machines didn’t have the master/slave functionality, they instead used those pins for the analog RGB output.
Plenty of old consoles had strange unused features. For example, the Megadrive VDP outputs the palette indices for each pixel in addition to the analog RGB output. This feature was used by the System C board (a Megadrive in an arcade form factor) to attach an external RAMDAC with higher color depth and more on-screen colours, and has been used recently to provide native HDMI output (https://www.megaswitchhd.com/).
There is one obscure product that actually did use the feature. The Sharp Famicom Titler (or Famicom Editor) was a full Famicom that could show an external video input behind the Famicom graphics.
I found this video that shows a Playstation running in the background of Super Mario Bros: https://youtu.be/TCsle-J9YzY?si=oyj_zZCKGionnzLu&t=423
The EXT pins only allow setting the backdrop color to one of the palette values in the master PPU's color palette, so the Titler can't use that functionality to superimpose graphics over arbitrary video. It actually uses an RGB PPU which doesn't even have the EXT pins. Instead, it uses a separate video encoder chip for the video superimposing feature. https://www.nesdev.org/wiki/X0858CE
Oh, interesting. I assumed the PPU could pass through video the way the TMS9918 can. My mistake!
As far as I'm aware the NES PPU was custom-designed specifically for Famicom/NES products only. There isn't anything else that uses it, so I assume someone at Nintendo thought it'd be cool and that's that.
My real question is: how did Nintendo wind up making the same useless feature twice?
Mode 7 of the SNES PPU has a quirky submode called EXTBG which uses the high bit of each pixel as a priority bit for the sprites. This lets you draw background graphics above sprites in Mode 7 if you so choose. This seems like perfectly ordinary behavior, but the way this is implemented is actually insane.
For context, the SNES PPU-1 implements Mode 7 by individually addressing two 8-bit RAM chips. It has to do this because of memory bandwidth[0] - it puts the tilemap on one chip and the actual pixel data on the other, so it can pipeline the memory reads and just barely fit within the bandwidth limitations of the system. But PPU-2 has a third set of data lines, EXT0-7. When EXTBG is active and the high bit of the pixel is unset, PPU-2 reads color data from EXT0-7 instead of VRAM.
The only reason why this winds up just becoming a priority system, is because Nintendo wired up the second RAM chip's data lines to the EXT0-7 pins, so it reads the same data in either case. But it would work exactly the same as the NES PPU's EXT pins, except the SNES PPU doesn't have a master mode. It is always a "slave"[1] in the terminology of the NES PPU.
In a different world where the EXT pins had been routed to the cartridge port, we could have completely fixed the SNES's biggest limitation: slow DMA. The fastest you can update VRAM is a 2bpp Game Boy sized area of the screen once per frame, or a full-sized area of the screen at 15-30FPS[2]. You'll notice that aligns neatly with the capabilities of the Super Game Boy and Super FX, respectively. Nintendo and other developers got very creative with how they used these chips, but if we had EXT pins on the cartridge bus, that wouldn't have been an issue.
[0] This problem is unique to Mode 7 because, with an affine transform, each pixel requires two unpredictable lookups into a tile map and it's associated tile data. On other modes, the tile can only ever change once per 8 pixels, so less data needs to be read.
[1] God I hate this nomenclature
[2] This is, in fact, a downgrade from the NES. You can actually stream a full picture from VRAM to the PPU and have it change every frame. That's the basis of the trick tom7 uses in the video "Reverse emulating the NES to give it SUPER POWERS!"
great name following the NESticle lineage
Reminds me of a NES that I overclocked when I was around 14 years old. It was the sort of silly thing a nerdy kid would do with too much free time on their hands, and didn't do much to improve the system. Most of the time it caused more issues than it fixed, but it was a good learning experience.
This is far more exciting, since it adds functionality to they system. Maybe I'll dust off my old hacked up NES and do this at some point. If only I had the free time these days.
Thx for sharing :)
It was always fun seeing the weird things that would happen with over clocked consoles from the 80's and 90's.
The most notable one I have seen was the performance change on Road Rash on the Genesis/Mega Drive. RR1 & 2 it just speed up the whole game. RR3, it just increased the frame rate and made it a much more enjoyable experience.
What did it improve? Sprite flicker? Slow down? I'd no idea this was possible on real hardware!
Overclocking won't help with sprite flicker. Sprite flicker happens because the PPU will only evaluate the 8 frontmost sprites active on a line.
Sometimes you get sprites disappearing by priority, sometimes the software will alternate active sprites; software sprite disabling in some titles is probably harsher than needed (might flicker when there's more than X sprites on the screen, even if there is never more than 8 on one line)
Should be able to fix a bunch of stuff. Slowdowns, missed frames, etc.
The game only has a limited amount of time to do all of its logic before the VSYNC interrupt forces it to draw to the screen. Game have different ways of handling this, e.g. by rolling back and abandoning the changes, drawing whatever they have, etc.
A faster clock should make it s/t games that don't always get done in time should at least have a better chance.
ANES? Like the homophone to anus?
makes blowing cartridges to then stuff into the ANES and enjoy; homophonic behavior.
Wait til you hear about the port on the NES’ bottom.
What? No, how could you have such a disgusting mind!
Kidding :), sad folks downvoted you for the question though. The video breakdown highlights that the name is a joke in this section https://www.youtube.com/watch?v=V2kaV_m4iNU&t=250s but the other 4 minutes are worth watching as well.
Oh man, A thing I literally needed right now haha
that's a really sweet ANES