• Our software update is now concluded. You will need to reset your password to log in. In order to do this, you will have to click "Log in" in the top right corner and then "Forgot your password?".
  • Forum moderator applications are now open! Click here for details.
  • Welcome to PokéCommunity! Register now and join one of the best places on the 'net to talk Pokémon and more! Community members will not see the bottom screen advertisements.
  • Want to share your adventures playing Pokémon?
    Check out our new Travel Journals forum for sharing playthroughs of ROM Hacks, Fan Games, and other Pokémon content!
  • IMPORTANT: Following a takedown request, the following hacks have been delisted from PokéCommunity:

    • Pokémon Glazed
    • Pokémon: Giratina Strikes Back
    • Pokémon Flora Sky
    • Pokémon Stranded
    The downloads and discussion threads for these hacks will no longer be accessible, and staff will be unable to return questions regarding accessing this content.

Research: FireRed Pokédex Hacking

Jambo51

Glory To Arstotzka
736
Posts
14
Years
  • Seen Jan 28, 2018
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:


Evolutions work without National Dex:
Spoiler:


Seen/Caught Flags:
Spoiler:


Pokédex Information Page:
Spoiler:


Main Pokédex Page (Listing):
Spoiler:


649 Patch Alpha 2 Available Here: http://www.pokecommunity.com/showpost.php?p=6932134&postcount=169
 
Last edited:

knizz

192
Posts
16
Years
  • Seen Oct 28, 2020
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.

Code:
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.
 
Last edited:

Jambo51

Glory To Arstotzka
736
Posts
14
Years
  • Seen Jan 28, 2018
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

C(++) Developer.
810
Posts
16
Years
Yahoo~!
:>
Thanks for posting. As soon as I quit fideting with phoenix I'll get to work on using this. :)
 

Jambo51

Glory To Arstotzka
736
Posts
14
Years
  • Seen Jan 28, 2018
@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

C(++) Developer.
810
Posts
16
Years
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

C(++) Developer.
810
Posts
16
Years
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

C(++) Developer.
810
Posts
16
Years
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

Glory To Arstotzka
736
Posts
14
Years
  • Seen Jan 28, 2018
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

C(++) Developer.
810
Posts
16
Years
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 )
 
Last edited:

Jambo51

Glory To Arstotzka
736
Posts
14
Years
  • Seen Jan 28, 2018
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.
 
94
Posts
13
Years
  • Seen Nov 2, 2016
http://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

Glory To Arstotzka
736
Posts
14
Years
  • Seen Jan 28, 2018
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.

Code:
.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. :)
 
Last edited:
69
Posts
13
Years
  • Seen Jan 8, 2012
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.

Code:
.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

C(++) Developer.
810
Posts
16
Years
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.

Code:
.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? :)
 
2
Posts
12
Years
  • Seen Oct 4, 2011
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 ^^
 
Last edited:
Back
Top