11 March 2016 - Forum Rules

Main Menu

Attempting first project: a few questions.

Started by 11tw, August 11, 2014, 06:15:54 PM

Previous topic - Next topic


Hi, I'm new to romhacking. I've taken it up as a way to learn binary and hex coding. My original plan was to level/stat edit the Japan-only release Fire Emblem: Mystery of the Emblem, in order to make units more balanced.
I have:

The translated ROM
Znes emulator

I have read as many guides as I could, but none of them go into the specifics of level editing, most of them mention either a) using hexadecimal code to edit a ROM or b) using/making a level editor.
I am not keen on using a pre-made level editor, as I would prefer to do this from scratch.

What would really help me start out would be:

1) a link to an in-depth guide into level editing
2) some advice on which method of hacking would be best to complete my target
3) any corrections on anything I've got wrong so far, programmes I should install, incorrect use of terminology etc.

thanks for any feedback,


Well, if I were to do this from scratch, I'd need a debugger emulator (such as ) and possibly a hex editor (such as XVI32). Then I would play around with the debugger emulator emulating the game and find and document the locations and format of the data I want to edit. Then I would either write a small tool or manually change the values in the ROM to what I want. Done!

But to understand what the concepts in the debugger emulator mean, you should probably understand some SNES CPU and memory basics. For just changing maps and unit properties you probably won't have to code anything in asm, but being able to read it is still kind of useful.

A game contains many arrays of numbers in seemingly arbitrary locations in the ROM. Things like map data and unit data are most likely among those countless numbers there in the ROM. Open the ROM with a hex editor to see this beautiful world to get an idea.

Cheat codes that manipulate what you want to edit can be useful to know, not necessary though. Reference sheets or FAQs containing unit stats can be useful when checking if what you found looks like unit data, for example (edit: and obviously you may be able to find the likely data in the ROM if you put the correct numbers in the correct format and simply search in a hex editor..). Maps can be seen ingame or possibly in some FAQs, for similar comparisons. Minor things.


Welcome, tw11.
Just to add to this - Fast's romhacking guide also mentions some techniques about figuring out game mechanics. Essentially I think what he mentions drills down to:
- save the state of the game
- do something that changes the element you want to edit (ex: lose a life, or pick up an object)
- save the state of the game
=> you can compare both game states to see what changed.

I'm not sure if that logic fully applies to level editing, but it could as far as objects and consumables are concerned (at elast for you to get to understand how objects are "named" by the game).

Other than that, nothing to add to the previous post. Level editing requires a good understanding of the game's data, which is bound to require a mix of browing of the ROM (with graphics editor first, maybe, to see map tiles & unit tiles and such?) and emulating to understand what the ASM actually does. It"s not an easy task, but you seem determined. So good luck!!


thanks STARWIN and BlackDog61, I'm very grateful for the help.


That sounds more like cheat making than level reverse engineering. You can do things that way though and you probably will be following what happens in memory -- it is always nice when a game changes such things for you.

Level editing... it is doable and there are tricks. The main one for me is figure out how I would do it were I to be programming it. Most levels I see are layered though, that is to say you have the thing that gives you the graphics, the thing that gives you the layout and the thing that gives you the enemies, the items and the other stuff. How any timers/scripts/conditionals get added in there varies a lot, and it can often be that the devs hacked in a routine that deals with that specific level -- old games tend to be more on the "make it work" side of things rather than "make pretty code we can reuse in the sequel/next version".
The only times I tend not to see the layered approach are really old games (talking old arcade/Lode Runner old), in those cases it is usually because it is quite simple.

Unit editing is probably closer to stats than levels. For Japanese games this can get odd -- some things like shining force are random and it saves accordingly, other games will have a fixed progression and just need to save what level, equipped weapons and experience you have. Fixed stuff is nice though as it is usually either controlled by an algorithm or a table somewhere in the game that has all the info.


I now have a SNES emulator with a debugging console (SNES9x). I can use it to play the game, but how do I use the debugging console to 'edit' the game? I have read a lot of FAQs and walkthroughs which say things about disassembly and assembly etc. but they all just say that they won't cover it and that other guides explain those parts.
Is there any guide which explains, for beginners, the way you use a debugger to edit the data within the ROM? If so would anyone be kind enough to link me to it? (my aim is to edit the growth rates of stats of characters to make Fire Emblem more balanced)


I would expect most emulators not to allow the edition of game files. ppsspp allows it, though, so maybe snes9x does?
The way I see things, you should use the debugger to understand how things work (using the disassembly view with breakpoints on instructions, on memory read/write, and with the memory viewer).
Once I understand how things work, for a particular goal, I would edit the game's files using a hex editor. Then test it again in the emulator.

