Lufia & The Fortress of Doom

The following information is pertaining to Estpolis Denki aka エストポリス伝記 aka Lufia & The Fortress of Doom.

SRAM

SRAM Checksum Algorithm

To calculate the checksum for each save slot, you start with the first offset in your save slot, and add up the little endian 16-bit numbers.

So, say for SLOT00, your first 16 bytes looked like this:

46 69 6C 65 30 30 E8 63 01 04 E5 E5 E5 E5 E5 E5

So, your first four bytes: "46 69 6c 65", are the HEX equivalent of the word "File" (if you don't believe me, look up the ASCII character table, and find that hex values 0x41 - 0x5A are upper case characters and hex 0x61 - 0x7A are lower case characters of the alphabet (A-Z and a-z respectively)).

Then, your next two bytes: "30 30", are the HEX equivalent of the printable ASCII characters 00 (the ASCII table defines hex values 0x30 - 0x39 as the textual representations of the characters 0 - 9).

Now we come to the little endian checksum part, which can be complicated, so please bear with me:

Then, the next two bytes are what your checksum is currently calculated as. Since it is a 16 byte value, to get your checksum as a decimal number, you take the first number, "0xE8", and convert it to a decimal -- 232. Now, you take the second number, "0x63", and convert it to a decimal -- 99.

But! Before you can add these two numbers together, you have multiply 99 by 256, since the number that exists there would actually be 0x6300. Anyway, 99 times 256 is 25344. Then you add 232 to that, and you get: 25576. That is your checksum value.

Why did I show you that complicated method? Because, we're dealing with little endian encoding. That means that "0x63" is your high order byte, and "0xE8" is your low order byte. The 16 bit value that is your checksum is not 0xE863, but it is actually 0x63E8. This little tidbit of information becomes important when we start going through the save slot to compute the checksum.

Now, if we were to start computing the checksum for this save slot, we would begin after the checksum bytes with the first "0x01". This is the low order byte, so the decimal equivalent here is 1. Now, we take the high order byte, which is "0x04". Remember, this is just like saying "0x0400" for the purposes of computing a checksum. So, convert the byte to a decimal -- in this case, 4, and then multiply it by 256 -- 1024; before adding back in 1. So, your first value in your checksum is 1025. You will continue in this manner until you reach the end of that save slot.

Except, there is a caveat: what happens when your checksum value goes over 0xFFFF (the biggest 16-bit number, aka. 65535). Well, your counter technically rolls back over to 0, and starts counting up again -- and you just throw away the extra.

So you've added up your save slot and you find out that it still doesn't match the two bytes at the end of "File00"? Well, that's why the assembler code up above was important -- it not only told us how the checksum algorithm works, but it also told us the base value to begin the checksum calculation off of. In this case, it is 6502. You can either start with this value from the onset, or you can add it on as the last step in the process, but regardless, the value this yields will be the two bytes that get stored away as your checksum for this save slot. Then you just have to rinse and repeat this process for the next two save slots! (by the way, 6502 is a decimal value -- not in hex).

$00/9429 A0 FC 03    LDY #$03FC              A:0070 X:616E Y:0000 ; load Y immediate with value 0x03FC
$00/942C A6 1F       LDX $1F    [$00:001F]   A:0070 X:616E Y:03FC ; load X with value at address 0x1F
$00/942E A9 02 65    LDA #$6502              A:0070 X:0000 Y:03FC ; load Accumulator with 0x6502
$00/9431 18          CLC                     A:6502 X:0000 Y:03FC ; clear the carry flag
$00/9432 7D 08 00    ADC $0008,x[$70:0008]   A:6502 X:0000 Y:03FC ; add with carry starting at address 0x0008
$00/9435 E8          INX                     A:4AE7 X:0000 Y:03FC ; increment the X register
$00/9436 E8          INX                     A:4AE7 X:0001 Y:03FC ; increment the X register (again)
$00/9437 88          DEY                     A:4AE7 X:0002 Y:03FC ; decrement the Y register
$00/9438 D0 F7       BNE $F7    [$9431]      A:4AE7 X:0002 Y:03FB ; repeat until Y hits 0 (branch not equal)
$00/943A AA          TAX                     A:592C X:07F8 Y:0000 ; transfer the accumulator into X
$00/943B 7A          PLY                     A:592C X:592C Y:0000 ; pull the Y register off of the stack
$00/943C AB          PLB                     A:592C X:592C Y:0000 ; pulls a byte off of stack into data bank
$00/943D 28          PLP                     A:592C X:592C Y:0000 ; pull processor status off of the stack
$00/943E 60          RTS                     A:592C X:592C Y:0000 ; return from subroutine

Below is a C++ program that accurately handles the checksum algorithm described above:

// File name: main.cpp
// Author: Vegetaman
// Date: February 24, 2011
// Purpose: Lufia Checksum

#include <iostream>
#include <fstream>

#define SIZE_OF_SRAM 0x2000                     // SRAM is 8K large
#define LUFIA_SRAM_FILE "C:\\Lufia.srm"         // SRAM file location
#define HALF_OF_2K 0x03FC                       // half of 2048 - 8
#define FILE00_OFFSET 0x0008                    // 8 bytes in
#define FILE01_OFFSET 0x0808                    // 2K + 8 bytes in
#define FILE02_OFFSET 0x1008                    // 4K + 8 bytes in
#define COUNTER_ROLLOVER_VALUE 0xFFFF           // max 16-bit value

using namespace std;

int main(int argc, char *argv[]){
  FILE *filePtr;                           // file pointer
  unsigned char ArrayOfSRAM[SIZE_OF_SRAM]; // array of char or bytes
  unsigned short accumulator;              // is a 16-bit unsigned integer
  unsigned short register_x;               // will be just like the register X
  unsigned short register_y;               // will be just like the register Y
  filePtr = fopen(LUFIA_SRAM_FILE, "r");   // open file Lufia.srm -- read only

  // NOTE: I am reading the SRAM into an array so I don't have to do all of my
  //       operations from the file, which would be really slow and wasteful...

  fread(ArrayOfSRAM, sizeof(char), SIZE_OF_SRAM, filePtr); // load the array
  fclose(filePtr); // always close your file handle

  // begin the routine of calculating the first 16-bit little endian checksum
  register_x = FILE00_OFFSET; // load the first offset into register X
  register_y = HALF_OF_2K;    // load 0x03FC into register Y
  accumulator = 0x6502;       // load the accumulator with the base value 6502

  while(register_y != 0){     // while Y does not equal 0 (will run 1020 times)
    accumulator += ArrayOfSRAM[register_x];      // get the first/low byte
    register_x++;                                // increment X
    accumulator += ArrayOfSRAM[register_x] << 8; // get the second/high byte
    register_x++;                                // increment X
    accumulator &= 0xFFFF;                       // discarding the carry flag
    register_y--;                                // decrement Y
  }

  // some code to throw the checksum up on the console so that it can be seen
  cout << "Checksum for FILE00: " << dec << accumulator << endl;
  cout << "Little Endian HEX: " << hex << (accumulator & 0xFF) << " ";
  cout << hex << ((accumulator >> 8) & 0xFF) << endl << endl;

  // prepare to calculate the second little endian 16-bit checksum
  register_x = FILE01_OFFSET; // load the first offset into register X
  register_y = HALF_OF_2K;    // load 0x03FC into register Y
  accumulator = 0x6502;       // load the accumulator with the base value 6502

  while(register_y != 0){     // while Y does not equal 0 (will run 1020 times)
    accumulator += ArrayOfSRAM[register_x];      // get the first/low byte
    register_x++;                                // increment X
    accumulator += ArrayOfSRAM[register_x] << 8; // get the second/high byte
    register_x++;                                // increment X
    accumulator &= 0xFFFF;                       // discarding the carry flag
    register_y--;                                // decrement Y
  }

  // some code to throw the checksum up on the console so that it can be seen
  cout << "Checksum for FILE01: " << dec << accumulator << endl;
  cout << "Little Endian HEX: " << hex << (accumulator & 0xFF) << " ";
  cout << hex << ((accumulator >> 8) & 0xFF) << endl << endl;

  // prepare to calculate the third and final little endian 16-bit checksum
  register_x = FILE02_OFFSET; // load the first offset into register X
  register_y = HALF_OF_2K;    // load 0x03FC into register Y
  accumulator = 0x6502;       // load the accumulator with the base value 6502

  while(register_y != 0){     // while Y does not equal 0 (will run 1020 times)
    accumulator += ArrayOfSRAM[register_x];      // get the first/low byte
    register_x++;                                // increment X
    accumulator += ArrayOfSRAM[register_x] << 8; // get the second/high byte
    register_x++;                                // increment X
    accumulator &= 0xFFFF;                       // discarding the carry flag
    register_y--;                                // decrement Y
  }

  // now throw the last checksum up on the console so it can also be seen
  cout << "Checksum for FILE02: " << dec << accumulator << endl;
  cout << "Little Endian HEX: " << hex << (accumulator & 0xFF) << " ";
  cout << hex << ((accumulator >> 8) & 0xFF) << endl << endl;

  // now, hold the program up until the user is done reading...
  cout << "Press ENTER to continue...";  // prompt user
  getchar();                             // wait for "ENTER" key
  return 0;                              // exit with success
}

SRAM Structure

Save slot 0 is at SRAM 0x0000, spot 1 is at 0x0800, spot 2 is at 0x1000 and there is extra space at 0x1800.
On an interesting note though, where the fourth save slot would be, the SRAM file I was working with says "Estpolis Biography Neverland Co.". A perfect 32 bytes starting at SRAM location 0x1800.

Items

You get a maximum of 5 pages of items, with 12 items a page, for a maximum of 60 items. The way the data is stored is that the first byte of the pair identifies what the item is, while the second byte of the pair identifies the quantity of that item that you have.

Note that there is some oddity in this list, such as two items named "Bomb", and at least 5 "Dummy" items, and then there's "Free Door" on top of that.

Not only that, but several of these items, such as "Sheran Key", go into your Scenario page, not your item list. But, I digress -- you can add them in to your SRAM file anyway.

Magic

You have a maximum amount of space for spells of 32 bytes. However, the way that magic works is that the spell listing must end with a call to 0x00 for "END OF LIST". Otherwise, if you use up all 32 slots in Hero's Magic list, he will also have every spell of Lufia's in his spell casting ability as well! And likewise, if you fill up all 32 of Lufia's spells, you can spill over into Jerin's territory. And if you fill up Jerin's... Well, you'll probably crash something, but just beware if you go to edit the game in this manner. Though with this method, you can actually give your Hero EVERY spell in the game when the team consists of only you and Lufia! Also, notice that there is no space reserved for Aguro to have magic, so you cannot just give him some spells to let him cast away.

In case you do not recognize some of the last magic spells on that list, that is because they must have been in there for test purposes. Without going too much off topic, here is what it appears that these extra magic spells do:

• Defake - Agility Down
• Figual - Confuse
• Paraiz - Paralyze
• Elegion - Thunder Spell (all enemies)
• Elegi - Flash Spell (all enemies)
• Elegio - Bolt Spell (all enemies)
• Absobl - Absorb Magic

The plus of some of these spells is that they cost only 1 or no MP at all to cast, meaning you can give them to your low level party and completely rule the entire game -- never mind the great items you could give yourself as well.

Dictionary Reference Key

The dictionary is located at 0x054E19 - 0x0553CC.

Ì, .z .& .îone.. a fake ..?. ..   rich ‡ gemstone.mines. Ì .o ran .‹..` ago.

Can't read some of those characters? Well, that's because the stuff that doesn't make sense has to do with punctuation and pointers to other words that get put in place.

The statement that should be making is this:

But, why would anyone
make a fake ruby?
Medan was rich in gemstone
mines. But they ran out
years ago.

A few words are there that you can make out (between some towns person and the Princess in Medan). Such as ",", "one", "a fake", "?", "rich", "gemstone mines.", "ran", "ago.". But what about the questionable things you can't see. Let's take the first part, the "But, why would anyone make a fake ruby, which looks like this, and compare it against the dictionary file of the game (0x54A50):

cc 2c 20 0c 7a 20 0c 26 20 0c ee 6f 6e 65 05 0c 7f 20 61 20 66 61 6b 65 20 0c 19 3f

Ì, .z .& .îone.. a fake ..?. 

cc    -> refers to an upper case "But"
2c    -> comma (",")
20    -> blank space
0c 7a -> refers to a lower case (0c is "lower case"/0d is "upper case") "why"
20    -> blank space
0c 26 -> refers to a lower case "would"
20    -> blank space
0c ee -> refers to a lower case "any"
6f    -> letter "o"
6e    -> letter "n"
65    -> letter "e"
05    -> line/carriage return
0c 7f -> refers to a lower case "make"
20    -> blank space
61    -> letter "a"
20    -> blank space
66    -> "f"
61    -> "a"
6b    -> "k"
65    -> "e"
20    -> blank space
0c 19 -> refers to a lower case "ruby"
3f    -> "?"

But, why would anyone
make a fake ruby?

After that, there is a "04 A0" code which I can only assume is some sort of "close textbox" and "open new text box" (and possibly a character sprite/on screen location to hook it to). But then we get to the second phrase:

0b 08 20 a0 20 72 69 63 68 20 87 20 67 65 6d 73 74 6f 6e 65 05 6d 69 6e 65 73 2e 20 cc 20 0c 6f 20 72 61 6e 20 0c 8b 05 0c 60 20 61 67 6f 2e

..   rich ‡ gemstone.mines. Ì .o ran .‹..` ago.

0b 08                   -> dictionary for the town name "Medan"
20                      -> blank space
a0                      -> lower case "was" (notice it is not referenced by any 0c/0d type calls)
20                      -> blank space
72                      -> "r"
69                      -> "i"
63                      -> "c"
68                      -> "h"
20                      -> blank space
87                      -> lower case "in"
20                      -> blank space
67 65 6d 73 74 6f 6e 65 -> letters for "gemstone"
05                      -> carriage/line return
6d 69 6e 65 73          -> letters for "mines"
2e                      -> "."
20                      -> blank space
cc                      -> upper case "But" (as 8c refers to lower case)
20                      -> blank space
0c 6f                   -> lower case "they"
20                      -> blank space
72 61 6e                -> letters for "ran"
20                      -> blank space
0c 8b                   -> lower case "out"
05                      -> carriage/line return
0c 60                   -> lower case "years"
20                      -> blank space
61 67 6f                -> letters for "ago"
2e                      -> "."

Medan was rich in gemstone
mines. But they ran out
years ago.

Then there's more words after that, because she's long winded, but you get the idea... It took me almost 8 hours of trial and error to figure out how the dictionary words were stored, as well as what numbers called them (which I figured out by comparing the dictionary against known phrases). The upper case/lower case was a bit harder to figure out as well. There's still some extra data that doesn't make sense yet. Also, there's a lot of words that are in the dictionary but they don't both to make a call to use them (like "one" in the above example"). There must be a reason for this, but I have yet to figure it out.

Some things are a little more hidden, such as a character is referenced by "07 0X" with Hero being "07 00" up to Gades as "07 0b". Also, while to get lowercase/uppercase for the one set of dictionary words it seems to be dependent on the "0c" vs. "0d" call, the other section of dictionary words has two memory addresses that are separate for lower case or upper case (though the dictionary only exists once, it just loops back on itself I guess). For example, in the non-0c/0d dictionary, the word "there" is referenced by "8e", while "There" is referenced by "ce". Meaning they're exactly 0x40 difference.

Now, for the dictionaries themselves, the character names start around "0xe800", the town names around "0xe850", there's one of 16 words (such as ('s) and ("Welcome")). These start at "0x54a50". Then the next dictionary (the one that has double calls to it, for being lower case/upper case) starts at "0x54ac0" (it contains 80 items, which makes for 160 words between upper/lower case). Then the main dictionary (called by 0c/0d for lower/upper case) starts near "0x54c10". Now, there's two types of dictionary calls here.

