Research: FireRed Pokédex Hacking

[Jambo51]

OK, this is an area that we seem to have very little knowledge in. No FireRed hacks have regional pokédexes (that i'm aware of), and almost all hacks get around the evolution problem (national dex pokémon not evolving without the national dex) simply by awarding the national dex at the start of the game. While this is alright, and it works, it doesn't look very professional.

We also (understandably, due to the large number of limiting bytes/words (trust me, it's both as i've done some research into it)) haven't ever really put any concerted effort into extending the pokédex.
What i'm proposing is that a few of us work together to actually work out how plausible it is, or indeed even if it is plausible.

I can also post some of my research into the Pokédex, but please note it's still fairly limited. All of the information below is for FireRed.

Kanto Dex Limiting Bytes:

Spoiler:

(Bear in mind that it loops the compare + 1 times, as it also loops on 0)
0x10352C - mov r1, #0x97
0x1035F6 - cmp r0, #0x96

Evolutions work without National Dex:

Spoiler:

At 0xCE91A change the next 4 bytes to 00 00 14 E0. This makes the previously conditional branch into an unconditional branch, which fixes the evolutions.

Seen/Caught Flags:

Spoiler:

There are 3 (yes, 3) sets of seen flags. I don't know why this is, but this would surely be a problem for any extension hack, as these would all need repointed to support more pokémon. These are all DMA protected, so it's impossible to give exact locations, but I do know how the game gets them, so i'll post that.

In all 3 cases, the game reads the ram location 0x0300500C for a base location, adds a specific amount to that base location, then adds the appropriate number of bytes to that to find the actual flag, the finally runs a flag decryption, but does not use the known flag decrypter at 0x6E6D0.

For the caught checks, the game runs the same routine, but passes it a different index. This makes the game check the caught flag instead of the seen flag. There are only 1 set of caught flags that i'm aware of. Again, they're DMA protected.

In any case, the routine which handles this, as well as the actual caught check, is at 0x104AB0.

These are the ones i've figured out so far:
R0 = Pokémon Species in in game index numbering.
R1 = Check Seen = 0, Check Caught = 1, Set Seen = 2, Set Caught = 3

Pokédex Information Page:

Spoiler:

This is the page which opens up when you select a Pokémon's name on the Pokédex, and shows pertinent information to that Pokémon's species.

The routine again checks the caught flag (you can't select a species name if you've not seen it, of course), and then proceed to load the information from the Pokédex information table. This is an interesting routine, in that it reads from a static ram location (the Pokédex's ram location after writing etc, is actually static). It reads which NUMBER you've pressed on, and then loads the Pokédex slot from the ram location which matches that slot. In other words, there are a set of converting (National -> Regional) routines used here which are largely (if not completely) useless.

Anyway, since the information loaded is already in National Dex numbering, it loads the data in order from the Information table, which starts at 0x44E850, including Missingno's slot 0. All the data except the species name (Pidgey, Rattata etc, not Tiny Bird, Mouse etc), sprite and cry is loaded using this routine. This routine is at 0x1058C4. The exceptions named above are just written directly from the original Pokédex data.

Known Locations related to this:
0x44E850 - Pokédex Information Table - 0x24 Bytes per entry, with 412 (386 + 25 + 1) entries.
0x02003400 - Pokédex Ram Location - 0x8 bytes per entry, with 386 entries (expandable in theory). Stores a pointer to the species name (if seen, else stores the pointer to the blank entry), the Pokémon species ID (H-Word), and the seen/caught status (H-Word).
0x020033B0 - Current Pokédex Page - Only used like this if on a species page. Copies the second word of the actual pokédex ram to here.
0x020033B4 - Current Pokédex Slot. Don't know an awful lot more than this.
0x020033C2 - Byte representing which mode the Pokédex is in. 0x0 = Regional, 0x5 = National.
0x020033C8 - H-Word - limit of the Pokédex.
0x020033CA - 3 bytes which change on changing page on the information screens. They change to 0xFF's when changing, then change to 0x2, 0x3 and 0x4 when on a page.
0x020033DA - H-Word - Species ID for cry to play.
0x020033E2 - H-Word - Offset from top of Pokédex. How many scrolls down you are from top of Pokédex. Hard to explain.

Main Pokédex Page (Listing):

Spoiler:

This is where most of the grunt work of the Pokédex is executed. The main routine starts at 0x103518. It checks what dex mode you're in, and loads the appropriate routine from a table, then mov PC, R0. It loads the Pokédex order from a table at 0x251FEE.

The rom then proceeds to check the caught/seen status of the first unchecked Pokémon in the dex, starting with Bulbasaur. If seen, it adds [Pokémon Species ID]*10 to the names array (0x08245EE0), and then stores the pointer at 0x02003400 + [Check Number*8]. It then writes the species ID as a halfword to 0x02003404 + [Check Number]*8. Then it finally writes the status of that slot's check into the following halfword.

Then it repeats until the check number becomes equal to the number of checks to be run. For the Kanto (Regional) Dex, that number is 0x96. For the National Dex, it's 0x181. We already have 411 Pokémon in the game (technically), so a good place to start would be getting the rom to show those extra 25 Pokémon on the dex.

The game limits the length the dex to the last SEEN pokémon by copying the ID of the current Pokémon being checked, IF it has been seen, to R10.

649 Patch Alpha 2 Available Here: https://www.pokecommunity.com/posts/6932134/

 

[knizz]

0300500C is pointing to the second of three savegame blocks that change position to avoid overusing certain parts of the memory. The data in it is tightly packed.

08104AB0 uses 08104AFE or 08104B14 depending on whether R1 is 0 or 1.

R1=0 loc_08104AFE:
LDR     R0, =saveblock2
LDR     R0, [R0]
ADDS    R0, #0x5C @ Start of second flagdata
ADDS    R0, R0, R4 @ R4 contains flag-nr (=pokemon-nr minus 1) divided by 8
LDRB    R1, [R0]
ANDS    R1, R6 @ R6 has only one of the first 8 bits set
CMP     R1, #0
BEQ     loc_08104BB0

R1=1 loc_08104B14:
LDR     R0, =saveblock2
LDR     R2, [R0]
MOVS    R0, R2
ADDS    R0, #0x28 @ Start of first flagdata
ADDS    R0, R0, R4 @ R4 like above
LDRB    R1, [R0]
ANDS    R1, R6 @ R6 like above
CMP     R1, #0
BEQ     loc_08104BB0

Because the first data starts at 0x28 and ends at 0x5C you only have enough place for (0x5C-0x28)*8 pokemon. (=416) Unless you know how to repoint in savegames you have these size constraints.

 

[Jambo51]

Because the first data starts at 0x28 and ends at 0x5C you only have enough place for (0x5C-0x28)*8 pokemon. (=416) Unless you know how to repoint in savegames you have these size constraints.

Thanks for letting me know that. I guess I shall have to learn how to repoint data in the save game. But nonetheless, I'm going to make an effort to get the Pokédex to use those 416 slots for now!

 

[Full Metal]

Yahoo~!
:>
Thanks for posting. As soon as I quit fideting with phoenix I'll get to work on using this. :)

 

[colcolstyles]

I'm not a Fire Red hacker but, for what it's worth, I did a little research on the "habitat" data of pokémon. You can read about it here.

 

[Full Metal]

^ that would be a good tool to make.
Sounds long and tedious.

 

[Jambo51]

@colcolstyles
Fantastic, every little helps as they say! It's something that would've needed researching, and you've saved us having to do so, so thanks!

@fullmetal
I wish it was easy, lol. I really need someone to do the "boring" side of the hack. I need someone to get the 4th gen cries working, as well as inputting all the relevant pokémon stats, so that they're ready to input if I get it working. If you can't do ASM research (I don't know if you can, so don't want to assume.) that'd be a helpful place to start. If you CAN do ASM research, every extra eye looking over the process helps us to catch all the limiters, and means less mistakes!

@knizz
I don't suppose you know how to repoint stuff in savegames? It's something i've never had to do before, but in theory, couldn't I make use of JPAN's extra save block hack? It'd give us plenty of free memory to make this hack work if we could use it!

 

[Full Metal]

There are 3 (yes, 3) sets of seen flags. I don't know why this is

maybe it has to do with the three regions? :)
EG In FR/LG I'm fairly certain there aren't any Hoenn pokemon available, although there are Jhotto pokemon... :)

 

[Full Metal]

Thank you for unnecessary and unwanted clarification that provides no help whatsoever.
ANYWAYS...
So, in theory we have the ability to expand up to 416 pokemon in the pokedex...wait...we already have that...we should probably look at the bugs in loading entries for those 25 unknown pokemon?

 

[Full Metal]

By 'expand' you mean, add more pokemon to the hoenn dex, not the pokedex itself. ( eg bulbasaur added to the hoenn dex. ) ?
I think there's been a thread on that somewhere...maybe. :|

 

[Jambo51]

Did some more research, and have concluded that it's gonna be REALLY complicated to pull off. We need to repoint the 3 sets of seen flags, as well as the caught flags because we're not able to use extra space as it's used by existing game processes. We also need to repoint the actual static ram pokédex as when expanded it's too long to actually store in its existing location. This oughta be loads of fun.

 

[Full Metal]

We could use compression? :)

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
IDEA! :)
WHAT IF...
We just used 1 bit ?
Eg: ( neededSize = numberOfPokemon / 8 ( rounded up ) ) * 2
( * 2 so that we can have a 'seen' count, and a 'caught' count )

 

[knizz]

That's what they're doing already :(

 

[Full Metal]

oh... :\
Well, just repoint a few things? :)

 

[Jambo51]

oh... :\
Well, just repoint a few things? :)

