So why can't the cartridge write to the S-PPU?

[psycopathicteen]

A while ago either Blargg or Byuu (can't remember who) said that address Bus B is only connected to the cartridge to read but not to write. I was checking schematic diagrams but I could not find what is preventing the cart from writing to the PPU.

[kyuusaku]

Because the data bus is shared with the A bus? Because the address bus and R/W strobes are effectively unidirectional since there isn't any apparent mechanism to request the bus? Because overriding the bus would be bad?

Because of these things it seems the purpose of the B bus is to simply simplify peripheral decoding.

[ReaperSMS]

The B bus has it's own RD and WR signals, /PARD and /PAWR on the schematic. This is to let the DMA actually work well, and what all DMA is either A->B or B->A. It drives one address out CA0-15, another out PA0-7, and asserts CPURD and PAWR, or CPUWR and PARD.

As for a cart writing to the B bus, there's no way to request the CPU to leave off. The DMA unit does it via the RDY line on the 65816 core, which is not exposed on the 5A22. The CPU is probably always driving the PA lines, so you can't drive them from the cart.

[Near]

As for a cart writing to the B bus, there's no way to request the CPU to leave off. The DMA unit does it via the RDY line on the 65816 core, which is not exposed on the 5A22.

Rather pedantic but worth noting, the 2A03 also utilizes the RDY line for DMC transfers. But of course the APU is internal to the CPU. By lowering the RDY line, it causes the CPU to pause and continuously read on the next read cycle. Then one can push a new address value onto the bus, overriding what is actually read. Restore the address prior to raising RDY again, and you can perform an injected read.

RDY does not suspend CPU writes, so even IF the cartridge bus was connected to RDY (it isn't), that could not be used to write to anything over the A bus.

If you had RDY on the cart bus, you MAY be able to strobe /PAWR and override the data bus. However, even then, unlike the 2A03 where only three consective writes are possible before a read, the 65816 can get in states where it never reads (STP), doesn't read for an entire frame (WAI), or doesn't read for ten frames (B->A DMA transfer of 64K bytes on all 8 channels.) If you wanted to stop the CPU for up to 167ms just to write to the B-bus, you could possibly do it IF you had that RDY line.

As it stands, if you touch that data bus you are going to end up with bus conflicts. The SNES cart and expansion ports were designed from the ground up to be READ-based devices that respond to the CPU (master.) As far as I know, it's the same for the NES. Only there you also have the PPU bus there, so you can do crazy stuff with how it returns CIRAM/CHR RAM.

[tepples]

Do I understand these two points correctly?

1. The B-Bus exists so that the DMA unit can set up the source and destination addresses at the same time.
2. If a coprocessor on the cart has a bunch of data it wants to write to memory through the B-Bus, it should lower /IRQ and have the master start a DMA.

How does the Super FX write pixels?

[ReaperSMS]

byuu: I believe the '816 does obey RDY on writes as well, not that it matters since you don't actually have the line avaliable.

tepples: a is correct. b is somewhat correct, usually the code itself tells the coproc what it wants to send, and DMA's from that.

The SuperFX renders into a characer buffer stored in the on-cart RAM. The game still has to upload those characters to VRAM for the PPU to use. Basically, think of the elite wireframe proto on the NES, done large.

[Near]

byuu: I believe the '816 does obey RDY on writes as well, not that it matters since you don't actually have the line avaliable.

I stand corrected. Absolutely fascinating. I love that even after a decade and a half of research, I am still learning new things all the time about this hardware.