View Single Post
  #34    
Old August 25th, 2010 (02:30 PM).
diegoisawesome's Avatar
diegoisawesome diegoisawesome is offline
Please understand
Silver Tier
 
Join Date: Dec 2007
Location: Goldenrod City, Johto
Age: 18
Gender: Male
Nature: Quirky
Posts: 971
Quote originally posted by JPAN:
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:
Code:
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
Code:
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
Code:
Ruby -> 0x081DFE74
Fire Red -> 0x081DF070
Emerald -> 0x082E20AC
JPAN, in Emerald, what variables are safe, then? Anything under 0x5536, or are there other used places?
__________________


My other resources:
My Website
diegoisawesome's MEGA-HUGE XSE Scripting Tutorial
diegoisawesome's Miscellaneous Finds
The Ruins of Alph Puzzles
Diego's Miscellaneous Patches
GBA Intro Manager
Reply With Quote