Secret of Evermore SRAM Format

This is a guide to the Secret of Evermore SRAM, the section of memory in the Secret of Evermore cartridge used to save your progress.

SRAM Basics

Secret of Evermore, like most SNES games, used an SRAM of 0x2000 (8 KB) bytes to store its information. Up to four games could be save. Each game used 0x331 bytes of SRAM. This means 0xCC4 bytes of SRAM are reserved for the game data, with 0x133C bytes used for other things (some unused). In this document, we are only interested in the 0xCC4 bytes of save game data.

Not all of the information contained in the save game data is known. Most of what is undocumented is related to quest progress and opened or already found treasure. The only major items of interest that I've yet to find are the save location, and the rare quest items.

Here is a short listing of what is known in no particular order. The sanity (aka checksum) data, the known alchemys and their levels, the boy's and dog's stats (name, experience, level, HP, and MP), the money (talons, jewels, gold coins, and credits), and the inventory (alchemy ingredients, items, armors, weapons, helmets, gauntlets, collars, trade goods, and charms).

The first game starts at 0x2 in the SRAM, and after its 0x331 bytes, the second game starts and so on for the four games.

SRAM Offsets

This information is presented in no particular order. Similar information will be grouped together.

When an offset is listed, this offset is relative to the start of the game data. For example, if I said the boy's name is at offset 0x26, this would be 0x28 (0x2 + 0x26) from the start of SRAM for game 1, and 0x359 (0x2 + 0x331 + 0x26), and so on.

Data in the SRAM is stored in little endian format, the format used by the SNES processor. This means words are stored with their least significant byte first. For instance, 400 is 0x190 in hex, which is two bytes 0x01 and 0x90. In little endian, this would be 0x9001 [90 01]. Mostly, this just means reverse the bytes. There are plenty of endian guides on the web if you need a more in-depth explanation.

Names

The boy and dog's names have storage space for 34 characters (null terminated). However the game limits you to 15 character names. Using longer names is untested.

The name is ASCII encoded, and names can consist of the entire alphabet (upper and lowercase), the numbers 0-9, and the characters , (comma), . (period), ! (exclamation point), ' (apostrophe), \ (backslash), - (hyphen), & (ampersand), # (pound), and (space). This is the alphabet the game limits you to using. Using characters outside this alphabet is untested.

The German and Spanish versions have slightly different alphabets for the names. In the Spanish version, # is replaced by the ñ. It is encoded in the name with the value 0xD7, not the unicode value 0x00F1.

In the German version, the numbers 0, and 4-9 are replaced by the capital and lower case vowels with umlauts and the eszett ß character. Their values are encoded as follows:

The byte immediately after the character's name must be the null terminator (00). If there is no terminator, the game will crash on load.

Levels

The valid range for levels are 1-99.

Health Points

The valid range for HP is 0-999, though the max should probably be at least 1.

Experience

The valid range for experience is 0-7562471. The high value is the dog's level 99 experience. Anything more than that is pointless.

Money Types

The next offsets are for the money types in the game. Their valid range is 0-16,777,215. The high value is the max value for an unsigned 24-bit number.

Weapon Inventory

The next offsets are for the weapon inventory. There is a single bit for each weapon. The first value is the offset in the SRAM, and the second is the bit that controls it. A set bit (1) means you have the weapon, and a clear bit means you do not have it.

Bit number start at 0 and go through 7 and run right to left. For example, in the byte with bit pattern 10010010, bit 0 is clear and bit 7 is set.

Weapon Levels

The next set of offsets are for the weapon levels. The first offset is for the major level (1-3), and the second is for the minor (power up progression).

The minor level ranges from 0-255. The status screen only shows values from 0-99. To convert between the actual value and the shown value, just divide the minor level by 2.56 and ignore the decimal places.

Alchemy Ingredients

The next set of offsets are for the alchemy ingredients. Their valid range is from 0-99.

Alchemy Inventory

The next offsets are for the alchemy inventory. Just like the weapon inventory, the first value is the offset and the second is the bit that controls it. A set bit means you know the alchemy, and a clear bit means you don't.

Alchemy Levels

The next set of offsets are for the alchemy levels. The first offset is their major level (0-9), and the second is their minor level (power-up progress). The minor level can range from 0-99. For some reason, both of these offsets are 2 bytes, but since the values never exceed 255, you can just ignore their second byte and treat them like a single byte value.

Inventory Items

The next offsets are for the inventory items, which include the common items, equipment, and trade goods. In other words, anything that can be bought, sold, or traded.

Most items have a valid range of 0-6, but a few can be up to 99. These include call beads, bazooka ammunition, and all the trade goods.

Charms

The final offsets are for the charms. They are just like the weapon and alchemy inventories. The first value is the offset, and the second is the controlling bit.

Unknown

The remaining values in the SRAM are unknown. Please update this guide if there you figure them out.

The Sanity Algorithm

As described earlier, Secret of Evermore uses two bytes of sanity data to ensure the SRAM is still being saved by the battery. This section describes that algorithm.

The following is the actual algorithm in the US version, obtained using Geiger's Snes9x debugger. I have commented each line.

$8D/B469 A0 2F 03    LDY #$032F             ; load 0x32F into counter
$8D/B46C 22 78 B4 8D JSL $8DB478[$8D:B478]  ; jump to subroutine

