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

[Other] Ruby/Fire Red/Emerald Disassembly Inquiries

thedarkdragon11

New World Pirate
529
Posts
14
Years
May I just ask/clarify/confirm some things (might be obvious or a no brainer, but anyway):

  • Will a complete disassembly of those versions allow us to select and combine features into a single "version" or port a feature to one another (e.g. Battle Frontier/Contest to FR)?
  • Will this increase the possibility to expand things we were "unable" to expand before (e.g. icon palettes, Pokémon storage, character limit)?
Will ask more soon... Thanks!
 

BluRose

blu rass
811
Posts
10
Years
May I just ask/clarify/confirm some things (might be obvious or a no brainer, but anyway):

  • Will a complete disassembly of those versions allow us to select and combine features into a single "version" or port a feature to one another (e.g. Battle Frontier/Contest to FR)?
  • Will this increase the possibility to expand things we were "unable" to expand before (e.g. icon palettes, Pokémon storage, character limit)?
Will ask more soon... Thanks!
yes, will have to change a few small things depending on if things are named differently but otherwise should be easy
yes, but significant refactoring would have to occur to display a new system. for the pokémon storage, the only reason it has yet to be done is because the ram usage it needs is far more than we have, especially to accomodate for like the 800-something amount of pokémon we have now
 

thedarkdragon11

New World Pirate
529
Posts
14
Years
yes, will have to change a few small things depending on if things are named differently but otherwise should be easy
yes, but significant refactoring would have to occur to display a new system. for the pokémon storage, the only reason it has yet to be done is because the ram usage it needs is far more than we have, especially to accomodate for like the 800-something amount of pokémon we have now

I see... About the storage, assuming a "new system" will be made, won't it be possible for the required RAM to be reduced (e.g. re-engineer the structure) to match the maximum that the "console" itself can accommodate?
 
I see... About the storage, assuming a "new system" will be made, won't it be possible for the required RAM to be reduced (e.g. re-engineer the structure) to match the maximum that the "console" itself can accommodate?

The Pokemon data structure, you mean? Yes it would, though you'd be rewriting the Storage System to accommodate the shorter data structure. However, unless you're okay with losing things in that structure it's not going to be a lot of space saved. You can shave off like 12 bytes of space without losing anything important (except Pokerus, but who is realistically going to run into that in your hack?) But that only gives you like 74 more Pokemon slots in the existing space. Your restructure will depend on what you plan on using for your hack. For example, if you don't care about contests or ribbons, you can cut those out of the data structure and get like 10 extra free bytes. If you're getting rid of trading, you can get rid of OT OTID and OTSID fields. It's really up to what the hacker wants.

I don't know enough about how SRAM is laid out to say for sure if restructuring SRAM would be useful to increase Pokemon storage space. I know that there are regions in the save that are not used in English files (eReader stuff, for example). In R/S I know where that area starts but don't know where it ends. If it's the whole rest of that block from where the data starts until the start of Pokemon Box data, that'd be enough space for 23 Pokemon without compression. Perhaps cannibalizing the backup save for more Pokemon Storage could be a solution, but the backup has saved me from losing my file a couple of times in my youth, so that's a big loss in my opinion.

The issue is that the things you'd be able to prune from the space that isn't already used to store Pokemon are so small that I doubt it would be worth it to completely restructure SRAM to reclaim. The Pokemon themselves are huge compared to much of the other data in SRAM. Wiping out whole features that get saved would probably be a better bet. For example, getting rid of Secret Bases entirely in Ruby and Sapphire and using that SRAM space for Pokemon gives you 40 extra slots without compressing the Pokemon data structure. Block 3 in R/S saves Television Shows and Contest winner portraits. Getting rid of that gets you 49 extra slots. Getting rid of the eReader, Secret Bases, TV shows, and Contest Winner Portraits only nets us 112 extra Pokemon in the save, for a total of 532. It's something but with Pokemon totals as they are nowadays it's a drop in the bucket at the expense of nuking features that you seem to have interest in porting into one, mega Gen 3 game.

