Ancient, but could be useful.
This is Icy Toast’s original tutorial, a guide to most everything he knew. This was an absolute must-read when it came out, it’s impact was huge. Without Icy Toast’s enormous advances, I doubt FE hacking would be anywhere near the level it is today. So without further ado, I present A Guide to Modification by Hex, copied word-for-word.
~ PROLOGUE: Getting Started ~
There are a few things that need to be said first. One of them, a rather important one actually, is this:
DISCLAIMER: Fire Emblem and all related characters, locations, names and whatever else are property of Nintendo and Intelligent Systems. Also, should anyone believe that their (possibly copyrighted) work has been used unrightfully in this guide, I’d appreciate it if they could contact me about it so that I can credit them/remove it.
Well, that’s that. =P
Secondly, you should remember that this guide won’t be complete and doesn’t aim to be so. I’m just providing this as a starting point for people to learn how to modify FE games by hex. After reading all of it, you’ll probably be able to find out many more things on your own. By the way, with ‘a starting point’ I mean, all the way from the start, so everyone should be able to understand this stuff, in fact. If you don’t understand it, it’s not because you’re not talented enough or anything, it’s just because I suck at explaining things. So… feel free to ask questions should anything be unclear.
The next thing that needs to be mentioned is the fact that although my guide will completely focus on modification of FE7, much of it can be applied in (almost) the same way to the other gba FE’s, except the locations of most parts of the data are different.
Finally, this chapter is called ‘prologue’ for a reason: it’s not one of the real chapters. It’s there only to explain the basic knowledge you should have to understand the chapters that are still to come. If you already have some experience with hex editing, you can just skip all this. If you don’t, well… I advise you to read it very thoroughly. ;D
What you will be needing
- An FE7 (US) ROM. The reason should be pretty obvious. Remember though, that owning a ROM is illegal, and that you should really buy the original games to support their creators. But yeah, I suppose everyone already knew that. XD
- A hex editor. I bet that surprised you all, didn’t it? Anyway, I personally recommend googling and downloading both WindHex32 and Cygnus Hex Editor 2.5. The latter can only be used freely for 30 days, but there… ehm, might just be a way around that. Of course I won’t be telling you, but… well, let’s just say it’s got something to do with your computer’s clock. >_> If you prefer not to taint your moral purity, just stick to WindHex, or any other hex editor you like. In this guide, however, I’ll be using Cygnus in a number of examples, and I’m afraid it’s almost a necessity for custom map coding.
- An IPS patcher/patch creator. I highly recommend StealthPatch, since it allows for expansion of the file being patched, which is a great advantage, to say the least. Again, just google it to find out where to download it.
- Nightmare and some FE7 modules. While not absolutely necessary, having these would be a plus, but I assume most of you will already have some anyway. If not, find them at FESS. (Download my modules here)(Link is dead)
- Unlz-gba: Only needed for graphics editing, but it’s an awesome tool. Once more, google is the key to finding it. =P
- Tile Layer Pro: It might be called ‘Pro’, but it’s really a free program, so don’t worry about having trouble to find this. It allows you to view a file’s code with the bytes showing up as coloured pixels, effectively enabling you to view and edit uncompressed graphics in the ROM. (As opposed to Unlz-gba, which lets you edit compressed graphics only)
- Mappy map editor: Not an absolute must, but it’ll save you many hours of work in the map programming section, so… find it and download it. Oh! And don’t forget to also download the FE7 tilesets here (updated with my link).
- The FE7 parser (by Twilkitri): Only needed for text editing. It allows you to change the script and it recompresses and inserts it into the game for you. An amazing tool, but unfortunately, it’s not publically available. Or maybe I should say, it’s not supposed to be publically available… since in fact, several links to it can be found in old topics at FESS. Good luck finding them. ;D
As an alternative to the parser, you could also try Zeld’s Anti-Huffman patch (to be found at FESS as well), which allows you to edit text directly in a hex editor. I’ve never worked with it myself, but apparently it does the job pretty well, so you might consider giving it a try.
The hexadecimal editor & system
Now that you (hopefully) have all you need, it’s time to run your hex editor and open the Rekka ROM. If all goes well, you should now see a bunch of seemingly illogical numbers and letters on your screen. In most hex editors, you should see three columns, the middle one being the widest. This middle column shows you what it’s all about: the 16777215 bytes that together make up one of the greatest games ever to exist. ;D
Depending on your hex editor and its settings, the middle column will show data in groups of either 2, 4 or 8 digits. One of the first things you should know, is that, in any hex editor, every 2 digits represent a byte. Let’s take a closer look at how this works.
Most likely, you’ll already know that a byte is made up of 8 bits, each of which can store a value of either 0 or 1. Together, this makes a total of 256 combinations for each byte, ranging from 00000000 to 11111111. This way of describing values is called the binary system, as there are only two (=bi) possible options for each digit.
Let’s compare this to the system we normally use: the decimal system. In the decimal system, we have 10 different possibilities for each digit in a number (hence the name), namely 0, 1, 2, 3, 4, 5, 6, 7, 8 and 9. Once we’ve had those ten, we just start over with a 1 in front of, then a 2, then a 3, and so on, until we reach 99, after which we start using a third digit. This should all sound terribly familiar, so why am I telling you this?
Well, in fact, it’s because the hexadecimal system is just the same thing, except there are 16 different options for each digit. These are represented by 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E and F. After that, counting in hex continues with a 1 in front of it, then a 2, … then an 8, then a 9, then an A, then a B… until we reach FF. See? It’s not at all hard to understand hex. (Note that although FF is the 256th possible value, it corresponds to 255 in the decimal system, since 0 is also a value.)
Now how does this relate to bits and bytes? When studying data in a hex editor, we want to be able to see the value of each individual byte. Of course, it might seem logical to make up a symbol for all 256 values a byte can store, so we can read the value of all of them, but since this would require learning 256 different symbols, this wouldn’t really be practical. On the other hand, if the hex editor would show every byte as the collection of 8 bits it actually is, thus only utilizing two different symbols, it wouldn’t be much clearer, as this would mean a lot of trouble if you wanted to decipher the actual (decimal) value of the byte from the 0’s and 1’s. That is why a middle road has been chosen. As it happens, half a byte, which thus consists of 4 bits and is often referred to as a nibble, can take 16 different values, ranging from 0000 to 1111. As 16 different values per digit, or a hexit, as it is also called in this context, is a manageable amount, each nibble is represented by a digit in a hex editor, so every pair of digits is a byte.
Look at the very first byte in the Rekka ROM; it says 2E. As you just learned, 10 in hex is 16 in decimal (since 0F = 15 and 10 comes after 0F), so 20 in hex is 32. It shouldn’t take much effort too figure out that E represents a decimal 14, so the 2E byte stores a value that would be represented by 32 + 14 = 46 in the decimal system. Don’t worry about having to calculate this stuff though, you won’t often need to do that. Still, it’s useful to be able to convert hex to decimal and the other way around, since it helps you to spot/edit things that represent an actual decimal number in the game, like character stats.
Here are a few numbers in both decimal and hex that are helpful to keep in mind:
hex 0A = dec 10
hex 10 = dec 16
hex 32 = dec 50
hex 64 = dec 100
hex 7F = dec 127
hex A0 = dec 160
hex FF = dec 255
Obviously, values exceeding FF are stored using more than one byte. There’s one catch to this though; those values taking more than a single byte have to be read by reversing the bytes. So a value that shows as 5A 8B 9F in the ROM, is to be read as 9F 8B 5A, which is 10455898 in decimal. Again, don’t worry about this too much yet, you won’t be needing this all that often. What might be good to remember though, is that a group of 2 bytes is referred to as a ‘half-word’, and a group of 4 bytes is referred to as a ‘word’.
Now that we’ve had all that theoretical stuff, let’s continue our guided tour of the hex editor itself. The column to the left of the actual data should show something like:
If it doesn’t, set your hex editor to display 16 bytes per row to fix it.
The numbers shown here are the addresses (also called offsets) of the first byte for each row. Each byte after that is obviously the address plus 1, but you should keep in mind that addresses are given in hexadecimal. The addresses are there to make it easier to refer to a certain part of the data, and you’ll soon be very thankful your hex editor shows them.
Finally, there should be another column at the right that shows lots of text, numbers, other kinds of characters and simple dots. This is the ASCII representation of the file. In other words, that’s what the file would look like if it were a text file. Usually, there’s very little of interest to see there, but at some points in the ROM, it allows you to see things you’d otherwise overlook. If you’d like to see an example of this, go to the offset 00FD8000. Each line here is partially written in ASCII, namely the names of a number of characters, and the other parts tell the game some vital information about that character’s battle animation, so having the ASCII column allows you to see which data is about which character. I won’t go into detail about this right now, but the thing you’re supposed to remember about this, is that the ASCII column can at times come in very handy.
Well, I’ll leave it up to you to explore all the awesome buttons of the hex editor yourself, but some you should definitely take a look at (if your hex editor has them) are the bookmarks, search and goto functions. They’ll be able to save you lots of time in the near future. =P
Now that you’ve learned a bit about how to use a hex editor, you probably think we can now start doing some actual editing, don’t you? Wrong. There’s one extremely important thing you should learn first, and you’ll need it for almost everything this guide will cover. Pointers.
A pointer is a small group of bytes, in Rekka’s case 4 bytes long, that does exactly as its name suggests. It points to another location in the ROM, or possibly even a location outside the ROM, like the gba’s memory. We won’t need to go into detail about the latter though, so I’ll stick to pointers pointing to places within the ROM here. Anyways, there are loads of pointers in the ROM, and you’ll need to learn how to read and formulate them if you want to get any further than the simple stuff.
Basically, a pointer is the exact address of the data it points to. The thing is, the bytes are reversed. This is not always the case, but in Rekka (and the other gba FE’s for that matter), it is. Also, 08 has to be added to the first byte of the offset, which has become the last byte in the pointer. Confusing? Nah, you’ll get used to it sooner than you think. And anyway, the 08 at the end of every pointer (since all adresses in Rekka start with 00, unless you expand the ROM) is really helpful as it allows you to quickly recognize pointers between other data.
Let me give you some examples just to get the hang of it.
Let’s say we have data at offset 00C9AB34, and we need a pointer to this data. First, we mentally separate the offset into 4 bytes: 00 C9 AB 34, and then we reverse them: 34 AB C9 00. Now, add 08 to the first offset byte, which is now the last pointer byte, and you get 34ABC908. There’s your pointer!
As another example, imagine you found a pointer saying “849AFD08”. Subtract the 08 from the last byte, reverse them, and voil