View Single Post
Old August 25th, 2010 (2:17 PM).
JPAN JPAN is offline
pokemon rom researcher
    Join Date: Dec 2008
    Posts: 104
    Originally Posted by Chaos Rush View Post
    I really hope that's just FR/LG... because I'm generally using variables from 0x5000 to 0x7FFF in my hack.
    I've searched the other ROM versions for it, and I have bad news:
    In Emerald, from 0x5536 forward affect the Boxes, and at Ruby, although not directly problematic, from 0x55a0 the variables aren't saved, and from 0x415c, you start overwriting names, sayings and Overworld data.
    This fact has made me think, how can we get usable, permanent variables? So, I've studied the FlashRom write routines, and found something interesting, and since I was on a multi-ROM streak, I confirmed it for Ruby, Fire Red and Emerald.

    The Pokemon games, as we know, use a 128K Flash ROM, that can be accessed by using the correct key at the 0x0e00xxxx addresses. A 128kB Flash has a total of 0x20000 possible addresses, so it uses a Bank system to allow access to the full memory. More details can be find at this useful document here.

    The save File is always written in 4kB blocks (0x1000 addresses), so the pokemon Game considers a Block to be a set of 0x1000 bytes of information. Those blocks always have the same configuration:
    0x0 - 0xf80 -> Data to store. (maximum spotted, can be less)
    0xff4 -> Block number
    0xff6 -> Checksum, calculated by adding all words in the copyed memory, then adding both Upper and lower halfword toguether.
    0xff8 -> Seems like a pointer, but needs further investigation
    0xffc -> a byte that seems to indicate how many saves since last load.

    The Games seem to use a round-Robin list to change the location of the Save data at each save, most likely to avoid chip degradation and unfortunate hacking attempts. Emerald and Fire Red have two lists (ruby is not confirmed), that have this Saving pattern:
    00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
    0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b
    The game has a complex pattern of choosing the start. I'll leave you with examples:
    07 08 09 0a 0b 0c 0d 00 01 02 03 04 05 06
    16 17 18 19 1a 1b 0e 0f 10 11 12 13 14 15
    09 0a 0b 0c 0d 00 01 02 03 04 05 06 07 08
    18 19 1a 1b 0e 0f 10 11 12 13 14 15 16 17
    0b 0c 0d 00 01 02 03 04 05 06 07 08 09 0a
    1a 1b 0e 0f 10 11 12 13 14 15 16 17 18 19
    The only data saved on these blocks are the data that in Fire Red and Emerald are located in the Dynamic pointers at 0x3005008, 0x300500c and 0x3005010.

    The Fire Red Table is as follows
    0x0 - Personal Data (at 0x300500c) Size: 0xf24
    0x1 to 0x4 - Map Data (at 0x03005008) Size: 0xf80*3 + 0xee8 = 0x3d68
    0x5 to 0xd - Box Data (at 0x03005010) Size: 0xf80*8 + 0x7d0 = 0x83d0
    Both Ruby and Emerald have similar tables, although the sizes of the ending packets may vary between ROMs. Layout is always this one.

    Now, why does this matter? Well, if you notice the lists presented, you can see that blocks 1c, 1d, 1e and 1f are not used, and that is true.
    So, if anyone wants, we can use this area to save and load our own pieces of data, just like the game.
    That can be used to increase the number of seen-caught pokemon, get some real empty Variables we can use, and even save our own data structures that we need to fit in pre-used variables to use.

    As a complementary note, I will now post the location of the "Save block" Routine in the three mainly used US versions
    Ruby -> 0x081DFE74
    Fire Red -> 0x081DF070
    Emerald -> 0x082E20AC
    Here are the links for my work

    Currently working on:
    Battle Script Documentation
    Another large project
    Reply With Quote