Why No Cartridge Access to the PPU?

[lidnariq]

Mega CD was reasonably well received and popular in the US, although not the blow-out hit that the CD-ROM² was in Japan.

The slot on the bottom of the GameCube for the Game Boy Player was originally intended for a RAM upgrade hooked up to the audio RAM, before it got us said Player.

[Pokun]

I see I didn't know that, in Sweden the Mega CD had quite a bad reputation for all of its interactive FMV titles and the 32X was considered a strange decision by Sega, both were considered flops. The Mega Drive itself did OK however, was more popular than the previous SMS and was only second to the SNES during the 16-bit era.

In other parts of Europe Sega won the 16-bit war however, maybe the Mega CD did better there.

[mannes]

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.

Couldn't this have been done if they added 1 extra line on the cartridge connection and replaced vram chip #2 with a simple transistor circuit? Since they removed vram # 2 anyway this would have been really cheap and easy to do and possibly given the system full ppu writes from cartridges at much faster speeds.

[Oziphantom]

no, as the PPU bus is not going to marshal with the 65816 bus and do a 50/50 split perfectly, as the PPU needs full bandwidth. so you would need to add another 16 address lines and then 16 data lines as the PPU bus is 16bits to the cart. But then how do you get data into said RAM faster as its on the PPU bus you will still have to access it via the port and during blanking anyway. So you just have more, and don't have any faster way. Unless its banked ROM which gives you instant access I guess. But that doesn't seem to really help any instances were people want this, they want a faster way into VRAM which a separate bus won't accommodate.

[lidnariq]

Since they removed vram # 2 anyway

?? are you confusing this with the megadrive?

[tepples]

There are a few things that could have been done to let the CPU perform programmed input and output (PIO) writes to VRAM at a modest complexity. They involve a VRAM write queue, or FIFO (first-in, first-out) structure, like that of the Genesis VDP.

• If a layer is not enabled in TM, TS, TMW, or TSW, turn the layer's time slots turn into write slots. This would eventually get used in the Game Boy Advance.
• Designate a tile number per background layer as presumed transparent. The PPU will not attempt fetches to this tile, instead using it for a write slot.
• Cache the last 8 by 1 pixel sliver from each layer. If two consecutive nametable slots have the same tile number and vertical flip, making a repeating pattern, and OPT has not changed the fine vertical scroll position, add a slot instead of the second fetch and used the cached value.
• Turn the 34th fetch column into slots.
• Add slots during the horizontal blanking between scanlines if there are fewer than 34 found sprite slivers.

[mannes]

Since they removed vram # 2 anyway

?? are you confusing this with the megadrive?

Not quite but I must be wrong about something. I read about a vram mod/hack where the owner soldered in the other 64kb of ram to his SNES. He showed photos and I thought he said he wired in the additional chip where vram #2 was supposed to be. I probably got it mistaken and he just wired his chip next to where the vram was, but I thought he said he soldered it in place of vram #2. I must of gotten it backwards in my own memory.

[mannes]

There are a few things that could have been done to let the CPU perform programmed input and output (PIO) writes to VRAM at a modest complexity. They involve a VRAM write queue, or FIFO (first-in, first-out) structure, like that of the Genesis VDP.

Would this have increased write speeds during hblank and vblank? If so, how much more data could theoretically be pushed into vram doing this? Sounds pretty neat I wonder why they didn't implement it before production.

[tepples]

VRAM write queue, or FIFO (first-in, first-out) structure

Would this have increased write speeds during hblank and vblank? If so, how much more data could theoretically be pushed into vram doing this?

A VRAM write queue would not have increased write speed during vblank. It would have made writing during hblank more practical, much as it was on the later Game Boy Color system.

Sounds pretty neat I wonder why they didn't implement it before production.

The PC Engine and Mega Drive were already out. Had Nintendo delayed the Super Famicom any more than it already was by adding a VRAM write queue, it might not have been able to overcome the other platforms' head start.

[mannes]

no, as the PPU bus is not going to marshal with the 65816 bus and do a 50/50 split perfectly, as the PPU needs full bandwidth. so you would need to add another 16 address lines and then 16 data lines as the PPU bus is 16bits to the cart. But then how do you get data into said RAM faster as its on the PPU bus you will still have to access it via the port and during blanking anyway. So you just have more, and don't have any faster way. Unless its banked ROM which gives you instant access I guess. But that doesn't seem to really help any instances were people want this, they want a faster way into VRAM which a separate bus won't accommodate.

But doesn't the sdd1 operate like this? If any of the cartidge rom address pins were shared with either vram or the ppu (or possibly the ppu output pins and just giving full control of the picture output to cart), it should be easy to perform writes with a simple additional pin that acts like a switch to some kind of multiplexer that could accept data from a cartridge cpu. It would have been very cheap to implement some copper and a few simple chips as a work around to crimping the vram from 128kb down to 64kb, considering they weren't planning on nerfing vram to begin with.