I'm sure others will propose more refined ways, but this one is "sort of universal". ;)


I have looked up what breakpoints are, and as far as I can tell they are parameters which you give the programme to pause at. Is this so that you can see what's happening to the memory of the ROM at that specific moment?

Also, I can't figure out what is meant by 'memory viewer'. Every time I look it up I get links to programmes which have memory viewers, but I don't know what that is or how to access it on SNES9X. An explanation or of what a memory viewer is, and an image showing how to use it in SNES9X would be awesome.

Quote from: BlackDog61 on August 12, 2014, 12:06:07 PM
(using the disassembly view with breakpoints on instructions, on memory read/write, and with the memory viewer).
So what does that mean? And how do I do that? I'm guessing that doing this involves setting the breakpoints so that the programme pauses at a moment where you can check something relating to the memory, but I'm not sure.

Any clarification or help would be great, as right now I feel totally clueless (and a bit stupid)...

p.s. I have no idea how to set breakpoints. A link to a guide on that would be great, as I was unable to find one.


Breakpoints are pretty much that, you can also log things (though that is probably better called watchpoints or just logging) and some debuggers will allow actions at those points as well. Here you have the classic read, write, execute breakpoints. The do much as you expect -- if something is written to it will stop and detail what is going on, if something is read as part of a DMA read/general read it will stop it and detail what is going on and if something is actually executed (not just read) it will trigger at that point.
The what is going on part is key, mainly as it will have what instructions led to that point and so if you want to say change what sprite is loaded you can put a read breakpoint on the sprite in the ROM, when that eventually gets read into VRAM you have the instruction that did it. You may have to work backwards from there (it might just be you have found the proverbial grunt that pulled the trigger where you may want the general) but by this point changing the sprite load location is so much busywork.

Memory viewer is much like it sounds. The game console/device has memory, the memory viewer can view it (usually at time you tell it to open the memory viewer or in real time) and it usually looks and acts much like a hex editor (complete with ASCII decode of the hex on the right, though here you should also have the option to load a table). Most will also allow you to manipulate the memory and this would be no exception, again it works much like a hex editor with the only real difference being it has a dropdown box on the top left to select between various memory types/locations.
As the memory on most old consoles has a defined layout/map ( ) it will probably also be split along those. Though I would not do without one for most purposes it is kind of like hex editing -- you can do an awful lot in it but if you ever see someone do something it is probably the result of a lot of work before then and/or a party trick.

Also I am not sure what the current hotness is for SNES debugging. bsnes changed a lot of things but Geiger's Snes9x (or some of the other SNES9x versions) are still useful and may be what people know/have guides for, equally no$sns appeared not so long ago and has a few fans (his other emulators have top flight debugging options, this is not quite as nice but beats a lot of other things). For then it should open with a debug window, you may need to click run to start the game.
Once in it if you click show hex (second button down in the third column) it will bring up the memory viewer, you may have to select view RAM. I should also note you have reasonable cheat searching options as part of the emulator as well -- "all" cheat making amounts to memory searching but one need not be making cheats in the traditional sense to find some value here.
Breakpoints. Third column, top button. It will pop up a new window. Put the memory address in you want to halt on and select whether you want write, write or execute (or some combo of them). When it changes it will halt the game and pop up some text in the debug console.
It will look something like
My breakpoint was for a write on 7E0026
$8F/FF79 E6 26       INC $26    [$00:0026]   A:0B43 X:0000 Y:00A2 P:envmxdIzc
INC means increase, as the machine is 16 bit you have to fiddle with things if you want more 16 bits of addressable memory (hence the slight complexity in the memory map stuff linked above)

