SRAM Expansion Patch (32Kb)

[madsiur]

SRAM Expansion
by madsiur
version 2.0
released on 06/25/2024
apply to a headerless FF3us 1.0 ROM
FF6 hacking wiki entry
Personal website entry
RHDN entry
Download


Description

This hack expands SRAM by $1600 bytes, allowing now $2000 bytes for each save slot plus a third 8Kb for general purpose. In original game, only 8Kb of SRAM is used ($306000-$307FFF), each slot occupying $0A00 bytes and $200 bytes for general purpose at the end of the 8Kb block.

With this hack, $306000-$307FFF is used for slot 1, $316000-$317FFF for slot 2 and $326000-$327FFF for slot 3. $336000-$337FFF is used for game SRAM as well. When you play the game, $7E1600-$7E1FFF is still used and copied to  correct slot at saving. $336000-$3375FF is copied to correct slot as extra SRAM. At game loading, correct slot is loaded into $336000-$3375FF.  So in order to save or load from extra SRAM in your hack, use for example STA $336000,X or LDA $336000,X.

Since $337600-$337EFF is not used, it means it could be used as scratchpad RAM for temporary things or have a general use common to the three slots.

SRAM could be expanded more but I figured a whole $2000 bytes instead of $0A00 is enough expansion for any hack. In HiROM mapping banks $20-$3F can be used  to map SRAM, using always the $6000-$7FFF range of the bank. $C0FFD8 tell the emulator the SRAM size of the ROM.

I have not tested this on sd2snes, Everdrive or real hardware. snes9x 1.55 and bsnes+ were used for testing. If you plan to use this hack and make a cart of your hack after, I have no idea what kind of cartridge you will need or if 32Kb of SRAM is supported by any existing SNES game.

New SRAM map

Code:

Slot 1 expansion:  $306A00-$307FFF
                  $306000-$3069FF = $7E1600-$7E1FFF

Slot 2 expansion:  $316A00-$317FFF
                  $316000-$3169FF = $7E1600-$7E1FFF

Slot 3 expansion:  $326A00-$327FFF
                  $326000-$3269FF = $7E1600-$7E1FFF

Other SRAM values: $336000-$3375FF (game common SRAM)
                  $337600-$337EFF (unused)
                  $337F00 = last altered savefile
                  $337F01 = rng index
                  $337F08 = checksum value #$E41B (slot 1)
                  $337F0A = checksum value #$E41B (slot 2)
                  $337F0C = checksum value #$E41B (slot 3)
                  $337F0E = checksum value #$E41B (slot 4)

[madsiur]

I commented out one line in the code and updated the patch. I had some minor problems at RAM initialization because because init would be done too late and data would get erased if you had use $336000-$3375FF prior to this.

Code:

//=======================================
// SRAM init
//=======================================
scope lbl_sram_init_sram: {
    rep #$20
    tdc
    tax
init_sram:
    sta $306000,x                       // slot 1
    sta $316000,x                       // slot 2
    sta $326000,x                       // slot 3
    // sta $336000,x                    // you want this line commented likely
                                        // because if you use this RAM for things
                                        // done at game loading, init is done too late
                                        // and data get erased..
    inx
    inx
    cpx #$2000
    bne init_sram
    sep #$20
    rtl
}

[J92R]

Pretty sure I could find a good use for this, thank you.

[Imzogelmo]

Offhand, a bestiary comes to mind. Also another project of mine which is in indefinite limbo but could be revived.
One question: I have read somewhere that this space reads/writes slower than the onboard RAM in 7E/7F. Is that true, and would it much matter?

[madsiur]

I have read somewhere that this space reads/writes slower than the onboard RAM in 7E/7F. Is that true, and would it much matter?

I've never read this but I have not looked for this info either. Where did you read this? I guess it wouldn't change anything if you don't read write often per frame to it, depending of the use some tests would be needed. BTW, FF6-G a japanese hack use the same method, and it is used in various places.

[Imzogelmo]

I'm not sure where I read it but for my purposes the speed probably wouldn't matter so I never looked into it. I was mostly curious if emulators replicated the alleged speed difference.

[madsiur]

I was mostly curious if emulators replicated the alleged speed difference.

It's the kind of thing I would expect from bsnes and higan. Anything using the snes9x core maybe doesn't.

[madsiur]

This patch just got a 2.0 treatment for the following reasons, download from original post:

1) Hack breaking bug where on save slot loading, extra SRAM would not be copied to $336000 (for slots 1 and 2).
2) Saving/loading code optimization that saves about half of the previous free space used.

I can now say with 100% confidence this hack is working, since I have tested it on one of my WIP projects that needed SRAM expansion.

[Warrax]

In the readme file you mention that you didn't test v2.0 on SD2SNES, Everdrive or real hardware so I decided to test it on my Super Everdrive V2 on a real SNES and when I save, it saves on all 3 slots which doesn't happen on emulators. I also have a SD2SNES, I will test on that one later.

Edit: Just tested with my SD2SNES on real hardware and it works perfectly so far on both original 1.0 rom and my hack based on v1.1, nice.
So I suppose my old Super Everdrive v2 can't handle 32kb SRAM. I did some more testing on it and found some weird behaviors like the cursor next to New Game on the loading screen when there's a savegame already and all slots being empty when I save but not when I load.