- 24
- Posts
- 9
- Years
- Seen Nov 3, 2018
Setting up and using Pokeruby/Pokeemerald
![[PokeCommunity.com] [Dissassembly] Setting up and using the Pokeruby/Pokeemerald dissassembly [PokeCommunity.com] [Dissassembly] Setting up and using the Pokeruby/Pokeemerald dissassembly](https://tcrf.net/images/6/62/Pok%C3%A9mon_Ruby-title.png)
![[PokeCommunity.com] [Dissassembly] Setting up and using the Pokeruby/Pokeemerald dissassembly [PokeCommunity.com] [Dissassembly] Setting up and using the Pokeruby/Pokeemerald dissassembly](https://tcrf.net/images/c/c8/Pok%C3%A9mon_Emerald-title.png)
Part 0: An Introduction
Spoiler:
I'm sure you've all heard of the recent gen 3 disassemblies and want to use them. That's good: but I'm sure an equal portion of you are on Windows and don't know how to make salad from scratch. So, how do you use pokeruby to make changes to things such as the code itself and what advantages does it offer me over traditional binary hacking, I hear you ask?
I'm glad you asked, but first we need to go over traditional methods of hacking gen 3.
1. Pre-Existing Tools
Currently, changing things in ROM requires just that: directly editing a ROM. The thing is though that pointers and data itself cant be moved without moving it to free space in the ROM, and whatever pointed there needs to be repointed by hand, manually, in order to avoid issues. This is particularly annoying if you're making a lot of changes.
2. Compiled C Injection
So what if you want to add new code? Well, you could write some C and compile it into ARM and thumb, and then manually change the pointers in your code to direct at the correct ROM data and redirect anything to use your new function. Still sounds very annoying? Well, lets talk about how this ROM was assembled in the first place.
The Pokemon games, in Game Freak's original source, were written in a programming language called C - specifically C90, a version of C published in 1990. This means all the data and code that make up the ROM were written in separate human-readable C files. These files are then run through a compiler to generate machine code. This machine code output is all joined together using a tool called a linker, which figures out how to combine these fragments into the final output (the ROM). This linking process determines the final offsets and recalculates every pointer for all the data and code automatically, meaning you don't have to keep track of the locations of data, only the labels given to that data.
By reversing this process, we can translate all the pointers and binary data (that you'd edit in a hex editor or another tool) back into human-readable C. This means that we can repeat the compiling and linking processes to get a modified ROM, but maintain the flexibility of being able to work with labeled data and code.
What is compilation you ask?
Compilation is the process that takes a higher level language and compiles it into assembly so the computer can understand and execute the instructions. This can be used for a number of reasons: but the main one here is that it makes a programmer's job easier when all they have to deal with is the higher level language and not things like register balancing and reallocation by hand.
There are a number of compiler/developer environments, but the one we will be using for this tutorial is Cygwin and thus assumes you have Windows at the moment. (Sorry Linux and Mac)
Part 1: Following pokeruby's INSTALL.md
Linux
Install devkitARM.
Then run the following commands.
Code:
export DEVKITPRO=/opt/devkitPro
echo "export DEVKITPRO=$DEVKITPRO" >> ~/.bashrc
export DEVKITARM=$DEVKITPRO/devkitARM
echo "export DEVKITARM=$DEVKITARM" >> ~/.bashrc
git clone [url]https://github.com/pret/pokeruby[/url]
git clone [url]https://github.com/pret/agbcc[/url]
cd agbcc
./build.sh
./install.sh ../pokeruby
cd ../pokeruby
To build pokeruby.gba:
Code:
make -j4
Mac
Install devkitARM.
Then in Terminal, run the following commands.
Code:
xcode-select --install
export DEVKITPRO=${HOME}/devkitPro
echo "export DEVKITPRO=${DEVKITPRO}" >> ~/.bashrc
export DEVKITARM=${DEVKITPRO}/devkitARM
echo "export DEVKITARM=${DEVKITARM}" >> ~/.bashrc
git clone [url]https://github.com/pret/pokeruby[/url]
git clone [url]https://github.com/pret/agbcc[/url]
cd agbcc
./build.sh
./install.sh ../pokeruby
cd ../pokeruby
To build pokeruby.gba:
Code:
make -j4
Windows
Install devkitARM to the default directory (C:/devkitpro).
Then download Cygwin setup-x86_64.exe for 64-bit Windows, setup-x86.exe for 32-bit.
Run the Cygwin setup and leave the default settings. At "Select Packages", set the view to "Full" and choose to install the following:
- make
- git
- gcc-core
- gcc-g++
- libpng-devel
In the Cygwin terminal, enter these commands:
Code:
export DEVKITPRO=/cygdrive/c/devkitpro
echo export DEVKITPRO=$DEVKITPRO >> ~/.bashrc
export DEVKITARM=$DEVKITPRO/devkitARM
echo export DEVKITARM=$DEVKITARM >> ~/.bashrc
git clone [url]https://github.com/pret/pokeruby[/url]
git clone [url]https://github.com/pret/agbcc[/url]
cd agbcc
./build.sh
./install.sh ../pokeruby
cd ../pokeruby
To build pokeruby.gba:
Code:
make -j4
Compiling Sapphire and later revisions
When you simply enter make and don't specify a target, then Pokémon Ruby 1.0 will be built. However, Sapphire can also be built, along with revisions 1 and 2 of both Ruby and Sapphire. Here is a listing of each ROM that can be made, along with the command to make the ROM.
Code:
Version | Command
-------------|---------------------
Ruby 1.0 | make ruby
Ruby 1.1 | make ruby_rev1
Ruby 1.2 | make ruby_rev2
Sapphire 1.0 | make sapphire
Sapphire 1.1 | make sapphire_rev1
Sapphire 1.2 | make sapphire_rev2
Faster builds
After the first build, subsequent builds are faster. You can further speed up the build:
Parallel build
This significantly speeds up the build on modern machines.
By default make only runs a single thread. You can tell make to run on multiple threads with make -j. See the manfile for usage (man make).
The optimal value for -j is the number of logical cores on your machine. You can run nproc to see the exact number.
Code:
$ nproc
8
If you have 8 cores, run:
Code:
make -j8
-j on its own will spawn a new thread for each job. A clean build will have thousands of jobs, which will be slower than not using -j at all.
Disable the dependency scanning
If you've only changed .c or .s files, you can turn off the dependency scanning temporarily. Changes to any other files will be ignored, and the build will either fail or not reflect those changes.
Code:
make NODEP=1
Part 2: Making changes and test them
Spoiler:
TODO: Make better guides
Conclusion:
You'll be able to make code changes with the disassembly similar to this fashion. To note: pokeemerald nor pokefirered is not ready for production yet, obviously, but this tutorial will teach you how to use it on a most basic level. Although this does and will open up gen 3 tremendously: there is much work to be done; we need to work more on pokefirered sometime down the line. Hopefully, now that you know how to setup the dissassemblies, you know how to make changes and eventually contribute to our cause. Thanks for reading.
Last edited: