Why does Address Bus B and /WRAM connect to Cartridge?

[bazz]

Address Bus B is only connected to PPU stuff.

I figure Address Bus B is connected to Cart so it can map some memory in the snes System banks 00-3f $2000+ region???

I'm really head scratching here. I don't really know enough about the purpose of another Address Bus. Why have 2? And why access it? It's been otherwise completely transparent to me, now I have delved into memory mapping. It is surfacing.

I can only guess that /WRAM is connected to cart incase it wants to... map WRAM somewhere else? If the guess is true, My question on top of that would be how does Address Bus A reflect real WRAM address? (normally mapped to banks 7e-7f).

[tepples]

Doesn't DMA require one of the source and destination to be on the A bus and the other on the B bus? If so, perhaps the B bus is connected so that carts have a way to DMA things into main RAM.

[koitsu]

Doesn't DMA require one of the source and destination to be on the A bus and the other on the B bus? If so, perhaps the B bus is connected so that carts have a way to DMA things into main RAM.

SNES DMA lets you transfer data between A->B or B->A, depending on what you want. The A bus is declared as "CPU Memory" (i.e. anywhere within the 24-bit 65816 addressing range), the B bus is declared as "PPU".

A bus is a 24-bit value which you specify entirely via registers $43x{2,3,4}.

The B bus is a 16-bit value, where you specify the lower 8 bits and the upper is always hard-coded to $21 (so that when doing a DMA transfer from A->B you essentially are writing to a $21xx memory mapped register of your choice).

The opposite transfer method (B->A) would be reading from a $21xx register and dumping what's read into some area of RAM that the 65816 can access natively (e.g. banks $7E/7F would be wise since they're the 128KB RAM area). Not that I've ever had need for the B->A (PPU->CPU) method, but the capability is there.

I can't help with the "hardware side" of things, i.e. I cannot explain the wiring of what pin correlates with what capability, why it's done that way, yadda yadda.

[bazz]

may anyone please answer why a cart would want to connect direct to address bus b and the wram lines? Why are they available to the cartridge?

[lidnariq]

Tepples's guess is as good as any other answer you're going to get. Exporting address bus B allows DMA to copy things to/from the cartridge (maybe a coprocessor) to the things on address bus A inside the console (e.g. RAM)

[blargg]

I always assumed that games like Yoshi's Island used that bus to handle the massive objects they can display.

[Near]

No games ever actually use address bus B from the cartridge connector.

It was a pretty bad bus. If you used it to send data, you wouldn't be able to DMA that data directly into VRAM (which is also exposed on the B bus), meaning you'd have to buffer it in WRAM, doubling your transfer overhead for any graphical data sent.

The Satellaview and Exertainment Bike use bus B, but only by way of the expansion port (same bus, different location.)

[qwertymodo]

The only cart I've ever seen that has used any pin of the B bus is the Super Gameboy, and even that only connected A1 (pin 59) to a capacitor, and none of the other address lines are connected to anything... so I'm not really sure what's going on there. The SuperFX doesn't use the B bus (verified for GSU-1A/2/MARIO-CHIP versions), neither do the Cx4, SA-1, SPC7110, or S-DD1. I can't speak for the other special chips, but I'm pretty sure they don't use it either. I believe the same is true for /WRAM.

Edit: byuu ninja'd me

[Ramsis]

Some flash cartridges use the B bus. The PowerPak's SDRAM DMA port sits at $21FF, a design choice that's probably related to a hardware register clash with the Exertainment bike (after a "long" reset, the PowerPak does some unknown stuff in the $21CX region).

[whicker]

The B-Bus is an implementation of the "I/O Ports versus Memory Storage" concept that a lot of 8-bit CPUs had at the time.

Since the CPU in the SNES has a "Motorola" heritage, then of course this port area is visible in the memory address space. As opposed to the "Intel" heritage, which DOES NOT map ports into the normal memory address space of the CPU and requires special CPU instructions to access those port locations.

In software, a port is something that either changes the behavior of the system (a settings area) or is a kind of I/O communication area ( Parallel-Port, Serial-Port, etc ). If you are familiar with other microcontrollers / microprocessors, this is just one of those intrinsic concepts that just makes sense. Having the ports in a known small area makes things easy to troubleshoot, easy to make assembler or compiler labels for, etc.