For reference, pruning the data structure down to 67-bytes (which is as far as I'd be comfortable) and using the space we just freed up in addition to the currently existing space gives us enough room for 635 Pokemon. Getting rid of all contest data as well puts you at 57-bytes per Pokemon which under the same conditions gets you 746 Pokemon. I'm personally not willing to get rid of Secret Bases, though I might be okay with losing TV shows and rewriting what data gets saved for Contest winner portraits to shrink it (each portrait is 32 bytes each and there are 13 of them).
 
Last edited:

thedarkdragon11

New World Pirate
529
Posts
14
Years
The Pokemon data structure, you mean? Yes it would, though you'd be rewriting the Storage System to accommodate the shorter data structure. However, unless you're okay with losing things in that structure it's not going to be a lot of space saved. You can shave off like 12 bytes of space without losing anything important (except Pokerus, but who is realistically going to run into that in your hack?) But that only gives you like 74 more Pokemon slots in the existing space. Your restructure will depend on what you plan on using for your hack. For example, if you don't care about contests or ribbons, you can cut those out of the data structure and get like 10 extra free bytes. If you're getting rid of trading, you can get rid of OT OTID and OTSID fields. It's really up to what the hacker wants.

I don't know enough about how SRAM is laid out to say for sure if restructuring SRAM would be useful to increase Pokemon storage space. I know that there are regions in the save that are not used in English files (eReader stuff, for example). In R/S I know where that area starts but don't know where it ends. If it's the whole rest of that block from where the data starts until the start of Pokemon Box data, that'd be enough space for 23 Pokemon without compression. Perhaps cannibalizing the backup save for more Pokemon Storage could be a solution, but the backup has saved me from losing my file a couple of times in my youth, so that's a big loss in my opinion.

The issue is that the things you'd be able to prune from the space that isn't already used to store Pokemon are so small that I doubt it would be worth it to completely restructure SRAM to reclaim. The Pokemon themselves are huge compared to much of the other data in SRAM. Wiping out whole features that get saved would probably be a better bet. For example, getting rid of Secret Bases entirely in Ruby and Sapphire and using that SRAM space for Pokemon gives you 40 extra slots without compressing the Pokemon data structure. Block 3 in R/S saves Television Shows and Contest winner portraits. Getting rid of that gets you 49 extra slots. Getting rid of the eReader, Secret Bases, TV shows, and Contest Winner Portraits only nets us 112 extra Pokemon in the save, for a total of 532. It's something but with Pokemon totals as they are nowadays it's a drop in the bucket at the expense of nuking features that you seem to have interest in porting into one, mega Gen 3 game.

For reference, pruning the data structure down to 67-bytes (which is as far as I'd be comfortable) and using the space we just freed up in addition to the currently existing space gives us enough room for 635 Pokemon. Getting rid of all contest data as well puts you at 57-bytes per Pokemon which under the same conditions gets you 746 Pokemon. I'm personally not willing to get rid of Secret Bases, though I might be okay with losing TV shows and rewriting what data gets saved for Contest winner portraits to shrink it (each portrait is 32 bytes each and there are 13 of them).

I see... Then how much slots can possibly be made if SRAM is restructured and remove the backup save (plus removing only trade stuffs, eReader stuffs and TV shows)? Correct me if I'm wrong, that backup save isn't that of a big deal in emulators as compared to cartridges?
 
I see... Then how much slots can possibly be made if SRAM is restructured and remove the backup save (plus removing only trade stuffs, eReader stuffs and TV shows)? Correct me if I'm wrong, that backup save isn't that of a big deal in emulators as compared to cartridges?

The backup save in RS is 56,000 bytes. You wouldn't even need to compress or dump features. You'd have 700 Pokemon in that space with an 80-byte data structure. 700+420 is 1120 Pokemon or 37 boxes worth total without doing anything but getting rid of the backup save. You can do the math based on the numbers from my previous post to find out roughly how many more slots you can tease out of the primary save based on whatever parameters you want.

Granted, as more Pokemon are added this is going to get worse. We will eventually have to settle for fewer spaces or make our hacks incompatible with hardware by addressing more SRAM than is possible.

EDIT: Doing this will also increase save times, as it'll be saving 112KB each save instead of 56KB. So this is an additional drawback.

EDIT2: You may also have to load box data from SRAM into RAM in pieces because there's no way this is all fitting at once. This means when you open the PC it's gonna have to load it more dynamically into RAM from SRAM, which necessitates saving the boxes back into SRAM as changes are made. There's a reason you had to save the game when you changed boxes in RBYGSC. This is the reason. Turning off the game without saving but after manipulating the boxes resets your progress but not your boxes in this scenario. The PC will have to be made more cumbersome with this extension to prevent glitches like this from happening. Perhaps splitting boxes into "banks" that you must save before switching to. So have 12 boxes in 3 banks and you only have access to one bank at once without fully saving your game to switch to another one. People more knowledgeable about the RAM we have available would be better at exactly partitioning out the RAM for a scenario like this.
 
Last edited:

thedarkdragon11

New World Pirate
529
Posts
14
Years
The backup save in RS is 56,000 bytes. You wouldn't even need to compress or dump features. You'd have 700 Pokemon in that space with an 80-byte data structure. 700+420 is 1120 Pokemon or 37 boxes worth total without doing anything but getting rid of the backup save. You can do the math based on the numbers from my previous post to find out roughly how many more slots you can tease out of the primary save based on whatever parameters you want.

Granted, as more Pokemon are added this is going to get worse. We will eventually have to settle for fewer spaces or make our hacks incompatible with hardware by addressing more SRAM than is possible.

EDIT: Doing this will also increase save times, as it'll be saving 112KB each save instead of 56KB. So this is an additional drawback.

EDIT2: You may also have to load box data from SRAM into RAM in pieces because there's no way this is all fitting at once. This means when you open the PC it's gonna have to load it more dynamically into RAM from SRAM, which necessitates saving the boxes back into SRAM as changes are made. There's a reason you had to save the game when you changed boxes in RBYGSC. This is the reason. Turning off the game without saving but after manipulating the boxes resets your progress but not your boxes in this scenario. The PC will have to be made more cumbersome with this extension to prevent glitches like this from happening. Perhaps splitting boxes into "banks" that you must save before switching to. So have 12 boxes in 3 banks and you only have access to one bank at once without fully saving your game to switch to another one. People more knowledgeable about the RAM we have available would be better at exactly partitioning out the RAM for a scenario like this.

With those drawbacks, it seems to me that it has to be restructured thoroughly in order to become safer... But I'm glad to know that it's quite possible on paper...
 
Back
Top