Thread: Research: FireRed Pokédex Hacking
View Single Post
Old April 30th, 2011 (7:16 AM).
Full Metal's Avatar
Full Metal Full Metal is offline
C(++) Developer.
Join Date: Jan 2008
Location: In my mind.
Age: 21
Gender: Male
Nature: Timid
Posts: 805
Send a message via Windows Live Messenger to Full Metal
Originally Posted by Jambo51 View Post
Using the following routine, I was able to repoint and extend the seen and caught flags for Pokémon to a free RAM location. The new routine has support for 656 caught flags, and 656 seen flags (as close to 649 as I could get using the 8 bits to a byte system, obviously aiming for the gen 5 total here!). Bear in mind however, that the routine is only limited by how much free space you allocate it. If we were to use a full save block to store caught and seen flags (which is possible using JPAN's save block hack!), we would be limited to a maximum of 10,240 pokémon. This is clearly more than enough XD.

The routine actually simplifies on the original greatly and as such, it's more open to bugs and oddities. Instead of having 3 separate sets of caught and seen flags, I reduced it to 1 longer set, pointed to a different RAM location. The only issue I have with the routine is that the new block of ram is NOT saved when saving the game.

.align 2
.global seencaughtflagsrepoint
 add r3, r0, #0x0
 add r5, r1, #0x0
 lsl r2, r2, #0x18
 sub r0, r3, #0x1
 lsl r0, r0, #0x10
 lsr r3, r0, #0x10
 lsr r4, r0, #0x13
 mov r0, #0x7
 and r3, r0
 mov r0, #0x80
 lsl r0, r0, #0x11
 lsl r0, r3
 lsr r6, r0, #0x18
 mov r0, #0x0
 mov r12, r0
 cmp r5, #0x1
 beq caughtcheck
 cmp r5, #0x2
 beq setseen
 cmp r5, #0x3
 beq setcaught
 cmp r5, #0x0
 beq seencheck
 b end
seencheck: ldr r0, newblock
there: add r0, r0, r4
 ldrb r1, [r0, #0x0]
 and r1, r6
 cmp r1, #0x0
 beq end
 mov r0, #0x1
 mov r12, r0
 b end
caughtcheck: ldr r0, newblock
 add r0, #0x52
 b there
setseen: ldr r1, newblock
there2: add r1, r1, r4
 ldrb r2, [r1, #0x0]
 add r0, r6, #0x0
 orr r0, r2
 strb r0, [r1, #0x0]
 b end
setcaught: ldr r1, newblock
 add r1, #0x52
 b there2
end: mov r0, r12
 pop {r4-r7}
 pop {r1}
 bx r1
newblock: .word 0x0203E400
This routine could theoretically be inserted directly over the original routine as it is smaller than it. If you wish to do so, paste my routine into the rom starting at 0x104AB2. However, it is substantially safer to insert it with a ldr bx combo. Up to you I guess. If you want to use a ldr bx combo, use Register 3.

As you can see, it sets up the new caught/seen flags at 0x0203E400 (seen) and 0x0203E452 (caught). That's 82 (0x52) bytes for each set, which equates to 656 caught and seen flags.

It uses a total of 164 bytes to safely store all the relevant bits. This is (again) actually smaller than what the original rom uses just to store 416 bits worth of flags. However, because all the data isn't concurrent, we can't use that for our new data.

The routine is pretty much self explanatory, and isn't complicated to the point of being unintelligible. This solves our first BIG problem related to the expansion of the Pokédex. Now if I could just get the block to save using jpan's hack, i'd be sorted.
If you been amongs the people looking for doc about how to keep your data
within battery saved memory, you've come to the right place. You'll probably
feel a bit the fool after seing how easy it is done, like i did.

in C, C++ you only need to create a 8bits pointer using an address within :
0x0E000000 and 0x0E00FFFF. This gives you 64K of memory.

In assembly, it's the same thing.

Note that this area can only be readed or writed 8bits at a time, meaning
it's no use trying to write data to it with a 16bits or 32bits pointer, only the
first 8 bits will get written.

For the visual amongs our horde, here's how you would do it in C++ :
#define GAMEPAK_RAM ((u8*)0x0E000000)
u8 *pSaveMemory = GAMEPAK_RAM;

// Save the initial data for the fibonai sequence
pSaveMemory[0] = 1;
pSaveMemory[1] = 1;

for(int i = 2; i < 13; i++)
pSaveMemory[i] = pSaveMemory[i-1] + pSaveMemory[i-2];

Here, we have code that write the first 13 number of the fibonaci sequence,
in the first 13 bytes of the saved ram. Take note that in reality, you shouldn't
use that memory for doing your calculations, only for backuping persistent data,
since it probably has a much more slower access rate.

Found here
Is this useful?

★ full metal.

I like to push it,
and push it,
until my luck is over.
Reply With Quote