[imamelia]

As posted from another board:

Okay, I've been learning a bit about the SA-1 and messing around with a patch that somebody else made for it, and I've come across some difficulties and things I wasn't sure about. I'll worry about the other stuff later, but what I'm wondering about right now is the BW-RAM mapping register $2225. Specifically, bit 7 of $2225, which should determine where the BW-RAM is. According to the wiki page:

$2225 (#$00, W, x)
SBBBBBBB
S = BW-RAM source to be projected
0 = $40-43 in 32 blocks(uses B0 to B4)
1 = $60-6F in 128 blocks(uses B0 to B6)
B = BW-RAM mapping for the SA-1(much like $2224)

So setting bit 7 should make all of banks 60-6F usable, shouldn't it? But then how exactly do you use BW-RAM from those banks? Everything else I've seen about the SA-1 seems to assume that BW-RAM is mapped to banks 40-43, and the one (poor) test I did suggested that it should be in banks 40-43 (I checked a series of loads and stores to the first area, set bit 7, then checked the second area). I can't even find anything in the bsnes source code to suggest it being mapped to banks 60-6F. So is this an unfinished function or what?

I should also mention that the person who made the patch can't even get all of banks 40-43 to work; according to him, he can't use more than half of that area (presumably, the third and fourth banks just mirror the first and second).  Could anyone shed some light on any of this?

[Nightcrawler]

I think you're getting confused on perspective and what the register is actually doing. Things are mapped differently between the SNES CPU and SA-1 CPU perspectives. Register $2225 is allowing you to select a single block ($0-$1F for $40-43 and $0-$7F for $60-$6F) from either the $40-$43 BW-RAM bank region OR the $60-$6F BW-RAM Bitmap region (from the SA-1's perspective.) and map that to $6000-$7FFF in banks $00-$3F and $80-$BF from the SA-1's perspective.

This has NO effect on mapping from the SNES CPU perspective!! You can only access BW-RAM at $40-$43 from the SNES CPU anytime and that should always work.

Register $2224 does almost the same thing as $2225, but is for the SNES CPU perspective! You can use $2224 to map the selected block ($00-$1F) from the $40-$43 region to $6000-$7FFF in banks $00-$3F and $80-$BF from the SNES CPU's perspective.

As far as the mirrored banks in $40-43, that may be game specific. The SA-1 can use up to 2mbit of external BW-RAM, but it is not required. I would imagine if a game used only 1mbit, you would get the mirrored effect described. I don't know off hand if all SA-1 used the same amount of BW-RAM (say all 1mbit or 2mbit) or they varied.

[imamelia]

Huh.  Does that mean, then, that banks 60-6F can be referenced uniquely—and separately from banks 40-43—from the SA-1 perspective?

Also, this patch is for a game that didn't originally use the SA-1.  That would probably change things, but I'm not sure how to get around games being hardcoded to expect a certain amount of BW-RAM (or SRAM, for that matter)...or make sure that a homebrew ROM uses the full 256 KB either.  I've always been confused by mapping related to the cartridge rather than the SNES hardware.

[Nightcrawler]

Huh.  Does that mean, then, that banks 60-6F can be referenced uniquely—and separately from banks 40-43—from the SA-1 perspective?

Yes. When the SA-1 executes code, it can access BW-RAM bitmap image range at banks $60-$6F and normal BW-RAM at banks $40-$43. When the SNES executes code, $60-$6F will NOT map to the BW-RAM bitmap image area. I don't believe anything is mapped at all is mapped to $60-$6F on the SNES side ever for SA-1 mapping and results would be open bus.

I don't know why you care so much about $60-$6F access. You don't need this for most uses of the SA-1 conversion features.  This could only possibly be useful if you were creating bitmap data on the fly, and then also absolutely needed byte per pixel access to modify, and weren't already using 256 color format (BW-RAM is already byte per pixel). What on earth are you trying to do?

Also, this patch is for a game that didn't originally use the SA-1.  That would probably change things, but I'm not sure how to get around games being hardcoded to expect a certain amount of BW-RAM (or SRAM, for that matter)...or make sure that a homebrew ROM uses the full 256 KB either.  I've always been confused by mapping related to the cartridge rather than the SNES hardware.

The emulator is responsible for the details of mapping the cartridge correctly. You'd have to look and see how SA-1 games are actually being mapped. I imagine with BSNES, you can define the correct mapping if the emulator doesn't quite get it right. Most emulators care about getting the games to run, not necessarily fully mapping the full capabilities of the add-on chips.

A good place to start is see what your patch changed to get the game recognized as SA-1. It probably mimics internal header information from one of the known SA-1 games which gets mapped accordingly in the emulator. Taking a peek at emulator code should then tell you if all SA-1 games get mapped the same way or there are game specific checks that result in different BW-RAM. I'd also check for the BW-RAM mirroring on several emulators and see if they all do this.

I would confirm myself the mirroring and the patch itself. I wouldn't just trust some guy who didn't seem to understand what it was he was doing. For that matter it wouldn't hurt to confirm what I have said. It should be correct, but it's possible there may be a minor missed detail or two as I don't do much SA-1 work.

You're going to have to start going through this stuff yourself and understanding what's being done or you probably won't be able to use it effectively.

[gauveldt]

