[justin3009]

I'm very curious on this as I'm not sure how this works nor what values would need to be stored to initiate it.

I'm messing around a little bit on Super Mario RPG and you 'CAN' expand the ROM to 6 MB using an ugly trick but as far as I can see, the data cannot be accessed normally by Geiger's. (Is it even possible to access regardless even WITH bank swapping?  This game has some very weird addressing issues in the emulator).

[PhyChris]

SMWC has some excellent info on SA-1. It would be a good idea to ask this question there too

[justin3009]

Will do so!  I saw their SA-1 chip for SMW (Though I think that just makes it 4 MB instead of the 6+ I'm aiming for).  I'll see if they have any information.

[Nightcrawler]

See if my explanation here helps on understanding the mapping and bankswapping for you.

[justin3009]

Okay, trying to make sense of it but I'm getting lost in all of the text ;w;

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.

Is this what I'd be after then or would I have to use the $2225 aspect as well?  It's also REALLY weird on how Super Mario RPG handles it's banks.  $C2:6E36 is what it says in the log but in the emulator it says $C2:EE36.  It's.. really, really weird on this game.

[Revenant]

Use $2224 if your code is running on the main CPU, or $2225 if it's running on the SA-1.

Note that both of those registers are for mapping RAM, not ROM; see the "Super MMC" register info here for ROM mapping registers, which is what it sounds like you're after if you want to expand the ROM.

The Super MMC registers are always written from the SNES side, but affect the address spaces of both CPUs. The lower 3 bits select a 1MB chunk of ROM to be mapped into one of the four mappable address ranges and the high bit enables/disables bank switching for that range (and basically just uses the default mapping if it's disabled).

I have no idea what the SA-1 support in Geiger's debugger is like (I suspect that address weirdness is its fault, not something the game's doing), other than that it doesn't support stepping through code running on the SA-1, which is a pain. I have a custom version of bsnes that has more useful SA-1 debugging features; the support for it isn't as complete as I'd like, and I haven't been developing it much lately, but I can put up a current build if you think it would be useful

[justin3009]

It's worth a shot.  I've never been a fan of bSNES but if I'm able to have more freedom when it comes to the SA-1 chip usage then I'll give it a shot.  This game definitely deserves a nice little expansion of data for people to use.

Edit: Yeah, it's basically impossible to work with Geiger's on this game.

$C3:31D6 is the actual location but it reads it as $C3:B1D6.  But if you try putting the main address as $C3:B1D6, it'll load a whoooooole different section of the ROM.  I wonder how the hell anyone was able to even do any ASM changes on this if they used Geiger's.  It's really screwed up.

Edit: Interestingly enough... I put a string of random ASCII letters after the expanded ROM and Geiger's can view it... but there's no address on the side.  FF:8000 is what I set for the main bit and FF:FFFF as the end, but it actually reads beyond that.  I just can't figure out a way to make it read those new areas quite yet until I can figure out the bank switching stuff.


Edit 2: Got it... kind of!  I wrote a bunch of ASCII text saying 'TAKING A TEST DRIVE OF TEXT HERE' into at 40:8000 in ROM.  I then wrote a quick test code and stored 01 to $2222 and set my main address to BF:8000.  When i load that and scroll, it shows the text is at C1:8000.  But if I set C1:8000 as the main address.. it loads from somewhere else.  I'm confused on what's going on..

[Revenant]

From what I remember from using it, the memory view in Geiger's doesn't really handle banks $C0 and up correctly (if at all) for LoROM games (which SMRPG is), so I probably wouldn't completely trust it to tell you whether or not you're doing stuff correctly with the SA-1.

Anyway, if you write some test data at offset $400000 (i.e. right past the end of the normal ROM), try writing $84 to $2222 ($400000 >> 20 == 4, and set the high bit to enable bank selection for banks 80-9F). You should see it from the CPU at both $808000 and $E00000 after that (and so on).

I'll post up a current build of my debugger in a bit, but I'm going out for now and I don't think I have one available at the moment.

edit: I should mention (since I forgot about this earlier) that writing to $2220-2223 always selects banks at $C00000 and up whether or not the high bit is set, so writing $04 instead of $84 in the above example will still map that part of your expanded ROM to $E00000, but not $808000; this may be better depending on what the original game code needs to be able to access at the same time.

[justin3009]

Oh, so THAT'S how that works!  Okay, got that now.  Just tested it and it does work that way!  I set the value back to what it normally was at $2222 after the test and no issues came up.  So if all goes well, then the code would have to be accessed via bank swap only when it's needed then set back to normal once it's all complete.  This 'should' allow extra anything if it is used correctly.  Specifically setting it mapped to banks $E0:0000+ is definitely a great limiter there as well and will cause a hell of a lot less issues.

Thank you so much for this!  I'll have to give this more of a whirl once I finish up some issues in Mega Man X3.

[FuSoYa]

Just remember there's a few things to watch out for with the SA-1 and current emulators if you're going to play with bank switching:

Snes9x 1.53 and lower ignores the high bit of the MMC registers ($2220-$2223)... it just pretends the bit is always on.  This means $00-$3F:8000-FFFF, $80-$BF:8000-FFFF will always be mapped to the same area of the ROM as $C0-$FF:0000-FFFF.  It doesn't really stop you from accessing all 8MB, but it does mean you can't do something nifty like having all 8MB mapped in at once (which is normally possible by setting the 4 MMC registers to 4,5,6,7).  I believe it's been fixed for the next version of Snes9x, whenever it comes out.

In ZSNES, the first 128KB past the 4MB mark of the ROM is being used internally by the emulator as the SA-1's RAM (and possibly some bits right at the 5MB mark if the game uses character conversion DMA, can't remember the specifics on it).  But as long as you don't bother using those areas of the ROM, you can expand up to 6MB.


Both issues were corrected in my 8MB builds of those emulators a couple years ago.

[justin3009]

Yep yep which are my main emulators I test them on DUE to those being fixed. I'd update SNES9X but there's no debugger beyond 1.52 so I'd just have to work around the problems.

As long as even part of the data can be accessed it makes it plausible to do what's needed, so that's darn good in itself.