On guides...
assembly language is just a human readable form of machine code, maybe with some niceties for obvious things. Basic processors do not actually know how to do all that much so most things, especially on older processors, are built up from basic adds, multiplies (though the SNES does not have this nor a divide instruction), read this area, write this area, compare this to that and act accordingly. You can speak to the memory in various ways (these vary with processor) but a lot of what you do will concern the registers. These are sections of extremely fast memory in the CPU and is arguably what determines the bit of a machine* (if you have 8 bit registers you have an 8 bit machine, 16 bit makes for a 16 bit machine.....), the SNES comes in very low with just three of the things available for general use which are known as A, X and Y. A is also known as the accumulator. Technically there are more registers in the CPU but they have defined functions, also parts of the hardware that handle certain tasks can also be known as registers (to save confusion if you want to call the former CPU registers and the others hardware registers then feel free).
Though there may be many instructions, the SNES is on the lower end at 91 or so (what counts and what does not can be debated a bit), it is usually a core set that most things will use (the maths, basic memory manipulation, something to compare and branch accordingly).
With it being such a direct translation of code it is about the only thing you can really convert between on computers. Trying to go from assembled code back to C/C++ is very hard (see the halting problem), though there are some options and some even higher level languages have even more options. I should say though that the vast majority of SNES games (basically everything older than the PS1) will be programmed almost exclusively in assembly in the first place.
This would mean the guide to assembly is really "find the CPU datasheet, there you go", in practice it is perhaps a bit easier as not everything detailed in the datasheet will be used, also the system, or in the case of the SNES even the game, itself may (will) have extras the CPU might not account for. With the SNES being marginally popular around here you do have a few options for the rest of it , the SNES programming book that the memory map was from is also good and is also good.
Assembly hacking is considered the hardest part of ROM hacking for a reason so do not be too put off if you find it hard at first.

*what is marketing, what is tech and what is something in between is a hot issue, or would be but most people consider it done to death. I usually roll with "what are the sizes of your general use registers" as how I determine the bit of a machine.

Anyway I am saying nothing that has not been said several times before in several other guides, most of which were written by people far more familiar with the SNES than I and done after actually thinking about it so I will leave it there.


Have you gone through the "Getting Started" section (under "Help") of this site? It's probably the best way for a newbie to get familiar with a lot of terms related to programming, debugging and romhacking in general, which starts with binary and hex editing. It has some easy practical examples with instructions you can follow to help you learn basic techniques.

Of course, they don't cover level editing, as it is most probably something very specific to each game. If you ask me, I'd say level editing is not the best starting point to learn romhacking.


Static stat editing (array somewhere) is a perfect starting point for learning romhacking. You just need to find the location of the numbers in the ROM and then you only have to change them. If level up stat gains are static, it will be either equally easy (array somewhere) or somewhat easy (code somewhere that does a bit of calculation). The difficulty of level editing depends on some things. As FAST6191 wrote earlier, the contents of a map are probably more complicated than that of stats (stats are just numbers that represent the numbers ingame!). Changing the terrain of a few tiles here and there might be quite easy, once you find the map data. But there may be starting positions of units, events and other such things.. if you want to have a complete control over that, you'll have to figure out how each part works there, and it will be the hardest part of this.

These are just my guesses of course, but usually games do things roughly like you'd expect them to. But as an example, the map data could be compressed. Then you would have to solve that part first, and it would also make the code harder to identify (compression code may seem incomprehensible if you expect it to be relevant map code).

I usually watch the RAM bytes to identify the purpose of some byte relevant to what I'm looking for, while the game is running. Alternatively I look for a pattern I know in the RAM (for example stats of the unit I'm controlling ingame, or stats of all units in the battlefield). Then I set a read or write breakpoint on an interesting byte to get close to the relevant code that I imagine there to be. The breakpoint stops the emulation when the byte is being manipulated (read/written). That's the most common thing I do when hacking.

Breakpoints are used to find relevant code. The amount of code executed is massive, so just going through all of it is very inefficient. It is possible to log all executed code though, and if you have a good idea of what you are doing, it can help. It is best to use breakpoints to get to a suitable starting point, and then break afterwards as soon as the code of interest has been executed. If you are lazy, you can just have one (execution) breakpoint (set on a code byte) in the game loop (that is visited once per frame, for example) and the resulting log will give you the codepath (with all the code logged) of the game loop in the particular game state. Just putting logging on without any limits will make the log file grow extremely fast and extremely large.

If you find something static like unit starting stats or whatever (I'm not familiar with this game) by searching the ROM (even though it has many numbers, surprisingly short sequences are unique), you can mod them without having to read any asm code or even without using a debugger at all.

Some numbers in the ROM are code, some are data. Code exists in sequences because the CPU executes it like that. Note that different code instructions have differing length, if you are going to edit the code manually. Also there is no extra space inside a typical code sequence, which is kind of a headache sometimes. Data is often in arrays.

edit: one more thing. it is good to note that the game has some initial values for stats. these are in the rom. once you have an unit/character in your party or whatever, the game has already loaded those initial stats to variables in a struct that represents that unit/character. another example is battle/scenario. it might be that data structure variables specific to the battle are loaded from either other variables (RAM) or from static ROM data when the battle/scenario is loading. overall it is good to be aware of the moments when the game loads variables, as you may want to trigger breakpoints at these precise moments (to figure out where variables get their values from between different game states and/or what processing is made). disclaimer: this is all speculation and it might not work this way but how else would it work.