Early on names:

0xe850:    8f e8 95 e8 9b e8

8f e8 refers to memory location "0xe88f", which contains the name "Alekia"
95 e8 refers to memory location "0xe895", which contains the name "Chatam" 
9b e8 refers to memory location "0xe89b", which contains the name "Sheran"

These places are called by text boxes by "0b xx", where "0b 01" is Alekia, "0b 02" is Chatam, "0b 03" is Sheran and so on (there's an extra space '.' in this list which makes the names start at 1 instead of 0).

Later on words:

0x54ac0:    42 cb 45 cb 48 cb

Here we have a bit of a problem, as memory location "0xcb42" is way back in the program and nowhere near what we want. So all of these later dictionary entries need to have the hex value "0x48000" added to them so that they point to the proper place. The unique item grabber program I made for Diablo I uses a pointer offset like this too, so it is not all that uncommon for larger programs, especially later on in the data when dealing with 16 bit little endian pointers.

42 cb + 48000H = "0x54b42" which contains the word "the"
45 cb + 48000H = "0x54b45" which contains the word "you"
48 cb + 48000H = "0x54b48" which contains the word "to"

In case you didn't notice, the pointer to the next word tells you where to stop. At least, that's my guess...

Important Codes

Offset: 048000 (hex)

"0c" -> lc
"0d" -> uc

SRAM details algorithm description, C++ checksum program and text dictionary compression by Vegetaman. SRAM Checksum traced and described by KingMike.