But I guess you're saying that even if there was 32 address lines available, the data rate would still be to slow. I thought the speed of the 65816 was the bottle neck for hdma writes as dma is capped at 2.68mhz? Wouldn't a faster main cpu give double the data write speed during blanking?

[mannes]

The PC Engine and Mega Drive were already out. Had Nintendo delayed the Super Famicom any more than it already was by adding a VRAM write queue, it might not have been able to overcome the other platforms' head start.

Yeah the timing was pretty critical I guess. It just seems they really needed an extra month to hash out the quirks since thier prototype design was slashed in what seems like the 11th hour. I wonder how long it was between the advertised prototype and final release product? Like it was mentioned earlier a vram port on the bbus side would have been a great idea in theory although having consumers buying additional components would likely be disaster for the US market. But doing what they did, forcing developers to release an additional special chip for every cartridge if they wanted the benefits of it, must have been a economical punch in comparison to something like the HuCard 3 which only needed to be purchased once. Then again prices dropped during the mid 90s so I don't know. It just seems including the extra 64kb of ram would have solved a lot of these issues to begin with and made the SNES a much more robust system. Not to mention the bbus side looks like another design flaw which makes good sense on the prototype that it was likely designed for, but rather useless without, as they couldn't really do much with the extra potential data after the nerf.

How much data can be pushed during vblank? It seems quite fast, is it possible to hide the blanking during the end of the TV draw phase and continually update to vram enough to achieve a full picture rewrite @ 30 or 60 fps?

[creaothceann]

But I guess you're saying that even if there was 32 address lines available, the data rate would still be to slow. I thought the speed of the 65816 was the bottle neck for hdma writes as dma is capped at 2.68mhz? Wouldn't a faster main cpu give double the data write speed during blanking?

*the speed of the 5A22; that's where the (H)DMA engines are located. Afaik we don't know why the DMA speed is ~2.68 MHz - probably because of support for slow (200ns) ROMs. From oscilloscope readings we know that DMA is 4 master cycles per clock phase, which is 186.{243386} ns.

The best way to increase the speed would've been doubling the data bus width from 8 to 16 bits. ROMs could still be slow, but transferring from two chips at once (just like VRAM).

To account for the additional 8 pins on the cartridge connector: the bank pins could be scrapped (reducing the address space back to 16 bits, with a layout similar to the NES but 128 KiB in size because of the 16 bits per address) and functionally replaced by a mapper on the cartridge. Or the B bus pins could be removed, which would actually free up 10 pins.

(But of course doubling the data bus width would require a new CPU architecture, sacrificing the NES backwards compatibility.)

[tepples]

Bulk DMA transfers 165.5 bytes per line, and I count 37 lines of 60 Hz vblank as usable. This gives just shy of 6 KiB: enough for an entire Game Boy screen (160x144 pixels, 2 bits per pixel) at 60 fps. In games that aren't FMV or coprocessor-rendered, you can push 4 KiB of sprite and background tile updates plus OAM plus whatever parts of the tilemap and palette need to be rewritten. You can extend vblank by using timed writes to INIDISP ($2100) to letterbox the view; Capcom's fighting games do this, as do most Super FX games.

[lidnariq]

I read about a vram mod/hack where the owner soldered in the other 64kb of ram to his SNES. He showed photos and I thought he said he wired in the additional chip where vram #2 was supposed to be. I probably got it mistaken and he just wired his chip next to where the vram was, but I thought he said he soldered it in place of vram #2. I must of gotten it backwards in my own memory.

It is technically possible to increase the SNES VRAM to 128KB, but you have to replace both chips, not just one. Only counterproductive things happen if you only replace one of the two (since except during mode 7, the SNES just treats its VRAM as 16 bits wide)

[lidnariq]

But doesn't the sdd1 operate like this? If any of the cartridge rom address pins were shared with either vram or the ppu (or possibly the ppu output pins and just giving full control of the picture output to cart), it should be easy to perform writes with a simple additional pin that acts like a switch to some kind of multiplexer that could accept data from a cartridge cpu.

You might be talking about "Bus mastering", as is supported by the 8086, the Z80, and 68k (this is what the RQ=BUSREQ=BR signal is for); in this case the S-CPU would get out of the way and let a cartridge CPU drive the same 24+8 bits of address bus, 5 controls signals, and 8 bits of data bus.

It would have been very cheap to implement some copper and a few simple chips as a work around to crimping the vram from 128kb down to 64kb, considering they weren't planning on nerfing vram to begin with.

While this theoretical bus mastering would let you get the 65816 out of the way, there's no guarantee the PPU could deal with anything any faster.

On the other hand, perhaps you're suggesting a "simple" multiplexer to allow the cartridge to directly interface to VRAM, bypassing the PPU entirely. If so, it's not simple at all: bus switches are huge and expensive in terms of pin count, PCB area, and unfortunately even silicon die area just for the massive number of wirebonding locations.

Furthermore, there is no moment when the S-PPU is not accessing VRAM for drawing the upcoming scanline. While this would let you increase bandwidth during vblank, any other moment would almost certainly yield so-called "snow".