A memory location, by contrast, is supposed to just stores values (data) or instructions (program).

Why would they bring the port area out to the edge connector? Simplicity. It's simple to throw in a '373 latch and an address decoder to be able to have the program change settings in the cartridge- whatever "settings" was going to mean, because obviously the designers in 1987-1988 couldn't anticipate everything. Let's say the cartridge was going to have a serial port, well, why wouldn't you put its data and control registers in the B-Bus area, and then interrupt and DMA back into main Work RAM memory? Same thing with sending from work ram to the outside world... DMA from work ram into some sort of port area mapped on the B-Bus.

What if programs got so huge that we needed to use memory banks again like on the NES? well, the B-Bus port area to the rescue! What if we got to the point that we had multicarts (which DID happen, BTW) and since each game is probably going to be coded to run from a fixed memory location regardless of its actual address on the ROM, how else are we going to tell the cartridge what game to map in?

Now, what really happened? Oh, well... since we already have unused pins from the address decoders needed for the ROM, we'll just keep cost down and use those pins to map any config area into the cartridge memory space. Plus we save on gold plating for the fingers... Money trumps elegant design, every time.


P.S.
I know skeptics won't believe me because I don't have a citable source, but the extra pins on the Super FX cartridge became a form of keying so that the game genie (at the time) didn't work. This was a practical issue... The SNES 5 Volt regulator is limited to 1 Amp and has a 1.5 A fuse. It was feared that the Super FX + A game genie would blow that rapid react fuse or overload the regulator over a long period of time. This is also why Super FX games are supposed to check for the multitap, and then SHUT DOWN if it's found.

As for the original reason, of course they were going to try to get away with using the onboard 21 MHz clock, but it turned out to be too shitty to use (plus doesn't it stop clocking during WRAM refresh?)

[bazz]

Hello Whicker, Thanks for that post. Easy read

[magno]

I'm pretty sure whicker is 100% right, and I always thought those pins' purpose what the same whicker told.

Talking about this issue, I think S-DD1 decompression process could have been triggered by "monitoring" B-Bus pins. As most of you know, S-DD1 monitors any write to $4800 to begin DMA decompressed data to CPU; the PPU register, source address, destination address and size of DMA must be read from the address bus and data bus, but it could also be read from the cartridge's B-bus. Maybe I'm wrong, but that could be one utility for B-Bus.

[Near]

Nobody knows how the S-DD1 realizes when to begin decompression.

I simulate it by having the S-DD1 watch $4300-437f, which is decidedly not on the B-bus.

It's possible that the CPU doesn't even propagate accesses to internal CPU registers to the cartridge A-bus, but it's the only way I can figure for it to work. There's nothing really on the B-bus that would be useful for what the S-DD1 is watching.

[magno]

Nobody knows how the S-DD1 realizes when to begin decompression.

Really? I remember reading a thread in this forum about how S-DD1 works, but I can't find it now. Besides, if Nevitski managed to convert the original code to a "S-DD1-less" code, I suppose he should know how it works

I simulate it by having the S-DD1 watch $4300-437f, which is decidedly not on the B-bus.

I thought address space between $2100 and $5FFF was on the B-Bus, thus it showed up in the B-Bus pins of the expansion bus. Thanks for the correction.
Anyway, the S-DD1 watches $4800, not $4300. I'm 100% sure as I just disassembled the source code 1 minute ago.

[Near]

Besides, if Nevitski managed to convert the original code to a "S-DD1-less" code, I suppose he should know how it works

Doing that doesn't require knowledge of how the S-DD1 works internally. It means a) expanding the ROM and avoiding bank swapping behavior, and b) pre-decompressing all the graphics from the cached locations of the old "graphics packs".

Anyway, the S-DD1 watches $4800, not $4300. I'm 100% sure as I just disassembled the source code 1 minute ago.

$48xx are the S-DD1's own registers. It watches $43xx to know when to switch from feeding regular data to feeding decompressed data. $420b watching isn't enough, because it also has to know when we're referring to a compressed channel or not. The ROM address and size of the compressed data is passed through $43xx. At some point the chip has to 'get a clue' that a decompression is about to happen and it buffers some data, because it won't be able to start decompression and feed the first byte in eight clock cycles. That'd be insane.