Why No Cartridge Access to the PPU?

[RandomDSdevel]

(After not receiving a suitably helpful answer to the question elsewhere.)

Why wasn't the SNES's PPU exposed to cartridges over the system's memory bus like the NES's was? (Aside from the SNES's CPU's DMA path to the system's PPU being fast and high-bandwidth enough, I mean.)

[lidnariq]

Expensive (per unit sold), fragile, and the NES put the PPU bus on the cartridge as a hedge because they weren't certain what they'd need.

The SNES cartridge slot (i.e. supporting, not the average cart) is already 62 signals on 3 1/4 inches of card edge; the PPU would need another 33 signals if mode 7 support was skipped, or another 48 if they wanted to make it possible to augment mode 7. 110 signals on a normal 2.5mm / 0.1" spacing card edge would be a very wide 5.5 inches, about as long as a PCIX64 card edge and noticeably wider than a PCIe 16-lane card edge. Or they might have done the same thing the NeoGeo did, with two PCBs, but that would make it even more expensive.

[creaothceann]

Not requiring the PPU to load the graphics from ROM allows them to be compressed.

[Pokun]

But the NES can do that too as long as you use character RAM instead of ROM, while it still benefits from the exposed PPU bus and even exposes access for adding extra nametables. Cartridges becomes more expensive though since they must always contain a character chip, ROM or RAM, it generally makes more sense to put VRAM in the console to keep cost of games down.

The NES has many weird or half-broken features that Nintendo fixed in later consoles (starting with the Game Boy), this might be considered one of them I guess.

[Fiskbit]

You can still offer just as much VRAM in the console while giving the cartridge access to the PPU bus. Most games wouldn't use this, so it wouldn't add per-unit cost. It would have been very handy for things like Star Fox, though, where DMAing data to VRAM is actually a significant bottleneck.

lidnariq's observation on connector size is pretty interesting and seems like a reasonable justification for dropping this, but I do consider this loss of functionality on the SNES to be a real shame.

[tepples]

The bigger shame is not adding a FIFO that queues writes to VRAM and commits them between reads by the PPU. Though the PPU uses most of the time during the scanline, it could have been designed to get off the bus long enough to make PIO or HDMA to VRAM viable:

1. Not all 34 sprite slivers in use
2. Some layers not enabled
3. Horizontally repeated tiles in a tilemap, letting the PPU reuse the pattern data bytes

[93143]

I don't know about "bigger". With S-PPU cartridge access, it wouldn't be nearly as important to stretch VRAM bandwidth a bit, especially in such an unpredictable way, and at the cost of potentially significant compute time wasted waiting for writes to go through (assuming it would work like the Mega Drive, which I believe stalls the CPU when it tries to write to a full FIFO).

Having reliable OAM access at some point in the line would be nice, especially with a FIFO.

Having a 16-bit bus would be nice too, as it would cleanly double VRAM bandwidth even if the CPU core itself only ever used half of it. I've always found it interesting that the SNES and Mega Drive both seem to have been designed for 128 KB of VRAM in two 64 KB chips, and the Mega Drive nerfed its VRAM DMA bandwidth by going with one 64 KB chip instead of two, while the SNES just cut both of its chips to 32 KB even though it had an 8-bit data bus and couldn't write to both chips simultaneously anyway. I know it was probably related to video chip design, but it's still amusing.

[creaothceann]

[...] the Mega Drive nerfed its VRAM DMA bandwidth by going with one 64 KB chip instead of two [...]

It's 2 chips... but contrary to what I assumed before they're two 4-bit chips.

[93143]

Huh. I tried to check that, and it sounded like there was only one chip.

Well, I guess the upshot is the same - the VRAM can only receive one byte per DMA cycle. Whereas the SNES VRAM could in principle receive two, except that, y'know...

[TmEE]

MD VDP internally uses a 16bit databus for the CPU interface and access to CRAM and VSRAM, but actual rendering only needs 8bits and only uses the serial port of VRAM to make the image. With full 16bit bus the VRAM bandwidth is doubled from CPU standpoint and rendering interleaves data using both of the serial ports one data unit after other. I'm not completely sure how the rendering part works in detail in the 128KB/16bit mode, it is something that is in the todo list, but many other things come first before I ever get to trying things out there...

A pixel bus on the cartslot could have been fun, it is what Saturn cartslot gives and it could allow whatever graphics capability to put into the cartridge that can stream data following pixel clock of base hardware and get it inserted as a new layer between existing ones. That how the MPEG decoder for the machine already works.

[Oziphantom]

the NES only has it as a way to make the NES cheaper and then push the costs onto every cart ever made. It was a dumb thing to have done in the first place, it just so happened that the NES was so cheap and rubbish that in the long run it worked out for them. Doing it on the SNES would have been counter productive, the amount of times it would have been used vs the costs of doing it, even if most of the carts didn't even have anything on the cart edge for it, the size of the cart and the cart edge would have made it worse.

For late era SNES being able to wack another 64K VRAM on a cart would have maybe been nice but I feel the better path would have been adding a memory expansion slot for it to be upgraded on the console once. Which is basically what they did on the N64, so I guess they learnt their lesson.

[creaothceann]

The same could've been done with the enhancement chips; just add a slot on the side where they can be inserted as cartridges like on the C64. Perhaps even a daisy-chain solution to allow games to use several chips at once.

Or there could be a panel at the bottom where they can be slotted in like SIM cards on today's mobile/smart phones.

[tepples]

Nintendo got away with expanding RAM on Nintendo 64 because it uses unified memory, meaning practically all memory in the machine is its work RAM. The RDRAM's latency and the 36 KiB of cache and TCM (16K CPU instruction cache, 8K CPU data cache, 4K RSP instruction TCM, 4K RSP data TCM, 4K RDP texture TCM) remain a bottleneck, just as streaming sprite cels into SNES VRAM is a bottleneck.

[Oziphantom]

The same could've been done with the enhancement chips; just add a slot on the side where they can be inserted as cartridges like on the C64. Perhaps even a daisy-chain solution to allow games to use several chips at once.

Or there could be a panel at the bottom where they can be slotted in like SIM cards on today's mobile/smart phones.

you could just do that with a pass through cart though, as Sega was going to do with the Power VR chip. But with the Snes expansion chips, needing to buy the DSP-1 and then DSP-2, DSP-3, DSP-4 and then the CX4 and the Super FX 1 and the Super FX 2 would have been to much, and a headache for the user. While a single 1 off VRAM upgrade late in the life of the machine would have been something the general user was probably famiular with by the then. From upgrading their desktop computers.

[Pokun]

My impression is that hardware upgrades are seldom popular for consoles. It's another thing for a PC that is made to be modular with lots of different parts from different manufacturers.
But for consoles you have to get software developers to support it and in general they rather make games that the most people can play, which is making a game that does not require the player to buy another device. And this means there are less games supporting the hardware upgrade which in turn makes it less attractive to the players, forming a vicious circle.

The Mega CD, Super 32X, 64DD are all examples of such features not being very popular. Things like multitaps and more obscure peripherals may also count, but they are usually for optional features only.

The Nintendo 64 Expansion Pak was successful but it's mostly used to optionally enhance games with, as there are only 3 games requiring it, which was probably a relatively simple feature to add. It was originally supposed to be a part of the 64DD only but after it the DD was withdrawn developers begged Nintendo to release it separately so they could get some use out of it for ROM cartridge games instead.
The Saturn's upgrades are similar in that not too many games requires them.

The PC Engine's CD-ROM² is about the only really successful hardware upgrade that I can think of (as there are more CD games than HuCard games). The PC Engine was designed with a CD-ROM disk drive in mind from the start as NEC was one of the pioneers of the format, and I guess CD games were so much cheaper to make that it was an attractive platform to release games for (though that doesn't explain why the Mega CD flopped).
And of course the Famicom Disk System also got really good support, at least in the beginning before the technology became obsolete for developers.