$8D/B478 A9 3F 04    LDA #$043F             ; a = 0x43F
$8D/B47B E2 20       SEP #$20               ; use 8-bit accumulator
$8D/B47D 18          CLC                    ; clear carry
$8D/B47E 7D 00 00    ADC $0000,x[$30:6666]  ; add data[offset]

$8D/B481 88          DEY                    ; y = y - 1
$8D/B482 F0 0B       BEQ $0B    [$B48F]     ; branch if y = 0
$8D/B484 E8          INX                    ; x = x + 1
$8D/B485 C2 20       REP #$20               ; use 16-bit accumulator
$8D/B487 0A          ASL A                  ; shift left
$8D/B488 E2 20       SEP #$20               ; use 8-bit accumulator
$8D/B48A 7D 00 00    ADC $0000,x[$30:6667]  ; add data[offset]
$8D/B48D 80 F2       BRA $F2    [$B481]     ; branch always

$8D/B48F C2 20       REP #$20               ; use 16-bit accumulator
$8D/B491 6B          RTL                    ; return from subroutine

The algorithm is fairly straightforward. First, we take an accumulator and initialize it with 0x043F. The first byte of game data is added to the lower byte of our accumulator. If a carry results, we ignore it.

Next we start a loop. We shift the accumulator left by 1. The shifted bit is placed in the carry. Then we add the next byte of data to the lower byte of our accumulator. The carry is also added here and reset to 0. If our addition results in a carry, it will be placed in the carry. This process is repeated for every byte of game data. Note that the carry from our addition will be ignored due to the shift that always occurs following the next iteration of the loop.

In the European versions, the algorithm is only slightly different. Change the initial value 0x43F to 0x16FF. This is the only difference.

Here is the C++ routine from soesrame I wrote (based on C source from phonymike).

    quint16 SRAMFile::checksum(int game) const {
    	quint32 checksum = 0x43F;
    	unsigned char temp = checksum + sram[SRAM_GAME_OFFSET + 2 + game * SRAM_GAME_SIZE];
    	for(int i = 3; i < SRAM_GAME_SIZE; ++i){
    		checksum &= 0xFF00;
    		checksum |= temp;
    		checksum <<= 1;
    		if(checksum > 0xFFFF){
    			checksum -= 0xFFFF;
    		}
    		temp = checksum + sram[SRAM_GAME_OFFSET + i + game * SRAM_GAME_SIZE];
    	}
    	return static_cast<quint16>(checksum);
    }

To clear up any confusion, a quint16 is a 16-bit unsigned integer and a quint32 is an unsigned 32-bit integer. These are types defined by the Qt library which is used by soesrame.

When you edit the SRAM by hand, the checksum will be wrong. To get around this, you can either fix the checksum, or have the game skip the sanity check. The latter can be accomplished by using a game gene code. DDA4-17E1 will do this. If you try to skip the sanity check with a game genie code, and have invalid game data in any of the four slots, the game is quite likely to crash.

You can get the code for a C program which will fix the sanity data for an SRAM file, as well as a Windows & Mac OS X binary here: soe-sanity.7z. For other platforms, you will need to compile it yourself. It is written in standard ANSI C, so it should run anywhere.

If you are compiling on a big endian platform, you will need to define BYTE_ORDER_BIGENDIAN at compile time. PowerPC and Sparc machines are probably the most common big endian platforms. Intel machines (x86) are little endian.

gcc -o soe-sanity soe-sanity.c

Will build the program using gcc on a little endian platform.

gcc -DBYTE_ORDER_BIGENDIAN -o soe-sanity soe-sanity.c

Will build the program using gcc on a big endian machine. I don't have much experience with compilers other than gcc, so you'll have to figure it out yourself if you're using something else.

The program has a simple interface. Specify the sram filename, the game that needs fixing, and the version of the game (us or europe). It defaults to game 1 and the US version.

Examples:
  soe-sanity "Secret of Evermore (U).srm"
  soe-sanity "Secret of Evermore (G).srm" --game 2 --version europe

The first one fixes the checksum for the first game using the US algorithm. The second one fixes the checksum for the second game using the European algorithm.

soesrame - Secret of Evermore SRAM Editor

For those that don't want to play around with the SRAM directly, I have written a program that edits all the values documented here. It's also nice in that it keeps the values within their valid ranges, and handles the sanity data for you.

You can find it at http://games.technoplaza.net/soesrame/. There are binaries for Windows, Mac OS X, and Linux. It should work on any platform that supports Qt, so it should work on any unice with X Windows. The full source is available as well.

Credits & Acknowledgements

I want to thank phonymike for discovering and documenting the checksum algorithm used by Secret of Evermore. He was also very helpful in answering questions I had about his code.

Thanks to Geiger for his debugging Snes9x version and the entire Snes9x team for Snes9x. Without it, it would have been very difficult to find the SRAM offsets.

Written by John David Ratliff (webmaster at technoplaza dot net / http://www.technoplaza.net/feedback.php)

The most recent version of this guide can always be found at http://games.technoplaza.net/soesrame/sram-doc.txt

Copyright (C) 2006-2008 emuWorks (http://games.technoplaza.net/)

This document is Copyright (C) 2006 emuWorks (http://games.technoplaza.net/). Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license can be found at http://www.gnu.org/licenses/fdl.html

Basically, it is free documentation in much the same way software under the GNU General Public License is free software. You can modify it, redistribute it, sell it, publish it, etc.