• 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?".
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.

[FR] Expanding the Pokedex

252
Posts
10
Years
  • Age 27
  • Seen Jul 6, 2019
I just want to add that this took months to accomplish even with years of research to start on. So take that and go into an almost completely unresearched rom (in this area at least) and it will take a while, a long while.
Yikes... Well I'm probably not going to be hacking for that long, so this is out of the boat then. Would it be possible to increase the size of the regional pokedex then without as much hassle as expanding the national pokedex?
 

GoGoJJTech

(☞゚ヮ゚)☞ http://GoGoJJTech.com ☜(゚ヮ゚☜)
2,475
Posts
11
Years
Yikes... Well I'm probably not going to be hacking for that long, so this is out of the boat then. Would it be possible to increase the size of the regional pokedex then without as much hassle as expanding the national pokedex?

It could be a byte change like FR but, again, who knows? lol
 
22
Posts
10
Years
In fact, I've never worked on Ruby or Sapphire, but I was convinced that the construction of the game had great common with Emerald. Excuse me x).
 
91
Posts
14
Years
  • Seen Feb 22, 2023
Okay okay okay, I state this again: I did most of the research for emerald, I am also willing to post the data for it, actually I already posted my ported version of JPANs Save Block Recycle Hack somewhere in RD, for the german version of emerald I guess, it can be ported easily. I also repointed all of the required tables, for emerald you have to do some additional work, which would be: The second sprite table, containing all of the animated sprites(I don't know if the other one is even used, since there is only one pointer to it it could very well be deadcode); And the sprite animation table(The movements pokémon do when they are summoned) You can find the information in a common editors ini file or research them yourself. Also, there are several versions of malloc and free, whereas we are only interested in malloc. In emerald they use a version of it which instantly cleans up the memory space it provides you. It is locaded at: 0x08000b4c, I guess this is global for all of the roms, since those header adresses are compiled instantly. There is also an ldr instruction which is allocating the memory for emerald: 0x080BB65A (BPED, german), however afterwards follow a few routines which load global pokédex variables in a form of "ldr malloced_base + 0x6XX" and if you have too many Pokémon you will overwrite those and run into severe problems. Therefore you have to relocate them, as for me I wrote a quick tool to do that, just search for 4-aligned words in an area which I guess contains all of the routines and adding a static value to them. That for the memory in emerald...

There is also a very similar limiting thingie in emerald, a simple bhi instruction you can just bypass with 0x0000; It was posted for BPEE somewhere already, for BPED its 0x0806D430. Now for the interesting part, I have no clue what to do about the amount of pokémon that is loaded into the dex, there is something at 0x080BC94A, which loads a global variable onto the stack, using mov and lsl, if you do change that it will load more pokémon, you also have to change some statics like in Firered, but I don't know exactly which ones and as I said above between Deoxys and 412d there is weird data loaded into my dex... Thats the problem I am facing currently, concerning emerald, the rest can be done "fairly" easily.

Did someone look at my national order table and can tell me if it's correct or how it has to look like? I am kind of sure this is not the problem, but anyways, it is somehow strange, you know.

~SBird

Edit: The save block thingie: http://www.pokecommunity.com/showthread.php?t=306202 You can probably easily port it to BPEE, but you want to use different adresses, I recommend 0x0203d000 ff; Also if we discuss on emerald for longer(which I would be interested in, should'nt we go to RD? Just asking.
 
Last edited:

karatekid552

What happens if I push it?....
1,771
Posts
11
Years
Okay okay okay, I state this again: I did most of the research for emerald, I am also willing to post the data for it, actually I already posted my ported version of JPANs Save Block Recycle Hack somewhere in RD, for the german version of emerald I guess, it can be ported easily. I also repointed all of the required tables, for emerald you have to do some additional work, which would be: The second sprite table, containing all of the animated sprites(I don't know if the other one is even used, since there is only one pointer to it it could very well be deadcode); And the sprite animation table(The movements pokémon do when they are summoned) You can find the information in a common editors ini file or research them yourself. Also, there are several versions of malloc and free, whereas we are only interested in malloc. In emerald they use a version of it which instantly cleans up the memory space it provides you. It is locaded at: 0x08000b4c, I guess this is global for all of the roms, since those header adresses are compiled instantly. There is also an ldr instruction which is allocating the memory for emerald: 0x080BB65A (BPED, german), however afterwards follow a few routines which load global pokédex variables in a form of "ldr malloced_base + 0x6XX" and if you have too many Pokémon you will overwrite those and run into severe problems. Therefore you have to relocate them, as for me I wrote a quick tool to do that, just search for 4-aligned words in an area which I guess contains all of the routines and adding a static value to them. That for the memory in emerald...

There is also a very similar limiting thingie in emerald, a simple bhi instruction you can just bypass with 0x0000; It was posted for BPEE somewhere already, for BPED its 0x0806D430. Now for the interesting part, I have no clue what to do about the amount of pokémon that is loaded into the dex, there is something at 0x080BC94A, which loads a global variable onto the stack, using mov and lsl, if you do change that it will load more pokémon, you also have to change some statics like in Firered, but I don't know exactly which ones and as I said above between Deoxys and 412d there is weird data loaded into my dex... Thats the problem I am facing currently, concerning emerald, the rest can be done "fairly" easily.

Did someone look at my national order table and can tell me if it's correct or how it has to look like? I am kind of sure this is not the problem, but anyways, it is somehow strange, you know.

~SBird

Edit: The save block thingie: http://www.pokecommunity.com/showthread.php?t=306202 You can probably easily port it to BPEE, but you want to use different adresses, I recommend 0x0203d000 ff; Also if we discuss on emerald for longer(which I would be interested in, should'nt we go to RD? Just asking.

There is only one front sprite table that needs re-pointing and it is the one with the double framed 128x64 sprites. The other is actually a leftover from RSE. If you look closely at the images, they aren't the same as some sprites were changed for Emerald.

If you guys do manage to pull this off, I promise that I will code it.
 

GoGoJJTech

(☞゚ヮ゚)☞ http://GoGoJJTech.com ☜(゚ヮ゚☜)
2,475
Posts
11
Years
There is only one front sprite table that needs re-pointing and it is the one with the double framed 128x64 sprites. The other is actually a leftover from RSE. If you look closely at the images, they aren't the same as some sprites were changed for Emerald.

If you guys do manage to pull this off, I promise that I will code it.

Emerald having leftover from rse lol
Aside from that typo, you'd have to test the JPAN save block hack on real hardware. I have a DSTWO, so maybe I can try it out for you.
 

karatekid552

What happens if I push it?....
1,771
Posts
11
Years
Emerald having leftover from rse lol
Aside from that typo, you'd have to test the JPAN save block hack on real hardware. I have a DSTWO, so maybe I can try it out for you.

Technically, the DSTWO uses an emulator on the NDS. It isn't actually real hardware.

When we say real hardware, specifically it is using a BIOS file, not actually hard, pushable buttons.:P
 
1,323
Posts
16
Years
  • Seen Dec 9, 2023
Emerald might be about 10% harder. Why? Cuz it's not as researched as FR. Even if it was, you'd have to debug all of the loading routines (sprites, icons, cries, everything you have to repoint) to remove limiters and find the malloc (assuming there is a malloc)
Then you'd have to research the dex, because its loading and storing is most likely 100% different from Fire Red's. Ruby would just take years because it's so unorganized.
Actually I've got some bad news, though I may be mistaken (and believe me, I hope I am):
I believe Jambo51 once said that Emerald's Pokédex is just as messed up as Ruby/Sapphire's, in the sense that it doesn't use the malloc system and that the pointers are hard coded and near-impossible to find. Jambo51 has tried expanding Ruby's Pokédex and he has stated that it is pretty much impossible because of how messy the coding is.

Not trying to be a party-pooper, as I would love to hack Ruby/Emerald as I have in the past, simply because I just like it more.
 
91
Posts
14
Years
  • Seen Feb 22, 2023
@Chaos Rush: Party hard:
Spoiler:

Emerald does use malloc, the thing is just that the global variables are linked in the form of "BASE_ADRESS + X" meaning you have to find A LOT of those and some are hard-hard-coded (or something^^) meaning that the compiler did not export the exact adress but only a mov-lsl instruction, which is good for saving space and bad for romhackers.

So yeah, it is possible, it is just some work but I am not willing to give up (by now)

~SBird
 

karatekid552

What happens if I push it?....
1,771
Posts
11
Years
@Chaos Rush: Party hard:
Spoiler:

Emerald does use malloc, the thing is just that the global variables are linked in the form of "BASE_ADRESS + X" meaning you have to find A LOT of those and some are hard-hard-coded (or something^^) meaning that the compiler did not export the exact adress but only a mov-lsl instruction, which is good for saving space and bad for romhackers.

So yeah, it is possible, it is just some work but I am not willing to give up (by now)

~SBird

In my own experience, I found pointers by writing a python script to do a little math. Meaning it would take a start and end offset, then search for every pointer for every offset in between and spit me back the results. You could do the same thing.
 
91
Posts
14
Years
  • Seen Feb 22, 2023
@Karatekid: Thats about what I did, what I did not so far is checking if those were the right ones, probably I am replacing a bit too much at the moment hehe... Also there are some I can't find just that way, because the offsets are even enough for the compiler to insert them via. mov/lsl. I guess I found all of them, because my dex is now working just fine, and I'll let you guys know if it really worked after some testing. If someone wants to do the same thing here is what I did so far:

-Repoint the national order table and moved the 25 slots between jotho and hoeen backwards, filling in 00 00 after the hoeen dex and creating the order for my new mons.
-Allocate 0x2000 bytes for the pokédex(You can probably do less)
-Kill the limiter which loads the dex data
-Add 0x700 to every 0x000006XX word I could find in the area that I think is the pokédex routines.
-Add 1 to each lsl rd, rm, #X instruction that I found out is responsible for the dex's global variables. I checked those with a debugger, so they are definitely it and I don't think there are more, since the dex is working just fine now.,

As ofr the 6XX stuff I wrote a quick program to do it, as karatekid already said. This was definitely easier, but I don't know if the stuff I changed really only affects the dex, and nothing else. I definitely chose a big area(0xbB6dc - 0xf0000)

So yeah, to conclude: Emerald is a lot harder, but it's not impossible!

~SBird
 

karatekid552

What happens if I push it?....
1,771
Posts
11
Years
@Karatekid: Thats about what I did, what I did not so far is checking if those were the right ones, probably I am replacing a bit too much at the moment hehe... Also there are some I can't find just that way, because the offsets are even enough for the compiler to insert them via. mov/lsl. I guess I found all of them, because my dex is now working just fine, and I'll let you guys know if it really worked after some testing. If someone wants to do the same thing here is what I did so far:

-Repoint the national order table and moved the 25 slots between jotho and hoeen backwards, filling in 00 00 after the hoeen dex and creating the order for my new mons.
-Allocate 0x2000 bytes for the pokédex(You can probably do less)
-Kill the limiter which loads the dex data
-Add 0x700 to every 0x000006XX word I could find in the area that I think is the pokédex routines.
-Add 1 to each lsl rd, rm, #X instruction that I found out is responsible for the dex's global variables. I checked those with a debugger, so they are definitely it and I don't think there are more, since the dex is working just fine now.,

As ofr the 6XX stuff I wrote a quick program to do it, as karatekid already said. This was definitely easier, but I don't know if the stuff I changed really only affects the dex, and nothing else. I definitely chose a big area(0xbB6dc - 0xf0000)

So yeah, to conclude: Emerald is a lot harder, but it's not impossible!

~SBird

Always check your offsets. If the offset%4 != 0, then skip it.

Also, I would make a list of changes (I'm sure you already did) and go through them slowly. You never want to replace too much. Check the surrounding areas for anything Pokedex related and then keep working. There shouldn't be more than about 10 changes (even that is a stretch) so yeah.

Edit: I just had a great idea! Keep a public Google doc and link to it here, so that we can follow your progress and then help you. don't allow the world to edit, just comment.
 

kearnseyboy6

Aussie's Toughest Mudder
300
Posts
15
Years
  • Seen Jun 22, 2019
Hate to bump but here are some glitches I have noticed...

When you received an extended mon from a trade (eg Arceus for Giratina) then when you receive Giratina it has Arceus' (what's the plural form? haha) palette.

Also when I catch a wild Buizel, ONLY on the screen it displays say Ratatta, it then registers Buizel in the Pokedex and Ratatta does not get registered. It really doesn't bother me... just wondering if others experience this?
 

karatekid552

What happens if I push it?....
1,771
Posts
11
Years
Hate to bump but here are some glitches I have noticed...

When you received an extended mon from a trade (eg Arceus for Giratina) then when you receive Giratina it has Arceus' (what's the plural form? haha) palette.

Also when I catch a wild Buizel, ONLY on the screen it displays say Ratatta, it then registers Buizel in the Pokedex and Ratatta does not get registered. It really doesn't bother me... just wondering if others experience this?

The second is probably the result of not making the habitat table properly. The first.... well... none of us trade, lol.
 

MrDollSteak

Formerly known as 11bayerf1
858
Posts
15
Years
The second is probably the result of not making the habitat table properly. The first.... well... none of us trade, lol.

Actually I fear the second may be something else entirely.
When I messed around with habitat data myself before your tool came out,
I noticed that no matter what Pokemon I caught, it'd display the first page
of the first habitat.
I think that's why it's showing Rattata, because Rattata'd be the first pokemon
in the grassland.
My worry is that there's some sort of byte somewhere in the midst of the
habitat data that when expanded, repointed or rearranged leads to catching
problems.
(This was actually one of the glitches that got me started on ASM, I just
haven't looked into it since.)
 
89
Posts
10
Years
Is it possible to port this to another ROM, say, Ruby?
Also, can you please post the methods you used to obtain your offsets (like the offset containing the amount of memory assigned for the Pokédex, I certainly haven't found that in any INIs) so that others can try porting this to other ROMs?
 

GoGoJJTech

(☞゚ヮ゚)☞ http://GoGoJJTech.com ☜(゚ヮ゚☜)
2,475
Posts
11
Years
Is it possible to port this to another ROM, say, Ruby?
Also, can you please post the methods you used to obtain your offsets (like the offset containing the amount of memory assigned for the Pokédex, I certainly haven't found that in any INIs) so that others can try porting this to other ROMs?

Ruby doesn't have a malloc system to store the dex info, so no, it's almost impossible on Ruby. The code is so messy you'll get lost in it.
 
Back
Top