If I understand correctly then the SA-1 can see the entire  BW-RAM (mapping both 40-4F/60-6F spaces) but the SNES only sees half (the 40-4F portion)?

If so it might explain why emulators have an issue where only 128KB of the 256KB RAM possible is useable.  IIRC the SMW S-1 patch author indicated attempts to use 128k-256k region in emulators just ended up as a mirror of the 0k-128k region but I didn't read anything to indicate whether or not the author got that issue from the SNES CPU bus perspective, the SA-1 perspective, or both.

I've read the official dox (book 2) and got the ROM banking figured out to get a full 8MB ROM map but still wrapping my head around the BW-RAM banking as it's more complicated.  The SMW SA-1 authors said something about being able to map that area in bitwise patterns and stuff (unless I'm confusing the bitwise patterning stuff with the character conversion logic since the author never clarified the difference).

I want the SNES CPU to have as much ram available as possible since I'm going to pretty much want it to live in WRAM and/or BW-RAM (meaning K and B are both in RAM or BW-RAM) for extended periods.

My understanding is:
[1] The SNES CPU will slow down the SA-1 whenever they share buses
[2] The bulk of ROM accesses ought to be done by SA-1 to utilize the character conversion logic
    (implying the majority of ROM graphics will be bitmaps versus characters)
[3] [1] and [2] suggest that other ROM data (such as audio) should be transferred by the SA-1
    through a BW-RAM window set aside for the purpose
[4] Due to [1] whenever the SA1 is going to transfer to the BW-RAM window the SNES-CPU must have its home only in WRAM
[5] The SA-1 thread is 4x faster than the SNES CPU thread is the sang in [1] is avoided
[6] If the SNES CPU thread is also working (not perma-sleeping in WAIs) something between 4x-5x is possible

WRAM is slow and small so the SNES cpu should not be taking residence there often (in this extreme case it probably makes sense to just JMP to a WAI opcode).  I envision a system where the SNES CPU has a directing (script processing) role (but is commandeered by interrupts to access the hardware which only it has access to such as the APU ports and PPU/DMA/HDMA registers).  In this case the WRAM WAI sleep would be the case of the SA-1 pumping new code into WRAM for the SNES CPU (and/or DMA and/or HDMA) to operate on.  You can think of this in terms that the code window (script routine) has completed and the SNES CPU is WAIing for a new script to execute (which will be started when the SA-1 is finished transferring a new script and the SNES CPU subsequently woken up).

It has to be a highly cooperative model so that each processor avoids the other's buses in all but worst cases (it may be posible that a huge piece of code that must be run by the SNES CPU would be more efficiently executed from ROM access than paged code chunks in BW-RAM and then it would be the SA1's turn for a catnap in WAIwai-land).

The format of the code window in BW-RAM might be st up like this:

[prefix]<code block><suffix>

The prefix might be empty.  If the SA-1 writes a prefix it would do stuff like set up A,X,Y,P,B,K,D,S correctly for the code block about to run.  If a code block is just successive continuation from the previous one being written no prefix is necessary (it can be all code).  When execution gets to the suffix section it initiates a request to the SA-1 for more data before becoming homeless and taking residence in a WRAM WAI shelter.

This windowing algorithm basically implements a crude form of paging or allows the SNES CPU to run sequences of short routines.
Essentially a script processing thread...

Dang I wish MSU1 and SA-1 could be in the same cart and that all emulators supported it.

Did anyone also consider that SA-1 also gives you nice full 16-bit fixed point multiply/divide capability?  Nice more accurate math that's even faster than the PPU's MUL/DIV!

The SA-1 gives a homebrew game (or intricate hack of an existing game such as SMW, FF6, ToP made to run 64mbit+SA-1) lots of nice goodies if its use can be mastered.

I really want to see some new life in this thread and maybe have these ideas expanded on.

[Nightcrawler]

If I understand correctly then the SA-1 can see the entire  BW-RAM (mapping both 40-4F/60-6F spaces) but the SNES only sees half (the 40-4F portion)?

Right on that. I think your general understanding of the points you mentioned are also correct.

Certainly the SA-1 has great potential to hombrew if it could be fully leveraged. As you know, there is a pretty big learning curve to really being able to take advantage of this setup. It's of little surprise that most commercial games utilizing the SA-1 didn't even take full potential of it either. It's probably the most advanced and versatile of all of the add-on chips.

[gauveldt]

...
...It's of little surprise that most commercial games utilizing the SA-1 didn't even take full potential of it either. It's probably the most advanced and versatile of all of the add-on chips.

It's certainly a fresh perspective when one looks at it again after having dealt with PC multithreading.
Want true multiprocessing on your SNES (even better than trying to do so with the APU)?  Add an SA-1

I really like the fact that SA-1 has a lot of shared memory with the S-SPU (the only thing the SA-1 can't see is the the WRAM and the only thing the S-SPU can't see is the somewhat smaller I-RAM and is more than made up for with the sharable BW-RAM which can meet or exceed the WRAM in size -- 2mbit or 256KB according to the official dox, maybe even 4mbit 512KB on the SA-1 side unless that is a typo in official book 2), and that it also use the S-CPU's instruction set (unlike MARIO1/SuperFX/SuperFX2).

...and that ability to use bitmapped graphics converted to the PPU character mode graphics in hardware can't be overlooked either