The following is intended to give you the aspiring ASM hacker a look into my mind as I go about accomplishing relatively simple ASM hacks. We're going to start off with something very basic: finding the text read routine. Then from there, we'll work our way backward or forward to find the drawing routine and anything else I can think of along the way that a translation might need to really up the quality of the patch as a whole.
The game I'll be working on is Fire Emblem 1 (FE1). Why? For one thing at the time of this writing, it hasn't been translated by anyone. Hopefully this doc will help someone in giving this neat little game the proper treatment it deserves. For another thing, I've never looked at the game, so you'll be able to see how I go about attacking a game for the first time.
Before we get started, there's a few things I'm going to assume. One: That you can read kana or at least have a kana chart handy, because I'll be using the Japanese version in the following examples. Two: You have a decent understanding of the 6502's instruction set. You don't need to have every opcode memorized, however; as long as you have a reference doc on hand to consult, you should be okay. Finally, you're going to want a copy of Yoshi's NES Tech on hand. Preferably printed out and in front of you. Also, you might want to grab a copy of Disch's new (again, as of this writing) Mappers doc. As I haven't looked at the game yet, I'm not sure which mapper (if any) it uses, so you'll want to be prepared.
As far as specific tools go, I'll be using FCEUXD SP 1.06. The only other thing you'll need is a text editor capable of handling large files. Notepad won't cut it. I personally use TextPad, which you'll see later on when I need it. With all of that out of the way, it's time to start the show.
One final note: Going into this, I have about 2 or 3 years of ASM experience under my belt or so, but I am going to try my damnedest to think like I did when I first started tackling ASM work. For what it's worth, Dragonball Z: Assault of the Saiyans was the first game I ever cracked at the assembly level. I was 15 or 16 when I started and had no prior programming knowledge. Hopefully that's a little encouraging to you guys who are stuck in the "I gotta know a high level language before I learn assembly" mindset.
Beginning of the End: Starting From Scratch
As I mentioned at the beginning of this doc, I'm going to start by finding the text read routine. By text read routine, I mean the code that is responsible for "reading" the text from ROM, deciphering any control codes and then passing the data onto the code responsible for drawing the text on the screen. The most reliable way of attacking a problem is by first establishing two things: what I know and what I want to do. Throughout this doc I'll begin each task by listing these two things. An example:
What I Know:
Anyway, before I go any further, we need a string to use. Fire up FE1 and play until you come to the first string of dialogue:
The NES is a tile-based system. What that means is that instead of a screen basically being made up of hundreds of single pixels laid out side-by-side, the picture you see on your screen is actually made up of little squares of pixels. Think of it as a grid. The screen is composed of 30 rows of 32 8x8 tiles a piece:
A screen is composed of two separate, but interconnected entities: the tiles (Pattern Tables) and the tile map (Name Tables). The tiles are the actual 8x8 graphics, which are drawn on screen. The tile map lists which tile goes where on the screen. You can think of the tile map as being a grid. This "grid" is laid out in memory so that each tile takes up one byte, the reference number of the tile that is to be drawn in that square. So, instead of drawing the entire screen out in memory, we have the tiles over here in the pattern tables, assign a unique number to each tile, and then have a list of which tiles we want to use over here in the tile map.
I guess an example is in order, no? Let's use the above screen from FE1. First we'll take a look at the tiles and see how they're stored separately from the tilemap. Open up the PPU Viewer (Tools -> PPU Viewer). You should now be looking at something like this:
As you can see, none of the tiles used on the screen you see on your left are laid out in the same order in the PPU Viewer. That tell's us something: the order of the tiles doesn't have any bearing on how they're drawn on screen. That's important, but I'll get into that shortly. In the meantime, let's see if we can't figure out how the tiles to draw are, well, drawn.