SRAM Expansion Patch (32Kb)

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)

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
}

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

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?

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.

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.

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.

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.

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.