It's not as simple as that. We aren't talking ROM repointing, we're talking saved RAM repointing. That's a difficult task at the best of times. Besides which, I would still need to find and modify all the limiters first anyway so there's no point worrying about this until i've repointed all the ROM data, and fixed it appropriately, and got the dex to recognise the extra slots.

 

[NintendoBoyDX]

https://pastebin.com/eATb3Sek
Note: "graphically related" is a bad term. Those were places where it breaked that were not either:
when the pokedex was first opened
when the national dex was first opened
Also, I haven't tested them all in other places, but the ones listed that are not "graphically related" should be relevant.

 

[Jambo51]

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.

.text
.align 2
.thumb
.thumb_func
.global seencaughtflagsrepoint
main:
 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
.align
newblock: .word 0x0203E404

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 0x104AB4, and overwrite 0x104AB2 with 00 00.
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 0x0203E404 (seen) and 0x0203E456 (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. :)

 

[Joshuablevins]

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.

.text
.align 2
.thumb
.thumb_func
.global seencaughtflagsrepoint
main:
 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
.align
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. :)

Amazing work i applaud such enginuity i wish i was some help but im afraid that i only know C++ (seeing as im a computer science major) that is of no help to my knowledge

 

[Full Metal]

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.

.text
.align 2
.thumb
.thumb_func
.global seencaughtflagsrepoint
main:
 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
.align
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. :P

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 = 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.

-------------------------------------------------------------------------------------------------------------------
SammyF

Found here
Is this useful? :)

 

[Syncro]

Hi, I'm fairly new to the ASM (honestly, all i can do is insert a routine) so I can't help even when I want to do.
but because this is an issue about pokedex, I would ask, Is there any possibility to remove the catch-area map?
PS: sorry for my bad english, I let you an image in case that you don´t understend what i want to remove/erase/disable.
Thanks for the answers, and of course for the research (is a great work of all of you).
C U ^^