FIRE EMBLEM:

ULTIMATE TUTORIAL
Welcome to my “ultimate” Fire Emblem hacking tutorial, dedicated towards hacking the
GBA Fire Emblem games. Don’t say I didn’t warn you: this tutorial is massive and it has tons of
details. Although this tutorial is a bit inclined towards Fire Emblem 7: Blazing Sword, the
information can usually apply to the other games. However, this tutorial will help most for FE7
hackers as it IS FE7 oriented. I will try and add details on the differences between modules and
offsets for different games when I can (the tutorial is already really long as it is).

Downloads:

HTML Version (Online)

DOC Version
PDF Version

Last Significant Update: March 27th, 2013

Background Info (Not necessary to read): Anyhow, I’m a 4-year or so Fire Emblem
hacker who is most commonly known by Blazer. My original username was Fire Blazer as in, one
who starts a fire by setting something ablaze, but that was kinda lame, so now I just go by
‘Blazer’. Anyway, I’ve made several Fire Emblem hacks. My biggest ones are Prince of Durand
(now dead) and The Last Promise (now finished!) but I’ve also made other hacks like Fire
Emblem: Shining Armor, Fire Emblem: Sacred Contention, Fire Emblem DS: Evil Version, Fire
Emblem Wars, Fire Emblem Rebirth, Fire Emblem Prisoner of Darkness, and some other minor
ones. I was also the lead manager/hacker of the Fire Emblem 12 Translation Project for part of
the time with a team of other dedicated people (who did more than I did, lol).

Contact Info: Because I no longer do modding and I’ve been getting far too many e-
mails, people pestering me, etc., I have removed my contact info. Please do not attempt to
contact me anymore. If you need help with hacking, please go on public forums where various
hackers can help you as opposed to… no offense, but pushing the burdens of your personal
projects on me (I know I’m evil for trying to conserve some of my free time).
Website: [Link] Forums: [Link]

Youtube: [Link]

Disclaimer: I do not have any rights to Fire Emblem, Intelligent Systems, or Nintendo, nor do I
claim anything by writing this tutorial, etc., I am just a humble video game player.

Please do not post this tutorial anywhere but the Fire Emblem Shrine. If I want it to be on a
website, I will post it there myself. Thank you for your understanding.

Please read the “Epilogue” at the end of this tutorial for more details on using and sharing the
Ultimate Tutorial.

Update Log:

July 8th, 2010 – I’ve remade the tutorial from near scratch (but included parts of former
tutorials as well).

August 19th, 2010 – Updates, added more chapters (sorry, I forgot to record which things I
updated).

February 19th, 2011 – More updates/chapters (see above).

November 6th, 2011 – Chapter 26 has been slightly updated. Chapter 45 and the Epilogue have
been majorly updated. Added new JFP patching chapter, and renumbered chapters past it
accordingly. Started and finished IPS, UPS, JFP, and XDelta patching chapters, as well as the
Nightmare Module Format chapter. Also revised chapters 72, 73, and the final chapter. Only
chapters 59-61 remain, which will most likely be finished in the next update.

November 7th, 2011 – Finished chapters 60 on weapon icons and 61 on map sprites in one fell
swoop. Then, after several hours, finished chapter 59 on custom spell animations. This means
that the tutorial is now complete—all chapters are finished. Any future updates will likely only
be revisions, adding small details, updates, and adding more information to the archive chapter,
chapter 72. Thanks for reading and waiting so long for this tutorial’s completion. I hope it helps
many people make awesome hacks! – Blazer

June 7th, 2012 – Minor fixes here and there.

December 4th, 2012 – More fixes and updates and whatnot.

March 27th, 2013 – Minor fixes, added a chapter on ASM hacking to the end, making this
tutorial well over 300 pages.
With that, it’s time to start my tutorial!

Table of Contents:

Prologue: Bare Basics

Chapter 1: Key Terminology & Abbreviations

Chapter 2: Using Nightmare Modules

Chapter 3: File Management

Chapter 4: Pointer Tables

Chapter 5: Battle Animation Editor

Chapter 6: Character Editor

Chapter 7: Class Editor

Chapter 8: Item Editor

Chapter 9: Spell Association Editor

Chapter 10: Stat Bonuses Editor

Chapter 11: Promotion Editing

Chapter 12: Map Sprite Editing in Nightmare

Chapter 13: Movement Cost Editor

Chapter 14: Terrain Stat Editor

Chapter 15: Portrait Editor Module

Chapter 16: Battle Palette Reference Editor

Chapter 17: Arena Class Editor

Chapter 18: Boss Music Editor

Chapter 19: CG Editing – Custom Cutscene Graphics

Chapter 20: Lyn’s Ending Editor

Chapter 21: Tutorial Editing/Getting Rid of the Tutorial

Chapter 22: Legendary Weapon Editing

Chapter 23-24: Music Insertion Tutorial (ELF Method) & Documentation

Chapter 25: Music Editing with Zahlman’s Song Editor (OUTDATED)

Chapter 26: Exporting Music with GBA2MIDI

Chapter 27: Battle Background Graphics

Chapter 28: Music Array Module

Chapter 29: Sound Room Editor

Chapter 30: Chapter Unit Editing with Nightmare

Chapter 31: Death Quotes

Chapter 32: Event IDs

Chapter 33: Battle Conversations

Chapter 34: Triangle Attacks

Chapter 35-36: The Animation Modules & Repointing Tutorial

Chapter 37: Support Editing

Chapter 38: Miscellaneous Nightmare Modules

Chapter 39: Loading FEditor Adv

Chapter 40: Text Editing with FEditor Adv

Chapter 41: Portrait Formatting & Preparation

Chapter 42: Portrait Insertion with FEditor Adv

Chapter 43: Locating Palettes

Chapter 44: Editing Palettes

Chapter 45: Working with GBAGE

Chapter 46: Chapter Data Editor

Chapter 47: Map Creation

Chapter 48: Map Insertion

Chapter 49: Event Assembler Basics

Chapter 50: Events – The Layout

Chapter 51: Events – The Event Codes

Chapter 52: Event Construction

Chapter 53: Map Tile Changes

Chapter 54: Chapter Creation Finishing Touches

Chapter 55: Importing Tilesets

Chapter 56: Animation Importation

Chapter 57: Custom Battle Animations – Frames

Chapter 58: Custom Battle Animations – Scripts

Chapter 59: Custom Spell Animations

Chapter 60: Weapon Icons

Chapter 61: Map Sprites

Chapter 62: Proper Betatesting

Chapter 63: VBA’s Tools

Chapter 64: Other VBA Options

Chapter 65: Recording Videos & Sound

Chapter 66: Fixing the Desync with VirtualDubMod & Video Rendering

Chapter 67: IPS Patching

Chapter 68: UPS Patching

Chapter 69: JFP Patching

Chapter 70: XDelta Patching

Chapter 71: Nightmare Module Format

Chapter 72: Miscellaneous Information Archive

Chapter 73: Useful Links & Websites

Chapter 74: Bonus – Assembly Hacking

Final Chapter: Credits, Thanks, and the Epilogue

Prologue: Bare Basics

Before you start hacking, you need to know some basics. I’ll be as brief as I can.

Think of a ROM as a game file. It contains the data for the game in it. When you play the game
and save, save files are created. They contain data about where you are in the game, what stats
there are, what weapons you have, etc.

An emulator emulates—imitates—playing the game on the actual system. So instead of playing

your ROM on a Gameboy Advance, you’d play it on the computer through an emulator, which
acts like a Gameboy Advance, but with more features.

The system has some limits to it. There is a limit to the number of colors you can use, a limit to
the # of layers, a limit to the # of tracks a song can have. This is the hardware’s limits—if you
don’t want to deal with these limits, then you are better off hacking a greater system, like the
Nintendo DS, or making your own game through something like RPG Maker.

That’s about it for the basics.

Chapter 1: Key Terminology & Abbreviations

If you want to follow along hacking discussions, tutorials, and understand what someone is
saying when they are answering one of your questions, you’re going to need to know some
terminology. They may also use some abbreviations as well. Here’s everything I can think of:
Note: These are not literal or exact definitions. I define them so that a person can understand
them and their purpose. Please do not contact me to correct me on the actual meaning of a
word. Thank you for your understanding.

- ROM – Read-Only Memory, the “game file”

- RAM – Random-Access Memory
- Emulator – plays a game, imitating playing on the actual system
- GBA – Gameboy Advance.
- NDS – Nintendo DS.
- DS – short for NDS… lol.
- Hardware – we’ll just say it’s the ‘system’ the GBA uses to interpret data found from a
cartridge or ROM.
- Cartridge – the actual game as it is bought from a store.
- Save file – contains save data for the game
- Savestate – contains save data for a specific point in the game. One can come back to
this moment in the game through a savestate.
- ASM – assembly, the programming for the game
- TSA – No one seems to knows for sure what it stands for. Use your imagination. It’s also
called map data. Its purpose is to take a bunch of mixed-up disorderly graphics and
make some sense out of it so that when you see the graphics in-game, they look nice.
It’s a sort of “layout” for graphics. Hard to explain.
- Debugger – a program that helps debug or a game, or search for bugs, find the cause of
them, and fix them. It’s also used to find other things though.
- Debugging – the act of using a debugger for its said purpose.
- Hacking – editing a ROM.
- Modding – another term for hacking, less juvenile I suppose.
- Formatting – preparing something to be inserted or used
- Patching – applying changes to a game.
- Patcher – a program that does patching.
- Utility – a tool.
- Text – words, characters, script, all types of writing.
- Graphics – ‘pictures’, ‘images’, visual aspects of the game.
- Frame – a still picture, one part of an animation.
- Animations – ‘moving’ pictures—frames put together to give the appearance of
something moving.
- Compression – a way to scrunch up data as to save space.
- LZ77 – A type of compression. Used with graphics, TSA, palettes, and other data.
- Huffman – A type of compression. Used in text.
- RLE – Run-length encoding. A type of compression that saves space by scrunching up
strings of data.
- Strings – hexadecimal bytes one after another.
- Hexadecimal – “Base 16”, a way to count, essentially. To denote hexadecimal, one can
use various prefixes, such as ‘0x’ and ‘$’. The basic counting is as follows: 0x00, 0x01,
0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
0x10. For simplicity purposes sometimes people are lazy and do not put a ‘0x’ before 0-
9, since the decimal and hexadecimal values are the same.
- Decimal – “Base 10”, another way to count. Most people are familiar with this.
- Binary – “Base 2”, another way to count, sort of. Only uses 0s and 1s. Google for more
info on binary (I RARELY use it).
- MS – Microsoft
- Converter – something that converts one thing to another type of thing. For example,
MS Calculator can convert hexadecimal to decimal and vice-versa.
- GBAGE – GBA Graphics Editor, the best GBA graphics editor for uncompressed and LZ77
data, made by Nintenlord.
- EA – Event Assembler, used to edit and insert events. The best way to edit events.
- NLZ-GBA – an older program similar to GBAGE, but outdated.
- unLZ-GBA – an obsolete graphics editor that I probably shouldn’t even mention.
- Text Editing Suite – an obsolete way to edit text.
- FEditor Adv – the best way to edit text, animations, and portraits. A program by Xeld, a
veteran Fire Emblem hacker.
- Song Editor – A program by Zahlman that can rip and insert songs that use the Sappy
engine.
- Sappy engine – a way that Fire Emblem and other GBA games can interpret music data.
- Sappy – it is also a program that is somewhat obsolete that was used to insert music.
- MIDI2GBA – a program used to convert MIDIs to GBA data.
- [Link] – a program used to convert MIDIs to GBA data and then put it inside a ROM such
that one could listen to the song by emulating said ROM.
- MIDI – music file that pretty much says what instrument to use to play what notes of
what kind. A simple music file that tells what to play as opposed to a recording (WAV).
- WAV – a recording of sound waves.
- MP3 – a compressed WAV.
- Sprite – a graphical object (can’t think of a better way to say this). Usually refers to
portraits or battle graphics (the characters that you see move in animations) but can
also refer to other graphics.
- Backgrounds – background graphics that don’t really move.
- Map sprites – refers to the overworld sprites that a player moves on the map.
- Hex editor – a program that edits data in hex (and often includes an ASCII editor to the
side).
- ASCII text editor – a text editor that edits text in ASCII ‘format’—google for more
information. Standard for many things. Fire Emblem uses this, but it compresses the text
with Huffman (not that you needed to know that).
- Offset – a place in the ROM denoted by a number. For example, the song table is
located at 0x69D6E0.
- Hex – short for hexadecimal.
- Byte – one ‘unit’ of editing. Corresponds to a number. Bytes can go from 0x00-0xFF (0-
255 in decimal).
- Bits – smaller than bytes. Google.
- Word – 4 bytes put together. Common input. Also the size of a pointer.
- Half-word – two bytes, half a word.
- Pointer – a word that points to some data. In ROMs, it has a prefix of 0x08 to it because
the hardware accesses all ROM data at 0x08000000.
- Little endian (byte reversal)- Reverses bytes. 0x12345678 becomes 0x78563412.
Practice makes perfect. The easiest way to do this is to split up words into bytes.
- Big endian- google it, not really too important for you to know.
- Word-alignment – Aligning data by the word. Is recommended all the time, but in some
rare cases, isn’t necessary. That means that data should start at an offset that ends in
0x0, 0x4, 0x8, or 0xC. 0x57120C is word aligned. 0x571205 is not. Think even/odd,
except only the values mentioned above are even, and everything else is odd. XD
- Table or Array – look up what an array is. XP. I really can’t explain this—you’ll have to
figure out yourself along the way.
- Nightmare – a program that edits data tables.
- Modules – files with information on what data nightmare should edit. Also called
“Nightmare Modules”.
- NMM – stands for Nightmare Modules.
- Nightmare 2.0 – a new version of Nightmare recreated from scratch by Xeld. Has more
features than the original Nightmare along with some fixes.
- ZIP archive – a way of compressing files. It takes a bunch of files and puts them into one
archive. The files can later be extracted (taken out) from it. It is a very common format.
This is something on your computer, not used in-game. It’s used to share lots of files
without having to download each one individually.
- RAR Archive – Same as above, but better. Also less common. Requires winRAR to use.
- 7zip Archive – Supposedly the best file archiver there is, but not used as much, and thus
less convenient. Requires 7zip or winRAR to use.
 - Java – google it. Is required for FEditor Adv to work (as well as some other programs like
Nightmare 2.0).
- Net framework – required for Nintenlord’s various awesome programs to work. The
alternative for non-Windows users is Mono.
- Tilesets – sets of tiles (lol). It’s what is used to make a map.
- Mappy Map Editor – the main program used to make maps.
- MAR Array File – a file that can be exported from Mappy. It’s used in conjunction with
the MAR Array Inserter to insert maps.
- MAR Array Inserter – inserts maps.
- Repointing – making a pointer point to something else. Also involves moving data.
- Expanding – adding space/room for editing. Making something larger.
- Kilobyte/Megabyte/Gigabyte/ - KB, MB, and GB, google these and make sure you know
them. Just bigger ways to count bytes.
- Palette – a range of colors. When one talks about a palette he’s talking about the colors
used in some sort of graphic or art. Most graphics only use 16 colors, including the
transparent color, but on occasion more colors are used (for things like CGs).
- VisualBoyAdvance – most people’s emulator of choice, almost always referred to as
“VBA” for short.

That’s all I can think of for now. Anything else I’ll mention later in the tutorial. I think it’s
enough definitions for now, anyway.

Chapter 2: Using Nightmare Modules

Nightmare is useful for editing a lot of things. The first things a person thinks of are stats,
growths, and classes, but it can do more than that. Each game has different modules though.
Fire Emblem 7 has the most modules, for example. And FE8 might have some modules for say,
the Valni Tower, which FE7 won’t have. That being said I will go through how to use as many
Nightmare modules as I can.

First, you need to get your clean Fire Emblem 7 (U) #1235 ROM. (U) is for U.S.A., #1235 is the
ROM #. I nor anyone else can help you with this, so you have to be self-sufficient here. If you
know how, you can always rip it straight from the cartridge. I don’t suggest you download any
ROMs unless you have the original game either. :\

To get Nightmare Modules as well as everything else you’ll need to hack, I suggest you go here:
[Link]
I upload anything that I think might be useful to someone on that site. Just use the menus and
search until you find it.

Once you’ve downloaded them, you have to extract the files. winRAR can extract ZIP, RAR, and
7ZIP files, so you might as well just download that and install it. Then right-click and hit “extract
here” or “extract to ‘X FOLDER’” on the Nightmare Modules’ file and some folders will pop up.

Navigate to the folder with your stuff. If [Link] (the actual nightmare PROGRAM) is not
included, you can also download that off of the website separately.

Double-click Nightmare to load it. Go to File-> Open Rom… or Ctrl+O and then locate your
game. Select it. Then do Modules-> Load Modules and select some modules you would like to
use. Nightmare modules have the .nmm extension to them. If you want, you can just load a ton
of modules.

Once you’ve loaded your modules, you’re ready to start editing, technically. However, I’m going
to go through some of Nightmare’s (the original Nightmare’s, NOT Nightmare 2.0’s) menu
options.

File-Open ROM opens the ROM, of course. Do this BEFORE loading your modules.

File-Close ROM closes the ROM. I actually suggest just closing Nightmare and then reloading
Nightmare whenever you want to open another ROM.

To save changes, you must first hit “apply changes” (under the File menu) to whatever area you
are changing. Easier than that, just hit “enter”. To save all of your accumulated changes, do
File>Save ROM, or just do Ctrl+S.

To unload a module and take it off of your list, do Modules->Unload Module.

“Link Rom to Modules” makes it so that whenever you load that ROM, it’ll automatically load
those modules. However, if you move or rename the ROM or the modules, it won’t work, and
will instead give an error message.

The other options aren’t too useful, so I wouldn’t bother with them.
Now, if Nightmare isn’t working for you, there are several things to look out for:

- Make sure you are applying your changes correctly

- Make sure you open the right ROM
- Make sure if you’ve linked ROMs and modules together, you don’t move or rename the
files (it’ll mess it up)
- Make sure you open the right modules for the right game, and that they are compatible

Here are some basic Nightmare issues. After the issue are a list of numbers that tell which
things to look at. If there is another issue, it’s possible one of the mentioned things applies to
your problem as well.

1. Check if you have the right ROM #- 1235, the American version.
2. The ROM is unzipped, meaning, it's a .gba file and not a .zip file. Right-click and extract.
3. Module is not extracted/unzipped. Right-click and extract. Download WinRar if needed.
4. Check if files are updated to the most recent ones.
5. ROM is a .gba file.
6. ROM may need to be expanded.

"The stats are absolutely crazy! Lyn has -128 speed!"

1.
4.

"The Module and ROM are not compatible."

1.
2.
3.
4.
5.
6.

"It's just not loading. It says I'm trying to crash Nightmare."

2.
3.
5.
Now, about the different aspects:

At the very top is what module you are using.

Below that is a list of the different entries in the module you can edit. Usually the entries are
labeled so that you know what you are editing.

Below that is the actual data to edit. There are different types of slots. Dropdowns allow you to
choose from a list (although sometimes those lists limit you to only certain values). Othertimes
you can edit data in decimal—for example, character stats are in decimal. If it was in
hexadecimal, I’m sure it’d confuse some of you a bit more.

There are also signed and unsigned bytes. Some values can go up to 255. Other ones become
negative once they reach 127 or so. I really forgot the details of signed/unsigned bytes but
because of this and other reasons, stats can’t go to like 255.

Whenever you make a change to an ENTRY, you have to press ‘enter’ to apply changes. When
you switch entries (say you were editing Eliwood and then you go to Lyn, it’s the same module
but a different entry) you have to press enter again for the new changes you make. (You press
enter AFTER the changes, btw.)

When you’re done with all your changes, then you can press Ctrl+S.

Here’s an image to help with the Nightmare layout:

That’s pretty much all you need to know about using Nightmare in general. Good luck with your
Nightmare editing!
Chapter 3: File Management

In order to be a successful hacker you need to have a lot of good management.

To start, try and use as few programs at once as possible. What you can’t do is use one program
to edit something, use another program to edit it, and then go back to the 1st program and edit
it again. It’ll undo changes from the 2nd edit because the 1st program doesn’t know that the 2nd
program edited it.

What I suggest doing is when you’re done making edits with a program, save, and then exit out,
and go to another program. This helps avoid confusions between programs.

Note that HxD, a hex editor, reloads a file from its source, so it DOES recognize edits made in
between, this is kind of an exception.

Also, when a ROM or some other file is being edited, you can’t edit it with another program or
the other program will give an error. As said, finish up what you’re doing with one program
first.

Another key to file management is to organize your folders and the such. Make a hacking folder
and divide that into a few more folders—one with programs, one with CLEAN ROMs (unedited),
one with hacks, one with other files, etc., it really helps.

Most importantly, BACK UP YOUR GAME. After every major change, BACK UP YOUR GAME.
Before you apply some patch to some game, BACK UP YOUR GAME. Before and after you insert
graphics, BACK UP YOUR GAME. You never know when something crappy might happen. Have a
folder JUST for back-ups and label your back-ups with the date, and maybe even what you did
before or after that back-up. For example, if I was about to insert some portraits, I would back-
up my game, call it “[Link]” and store it in a folder. Then I know what I
did after (inserted portraits), I know it’s a back-up, and when I took it.

If you have good file management then you’re on your way to making a big successful hack. ^_^
Chapter 4: Pointer Tables

Note: This is a copy/paste from my old hacking tutorial.

What is a pointer table? Start by opening your hex editor, and selecting Go to, jump, or
whatever sounds like that. I’d like you to go to c9c9cc for this.

At 0xc9c9cc you’ll find pointers. It’ll look like a bunch of numbers and 08’s for that
matter. If it doesn’t, then you are either at the wrong place or in a wrong ROM. To make
sure, it should look like this.

Now that you are there, you are probably confused with all these “pointers”. I call this
the Event Reference Table, although since it has more than events, you can call it the
Reference Table I suppose.
 A pointer is reversed by little Endian, that formatting thing I talked about. So the first
pointer 4CC73408 is 0834C74C. The 08 is added onto every address in the game. I’ll get
into that later, but for now, just sort of ignore it. You won’t need to worry about it too
much until you get into ASM (assembly) or expansion.

Now this is the great table that you will use to repoint things. Repointing is changing the
pointer to somewhere else. Now let’s say I repoint to extra space, where this is tons of
free space to do whatever. Then I could put tons of information there, or rather much
more information than the game normally allows. For instance, you are limited to
around 150 weapons by editing the data that’s already there. But if you have more
space, you can add more items. Repointing data to this new space is expansion.
Hopefully it’ll get clearer as the guide continues.

I hope that was useful for you!

Chapter 5: Battle Animation Editor

Note: This is a copy/paste from an old tutorial.

For some reason, this confuses some people. This isn’t fully custom animations, this is
the basic animation thing using Nightmare.

1. Load up Nightmare, the game, and the Custom Battle Animation module and the Class
Editor. It should look like this.
2. Now for each animation you need to select the weapon type. Let’s say we are making a
mercenary animation. Then select All Swords (already selected).
3. For the second slot make it All Weapons because it is for all swords, not just one sword.
Otherwise use Custom Animation for a Weapon.
4. Select the animation to use.
5. Don’t touch the separator. Then do the same thing for the next 3 slots, and a separator,
continuing to however many you need. Then enter and ctrl+s and you are done with
that part. It should look like this.
 Now the game needs to know about this animation.

6. Go to the class editor.

7. Go down to the Battle Animation Pointer.

Change that to 0x8POINTER. 0x8 is the beginning of any pointer (except for expansion),
and the pointer would be the number at the top of the custom battle animation pointer.
Which is this one.
So that would be what you put in. 0x8FFF800. Now enter and ctrl+s again, and play as
Eliwood. Should look like this.
And what happens in-game?
 Ah! He’s messed up! That’s because of his palette, unfortunately. Remember, that this
changes the class animation and not the character animation. For a custom character
animation you either need a class just for them, or a custom battle sprite which will also
be explained later (this is another type of custom battle sprite).

That’s all for today. =)

Chapter 6: Character Editor

I will do a run-down through this module.

At the top is a list of characters to edit. Generic units lack portraits, chibis, amongst other
things. The tutorial characters are used in Lyn’s mode, while the non-tutorial ones are used in
Eliwood’s/Hector’s mode. Lyn’s mode characters don’t have supports, but they can have
them—you just have to add the support pointer to them.

IIRC unit 0xFB is labeled “Enemy” and is the generic enemy unit used in the arena, so I suggest
that you don’t edit it. I would also not edit “Wall” or “Snag” at the end, as well as any other
character that seems fishy or special (like the Fire Dragon, don’t edit him into something else—
he is a special character).

Now, onto the actual data:

- Character name – the index for the character name text. Type it into FEditor Adv.
- Character description – same, but for description text.
- Character number – used to reference the character. I suggest you don’t edit this.
- Class (support viewer only) – only affects the class shown in the support viewer.
- Portrait – the portrait used for the character.
- Mini-portrait – default uses the portrait’s chibi, everything else is for generic enemies.
- Affinity – self-explanatory.
- Character number 2? – don’t edit, just to be safe.
- Level – doesn’t affect the actual level. It affects autoleveling, I think. You’ll find more
about this when using the Chapter Unit Editor or Event Assembler when you edit units.
- Base stats – these are added to the class stats to get the FINAL character stats. Stats can
be negative but might glitch if they are unless you use FEditor Adv’s autopatch.
- Con bonus – same, it’s added to the class bonus. It can be negative as well.
- Weapon levels – the weapon levels the unit has. Unless you’re hax like Athos, you can’t
have more than 1 S level weapon—try and figure out how to do it like Athos if you want.
 Also, if the class has a base weapon level, it is used unless the character weapon level is
higher.
- Growths – self-explanatory, aren’t added to class growths, they are as you see them. For
player characters, these are used; for enemy characters, class growths are used. The
max a growth can be is 255.
- Palette – which palette to use. Generic default colors are for generic enemies.
- Custom battle sprite – gives the option to use a custom battle sprite/animation, but
NOT use a custom class.
- Character abilities – they are all pretty self-explanatory. You can combine values to have
multiple skills from one list. For example, to have a character that could use steal and
thief key (but not have the class ability to use it), you would do 0x04 + 0x08 = 0x0C.
- Supports Data pointer – a pointer to support data… self-explanatory I suppose. 0x00
means no supports.

Chapter 7: Class Editor

This module edits class data, NOT what character is what class. Just wanted to make that clear.

There are 3 ‘unused classes’ at the end that you might think you can use, but probably
shouldn’t be used. Apparently they actually are used for something, and what’s important is
not what it’s used for (because I’m not sure myself), but the fact that they aren’t free to be
edited and all. There are also some classes that are only used in cutscenes as NPCs (like the
Peer class, Elbert’s class) and some unused female classes. Some classes don’t have animations.
For example, there is no female Myrmidon animation, and the Paladin (F) does not use
Isadora’s animation by default.

Rundown:

- Class name/description – text index to be used with FEditor Adv.

- Class number – class reference number. Better to not be edited.
- This class promotes to – obvious…
- Standing map sprite – the map sprite used when you aren’t selecting the character. For
the moving map sprite, you have to edit it using the map sprite pointer table editor,
another module (with a somewhat long name).
- Walking speed – obvious, slow or fast.
- Default portrait – for the class, if there is no real portrait, what portrait is used. Typically
the enemy class card. Supposedly if someone has a custom class you can use this so that
their unpromoted class uses one portrait and their promoted class uses another
 portrait. It’s a cool idea, but I don’t know if it actually works, since I haven’t tested it
myself. XP
- Base stats – obvious.
- Max stats – the limit to what the cap can be. Without Xeld’s patch included in FEditor
Adv, the max is 31. To see how to get past that max without glitches, see FEditor Adv’s
documentation. Note that HP normally cannot go past 60 for allies either. Enemies can
go higher though.
- Class relative power – affects experience. A lower number means more experience.
0x03 is like the default.
- Class growths – IIRC affects enemies and how they grow. I forgot for sure.
- Promotion bonuses – stats added when a unit promotes. For the CON bonus, it’s the
difference between the promoted and unpromoted class.
- Class abilities – self-explanatory. They can be combined as well (see the character
module chapter for more info).
- Base weapon-levels – the “minimum” weapon levels that a character of this class must
have. Can’t go lower than this.
- Battle animation pointer – a pointer to the data that says what animation to use for
what weapon. You can edit this with the battle animation editor OR make your own
data with the custom battle animation editor.
- Movement/Terrain data pointers – you can edit these with the appropriate nightmare
modules. It affects what tiles a unit can move on and the terrain bonuses they get there.

Chapter 8: Item Editor

There are a few unused weapons/items and ones that aren’t obtainable without some bonus
requirements, so I suggest you replace these, because expanding this stuff to allow for more
item slots is tedious (mainly because you also need more space for weapon icons).

Run-down:

- Item Name/Description pointers – by now you should know what this is- text index.
- Item number – reference number.
- Weapon type – obvious.
- Weapon abilities – you can combine bytes, just as you can with character/class abilities.
- Stat bonuses pointer – points to stat bonuses, for example, Durandal gives +5 strength.
You can use the stat bonus editor to make your own stat bonuses, or go to the offset
mentioned in a hex editor to edit the data there.
 - Effectiveness – same as above, essentially. The pointer just points to a list of class
numbers that the weapon is effective against.
- Durability – uses
- Power – might
- Hit% - obvious
- Weight – obvious
- Critical – obvious
- Range – To get the range, the first bit is the starting range and the 2nd is the end range.
So 0x11 means only within 1, but 0x12 means 1-2 range, and 0x24 means 2-4 range, etc.
- Cost per use – uses x cost per use = actual cost (sell price is ½ of that)
- Weapon Rank – obvious
- Item icon – obvious
- Staff/Use Effect – from my experience this is tricky trying to get it working, so if you play
around with it and it’s not working right, there’s nothing you can do about it unless you
know ASM.
- Weapon effect – obvious
- Weapon experience – how much ‘experience’ the weapon gives towards getting to the
next weapon level. 1 is normal, 2 is high, 0 is nothing, and you can do 3 and on, but it’d
be a bit broken to have 3 WEXP.

Chapter 9: Spell Association Editor

This module controls what weapon has what animation. It’s mainly for magic weapons, tomes,
and staves. However other weapons have “blank” entries where the “animation used” slot is
set to 0xFFFF because there is no spell animation used.

Note that ‘spell animation’ can also refer to non-spell animations such as javelins and arrows. It
just refers to any separate animation associated with a weapon that isn’t actually apart of the
class battle sprites. I hope that made sense.

Run-down:

- Weapon – which weapon to use

- # of chars to display – 1 or 2, anything else will glitch (this one is obvious too)
- Animation used – also obvious
- Return to original position (map) – I suggest putting this on.
- Facing position (map) – unless it’s a staff, this should be towards the target
 - Enemy’s flashing color (map) – white is default for weapons, dark is for dark magic, red
is for fire magic, etc., just do what you think looks nice.

That’s all there is to it.

Chapter 10: Stat Bonuses Editor

All you have to do here is type the bonuses you want, then take the pointer at the top and type
it in the item editor. For example, the first entry is 0xFFF2A0 so in the Item Editor under “Stat
Bonuses Pointer” you’d type 0x8FFF2A0. That’s all there is to it.

Chapter 11: Promotion Editing

If you want edited promotions for the classes, use one of the custom pointer slots in the
Promotion Item Editor (in the dropdown where it says “Promotion Pointer”) and then go to that
offset in a hex editor and type the class numbers of the classes that can promote through this
item. Remember to save your changes in both nightmare and the hex editor and not to overlap
changes by having both programs open at once.

To change which class promotes to which class, there is a dropdown slot in the class editor.

Chapter 12: Map Sprite Editing in Nightmare

Note: I don’t know how this works in FE6 or FE8 for sure. This is for FE7.

The Map Sprite Pointer Table Editor module controls the moving map sprites. Each class has its
own pointers. The ‘animation pointer’ would better be called the graphics pointer as it is a
pointer to the actual map sprite graphics which you can edit in GBAGE. The other pointer is
from what I know more like an actual animation pointer—it tells like, how to work the map
sprite and its animation and crap. Sometimes when you import map sprites from other games
the animation will still not look good because of the ‘Another Pointer’ in which case you have to
import that data too.

Anyway, if you want to reuse a map sprite of one class on another class, simply copy the
pointers and paste them onto the new class’ slot in the module. That’s it.

Chapter 13: Movement Cost Editor

Note: The nightmare module is actually called ‘Movement Type Editor’ as of writing this tutorial,
but it’s better called what the name of this chapter is called, really.

This controls how many ‘movement points’ it costs to travel certain types of terrain. Think of
the movement of a class as a # of points they are allowed to use to travel. So if the value next to
a type of terrain is ‘1’ it just takes 1 movement. If it’s ‘2’ then it requires 2 movement spaces,
meaning a unit with 5 movement can only travel through 2 forest tiles because forest tiles
require 2 movement and 5/2 = 2.5, rounded down to 2.

If the value next to a type of terrain is ‘255’ then it is uncrossable because a unit won’t have 255
movement points.

There are offsets at the beginning of the name of each entry—use that offset to repoint
movement data. The pointer to movement data is located in the class editor.

Chapter 14: Terrain Stat Editor

Another very short chapter. It is split up into ground and air units. How/what to edit is very
obvious. Just know that Pegasus Knights, Wyvern Riders, etc. use the air movement—as they
are flying they are unaffected by most terrain and do not really receive bonuses. All other units
receive the standard ground bonuses.

The pointers to this data are in the class editor. That’s all you really need to know.

Chapter 15: Portrait Editor Module

There is a portrait module made by Ace that was used to repoint graphics and edit
miscellaneous stuff like frame positions and eye control. However, because of Xeld and
Zahlman, you can do everything this module can do in FEditor Adv.

Just some quick notes for those who are curious:

- FE6 does not have blinking frames

- Portraits and chibis are LZ77 compressed
- Mouth and eye frames are uncompressed data
- Sometimes the game has separate portraits—one with the eyes already open, and one
with the eyes already closed. Just a heads-up.
That’s all I have to say about this module.

Chapter 16: Battle Palette Reference Editor

This is a very useful module that tells the offset of the palette of a certain character/class. In the
character editor is a byte that affects the palette-that byte references this table, finds the offset
of the palette, and then loads the palette.

The good thing about this table is that it already has some empty slots near the end to use if
you need the extra palette space.

The actual offsets given are offsets to the LZ77 compressed palette data. If you want to edit it
real quickly, you don’t have to decompress the data to edit it. However, if you are editing the
data and you want to edit all 4 palettes—1 for each allegiance (including the P4 allegiance
located in the arena) then you can do so by decompressing the data using NLZ77 Compressor,
editing it like any other palette, and then recompressing it and re-inserting it.

One more quick thing. If you want to make it so that your edited palette works for all
allegiances, you should edit a palette of the same class as your new character. For example,
let’s say you are making a guy named David and he is a knight. His character data replaces Lute
from Fire Emblem 8: Sacred Stones. Well, here’s what you’d do. You’d “steal” the palette of
Gilliam, who is a knight, by going to the offset, copying the palette data there (palette data
starts with a 10, so with that clue you should be able to know when the palette data ends) and
pasting it somewhere else. Then repoint Lute’s/David’s palette to the Gilliam-replica palette.
Then edit Gilliam’s copied palette to whatever you want through a battle palette editing
technique. Save the edited battle palette and you now have a knight palette for David that will
work right on all 4 allegiances and not look glitch when David is an enemy or an NPC.

If you want to know how to actually edit battle palettes’ colors, you can find that in a later
chapter that I will make.

Chapter 17: Arena Class Editor

This is pretty simple as it only has one thing to edit (which class appears). The thing is, I don’t
suggest editing the ‘empty’ slots at all. This is because these empty slots are most likely
separators.

What do they separate? If I had to take a guess, I’d say they separate different modes, meaning
the first set of classes is for Lyn’s, the 2nd is for Eliwood’s, and the 3rd is for Hector’s.
My only other comment is that from what I remember, character 0xFB in FE7 (labeled as
“Enemy”) is the unit used in the arena. FE6 and FE8 probably also have some unit reserved for
the arena in their character editor, I just don’t know which one. That’s all I have to say about
this module.

Chapter 18: Boss Music Editor

Very, very simple to use module, but also very useful. I just want to note that you can’t have
allies have their own battle themes, to my knowledge. It only works if they are an enemy.
However, if you give one of your allied units a battle theme anyway, and then you fight them in
the arena, the ‘boss music’ may very well play. I haven’t actually tried this, so it’s just an idea.

Chapter 19: CG Editing – Custom Cutscene Graphics

Note: Currently FE7 oriented.

You want to make your own CGs to insert into a game? Well, here’s all you need to know about
making them as well as making use of them.

To start, let’s take a look at the CG Editor module I made. It’s just a table editor, but it can be
useful. The graphics pointer points to either A) graphics or B) a set of pointers that has more
graphics. The TSA pointers points to the TSA that says how to use the CG graphics and make it
into a full-fledged background. The palette pointer is kinda obvious—it’s the palette.

With that out of the way, let’s take a look at the alternate graphics pointer. Lyn mode CGs point
to a set of graphics. Take the first entry in the CG editor-- 0x8CED6D0. We’ll go to the offset
0xCED6D0 in a hex editor.
What’s highlighted is the set of pointers. It’s 10 pointers, 0x24 bytes (or 40 bytes). Each graphic
is actually a 240x16 piece of the entire CG. If you take all 10 pieces together (vertically) you get
a 240x(16x10) or 240x160 image. The size of the GBA screen is 240x160, so we have a full
background.

Why do Lyn mode CGs work this way? I can’t say for sure, but I have a good feeling it’s because
of the Lyn’s Mode Ending, which uses the CGs as a background. In any case, you can go to one
of the pointers and see the graphics if you want. I must admit it is a bit troublesome to use CGs
in this manner, which is why you may not want to actually replace these CGs unless you replace
them with black graphics (which is what I did in my hack Tactics Universe).

Now, there’s something the current version of the CG Editor is missing (at the time that I am
writing this—I may update the module later). It’s a byte that is a flag as to whether the CG
works like a Lyn’s mode CG or a normal CG.

Go to 0xCED888 in a hex editor. The byte you see there is 01. If it’s 01, it’s a Lyn mode CG. Else,
it works like a normal Eliwood/Hector mode CG. That’s all there is to it.

Some other quick notes:

- Palettes are uncompressed

- Graphics are compressed
- TSA is compressed
Alright. There’s something else I want to tell you about editing CGs. If you want a simple 16
colored CG, there is an easy way to do it.

Just make an image that is 240x160 in size. Load it into Usenti, a bitmap editing program
oriented for the GBA that you can find on my site. Hit Palette-> Requantize and type “16” to
make it 16 colors. If the image has too many colors to start with, it won’t look good, which is
why I suggest you use simple images.

You can also do something like a sepia tone or a one-color image—something that is like
grayscale, but tinted with a color, so that it is all red, all blue, etc.

This is a graphics editing thing, however, and I cannot help you with this. You’ll have to ask in a
graphics area how to do such an effect.

Anyway, once you get a 16 colored image, change the size to 256x160 using Usenti. The 16x160
portion on the far right that you just added should be the transparent part. Also, at the very top
left, there should be a pixel with the color that is going to be transparent. Said pixel will turn up
black in-game, but it can’t be helped (by me), unfortunately.
As you can see, I managed to save some quality by making the entire image red, but it’s still
kinda eh. On the right in the color box you can see I only have 16 colors (1 row). Although you
most likely can’t see it, at the very top left of the CG is a dark red pixel that is the SAME dark red
on the right. When I insert this CG, it’ll turn up black, of course.

Once that’s all done, save your image. Load the CG stuff with GBAGE-everything you need to
edit a CG is in the CG Editor module. I suggest editing an Eliwood’s mode CG, of course. Type in
the graphics offset and the ROMPalette Offset as it is in the CG editor. You don’t really need to
load the TSA for the image.

Hit “Import Bitmap” and select your graphic where it says “File”. Put in an offset for the CG to
be inserted and check the following stuff:
When that’s done hit “OK” and hit “OK” again. Now save with GBAGE (File->Save) and then exit
out.

There’s one last thing. We haven’t touched the TSA, have we?

Well, there’s a ‘trick’ of sorts with images that are 16 colors. The game already has some TSA
made to use with a 256x160 image that only has 16 colors. It’s offset is 0x50BE54. Open up the
CG Editor in Nightmare and type that under the TSA for your image (remember that since it is a
pointer, you type 0x850BE54). Then save.

Now all you have to do is test your CG in game.

…Wait, how to do that?

Well, you need to load the CG using events. The event assembler code to load a CG is-

Shows a CG picture
SHCG XX
XX = picture value

(Direct copy/paste from EA files)

To do it in hex, the code is D3 00 XX 00, not that anyone uses hex anymore… right?

I suggest putting fading codes before and after the CG to smoothen the transition. It’s kinda
necessary if you want the CG to look right.

FADI
SHCG 0xNN
FADU
STAL 0xFF

The above is an event to fade into the CG, load the CG “0xNN” (obviously put a real value
there), and then wait for time 0xFF (255) in who knows what units (frames?). You can put other
codes in between the fading codes, of course. I just showed the bare minimum.

There’s also a macro made by Nintenlord to make it easier:

 //Smooth changing to CG
#ifdef _FE7_
#define ChangeToCutScene(cutscene) "FADICG 0x10; SHCG cutscene; FADUCG 0x10"
#endif

All you have to do in your events is put ChangeToCutScene(value) and it’ll change to the
cutscene specified. Makes it slightly easier, I suppose. That’s it for events…

BUT WAIT!

There’s a nifty program that can help you insert CGs OVER 16 COLORS! AND THE METHOD IS
KINDA EASIER!!!

FEditor Adv has it with it. The batch file is called “Execute CG Maker”. Execute it and you’re
your original 240x160 CG image. It’ll ask where to save an image showing what the converted
CG looks like after it’s GBA-ification. I’m using an arena (shown below) so I’ll just call my new
one “[Link]”. Next you need to tell it what to call the image data dump. “arenadmp”,
“arenaimg”, or “arenagraphics” works. Something to tell you what it is, that’s all that matters.
Then you need to save the map data (Xeld calls it map data, but everyone else is so accustomed
to saying “TSA” that I just say TSA as well). Save it as something you’ll recognize. Same for the
palette data. Then you’re done.

Below is what my image looks like afterwards.

Pretty good, amirite? It uses more than 16 colors and manipulates the TSA/map data in a
complex way to do so. Thank Xeld for his program.

Now all you have to do is copy the data from each respective file into some freespace in your
ROM, and mark down each offset you insert it at. So for example, we’ll say I am inserting my
graphics at 0xD20000, my TSA at 0xD25000, and my palette at 0xD26000. I have them all
written down and labeled. I save my hex editor.

Then using the CG Editor module I repoint everything, making sure to add an 0x08 to the
beginning of each pointers (0x8D20000, 0x8D25000, 0x8D26000). Then I save with Nightmare
and test my ROM (I already went over how to load CGs).

It’s a bit of work, but making CGs is quite rewarding, and it’s easier than SOME stuff, that’s for
sure! Good luck with your CG making!

Chapter 20: Lyn’s Ending Editor

This module changes what text is used in the Lyn’s ending module as well as what character’s
data is used. You see, the ending shows a record of battles fought, won, and lost, and it gets
that from the character #. Depending on whether the character “died” (got injured) or not,
there are two different text.

Actually, there’s an error in the current Lyn’s Ending Editor (if you do not see this error in your
version, don’t worry about it). It says that there is an Injured Text for the Tactician, but from my
foggy memory, I think the latter text is actually for the female tactician, while the former text is
for the Male tactician. The game knows the male/female thing based off of what you chose
when you started the game and stuff.

The “Lyn Hilltop” text is just some text near the end that has a CG of Lyn on a hilltop. For
simplicity’s sake I made the whole module one entry.
There’s one more thing I want to say about this. When editing the text, there is a trick to it—
after each line on the text, you have to add a bunch of spaces. For whatever reason, this is how
the game knows to make a new line, and if you don’t add a bunch of spaces, the text glitches.

So your ending should look something like this, except you don’t need the words ‘space’ and
you won’t SEE the spaces, but the game will know they are there.

Gravyman, Saucy Boy (spaces)

(invisible linebreaks)
He served gravy to people (space space space space space space)
in all the kitchens of the (spaces)
world, disgusting people with (spaces)
his inferior cuisine. (spaces)

I don’t know exactly how many spaces you need after each line so I would just add as many as
necessary, really. Experiment, play around, and work it out.

One more chapter, down!

Chapter 21: Tutorial Editing/Getting Rid of the Tutorial

This is a frequently touched upon subject. I want to make this quick.

To get rid of the very basic tutorial events, you can A) use the Tutorial Editor nightmare module
B) use the Event Assembler or C) use some patch somewhere.

Method A:

Load the tutorial editor module for FE7. Repoint each pointer to an empty space of 4 00s. If you
don’t know of a space, you can type in 0x80000B4 because at that very offset are 4 kinda-
random-but-probably-important-for-something 00s.

Just do that for every pointer and bam.

Method B:
At the very top of events, before even the #include stuff, put DISABLE_TUTORIALS and the
Event Assembler should disable the tutorials when you insert your events.

Method C:

I don’t know where this patch is but it does the same thing as the stuff above. It’s just a patch
way. There is a ‘Tutorial Killer Patch’ I made but it gets rid of complex tutorial events as well.
However, it is reported as glitchy, but I have given up on trying to fix it after such a long time.

Chapter 22: Legendary Weapon Editing

FE7:

There is a nightmare module thanks to Xeld that can edit which weapons have the special stuff
that goes with the legendary weapons Armads, Durandal, Forblaze, and Aureola. It’s very
simplistic.

However, if you want to add more weapons to this list, you have to do some different stuff (you
can’t just expand it like normal). See this topic for more information--
[Link]

Chapter 23-24: Music Insertion Tutorial (ELF Method) & Documentation

This is a copy/paste from my music hacking tutorial I released. It tells how to insert music using
the “Elf Method” ([Link], a hex editor, Nightmare, and a few other things). It also tells how to
make a song loop and includes documentation.

This tutorial does NOT cover how to rip music from other games and import them, however.

This tutorial, created by me, Blazer, will guide you step-by-step on how to take a MIDI and insert it into
either Fire Emblem 6 or Fire Emblem 7. I have not made an instrument patch for Fire Emblem 8 so you’ll
have to either find some other way to hack music or bribe me into making one for FE8. :P

Tools Needed:

Required:

Music [Link]

Your MIDI, i.e. a song file ending in .mid

Midi2AGB/Midi2GBA*

Anvil Studio (or another good MIDI editing program, although Anvil is preferable)

HxD (or another good Hex Editing program)

A Fire Emblem ROM (or another GBA ROM—this tutorial is direct towards Fire Emblem hacking,
however)

Blazer’s Instrument Patch (found in tutorial)

NUPS

Optionals:

Sappy 1.6

Sappy 2005

*(Same programs, I’ve seen them under both names, I will reference it as Midi2GBA)

YOU CAN FIND MOST PROGRAMS AT HTTP://[Link]/

Part 1: Background Information

Before trying to insert custom music into Fire Emblem or any other GBA game, you should:

- Know how to manipulate a hex editor and its basic commands (go to, find, opening, saving,
copying, pasting, and editing)

- Know how to make patches as well as apply patches

- Use Visual Boy Advance to play ROMs, savestate test, etc.

- Know how to back-up ROMs. Backing up is very important. I will not constantly warn you to back
up your ROM, but I will on occasion—it’s up to you to do it.

Terms: (note: some definitions may have been simplified or otherwise defined as something else for the
sake of making it easier to understand, please don’t talk to me about technicality terms, I’m a casual
hacker and I don’t care for 100% accurate definitions.)

MIDI- a song file that contains all the tracks of a song.

Track- one part to a song, a track contains all the info about what a certain instrument should play. Each
track has one instrument and the track has all the notes for it.

Instrument- Digital instruments, an instrument is a sound or set of sounds to play. Acoustic Grand is a
type of instrument. The track would tell what sounds of the instrument to play, when, for how long, etc.
General Hex Editing Terms- This includes—offset, hex, byte, word, pointer, little-endian, header, etc.

Pitch- How high or low a sound is.

Octave- What set of pitches to use. A lower octave has lower, deeper sounds, while a higher octave will
produce higher pitched sounds.

Volume- The loudness, in this case, the loudness of a track or song.

Part 2: Downloading the Programs

Everything you need (excluding illegal ROMs, which btw, a ROM isn’t really a program) can be found at
[Link] simply navigate that site and download what you need.

The music list can be found in the documentation section. Anvil Studio and Mid2GBA can be found on
the Music Editors page, just as HxD can be found on the hex editors page. The instrument patch can be
found in the Patches section and NUPS can be found on the patchers page.

Finding a MIDI is up to you. Use google and [Link] to find a MIDI of a song you may
like or something. Don’t ask for help with this.

Part 3: Preparing Your MIDI

Before you insert your MIDI, you need to make sure it is properly prepared. This includes quite a few
things. Ease up your mind, it’s pretty straightforward and you use a easy program to help you with it.

Load up Anvil Studio, and then load up your MIDI file. In the middle you should see a bunch of tracks.
The middle part is where all your tracks and their information are. To the left is the track name, then the
type it is, and the instrument used (example, Acoustic Grand, Violin, String Ensemble 1, etc.).

Step 1: Minimizing Tracks

Having more than 10 tracks in a song will probably screw things up somewhere down the line. I wouldn’t
even try and do it—I remember a friend telling me he tried to and it failed.

One thing to do is delete any tracks without notes. It will say to the left of the play/pause buttons “no
notes” if a track doesn’t have any notes. Sometimes there are redundant tracks labeled “Copyright” or
something. If there are any, go to Track->Delete at the top of the menu.

That shows a redundant track named “Copyright by Bla Bla Bla” and at the top it says “no notes”.

If you still have more than 10 tracks, you should find another MIDI. Sorry but, there are limits in life.

Step 2: Truncating Your Song

Some songs repeat within themselves. Like a song may be 6 minutes, but at 3 minutes it just repeats
itself all over again. Well, in-game, this uses up some space and for maximum efficiency, you’d best get
rid of the repeat. Do so by finding out exactly where the song repeats and then going File->Truncate
Song-> Delete from Current Position to End.

Going to View-> Composer may help you find the place where it repeats—otherwise just listen to the
song and stop once you hear it, then click around in the track area until you get to the point where it
repeats. Then do as I say and TRUNCATE!

Step 3: Track Timings

In order for your MIDI to properly repeat in-game, all of the tracks need to be aligned. Otherwise one
track might go ahead and play itself before another track has finished its rounds, and then once it
repeats in-game, you’ll be like “WOAH THE SONG IS ALL MIXE D UP WHAT DO I DO?!!!!”.
I got this trick from someone else—I believe it was Charon the Ferryman, a member on my forums. Go
to View-> Composer if your composer scroll isn’t loaded already. Select the first track, then click in the
composer area. Hit “page down” on your keyboard (or if you don’t have that, do it slowly by holding the
right arrow) until you reach the end of the track. Making sure you are at the end, look at the top.

Make sure the time and the duration are the exact same. If it isn’t, then add rests by clicking the “Insert
a Rest” button until it is.

There’s the button if you can’t find it. Now if your song’s duration CHANGES, that’s also bad. Press the
backspace button to delete rests. Usually one backspace will get it to the perfect timing. In my case, the
duration went to 3:03:07 due to an extra rest, and then I pressed backspace once, and now it is back to
3:03:04.

Click on the next track (simply click on the row of the track underneath the column named “Track
Name” if you’re stuck on how to do select a track, and then make sure the track is highlighted) and do
that with EVERY SINGLE TRACK. Yeah, the repeating process makes you hate large #’s of tracks. D:

Once that’s done, best save your song. You’ve now prepared your song for insertion. That was arguably
the hardest part of the entire process. :P

Part 4: Applying Blazer’s Beta Music Insertion/Instrument Patch

So, get my epic patch from my website at [Link]

I probably sound narcissistic for calling it epic, but everyone needs to feel some good self-
accomplishment. I’m just having some fun… XP

Right, back to hacking,

Here’s the Readme:

README
-------

This is a private patch supplied by Blazer. It is not for use without permission. Credit must be given.

It adds all instruments at offset 0x107d7d0. Data ends at 0x11b6530. The actual instrument map can be
referenced by the offset 0x11ae42c when creating songs.

Back-up your ROM before using and be very careful with this. If you have not gotten this patch directly
from Fire Blazer than the data will not be repointed properly and it WILL screw up your ROM if used in
combination with a MIDI.

Thank you for your time.

As long as you don’t post this tutorial anywhere (you can link people to it, but link them to the WEBSITE,
DO NOT REPOST IT SOMEWHERE ELSE), then you’re free to use it. Also give credit if you use it in your
hack. Not only because I indirectly helped you with your hack but I’m curious to see if people actually
make use of things like these, and curiosity is just so hard to control.

Now, with that said, if you read the README (that’s the point of it), it says some data is inserted at some
scary offset. Well, if you happened to have data at that offset, we have a problem—the patch’s data has
pointers inside of it. TONS of pointers. The pointers are relative of each other. Unless you want to
repoint hundreds of pointers, the data has to go where the patch says it is going. In short, make sure
there is nothing at that offset.

So you’ll need to move out any data you have there—go use a hex editor and check to see if there is any
data between those offsets. If there is, it WILL be overwritten, beware. Also, if you have a clean ROM,
this WILL expand your ROM, meaning you will now have to start using UPS patches if you haven’t
already, and if you simply dislike expanding... well too bad. -_-

BEFORE you use NUPS (find it on [Link]) to apply that patch, BACK UP YOUR ROM! I make no
guarantees that nothing will go wrong and everything works. It’s worked for several people but that
doesn’t mean it won’t screw up your ROM. You have been warned.

That being said, go ahead and apply the patch, because you’ll never get anywhere without it.
Part 5: Converting Your MIDI

With that done, time to convert your song to GBA format. Crack out MIDI2GBA. Open up that program
called “[Link]”. It has an icon with the text ‘ELF’. Put your MIDI file into the folder called ‘mid’. The ‘mid’
folder is inside of the MIDI2GBA folder. Make sure it is your ONLY and I mean ONLY Midi there. In fact,
make sure it is your only file there. Otherwise things can get confusing later on and my methods won’t
necessarily work if you try and insert/convert multiple MIDIs at a time.

Once you’re sure it’s in, press the “??” button in [Link] (the ELF program). A pop-up window will come
up and your song will either be on the left or the right. If it’s on the right, the conversion failed. If it’s on
the left, it’s a success.

Now if it’s on the right, don’t get all pissed at me. There are some reasons why this might happen.

- Errors in the MIDI. Try to repair it using Anvil Studio. In Anvil, go to File-> Repair and hit “No” to
any pop-ups, then save and retry.

- The following may actually mess it up as well. Don’t try to repair the song and then insert, first
try to insert and then repair.

- Awkward instruments or something. Perhaps your MIDI file has some instrument that the
program “doesn’t like”. I doubt it, but who knows.

- Bad tracks, some unsupported type of track.

- MIDI file type. Try saving it as MIDI format 1 and midi format 0, although I’m not sure if this
makes a difference, maybe it does. It has to be a MIDI by the way—MP3’s and WAV’s are totally
different, don’t even try them.

- The file name has some weird symbols in it.

- You could just be unlucky and your song doesn’t want to work. This often times happens with
Felover3, a hacker who seems to fail at a lot of things… Poor dude.

If you can’t get it fixed, I’m sorry, this is a flaw in this method. I can’t help you too much besides saying
redo the process or try a different MIDI. To be honest, while writing this tutorial I did one myself, but
the MIDI I tried to insert ended up being on the right. In fact, so did the 2nd one. Not until I got to the 3rd
one did it work like it should.
Now, time to test out how your song should sound in-game.

Already?! We already get to test?!

YESZ!

In the MIDI2GBA folder is a ROM called [Link] – load said ROM using VBA and then press “Z” (the
equivalent of the “A” button in-game), wait a second, and then listen to your song.

If it’s choppy, then that means conversion had some difficulty. If the sounds are a little different or
something, then that’s due to instruments. Conversion isn’t perfect and the GBA hardware has its
limitations, thus the song won’t sound perfect. If it sounds pretty good, that’s great let’s continue. If not,
try repairing the song, manually fixing it using MIDI editing skills (if you have any), or try another MIDI.
My song, Celica’s Map Theme, sounds great, although not exactly like it should, so I am continuing. My
other two choices (Awkward Justice from Tales of the Abyss and Rick Roll by Rick Astley) didn’t work… it
was quite unfortunate really, but such is hacking. :P

Now time to get it to Fire Emblem.

Nub approach: can’t we just copy the song from [Link], the game we just played, into our game?

My approach: Let’s just copy the song from the test game into our game!

Hey, something IS simple! Sorta. Let’s get down to it.

Part 6: Making Your MIDI Repeat and Transferring it to Your ROM

Sigh, this tutorial is getting really long. And my hands are tired. Yeah. Not cool. Also, I’m making more
and more redundant comments like these.

Get your hex editor out, open up your Fire Emblem ROM as well as [Link]. Back-up your ROM, btw.

Go to 0x1B3BB8 in [Link] – this is where your first track starts. Now copy everything from here to the
end of the ROM. You’ve just copied all of the music data as well as the song’s header. That’s all you need
to know for now. :P

Now I’m going to make use of a new method of doing the repeats in the game. What you have to do is
paste all that data you just copied into a blank file. Using HxD, just press Ctrl+N or File->New and a new
tab will come up. Go to that an press Ctrl+V to paste all of your song data. Bam.

Now here’s how this works. The command to end a track is B1. The repeat command is B2 *pointer*.
For whatever reason, [Link] doesn’t add a repeat to the tracks, so you have to do it yourself. My easy
way is to just use a find and replace feature.

Press Ctrl+R in HxD, or if you’re using some other hex editor, find the option to do a find and replace. In
the find menu, type in “B1” (hex) and in the replace area type in “B2 00000000 B1 000000”—without
the spaces. It should look identical to this.
With that done, press “OK”. If you selected “Prompt on Replace” it will ask whether you want to replace
each instance of B1. In most cases you want to replace every one, but SOMETIMES there will be a B1
byte that isn’t actually the B1 we want to replace. If that doesn’t make any sense, sometimes there will
be a ninja B1, but we DON’T want to replace those, because they are ninja. The way to make sure that
you don’t replace a wrong byte is look at the B1 thing and check to make sure that after the B1 is a “BC”
byte. This’ll make more sense with a picture.

If the B1 and BC are next to each other then I can almost guarantee you want to replace it, so hit
“replace” and do that with every instance and once you’re finished you’re good to go.

What you’ve just done is preformatted the song to have repeats. You added in the code, so now you
have to insert the MIDI into your ROM and then fix up ALL the pointers. Fun.

As I just said, we need to put the MIDI in your Fire Emblem ROM. Copy all the MIDI data (the one that
you just did a find-and-replace function on). We’ll need a bunch of free space for this song. I’m going to
paste at some offset farther into the game that isn’t being used at all. Make sure wherever you paste
your edited song/MIDI IS NOT BEING USED and there is plenty of free space around it, just to be safe.

For your info (in case you didn’t know), it is best to insert at offsets that end in ‘00’. Like 0x1200000 is
easier to remember than 0x10849C4, although both will work. I just expanded my ROM further and am
inserting it at 0x11E4000. That’s an easy to remember offset. Because offsets are always important, I am
going to write it down. You should be writing down all these offsets in something like a notepad file
yourself—do it or you’ll suffer consequences later on.

Now, once you paste it, go to the end of wherever your pasted data is… my hex editor (HxD)
automatically takes me there. By the way, you should paste write, not paste insert. Paste insert = Ctrl +
V and it adds the data in the middle of the game, which messes up pointers. Ctrl + B overwrites the free
space you have and doesn’t mess up pointers.
Once you’re at the end of your song data, you should see to the right (in the ASCII text part) the name of
your file, something like “[Link]” with “awesome” being the name of your song… If you see that,
you are in the right area. Congratulations.

Boxed in dark red is the text. On the right you can see the name of my MIDI and on the left you can see
the hex for that text. 4 bytes before the text is what I consider a garbage pointer. That’s all you need to
know, it’s garbage. Like all garbage, you get rid of it. The name of the MIDI is garbage too, so just ‘00’ all
that out. Your end product should be something as beautiful as this.

With that, on to the next part!

Part 7: Track Pointers & Repointing

This is the final part of your MIDI, which is ironically called the header. The part in the dark red box, the
first 4 bytes, are 06 00 0A 00 in this example. 0x06 is the # of tracks I have in my song. My song DOES
have 6 tracks.

After that is a pointer to the Instrument Maps, also known as Voice Groups, although instrument map is
a much better term in my opinion. My patch inserts instrument maps at 0x11AE42C. In “pointer form”,
that is 2C E4 1A 09. If you notice, the only difference between the current pointer and what the new
pointer should be is the ‘09’, so change that. Once you do, you will have set up your instruments for the
song. Simple as that. Not only this, but any of the songs that are inserted with this method will use the
exact same instrument map, so there’s no hassle. :D

After that, in the purple box, are the pointers to the tracks. Right now they still point to our old tracks,
eww. A pointer is 4 bytes and if you notice there are 6 sets of 4 bytes up in that data I posted, or 6
pointers. 6 pointers for 6 tracks. Your song will probably be different. It might have 10 pointers or 3
pointers and the pointers won’t all be the same as mine.

Anyway, first we need to add in the repeat pointers. If you remember we added the B2 code to the song
for every track earlier on. What we were doing was adding the repeat code, 0xB2, and space for us to
put in a pointer. The pointer points back to the beginning of the track so that the track just plays over
again… and over again, and over again. :P

Go to the offset where you put your data. For example I put my data at 0x11E4000. From now on, write
down offsets, because it is very important to for you to repoint stuff. Do a search for the hex 0xB2 and
you’ll get to the end of your track.

Now the beginning of this track is at 0x11E4000 for me. You just wrote this offset down, it’ll be
something different for you, depending on where you put your song. In pointer form that is 00 40 1E 09.

About turning offsets into pointers:

Break up the offset into parts:

AB + CD + EF + GH = GH + EF + CD + (AB+8)

So 0x00123456 would turn into

56 34 12 08

And 01 1E 40 00 becomes 00 40 1E 01, but you add an ‘08’ to the last byte making it 00 40 1E 09. Bam.
Now type that in where the 00’s are between the B2 and B1. Like so.

Now that you’ve done that, there will be a “BC” byte soon after that. “BC” is the first byte of a track. I
could load you with lots of more information, but this is confusing enough as it is, so if you’re looking for
documentation on how track data is made up, look at the end of this tutorial.

Anyway, we want to know where the beginning of the next track is so that we can tell the game where
to repeat to. So find out the offset of the next track—look for the magical BC.

At the bottom left of HxD it tells you the offset of wherever you are. So that byte is at 11E4902. Yes,
great. I’m going to write that down, then do a search for B2 again. Then I’m going to take that offset, put
it into pointer form (02 49 1E 09) and then place it in the middle of the repeat code. Then I’m going to
find the next BC and start the process ALL over again, writing down the offsets each time, until I get to
the final repeat code.

And, stinks for you, but you’re going to have to do this too, and the more tracks you have, the more
frustrating and tedious it gets.

Eventually you should see your track header again, you know, the 06 00 0A 00 bytes, where “06” is the
number of tracks in your song. Once you see that, you know you’ve finished doing the repeating for all
the tracks. Congratulations, now you have to repoint the entire track header.

Take all those offsets of the track headers and repoint the tracks.
Remember a pointer is 4 bytes. There are 24 bytes there so if each pointer is 4 bytes then that means
there are 6 pointers, because my song has 6 tracks. If your song has 10 tracks, that means you have to
replace 10 pointers with the 10 offsets of the beginning of each track. Great. Do that and save your
game/ROM so you don’t lose all your work. Hahah.

Part 8: Finale- Assembling Your Song & Profit

This differs for each game.

Use the Music List for each game (comes with Nightmare Modules) to find out which song you want to
be replace. You can also replace a “blank” song.

Now, take the hex of that song and note it down. I am going to replace song 0x7A in Fire Emblem 7,
which is a “Nothing” song. But it’s OK. :D

For FE7 at least, there is an easy way of doing this: there is a Nightmare Module called the Music Array
Editor which you can open up in… Nightmare. Choose the song you want to replace and repoint the
offset of the current song to the offset of your new song—but make sure to add 0x08000000 to the
offset or it won’t work. E.g. I would type “0x091EC900”, not “0x011EC900”. Then hit enter and save and
go ahead and play the song in the game (an easy way to do this is to make the song play as the map
music by editing the music in the Chapter Data Editor).

If you don’t have this module, you’ll have to use this outdated way of doing it. Do check to see if you
have the latest Nightmare Modules in general, but otherwise… well, sorry I guess. XP

*Outdated Method*

Now you need to find out where in the pointer table that song is. You can optionally use Sappy 2005 to
load up your game, find the song, and then look at Sappy to find the offset of it.
“Table” is where the pointer to the header is. That offset there, circled in red, is what we want.

“Header” (blue) is the offset of the song header. We just made that—it includes pointers to all the
tracks, tells the game how many tracks, and where the instrument map is.

“Voices” (green) is the offset of the instrument map. My patch makes a universal version and the offset
of it is 0x11AE42C. That’s also in the song header, and we’ve already repointed that too. Just a little bit
more!

Go to the “Table” offset with Sappy. If you don’t have Sappy, follow the directions below

1. For FE7, go to 0x69D6E0. For FE6, go to 0x3994D8. For FE8, go to 0x224470. For any other game,
you’ll need to use Sappy to find out where the Song Table is.

2. Take your song # (mine is 0x7A—yours is whatever you got from the Nightmare Module’s Music List)
and multiply it by 8. Use Microsoft Calculator or something (make it Scientific and then select hex—it
can multiply hex, that’s right). You could probably find some calculator online too. Then take that
number and add it to the song table offset. So for me, 0x7A times 8 = 0x3D0. 0x3D0 + 0x69D6E0 =
0x69DAB0. That is the offset of my song.

Alternatively, for Fire Emblem 7, I made a Music Array Editor which can help you edit any of the songs
up to a certain point, but it’s limited due to an incomplete music list and it’s only for FE7.

What’s highlighted is my song’s info. The final bit. The pointer is a pointer to the song’s header. Mine is
at 0x11EC900. Good luck if you didn’t write it down like a good person.

0x11EC900 = 00 C9 1E 09, so I type that in. The next 4 bytes, which are currently just 00000000, have to
do with priority.

00 = Top Priority, 01 = Map Song Priority, and I had others noted down but pretty much the higher the #
gets the lower priority it has. Sound effects have a high priority of 6-8 generally, while backgrounds
music generally has 0-1, misc. music has 2-3, and yeah… You should be able to figure things out. Most of
the time you’ll just need to use 00 or 01 anyway.

01 00 01 00 is necessary for map songs to work correctly, or else when a unit goes into battle the map
music will stop playing. Just letting you guys know about that.

My final result is:

As usual, red is the edited stuff. I save, and then I test. You can test using Sappy v1.6 or just go straight
into Visual Boy Advance. Obviously you need to make your song play in game, which means you have to
somehow load it, whatever that way is. If you’re replacing something like the title theme, then that’s
really easy to test, because you just load up the game and bam. If you’re replacing a song that currently
wasn’t used, it’s up to you to test that song out.

Part 9: Possible Errors & Wrap-UP

Hopefully your song works. If it doesn’t, error could be

- Number of tracks

- Song wasn’t converted properly (program’s fault)

- Faulty pointers (very very likely, double check pointers, check for 08/09 for the last byte)

- Messed up data

- Overwrote some important data

- Edited the wrong pointer (rather than messing it up)

- You inserted some data somewhere, thus shifting everything, making pointers go wrong

- Some sort of pointer error >_>

- The song simply doesn’t want to play?

- You aren’t playing the right song in-game, you think you’re playing the edited song but you
really aren’t

- I dunno dude. Leave me alone. This tutorial is 4,900+ words and 19 pages. I’M FREAKIN TIRED.

Once you do a couple, you can make up your own tricks to make it go faster, and you’ll know how it all
works, making things go a LOT faster. I can probably insert a 5 track song in 30 minutes, a 10 track song
in like an hour and a half (yeah # of tracks can totally make things harder…). And I haven’t done a ton of
insertions either. A little bit of practice and you’ll make every minute of music insertion worth it.

Update: I recently inserted like, a 6 track song in 10 minutes, so it just takes some practice and then
things like repointing and knowing what to do will come REALLY easy. ^_^

Part 10: Documentation and Stuff

Commands:

BC PP

BD II

BE VV

These are commands that set stuff. There are other commands too but I won’t get into it. The first is BC
PP where PP = octave. 0x00 is default while adding or subtracting 0x0C will get you lower and higher
octaves, for example, 0x0C or 0xF4.
BD II sets the instrument. The conversion already does this for you but if you want to change it you can
do so manually. The instrument is the one labeled in Anvil Studio—[you] take that # and then subtract
one, then convert the number from decimal to hex. Wala, you have your instrument.

BE VV sets the volume, IIRC. VV is a # between 0-127, except in hex.

You shouldn’t need to change this but if you want to, it’s available to you, and it’s better than having to
edit the MIDI with anvil studio and then reinsert everything, IMO, assuming you don’t have to make
massive changes to the tracks.

B0 = Rest

B1 = End Son

B2 = Repeat

Some more commands for you to know*.

*(I am calling them commands, even if the name sometimes doesn’t make sense)

Atrius’ Notes:
The audio track data is a list of commands and arguments for playing music/sound effects.

Anything below 0x80 is an argument, and anything 0x80 and above is a command.

0x80 - 0xB0 = Rest commands of varying lengths, to wait a certain amount of time before playing each
note.

0xB1 = Stop command, to signal the end of the audio track. From what I've noticed even if a song loops
it has one of these after the loop command.

0xB2 = Jump command, to jump the playback pointer to another location in memory. Often used to loop
songs by jumping back to the beginning of it.

0xB3 = Jump command where playback can jump back to after it again later. Used when you want to
repeat part of a song before continuing with the rest of it.

0xB4 = Return to last 0xB3 command.

0xB5-0xBA = Unidentified

0xBB = Set Tempo

0xBC = Set Pitch offset

0xBD = Set instrument

0xBE = Set Volume

0xBF = Set Panning

0xC0 - 0xCE = Unidentified

0xCF - 0xFF = Play notes of varying lengths.

So to break apart the track information I gave you:

BE FF BC 00 BB 01 BD 00-CF 3C 7F B0 B1

BE FF = A volume command with an argument of 0xFF (Volume is an odd exception to the rule that
arguments must be less than 0x80)

BC 00 = Set the pitch offset to zero

BB 01 = Very low tempo so that the note is drawn out long enough for voice samples to play their full
length.

BD 00 = Set the instrument to the first entry in the instrument map.

CF 3C 7F = Play a note with a pitch of 0x3C (Right in the middle of the available range), and a volume of
0x7F (The maximum available)

B0 = Wait long enough for the note to finish playing

B1 = End the audio track

Charon’s Notes:
Pitch

Pitch is very easy to understand. As Atrius noted, it is follows the byte 0xBC (which is usually
the first byte in a given track anyhow). Pitch works like this:

0x00 is the base, equivalent to Middle C.

0x0C is one octave higher; High C.

0xF4 is one octave lower; Low C.

If you haven't noticed, it goes by increments of 0x0C, so for higher increments, they would be
0x18, 0x24, ect, while for lower increments they would be 0xE8, 0xDC, ect.

Tracks can be transposed by any value, however, so if you wanted it to be in a different key, you
could change these values. If done, make sure to add/subtract 0x0C when raising/lowering
octaves.

Tempo
Tempo is simply the tempo transfered into Hex. So, if your original tempo was 80, you would
put in 0x50. It follows a 0xBB byte.

Instruments
The instruments correspond with the instruments of the voicegroup. Although the instruments
can be anything you want, the typical way is to have the instruments correspond directly. It
follows a 0xBD The direct map:

PIANO
0x00 Acoustic Grand (often used as a drum kit)
0x01 Bright Acoustic
0x02 Electric Grand
0x03 Honky-Tonk
0x04 Electric Piano 1
0x05 Electric Piano 2
0x06 Harpsichord
0x07 Clav

CHROMATIC PERCUSSION
0x08 Celesta
0x09 Glockenspiel
0x0A Music Box
0x0B Vibraphone
0x0C Marimba
0x0D Xylophone
0x0E Tubular Bells
0x0F Dulcimer

ORGAN
0x10 Drawbar Organ
0x11 Percussive Organ
0x12 Rock Organ
0x13 Church Organ
0x14 Reed Organ
0x15 Accoridan
0x16 Harmonica
0x17 Tango Accordian

GUITAR
0x18 Acoustic Guitar(nylon)
0x19 Acoustic Guitar(steel)
0x1A Electric Guitar(jazz)
0x1B Electric Guitar(clean)
0x1C Electric Guitar(muted)
0x1D Overdriven Guitar
0x1E Distortion Guitar
0x1F Guitar Harmonics

BASS
0x20 Acoustic Bass
0x21 Electric Bass(finger)
0x22 Electric Bass(pick)
0x23 Fretless Bass
0x24 Slap Bass 1
0x25 Slap Bass 2
0x26 Synth Bass 1
0x27 Synth Bass 2

STRINGS
0x28 Violin
0x29 Viola
0x2A Cello
0x2B Contrabass
0x2C Tremolo Strings
0x2D Pizzicato Strings
0x2E Orchestral Strings
0x2F Timpani

ENSEMBLE
0x30 String Ensemble 1
0x31 String Ensemble 2
0x32 SynthStrings 1
0x33 SynthStrings 2
0x34 Choir Aahs
0x35 Voice Oohs
0x36 Synth Voice
0x37 Orchestra Hit

BRASS
0x38 Trumpet
0x39 Trombone
0x3A Tuba
0x3B Muted Trumpet
0x3C French Horn
0x3D Brass Section
0x3E SynthBrass 1
0x3F SynthBrass 2

REED
0x40 Soprano Sax
0x41 Alto Sax
0x42 Tenor Sax
0x43 Baritone Sax
0x44 Oboe
0x45 English Horn
0x46 Bassoon
0x47 Clarinet

PIPE
0x48 Piccolo
0x49 Flute
0x4A Recorder
0x4B Pan Flute
0x4C Blown Bottle
0x4D Shakuhachi
0x4E Whistle
0x4F Ocarina

SYNTH LEAD
0x50 Lead 1 (square)
0x51 Lead 2 (sawtooth)
0x52 Lead 3 (calliope)
0x53 Lead 4 (chiff)
0x54 Lead 5 (charang)
0x55 Lead 6 (voice)
0x56 Lead 7 (fifths)
0x57 Lead 8 (bass+lead)

SYNTH PAD
0x58 Pad 1 (new age)
0x59 Pad 2 (warm)
0x5A Pad 3 (polysynth)
0x5B Pad 4 (choir)
0x5C Pad 5 (bowed)
0x5D Pad 6 (metallic)
0x5E Pad 7 (halo)
0x5F Pad 8 (sweep)

SYNTH EFFECTS
0x60 FX 1 (rain)
0x61 FX 2 (soundtrack)
0x62 FX 3 (crystal)
0x63 FX 4 (atmosphere)
0x64 FX 5 (brightness)
0x65 FX 6 (goblins)
0x66 FX 7 (echoes)
0x67 FX 8 (sci-fi)

ETHNIC
0x68 Sitar
0x69 Banjo
0x6A Shamisen
0x6B Koto
0x6C Kalimba
0x6D Bagpipe
0x6E Fiddle
0x6F Shanai

PERCUSSIVE
0x70 Tinkle Bell
0x71 Agogo
0x72 Steel Drums
0x73 Woodblock
0x74 Taiko Drum
0x75 Melodic Tom
0x76 Synth Drum
0x77 Reverse Cymbal

SOUND EFFECTS
0x78 Guitar Fret Noise
0x79 Breath Noise
0x7A Seashore
0x7B Bird Tweet
0x7C Telephone Ring
0x7D Helicopter
0x7E Applause
0x7F Gunshot (also commonly used as a drum kit)

Volume
Volume is a simple concept as well, but unlike most of the song arguments, it must be a value
less than 0x80, or else (for some whacked out reason) it acts as a rest o.o

It follows 0xBE.

Panning
I need to investigate panning a little more, but I do believe that 0x00 is the neutral value. Either
that, or it's 0x0C. I believe that pan's range is from 0x00 to 0x0F; Atrius, correct me if I'm
wrong.

Also, about 0xB1 - if your track doesn't end in it, it will cause the game to crash and make that
horrible noise some of us know too well o-o

Part 11: The Music Hacking Run-Down (Shorter Version of Tutorial & Walls of Text)

Let’s say you’ve already hacked music before but you forgot how it works. Perhaps you just
want to know the general idea of how to hack music or the general layout of GBA game’s music,
whether that game be Fire Emblem (which is the focus of this tutorial) or not. This is the section for you.
It won’t go into huge detail but it’ll still give directions and whatnot.

First you have to download all the programs related to music hacking. Once you’ve unzipped
them and everything, take your MIDI and load it in Anvil Studio.

What we’re going to do here is have the MIDI formatted so it can be properly inserted. To start,
we don’t want the song to repeat inside of the MIDI, because we’re going to have the game repeat the
song for us. If the MIDI repeats within itself then we’re just consuming space. Use Anvil Studio to
truncate the song such that it only plays once.

Next we have to get rid of all unnecessary tracks to minimize tracks. I don’t recommend
inserting a song with more than 14 tracks. I’ve done 14 tracks but on occasion I actually have problems
with them. It’s best to limit a MIDI to 10 tracks or under if you can, just to be safe. Delete any tracks
without any notes (Anvil Studio will have some red text at the top left letting you know) and delete any
tracks that are already muted. If you still have too many tracks, look for some redundant tracks that only
have a few notes or have minor instruments that you can live without.

After optimizing the number of tracks you will need to equalize your track’s lengths. Making
sure that you go to View-> Composer, select a track, go all the way to the end of it, and make sure that
the track length and the song length match exactly. If it doesn’t, insert rests until the track length
matches the song length. Make sure you don’t add so many rests to the track that it makes the song
longer. If you make the song longer it’ll mess up the other tracks and it’ll also be adding rests to the end
of the song, so when your song repeats, it will have a pause in between the repeat, and thus sound bad.
That being said, optimize the song to be repeated properly with equal track lengths—with all tracks.

You can now save your MIDI (I recommend to use the “Save as” option in Anvil Studio to make a
separate copy with the new edited MIDI). Go to where you saved the MIDI and drag it into the ‘midi’
folder inside of MIDI2GBA, making sure that the MIDI you are going to insert is the ONLY file inside of
that folder. Double-click [Link] in the MIDI2GBA folder and hit the ?? button. Click “OK” and then look in
the two columns. If your song is on the left side, the program and MIDI worked fine… well, they should
have, anyway. If it’s on the right side, something is up with the MIDI, in which case please refer to part 5
of the tutorial.

If you have not already applied the instrument patch for FE6/FE7, please do so. If there is no
instrument patch for your game, what you can do is just apply the patch to a clean FE6/FE7 game
anyway and copy the new data in the expanded section of the game (0x1000000 to the end of the
game) and copy it to whatever game you are hacking. If you don’t get what I mean by this, then oh well,
this tutorial is optimized for Fire Emblem hacking, but as usual I just keep FE8 out of the mix.

Anyway, the patch aside, load the ROM “[Link]” (located in the MIDI2GBA folder) into Visual
Boy Advance or your GBA emulator of choice (VBA is the best GBA emulator though…). Press “A” or your
keyboard alternative which will make the ROM play your inserted song. Make sure it plays nicely and
whatnot. Then close the ROM.

You’ve now heard your song play in a GBA ROM, so hopefully that’s motivation to continue this
music insertion process. Load your ROM (for example, your hacked Fire Emblem 7 ROM) and [Link] in
a hex editor. I most definitely recommend using HxD because it has all of the features needed and that’s
what I use. Copy all the data from 0x1B3BB8 to the end of the game into a new, blank file. Use a find and
replace function to find “B1” and replace it with “B2 00 00 00 00 B1 00 00 00”. Do that to all instances—
you should find as many “B1” bytes as you have tracks. Once you’re done with the find and replace
function go to the end of the ROM and delete the ASCII text that has the name of your MIDI. Also delete
the 4 bytes before the text as they are part of a stupid pointer that you don’t need.

Now copy the data in this file you’ve just done some stuff with and paste write (for HxD, use
Ctrl+B, NOT Ctrl+V, Ctrl+V will INSERT data and possibly mess up your ROM) your data into a lot of clear,
open space in your FE7 ROM. Make sure there is plenty of space just to be safe. You will need enough
space for all of the data you are pasting so just look at HxD to find out how much space that exactly is.

Now go to the beginning of where you pasted your data and write that offset down. In fact,
write every relevant offset down from now on. You will need it. I recommend just opening a notepad
and typing important offsets.

Do a search for 0xB2. You’ll find the data B2 00 00 00 00 B1 00 00 00. The first 4 00’s are where
your pointer will go. They point to the beginning of the track. This data here is the repeat code and for
the track to repeat you need to tell it to play itself over from the beginning of the song. So the pointer
should go to the beginning of the song, which I told you to write down the offset. Put it into pointer
form (little endian, noting that offsets have an ‘08’ at the beginning of them, such that the offset
005C3984 will become 08 5C 39 84 which will finally be 84 39 5C 08) and enter it into that space of 4
00’s. Now right after the “B1 00 00 00” should be a “BC” byte. This is the beginning of the NEXT track.
Write down the offset that the BC byte/write the offset of the beginning of the track. Do another search
for B2 and do the same thing you just did with the pointer. Repeat this for every track until you end up
noticing that there is no “BC” byte for the next track because you’ve added the repeat code for every
track. After the final “B1 00 00 00” part you’ll end up at the header (TT 00 0A 00 where “TT” is the
number of tracks your song has, in hex). After the first 4 bytes is a pointer to the instrument map. My
patch inserts it such that all you have to do is turn the ‘08’ in that pointer to a ‘09’. All the other pointers
in the song’s header are pointers to the tracks.

Assuming you listened to me and wrote down all the offsets of the tracks, you can now take
those offsets and type them in “pointer form”, one after another, until you’ve replaced all the old track
pointers with the new track pointers.

Save your ROM and go to your song’s song table. You can use Sappy 2005 to find this or look at
the full-length tutorial for specific offsets for Fire Emblem games. Alternatively there is also an FE7
Music Array Editor which lets you edit the pointers and priority of songs in the song table/array. You’ll
now need to find which song you’re going to replace.

Let’s say you’re replacing song 0x4C, whatever that is. That’s great. Each entry is 0x08 bytes—at
least it is in Fire Emblem games, I’m not sure about other games—so multiple 0x4C by 0x08. Add this to
the offset of the music array (for example, FE7’s music array is at 0x69D6E0). Go to that offset and
replace the pointer here with a pointer to your new song’s header. Change the priority accordingly
noting that 00000000 is for background music, 000100001 is for map music, and lower numbers are for
various things, see the full-length tutorial for more details. XP.

You’ve now done a lot of stuff. Let’s think it over… we’ve formatted the song, got it converted to
GBA format, added repeats, made an appropriate song header, made sure that the song has appropriate
instruments (it’ll use standard MIDI instruments) and told the game where the song is as well as what
priority it has. All we have to do now is make the game use that song. That’s up to you—if you’re
replacing something like the title theme then that’s not a problem because the song already plays in
game. If you’re replacing some random song or an unused song then you’ll have to make the game use
that song yourself which is up to you. For Fire Emblem I suggest using the Chapter Data Editor, Sound
Room Editor, or Boss Music Editor to get your song to play in-game if it doesn’t already.

Hopefully it sounds nice and well. If you need more help or if the song had some issues, please
see the full-length tutorial (parts 1-9). This is mainly to give the general idea without completely
explaining anything, dividing into parts, etc.

Part 12: Credits & Thanks

My last part, I would appreciate credits and thanks for this tutorial. I sacrificed a ton of time
creating this and learning how music works and stuff. I’m not trying to complain butaAll I ask is that if
you use it, you put my name (Blazer) and Charon the Ferryman somewhere obvious, like in the credits.
Thanks for your understanding – I hope this guide helped you.

Special Thanks To:

Atrius – Lots of information about music editing, helped me insert WAV’s (which is NOT explained here)

Charon the Ferryman – her tutorial on music editing helped and inspired me to make my own tutorial.
She also gave me some one-on-one help with how to hack music and I took her method and just
expanded on it and stuff like that.

Chapter 25: Music Editing with Zahlman’s Song Editor

First of all, you need to download Zahlman’s song editor to do this. I suggest going to this topic-
[Link]

Next, download and install Python. It’s necessary.

Once that’s done, extract the files from the download. Read the README and transcript just to
give some background. Who knows if it’ll actually help, but it wouldn’t be included if it wasn’t
meant to be read, right? XP

Now, double-click [Link], and some stuff’ll happen. Mainly a screen will come up with a
disclaimer and a comment saying that if you need ‘help’ you should press ‘help’.

If you actually do type in help and press ‘enter’ on your keyboard, it’ll give you a list of
commands, and tell you some stuff. Here’s the important stuff:
 - Commands are not case sensitive. Filenames, probably yeah, just stick with doing proper
capitalization always, to limit the chance for problems.
- Decimal doesn’t have a prefix, while hexadecimal (AKA ‘hex’) has the 0x prefix. We know
this already (if you don’t, then this might be hard for you…).
- Don’t include extensions or quotes with filenames
- You can use relative paths or absolute paths. To make things easy, when the program
needs to access a file, make sure the file is in the same folder as the program. That way
you just type the file name—no fuss, no mess.
- (some other stuff you can read if you want to—isn’t completely necessary to know
when using the program, but a good read anyway)

Now, onto actually using the program. To start, you should know how to find more information
on a command. Simply type ‘help commandname’. So for example, to find out how the ‘open’
command works, type ‘help open’.

The open command is the easiest. Just type ‘open nameofrom’. So if my game is called
‘[Link]’ I’d type ‘open fireemblem8’. It’ll say “Loaded ROM from disk”.

Now, what to do with this ROM… Well, let’s say I want to extract a song from this game and put
it into Fire Emblem 7. First we need to know where the song is in Fire Emblem 8. This is where
Sappy can actually be useful. You can have it locate the song table for you and grab the offset
from it.

That being said, open Sappy 2005 and then load the ROM you want to export from. It’ll
(hopefully) find the song table of the game you are trying to hack—if it doesn’t, then something
tells me the game doesn’t use the Sappy engine, so you can’t hack its music with these
methods. On the left it’ll say the offset of the song table.

For FE8, the song table is at 0x224470. Now, in the FE8 nightmare modules is a music list. This
will actually prove very useful because it tells us which song is which. One day I was feeling nice
and I uploaded this song list here, for your reference-
[Link]

Let’s rip Truth, Despair, and Hope (TDH for short) because it’s an awesome song. It’s song 0x0D.
Since each entry in the song table is 8 bytes, we need to do (0x0D x 0x08) + 0x224470 to find
where the pointer to the song is. We can use Microsoft calculator or an online hexadecimal
calculator to do this.
If you don’t see options for hex in MS Calculator, set your view to scientific (View-> Scientific).
Then hit “hex” at the top left.

D x 8 = 68, according to MS Calc. + 224470 (the program knows it is hex because it is in hex
mode, so no need to put ‘0x’ in MS Calc) is 2244D8. So we’ll go to 0x2244D8 in a hex editor.

I see 5C 2A 55 08. That’s a pointer. It has little endian, i.e. byte reversal, so let’s flip it and we
get 08552A5C. Take off the ‘08’ (only the game needs to know about the ‘08’) and we have
0x552A5C. Finally, we have the offset we need.
Back to Zahlman’s Song Editor. All we’ve done so far is ‘open fireemblem8’ to open our FE8
game (or in your case, whatever game you’re using). Next we’ll do rip 0x552A5C to rip the song
we want.

Great! All 7 tracks were ripped. Let’s consider ourselves lucky that the program supports those
kind of tracks.

Now we can do two things. We can A) save the data in a binary file or B) burn the data to
another ROM. Let’s save it and then burn it, for teaching matters.

Type in ‘save songname’ to save the data to a binary file. Since I just ripped TDH, this is what I
did:
Now it says we can still burn it if we want. So let’s do that. First, we’ll open up the ROM we
want to burn it to. Mine is called ‘[Link]’ so I’ll do ‘open sc’. Then I’m going to burn the song. I
need two offsets—one offset where the pointer to the song will go, and another offset for
where the song is going to be inserted to. I know I have some free space at 0xD40000, so that’s
solved.

But how do I know which pointer to replace? I have to go to FE7 and do the same thing I did
with FE8 to find a song. We’ll say I am trying to replace song 0x5A, which is the main theme.
0x5A x 8 + 0x69D6E0 (offset for FE7’s song table) = 69D9B0. So that is where my pointer is going
to go.

So I have to type ‘burn 0x69D9B0 0xD40000’ to make it repoint the song at 0x69D9B0 to the
new song I am importing to the offset 0xD40000.
Burning successful! Now I just have to save my game. WAIT, DON’T USE THE SAVE COMMAND.
Remember, the save command is to DUMP SONG DATA. We’re trying to save our ROM. Do
“close romname”. In this case, I just opened ‘[Link]’, so I do ‘close sc’.

YESZ. Saved ROM to disk. Alright, I’m going to go test my song out now.

(*Tests…*)

It worked! Great! I know how to import a song!

But, wait, this song is cool and all, but I want some new music in my hack! I want to insert a
MIDI!

Well, here we go. Let’s start all over again—let’s close and re-open Zahlman’s Song Editor just
to refresh ourselves.

Before we continue, we need to apply a patch. This patch supplies us with basic MIDI
instruments. You can find it here- [Link]

But wait, thing is, this inserts data at a place, and it may very well overwrite some of your data.
This is why I suggest you don’t apply this patch unless you have an unexpanded ROM, and if
your ROM is expanded, that will be a problem, so this method will not work for you (D: D: D:).

Assuming you can apply the patch (use NUPS and make sure to hit ‘Notify’ on the left so that it
bypasses the fact that the patch will most likely not match your file) we now have instruments
to use so we can continue.

Let’s open our hack. ‘open romname’. Bam. Now, we need to convert a MIDI. ‘help convert’
tells us we need an offset for the instrument map (my patch takes care of that) and the name of
the MIDI. I am a very simple person (lol), and have called my MIDI ‘cm’ for ‘custom music’.

I will give you the offset for the instrument map (since it comes with my patch): 0x11AE42C. So
we must now type ‘convert 0x11AE42C cm’. We can now save our data to a binary file and load
it later, or we can just burn straight to the ROM. I’m going to do the latter.

Like before, we need to know which song to repoint. I am going to use the same song as before
in FE7—song 0x5A, the main theme. I’m using this because I can test the main theme right after
I load the game. I got the offset I needed already by doing 0x5A x 8 + 69D6E0 = 69D9B0. I have
empty space at 0xD50000 so I will insert my song there. So I type ‘burn 0x69D9B0 0xD50000’.

Now I save my ROM (‘close sc’) and test.

I hope it works for you, because it sure did work for me. It wasn’t perfect, but I didn’t expect it
to be perfect, since the program is still a work in progress, and the MIDI I used wasn’t great
either.

The tutorial on how to do it is a bit long, but get the hang of it and it’s a 1-to-3 minute job.
Enjoy your new song! ^_^

Chapter 26: Exporting Music with GBA2MIDI

There’s another way to import music from other games besides Shadowofchaos’ very hard
method and the ZSE (Zahlman Song Editor) method.

You can use a program called GBA2MIDI to convert a song to a MIDI and then use my Elf
Method tutorial to insert that MIDI. All I will do in this chapter is quickly teach you how to
export a MIDI.

First, you need your game. It has to use the Sappy engine or this won’t work. You know that if
you try and load your game and it doesn’t load/the program crashes, it is most likely because
your game does not use this music format. It’s unfortunate, but it happens.

Anyway, first download GBA2MIDI from my site. Extract the files and open it up. You should see
the following-
First, let’s load the ROM. Hit the “…” at the top right to browse for the file and select it. Then,
using the browse button right underneath it, choose a generic file that the MIDI will be
exported to. No matter which song you choose, the MIDI will ALWAYS be called this. Keep this
in mind. Your screen should look something like this (but perhaps with a different game).

Next, use the arrow keys next to ‘OFS:’ to choose which song to play. If you’re not sure which
one to use, you can try ‘convert’ (make sure you have ‘Play at once’ checked) and listen to the
song. To stop it, press the “Play/Stop” button. The same thing to play it again.
The ‘list’ and ‘help’ buttons probably won’t be too useful to you. The ‘list’ button can be used to
supply your own offset for a song table to the program, but the program has its own way of
locating the song table, so that shouldn’t be necessary. We already know what every other
button does except for the ‘close’ button which simply closes the program.

Now for the checkboxes:

Play at once – plays the song right after conversion.

Output Instruments – outputs the instruments used in the song as WAVs in a subfolder. Useful
if you wanted to import the instruments, but it’s not very easy to do something like that
manually, so if you want to import instruments from another game, you’re going to need ZSE
(no way to get everything in one package, huh?).
Optimize for XG – sort of alters the instruments used and stuff. Hard to explain what it changes,
but you can hear the difference. It often times affects drums.
Extract sequence data – I’m not too sure what this is, actually, nor am I too curious about it.
Minimal conversion – same as above. I don’t know everything, lol.

When you convert a song it’ll output as whatever you told it to output. I suggest renaming the
exported MIDI and then you can use it for whatever you want—if you’re a hacker, then that
most likely means you will insert the MIDI into another game.

You’d only really use this method if ZSE was not able to export the tracks because the tracks
were unsupported. Otherwise, ZSE > GBA2MIDI. That’s it for this chapter. =D

Chapter 27: Battle Background Graphics

Note: This chapter will only cover how to insert custom battle background graphics. It may help
with some other types of graphics, but it will not cover other battle related graphics such as
sprites or the battle template.

To start, what are battle backgrounds?

I gave this term to the backgrounds that you see while you are fighting—not the platforms but
the image behind it. If you don’t like these, then you can change them. I’m not going to supply
you with the graphics to change to, but I will tell you how the whole shebang works.
First, using Nightmare, load my Battle BG Editor. Skip over to the Desert one (0x08). There are 3
pointers, very much like the CG editor.

- Graphics are LZ77 compressed

- TSA is LZ77 compressed, unlike CGs
- Palettes are also compressed, unlike CGs

Oshi- everything is compressed. Well, that’s actually not a problem. GBAGE can decompress
said stuff.

However, there’s another trick to this. Compressed and uncompressed TSA work differently.
When you look at an image with uncompressed TSA in GBAGE, you’ll notice that the whole
image is flipped, and every 240x16 line is also flipped. Compressed TSA ‘doesn’t have this
problem’ and works ‘normally’. With CGs, which use uncompressed TSA, either the re-used TSA
or FEditor Adv’s custom TSA takes care of the weird image flipping. With battle backgrounds,
you can just use my custom TSA and it should handle all 16 colored images.

That being said, we’re going to need a 240x160 image for the background. The WHOLE image
doesn’t NEED to be apart of the background—you can have just a background strip like the
original games do-but whatever, your choice. An important note about your image; battle
sprite’s feet are typically set to be 100 pixels down from the top of the image. This means that if
you are using a background and removing platforms from the game (like I did with Tactics
Universe, for those who have played) you have to make sure there is a place to stand 100 pixels
down.

You can stink that image into MS Paint and see if you want, verily there is a place to stand 100
pixels down. Also, to ‘format’ your image, you need a portion of the transparent color at the
very bottom (the size of said transparent area is 240x8) and a pixel of the transparent color at
the very top-left which will become black (there IS a way to avoid having this pixel here, but it’s
so insignificant that I am not going to give you TSA to do it).

OK, we have a lot of things on our mind with all the information I’ve given. What we’re going to
do is take this formatted image, make it 16 colors, save it, import it as a bitmap with GBAGE,
repoint the graphics, insert over the old palette, insert our own custom TSA to use with any 16-
colored image formatted like above, and then repoint the TSA. Then good thing is, once you
insert the TSA once, all you have to do is repoint every custom battle background to use that
TSA. That bad news is, you’re stuck with 16 colors, because I don’t feel like inventing a method
to not be stuck with 16 colors. You can be mad at me, I don’t care.

[Link]

There’s my TSA/map data. Download it. Open it up in a hex editor like HxD.
Alright, cool stuff. Looks like a bunch of numbers going straight up from 00 and on, with some
LZ77 compression in the mix. It pretty much is.

Copy that and paste it into your ROM into some free space. Note the offset that you insert it at.
In fact, write down all significant offsets from this point on. You’ll find it quite useful.

So I’ll say I inserted mine at 0x1376100. Now we need to insert the palette and the image. To
GBAGE!

Now, using the offsets given in the Battle BG nmm, let’s load a background. I am using the
desert one so the graphics are at 0x2F758C.
Don’t worry about what you see in the graphics area. It’s not going to look right until we load
the palette and TSA. So do that—my palette is at 0x2F83A8. Make SURE you select
‘Compressed ROMpalette’ or else it won’t work.

Now, to load the (original) TSA. 0x2F8454.

Make sure that ‘Use TSA’ and ‘Compressed’ are both checked. If that’s done, your image should
look like this, or look like whatever background you were trying to load:

If it doesn’t, I suggest double-checking all your settings (everything should be compressed) and
make sure your width is set to 30 and your height is set to 32.

Once that’s done, it’s time to insert your formatted graphic. Hit “Import a bitmap” in the Image
Control window. Time to put up some write options.
Hit “browse” to locate the formatted graphic you want to insert. Make sure that it A) has a
transparent pixel at the very top-left, B) is 240x168, C) is 16 colors (use Usenti’s palette-
>requantize option to do that very quickly if you haven’t already—if the image has too many
colors to start with, after you make it 16 colors it won’t look good, see the CG tutorial for more
info on this). Next to “Graphics offset” put in an offset to insert the graphics at (duh). Make
sure there is plenty of freespace and always write down your offsets.

Do the same thing for the palette-although you CAN just insert over the old palette, it doesn’t
hurt to repoint stuff anyway, and there’s less room for error if you repoint data to freespace.
Check all the boxes like I have.
Note how my palette is exactly 0x100 bytes BEFORE my graphics. So I left some space in
between, even though my palette should only take up about 0x20 (32) bytes. (Each color is 2
bytes, and since the image is 16 colors, 16x2=32 bytes, which is 0x20 in hex. However there’s
compression and stuff so it doesn’t actually take that many bytes…) If you want to be REAL safe,
you can leave 0x200 bytes between the graphics and palette, because palette data should
never taken up more than 0x200 bytes.

Anyway, hit “OK” and then hit “OK” to anything else. It should insert and look real weird
because we haven’t loaded our TSA yet. Load your TSA (mine is at 0x1376100-I remember
because I wrote down my offset :P) so I will do that.
I’m going to save my changes so far (File->Save) and then see how my image looks so far:

Looks exactly like I thought it would look. No complaints from me!

Now the final step-repointing. Reload Nightmare and the Battle BG editor (remember that we
close programs after we move to another program to avoid overlapping changes and causing
confuzltion) and go to whatever background you just inserted over. In my very case, the desert
background (even though I inserted mountains…). The graphics and palette should already be
repointed thanks to GBAGE, so we just have to type in the TSA. Again, mine is at 0x1376100, so
I type 0x9376100.
Enter/ctrl+s to save nightmare, exit out, test in VBA… and it should work. Wooh! Now that we
know how to do this, it should get a lot quicker (like most things). Let’s keep it up =D.

Chapter 28: Music Array Module

The Music/Song Table/Array module helps 1) repoint music and 2) control the purpose of the
music.

If you open up said module with Nightmare, you’ll see a list of songs. Said list of songs gets cut-
off after a while because the Music List you commonly see skips some of the entries. Thus my
solution was to simply leave them unlabeled (unless somebody else wants to go back and label
them).

Anyway, aside from being able to repoint the song data with this module, you can change the
priority. For most songs used in cutscenes, during battle, etc. it’s the highest one (0x00). For
map music, you want to set it to 0x01000100 (the 2nd option) because otherwise the song will
stop playing after a battle. What’ll happen is it’ll play to start, but after you go into an animated
battle, it’ll stop playing, and it won’t start playing again unless you reset the music in the game’s
options, suspend/resume, or wait until the next turn.

That’s all there is to it, really.

Chapter 29: Sound Room Editing

There is a nightmare module that can edit the songs in the sound room. Open that up in
Nightmare and we’ll get started.

This is going to be a very quick chapter. The song is which song plays in that entry. The song
length is for when you use random mode and there is a sort of music player. It has a time limit
of sorts to play the song, and it needs to know how long the song is. As mentioned, 0x3B is
about 1 second. 0x3B = 59 in decimal. What we have to do is take how many seconds our song
is (let’s say it’s 74 seconds) and multiply it by 59. 74x59 = 4,366. In hex that is 110E (hint: I’m
not a genius, I just use a calc by Microsoft). If I’m right about how this works, then that’s what
you put for the time.

The ASM pointer is something used for the songs toward the end—possibly something to do
with unlocking the songs without actually listening to them (IIRC they require some Mario
bonus disk thing). It’s nothing to worry about.

The text pointer is just the index for the text. You can edit the song name in FEditor Adv by just
typing in said text ID/pointer/index/whatever you want to call it.

Chapter done!

Chapter 30: Chapter Unit Editing with Nightmare

There are two main ways to edit units. The first way is to use Nightmare. The second is using
the Event Assembler. The latter is mainly for people who want to use custom events or want to
add more units. I’m going to cover the first way here in this chapter.

To start, in unit data, you will find some empty slots. Don’t edit these—they are separators. The
point of them is to separate different groups of units. Allies and enemies of normal/hard mode
are separated, as are “event units”—units that only appear in events (NPCs and the like)—and
reinforcement units (units that show up mid-chapter as opposed to the beginning).

The character and class are obvious. The character’s leader just specifies who is the boss/leader
of that allegiance of units. Not really important.

The starting level is kinda obvious too. Note that there are two options for each level/allegiance
though—the 2nd one is the autolevel feature which adds stats based off of ‘automatic level-
ups’. It’s mainly used for enemies so that a level 1 enemy doesn’t have the same stats as a level
10 enemy, even if they use the same character data.

The loading coordinates is where they start on the map. They will then move to the starting X-
coordinates. Sometimes this can just be the same, other times (during cutscenes) you may want
to actually have them move to wherever they are gonna be stationed. Note that coordinates
start from the top left (0,0) and X is to the right while Y is to the left. If you are using a custom
map, it is sometimes useful to use Mappy to figure out which tile is what co-ordinate.

There are only 4 spots for items, unfortunately. It’s kinda obvious what to do here as well.

AI is sort of tricky, if only a little. AI stands for ‘Artificial Intelligence’ IIRC. There are 3 main AIs I
use. 00000000 – default attack anything. 00030900 – attack anything within range. 03030920 –
attack only if a unit can be attacked without moving. The first is for main enemies, the second is
for guarding enemies, and the third is for bosses who guard a gate or throne or something.
There are also dropdown lists that have some other options though, so you’re free to play
around with those things.

Notes on How the Game Loads Units:

Once a unit is marked as an ally and you play as them for a chapter, their data is in the save
data, so all you need to do to is load their character with their character #. Everything else is
insignificant (allies don’t use AI). However, if that unit is killed, that’s a different thing—you
have to reload their data again, from ‘scratch’.

Battle preps work similarly, however, if a unit is killed OR their allegiance is changed, they will
no longer be considered an ally and will not show up in battle preps. How many units are
allowed in battle preps is dependent on how many characters you add. It doesn’t matter which
characters you add or where you add them because the player gets to choose which characters
he/she wants to use in the battle as well as reposition them. However, if you put in 10
character slots, that means the player can only choose 10 characters, and the characters can
only be at the spots that you designated with the starting co-ordinates.

Also, units will NOT show up in battle preps unless they joined the chapter BEFORE. That means
you can’t just add a new unit to the unit data and expect them to show up in the battle preps.
They have to A) be secretly loaded the chapter before at the end cutscene, so the game
recognizes they are a part of the ally team, or B) loaded separately from the battle preps
through events. This is important-just adding a new unit to the unit data when battle preps is
on doesn’t do anything. As said, if battle preps are off, that’s different.

Chapter unit editing in Nightmare can get tedious and may sometimes be limiting or confusing,
but that’s Nightmare and hacking in general for you. If you don’t like it, learn how to use the
Event Assembler! :P

Chapter 31: Death Quotes

This will not teach how to edit death quote text. Death quote text works the same as other text
(even though I haven’t actually taught how to edit text yet). This just edits the stuff in the
Nightmare modules.

We’ll start with death quote editor part 1-2. If I’m right, this is Lyn’s mode death quotes and…
something else. Part 2 starts after the 0x00 entry near the middle. It *probably* should be 2
different modules, except the data is right next to each other, so it’s kind of confusing.

Anyhow, character and chapter is obvious-use 0x43 for most characters unless they have a
special death quote in a specific chapter (in which case specify the chapter, of course).
The pointer to the death event is a pointer to a very short event that usually just contains a text
event. For example, if you go to CC0808 in a hex editor (for Lyn’s death quote, the first entry)
you’ll see “0D000000 A8070000 09000000 0A000000 00000000”.
The 0D part is the command for normal text. A807 is the text pointer, but reversed due to little
endian, so it’s actually 7A8. This is what you go to in FEditor Adv to edit her death quote text.
The ‘09’ command clears the text and ‘0A’ ends the event. The 00s are just insignificant
nullifiers for the most part (but don’t edit them anyhow). The main part to worry about is the
A8070000 since that’s the text pointer/ID/reference (from now on I’m calling it text ID for
simplicity’s sake) that you might want to change.

Now, later on, you may want to write your own custom death quote event using the Event
Assembler; if you don’t know about this, then don’t worry about it, but if you want to know
how, simply do something like this:

ORG 0xD20400
DeathQuoteEvent:
*insert events here*
ENDA

Then link to the event using the death quote module by updating the pointer in the module
(and be sure to add 0x08000000 to the offset or it won’t work).
On a side note, if you’re going to repoint death quotes, note that part 1 and 2 BOTH need to be
repointed… so yeah.

[Back to the main topic] The trigger ID is something that will take a bit of learning to
understand. It’s like a number that references an event. I call it an event ID. In this case, Lyn’s
death quote has event ID 0x65 attached to it. This is important because when event 0x65 is
triggered, the game over scene occurs. Yes—if you want a game over scene after the death
quote, just give the character a ‘Trigger ID’ of 0x65. As long as the game’s events are coded to
react to this death quote, this should work properly.

The Trigger ID can also be used in conjunction with other events though. You could set it to say,
0x0B, and then make an event that happens when 0x0B is triggered. So you could make it so
that if you kill a unit, the chapter ends right after… Just like a boss. Yes, bosses typically have a
Trigger ID of 0x02 (although their data is in death quote editor part 2, for whatever reason).
Similarly Trigger IDs 0x01 and 0x03 are also reserved, so it’s better not to touch 0x01-0x03 and
0x65. Managing them is kinda hard but it’s feasible. I’ll cover more about this in the next
chapter.

Anyway, let’s continue to part 2 of the death quote editors. This one is a bit better. It’s the
same except it gives us the option to just put a text ID instead of ALWAYS having to have an
event. But still, there is an option for an event if you want (if not, it’s 00). The Trigger ID works
the same (I will cover more about it in the next chapter).

Chapter 32: Event IDs

Well, my order is a bit messed up. Maybe I should be teaching things like how to edit text and
portraits before going onto teaching event IDs. Maybe I should. Oh well.

Before you read this part of the tutorial, please read the previous chapter on death quotes
because it contains information on Trigger IDs, AKA Event IDs.

^With that out of the way… event IDs come from various places. One place is scenic events-
there are event IDs there that have many purposes. When we get to events, you’ll start seeing
spots to put event IDs ALL over. There’s even codes that can trigger them on and off ‘manually’.

One thing is that the event IDs are shared-meaning you shouldn’t use the same one in a
chapter, unless it’s 0x00. If an event has an event ID of 0x00, it can happen infinitely (unless
something ELSE is stopping it from happening-like if you visit a village and the village gate is
closed, you can’t visit the village, regardless of whether the event ID is 0x00 or not). Thus
events with 0x00 are like ‘generic events’ and don’t have any special properties to them.

Event 0x01 is for something—I think boss battle quotes. Event 0x02 is for death quotes, I
believe. Event 0x03 is for the seize event. Event 0x65 is the ‘game over event’-if this is
triggered, the game will go the game over screen. I would say almost anything after event 0x65
is a ‘perma-event’, meaning that the event ID remains in use after every chapter. Earlier event
IDs, like 0x01-0x64, are not permanent. After the chapter is done, they get reset to not being
triggered.

Actually, I have a confession. I’m not sure which events are permaevents and which are not-I
only have a VERY vague idea. It shouldn’t be a problem though, hopefully. Oh well. :\

So, back to where event IDs come from:

- Scenic events
- Location events (villages, seize)
- Death quotes
- Battle quotes
- Triangle attack battle quotes (yes, even this)
- Events in general

These are all shared. Meaning if say, event 0x14 is triggered because of a battle quote, and an
event with ID 0x14 is supposed to happen in a scenic event, it won’t happen, because event
0x14 was already triggered (and the game is trying to avoid having the same event happen
twice). Thus you have to manage which events you use and how you manipulate them.

With this background, you’re ready to step into events! Unfortunately, events are chapters
ahead of us. D=

Also, here is a list of known event ID’s (event ID’s known to be reserved for something), straight
from the Event Assembler.

--------------

//Event ID's with special meanings

#ifdef _FE6_
#define NoID 0
#define BossQuoteID 1
#define BossDeathQuoteID 2
#define SiezeID 3
#define GameOverID 0x65
#define CathConvo1 0x67
#define CathConvo2 0x68
#define CathConvo3 0x69
#define IliaSacaeRouteID 0x6B
#define CathRecruited 0x70
#endif

#ifdef _FE7_
#define NoID 0
#define BossQuoteID 1
#define BossDeathQuoteID 2
#define SiezeID 3
#define UseSecondaryMusicID 4
#define GameOverID 0x65
/*
66
67
68
69
*/
#define Ch13xBeatID 0x6A
#define Ch17xBeatID 0x6B
#define Ch19xBeatID 0x6C
#define Ch23xBeatID 0x6D
#define Ch28xBeatID 0x6E
/*
6F 31x/32x beat?
*/
#define LloydOrLinusID 0x70
#define DorcasDeadID 0x71
#define WilDeadID 0x72
#define LuciusDeadID 0x73
#define SerraDeadID 0x74
#define ErkDeadID 0x75
#define KentVisited 0x76
#define SainDeadID 0x77
#define RathDeadID 0x78
#define FlorinaDeadID 0x79
#define MatthewDeadID 0x7A
#define NilsDeadID 0x7B
#define WallaceDeadID 0x7C
#define PentDeadID 0x7D
/*
7E
7F
*/
#define AthosDeadID 0x80
#define HawkeyeDeadID 0x81
#define JaffarDeadID 0x82
#define LynModePassedID 0x83
/*
84
85
*/
#define Ch19xxBeatID 0x86
#define PentHeavenSealReceivedID 0x87
#define DartDeadID 0x88
#define VaidaDeadID 0x89
#define PentXLouiseC 0x8A
#define PentXLouiseB 0x8B
#define FioraTriAttackConvoID 0x8C
#define FarinaTriAttackConvoID 0x8D
#define FlorinaTriAttackConvoID 0x8E
/*
8F
90 Other triangle attack IDs?
91
*/
#define OswinDeadID 0x92
#define KarelDeadID 0x93
#define NinoDeadID 0x94
#define BartreDeadID 0x95
 #define KarlaDeadID 0x96
#define AnnaVisited 0x97
/*
98
99
*/
#define HeavenSealPentID 0x9A
#define MerlinusJoined 0x9B
/*
9C
*/
#define SomeoneSemiImportantDiedID 0x9D //Only in internal use
#endif

#ifdef _FE8_
#define NoID 0
#define BossQuoteID 1
#define BossDeathQuoteID 2
#define SiezeID 3
#define DefeatAllID 6
#define GameOverID 0x65
#endif

------------------

Chapter 33: Battle Conversations

There are two types of battle conversations: specified and unspecified. Specified means it is between
two specific characters, while an unspecified battle conversation can happen when one character fights
with any character.

We’ll start with the unspecified battle conversation module by Icy Toast. The character and chapter are
obvious. Now depending on your version of this NMM, you may have ‘Convo Text’ and ‘Convo Bank’, or
just ‘Convo Text Pointer’. Regardless of where it’s broken up into two slots or not, it’s just the text
pointer that is used.

For information on trigger IDs, see the other topic. If you wanted a battle conversation to occur
everytime you fight a unit, you could use 00. The default value for boss battle convos (assuming there
aren’t any special properties) is 01. If you wanted an event to happen after a battle conversation, you
could set it to something else and make an AFEV event happen when said event ID is triggered. You’ll
learn about after events (AFEV events) in the event chapters of this tutorial.

The specified battle conversation editor works similarly, except there are 2 characters, and the event ID
is not 01. It’s some other value that the game uses. Remember that event IDs for a chapter are shared
between battle conversations and scenic events/the main events, so don’t have two events with the
same ID. 

The ‘event data pointer’ can be used in place of a text pointer. It’s really only used when there’s special
properties for a battle conversation-for example, if there is a different battle conversation for Hector’s
mode and Eliwood’s mode of a chapter. It’s just a pointer to an event-you have to either edit the event
in hex or make an event with the EA, specify an exact location for that event, and then put the pointer
to that event in the battle conversation ‘Event Data Pointer’ slot. It’s something you most likely won’t
use in your hack, so I wouldn’t worry about it too much.

That’s all there is to it. Another chapter down, w00t!

Chapter 34: Triangle Attacks

Before I go on writing a tutorial, I’m going to post some notes I have on triangle attacks.
Notes on Triangle Attack:

Character Editor Nightmare Module:

Ability 3, 0x20 is Triangle Attack. This is for Pegasus Knights. There is another triangle attack option,
0x40. I am almost certain this is leftover from FE6 as the armor knight triangle 'skill' is 0x40 in FE6.
However, this triangle attack could probably be used for something else too.

0xC9F130 - Triangle Attack Convos

Character, chapter (0x43=any), Text ID, Trigger ID

(Info thanks to NL)

Should be able to expand to allow more triangle attack convos, for say, alternate combinations of
triangle attacks (like if there are 4 pegasus knights) or usage of the currently unused triangle attack skill
(just add more convos, set the skills, and if the game already has the code there [just unused], then it
should work).

Triangle Attack Graphics- Start around image 495 (+ or - a few) in GBAGE

0x2E5CB8 - First Graphic

Order:

PegasusKnight (Lance)
FalcoKnight (Lance)
FalcoKnight (Sword)
PegasusKnight (Lance) (2nd sheet)
FalcoKnight (Lance) (2nd sheet)
FalcoKnight (Sword) (2nd sheet)

ArmorKnight (Standing)
General (Spear) (Standing)
General (Axe) (Standing)
General (Handaxe) (Standing)
ArmorKnight (Attack Motion)
General (Spear) (Attack Motion)
General (Axe) (Attack Motion)
General (Handaxe) (Attack Motion)

Pointer to ArmorKnight graphics at 0x6AAC8 in ASM

This means that they are probably already coded into the game and leftover from FE6, but simply unused
(most likely since there aren't 3 armor knights to do it with). This also means that it's likely that one can
use the Armor Knight triangle if they just set it up.

Data continues right after the final graphics (i.e. there is more graphics right after the General handaxe
graphics) meaning miscellaneous data (animation and whatever else) is probably both before and in the
first megabyte's span of data.

0x2E58BC - compressed data right before graphics. Slight resemblance to TSA at first but then diverts
from this and shows signs of graphical data (0xF0 0x01, which is in essence blank graphics). Idk if it has
to do with anything.

In any case the only way to tell how this works and what is relevant or not is through ASM. One could
edit the existing graphics, triangle convos, who has the skills, and test the usage of the unused [once
used as FE6's armor knight] triangle attack.

For palettes, I believe that the palette of the surrounding characters is used... that is, use the battle
reference module to get the palette of the Pegasus Knight sisters. I tested this and it loads fine and looks
great.

Farina's Palette- 0xFDA00C

Fiora's Palette- 0xFDA07C
Florina's Palette- 0xFDA0EC

Alright. Now that that is off my back, I can tell you how to make use of this information.

To start, there’s a module called the Triangle Attack Convo Editor or something like it. At least, there is
such a module for Fire Emblem 7. I’d like you to open that up in Nightmare.

The character, chapter, and convo value/text pointer work as they always have. If you don’t know how
these work, I suggest learning about death quotes and battle conversations first.

The ‘trigger ID’ also works as it usually does. There’s a whole chapter on these, so I won’t explain this
either. Which means we’re almost done here.

By default there’s only room for 3 conversations. But what if you want more than 3 conversations?
There could be many reasons for wanting more conversations—if there’s another Pegasus Knight, if
there’s a special conversation for a chapter, or something else. Well, to do this, you have to expand the
table. To expand it, you have to first move the data to empty space and then repoint it. The details? I’ll
cover them in a later chapter.

Now, how does the game know which characters have the triangle attack ‘ability’? The keyword is
‘ability’. It’s in the character abilities. Load up Fiora in the character module and scroll down all the way
to ‘character ability 3’. You should see 0x20 – Triangle Attack. Bam. There’s also another set of triangle
attacks with the value 0x40. I think this was originally the armor knight triangle attack, but when I tested
it out myself with 3 FalcoKnights, it showed FalcoKnights, not Armor Knights, so maybe the game checks
to see if there are 3 armor knights first. I really don’t know, but the alternate triangle attack is there and
ready to use.

As for palettes, the palettes of the FalcoKnights that cut-in are from the other characters palettes… err,
that means that as long as the palettes of whoever is in the Triangle Attack are working palettes, they
should work/look fine during a triangle attack.

If you’re really into graphic editing, you could try fiddling with the jumbled graphics that I noted in my
notes (I gave offsets and some other information). However, it’s not very easy, nor is there a lot of
freedom with it, so I wouldn’t exactly suggest it.

With this, have fun editing triangle attack conversations, making your own triangle attacks, etc.!

Chapter 35-36: The Animation Modules & Repointing Tutorial

In this chapter we’re going to quickly go over the modules in the ‘Animation’ folder-at least, the
modules we haven’t gone over yet.

First, we’re going to start with the Animation Pointer Table Editor. It’s a table for both reference and
repointing that has relevant offsets for each animation. The header is just some text that I probably
wouldn’t edit. The ‘mode divider’ is also something I wouldn’t edit. Frame data can be edited but you
have to know how and it’s not something that’s really suggested or needed very often. I might cover the
basics of how to do it. I wouldn’t suggest editing anything there except maybe the palette. The palette is
like, the generic class palette, for generic units. Yeah. :\

Next, the Item Animation Reference Pointer module. All it can possibly do for you is repoint two
pointers to something else. Since it uses a dropdown, you are limited to only repointing it to one area.

Since we don’t want to be too limited in our hacking, I’m going to teach you how to repoint it in a hex
editor. Skip this if you don’t care about expanding/repointing data, especially if you don’t care about
this data at all. All it does is repoint Spell Associations so that you can add more weapons to the list.

Go to offset 0x052B24. If you’re wondering how I figured this offset out, all I did was edit the Nightmare
module (.nmm file) in a text editor and looked under the line that says the name of the module.
As said, this is sort of limiting. We can just go to that offset in a hex editor and repoint it to whatever we
want.

If you don’t know, ‘pointer form’ in a hex editor is (0x08000000 + offset) – reversed. The default offset
to animation lists or whatever is 0x00C999C0. I add 0x08000000 so it becomes 0x08C999C0. Then I
reverse the order of the bytes (a byte is like two digits). 0x08 C9 99 C0 becomes C0 99 C9 08. At that
offset I told you to go to, we see exactly those bytes. If we wanted to repoint it to some other blank
space, we’d take the offset of the blank space and reverse it like I just did, then just type it in.

However, if you remember, the NMM has TWO pointers to repoint. Well, to find the other pointer, we’ll
just search for its bytes. So we do a search (typically ctrl+F) in our hex editor of C0 99 C9 08.

(Make sure to set the input/datatype to hexadecimal, not decimal, text, or something else.)

Alright, we found another instance. That’s the only other instance there is. So we repoint this one too.
After that, we’re almost done.

Now we’re going to copy the old data to the new area. Let’s say our new area is at 0xD70500, just for
teaching purposes. We’re going to copy the data there where there is plenty of free space to be used.
The point of free space is to add more things to a list or table.
The purpose of repointing is like moving books to another room. You can only put so many books into a
room before you get to the walls and you can’t put anymore. So we just designate another room for all
the books. This room has PLENTY of space though, so we can add even more books. However, we can’t
have an infinite number of books, because the building has its limits as well.

The equivalent:

We can only put so many entries of data (in this case, item animation/spell animations) into one area
before we run into other data. So we have to designate another area to use, and then move all of our
old animations there. Then we can add our own item/spell animations there.

Hopefully this is all starting to make sense. We did the designating (repointing), so now we have to
move our stuff. Go to 0xC999C0 and copy all the data from there to 0xC9A1B0 (but don’t include that
last 0xFF byte).

Copy it (ctrl+C) and paste it into our new area. Per my example, I am putting it at 0xD70500. You know
how to paste data, hopefully (make sure you are PASTING data, NOT inserting new data, if you insert
new data it’ll shift over the offsets of other data and your ROM will get royally screwed).

Now save your ROM in your hex editor. We’re going to do one last thing. To make sure we don’t have to
edit data in hex, we’ll edit our Nightmare Module to edit the data at our new offset.
The “repointing module” is the one we were using before I said “this has its limits, it’s lame”. The actual
data we are repointing is the item animations, AKA spell associations. So go to the spell association
editor and make a copy of that .NMM file. Make a copy for your repointed table of data.

Call it something to remind you that it’s repointed. Now open it with a text editor (my NMMs are
already set to open with a text editor-if yours don’t, just double-click them, hit “open with a specific
program” or something like that, and choose Notepad or your preferred text editor from the list of
programs).

It should look like this:

We’re going to A) rename the module to remind us that it is repointed, B) change the offset from
0xC999C0 to 0xD70500/your equivalent offset, and C) change the # of entries from 127 to however
many entries you want (I suggest 150 because you probably won’t need anymore than that many, and if
you do, good luck on actually making over 23 custom weapons and items). Here’s my changes to show
you what I did (you should be able to figure out what to change based off of my image and what I said).

Save it and you’re ALMOST done, I’m serious this time. Now you just have to open up your new module
and you’re ready to start editing. You’ve learned how to repoint and expand data, as well as customize
your own Nightmare Module for it! Congrats!

Unfortunately, this chapter is not yet done. FE7 has one more animation module. A “custom item
animation list” one. The module is just an outdated version of the Spell Association editor that was
made to be at 0x9000000 instead of 0xC999C0. In other words, like the Item Animation Reference
Pointer module, you probably won’t make use of it anymore. (Still, you have to admit Pukachi was nice
to make all these nightmare modules to help us out with our hacking. After all, she started most of the
thing, some years ago… before that, only a few people did FE hacking… myself not included… )
Chapter 37: Support Editing

This is a tedious job, especially for a sole hacker to do, but sometimes it is worth it. Personally the Fire
Emblem games that had legitimate supports (where the characters actually had personality and
background) were some of the best.

Anyway, if you have outdated modules, you may have ‘Custom Support Pointer Editor’ and ‘Support
Pointer Editor’ modules. The former is used for expansion but it’s limiting, and thus trash.

We’ll start with the Support Bonus Editor. It lists the affinity and the bonuses that said affinity gives.
Attack and defense bonuses are stats while the others are percentage boosts.

The support compatibility editor is a list of what supports a character has. A character can have a max of
7 supports, and to my knowledge, can have no more than 4 “active” supports at a time (supports that
actually have reached at least level C and can be seen on the menu).

The initial support count is the count towards getting the next level of supports. Some general values for
supports are:

- 100 for C level

- 180 for B level
- 241 for A level

These aren’t exact/for sure. They are just general ranged if you want a set support. Otherwise, you can
have it set at 0, or something higher. Two characters that already have some relationship with each
other (like Eliwood and Hector) are more likely to support realistically, and thus have a higher initial
support count.

The support gain per turn is how much the support level grows for every turn they are next to each
other. A higher the number the quicker it grows (although you don’t see the effect of a support
relationship growing until you have the next level’s support conversation).

To make use of these entries, there is a pointer in the character editor called the “Supports Data
Pointer”. It points to a specific slot as opposed to a reference byte like 0x00 for Eliwood or 0x0A for
Oswin. This actually makes it somewhat easier to make use of. :\

By the way, each entry is 0x18 bytes IIRC, meaning pointers will be 0x18 bytes apart. This information
may or may not be useful to you.

The Support Convo Availability Editor just specifies which conversation values (text pointers) there are
for the C, B, and A level support conversations between two characters. By now you should know
enough about hacking that I don’t have to explain anything here.
Everything in the Endings Editor should be obvious so I’m not going to even cover that. Thus, we’re done
with learning about supports and endings!

Chapter 38: Miscellaneous Nightmare Modules

In this chapter I’m going to quickly run through what some other nightmare modules do.

FE6:

Army Editor – same thing as chapter unit editor, pretty much.

Battle Screen Editor – edits the layout of the battle screen. I myself don’t really get how to use this, and
thus am not covering it.
Critical Bonus Editor – edits the critical bonus. (Default: 15)
Event References – a module for the event table. It helps with knowing where event data is located as
well as repointing.
Level Cap Editor – edits the level cap. (Default: 20)
Promotion Level Editor – edits the level at which a unit must be higher than to promote. (Default: 9,
meaning level 10 or higher)
Shop Event Editors – edits the events for shops (location, shop pointer, shop type).
Vendor/Armory Editors – edits the contents of vendors and armories.

FE7:

Afa’s Drop Bonus Editor – edits the bonuses given by Afa’s drops.
AI Recruitment Editors – edits info about “AI recruitments”, where an NPC or enemy unit moves to and
talks to a character in order to be recruited. Clarine of FE6 and Xane of FE12 are just a couple examples.
Battle Screen Editor – edits the layout of the battle screen. I myself don’t really get how to use this, and
thus am not covering it.
Beta Modules – for editing the FE7 beta.
Chest Editors – edits the contents of chests.
Critical Bonus Editor - edits the critical bonus. (Default: 15)
Event Pointer Tables – can edit the individual event pointer tables of chapters. Not very useful anymore.
Event References - a module for the event table. It helps with knowing where event data is located as
well as repointing.
Level Cap Editor - edits the level cap. (Default: 20)
Luck Cap Editors – edits the luck cap. Comes in two parts. (Default: 30)
Promotion Level Editor - edits the level at which a unit must be higher than to promote. (Default: 9,
meaning level 10 or higher)
Shop Editors – edits the contents of shops.
Seize Throne Editors – edits the location of thrones that can be seized. Currently incomplete.
S-Rank Bonus Editor – edits the bonuses of S rank weapons.
Vulnerary Editor – edits the amount of HP restored by a vulnerary. (Default: 10)
World Map Event References – A list of pointers for world map events, the one you see before a chapter
actually starts.

FE8:

Battle Screen Editor – edits the layout of the battle screen. I myself don’t really get how to use this, and
thus am not covering it.
Chest Editors – edits the contents of chests.
Critical Bonus Editor - edits the critical bonus. (Default: 15)
Event Table Editor – same as the Event References editors for other games, just for FE8, and with a
different name.
Level Cap Editor - edits the level cap. (Default: 20)
Palette Association Editors – edits which palettes go with which characters and classes.
Promotion Level Editor - edits the level at which a unit must be higher than to promote. (Default: 9,
meaning level 10 or higher)
Recruitment Editors – edits recruitments.
Reinforcement Editors – edits unit reinforcements.
Shop Editors – edits the contents of shops.
Summon Editors – edits which classes can summon and what character/class is summoned.
Vulnerary Editor – edits the amount of HP restored by a vulnerary.

You may be wondering “hey, wait, we still haven’t done the Chapter Data Editor yet!”. That’s because
I’m saving the “best for last”. Sort of. Something tells me the Chapter Data Editor is going to be a long
chapter, so I am going to try and keep it as short as I can, but it has a lot of important information
related to map and event editing and creation. All this, after something else. :P

Chapter 39: Loading FEditor Advance

What, I’m dedicating a whole chapter just to loading FEditor Advance?

Eh, it’s not that big a deal, I dedicated chapters to minor modules like the Arena Class Editor. Plus I’ve
seen so many topics on getting FEditor Advance to work that I feel I must make this chapter.

Step-by-Step Tutorial:

1. Go to the Java website. [Link]

2. Download the program by clicking on it. If you are a Windows user, use the online download if
you don’t know what to do. There are instructions on how to download and install Java. For
example, a windows user would look to the right where it says “instructions” and click there,
getting them to this page-
[Link]
 3. Save the file to your desktop or run it automatically. If it is saved, double-click and install. Wait,
why am I typing this, the website gives instructions.
4. Once Java is installed, restart your computer. Just to be safe. There is no harm in restarting your
computer, and I want this to be fool-proof. So do it.
5. [Link] Test your java. It should work. If it doesn’t, re-
install while following the directions.
6. Download FEditor Adv. You can find a link to the topic on my website, or you can just google
“FEditor Adv” and it should show up on Fire Emblem Universe, a bunch of crappy forums.
7. Extract the files. To do this, use 7zip. To download 7zip, go here- [Link] Note
that 7zip files can also be extracted with winRAR. Once it is installed, right-click and hit ‘extract
here’ or something like that.
8. A folder should come up. I suggest you move this folder to wherever you keep your hacking stuff
(as opposed to just lying about on the desktop; organization is key to a successful hack).
9. Open the FEditor Adv folder.
10. To run FEditor, you can either A) click the ‘run’ file or B) go to the dist folder and double-click
FEditor [Link]…
11. It will ask you to open an FE ROM. Open up an English, U.S.A. release GBA Fire Emblem ROM of
your choice. For FE6 (Sealed Sword/Binding Blade/Fuuin no Tsurigi) the ROM should be the
Japanese ROM patched with the translation patch found on [Link]. Please do not ask
me for ROMs, I will flame you. :D
12. If your ROM is edited, it will most likely give you an error message. Just hit “OK” or “Yes” or
something.

Congratulations. You have hopefully followed my overly specific directions and successfully loaded
FEditor Adv. If you have not, I would check the following:

- Program, make sure to have the latest version *ironically, I am using an older version because
FEditor Adv is not compatible with some of my older hack, and yet I am telling you to use the
latest version at all costs*
- ROM, it should be the (U) version. Check the ROM# as well, and for FE6, use the RHDN patch, as
said.
- The ‘cleanness’—if you’ve made massive edits and most importantly edited something that the
program uses to check which FE game it is, that could be a problem. Like the ROM header, for
instance. IIRC FEditor Adv checks something in the header, so if you’ve edited that, it could very
well be a problem.
- Your java. I can only hope you installed it right…
- Your file extraction. If by somehow you extracted it wrong, the files could get corrupt, although
the chance of this happening is very low, I think…

If it’s still not working, then check yourself. No, really, I don’t know what else to do. I can’t write more
than a page on how to load a program. It’d suck if you couldn’t get it loaded, but plenty of people can,
so it’s not the program, at the very least. Sorry if that happens to you. :\
With FEditor Adv loaded, we can now use all of its features! Huzzah!

Chapter 40: Text Editing with FEditor Adv

The reason why this chapter is called ‘Text Editing with FEditor Adv’ and not just ‘Text Editing’ is because
there ARE other ways to edit text, but they are kind of inferior and obsolete. So much so that I am not
even going to cover it in this tutorial, because there is no point in teaching old methods if the old
methods are inferior in almost all ways.

Anyway, open up FEditor Adv. The first thing I see is a Memory and Free Space Manager that I have no
idea how to use. Sounds pretty bad, right? Well, I’ve gotten along without it just fine… That’s probably
the only major thing you won’t find in this tutorial, unless someone else submits a chapter on how to
work it.

Go to Tools-> Text Editor. Bam, text editor loaded. It should look like this:

It starts at text entry 1. It goes as far as text entry 133D. The input index is what text entry is being
loaded at the moment. The max index is as far as it goes-you can change it if you want to, but you
shouldn’t have to change it unless your game is like 40 chapters long and text-heavy.
The find and replace boxes should be simple. You can find some text in the script or you can find AND
replace some text in the scrip. Just type in the text and hit “find”, and hit “find next” to find every other
occurrence after that (find previous obviously just goes back an instance). It works like a hex editor,
except it’s a tex-t editor. “Replace all” replaces all occurrences of something.

I don’t know what the “Use Reg ex?” does. It’s probably not too important.

Now, actually editing text is easy. There are some control codes you should know and stuff but mainly
it’s just loading portraits, typing text, and pauses. I’ll get into the details later, but when you make
changes to text, you have to hit ‘apply’-you have to do this after EVERY ENTRY, not after you’re all done
with text. Wait to press it, you’ll regret it. :P

The ‘revert’ button just undoes applying something. I think. The ‘dump…’ button dumps the script to a
text file (and it asks you where to save it/what to call it). The insert is the opposite, it lets you insert a
dump script. The idea is that you dump a script, edit it, and then re-insert it. And when you’re done with
the text editor, you press ‘Quit’.

Now, about actually making text. You have to load portraits, and to do that, you use the following code:

[LoadFace][0xPP][0xVV]

0xPP is the portrait value. You can find a portrait list in the folder with the character and class editor
modules, and probably some other folders too. 0xVV is almost always 0x01, except for when you’re in a
village, house, or other type of scene. To have a portrait be the portrait of the current character in use,
use [0xFF][0xFF]. So in a village you’d just use that and whatever character is used to visit the village will
show up with their portrait.

However, there’s one more aspect to loading Portraits. Positioning. There are various positions. You just
put the positions right before the [LoadFace].

[OpenFarLeft]
[OpenMidLeft]
[OpenLeft]
[OpenRight]
[OpenMidRight]
[OpenFarRight]
[OpenFarFarLeft]
[OpenFarFarRight]

To move a portrait from one position to another, just change the ‘Open’ to ‘Move. So to move to the Far
Right, you’d do [MoveFarRight]. However, note that when a portrait moves, the way they are facing
does not change, so you have to clear a portrait and then reload it to change position. To clear a
portrait, use the code [ClearFace]. [ClearFace] is also commonly used in special battle conversations;
after every line one character says, their portrait is cleared, because during a battle there is only room
for one person to be talking (lol).

When typing your text, you can’t just type straight through. After about a max of 30-35 text characters
(it depends on how big the characters are), you should make a new line.

01234567890123456789012345

About that long. That’s actually only 26 numbers, but trust me here. However, sometimes if you do this
you’ll have one line that has reached its max length and another line that only has one word. It looks
odd, and so I suggest evening out the length when ‘formatting’ text.

Text text text text text text text

text.

Should become

Text text text text

text text text text.

It’s better for reading and professionality. Another thing that helps a lot with reading is pauses where
you have to press the “A” button to continue the text. To make one of these “blue-arrow pauses” (a
blue arrow appears in the corner when it happens), use [A]. This is best used every two lines, but once in
a while you may make it 3 lines. The original game sometimes has pauses in the middle of sentences,
which is kind of odd and unprofessional, but it means that if you don’t care so much, use [A] every two
lines and whoever plays your game shouldn’t miss any text.

[.] is a very quick pause. Sometimes you’ll see it randomly but it’s not random—just don’t worry about it.
[…..] is a slightly longer pause. [ToggleSmile] makes a character smile, [ToggleMouthMove] makes their
mouth stop moving (used for ellipses), [Yes] asks a Yes/No question with “Yes” selected to start (No
does the same but with “No” to start), [CloseEyes], [OpenEyes], and [HalfEyes] are obvious, and for all
the other interesting codes, just look in FEditor Adv’s ‘doc’ folder-there is a folder called “Text Control
Codes” with codes to use. (Note that the ‘NL’ code is redundant as FEditor Adv automatically converts
the invisible linebreaks into codes for the game to interpret).

Remember all those “text pointers” and “convo values” we’ve seen in Nightmare Modules and the such?
Just type in the values there into the “Input Index” to go right to that text. By the way, Lyn’s mode text
starts at index 813. 

With all that knowledge you’re on your way to making an awesome script. Just make sure to apply after
every change to an entry, and save often just in case. Also, experimenting is the best way to learn!
Chapter 41: Portrait Formatting & Preparation

Yes: like text editing, there are other ways to do portraits than FEditor Adv. However FEditor Adv > all.
It’s much easier than it used to be.

First, you need a portrait with frames and a chibi. I can’t help you with this. This is a spriting thing. You’ll
have to learn how to sprite and make your own portraits or request portraits from others (the latter is a
bit difficult—people don’t wait around for random people to request portraits, most of the time).

Once you’ve got that done, clear up your spritesheet (a sheet with the portrait, normal talking frames,
normal smiling frames, blinking frames, and chibi) so that ONLY the sprites are on there.

Next, we have to reduce colors. Look at your image. The hair should have one set of colors with 3
shades, and the armor should have another set of colors with 3 (max 4, sometimes). Everything else
should be either skin colors or outline colors (there is typically an orangish color and dark brown color in
skins and the outline color is usually a dark purple).

Open up your image in Usenti. If it won’t load, that’s most likely because it is a GIF, and Usenti is a
bitmap editor, so your image must either be a BMP or a PNG to load. PNGs are superior to BMPs
because they are MUCH smaller in size, have transparency capabilities, and when you upload them to
photobucket, photobucket doesn’t convert them to JPEGs and distort the image with fuzziness. (Cough,
BMPs get distorted by photobucket…)

Once it’s loaded, we need to check colors. On the bottom right there should only be one row of colors—
16. Lemme show ya.
See, only one row of colors (look at the bottom left). If it’s NOT like that, there IS a way to reduce colors
without tedious work. However, there’s a limit to how much reducing can be done before the image
changes.

First, zoom in to your image, about 4x or so, so you can easily see the shades of colors and their
differences. Next, go to Palette-> Requantize at the top.
Type in “16” like so.

Hit “OK”. Look at your image carefully to see if the quality has changed a lot. If it has, that means you
have too many variety in colors, and you need to manually use spriting techniques to reduce the # of
colors. Otherwise if there’s no major difference, you should be OK. (Tip: you can use ctrl+z and ctrl+y to
go back and forth between the lots-of-colors and 16 color images and look for differences.)

After that, you need to format your portrait. This is what most people have a hard time with. I will post
multiple methods on how to do this. Also, there is an ‘old format’ which hardly anyone uses anymore,
and a ‘new format’. I will include a few details on both, but mainly the new format.

Tutorial 1: Formatting Portraits Step-by-Step with Layers by Nayr

Note: The following images are used in this tutorial as formats/templates.

Alignments | Standard Format Box

[16:08] NayrLRosfar: step 1: Paste the mug into the hack box on the template.
[16:08] NayrLRosfar: step 2: Copy the mug and hack box and paste into the alignment sheet in
a new layer.
[16:09] NayrLRosfar: step 3: Move the box over until it fits into one of the alignments, find
the one that fits and copy paste under the red box on the mug. That'll copy the proper
frame alignments.
[16:09] NayrLRosfar: step 4: Past into the appropriate spots in the template. Repeat process
for mouths.
[16:10] NayrLRosfar: step 5: Copy/paste the eye blinks, mouth flaps for talking, and smiling
[frames] into their appropriate places on the frames. Edit to fit if splicing in from another
mug.
[16:11] NayrLRosfar: step 6: Paste in the chibi in the box above the blinking frames.
[16:11] NayrLRosfar: step 7: Merge all layers down on template and remove the background
color or fill it in completely.
[16:11] NayrLRosfar: step 8: Optional. Double check to make sure there are no stray colors
that could prevent insertion.
[16:12] NayrLRosfar: step 9: save as [a 24bpp] png

Tutorial 2: Video Tutorial on Portrait Formatting by Flyingace24

Video Link

Tutorial 3: Video Tutorial on Old Formatting by Blazer

Video Link

Hopefully those tutorials have taught you how to format a portrait. Now you have to insert your
portrait, so get ready!

Chapter 42: Portrait Insertion with FEditor Adv

This will be quick and painless, assuming you’ve done everything right so far.

Open up FEditor Adv. Go to Tools-> Portrait Editor.

At the top we see the formatted portrait with its frames. In this case, it’s the ‘dummy’ portrait. Below
that we see what it actually looks like. The input index is which portrait you are viewing. You can type in
a value from a portrait list to go right to a portrait—for example, the portrait says Lyn’s default portrait
is 0x16, so we type in 16 and go to hers.

The ‘max index’ is just how many portrait slots there are.

‘Eyes always closed’ makes it so that the portrait’s eyes start off as closed. You can have this same effect
by just using the closed eye frames for the open eye frames, too, if you wanted.

I wouldn’t mess with the palette editor (the colorful boxes).

‘Load from File…’ loads a portrait (I think only BMPs and PNGs work). ‘Revert’ will undo a portrait load.
‘Save’ saves it. ‘Save to file…’ saves a portrait to a file. However, when you save it, you have to add the
extension yourself (so to save Lyn’s portrait as a png, type “[Link]” or something). ‘Quit’ is kinda
obvious…

What we’re going to do is hit “Load from File” to load your formatted 128x112 16-color portrait with
proper formatting and saved as a PNG. (Tip: make sure it’s everything I just said, and if your insertion
doesn’t work, go back and make sure it’s everything I said again.) If it’s done right, it should show up in
place of the current portrait.

Hit “save” to save. Then hit “quit” to exit out of the portrait editor.
Now go File-> Save to save your ROM per usual. Portraits almost never cause a game-breaking crash so I
wouldn’t worry about backing up before portrait insertion (as opposed to bigger less foolproof stuff like
animation insertion, graphic insertion, or event insertion).

Test it out in VBA and hopefully it looks nice! Enjoy your new portrait! ^_^

Chapter 43: Locating Palettes

Wow, we’re already on chapter 43. I’ve only been working on this for a couple of days...

Well, it’s about time we learn how to find palettes. First of all, re-read the definition in like, the first
chapter. Once that’s done, open up your hex editor of choice, mine being HxD, and open up VBA.

Play the game until the palette who you want to find in your hex editor shows up. I’m going to be really
simplistic and edit the title screen palette of FE7.

Alright. We’re going to look for the bluish/purplish background’s palette. Go to Tools-> Palette Viewer in
VBA.
The palette we want to edit is the one at the bottom left. Palettes are in rows, so it is the bottom row in
the “Background” area of palettes. By clicking on a color, we can see it’s Address (where it is in the
RAM—RAM is memory, a temporary place for storing data), it’s RGB (Red, Green, and Blue values used
to make a color), and value in hex.

The RGB values are on a 0-31 scale. Normally people use a 0-255 scale, but the GBA is sort of limited.
That being said, just multiple each value by 8 to get the RGB in “standard terms”. So for the color I have
selected in the image above (a transparent green color), I multiply the RGB (16, 20, 16) by 8 to get
(128,160,128). Keep this in mind for later.

The value is the hex value of the color. The game uses little endian, so if we want to know its value, we
have to reverse the order of the bytes first. So 0x4290 becomes 9042. That’s only one color though, and
we can’t find a palette by just one color. So get 3 more colors, so we have the first 4 colors used.

9042 987F 567F 147F

Sometimes doing more than the first 4 colors can be dangerous because of compressed palettes.
Compression makes it so that you can’t just search all the colors in a row, because there are other bytes
(usually 00s) in between.

Now use a find command (typically ctrl+F) in your hex editor and search for those bytes. (Tip: starting a
search from offset ‘0’ is the best because it searches the whole ROM. If you start a search at some
random offset, you can often times only search either forward and backward, and will have to do
multiple searches, and waste time.)

With that ready, do a search. My hex editor automatically takes me to where it finds those bytes.
This palette is uncompressed. How do I know? Here are some easy tricks to recognize LZ77 compression.
Of course, when you don’t recognize it, that means that it’s not there.

Recognizing LZ77 Compression

1) Standard LZ77 compression starts with a ‘10’.

2) After that it has two bytes saying the size of the data. You’ll see common sizes and recognize them
quickly through experience.
3) A ‘00’ byte every 4 bytes. (This does not hold true all the time, but usually at the beginning of LZ77
compressed data, you’ll see this pattern.)

That’s all I have, actually, but if #1 and 2 don’t tell you almost instantly, then #3 won’t be too useful
either (but it’s a good check to make sure).

Anyway, this makes it easy on us. We’ve now located the palette, and even if it were compressed, we
still could have located it because we used a safe method.

One last thing. Sometimes there are multiple instances of a palette. Use a “find next” feature (or just do
ctrl+f again from where you are) and you may find another instance of the same palette. There’s only
two ways to know which palette is which if the whole palette is the exact same. You can A) just edit
both and see what does what or B) debug. The latter is probably not within your skills, especially if
you’re reading this tutorial to learn how to edit palettes. (No offense.)
Chapter 44: Editing Palettes

There are multiple ways to edit palettes and find the values to change them to.

Method 1: Editing Uncompressed Palettes with SNES Palette Editor

SNES Palette Editor works fine for GBA too, trust me. Download it from google or something and open it
up. Load your ROM and go to the offset where your palette is (we already located the palette in the last
chapter). Make sure your palette is uncompressed. See my guide in the previous chapter for telling the
difference between compressed and uncompressed.

YESZ! We can clearly see the colors and their values. We can even see the Raw Color value and the RGB.
If we wanted, we could even do searches for colors, but that’s not really my thing, so I didn’t cover that
in my previous chapter’s instructions.

To edit the color, we can drag the bars left and right until we get the color we want. To change which
color we’re editing, we just hit the ^ arrow next to the “Address:” slot/the offset. If you want to use a
specific color, you can get the color’s RGB from MS Paint or some other program (this is a spriting thing
really…), round each value to the nearest multiple of 8, and then divide.
However, converting colors like this can sometimes be a pain, and this method only works for
uncompressed palettes, unfortunately.

Method 2: Getting the RGB of a Color and Converting to Hex

I don’t exactly have a color I want to use for this title screen background, so I’m just going to show you
how to get the RGB of some random color on a portrait.

Load up MS Paint or another program, zoom in, and use the eyedropper tool to select the color you
want to find the RGB of. Often times you can see the RGB off to a window on a side for programs like
Photoshop or Corel Paint Shop Pro. I’ll just show you how to do it in MS Paint:

(You can’t see my eyedropper, but I’m about to select the light orangish/brownish color.)

After it’s selected, go to Colors-> Edit Colors… and hit “Define Custom Colors” so that the following pops
up (except with whatever color you’re using):
To the far right you can easily change the shade of the color to something lighter or darker. You can also
pick another color from the rainbow-like area. What’s most important is the RGB: it is 248, 208, 112.

With this, we can A) round it (it’s already rounded, actually…) to the nearest multiple of 8 and divide by
8 to get the RGB on a 0-31 scale, then put it in SNES Palette Editor or B) put it into GBA Color Picker and
get the hex value to use with SNES Palette Editor or a hex editor. We’re going to do B.

Download, extract, and open up GBA color picker. Put in the RGB for your color and it’ll get the nearest
match—and it does the rounding, too.
We now have the hex for this color—3B5F. If we put this in a hex editor to replace another color though,
we have to reverse the order as usual. You can hit the “Byteswap?” checkbox in GBA Color Picker if you
want, but it only does it once, meaning if you edit the RGB input, it’s not going to byteswap it again (you
have to click the button everytime to byteswap, pretty much).

By the way, GBA Color Picker crashes if you leave one of the RGB slots empty (without a value). So don’t
use backspace to delete the numbers there or it’ll freak out and crash.

So we take the color we’re trying to replace and put in the hex we got. We use this for every color until
we’re done. We can use this to replace uncompressed or compressed colors as since we’re humans, we
can just skip the ‘00s’ that occur every once in a while in compressed palettes and only replace the bytes
that are actually color bytes.

Method 3: Editing Palettes with GBA Graphics Editor

This method involves Nintenlord’s GBAGE. Hopefully you know the very basics of how to work it—have
Net Framework 3.5 or higher installed (or Mono, the Linux/other equivalent), how to load a ROM, how
to save, and how to input offsets and navigate through images.

After loading GBAGE and your ROM, we need to locate the image you want to change. You can scroll
through all the images if you want, you can find out the offset by debugging, you can find it by logic and
a hex editor (the palette and the offset are often close to each other, so if you find the palette the
graphics might be nearby—it’s up to you to search in a hex editor and find it, not me), or you can see if
someone else knows. I happen to have some FE7 offsets, but I’m pretty clueless on FE6 and FE8, so
you’ll have to “manually” search those games by scrolling through the images (or you can just use
another method to edit palettes…).

Anyway, I happen to know that in GBAGE the title screen background image is at 1369 (offset 66AF8C).
The preferred size is 30x32*. We already located our palette at 66AF6C, so we put that into the
“ROMPalette Offset” slot of the Palette Control… hey, wait, that’s only 0x20 bytes before the graphics!
Oh look, that stuff I said about logic before was actually kinda helpful maybe!

*30x20 will work too. The size is just the # of tiles the image is, with each tile being 8 pixels. The screen
is 240x160, and 240/8 = 30 and 160/8 = 20, but it doesn’t matter how large you make the height
because there aren’t any graphics to load anyhow.
If you’ve done everything I told you, it should look like that. Actually, it looks kinda weird, doesn’t it? The
top left tile (8x8 pixel piece) is missing, and it’s in the bottom left… The reason why the game does that
is because it recognizes the first pixel it sees as transparent, and the first pixel would normally be a blue
one, so it uses this image where the first pixel is green (the transparent color). To make up for the
distorted layout of the graphic, it uses TSA. I suggest you read up on the battle background and CG
chapters for this to make more sense.

Anyway, back to relevant information. We have the palette loaded. We can save the image as a PNG,
edit the colors using Usenti by changing the RGB values to what we want (click on the colors in Usenti
and just put your own RGB/use the scrolly thingies), save the image, and then re-import it. When you
reimport the image, all that matters is that you replace the old palette with the new palette.
Yup, I wouldn’t even have anything else checked. Once you import the palette, save your ROM, and you
should be done.

With that, we’ve found our colors and replaced the old colors and made our palette changes. After
saving, we can load VBA and check out our palette changes to see if they look good, turned out right,
and give us a refreshing feeling.

If something didn’t work right, make sure you:

- Didn’t overlap changes (change with one program, then change with another without
exiting/reloading and all)
- Forget byte reversal when typing in the hex, or even do byte reversal twice
- Forget to convert properly (dividing/multiplying by 8, inserting the right values into GBA color
picker)
- Edit the wrong colors (use the palette viewer to help know which colors you are editing)
- Edit the compression bits (be sure to avoid 00’s unless they are part of an actual color—
remember, 00s come about every 4 bytes).

Wooh! We’re done!

Chapter 45: Working with GBAGE

Here we’re gonna learn a little bit more about graphics, palettes, and TSA. Just a little bit more.

Load GBAGE and your ROM, to start.

There are 3 main things you can input into GBAGE. The offset, palette, and TSA. The width and height
can be adjusted to make the image look good. I’ll say it again just to make sure you know it: size is in
tiles, and tiles are 8x8 pixels, and the GBA screen is 240x160.

You can dump and insert/load raw graphics. It’s like the raw hex for it. You can’t SEE anything unless you
save it as a bitmap, however.

If you’re editing uncompressed graphics (just uncheck the ‘compressed’ button, although you have to
know where the uncompressed graphics are) you can scroll through it by hitting the +/- block, +/- line,
and +/- screen buttons. You can load palettes the same as normal as well.

When you save a bitmap, it’s best to save as a PNG, because PNG is one of the best common image file
types out there in both functionality and size. You can then edit the image; however, I have to warn you
about tampering with it too much. If you add colors to the image and save it, it’ll mess up the palette. If
you insert an image with more than the original amount of colors, it’ll overwrite data AFTER the palette.
Furthermore, sometimes images may appear to use more than 16 colors, but don’t actually—it’s all a bit
tricky so just be safe with what you’re doing and constantly back-up as mistakes in graphical editing can
easily lead to a completely messed up and glitch ROM (in the most unpredictable ways).

Similar things can happen with graphics. This is why when you check the ‘Import Graphics’ or ‘Import
Palette’ button in GBAGE, also check the ‘abort if bla bla’, because it stops GBAGE from overwriting
data. If it DOES abort, there is an easy way to insert your data without much fuss. Just find some free
space (I manage mine pretty well so I know where I have free space in my ROMs) and put in new offsets
for your data, then hit “Repoint X pointers” to repoint the graphic or palette pointers. This will insert the
data without worry about space and then repoint the graphic or palette so the game knows where the
new data is.

Another thing: it is VERY good to document what you find and change in GBAGE. I don’t spend my time
bolding stuff unless I mean it. If you write down cool graphics you find while scrolling through, you can
just go back to your list of graphics and what image # they are and be like “hey, I want to edit that”, then
go to the image and do what you want with it. Also, when you repoint stuff, you’ll want to know where
it is in case you need to go back and do stuff to it.

This includes palettes! Finding palettes isn’t the most fun thing ever. You might as well take 5 seconds
out to write where the palette is so you save yourself 5 minutes later on. *even though it only takes me
like 30 seconds to find a palette most of the time*

That being said, I have a little documentation for FE7’s graphics. Nothing for FE6 or FE8 not because I’m
biased, but because I’ve just never hacked those as much. Oh wait, that could be considered bias…
teehee. I only made one hack of FE6 so far and haven’t done much with FE8 except for importing data
from that game for my hack Fire Emblem: Sacred Contention.

Graphic Documentation
----------------------

#s for use with GBAGE

FE7
----

800 - Levelup
802 - Numbers
805+ - Map Effects, Staff Anims?
825 - "To Be Continued"
826 - "Game Over"
835 - Statsheet Related Stuff
836 - " "
839 - Arrows
846 - Chapter Title Bar? (Menu?)
847 - Chapter Title Bar (When Starting Capter)
848 - "Game Over" again
849 - Letters
854 - "Help"
855 - Misc. Graphics
857 - Arena Menu Stuff?
860 - Weapon Type Icons
861-862 - ^Same, but scrunched up and split apart
865 - Another background
866 - Vertical Arrow in statsheet (not sure)
867 - Above, but horizontal
868 - More Text
874 - Star
879 - Main Menu Graphics
880 - ^Same
883 - Sound Room Graphics
884 - Mode Select Stuff
898 - "Personal Information" Scroll
900 - Main Menu BG, Statsheet BG
904 - Class Roll Primary Weapons Graphics
906 - Another Text Font
907 - Another Text Font
(CGs between here)
1099 - "Fin" Text
1100 - Player Ranking Text
1101+ - Credits
1135 - Intro Text
1153 - 2003 Nintendo Presents
1154 - Various Weapons that circle around in opening
1156+ - Water Droplet Animation
1187+ - Opening "CG" Backgrounds (broken up into many pieces...)
1273+ - Misc. Opening Effects (I'm guessing, anyway)
1368 - "Fire Emblem" Shadow
1370 - Sword, "Fire Emblem", "Press Start", and Copyright Graphics
1371+ - More
Misc. Effects? Thunder sparks are here...

1376+ - Beginning of Portraits/Chibis.

Wait! I have more!

Arena Dialog Background

-------------------------

Image Data at 0x3EFA3C

Image #797 in GBAGE, data is LZ77 compressed

TSA at 0x3F2618, uncompressed

Palette at 0x3F2ACC, uncompressed

Battle Preps/Miscellaneous Background

--------------------------------------

Image at 0x407440

Image #865

Palette at 0x40D130

Menu & Statsheet Background

----------------------------

Image #900

0x418E44

Palette at 0x41E2D8

CGs
----

Start at around image 922, first broken up into 240x16 pieces, then total CGs, TSA and battle
palettes can be found at CG table, please see CG editor or other doc for more information.

Opening Text
-------------

Starts around image #1135 offset 0x5E9D4C

 Fire Emblem Shadow
--------------------

Image #1368 0x66AB48

Title Screen Background

------------------------

Image #1369 0x66AF8C palette at 0x66AF6C

Armads at 0x66F294 Image #1370

"Fire Emblem", Shadow, Sword, misc.

stuff at Image 1371 offset 0x66FD80

^Palette at 66FCE0 (note: multiple palettes for different parts, change the palette index appropriately)

OK, that’s all I have to share with you.

I think I’ve said enough about that topic then. Next, about palettes—there are different graphic modes.
GBA almost always uses 4bit, so unless you’re an NDS hacker *like me*, I wouldn’t worry about it too
much. I don’t think any images use 256 colors (which would be 8bpp), nothing definitely uses Truecolor
or Indexed bitmaps, and the only other graphics are ones that use 2bpp and lower which isn’t included
in this tutorial as GBAGE doesn’t support it (and it’s not very useful).

“Gray scale” makes it so that the image is grayscale. This is sometimes useful. It’s most useful when
you’re scrolling through images trying to find out what they are. If it’s set to grayscale, it’s easier to see
the details of an image and make out what it’s supposed to be, as opposed to using some palette with
weird colors.

If you load a palette that is compressed, just click the appropriate button to load it properly. Else, said
button will be greyed out.

The palette index is for palettes with multiple uh… indexes. Sometimes there are alternate palettes for
an image that can be loaded with the ‘palette index’ button (for example, map sprites). You can quickly
scroll through these by clicking the up/down arrows next to Palette Index.

Oh wait, there’s a way to edit colors in GBAGE too, I forgot! You can use the Color Control box and type
in RGB (has to be divided by 8 though) to edit colors. I’m not really good with it, so you’ll have to
experiment with it yourself if you want to use it…
Now, onto the last menu. Tile Control. You can choose to use TSA and, if the TSA is compressed, you can
choose to load said compressed TSA.

The “amount of bytes to ignore for displaying” is a feature used to skip tiles to align images. I can’t
explain it too well, but sometimes if an entire image seems to be off a little bit, either adjust said feature
or the size. Usually you’ll see a weird tile at the top-left corner or everything will look like it’s shifted a
little when this is needed.

You can even manipulate the tiles with GBAGE. “Tile index” is which tile you want to select, starting
from the top-left, going to the right and then down the rows. You can flip the tiles horizontally,
vertically, make them use another graphic by altering the graphic number, or make a tile use another
palette in the index by adjusting the Palette index. This is extremely useful for TSA hacks—however,
newer versions of GBAGE don’t let you edited compressed TSA, in which case you will have to use a
decompressor to decompress the TSA separately and then edit it.

I realize that this part is a bit more difficult than the other aspects of GBAGE, and so I’m going to help
out a little. First of all, you need to use TSA, and if it’s compressed, hit that button.

While I’m at it, you may be thinking “how do you even know where TSA IS?”. There are several ways to
find TSA:
1) Find it in a pointer table/array. For example, the Battle BG Array Editor (it’s a nightmare module)
has a list of graphics, palette, and TSA for battle background.
2) Use debugging. If you don’t know how to debug though, this won’t prove to useful.
3) Look using a hex editor. Often times TSA, palette, and graphics are all right next to each other. In
fact, most of the time they are. Thus it wouldn’t be surprising to find TSA data right after the
palette data, for instance. Being able to recognize different types of data is a skill you’ll develop
over time just by experimenting and studying—it’s mostly as simple as looking for patterns.
Anyway, back to editing the TSA. You can click anywhere on the image and select a tile like that
(probably preferable), or type in a “tile index” to select which tile to edit. The “Graphics” slot dictates
which tile should be used at this spot in the graphic.

It’s like this:

The raw graphics are a bunch of building blocks.

The palette is the paint.
The TSA is the map telling which blocks go where.

However, not only can the TSA tell which blocks go where, but also control how they are placed—which
you can change by clicking “horizontal” and “vertical” under Flip—and reuse blocks an infinite amount of
times. It can even specify which palette a tile uses, which can be changed by clicking up or down on the
“palette” box. This makes it so that a 16 color image can be more than 16 colors by having different
parts of the graphic use different palettes and thus different colors.

Here you can see that I’m editing the tiles at the bottom right. I’ve not only flipped them but I made one
of the tiles (the tile being highlighted) use palette “1”. Unfortunately palette 1 is just a dud—it’s just a
bunch of 00’s there and 0000 = black, so we get a black box, but it still illustrates how the Tile Control
menu of GBAGE can edit TSA to change how images are displayed in-game.

There is one other use for changing the palette. If you’re not sure what tile you are editing, you can
change the palette quickly and spot the tile that changes palette—that’s easier than trying to tell which
tile was just flipped or something.

Now, let’s get some practice with the title screen menu background. I’ll tell you where the graphics,
palette, and TSA are, so load them into GBAGE. Note that the graphics are compressed.

Graphics- [Approximately] Image 1369, Offset 0x66AF8C

Palette- Offset 0x66AF6C
TSA- Offset 0x66EDC0

Once that’s done, you should see the following in the image panel:

WAIT! I CAN EXPLAIN!

First of all, there’s an extra tile there that is causing some problems. We can use the ‘ignore bytes’
feature to get rid of that. Ignore two bytes (the equivalent of one tile).
That should look something like that.

And that’s how that should look. Yes, it should look like the whole image is flipped upside down and
every row is also flipped upside down. The reason why is because the game undoes these flips. I don’t
know why, but it’s the truth. The game initially processes the image like this, and then it undoes the
flips. It’s a result of uncompressed TSA—compressed TSA is not flipped like this, meaning “what you see
is what you get” with compressed TSA. If you’ve done the chapter on battle backgrounds, you’re familiar
with compressed TSA already.

If we really wanted we could flip each tile and change the order manually. But as I said, that isn’t
necessary, because the game does that for us. Still, we can practice manipulating TSA by changing
random tiles. Just click on a tile and edit the ‘graphic’ part, flip it both ways for the lulz, and edit the
palette. Just so you know how it works.

Here’s one more example of how this works, just for emphasis:
And my results (the tile at the top):

That’s just to show you what I mean. And with all that practice and explaining done, you should now
have a decent grasp of editing graphics using GBAGE, or at the very least, you should be less intimidated
by all the features popping out at you!

Chapter 46: Chapter Data Editor

Finally, this chapter. The chapter on the chapter data editor, the only Nightmare Module that Blazer
hasn’t covered.

Open Nightmare, your FE ROM, and the chapter data editor. We’re going to do this.

Chapter Reference Pointer… eww. I wouldn’t worry about it. So far no one has (publicly) shown that this
is useful to anyone.
Object Set 1, Object Set 2, Tile Configuration, and Palette are all important and all related. They are
properties of the map’s tileset (see definitions for what a tileset is). For a map to work properly, these
settings have to be right. If you make a field map, you have you use the field object sets and tile
configuration. The palette can be changed, but it can only be changed to a palette that is labeled as
‘Fields’. For example, palette 0x1E is fields, and palette 0x17 is Fortress&Fields. They are TOTALLY
DIFFERENT. You can only use something marked as ‘Fields’ and solely fields.

To know which tileset settings you use, you have to look at the name of the tileset you used to make
your map. If you used tileset 0A000B0C, then you set object set 1 to 0x0A, object set 2 to 0x00, palette
to 0x0B, and tile config to 0x0C. If you take a look, all of those bytes are marked with “Plains&Castle”, so
they should work together. Keep this information in mind as it is important for when you make your
map (although I’ll probably repeat myself and tell you what it is again anyway).

The map is a byte that reference the Event Table that says what map to use. You can change this to any
other map if you want, but remember to change the other settings as well to match whatever map you
change it to.

The tile animations are for changing tiles like water tiles. If water tiles were still they’d be slightly less
cool, so we have tile animations to make them move. It’s kinda obvious what to put for what map.

Triggerable Map Changes are for tiles that can change into other tiles. For example, when you open a
chest, it changes from a closed chest tile to an open chest tile. Same thing with doors and breakable
walls. The data for these changes is at an offset in the Event Table, and this byte references the Event
Table.

Vision Distance is for Fog of War (FOW). If it’s ‘0’, it’s assumed there is no fog of war.

Preparations Screen can be disabled or enabled, but ultimately if you do not set up the events to match
the settings, the Preparation Screen will not load regardless of what the byte is (your game might crash
though).

Weather is kind of obvious, except some values don’t exactly work right. Thus I only suggest using the
Snow, Rain, or if you’re in a firey area, Fiery Glow weather effects.

The battle tileset is for which battle backgrounds/tiles to use. For a foggy map or a night map you’d use
different tiles, of course. This changes that. If you’re not sure what to use, set it to something that
sounds right, and then test it out until you get what you want.

The Phase music choices are the map themes for the different phases. I wouldn’t touch the Secondary
Player/Enemy phase things, mainly because I don’t see a need for them, I don’t know what they do, and
I don’t recall them even being used (they probably are used SOMWEHRE, idk where though).
The Worldmap Chapter Prologue music is for when you start a chapter and you’re on the world map and
it goes over recent events and stuff.

The opening music is kinda obvious, it’s just the music that starts when you begin the chapter and the
first scene starts.

Destructible Walls HP is just how much HP the walls have before they get broken down.

The tactics stuff is tactics stuff. I really don’t give a crap about tactics and all, but if you want to change
it, it’s there for you.

The EM/HM Chapter Number Text is the chapter with the # in front of it, which you see on the main
menu. The ‘Chapter Name’ text pointers are the ones with just the name that you see in like the Status
Menu and stuff.

The Event Data Reference is a byte that references the event table and tells the game which events to
use. Same thing applies to Worldmap events (labeled “Worldmap Chapter Prologue Scene”).

The Pre-Augury text is what the fortune teller says before you pay. After that is the actual augury text
(and it can change for each mode, of course) and then there’s the Post-Augury Text, which is what is said
after the augury is all said and done.

The Augury Portrait is just what portrait to load for the Augury… either that old lady or Nils, typically.

Augury price… obvious.

The chapter no. thing is for the battle preparations. It says at the top what chapter you’re playing.
Unless you reorder the chapters (like say, make chapter 7x into chapter 8, and so on) then you probably
won’t need to deal with this.

The Merlinus Co-ordinate is where Merlinus’ tent starts off. It’s in the chapter data editor because you
don’t get to reposition Merlinus during battle preparations.

Enemy count for Winning Road is so obvious…

When the chapter begins, the game either fades to black, or fades to the map. This is important when
you are making your events, but we aren’t to that point yet, so I’ll leave it be.

The status objective text is for the status menu. The text is a little bit longer and a little bit more
descriptive than the Goal text pointer, which is usually just two words, like “Seize throne” or “Defeat
enemy”. By the way, this just changes the text, not the actual goal. The actual goal is a part of events.
You can also choose what information the game should display in the corner. If you don’t want anything,
0x00 is fine.

If there’s a turn limit during your chapter, you can display it. If you need to defend for 13 turns, type 14.

If you have good memory you may recall that Natalie in FE7 has a blue symbol because she is a character
that is supposed to be protected. You can give this symbol to any unit in the chapter. It’s kind of cool, I
guess. This is the “Protect Character Marker” dropdown that I’m talking about.

Lastly, in chapter 28 (Eliwood) or so I believe, when you’re getting Durandal, there is an arrow that
points to a certain tile you are supposed to wait on. You can set this arrow to be anywhere by giving it
some co-ordinates on the map.

Well, that wasn’t so scary, except for the fact that I had to type almost 3 pages of explanations and stuff.
The chapter data editor is most important when you’re doing events—you have to change the goal text,
sometimes do special attributes (character marker, tile marker), the augury text, chapter numbers/text,
set the events, and most commonly set the map settings to the right ones.

HOLD IT! (Unless you aren’t hacking FE7!)

After Final Chapter: Light (pt2) are some cutscene/miscellaneous maps. They are chapters that are
loaded through events during cutscenes. For example, when Rath joins at the end of chapter 7, I believe,
you see some village/town. This map is a cutscene map—it only appears in a cutscene. However, you
can use these spots for either your own cutscene maps OR your own chapters. Chapter 0x41 (it’s
actually 0x42, but NMM has the prologue as 0x00 when it’s actually 0x01) is actually the link arena
‘chapter’, however, so I would refrain from editing that. Anything before that and after the final chapter
part 2 is safe game. *Unfortunately the chapter data editor for FE7 is not compatible with the ‘extra
chapters’, and I myself don’t have time to make the proper updates…*

Chapter 47: Map Creation

I’m tired of writing this tutorial. Honestly. So from now on, I’m going to stop making so many wasteful
comments like the one I am typing right now.

First of all, download Mappy and the appropriate tilesets. Go. Do it. Google “Fire Emblem Mappy Map
Editor”, or look on my site. No excuses.

Extract the files as usual, blab la. Depending on what game you are hacking, there are different tilesets.
As usual this hack is FE7 oriented and I will be using FE7 tilesets to make an FE7 map for insertion to FE7.

Open up Mappy and make a new map. File-> New.

Your settings should be as follows. All GBA maps use 16x16 tiles. The smallest size is 15x10; the biggest
size differs for each game or something. FE7’s biggest size is 43x36. I am going to make a very small and
simple map for this tutorial. When you’re done with the settings (should take 10 seconds) hit “OK”.

A message will pop-up. Read it, but don’t do anything. Mappy should look like this:

But not for long. Do File-> Import… or hit Ctrl+I. Select a tileset, and only ONE tileset.
I am going to use the fields tileset, 1C1D1E1F. Note the name of the tileset you use. It is very important
that you have this for later.

Thus I click “open” and load my tileset.

I now see a bunch of tiles to the right. You should too.

I can use these tiles to make a map. I will make a very, very simple map, because I am just testing—
making a simple map is good in case you mess up and need to restart from scratch. Learn how first, then
you can spend time with fancy map making later.

Despite this, I’m going to teach you the fundamentals to map-making:

- Drawing a rough draft/doodle can be very useful.

- Reference other maps to make maps properly.
- Don’t spam/abuse tiles.
- Think about realism.
- To actually use a tile, click on it on the right and then click on it on the map area.
- You can hold your mouse and drag to apply a map tile in multiple places.
- Ctrl+Z undoes the last change you made. You can only undo one change.
- Don’t use glitchy or black tiles.
- Make sure to shade castle maps. Remember, walls make shadows, so tiles next to walls need
the appropriate shading on the left and top.
- Look at elevation and make sure it is correct.
- “Grass patches”—different colored grass—helps make grass look less bland.
- Don’t abuse fortress or pillar tiles like some people do.

Once you’re done with your map, save it. Here’s what my real quick test map looks like.

Before we move on, I am going to cover some of the functions in Mappy (mainly the ones you will use).
File-New Map – makes a new map.
File-Open – opens an FMP/map.
File-Save – saves a map.
File-Save as – saves a map as a different file/as a copy.
File-Import – imports a tileset
File-Export – I will cover this in a minute.
Edit-Undo – undoes a map change.
MapTools-MapProperties – tells you the properties of a map (the size, tilesize, and other stuff)
MapTools-Resize Map – lets you change the size of a map and add rows/columns based on where the
‘center’ of the map is. To add columns to the right and left, center at ‘1’. To add columns all around,
center at ‘5’. To add columns to the left and right, center at ‘9’.
MapTools-Grid – turns grid on/off. Alternatively use Ctrl+G.
MapTools-Zoom (X) – zooms a certain amount. Useful for analyzing tiles.

We are now going to export the map as two things. We can do each export separately, or both at once.
The latter is more convenient. Start by doing File-> Export.

Check the things marked. The .MAR is for hacking purposes. The “current layer as big picture” exports
the picture of a map as a BMP. If you want to share it with others, I suggest you resave the image as a
PNG first. The image will have the extension ‘scrn’ at the end and be located wherever the FMP is. Same
thing with the .MAR.

After you do this, save your map, and we’re done with map creation!

Chapter 48: Map Insertion

Now that we’ve made our map and have a .MAR, we can insert it into the game.

First we need to insert the .MAR. Thankfully the awesome Nintenlord made a program that does it for us
(yes, you used to have to do it manually, and man was it a pain). It’s called the MAR Array Inserter. Like
many other things, you can find it on google or on my website. It’s a simple but useful program.

When you first open the program it should look like this. Please note that like all of NL’s programs, you
have to have the Net Framework or Mono installed… this should already be done if GBAGE worked for
you and all.

Use the “browse” button to locate the MAR file that we just exported. Use the browse button below
that to navigate to where the ROM you are going to insert to is.

Now you need to know the size of your map. If you don’t already know it, you can go into Mappy, load
your map, and use MapTools->MapProperties or MapTools->Resize and it’ll tell you the size of your
map. Anyway, enter that into the ‘Map size’ slot.

Lastly, we need some free space to insert to. Let’s say 0x1009100 is empty so we are going to insert our
map at that offset. This is just my example though—like always, you need to know your own free areas
and manage them so you don’t overwrite data and stuff.

Once you’re done inputting the info, it should look something like this:
Except with different offsets and stuff. If you notice, I label the map I am inserting with its size
beforehand so I don’t have to go back and look it up.

Anyway, once that’s all set up, we hit “run”, the program says “Finished”, and the map is inserted, so we
can exit the program.

Now we have to fix up our tilesets. I was smart and I wrote down before what tileset I used for this map:
1C1D1E1F was the name. These also happen to be the bytes I use in the Chapter Data Editor. It’s pretty
nifty. So let’s load Nightmare, our ROM, and the chapter data editor.

In my case I’m inserting over chapter 18/19 (I’m actually killing two birds with one stone and doing legit
hacking ATM), but it works all the same for all the maps. Currently it’s set to 0A003A0C for a Plains and
Castle map. I’m going to have to change those bytes to 1C1D1E1F. And bang.
Remember! The maps palette can change to anything in the same set, but nothing else can change! You
can’t make a map meant to be an outdoor field map and then use castle tiles. It just won’t work.

Hit enter/apply your changes in Nightmare and save. Now we are going to use the Event References
module to repoint the old map to our new one.
Alright. I loaded the module and scrolled down to the chapter 18/19 map pointer, since that IS what I
am changing. I see some pointer that I don’t care too much about. I’m going to repoint it to my new
map. Since my new map is at 0x01009100, the pointer is +0x08000000 to that, meaning 0x09009100. So
that’s what I type. I hit “enter” to apply changes and then save. I’m done!

Congratulations, you’ve inserted your first map! I hope you enjoy it!

If you’re looking to make a totally new chapter (instead of being limited to the old game’s EXACT same
scenes with EXACT same events) then read on, because I’m going to hack events next!

Chapter 49: Event Assembler Basics

There’s two main ways to do events. You can do them straight in hex with a hex editor, or with the
Event Assembler. The Event Assembler is much easier, so I’m going to cover this.

First, some things to start you off:

- EA = Event Assembler
- STLB = Standard Library = the standard definitions included with the EA
- EALF = Event Assembler Language file = the text file with all the EA codes you can use.
- Assemble = use the Event Assembler to interpret the codes in a text file and turn it into hex that
the game comprehends.
 - Disassemble = Opposite of assemble, take the game’s events and put it into a text file with
codes that you can understand.

You should of course know what pointers and offsets are. While knowledge of programming languages
can be useful, it is not by any means necessary.

Download the Event Assembler and extract its files as you would any other program. I’m now going to
tell you about the basics of event assembling.

The program itself isn’t going to be used much. Open it up and see for yourself.

The input is either where you put the text file (for assembling) or the ROM (for disassembling). You put
the opposite thing in the output (so for assembling, you’re going to output a ROM, and for
disassembling, you will output a text file).

Obviously you have to choose which game you want. When disassembling, you need to input an offset.
The offset can either be an offset a pointer in the event reference table, or it can be the actual ‘header’
of the events. The header is a list of pointers saying what event data is where. If you are going to point
to the latter, you need to select the appropriate checkbox.

I would just always add end guards since it’s not something you need to worry about too much.

Of course, when you have your correct input and settings, click “assemble” to assemble or
“disassemble” to disassemble. This is how you work the EA. You’ll likely reference this part of the
tutorial later because you’re not actually going to do any assembling for a while.

Your event assembler folder should look like this, but without the NewMacros file or template file.
“Language raws” is a folder of the EA assembler language raws… as in, it defines what code is what/it’s
hex equivalent and the format of the code, as well as some other stuff. You can change it if you want.

EAstdlib is a library of standard EA definitions. You can edit it if you want, but since it’s the standard
definitions, it’s not exactly supposed to be edited. If you look at my icon, it shows a notepad in it. That’s
because I have set .event files to open with Notepad so I can edit them. Yes, that’s right—to edit the file,
just open it in notepad.

Now, what exactly are definitions? It defines stuff. It can define a name for a value—for example, Lyn’s
character hex is 0x2D, but instead of typing 0x2D, you could type ‘Lyn’ in the event assembler. This is
easier than remembering the hex for every character/having to look it up. Tutorial (i.e. Lyn’s mode) Lyn
would be Lyn_t. As said, you can view the files and see the definitions for each game.

#ifdef _FE8_
#ifndef _NO_FE8_DEFINITIONS_

#define Eirika 0x01

#define Seth 0x02
#define Gilliam 0x03
… (more entries)
#endif
#endif

This is stolen from the STLB. #ifdef _FE8_ is an ‘if’ statement that see if it’s FE8. It also checks to see if
_NO_FE8_DEFINITIONS is marked. That is, if you DON’T want to use the standard FE8 definitions but
rather your own definitions, you could use _NO_FE8_DEFINITIONS in your code, and when the EA checks
to see if it should use the definitions, it’d be like “no, this is marked, so I can’t do it”.

For each #ifdef/#ifndef there has to be an #endif. Thus after all the definitions for characters, classes,
and items, is an endif.
There are also these ‘shortcuts’ called macros. Macros simplify otherwise long processes. Let’s look at a
few macros as well as other definitions in the STLB.

//Backwards compability
#ifdef _FE7_
#define IFEV IFEF
#endif

This defines one code as another code, so if a person had used an older verison and used one
spelling, their code would still work.

#ifdef _FE8_
#define GotoPrepScreen "GOTO $591FD8; ENDA"
#endif

This macro makes a code “GotoPrepScreen” that the EA interprets as the code in quotes next to it.
Instead of remembering that offset and the whole code, you can just type something easy to remember.
Much better, huh? While we’re at it, do you see the semi-colon after the 8? A semi-colon is like a way of
signifying a line break (a new line) without actually making it. Thus the EA knows that “GOTO” and
“ENDA” are separate codes.

#define Village(eventID,offset,X,Y) "VILL eventID offset [X,Y] 0xE; LOCA eventID [X,Y-1] 0x1D"

While you still don’t know how to actually use macros and codes in your events, you should understand
how they work. Everything inside of the parantheses, separated by commas, is a paremeter. eventID is a
parameter—we know what event IDs are, of course. So is the offset of the village, as is the X and Y co-
ordinates. However, that small code on the left comes out to be the code on the right—it’s much easier
for us to use the code on the left. Make sure you get the connection—the input ‘X’ and ‘Y’ is the same
input on the right for the ‘X’ and ‘Y’ there. However, we’re avoiding all the other codes and bytes by
using our little shortcut. It’s why macros are so useful.

I think we’ve covered macros well enough that we can move on to the next file in the folder.

The Event assembler language file that I will be calling “EALF” is a list of all the codes you can use with
the Event Assembler. It does not, however, include macros. It contains the “base codes”—the very
codes that are defined in the language raws. It says what paremeters there are and explains the basics
of each code.

I’m going to cover many codes (as well as some of my own macros) in another chapter. I will not cover
every code, but I will cover enough that you will know what codes to use when and where and how they
work in conjunction with the rest of the events.
The README should be read. Nothing else to say about that.

There’s also the template file Markyjoe1990 made. It has a base layout for codes. I’m going to give you a
similar template in the next chapter.

The other file you saw me have was a custom file for my own macros. Don’t worry, I’ll share the macros
with you in a couple chapters. :D

Chapter 50: Events – The Layout

How do we actually make our events? Well, there are different ‘sections’ for different types of codes.
We need to know the layout of the events, and then make the actual events. We do all of this in a
simple text file. If you by some chance don’t know how to make a text file, I can tell you how to do it on
windows. Either A) right-click on a folder, do New-> Text Document (it might say Notepad File or
something maybe), then rename it to something that makes sense like “Chapter X events”, B) go to
program files in the start menu, then go to Accessories, then load Notepad, and save the file, or C) copy
an existing text file, rename it, and open that.

Now I’m going to post my template; don’t be alarmed.

//Made by markyjoe1990 of Youtube

//Modified by Nintenlord
//Modified by Blazer

#define DISABLE_TUTORIALS
#include [Link]

EventPointerTable(0x??,Pointers)

org 0x????????
Pointers:
POIN Turn_events
POIN Character_events
POIN Location_events
POIN Misc_events
POIN BallistaData BallistaData
POIN BadEN BadEH BadEN BadEH
POIN GoodEN GoodEH GoodEN GoodEH
POIN Opening_event Ending_event

Turn_events:
CODE 0x00

Character_events:
CODE 0x00

Location_events:
CODE 0x00

Misc_events:
CauseGameOverIfLordDies
CODE 0x00

Ballista_events:
CODE 0x00

Opening_event:
ENDB

Ending_event:
MNCH 0x??
ENDA

GoodEN:
UNIT Empty

GoodEH:
UNIT Empty

BadEN:
UNIT Empty

BadEH:
UNIT Empty

#ifdef _FE7_
#define TileMap(TCN,X1,X2,L1,L2,TilePointer) "CODE TCN X1 X2 L1; CODE L2 0x00 0x00 0x00;
POIN TilePointer"
#endif

org 0xC9C9C8+(4*0x??) // - Pointer to tile map changes

 POIN TileChanges

org 0x????????

TileChanges:
TileMap(0x00,X1,X2,Y1,Y2,TilePointer)
CODE $FF
CODE $00
CODE $00

TilePointer:
CODE (Tile hex)
CODE $00

MESSAGE Events end at offset currentOffset

//The map for this chapter is at offset: ????????

This template includes:

- all main structure events

- getting rid of the tutorial
- including the STLB
- the format for tile map changes
- event table repointing
- normal and hard mode enemies (no differentiation between E/H modes to save space/I forgot
which is which…)

Please copy that to your text file and take a good look at it. I’m going to explain everything from top to
bottom.

“//” denotes a comment. Anything after that is ignored, but can be seen. Thus all the comments there
that say who have edited the template are rightfully ignored by the program.

#define DISABLE_TUTORIALS - disables the tutorials. I covered this in a MUCH earlier chapter. Once you
disable the tutorials once, you don’t need to do it again.

#include [Link] – this includes the standard definitions so that you don’t have to waste space
defining them all in one text file. You can include other definitions (like your own) as well.

EventPointerTable(0x??,Pointers) – this is to repoint the pointer in the event table (you can also do it
manually using a hex editor or the Event Reference module). 0x?? is the ‘reference byte’ for the events.
To know what this is, you can go into the Chapter Data Editor and scroll down to where it says ‘Event
Data Pointer’ or something like that. I’ll show you a screen real quick:

It’s called ‘Event Data Reference’ (I was close). The byte is 0x65, so that’s what I use. The text ‘Pointers’
is a pointer itself. What this does is go to entry 0x65 in the event table and repoint the pointer there to
wherever the ‘Pointers’ data is.

org 0x???????? – this is uh… we’ll say it’s a code that says where to put data. Anything that comes after
it (but before the next org) goes at this offset. For our events, we need a bunch of freespace. We’ve
been through this before. Note that when you put your offset, you don’t need the ‘0x08’ in front of it.
Personally I am using 0xCB3800 although this is not typically free space so I don’t suggest using it
yourself.

Pointers:
POIN Turn_events
POIN Character_events
POIN Location_events
POIN Misc_events
POIN BallistaData BallistaData
POIN BadEN BadEH BadEN BadEH
 POIN GoodEN GoodEH GoodEN GoodEH
POIN Opening_event Ending_event

These pointers are the header we were talking about. As said before, the EventPointerTable
code repoints a pointer in the event table to wherever this data is—and we specified where this data is
with the org code. The pointers themselves are the base 16 pointers for FE7 events. FE6 and FE8 have a
slightly different format, IIRC.

Anyway, POIN is a code that makes a pointer. It’s going to make a pointer of each word there (a
word is separated by a space, of course). So if we make a pointer to “Turn_events”, there has to be
some events labeled “Turn_events”. Verily, there is.

Turn_events:
CODE 0x00

Before I explain what turn events are, let me explain what it means to put a name and a colon after it.
It’s making a ‘label’ or a ‘group’ or an ‘event’. Because you use the same thing for units, I don’t want to
call them events, so I am going to call it a label. Back to the POIN code above, it points to this
Turn_events, which has some code beneath it. Right now all it has is a CODE 0x00—CODE 0x00 is a
nullifier that signifies the end of these events. The actual events we’d put here are events that take
place during a certain turn—for example, for a scene at the opening, you could have a scene on turn 1,
and for a scene on turn 4, you’d use turn events. I won’t actually teach you what codes to use here/how
to make turn events until later though.

From here on out I’m going to be less detailed on my explanations, so here we go:

Character events – talks/conversations between characters

Location events – villages, shops, doors, chests, etc., any events that take place on a certain tile
Miscellaneous events – other types of events. Includes “after-events” and chapter goal conditions.
Ballista events – events for ballista units
Opening event – the events for the opening scene. If battle preparations are on, then it loads this
automatically, and the event ends with “ENDB”. If battle preparations are off, you need to have a turn
event on turn 1 that uses the opening event, and the event ends with “ENDA” (you also have to
manually load units onto the map).
Ending event – the event at the ending scene. This is only directly used if you have a seize event with
event ID 0x03.
GoodEN – Ally unit data for Eliwood* normal mode.
GoodEH – Ally unit data for Eliwood hard mode.
BadEN – Enemy unit data for Eliwood normal mode.
BadEH – Enemy unit data for Eliwood hard mode.

*Also used for Lyn’s mode

The stuff at the bottom is all for tile changes, except for the message at the end, which just says where
the events end after they are inserted. You’ll see what I mean when you assemble events. As for a map’s
tile changes, you’ll have to see another chapter on that. :P

Chapter 51: Events – The Event Codes

This part is going to be a drag—it’s where I explain all the codes in the Event Assembler so that you have
no excuse to not know how any of them work unless it’s A) a code not listed here, B) something I can’t
work, C) glitch due to the program, or D) a CODE or ASMC thing that you can’t figure out because it’s not
a supported code but rather some special code.

Open up the EALF. The EAL text file contains a list of all the codes, as said. It doesn’t include some
macros though. I’m going to skip any codes that can be easier done with macros, and I’m skipping any
codes I don’t know. I’m also only going to give the important details that aren’t obvious, so if I don’t
mention an aspect of something, that means it is obvious.

Here are some generic principles to know:

- Event ID/event identifier is covered with its own chapter, and thus I will not cover how it works
again, and will just expect that you know it.
- $ and 0x both denote hex, otherwise it is decimal. Binary has a ‘b’ at the end of it.
- a pointer is a name, not an offset. When it asks for a pointer, you give a name, and later on you
use “NameofLabel:” and give the appropriate info for that event (i.e. you use codes to tell what
happens during said event).
- [X,Y] asks for co-ordinates. Co-ordinates are from the top-left of the map, which is considered
(0,0). You can use Mappy to figure out co-ordinates easily by just highlighting a tile in Mappy (it
tells you at the top left what the co-ordinates are).

With that, let’s get started! XP

Turn based events.

TURN 0xPP $pointer [XX,YY] 0xZ 0xMM
PP = event identifier
XX = starting turn
YY = ending turn+1
Z = 0 beginning of player phase
Z = 8 beginning of enemy phase
MM=mode 01=ENM 02=HNM 03=EHM 04=HHM, FE7 only

This is like, the only code you’ll used in the Turn_events area. If you want an event to happen on any
mode, just set ‘0xMM’ to ‘0x00’. A turn-based event might look like this:
TURN 0x00 Opening_scene [01,00] 0x0 0x00
Character based events.
CHAR 0xPP $pointer 0xAA 0xÄÄ 0xMM
PP = event identifier
AA = character1
ÄÄ = character2
MM = 1, eliwood
MM = 2, hector
MM = 00XX0003, if event XX has happened, for FE7 and FE8 only

These go in the character events area, of course. This code is for a talk between two characters. To make
a talk go both ways you need two events, with the characters switched in them. However make sure that
they have the same event ID so that if the conversation goes one way, it can’t go the other way as well.

Example:

CHAR 0x07 RecruitmentConvo 0x03 0x0D 0x00

CHAR 0x07 RecruitmentConvo 0x0D 0x03 0x00
CODE 0x00 // - nullifier

Shop list.
SHLI 0xI1 0xI2 0xI3
0xI1,2,3... = item.

This is an easy code. In a shop/armory/secret label use this to specify what items/weapons are available.
Note that there IS a limit to how many there can be, so I would not add too many. Idk what the specific
limit is though. 0xI1, 0xI2, etc. are just the hex values of the items. You can also use names
‘IronSword,IronSpear’, but they have to be defined (I covered definitions earlier—this is how you use
them).

Area events.
AREA 0xPP $pointer [X1,Y1] [X2,Y2]
[X1,Y1] = upper left corner of trigger area
[X2,Y2] = lower right corner of trigger area

Honestly, I’ve sort of forgotten where this goes, but I think it actually goes in the Misc_events section,
NOT the location events. It sounds ironic, but this is what I remember (and I’ve been doing events for
years, guys). This is pretty self-explanatory—it sets a rectangular area to have an event such that when
you wait on a tile there, the event activates. Note that certain codes won’t work with an area event
because the character is still considered moving when this activates (thus the DISA code, which removes
a character from the map, does not function properly).
 Event after another event.
AFEV 0xPP *pointer* 0xRR
0xRR = The event ID of previous event.

This goes in the Miscellaneous section as well. It activates an event after another event has been
activated. This is actually how the game over event works—when event 0x65 is activated/triggered, it
uses an after event to go to the game over screen. *this is one of the event codes I told NL about, tee
hee*

Event if ASM condition is fulfilled

ASME 0xPP *pointer* *ASM pointer*
ASM pointer = pointer to ASM code

Unless you are familiar with specific ASM conditions, I don’t suggest using this codevery often. Despite
this I think the ‘Defeat All Enemies’ goal uses this kind of event (but there should be a macro for it…).

Unit data FE7 and FE6:

UNIT 0xZZ 0xCC 0xLC 0xLL [X1,Y1] [X2,Y2] I1 I2 I3 I4 A1 A2 A3 A4
UNIT 0xZZ 0xCC 0xLC 0xLL [X1,Y1] [X2,Y2] *Items* *AI*
UNIT 0xZZ 0xCC 0xLC 0xLL [X1,Y1] [X2,Y2] [I1,I2,I3,I4] [A1,A2,A3,A4]
ZZ = Character
CC = Class
LC = Leader character
LL = Starting level
[X1,Y1] = Loading coordinate
[X2,Y2] = Starting coordinate
I1 I2 I3 I4 or *Items* = Starting inventory
A1 A2 A3 A4 or *AI* = Units artificial intelligence

Character and class are obvious. Leader character is described in the “Chapter Unit Editing with
Nightmare” chapter (it’s not very important, so you can just set it to 0x00 if you want). Starting level is a
byte that determines the allegiance, starting level, and whether a unit is autoleveled or not. There is a
list of values in the Nightmare modules; however, there is also another (MUCH better) way to do
starting levels. Use the macro:

Level(Level,Allegiance,T/F) where “Level” is a number that determines the level, “Allegiance” is either
“Ally”, “NPC”, or “Enemy”, and T/F is either “True” or “False”.

The first co-ordinates are the loading position. Units will then move to the starting positions. If battle
preparations are on, these co-ordinates might as well be the same.
Items is just a list of items with a max of 4 starting items. I prefer to use the 3rd method of writing them,
with the brackets and all. Each item is separated by a comma.

AI is the hex for AI, with each byte being separated… You can see my Chapter Unit Editing with
Nightmare chapter on how AI works.

Now, for an example:

UNIT Hector 0x03 0x00 Level(5,Ally,False) [03,00] [03,02] [IronAxe,SteelAxe,Vulnerary]

[0x00,0x03,0x09,0x00]

(Note: Allies don’t actually use AI, but I included it to show you how it works anyhow)

Ballistae's
BLST [XX,YY] *Ballista type*

“Ballista type” is either 0x34, 0x35, or 0x36. After the BLST code you have to add the code “ALIGN 4” for
reasons I don’t want to get into—it prevents some glitches from happening, however. Both codes go in
the ballista events and are probably the only codes you’ll use there unless you know super special codes.
XP. It should look like this:

Ballista_events:
BLST [14,23] 0x34
ALIGN 4

That’s just an example, of course.

Showing text.
TEX# 0xZZZZ
ZZZZ=text value
//# - code
//1 - 0d
//2 - 0e
//3 - 0f
//4 - 11
//5 – cf

TEX1 0x0816 – this loads some text at the beginning of lyn’s mode. it uses the default text loading code,
which is TEX1, and is for dialog. I forgot what 0E and 0F are for, but 11 is for continuing text while still
using the same loaded portraits and the such. You’d use this if you have some dialog, need to change
the music playing, and then continue dialog, but don’t want to show all the portraits being cleared and
then reloaded just when the music changes.
CF is for CG text. Just make sure to use the [SetName] text control code in FEditor Adv to set the name
of who is talking. (And of course, every time it changes whose talking, you need a new text event…)

TEX8 0xZZZZ [XX,YY]

Show small brown textbox
ZZZZ = text value
XX,YY = position of the textbox

RETB
Hide brown text-box

This text code is mainly used for displaying the name of a location when there is a scene that shows
something happening in another area. It’s just a small brown box though, really. The position is in pixels,
IIRC, that is if you want it at the top left, you could use say [24,16] and it’d be there. It’s up to you to
experiment and figure out where you want it.

The latter code just hides the text box afterwards. It’s necessary for your events to work properly.

Makes event ID usable.

ENUT 0xNN
Makes event ID used.
ENUF 0x00
NN = event number

This is mainly used amidst conditional events but doesn’t have to be. It can set an event ID to be usable,
i.e. an event with said event ID CAN activate, or it can set it to be unusable, so that an event with said
event ID CANNOT activate.

Condition related codes.

Turn condition
IFTU 0xII 0xTT
Event condition
IFEV 0xII 0xVV
Previous yes/no statement
IFYN 0xII
Checks for Eliwood mode
IFEM 0xII
Checks for tutorial mode
IFTT 0xII
Unit is Fielded
IFUF 0xII 0xXX
 Checks for active character
IFCA 0xII 0xXX
Checks if character is dead (or recruited?)
IFCD 0xII 0xXX
ASM condition is true (returns non 0 value in r0)
IFAT 0xII *pointer*
ASM condition is false (returns 0 in r0)
IFAF 0xII *pointer*
End of if statement
ENIF 0xII
Else statement
ELSE 0xII
II = condition identifier
VV = Event number
TT = Turn number

Wooh, so many conditional events! Conditional events are just if/else statements, really. The base
structure for them is:

IF (insert parameter)
// - (insert event to happen if condition is met)
ELSE
ENDIF
// - (insert event to happen if condition is not met)
ENDIF // - it really does “ENDELSE” but it’s ultimately the same code as “ENDIF”, so…

Btw, for the turn condition, it’s actually like “TURN LIMIT -1” or something. I think...

Anyhow, conditional events are a bit tricky, so I would just follow the general format above and use
whatever beginning codes you want to check for whatever thing you want (check what character is
fielded/dead/currently in use, or what mode, or turn #, etc.).

Change weather.
WEA1 0xZZ
WEA2 0xZZ
ZZ=Weather

You know the ‘Weather’ dropdown in the Chapter Data Editor? You can find values for weather in there.

Load units.
LOU1 $pointer (repeatable)
LOU2 $pointer (repeatable)
 LOU3 $pointer (repeatable)
LOU4 $ENM pointer $EHM pointer $HNM pointer $HHM pointer
LOEV 0xZZ 0xPP [XX,YY]
ZZ = Character
PP = Class
[XX,YY] = coordinate to load into.

This is how you actually load units. I almost always use LOU1. In your early chapters there won’t be
battle preps and so you’ll need to load units during a cutscene like this. WITH battle preps, units are
loaded based off of the ‘GoodEN’, ‘BadEN’, etc. pointers in the header that we talked about a while ago.

The actual pointer is the pointer to a list of units. I already covered how units work, but here’s another
bit of example anyhow:

LoadUnitsEvent:
LOU1 AlliedUnits
ENUN // - this code is used after an event. It waits for the previous event to be finished. It’s almost
always used after loading units or movement, however.

AlliedUnits:
UNIT Eliwood 0x01 0x00 Level(1,Ally,False) [0,0] [2,2] [IronSword,Rapier,Vulnerary] [00000000]
UNIT Empty // - this has to be at the end of your units. Otherwise the game will not know when to stop
loading units and your units WILL crash and stuff. Almost guaranteed crash (I won’t tell you how to not
include this and not crash it, some secrets are better kept secret).

OH WAIT! I forgot about the LOEV code. It loads an NPC with said character and class at the coordinates
[X,Y]. That’s all. =D

Move units on map.

MOVE [X1,Y1] [X2,Y2]
MOVE [X1,Y1] [X2,Y2] 0xGG
MOVE [X1,Y1] *pointer To Move Manual*
MOVE 0xZZ [XX,Y2]
MOVE 0xZZ [XX,Y2] 0xGG
MOVE 0xZZ *pointer To Move Manual*
[X1,Y1] = Starting coordinate
[X2,Y2] = Ending coordinate
ZZ = Character
GG = Speed of moving

There are various different MOVE codes but the EA has them all start out the same. If there are multiple
co-ordinates, it moves the unit at the first co-ordinates to the 2nd co-ordinates. 0xGG is optional—you
can test out values to see what you need. Alternatively, you can use 0xZZ to specify a character instead
of specific co-ordinates. You can use ENUN to wait for movement to be finished before executing the
next event. That’s about all I have to say.
End unit load or/and move event
ENUN

I covered this earlier, but you just use this aftering loading units or moving units. It can also be used to
wait for an earlier event to finish taking place before continuing on (but it’s not used much like that).

End of an event
ENDA

At the end of a scenic event (a scenic event is one with say, dialog, character movement, etc., as
opposed to one of the codes in the ‘Turn_events’ or ‘Location_events’ areas) you put this, UNLESS the
scene is the opening scene and you want battle preparations, in which case you need to use ENDB (for
FE7) or GotoPrepScreen (for FE6-FE8 IIRC).

End chapter and transfer to next one

MNCH 0xYY
MNC2 0xYY (skips world map)
YY = Chapter number.

An alternate way to skip the world map is to set it to 0x00 in the Chapter Data Editor. Anyhow, this code
is used at the end of chapters—it takes you to the save screen and continues to the next chapter. To
know the chapter # of your chapter, there is a list of chapters in the “Quote Editor” folder with the hex
next to them (at least, for FE7 there is—for FE8, you can use the hex values seen when you load the
Chapter Data Editor). Use the hex of the chapter you want to go to in place of ‘YY’.

Stall.
STAL 0xZZ (repeatable)
ZZ=time to stall

Very simple code. It makes the game wait. The time is in… uh… I’m not sure, and I’d guess “frames”, but
I could easily be wrong, but anyhow, 0x1E is a short pause, 0x64 is a second pause, 0xFF is like 2-3
seconds or so… just test out values until it looks good, kay?

Move camera on map.

CAM1 0xZZ
CAM1 [XX,YY]
CAM2 [XX,YY] //1F
ZZ=character
[XX,YY] = Character
The “camera” of the map is what part of the map is being focused on. You can set it to focus on a
character or a co-ordinate. (Warning: If you set the camera to focus on places too close to off-screen,
the map will get messed up and stuff… in other words, be careful about where you focus it on—don’t try
and focus it on the bottom-right corner, that will surely be screwy.)

Changes vision distance

VCBF 0xZZ (black fog)
VCWF 0xZZ (white fog)
ZZ = vision distance
00 = infinite

This is a code that changes how far a unit can see in the fog. It loads fog if there wasn’t fog before. Kinda
simple…

Changes/puts up a convo background

BACG 0xZZ
ZZ=background

This is a simple code and used somewhat frequently. It loads a background for dialog. To use it properly,
you need to have a FADI and a FADU after it, or else the transition to the background will not look good.
I made a list of backgrounds for FE7 but for the other games, you’re kinda on your own, unless someone
has a list they want to share…

Shows a CG picture
SHCG XX
XX = picture value

Like the BACG code, but shows a CG.

return to map
REMA

Used after text to clear the text and return to the map view.

Changes music
MUS1 0xZZ
MUS2 0xZZ
MUS3 0xZZ
ZZ=music value

See the music list for values to use.

 Makes sound effect play
SOUN 0xZZZZ
ZZZZ=sound effect value

See the music list for values to use.

Fades music out.

MUEN 0xZZ
ZZ=fade out speed

0x05 is a decent speed. Ending music abruptly as well as ending one song and switching to another song
abruptly are both bad ideas that don’t sound good and people will notice it. Thus this code could be
used more than you might think.

Lowering/Highering volume of the music

MUSI (makes music more silent)
MUNO (makes music normal after MUSI)

…I have nothing to say.

Causes map changes.

MAC1 0xZZ 0xY
MAC2 0xZZ
MACE (placed after a bunch of MAC2)
MAC3 0xZZ
ZZ=map change number
Y=0 does them
Y=8 undoes them

You’ll mainly use MAC1 (especially because I don’t know/remember what the differences for the other
ones are). The ‘map change number’ is the first byte in the map changes. The first map change in the list
is 0x00, the 2nd is 0x01, and so forth. You’ll learn more about map/tile changes later.

Load map
LOMA 0xZZ [XX,YY]
ZZ = Map number
[XX,YY] = Coordinate

Mainly used for cutscenes, which is why it’s called ‘Load map’, but it’s sort of like going to another
chapter without actually going through the save screen and world map. The map number is actually the
chapter number (and when it loads the chapter, it consequently loads the map). Unless you’re really
smart and understand all of this and think you can manipulate event codes really well, I wouldn’t try and
use this code to do a “chapter after a chapter” (i.e. without actually saving). XP

Giving items to character

ITGC 0xPP 0xZZ
ITGV 0xZZ (village)
ITGM 0xZZ (to main lord)
ZZ=item
PP=character

Money giving
MONE 0xZZ 0xMMMM
MMMM = Amount of money
ZZ=00 village
ZZ=01 cutscene

So very obvious. The ZZ byte in money giving is important because it helps decide whether a weapon is
received or “pilfered” -_-.

Execute ASM
ASMC $pointer (repeatable)

Unless you want to write your own ASM routines using the EA (*sweats* D:) you want to actually put in
a pointer here. What pointer to use? Well, there are different ones for different effects. I guess you have
to be smart and know them. One way to know them is to analyze existing event codes by disassembling
and figuring out what certain ASMC codes do. That’s how I figured out most of my event hacking back
when there wasn’t any Event Assembler or FEditor Adv. >_>

Change unit condition

UNCM 0xZZ 0xXX (causes)
UNCR 0xZZ 0xXX (reverses)
ZZ = character
XX = condition values
01 = invicibility
02 = Grayed out
10 = rescuing a unit
20 = being rescued

Effects map sprites, btw.

Makes unit disappear and re-appear

DISA 0xZZ (disappear)
 DISA [XX,YY]
REPA 0xZZ (re-appear)
REPA [XX,YY]
ZZ = Character
[XX,YY] = Coordinate

Very obvious… use co-ordinates or the character #.

Make units fight (FE7)

FIGH 0xZZ 0xPP $pointer $code
ZZ = Attacker
PP = Defender
code = 00000000 normal, controlled fight

If you want a totally scripted fight, there’s a trick. Yes, there is. Oh yes. There’s a bunch of things you can
do with the data pointed to by ‘$code’… I think I’ll teach you.

To start, the $code can do some special things. One thing it can do is make the attacking character equip
any weapon, even if it’s not in their inventory. lolwut? Yes it can. $0000001F would make them equip an
Iron Axe, for example. It’s the first byte that controls it (when using ‘$’ you are reversing the byte order
though, making it seem like the last byte).

Now, the data pointed to by the pointer controls what happens in the fight. You can have multiple
attacks, but typically any more than 4 attacks and the game may start to act a bit silly, so be careful.

FightData:
CODE (bytes)
CODE 0x00 0x00 0x80 0x00 // ends the fight

A general fight looks like that. There are many things you can do with the fight, though. One attack
consists of 4 bytes, and those 4 bytes control everything about that one attack.

CODE 0x00 0x00 0x00 0x20

What this does is make an attack that 1) hits 2) acts normal 3) that the attacker does and 4) that does
0x20, or 32 (yes a lot) damage. The first byte controls the outcome of the attack.

Byte 1:

0x00 = Hit
0x01 = Critical
0x02 = Miss
 0x40 = Poison
0x80 = Devil

The second byte is, to my knowledge, only used to control whether the hit is a silencer or not. 0x00 is
normal, and 0x08 is silencer (it has the silencer special dark kill effect too).

The third byte controls who attacks, if anyone. 0x00 means the attacker attacks. 0x08 is to make the
defender attack. And 0x80 ends the battle (which is why 0x00 0x00 0x80 0x00 is used at the end of all
fight events, if you’re smart).

The last byte is the easiest byte to remember, as it is the damage—in hex, mind you. As usual, use your
head or MS Calculator or an online calculator to convert from decimal to hex.

Now, here is an example of a scripted fight.

FIGH 0xED 0x01 AnakinFight $0000001F

UNCM 0xED 0x01
MOVE 0x2D [16,23]
ENUN
FIGH 0x2D 0xEE SiegFight $00000000
UNCM 0xEE 0x01

AnakinFight:
CODE 0x02 0x00 0x00 0x00 // attacker misses and does 0 damage
CODE 0x01 0x00 0x08 0x30 // defender attacks, critical, and does a whopping 48 damage
CODE 0x00 0x00 0x80 0x00 // the battle ends

SiegFight:
CODE 0x81 0x08 0x00 0x30 // attacker critical and does 48 damage WITH a silencer… to HIMSELF
// because of the devil effect. So he pretty much assassinated himself. XD
CODE 0x00 0x00 0x80 0x00 // the battle ends

***USEFUL INFO ON SCRIPTED MAP FIGHTS***

Alright. So character 0xED fights character 0x01 (happens to be Anakin). The enemy uses weapon 0x1F
to fight (see the last byte of the FIGH code), which is an Iron Axe, but the unit data (which I didn’t show)
says his class is a soldier. Do you know what this means? It means that the game can’t load an animation
because soldiers don’t have an axe animation. The result? The scripted fight happens on the map
instead of with full animations on. This is useful for fights with generic enemies where people typically
don’t want to see battle animations. I think it’s a pretty good idea because I can’t find a byte that forces
animations off, but then again I came up with it so I am biased. XD
As for what happens in the fight, see the comments and look at what I said about what byte values do
what, and you should figure it out.

Now admittedly there are some other codes in-between the two FIGHs but just ignore them for now. In
the next FIGH code, character 0x2D attacks character 0xEE, and uses the weapon he has equipped.
Notice how in the code I used 0x81 for the first byte. Wait, that wasn’t an option! 0x80 is devil, and 0x01
is a critical, but 0x81… oh, get it? It’s just a critical with the devil’s axe effect. He’s essentially critical-ing
himself like an assassin. Fun stuff.

That’s all there is to FIGH commands. Just be careful that you don’t do anything reckless, as they can
EASILY mess up. For one, make sure the fighting units are within range of each other, and don’t try doing
anything stupid (not that you would) like a missing critical (0x03—I sincerely doubt it would work…).

As for the FE8 scripted fights… I have almost no clue how the FE8 code works so I can’t help you there.
Then again, this tutorial is FE7 oriented, so I have few regrets. T_T If you need help, try Arch’s event
tutorial, as it includes info on the differences between FE7 and FE8 and the like. It’s useful.

Kill a character
KILL [XX,YY]
KILL 0xZZ
ZZ = Character
[XX,YY] = Coordinate

Actually kills the character rather than just making them disappear. When a character is killed, so is their
data, meaning if you try and load the character you killed later, they will have their base stats. This only
applies to allies, of course, because enemies and NPCs can’t level up, but why would you want to kill an
ally…? :P

Changes units AI
CHAI 0xZZ $AI code
CHAI [XX,YY] $AI code
ZZ = Character
[XX,YY] = Coordinate

The AI bytes are the same AI bytes used in unit data. Whoop-dee-doo.

Changes characters affiliation (FE6/FE7)

CUSI 0xZZ 0xPP
ZZ = Character
PP = affiliation code

Changes characters affiliation (FE8)

 CUSA 0xZZ to ally (blue)
CUSE 0xZZ to enemy (red)
CUSN 0xZZ to neutral (green)
ZZ = Character

For FE6 and FE7, 0x40 should work for NPC, and 0x80 should work for Enemy. I think. If they don’t work,
then just test values (I know 0xA0 should work for enemy, NPC should be somewhere in the middle…).
There are macros for FE7 to simplify this so you don’t have to remember values.

FE8 is lucky and has 3 separate codes for each allegiance. Well, idk if you consider having to use 3
separate codes lucky, but it’s better than having to remember random ‘allegiance values’…

Promotes character (FE8)

PROM 0xZZ 0xYY
ZZ = Character
YY = Class to promote to

FE8 is lucky and has its own code for promotions. I only know a code for promoting the Main Lord in
FE7. D: I’ll give you some of these macros later (very soon).

Fadi in/out black

FADI 0xZZ
FADU 0xZZ
ZZ = Speed of the fade-out
01 = slowest possible
FF = Fastest possible

Fade in/out white

FAWI 0xZZ
FAWO 0xZZ
ZZ = Speed of the fade-out
01 = slowest possible
FF = Fastest possible

Fade in/out for CG

FADICG 0xZZ
FADUCG 0xZZ
ZZ = Speed of the fade-out
01 = slowest possible
FF = Fastest possible
These codes are pretty important. When you fade to black, you can execute events without the player
seeing them. You can “secretly” load units, make them all invisible, load music, load a background, load
a CG, or something else. These codes generally work the same, except one is black, one is white, and
one is for CGs, apparently (I never used the CG code myself). A good value for average-speed fades is
0x10 and for slower fades, 0x04. For faster fades, something high (but probably not 0xFF).

Pointer
POIN $pointer

It makes a pointer. I can’t believe I just said something so obvious.

Go to event
GOTO $pointer
Executes pointed events and then returns.

The EALF already explains this one. Once again, I find myself near stunned that I even pasted this. I must
be tired/bored…

Now, onto those macros I said. I’ll give’m, but they’re only for FE7, unfortunately. Once again FE7 is
treated better than all the other games. Sorry, but FE8 hacking never got my interest, and I don’t feel
like going to that game and having to figure out all the stuff that I already know about in FE7. D:

//NewMacros
//Most new macros are by Blazer. The CameraOff and FE7 allegiance codes as well as the rescue
//code are all thanks to Arch. Some of the hex I got for the codes is in thanks
//to Nintenlord and Icy Toast.
//Please make sure you have the latest version of the Event Assembler and this file before using.
//Please credit Blazer, Arch, Nintenlord, and Icy Toast if you use these.
//Also, check to make sure that some of these macros don't have language codes made for them
in
//a newer release of the Event Assembler. Thank you and enjoy!

#ifdef _FE7_
#define UnitClear "ASMC 0x7A8B9"
#define Scroll(Box,Index) "CODE 0xA7 0x00 0x07 0x00; CODE 0x00 0x00 0x00 0x00; CODE Index
Box 0x00 0x00; CODE $42; CODE $08083181; CODE $89"
#define Reposition(Char,XC,YC) "CODE 0x2F 0x00 0x00 0x00; CODE Char 0x00 0x00 0x00; CODE
$00YC00XC"
#define UnitFlash(Char,Time) "UNCM Char 1b; STAL Time; UNCR Char 1b; STAL Time; UNCM
Char 1b; STAL Time; UNCR Char 1b; STAL Time; UNCM Char 1b; STAL Time; UNCR Char 1b; STAL
Time; UNCM Char 1b; STAL Time; UNCR Char 1b; STAL Time"
#define MoveOff(Char,X,Y) "MOVE Char [X,Y]; ENUN; DISA Char"
 #define TileMap(TCN,X1,X2,L1,L2,TilePointer) "CODE TCN X1 X2 L1; CODE L2 0x00 0x00 0x00;
POIN TilePointer"
#define Rescue(Char,Rescuer) "DISA Char; ENUN; UNCM Rescuer 0x10; STAL 0x10"
#define CameraOff "CODE 0x3D"
#define CameraOn "CODE 0x3C"
#define Ally(Char) "CUSI Char 0x00"
#define Enemy(Char) "CUSI Char 0xA7"
#define NPC(Char) "CUSI Char 0x37"
#define BlackOff "CODE $0C"
#define QuintessenceEffect "ASMC 0x7D711; STAL 0x3C; ASMC 0x7D7B5; STAL 0x3C; ASMC
0x6CCB9; ASMC 0x7D771"
#define LynModeEnding "CODE $58; CODE 0x30 0x0F 0xCC 0x08"
#define UnitInvisible "ASMC 0x7A939; ASMC 0x7A9D5"
#define Rumble "ASMC 0x7D645"
#define MainCharPromote "ASMC 0x79AF5"
#define DarkenScreen "CODE $E1; CODE $E0; CODE 0xFFFFFFFF; CODE 0x04 0x00 0x00 0x00;
CODE 0x80 0x00 0x02 0x08; CODE $E2"
#define MapColorChange(Speed,ColorByte1,ColorByte2) "CODE $E1; CODE $E0; CODE
0xFFFFFFFF; CODE Speed 0x00 0x00 0x00; CODE 0x80 0x00 ColorByte1 ColorByte2; CODE $E2"
#define MapColorReturn "CODE $E1; CODE $E0; CODE 0xFFFFFFFF; CODE 0x04 0x00 0x00 0x00;
CODE 0x00 0x01 0x04 0x10; CODE $E2; CODE $E2"
#define LightningStrike(X,Y) "CODE $DD; CODE X 0xFF 0xFF 0xFF; CODE Y 0xFF 0xFF 0xFF; CODE
$42; CODE 0x99 0x14 0x01 0x08"
#define DefeatAllEnemies(pointer) "CODE $0E; POIN $pointer; CODE 0xE9 0x9F 0x07 0x08"
#define DefeatBossGoal(pointer) "AFEV 0x00 pointer 0x02"
#define IfPlayerUnitsOnly(evid) "CODE $48; CODE $01; CODE 0xF1 0xA2 0x07 0x08; ENUT evid;
CODE $45; CODE $09; CODE $44; CODE $01"
#define IPUO(evid) "CODE $48; CODE $01; CODE 0xF1 0xA2 0x07 0x08; ENUT evid; CODE $45;
CODE $09; CODE $44; CODE $01"
#define ENDPUO "CODE $44; CODE $09"
#define LoadLynsModeFallenText "GOTO 0xCC0928"
#define GUARD "0x03,0x03,0x09,0x20"
#define ATRANGE "0x00,0x03,0x09,0x00"
#define NOAI "00000000"
#endif

You can use them, of course, as long as you give credit. People who make programs, codes, and even
nightmare modules all deserve some sort of thanks, IMO. Especially people like Nintenlord and Xeld who
have contributed a LOT.

Anyway, I’ll cover each code briefly.

The UnitClear code is used in cutscenes to clear all the units off the map leftover from the battle.

The Scroll code loads a scroll-esque box (the ones often seen in tutorials) with text. “Box, Index” is an
old-fashioned way of dividing up the text pointer into two parts (sorry, my macros are not very
efficient). “Box” would be the first part and “index” would be the second part.

The Reposition code is used to move a unit without actually seeing them move there.

The UnitFlash code is mainly for me, but anyhow, it makes a map sprite flash (appear invisible and
visible repeatedly) as if though the unit is coming out of the shadows.

The MoveOff code simply moves a unit off the map (you still need co-ordinates though. )

TileMap is a macro used for map/tile changes. Beware: it uses all hex for input. You’ll learn more about
this very soon.

The Rescue macro simply makes it easier to rescue a character during a cutscene.

CameraOff makes it so that the camera doesn’t follow movement and unit loading all over the place.
CameraOn undoes this by turning the camera back on (obvious, huh? XD).

The Ally(Char) etc. codes just change the allegiance of a character to whatever you want.

BlackOff is used A) when the chapter fades to black to start (you can change this setting in the Chapter
Data Eidtor), and B) in a turn 1 scene when battle preps are set on, it is needed for reasons I can’t
explain. Pretty much, whenever you have battle preps, make a scene on turn 1 and include this code at
the beginning of it.

QuintessenceEffect does the quintessence sucking red wavy crap. You have to see it to know it.

LynModeEnding makes the game go to the Lyn’s mode endings.

UnitInvisible makes units invisible, supposedly. I got this code from NL, so…

Rumble is just a rumbling effect…

MainCharPromote promotes the main character (depends on the mode, idk if it works in Lyn’s mode).

DarkenScreen is quite obvious.

MapColorChange changes the color of the screen to whatever you input (has to be hex) and does it with
the speed you input. Don’t know what to input? Experiment and find out.
MapColorReturn returns the screen to its normal colors.

LightningStrike makes lightning strike (it’s used in a very late chapter in FE7 by Limstella). The
positioning would normally be controlled by 0xC0 and 0xF0, AKA (13,15), but it’s tricky. Do what you
want with it, but I don’t like having to deal with tricky special effects.

DefeatAllEnemies and DefeatBossGoal are ways of making said goal conditions. They go in the
Misc_events section. Of course, you have to input a pointer for them to go to. This is redundant because
Nintenlord already made macros for them included in the EA’s standard library. XP

IfPlayerUnitsOnly checks to see if the current character is an allied/player unit. The shortened verison is
IPUO.

LoadLynsModeFallenText does exactly what it says. When a character is injured, text is typically loaded
at the end of the chapter. It’s supposedly done using this code.

GUARD "0x03,0x03,0x09,0x20" is a shortcut for entering the guard AI. At the end of unit data I could put
“…… [Javelin,Vulnerary] [GUARD]” and the unit would stay in his one spot, attacking whoever he can
while staying still. It beats typing out the hex. Arch has some other useful AI macros you can use (see the
Fire Emblem Shrine or Fire Emblem Universe for them—check the documentation sections).

If any of the macros don’t work, don’t get frustrated at me. The solution is simple: don’t use them. I’m
being nice and sharing, so be nice and accept what gifts are offered to you. :P You can always contact
me too so I can fix them. That works.

Now that we know all about the codes used in events, we have to actually construct our chapter by
putting everything together.

Chapter 52: Event Construction

I’m going to make this chapter easy on myself. You look at a bunch of events and recognize all the codes
used (because I explained most of them). Then you are like “oh, this makes sense” and you get a feel of
how actually using the codes to build your events work. Right, I’ve explained enough about events, so
you’ll have to work it out on your own by looking at this chapter of mine from Tactics Universe. If you
still need more help constructing your events, please look at Arch’s tutorial, found here--
[Link]

#include [Link]
//#include [Link] – this would load my custom macros. You can add a line like this
//to load your own macro file, which can contain your own macros and macros by others.
//I suggest you download Arch’s and my macros from the FEShrine as they are very useful.
org 0xC9C9C8+(4*0x5A) // - tells the game where the pointer to this chapter’s events is

POIN Pointers // - makes the pointer

org 0xCB2000 // - tells where to insert data

Pointers: // label name
POIN Turn_events // makes a pointer to turn events, same for others but different events
POIN CharacterTalk
POIN Location_events
POIN Misc_events
POIN Ballista_events Ballista_events
POIN BadEN BadEH BadEN BadEH
POIN GoodEN GoodEH GoodEN GoodEH
POIN Opening_event Ending_event

Turn_events: // name of turn events. Look how it matches with the POIN to the top.
TURN 0x00 PreBattle [01,01] 0x00 0x00 // - creates a turn scene on turn 1 on the ally phase
CODE 0x00 // ends structure events

PreBattle: // the actual turn scene that is referenced in the turn event. be careful with
//capitalization and spelling always!
BlackOff // custom macro used to fade out of a black screen at the beginning of a chapter or //
after battle preps
ENDA // ends the scenic event

CharacterTalk: // for character talks, most commonly recruitment conversations

CODE 0x00 // ends structure events

Location_events:
Village(0x07,Village1,3,2) // creates a village with event ID 0x07
Village(0x08,Village2,3,8) // creates a village whose scene is “Village2”
Village(0x09,Village3,2,11) // creates a village with co-ordinates (2,11)
Village(0x00,Village4,1,14) // village that can be visited repetitively due to 0x00 as event ID
Door(9,14) // allows a door to be opened at 9,14
Door(10,14)
Armory(WeaponShop,6,16) // creates an armory at (6,16)
Vendor(ItemShop,9,17) // creates a shop with a list of weapons called ItemShop
CODE 0x00 // ends location events/structural events

Village1:
Text(0x0D,0x970) // text macro that loads background 0x0D and text 0x970
ITGV KnightsCrest // gives a KnightsCrest to the active unit visiting the village
REMA // removes graphics/returns to map
ENDA // end scenic event

Village2:
Text(0x01,0x971)
MONE 0x00 5000 // gives 5,000 gold to player, for villages (cutscene would be 0x01, not 0x00)
REMA
ENDA

Village3:
Text(0x0D,0x972)
ITGV 0xA5 // gives item/weapon 0xA5 to current unit
ENDA

Village4:
Text(0x01,0x973)
REMA
ENDA

WeaponShop:
SHLI IronSword SteelSword IronSpear SteelSpear Javelin IronAxe SteelAxe HandAxe IronBow
SteelBow // list of weapons available at weapon shop
CODE 0x00 // data separator

ItemShop: // same structure as weaponshop

SHLI Heal Mend Fire Thunder Lightning Shine Vulnerary Antitoxin
CODE 0x00

Misc_events: // miscellaneous events, triggered events

ALIGN 4 // prevents misalignment from shops
CauseGameOverIfLordDies // when event 0x65 is triggered, game over screen will occur
DefeatAll(Ending_event) // when all enemies are defeated, the game goes to “Ending_event”
AREA 0x14 ItemFind [9,13] [12,14] // area event with event ID 0x14 called “ItemFind”.
//Item can be found by waiting anywhere between [9,13] or [12,14]
CODE 0x00

ItemFind:
ITGV DoorKey // gives a doorkey
REMA
ENDA
Ballista_events:
CODE 0x00

Opening_event:
ALIGN 4 // prevents misalignment from ballista data
CameraOff // custom macro that turns the camera off so it doesn’t follow unit movement
CAM1 [0,0] // moves camera to position [0,0]
UnitClear // custom macro that clears all units from the field (redundant, no units loaded yet)
BlackOff // custom macro that removes black screen
CAM1 [0,0]
ENUN // waits for event to finish/camera to move
LOU1 Allies // loads unit group “Allies”
ENUN // waits for units to move
CAM1 [3,10]
STAL 40 // stalls the game for time of ‘40’, a short pause that helps the flow of events
CAM1 [6,14]
STAL 40
CAM1 [14,14]
LOU1 Kelik // loads unit group “Kelik” (NOT necessarily the character “Kelik”)
ENUN
STAL 40
CURF [14,15] // flashes the cursor on (14,15)
FADI 0x10 // fades in with speed of 0x10
BACG 0x0A // loads background 0x0A
FADU 0x10 // fades out with speed of 0x10
TEX1 0x967 // loads text
REMA // clears text and returns to map
STAL 0x10 // stall, but with hex input
ENDB // goes to battlepreps, one can alternatively use a macro

Allies: // name of unit group/event label

UNIT Sain 0x00 0x00 Level(1,Ally,False) [6,16] [6,16] [0x00] [00000000] // loads character “Sain”
UNIT Lyn 0x00 0x00 Level(1,Ally,False) [3,12] [3,12] [0x00] [00000000] // class “0x00”
// the game knows to load Lyn’s class as Lyn is already an allied unit in the save data
UNIT 0x49 Myrmidon 0x00 Level(15,NPC,False) [14,15] [14,15] [0x00] [00000000]
// loads level 15 NPC without autoleveling (automatically adding stats)
UNIT Empty // unit separator to prevent glitches

Kelik:
UNIT 0x02 0x00 0x00 Level(1,Ally,False) [16,14] [16,15] [0x00] [00000000]
UNIT Empty
Ending_event:
MUEN 0x05 // fades out of music at speed 0x05
FADI 0x10
BACG 0x0A
MUS1 0x0038 // loads music 0x0038
FADU 0x10
TEX1 0x968
MNCH 0x17 // goes to chapter 0x17 (not exactly chapter 17, but the 0x17th chapter in the data)
ENDA

GoodEN: // allied units, controls positioning and # allowed in battle preps

UNIT 0x02 0x00 0x00 Level(1,Ally,False) [16,10] [16,10] [0x00] [00000000]
UNIT Sain 0x00 0x00 Level(1,Ally,False) [8,12] [8,12] [0x00] [00000000]
UNIT Lyn 0x00 0x00 Level(1,Ally,False) [16,4] [16,4] [0x00] [00000000]
UNIT Empty

GoodEH: // allied units in hard mode (you can limit the # allowed in battle preps)
UNIT 0x02 0x00 0x00 Level(1,Ally,False) [16,10] [16,10] [0x00] [00000000]
UNIT Sain 0x00 0x00 Level(1,Ally,False) [8,12] [8,12] [0x00] [00000000]
UNIT Lyn 0x00 0x00 Level(1,Ally,False) [3,4] [3,4] [0x00] [00000000]
UNIT Empty

BadEN: // normal mode enemy units

UNIT 0x49 Myrmidon 0x00 Level(15,Enemy,False) [16,2] [16,2] [0x9C] [0x00, 0x03, 0x09, 0x00]
UNIT 0xB3 Archer 0x00 Level(10,Enemy,True) [14,15] [14,15] [ShortBow,IronBow,Vulnerary]
[0x00, 0x03, 0x09, 0x00] // loads inventory of ShortBow etc.
UNIT 0xB3 Pirate 0x00 Level(10,Enemy,True) [18,13] [18,13] [SteelAxe,HandAxe] [0x00, 0x03,
0x09, 0x00] // unit has AI of “attack in range” (00030900)
UNIT 0xB3 Pirate 0x00 Level(10,Enemy,True) [2,12] [2,12] [PoisonAxe,Vulnerary] [0x00, 0x03,
0x09, 0x00] // unit DOES autolevel (set to true)
UNIT 0xB3 Pirate 0x00 Level(10,Enemy,True) [10,6] [10,6] [IronAxe,HandAxe] [0x00, 0x03, 0x09,
0x00]
UNIT 0xB3 Pirate 0x00 Level(10,Enemy,True) [6,7] [6,7] [HandAxe,Vulnerary] [0x00, 0x03, 0x09,
0x00]
UNIT 0xB3 Fighter 0x00 Level(10,Enemy,True) [15,6] [15,6] [SteelAxe,HandAxe] [0x00, 0x03,
0x09, 0x00]
UNIT 0xB3 Mercenary 0x00 Level(10,Enemy,True) [7,3] [7,3] [SteelSword] [0x00, 0x03, 0x09,
0x00]
UNIT 0xB3 Mercenary 0x00 Level(10,Enemy,True) [12,10] [12,10] [PoisonSword,Antitoxin] [0x00,
0x03, 0x09, 0x00]
UNIT Empty
BadEH: // for hard mode units
UNIT 0x49 Myrmidon 0x00 Level(15,Enemy,False) [16,2] [16,2] [0x9C] [00000000]
UNIT 0xB3 Archer 0x00 Level(12,Enemy,True) [14,15] [14,15] [ShortBow,Longbow,Vulnerary]
[00000000]
UNIT 0xB3 Pirate 0x00 Level(12,Enemy,True) [18,13] [18,13] [SteelAxe,HandAxe] [00000000]
UNIT 0xB3 Pirate 0x00 Level(12,Enemy,True) [2,12] [2,12] [PoisonAxe,Vulnerary] [00000000]
UNIT 0xB3 Pirate 0x00 Level(12,Enemy,True) [10,6] [10,6] [IronAxe,HandAxe] [00000000]
UNIT 0xB3 Pirate 0x00 Level(12,Enemy,True) [6,7] [6,7] [HandAxe,Vulnerary] [00000000]
UNIT 0xB3 Fighter 0x00 Level(12,Enemy,True) [15,6] [15,6] [SteelAxe,HandAxe] [00000000]
UNIT 0xB3 Mercenary 0x00 Level(12,Enemy,True) [7,3] [7,3] [SteelBlade,Vulnerary] [00000000]
UNIT 0xB3 Mercenary 0x00 Level(12,Enemy,True) [12,10] [12,10] [PoisonSword,Antitoxin]
[00000000]
UNIT Empty

org 0xC9C9C8+(4*0x59) // - Pointer to tile map changes

POIN TileChanges // repoints tile changes

org 0xCB1F00 // puts data at offset 0xCB1F00

TileChanges: // list of tile changes

TileMap(0x00,0x03,0x02,0x01,0x01,VillageGate) // tile change #0 (0x00)
TileMap(0x01,0x03,0x08,0x01,0x01,VillageGate) // top-left tile of change is [0x03,0x08] or [3,8]
TileMap(0x02,0x02,0x0B,0x01,0x01,VillageGate) // [0x02,0x0B] = [2,11] – convert to hex
TileMap(0x03,0x01,0x0E,0x01,0x01,VillageGate) // w/ your head or a calculator
TileMap(0x04,0x09,0x0E,0x02,0x01,TownGate) // tile area is 2 tiles horizontal, 1 tile vertical
CODE $FF // terminates tile changes
CODE $00 // above
CODE $00 // above

VillageGate: // name of tile data group

CODE 0x80 0x00 0x00 0x00 // one tile [0x80,0x00] – use reference tilesets to obtain hex

TownGate:
CODE 0x24 0x08 0x28 0x08
CODE 0x00 // separator to prevent mixing of data
Hopefully you’re on your way to making your own chapter with all the knowledge you have. All that’s
left is some finishing touches—first, I’m going to cover tile changes in detail, and then we’ll work on the
finishing touches (using the Chapter Data Editor to finish your chapter construction).

Chapter 53: Map Tile Changes

THIS WAY OF DOING TILE CHANGES IS OUTDATED! I have kept it here for reference, but please use
this better method instead!

[Link]

Here’s another tutorial that covers the same thing:

[Link]

Sorry but I don’t actually know how to used Tiled yet as I haven’t really needed to do so, and these
tutorials seem to do a fine job of explaining it… so this is all I can offer. Best of luck! XP

----------------

Here’s the run-down of how I set up tile map changes to work in the EA. Although I’m sure NL could
work this out much better than I have, here’s something that works and doesn’t require you to do it in
hex, but together with the events in the EA.

org 0xC9C9C8+(4*0x??) // - Pointer to tile map changes

POIN TileChanges

org 0x????????

This repoints the tilechanges to your new tile changes and sets them to be at offset 0x???????? (you
have to put in the offset, of course).

TileChanges:
TileMap(0x00,X,Y,XL,YL,TilePointer)
CODE $FF
CODE $00
CODE $00

Creates a label called ‘TileChanges’ which contains data for the tile changes. TileMap(blob) is a macro.
The first byte in the blob is a sequential byte—it starts with 0x00 and goes up. Co-ordinates must be in
hex (sorry) and are from the top-left of the map, as always. (X,Y) is the top left tile of the area that
changes. XL and YL are the lengths in tiles to go horizontally (XL) and vertically (YL). “TilePointer” is the
name of a label with the data for the tiles that it will change to. For example, if you have a 2 by 2 room
that changes and the top left tile is (18,10) you’d do TileMap(0x00,0x12,0x0A,0x02,0x02,Room).

TilePointer:
CODE (Tile hex)
CODE $00

CODE (Tile hex) is the hex of the tiles. You write out the hex of the tiles from left to right (and
then going down the rows). So if my tiles were 0xD0 0x04, 0xD4 0x0C, 0xD8 0x04, and 0x5C 0x07, for
example (I just chose random tiles), I’d do:

Room:
CODE 0xD0 0x04 0xD4 0x0C
CODE 0xD8 0x04 0x5C 0x07
CODE $00

To know which tiles to use, you need to have the “co-ordinates” of the tiles. You need something to
reference—that’s where there are reference tilesets. Unfortunately they are only for FE7, which is the
bad part. You can find FE7 Reference tilesets in the documentation part of my website (yes, in the doc
part, I know). Here’s what one looks like:

You can’t see it very clearly in my image because mine is resized, but at the top and to the left there are
numbers. If I wanted say, the open chest tile, I’d use 0x04 0x00. That is, I use the column it is in (the
numbers at the top), and then use the row it is in (numbers to the left).

The #define stuff is just the definition for the Tilemap macro. I wouldn’t edit it if I were you.
Now if that wasn’t good enough for you, you can check out Icy Toast’s old tutorial on tile map changes in
hex. You can find it here- [Link] (you have to
go down the page to find the part on tile changes though).

Chapter 54: Chapter Creation Finishing Touches

Before we’re totally finished we should fix up some of the stuff in the Chapter Data Editor. It’ll help out
with our chapter creation—we already have the maps and events, so now it’s onto the other stuff.

I’ve already been through what all this does, but anyhow… the triggerable map changes byte should be
the one for your chapter and it should match the byte in the Tile Map Changes part of your events.

If the Preparations Screen is turned off and you try and load battle preps (ENDB), it won’t work. If it’s ON
and you don’t load battle preps, idk what’ll happen, but it could screw up as well. Just make sure that
the events match the setting in the CDE. If you used ENDB/GotoPrepScreen at the end of your opening
scene, the game will try and go to the battle preps, but only if it is enabled. And, of course, if
preparation screens are on, remember to have an event on turn 1 with the BlackOff code (for FE7,
anyhow…).

Make sure your weather and battle tileset match your map/what you want them to be. Change the map
music around as well if you want.
Just showing some more music you can change. It’s better to use the “Chapter Opening BGM” thing
instead of your own event code to load the music at the beginning of the chapter. (I use 0xC3 “Nothing”
in this screenshot, but I actually have custom music inserted over it, so it actually does play a song, mind
you…)

Changing your chapter name/number text is a good idea. Again, make sure your event data reference
byte is right, and if you don’t want a worldmap chapter prologue scene, set that byte to 0x00. Also, take
care of the augury text if needed (on later chapters in Eliwood’s mode Hannah or whatever her name is
will appear and the augury option will be turned on).

More augury text and the portrait and the price, obvious stuff. The Preparation Screen Ch. No. only has
to be worried about if you have battle preps on. It’s what it displays as the chapter at the top.

See where it says “Chapter 10”? That’s what I’m referring to.

Anyway, the Merlinus co-ordinates are easy, as is the Winning Road byte. The chapter title display fade-
out is somewhat important because it dictates how your chapter starts off. If it’s ‘fade to black’, you
need to use the black off code to fade out of the black and onto the map, IIRC. *alternatively you could
TRY the FADU or REMA code, but I can’t say it’ll work*

Just a few more things we might want to take care of. You’ll probably need to change your
objective/goal text, and possibly the goal window information. If you are doing a defend or timed
chapter of some sort, a turn count would be nice. For the protect character marker, see the original
chapter on Chapter Data editing. The tile marker would be used in like an escape chapter to specify
where the unit should escape to. XP

Now save any changes in the Chapter Data Editor and exit. Assemble your events (I say how in like the
first chapter on Event Assembly—you just input the text, output the ROM, hit the game you are
assembling for on the right, and hit “Assemble”) and fix any problems there are. Test your events out as
well. There are many, many places you could make errors in, even if the Event Assembler doesn’t report
an error in your events. (It only reports stuff that it can’t properly interpret—it doesn’t say whether the
event will turn out like you actually want it to in-game, it doesn’t know that much.)

Here are some things to check if you’re having errors:

- Names of definitions. If you use say “IronLance” and it doesn’t work, that’s because the weapon
is defined as “IronSpear”. The EA is case-sensitive. IIRC sometimes weapons like “Armorslayer”
are spelled “Armourslayer” (although I could be wrong about this specific case).
- If you aren’t sure what a macro, definition, or code is, look it up. If you aren’t sure what a code
does, see if I explain it, and if it’s one of the few codes I didn’t cover, ask a question about it on a
forum or something.
 - If the game says that certain things aren’t word-aligned, look at where the error starts. That is if
it says “Opening_scene:” and everything beyond isn’t word-aligned, then look BEFORE that for
something that might somehow mis-align it. The code ALIGN 4 should help realign stuff
afterwards, by the way.
- If you can’t load even up to the main menu, it’s very possible that your chapter name is too long
or something. Try changing it.
- If the game screen goes black after starting the chapter, you may need the BlackOff code.
Otherwise, try changing the Chapter Title Display thing in the Chapter Data Editor (I will
reference this as the CDE from now on).
- Always double-check your pointers in Nightmare and the such. Don’t forget about adding
0x08000000 to your offset.
- If it says “X is an invalid name” it’s likely because you didn’t actually make a scenic event, but
you made the base event for it (an event that points to said event).
- If it says some code isn’t supported, check the format. This is likely to happen in Unit Data if you
forget a byte or make a typo or something.
- Remember, use FADI code to fade into black, run some ‘background events’—stuff the players
don’t need to/shouldn’t see happen, and then use FADU to fade out to either the map, a dialog
background, or CG.
- If battle preparations aren’t loading, check the Battle Preps byte in the CDE, or check to see if
you used ENDB (for FE7) or GotoPrepScreen (for FE7 and FE8, maybe FE6, idk for sure).
- It IS possible that the EA isn’t working properly somewhere. Make sure it’s not your own
mistake first and then report it and see if a problem is the EA’s fault. The EA is pretty well done,
but it’s easy to make a small error somewhere.
- When asking for help on events, post your script! Knowing how to ask questions is imperative.
Post a script, a patch, and a savestate. That way people have the information to help you.
Sometimes screenshots and videos are useful too.
- Don’t forget CODE 0x00, ENDA, or UNIT Empty at the end of a group/label/event. CODE 0x00 is
for the main framework events (turn, character, location, misc, and ballista events), ENDA is for
scenic events, and UNIT Empty is for units, if you forgot.
- If your map isn’t loading, there are various reasons why it may not load. It’s probably a pointer
problem though. If it loads but looks weird, either your map is corrupted or you are using the
wrong tileset. See the map chapter(s) for more information.
- Sometimes if you forget the ‘BlackOff’ code units may not load or move properly. There are
many weird glitches that come along with not using this code, for whatever reason, so beware.
- There are many, many codes and macros that can be used. See if one of them can fit whatever
you need. If it happens in the original game, it can probably happen in your hack too, so
sometimes analyzing other events by disassembling is useful.

That’s all I have to say to help you for now. With that, I hope your custom chapters are success!

Chapter 55: Importing Tilesets

Ever wanted to use a tileset from another game? This tutorial will teach you how. It’s actually a
very simple concept—locate the data in the game that has the tileset you want, copy it, and
repoint it. That’s it.

In this example I’ll import the Valni tileset into FE7. First I load Nightmare, an FE8 ROM, and the
event table editor. I locate the tile config, object, and palette I want to use. In addition, I’m
going to transfer a map, just so I can test that the imported tileset works without having to
make my own map.

Wow, I sure am lucky! All the offsets I need are right next to each other! I’ll start with the object
type. This is what it looks like:
I have to go to this offset and copy the data there. But how do I know to stop? Well, I have to
know by finding the offset of the object type that comes before it. This is object type 10.
I go to object type 10 and see the offset 0x8165F7C. So the Tower of Valni object type ends at
0x165F7C. So I go to the offset 0x1609BC and copy the data from there to 0x165F7C using a hex
editor. Pic below:
Then I paste it into some free space in the game I am importing to. I will use 0x1040000 in this
example/for this tutorial.

Now I have to do the same thing for all of the other data I am importing. Actually, importing
most data (aside from ASM, animations, and data that has pointers inside of it) works like this,
so importing a tileset is nothing special. =O

Once I’m done copying the data from one game and pasting it into another, I have to repoint
the data in the other game. Since I am importing into FE7, I open nightmare and load the Event
Reference Module. I can replace an existing tileset and repoint the old pointers to the new
tileset info.

(This just shows me repointing the Dragon’s Gate tileset to something else. You can also replace
other entries besids tileset entries but you have to edit the Chapter Data Editor dropdowns to
let you select said bytes, and you have to know what you are doing in general… it’s too complex
for me to explain it, sorry.)

Anyway, as said, do that with each part of the tileset (and the map as well) and then enter the
bytes into the Chapter Data Editor per normal.
Err, you’ll notice my thing is sort of kinda uh… “hacked” so that there aren’t any dropdowns.
This is because having dropdowns is often times limiting because I can’t enter any value I want
to. D=

Anyway, once that’s done, load up your ROM, test your map, and enjoy your imported tileset

Chapter 56: Animation Importation

Chapter 57: Custom Battle Animations – Frames

Okay, now this is one cool aspect of Fire Emblem hacking, in my opinion. In fact, if you want to
have a good hack, you need at least a couple of these. In my opinion, of course.

Part 1: Briefing

A custom battle animation is just what it says. When you play Fire Emblem and you have
animations on and you use say, Eliwood, to attack a bandit, you see a red-haired guy with blue
armor stab a shirtless dude with an axe. Each of those characters has their own ‘animation’. An
animation, in case you don’t know, is like a bunch of pictures shown right after each other to
give the appearance of movement. You can google for more details.
So yes, we can have our own animations. That is some great stuff. But, you have to make the
sprites—the little guys who do the moving—as well as format the sprites, which I will cover in
this tutorial, and then script the sprites.

Where do you get sprites? Well, you can always make your own battle sprites. You could also
use other games’ sprites, assuming they are 16 colors or less, because battle animations must
be 16 colors or less—and I mean the ENTIRE sheet must use the SAME 16 colors
THROUGHOUT—you can’t have each sprite use a different set of 16 colors. Usenti is a great
way to reduce colors as it has a Palette option called “Requantize” which will forcibly reduce
colors, and it also has a palette box to the right which can be used to manually edit colors.

You could also request someone to make a sheet (collection) of sprites for you, AKA an
animation. But getting the sprites is YOUR problem. I can edit existing Fire Emblem battle
sprites myself, which is an important skill, because most of the time in hacking, you have to be
able to supply yourself with the things needed to hack.

Part 2: The First Frame

Anyway, onto actually making the animation. What we are going to do is create individual still
images of each part of the animation. Each image is called a frame.

That right there is my first frame of Kelik, an original character of mine. He’s standing. I call it
my standing frame, AKA an idle frame. He’s not doing anything. He’ll be in this position at the
beginning and end of battles, as well as when he gets hit, and just while he isn’t doing anything.
It’s also the base frame I use for every other frame. So it’s important.

How did I get this frame? Well, I do everything in MS Paint, personally. To start, you need a
248x160 image. 248x160 means the width is 248 and the height is 160. The reason why is
because the GBA screen is 240x160 pixels. The extra 8 pixels in the width is where you can put
your battle palette.

So I open MS Paint and make my image with dimensions 248x160.

Then, I fill in my image some color that has a very, very low chance of being a color in my battle
palette. Since Kelik is not green, I’ll put in green.

Okay, that’s really all you should have now. Next, we put in our sprite. Now, we want our sprite
to fit in with the battle background, platforms, template, and other animation. So we want to
make sure its feet are at the right level.
It’s hard to see, but at the bottom-right it shows the co-ordinates of the pixel I am hovering
over (which you also can’t see, but my invisible cursor is at the bottom-left of his left foot, our
point of view). It says “143,101”, which is about right. The near foot should be about 100 pixels
down. The body should start showing up about 140 pixels to the right. Granted, if you have a
bigger sprite, you might need to make some adjustments.

What you must do is paste your sprite and then position it in that general area to get a good
alignment. Generally if the left foot is at about (142,100) you should be good, but there’s no
specific rule.

By the way, an important feature you should know how to use is the opacity/transparent
control feature of MS Paint, which is to the left. When using the select tool, you can make a
color transparent, or see-through. The default color to be see-through is white; however, you
can right-click any color on the image and make that the transparent color. You’ll know it’s the
transparent color because it’ll show up as the other color at the far-left of the color box at the
top of MS Paint. For example, if I right-clicked green (which is the background, so it should be
transparent), the color box would look like this:
The transparent color is circled in orange.

However, your toolbox must also have the appropriate setting on for that color to be
transparent:

Do you see the blue-highlighted box at the bottom? The top one will make the background
color (green) opaque, as in, it won’t be transparent. If you click the bottom box, the color WILL
be transparent. It’s that simple.

Anyway, back to making the frame. You should have something like this, but with your own
sprite:

Next is an optional part. I highly suggest you do it. I call it palette preparing. You see, FEditor
Adv can automatically detect your 16 color palette for you, but sometimes, it just kinda acts
silly and messes up. Other times, you may want to have a specific order to your palette, e.g., if
the animation you are inserting is a Pegasus knight with axes, and you want it to be compatible
(palette-wise) with the lance Pegasus Knight animation. If you don’t care for this, you can skip
it, but don’t blame me if your palette acts weird later.
Part 1B: Palette Preparing

So, what you are going to do is place all 16 colors of your palette in the top-right corner. The
very top-right color must be the background/transparent color, and the colors after that can be
in any order you desire. How to get the colors? You can either manually use the eye-dropper
tool and select each color and then place one pixel of it in the top-right corner, or you can use
the “Usenti method”, which I invented.

To do the Usenti method of palette preparing, you must first download and open Usenti. It
should look like this:

Then, drag your image (standing frame) onto Usenti (or use File->open to open your standing
frame).

At the right is a palette box. It has a list of all the colors used in that image. Because battle
sprites must be 16 colors or less, your palette should be no more than 16 colors. (Having more
than 16 colors is a spriting issue, so if it IS more than 16 colors, ask some spriter how to get rid
of colors.)

Here is my palette box:

As you can see, there is one row, or 16 colors. Now what you must do is take a screenshot of
Usenti by pressing the screenshot button on your computer. Then, open up a new window of
MS Paint, and paste your screenshot into that window. Then, using the select tool, find the 16
colors in your palette box, select them, and copy them. This is what I’m talking about:

Then, paste that bar into your standing frame image, near the top-right, and zoom in, like so:

Now we have some colors here that aren’t actually apart of the palette. I’m talking about the
red, white, and green outline, as well as the black stuff in between, and the grey outline. We
need to get rid of all that, which can quickly be done by usingt he bucket tool and making all
those dumb colors into the transparent/background color (dark green in this case).

Great, we have what we need. Now we use the eyedropper tool to select each color and put
one pixel of it in the top-right corner. Watch.
Do you see the colors at the top-right? The very top-right pixel is the dark green background
color, with the rest of the colors to the left and below that. Just make that the area of the
palette space is 8x2 pixels (8 times 2 = 16 colors), i.e. one row should only have 8 colors. If you
by some chance don’t have 16 colors and have like, 14 colors, just make the rest of the area
dark green (transparent color).

Now, delete the big squares of colors, and save your image, which should look something like
this:
(Note: I’m zoomed in at 2x or 200%)

Part 2: Testing the Foundation to Your Animation

You now have one frame. Wooh, that may have seemed like a lot of work. In fact, your first
time, it probably will be, especially since you have to read my long, detailed explanations of
how to do everything. But once you know what you’re doing, it should only take 5 minutes, if
that.

Now that we have one frame, we can base every single other frame off of this one, because the
palette is set-up (well, maybe it is). However, to be safe, we are first going to test your
animation, to make sure that the first frame was made right.

WHAT?!

WE ONLY HAVE ONE FRAME?!

Yes, but that one frame will be the basis for every other frame, so it better work right!

We’ll just make a simple animation script. It starts with a text file, a simple notepad file ending
in .txt. Since my guy is named Kelik and his class is “Legend” and he uses a sword, I
appropriately called him Kelik Legend (Sword).txt.
Since I’m nice, I’ll give you guys a template script. As long as you have one frame called
“[Link]”, it should work. Which reminds me—ALWAYS SAVE YOUR FRAMES AS PNG’S.
Why? Because BMP’s take up a lot of space, and I always use PNG’s, so it’ll be easier to follow
this tutorial if you do too. Plus, if I remember correctly, FEditor Adv only accepts 24bit bitmaps,
and I could explain that to you, but I really don’t want to.

------------------------

/// - Mode 1

C03 -

C07 -

3 p- [Link]

/// - Attack Frames

C04

C1A

C1F

/// - Frames after hitting but before stopping to wait for HP depletion

C01

/// - RETURN TO BASE

3 p- [Link]

C06

C0D

~~~ -

/// - Mode 3

C03 -

C07 -

3 p- [Link]

/// - Critical Frames

C04

C08

C1F

/// - Frames after hitting but before stopping to wait for HP depletion

C01

/// - RETURN TO BASE

3 p- [Link]

C06

C0D

~~~ - Mode 5

C03 -

C07 -

5 p- [Link]

C05

4 p- [Link]

C01

4 p- [Link]

C06

3 p- [Link]

C0D

~~~ - Mode 6

C03 -

C07 -

5 p- [Link]
C05

4 p- [Link]

C01

4 p- [Link]

C06

3 p- [Link]

C0D

~~~ - Mode 7

C02

2 p- [Link]

C0E

3 p- [Link]

C01

2 p- [Link]

C06

2 p- [Link]

C0D

~~~ - Mode 8

C02

2 p- [Link]

C0E

3 p- [Link]

C01

2 p- [Link]
C06

2 p- [Link]

C0D

~~~ - Mode 9

3 p- [Link]

C01 -

~~~ - Mode 10

3 p- [Link]

C01 -

~~~ - Mode 11

3 p- [Link]

C01 -

~~~ - Mode 12

C03 -

C07 -

3 p- [Link]

/// - Attack-That-Will-Miss Frames

C04

C1F

/// - Frames after hitting but before stopping to wait for HP depletion

C01

/// - RETURN TO BASE

3 p- [Link]

C06
C0D

~~~ - End Animation Data

-------------

Everything between the dashed lines is part of the template script, so copy and paste it into
your text file. Then save it.

You now have a working script. You don’t know what it does though, because I haven’t taught
that, and I don’t plan on teaching it. Ever. In this chapter. :P

In all seriousness, all it does is show the standing frame for literally every single animation
mode. But that’s cool enough for us. Let’s crank up FEditor Adv with our ROM so we can insert
this bad boy.

Oh, but quickly, a review of what we have:

- one frame called ‘[Link]’ with the sprite and the palette at the top-right that we
spent forever making

- a script that we gave a nice name to with the codes I provided you

That’s it. And both items are in the same folder, because I said so (hint: put them in the same
folder).
OSHI- IT’S FEDITOR ADV

Yes it is. This is the “Class Animation Creator”. What you want to do is hit the “Load from Script”
button. Then, select your .txt file animation script. FEditor Adv will run through it and stuff. If
your script is error-free and so is your image, nothing will come up. If some error does, here’s
what you should check:

- size of image (should be 248x160)

- file type of image (PNG? if that somehow doesn’t work, try a 24bpp bitmap)

- palette (if you didn’t prepare the palette, try doing that. If you did, make sure it’s less
than 16 colors!)

- script is .txt file with what I gave you

- Blazer (check to make sure he isn’t being dumb and didn’t forget something or mess up
something? if it’s none of the above it might be this… >_>)
At the end, in the small dialog box at the bottom, it should say “Mode: Complete” if it’s all
done.

NOTE: IF IT GIVES IN AN ERROR YOU MUST HIT “RESET ANIMATION” BEFORE YOU TRY TO
INSERT THE ANIMATION AGAIN. I ALSO SUGGEST HITTING “QUIT” AND RELOADING THE
EDITOR IF FEDITOR ADV IS GIVING YOU PROBLEMS. (If you’re wondering why I bolded
that, I got an e-mail saying that someone got stuck for 1-hour because they didn’t; and
admittedly it’s not the most obvious thing in the world and I should have mentioned it, so
yeah, here it is.)

Here’s the dumb part. You have to save the animation by clicking “save to file…”. I usually
make a new folder called “Animation Data” within the folder where I am keeping all my
frames and the animation script, and I save it in there. Just name it something logical and
then go to the Class Animation Manager in FEditor Adv.

Okay, so now you have to find the animation you want to insert over. You type in a new
number into the “Input Index”, which neatly corresponds to the animation list supplied in
the folders of Nightmare Modules.
Once you find the animation you want to replace, you hit “Insert” and find that one file you
just saved with the “Class Animation Creator” part of FEditor Adv. Let FEditor Adv do it’s
shit, then save your ROM with FEditor adv.

If all goes well, your guy should be standing, kinda like this.

And that’s all the sprite should be doing, because you only have one frame. If it’s just doing
that, and it’s looking hella boring, that’s great news. We can now go on and make every
other frame. If there are some issues, we gotta fix them.

The main issue that comes to mind with this is the palette issue. You see, a custom battle
animation has its own palette. You can force a character to use that class’s battle
animation’s palette by setting their palette in the character editor to “0x00”. Look:
You see the blue box? It’s set to “0x00” because this character has a custom animation. The
animation we are inserting has the palette for us, so we don’t need to assign the character
another palette. This may or may not be the case for your animation.

If it’s another problem, I can’t be a psychic and predict and address it here, so I suggest
posting on a forum or something to get some help with it. Make sure to post your
animation script and the frame (and possibly a patch that lets one test the animation
quickly or a screenshot showing what it looks like) or else there’s no way to really tell what
the might problem be.

Anyway, back to the ideal situation—everything works. Now we exit out of FEditor and
Nightmare and go back to that standing frame in MS Paint.

Part 3: Making the Rest of Your Frames

Looking good, kinda. Now, we have to make the rest of the frames. You can start with whatever
mode you want—attack, critical, range, range critical, or dodge, but ultimately, every time you
do a new animation mode (a part of the animation), you should start with the standing image.

Now, if you already know how to animate images, this is going to be a piece of cake. If not, well,
it’ll take some practice and tweaking to get right, but have patience.

You need to copy the sprite from your sprite sheet and paste it onto MS Paint. Using the
transparency feature of MS Paint which I explained a while ago is quite useful.

Can you see how the selection of Kelik I copied over has some green, and that green is covering
over the old Kelik? It’s really hard to position my new pose over the old pose like that. So I turn
on transparency, and wala:
Now I can drag him around until I get him to align with the last sprite. In this case, he’s only
supposed to move his chest/head while dodging (because he’s slick like that). Since his feet
aren’t moving, I can position the feet of this new pose over the feet of his old pose.

Wait, I can still see his old pose hiding behind there! Yeah, that’s a problem. That’s why once
you align the new sprite/new pose over the old one, you can change the transparency mode to
make it un-transparent, which will get rid of the old sprite. You should see what I mean:
(Notice how transparency is turned off using the box on the left toolbar)

Okay, we have another frame set-up. But it’s still called “standing”.png. That’s a problem. Using
file->save as, save it as something else. Since this pose happens to be a dodge pose, I’ll call it
“[Link]”. Thankfully, I’m lazy and I only made one dodge sprite, so there isn’t even a
“[Link]”. Haha.

Now that I’m done with that animation mode (that was quick), I’ll do another one.

Doing the range mode frames is pretty easy, because chances are, your character won’t have to
move much. That is, you don’t have to worry about whether a weapon will actually hit an
enemy, and there probably won’t be much feet movement, or jumping, either. My point is, I
don’t really have to cover that too much—just put the frames and know that the game will take
care of showing the actual spell animation (for example, when the ice tornado forms and the
ice block shatters in Fimbulvetr—the game will take care of that for you).

Physical attacks, however, are a bit harder. If you’re a mage, your attack animation and ranged
animation are the same. If you’re like Kelik, and you’re a swordsman, your ranged animation is
only used for ranged swords, while your attack animation is used for melee (close-up) attacks,
so it’s different.

What makes physical attacks harder is just keeping track of the sprite’s movement. You don’t
want it too high or too low. Remember, foot level is about 100 pixels down (it’s not some
difficult number like 126.38 so no complaining). Your guy’s sprite should start about 140 pixels
to the right. And the enemy’s center is typically at about (90,85) so that is where a weapon
should slash through or whatever, approximately.

If you look at an actual screenshot of a game (even though this is a hack), you can see that
there really isn’t too much space between the two enemies, so keep that in mind.

Here’s a screenshot of one of my attack frames. This is when the enemy is actually being hit.

It’s hard to see as usual, but at the bottom-right is the co-ordinate (92,87), which is ALMOST at
what I suggested (the co-ordinate (90,85)). You could check the feet too and see that it’s at
about 100 pixels down.
What is the significance of all this info? Why am I telling you? Well, during your attacks, you
have to make sure the sprite will actually reach the enemy, but not have its sprite go too far
into the enemy, or make it look like your character’s weapon is just BARELY hitting the enemy.
Not only that, but you need to make sure that when your character moves back to his/her
starting position, they are at the right place—which is why you always use your standing frame
as a base to make sure your animation flows smoothly and that all other frames are aligned.

Now, we’re ALMOST done learning about making frames. I know, we haven’t even gotten to the
coding, but thankfully coding is easier than this, or at least not as time-consuming.

One important thing I must show you how to do is piercing frames. The first example that
comes to mind is a Knight. When he stabs an enemy with his lance, the lance doesn’t just
appear right over the enemy sprite. It kinda actually looks like the lance is going through them,
even if there is no blood.

This is not the example I was talking about, but whatever—you can see that the thief sprite
somewhat covers the General’s spear a little, the point being it looks like the weapon’s going
through him. Well, you have to make a special version of a frame for this effect.

This new frame will have a size of 488x160. You may have guessed already: the frame consists
of 2 screens, each being 240x160, side-by-side, for a (240x2)x160 or 480x160 image, with an 8
pixel column for the palette, just like before.
Now, I’m gonna have to be a bad kid and switch my example animation to another one,
because Kelik, the red-jacketed sword guy I’ve been showing, doesn’t use piercing frames (he
slices, doesn’t pierce).

First, this:

Then, this:

(Note: the name ‘a13p’ stands for ‘attack13pierce’, as in, attack frame #13, which is a piercing
frame.)
This is actually a very easy-to-do maneuver. The left portion of this frame is everything that
DOESN’T pierce. It’s the 240x160 image of everything but the weapon. And the right portion of
this frame is the sword; it pierces. If there is an enemy there, the enemy’s sprite will have
priority over the sword, making it so that the enemy sprite/body covers the sword. Making it
look like the sword went through the sprite… in short, piercing.

Once you set that up, you’re good to go. With piercing frames out of the way, you should now
know how to make all your frames for your animation. I need you to do that, so we can FINALLY
head on to the next chapter, which will cover animation scripts, and how the game will receive
your animation.

Chapter 58: Custom Battle Animations – Scripts

Oh my. In the previous chapter, you made your animation frames. Now, we have to code them.
That little template script I gave you will be the basis for that, but your REAL animation script
won’t be that simple.

First, you need to go to FEditor Adv’s doc and find the very important list of 0x85 commands to
use. I could explain the significance of the name, but it won’t help you with your hacking. In
case you can’t find it on your own, it’s in the “Battle Animations” folder, which is in the “doc”
folder, which is in the main folder of FEditor Adv. It’s called “0x85 Command Usage”.

Now go, read it. Yes. Read the ****ing doc.

I just pulled a Xeld. Had to do that at least once in this tutorial.

Okay, I will now go ahead and explain the template animation script I gave you, since you read
the doc and you have some background on a few things, maybe.

First, there are 12 animation modes. Each mode needs its own codes and has its own
significance, except for modes 2 and 4. I’ll explain each in order, so I’ll get to modes 2 and 4
very shortly.

Mode 1 is the attack mode. It’s the main attack that hits and does damage. But it’s not a critical,
and it’s only used in melee (close-up) fights.

Mode 2 is the above, but its sprites are layered BEHIND the enemy. This is how piercing is done:
in the piercing example in the previous chapter, the piercing sprites are put behind the enemy,
if need be. It’s automatically coded for you based off of the frames and mode 1, so no worries.

Mode 3 is the critical attack. It works the same as mode 1, but activates with a critical.
Mode 4 works the same as mode 2, but applies to mode 3. Consider it the piercing mode for
critical.

Mode 5 is for ranged attacks. This means attacks that load spell animations, but don’t actually
hit themselves.

Mode 6 is the above, but for critical ranged animations.

Mode 7 is the melee dodge. Close-range dodge. Enough said.

Mode 8 is the ranged dodge, for ranged attacks. Kay?

Mode 9 is the standing animation. It’s just for standing. Yes, you can have an animation for
standing guys, but good luck getting it to work right.

Mode 10 is another standing animation. Or so the doc says. If I knew what the difference
between mode 9 and mode 10 was, I forgot, or else I’d tell you.

Mode 11 is the last standing animation, for ranged attacks. If by some chance your character
stands differently when he’s farther away from an enemy, then by all means use this mode to
make your character stand differently.

Mode 12 is the missed-attack animation. It’s what happens when an attack misses. It’s usually
very similar to the normal attack animation.

Okay, now that we know that, I’ll cover how to actually code each mode. To be honest, once I
teach you the first mode, the attack mode, the rest will be a piece of cake, because the key to
doing each mode is using 0x85 commands to spice up your animation.

0x85 commands can add sounds, special effects, and other stuff. But mainly sounds and special
effects.

In mode 1 for the template, we have:

/// - Mode 1

C03 -

C07 -

3 p- [Link]

/// denotes a comment. So “- Mode 1” is ignored

C03 and C07 are important codes. Just keep them. (NOOO!!! DELETION!!! EVARRRRR!!!!!!)
3 p- [Link] is important. It’s the graphic-loading code. So it’s very important.

“3” is the time for the frame to be shown. “3” isn’t very long. When you test your animation,
you’ll see for yourself. It’s hard to tell you how long “3” is, so you’ll just have to play around and
test different values and find out what looks good. Just know that the time must be a positive
integer greater than 1 (e.g. 1, 2, 3, 4, 5… etc… why am I counting?).

“p” is just part of the code.

“[Link]” is the name of the frame to use. Make sure the frame is in the same
directory/folder as the script, or else you’ll have problems.

Now, onto explaining the rest of the script:

-------------------------

/// - Attack Frames

C04

C1A

C1F

/// - Frames after hitting but before stopping to wait for HP depletion

C01

/// - RETURN TO BASE

3 p- [Link]

C06

C0D

---------------

C04 is just what the doc says. It starts HP depletion. Keep it always when there is a hit.

C1A is the normal hit code. Just keep it next to C04, please. Oh, and you can only have one of
these.

C1F is the hit sound. It actually changes depending on whether the attack is a critical or not and
stuff.
C01 is the code that says “wait for HP to deplete completely before continuing the animation”.
Whatever frame is right before that is the frame that will show until the HP is done depleting.

C06 says “start enemies animation sequence”. And C0D ends the animation. So logically, you
will most likely just want them next to each other.

That’s the basis to the attack animation. It’s quite simple, no? You can add lots of frames
(although if you have too many frames in an animation, the game won’t be able to take it, and
problems that I cannot help you with will ensue), and you can also use other codes listed in the
doc (0x85 command usage text file).

For example, the doc says “0x1B Play quick "heavy step" SFE”. How do you use that? Simply put
a “C” in front of the hex and give it its own line. Like so:

C1B

That’s it. Then it will play that sound (which happens to be a stepping sound, which you will
probably use in animations that move).

If you don’t know what a sound sounds like, just test it out with your animation and find out.
Experiment with the codes if you need to.

Oh, there’s one thing the doc might have missed out on though. There is a special code that
works like this: “S####”. ‘S’ stands for ‘sound’. It’s a sound code. Xeld made a special hack that
made a new code that will play any sound. “####” is the hex of the sound. Oh, and it can play
music, too. If you need to know the hex of the song or sound or whatever, just look it up in a
music list that comes with Nightmare Modules.

Last thing—if your attack has multiple hits, you CAN’T USE C1A. So you have to use C51, which
is like a ‘fake hit’. It makes the screen flash white, but it doesn’t add those blue things. But oh
well—it’s still cool. Using C51 and C1F in conjunction will give the illusion that the enemy is
being hit. The idea is like so:

ATTACK FRAME

ATTACK FRAME

C51

C1F

JUMP FRAME

RAISE SWORD UP
SWING DOWN FOR THE BIG FINAL CRUSH

C04

C1A

C1F

Where the “C04 / C1A / C1F” is the final hit, where the HP finally depletes.

Now that mode 1 is done, comes explaining the rest of the modes, which will be easy.

Mode 2 will be done for you.

Mode 3 works the same as the critical, except instead of C1A, it uses any value from C08 to C0C.
I usually just use C08 because I know it works and while I don’t know what the other ones do, I
am guessing that it is just a difference in the color of the critical hit effect.

Mode 4 will be done for you by FEditor Adv as well.

Mode 5 is the ranged mode, as we know. Instead of a hit with C04 / C1A / C1F, you put “C05”,
which loads the spell animation. And that’s all there is to it—C05 will take care of the
spell/ranged weapon or whatever.

Mode 6 is the above, but the critical. You know how to put frames together and add in codes to
make it look and sound cooler, so go do that.

Mode 7 and 8 will probably be the same, since they are dodges, and most people don’t really
care to make their dodges different. Put the actual dodging frames after C0E, and the return-to-
standing frames after C01. Remember that the frame before the C01 will be the frame that the
sprite stays on until the move is “completely dodged”… if that doesn’t make sense, don’t worry
about it. Heheh…

Modes 9 through 11 can be some animation, but just know that the animation is just the idle
frames, so it shouldn’t be anything special. I usually just keep it as my standing frame, which
makes 3 modes automatically done, because all the template does is use standing frames in the
first place.

Mode 12 can just be a copy/paste of mode 1, but with the attacks taken out. Meaning that, if
you have multiple attacks, you need to put the C04, which will make the enemy do their dodge,
during the first attack, or else it’ll look like *slash slash slash* *dodge the final slash, no
damage* and it’ll just be wtf.

So if your animation looked like:

C03

C07

ATTACK FRAMES

C51

C1F

MORE ATTACK FRAMES

C04

C1A

C1F

OTHER ATTACK FRAMES

C01

RETURN TO BASE

C06

C0D

----------

It’d turn into

----------

C03

C07

ATTACK FRAMES

C04

MORE ATTACK FRAMES

C01

RETURN TO BASE
C06

C0D

-----------

If you didn’t notice, I moved the C04 back to BEFORE the first attack (remember, an attack can
also be C51 / C1F), and I got rid of the hit sounds and hit effects, or else it’d look and sound like
they were being attacked even though they dodged.

With mode 12 done, your animation script is done! Save everything and check for errors. You
may have written something and forgot to comment it out, or you may have accidentally forgot
to press enter and might have something like “C51C1F” on one line instead of two lines. You
may have also typed “c23” instead of “C23”, which matters—the “C” in commands MUST BE
CAPITALIZED. Also make sure you typed in all the file names for your frames right.

With the proofreading done, you can now insert your animation, which you already know how
to do, because you once tested the very basic animation in the previous chapter. Insert it, and
test it, and see how it is.

Is it too fast? Make the timings larger. Is it choppy? Well, you’d have to add more frames, so
that’s a spriting issue. Do the sounds work right, and how well are they timed? Try playing
around with the order and timings of things to fix that. Are there too many effects, or not
enough? Delete/add commands as need be—the 0x85 command usage list found in FEditor
Adv’s doc IS YOUR FRIEND. Lastly, are the frames aligned well? If not, go back to the frames in
MS Paint and try and figure out what’s wrong.

Touch-up your animation and make sure it’s looking nice and spiffy. Be sure to test out the
attack, critical, dodge, ranged, and ranged-critical animations, and anything else that might
need testing.
Mine looks pretty nifty. He looks like he’s having a staring contest with the Dragon! D=

Wait! There’s ONE LAST THING!

Your animation needs a disarmed animation. I’ll just tell you how to do it—now that you’ve
done the main animation, you already have more than enough skills to code the disarmed.
Simply make the disarmed frames based off of the standing frames, and then keep the bear
bones to every mode, while replacing all standing frames with the disarmed standing frames,
and making sure to remake the dodge frames into the disarmed dodge frames. Since there are
no attacks, you’ll save yourself trouble if you just make the attack modes just have one frame of
your character standing there disarmed—no one will know, and it saves space and time (since
FEditor Adv doesn’t have to process all the attack frames and codes).

That’s all there is to it. I know I say that and you’re like “that’s all? that took forever!” but once
again, even a complex animation with 50 frames could only take a few hours once you know
how to do it. I’ve probably (I never timed myself) done animations in less than 30 minutes, or
even quicker, for short ones that only have a dozen or so frames—so it’s really not that bad,
and in the end, it’s worth it, because there’s nothing like enjoying your awesome animation in-
game and sharing it with others who play your hack. ^_^

Chapter 59: Custom Spell Animations

Oh my. Custom spells. It is one of the hardest things to do in hacking, and one of the most
mysterious aspects of hacking. Very few people have done custom spells successfully, and very
few know much of anything about this.

Of course, this is where this chapter comes in. This is actually the very final chapter I am writing
for this tutorial, despite the order. Every other chapter has been completed as far as I know
(there are so many I can’t be sure). This is also going to be one of the lengthiest chapters,
despite the fact that I am going to try and be concise and straight-forward as much as possible.
Before you advance, please make sure of the following:

- You are able to insert your own custom battle animations. Many of the aspects of battle
animations are very similar to spell animations. If you cannot do the former, you have
little hope of doing the latter.

- You have a lot of free time and patience.

- You should have some basic knowledge of the following terms: opaque, transparency,
background, foreground, object, translucent, frame. Knowing the definitions and
understanding them should be sufficient.

- You have some spell sprites to work with. I of course cannot supply you with those. It is
up to you to make or find them.

Alright. Let us begin.

Before we start, we must check the spell sprites you have. The spell sheet as a whole does not
have to be 16 colors, but each individual frame has to be 16 colors. Thus we will not be
quantizing colors to change images to 16 colors (if they aren’t already) until we have made the
individual image first.

You will need FEditor Adv and an image editing program. I suggest Usenti if your computer
supports it as that is what this tutorial will use. It has the ability to reduce colors and do basic
graphic operations in a simplistic manner. It was also intended for GBA use, if you didn’t already
know, and so it’s just perfect for GBA hacking. If Usenti does not work for you you either A)
need to know how to do the same things with a program like Photoshop, PSP, or Gimp or B) are
screwed. This is why I always stick to Windows, that and all the other reasons.
But anyway before I get e-mails about how Macs are better (>________> longface) let’s get on
with the show.

Create a folder for all your spell frames. Include everything in there—reference videos, the spell
sheet, the README, and a blank text file named “[Spell Name] Script” where you will code your
spell script. In my case I am actually doing the entire process for this tutorial (not just faking it)
and am inserting a spell called Shaver. The spell frames are ripped from Fire Emblem: New
Mystery of the Emblem ~Heroes of Light and Shadow~, and thus they have more colors than
the GBA supports. They are also not in the perfect format for GBAFE. Thus the process will be
thorough and I may do something that aren’t necessary for you but may be necessary for
certain spell animations.

tl;dr I’m trying to covering everything.

There are two main layers for spells: the object and the background. The object is always
opaque. The background can be set to be translucent. The level of translucency is decided by
the script. Thus you won’t be doing any fancy photo-shopping to create translucency. It will all
be done by the game.

You must divide your spell sheet into these two layers. This is up to you as this is a spriting
matter. Decide which is which.

To start, we’ll want to test a very basic spell script. Start with two blank frames. One will be a
blank object frame, and the other will be a blank background frame. To do this you must know
the dimensions of the frames. The documentation on spells that comes with FEditor Adv will
help with this (and possibly other things) so take note of this.

Object:

Background:
I named mine “blank” and “blankbg” respectively for sake of ease. You may just want to name
yours something even shorter like “bo” (blank object) and “bbg” (blank background). I’m too
lazy to rename mine though.

If you’re using the doc version of this tutorial you may be able to just copy the images into an
image program and save them. If you’re using the HTML version (online) you should be able to
right-click them and hit “save image as…” to save them. If you’re using the PDF version all I can
do is suggest you try another version or simply make an image knowing the dimensions,
488x160 and 264x64 respectively. The background color does not particularly manner but I
suggest making it something that will not clash with any of the spell frames (or perhaps it
should clash to standout and rather not blend in with any of the spell frames) and something
that will most obviously be the background color.

When you have those two frames copy this into your spell script text file (just a standard .txt
file):

/// - Start Animation

C00

C00

C00

C00

C00

C00

C00

C000040

O p- [Link]

B p- [Link]

C00001A

C1F

~~~
O p- [Link]

B p- [Link]

/// - End Animation

Noting that “[Link]” and “[Link]” change depending on the filename and extension
of the blank object and blank background files respectively.

Now open up FEditor Adv with your ROM. I always use a testing ROM for my animations and
back-up the test ROM so that if something screws up, nothing bad that I can’t fix will result. I
always perfect it in a test ROM and if your hack gets messed up because you tried to do this
straight on your real hack, don’t blame me. Though you can’t blame me for any of this as this is
just a profit-free guide to hacking and you’re using it out of your own will with no responsibility
or liability on me.

ANYWAY…

Open up the scary spell animation inserter under tools. Should look like this:

Don’t freak out. Most everything on the top half is for manually making spells. We are using a script so
this is not necessary. Scripts are much, much better—much more convenient, much easier to use, much
easier to fix, much easier to share. So just forget about everything before the “Add Miss Terminator”
button, including that button.

“Max index” refers to the max # of spells you can have, which you can change to increase the amount of
spells you can have. (Derp)

Input index refers to the spell animation hex… that is, which animation you’re replacing. You should be
able to find a list with any spell association editor, that is the nightmare module named so, though I
believe it’s oddly called the Custom Item Animation List module for FE8—regardless here’s an excerpt
from the FE8 list (named Ranged Attack [Link])

74

0x00 - Nothing

0x01 - Hand Axe

0x02 - Arrow

0x03 - Javelin #1

0x04 - Javelin #2

0x05 - Javelin #3

0x06 - Javelin #4

0x07 - Javelin #5

0x08 - Javelin #6

0x09 - Javelin #7

0x0A - Javelin #8

0x0B - Javelin #9

0x0C - Javelin #10

0x0D - Javelin #11

0x0E - Dance/Play (Regular)

0x0F - Dance/Play (Regular)

0x10 - Ballista (Glitchy Arrow)

0x11 - Nothing (Stalls Battle Screen)

0x12 - Sword of Seals Fire

0x13 - Flametongue

0x14 - Fa's Holy Dragon Stone (BGM/SFX-kill)

0x15 - Iodun's Dark Dragon Stone (Mirrored)

0x16 - Fire

0x17 - Elfire

0x18 – Nothing

As you can see the hex is on the left with the name of the spell animation on the right. If you
didn’t already know, anything that is a projectile is considered a spell, including javelins, arrows,
and hand axes-it doesn’t have to actually be magic. This is just to simplify the naming of things,
it’s easier to refer to everything as spells.

I am going to replace 0x16, Fire, because it is very easy to just get a mage unit to use Fire. In
fact, my animation testing ROM has a save state with a mage (with a custom battle animation
nonetheless) using Fire, so this is totally perfect. *wink*

Regardless of whatever you replace you’ll likely need to use Nightmare to get a situation where
you can actually test the spell animation. I also suggest upping the critical a little bit and
keeping Nightmare handy so that you can ROM hack the character or weapon’s stats as to force
misses, hits, criticals, etc., to test various different situations. If you know how to RAM hack to
change those stats on the spot, that’s even better, but I won’t teach that here.

Back to FEditor Adv, type in the input index and load your script using the obvious button.
There should be no errors unless you somehow got the wrong image or typed in the wrong
path in the script. When it’s done the log at the bottom will show some stuff but not much else
will happen. You have to hit “terminate animation” to finish the spell insertion and insert it to
the input index. In the case that you’ve messed up, be sure to hit “reset animation” before
loading a script again, or you’ll load over an existing script.

Lastly if you want to dim the screen you can click that box. For things like arrows and javelins
you probably won’t want that but actual magic spells will probably want the screen dimmed to
make it more authentic as most if not all spells do so.
When it’s inserted the spell animation hit “quit” and save with FEditor Adv. If you need to,
setup a mage or something to use the spell (using Nightmare or the Event Assembler or
whatever is needed) and test the animation. Just be sure to close FEditor Adv after you’re done
so that you don’t end up overwriting changes (see the chapter on how to have good hacking
habits, wherever that one is, and why you shouldn’t have FEditor Adv and Nightmare opened
up simultaneously).

Congrats! You’ve inserted your first spell animation! It’s especially bland and should just involve a basic
hit and a quick screen dimming. That’s the point though—to make sure you know how to insert it. Now
all we have to do is add in actual sprites and spice it up with some codes.

Easier said than done thuogh.

Now we’re off to making frames. I’m going to start with the object frames first because I feel they are
easier. The image is divided into 3 parts: a 240x160 section, another 240x160 section, and an 8x160
section.

The first section is the foreground. I think. It’s the sprite that shows up in front of the battle animations.
The second 240x160 section (P.S., 240x160 is the size of the GBA screen, which you should know from
the battle animation tutorial) is the background. It’s what appears BEHIND the battle animations. All you
have to do is copy/paste your spell sprite to the appropriate section depending on what you want. As for
actually knowing where to put it, that is an animation issue, which is more of an artistic thing. I suggest
taking a screenshot of the GBA game and finding where you want your spell to start, then taking the
pixel co-ordinates of that point, doing that as you animate the frames. Again, the battle animation
tutorial teaches this so I will NOT go through this in detail.

If the frames are already fit to be 240x160 and animated for GBAFE, then that is absolutely awesome.
Just one more reminder: the spell should assume that the screen is NOT shifted. The screen’s view
sliding/shifting is a trick of the game, a code in the script.
The final portion is for the palette. You can enter in a palette like you did battle animations but it’s
tedious and mostly pointless so I suggest leaving it as the transparent color and FEditor Adv + the game
will handle the rest. Hextator did a good job of making this convenient, no? Props to him. XP

Believe it or not this Shaver spell I am inserting does not have ANY object frames; everything is
translucent and thus I have to use the background frames. However here is an example.

I suggest saving each frame as a new file numbered in the order they appear. Take note that
you load an object frame and background frame at the same time so one sprite may appear
simultaneously with another. Oh, the beauty of spell animations.

The object frames are a bit more of a pain in the butt. They are 264x64. Yes, only 64 height,
when the screen is 160 pixels. You see, these frames only use a specific portion of the screen.
160-128=32. They ignore 32 pixels. 16 on the top of the screen, 16 on the bottom. Why is it 64
height? The image is resized to be half. Why? Hextator (the creator of FEditor Adv and the CSA
system) had to do this in coding the new spell animation format. He actually made a completely
new system for spell animations. That’s why everything’s so different. And he worked hard on
this. I would know. I was there. So live with what you get and don’t be a whiner. ^_^

The actual width of the actual image here is 256x64. The last 8x64 portion is of course for the
optional forced palette. The image is 256x64 because you have to remember that the screen
can slide here in which case the range of the spell can become more than just 240 pixels, if you
get what I mean… (if you don’t get it, don’t worry about it; act like everything’s normal).

Time to do this. For my spell animation, my ripped frame starts off looking like this, though I
happened to pick a frame in the middle just for a first frame test (once we make our first
background frame, along with the object frame we learned to do earlier, we’re going to do
another spell insertion test).
Oooh, shiny. However, that won’t do for insertion. Gonna take off the bottom half first, then
resize it to 240x160.

Well it still looks pretty good to me. So let’s remove 16 pixels off the top and bottom then since
this part of the spell only takes part in the middle area…

All that’s left is to resize it to half again:

Add the 24x64 portion to the right to make it 264x64:

Aaaaand make it 16 colors. Oh wait, how do we do that? Well, I use Usenti (found on google).

Palette -> Requantize -> #colors = 16, “OK”

Result:

Thoughts: Blegh.

The quality has gone down. Even if the image will ultimately be stretched back to 240x128 height like it
should be (that’s just how these frames work, has to do with the transparency), the post-resized result
won’t be as good as the original and now that it onlny has 16 colors it doesn’t look nearly as shiny or
cool.

And what can we do?

Not much.

That’s hacking for you. Especially on the GBA system. There are limitations. You can’t always get what
you want, definitely not get it to be perfect. If you get it even close you should consider yourself lucky.

So we suck it up, save the frame, and go to our script to add it in there:

To do that though, you have to learn about the format of scripts. Before I go through a script though, I
suggest you open up the 0x85 command list for spells (found in FEditor Adv\doc\Custom Spell
Animations) and readup on that a little. Just a little, for old Blazer here. Then you can read my
explanation of each code below.

/// - Start Animation – always at beginning

C00 – buffer code. Stalls. Needed. If you encounter random looking graphic or palette errors you
probably need some of these. Sometimes if the spell progresses too fast it loads the wrong palette or
other data in the VRAM or elsewhere interferes with the spell. In short, just add these and take it easy.

C00

C00

C00

C00

C00

C00

C000040 – makes the screen slide. Always have it, and early.

O p- [Link] – object frame, followed by the path. This code must be proceeded by the next two
codes, they are all jumbled up together, you can’t load one frame by itself. Or if you can you couldn’t
back in the day. :P

B p- [Link] – the background frame. Same deal.

1 – the length of the frame. 1 is the shortest. Has to be a whole number. 3 is like slow. Most frames will
probably be 1-3. This is more of an animating thing, but you can test different times yourself to get a
feel for it.

C00001A – hit code, must have

C1F – hit sound, recommended

~~~ - miss terminator. This makes it so that the animation stops if a miss occurs. Stupidly enough this
HAS to be after hit code, meaning you can’t have an animation miss before it would have hit. It has to
miss after it would have hit. Yeah, I know. Silly and inconvenient. That’s life.

O p- [Link] – another frame loading code identical to the one above. Nothing special here.

B p- [Link]

/// - End Animation - ends loading code from the animation script

Now that that’s explained, let me go through the command list:

0x00 through 0x13 (except 0x08) - Ignored/unused – self-explanatory

0x08 Attack (becomes critical automatically) with HP stealing – never used this before but I
believe you use it either instead of C00001A or after C00001A. Find out for yourself if you’re
really curious.

0x14 through 0x28 - passed to attacker's animation; it is recommended that all possible caster/

spell animation combinations are considered such that no combination conflicts – this
means that using a code with one of these command values is like using a code for the battle
animation user, not for the spell. You’d have to see the 0x85 command list for battle
animations to know what codes C14-C28 would do.

0x29 Set brightness and opacity levels for the background. – opacity refers to the translucency
(the opposite in a way)

Argument XX is the brightness level from 0 to 100% (0x0 through 0x10) – 0x00 = 0, 0x10
= 100%, values in the middle reflect a percent in the middle

Argument YY is the opacity level from 100% to 50% (0x0 through 0x10) – 0x00 = 100%
opacity (can see everything), 0x10=50% opacity (is translucent and you can see halfway
through). As above, values in the middle reflect a percent in the middle.

0x2A Sets whether maps 2 and 3 of the GBA screen should be visible.

Argument YY is the boolean for whether to display those two maps:

 The value 0 means "false to display"; all other values mean "true". – thus
C00002A would stop maps 2 and 3 from being visible, C00YY2A where YY is any value but zero
would mean it shows. This is used to make parts of the screen black.

0x2B through 0x3F - passed to attacker's animation; see note above – see my own note above,
heheh

0x40 Scrolls the screen from being centered on the attacker to being centered on the defender.

This should not be used more than once per animation. – has been used/explained
before

0x41 through 0x47 - passed to attacker's animation; see note above – see my own note above…
again. teehee

0x48 Plays sound or music whose ID corresponds to those documented in Music [Link] of the
Nightmare module packages. - very awesome code, used for almost all sounds. Is pretty much
explained enough already.

Argument XXYY is a 16 bit music ID.

0x49 through 0x52 - passed to attacker's animation; see note above for commands 0x14
through 0x28 – bla bla bla, see above

0x53 through 0xFF - Ignored/unused – derp

Okay, now that I’ve broken down the format of and the possible codes used in spell animations,
we can start adding in some own frames and codes. Here’s the bulk of my script for my next
test:

C000040

C100D29 – Set brightness to 0x10 = 100%, and opacity to 0x0D—given that 100%-50%=50% =
range of opacity change, and 0x10 = 16 values, 50/16=3.125 meaning each increase in 0x01 is
equal to a little bit more than a 3% decrease in opacity. 0x0D =13 x 3.125% = 40.625% opacity
decrease. 100%-40.625%=59.375% opacity level. That’s some math for you. =D

O p- [Link] – this frame load here is just a buffer blank frame load that’s good to have

B p- [Link]

2
C02F948 – this is command 48, loading sound 02F9, which happens to be a swishy sound I’m
testing out (to see if it fits Shaver).

O p- [Link]

B p- [Link] – another frame load but this time I’m loading frame s1, the new background
frame I made. Since I applied an opacity change code it should appear somewhat translucent.

10 – the length is 10 to make sure I can see it clearly, since this is just a test of one frame.

C00001A (after this the rest of the script continues on)

Wooh. Alright, time to save our script and test it. Here goes nothing!

Oops! An error! How do we figure out what went wrong? Well, thankfully we’re early on so we
only have a few frames to check and a few codes to check. Sometimes it’ll say that an image’s
dimensions are wrong, in which case you must of course check that. Other times FEditor Adv
might be a bit more cryptic and say:

Great, I could have told myself that. Thankfully the log can help us a little. We can look at the
last frame it attempted to load and check that frame and the codes around it for any errors.

“…\Shaver (DS)\[Link]”

Okay, [Link]. Wait, that’s the new frame I did! What’s wrong?

After a look at my programs, I realized I never saved my 16color version (yes, this actually
happened to me, haha, and it was a perfect chance to write about it). If it were a code problem
I could have looked at this information:
0x85 command count for this spell: 10

Animation frame count for this spell: 1

To see how many codes and frames were loaded to see how far the program was into the script
before it crashed, and then search that area of the script because the error would HAVE to be
there.

Once the error is fixed, just hit “reset animation” and load the script again. Terminate it, quit
the spell inserter, save, and test. Hopefully the frame works out—if not, try changing the
settings or positioning of things around as needed. Granted it’s just the first REAL test frame so
there shouldn’t be too many quirks.

Once that’s done, you’ve all the knowledge you need to go ahead and start making all the spell
frames you need. If you forget how to do something, just look back—you’ve already learned the
whole process, you’ve just yet to do it. After all, if you can make one frame, you can make a
million of’m.

Oh and here’s my frame as a little farewell present:

It’s true! It did work! It’s still very much a work in progress, as you can see, but the point is we got he
test frame working. The rest just takes time, patience, and the attitude that YOU CAN DO IT!

^That there was my real final present. A spell.

A spell…

Of confidence!

Good luck! And make awesome spells! Ones that will shock the world! I’m done here—this was the final
chapter I wrote! So… goodbye, my friend!

~ Blazer
Chapter 60: Weapon Icons

Ah, weapon icons. For the custom items and weapons you make to ever be complete, you’ll
need custom weapon icons. Even if you don’t have them, you may just want to make the old
icons look better. You may even want to edit some other icons besides weapon icons. In any of
these cases, you’ll need to be able to edit the icon graphics.

Before I get started, I am just going to let you know that while this is called “Weapon Icon
Editing”, not everything you edit is a weapon. It’s just simply easier to refer to them all as
weapon icons than “weapon, item, and miscellaneous icons”. Hopefully you can tell why. ^_^

There are several ways to go about this process but I am only going to teach the best way that I
know: thus if you have learned the TLP method or another method and want to know more
about that, I am not going to help you here, as I have no intention of endorsing completely
inferior (IMO) ways of editing weapon icons.

To start, you’re going to need GBA Graphics Editor, a graphics editing program by Nintenlord
that you have hopefully acquainted yourself with. If you haven’t, you may want to check out
chapter 45, “Working with GBAGE” (GBAGE is the abbreviation for GBA Graphics Editor which I
will henceforth use to refer to the program).

Open the program and your ROM. Immediately switch the graphic type to uncompressed
graphics, as weapon icon graphics in all games are uncompressed graphics. Then proceed to
enter in a graphics offset and palette offset according to which game you are using:

FE6 Weapon Icon Graphics: F9D80

FE6 Weapon Icon Palette: FED80

FE7 Weapon Icon Graphics: C5EA4

FE7 Weapon Icon Palette: CBEA4

FE8 Weapon Icon Graphics: 5926F4

FE8 Weapon Icon Palette: 5996F4

Thanks for the offsets goes to the people who originally found them, whoever they were. They
are much appreciated.

Once you do that (my example is FE7)…

You should see this:

Or something similar dependning on your game. Note that my ROM is hacked and thus I have
some different weapon icons; however, it should generally look quite similar.

If you did, you are successful. Despite the odd format of the icons, you have spotted them, and
that is what is most important, in my honest opinion.

However, to make it look better, you can change the width to 2—and I suggest you do this as it
aligns the weapon icons perfectly. Now you have the height issue—at a width of 2, the height
controls how many weapon icons show up. First of all, it should definitely be an even number.
After that, it’s up to you—you can just have one icon show up by making the height 2, or have a
bulk amount show up (noting that GBAGE has a limit to the height so you can’t make them all
show up at once at width 2). For bulk amounts, I suggest a height of 64. This gives you many
weapon icons in one column and also makes it easy to remember the offsets of the next set.
Look: with these settings,
I have this show up:

Where the bottom icon is the steel axe icon. As you may already know, the icon after the steel
axe is the silver axe. Well, if I just add 0x1000 to my offset of 0xC5EA4, I get 0xC6EA4, which is
the start of the next “set”, starting with Silver Axe. Looky:
Sorry for the really tall images, but I’m trying to make a point here. I personally save each set as
a bitmap using the “Save as bitmap” option, naming the image after the offset I can find it at in
GBAGE. After that, it’s time to edit the image.

However, we have to worry about the palette, which we cannot, or rather, should not, disrupt.
Most importantly you must use the same 16 colors for all the weapon icons, and nothing more
than those colors; and if you wish to replace those colors, edit the palette using a hex editor,
NOT with GBAGE, as it is much safer to use a hex editor. You may be able to edit the image in
MS paint or an equivalent image editing program (hopefully something better) and get away
with it, but I personally suggest googling and downloading the paint-look-alike Usenti if your
computer supports it. It is very good at keeping palettes in tact in the exact order you save the
image as.

You see, when you save the bitmap, the palette comes with it. To prevent not only the colors
but the order from getting mixed up, well, I’m not sure, but I know that if you use Usenti to
copy or edit the image, the palette will rarely ever mess up. Thus when you import the bitmap,
the same 16 colors in the same order will be there and your image’s palette won’t screw up—
and trust me, it’ll be VERY obvious when it screws up. I still screw up sometimes.

Another suggestion is that you save the image as PNG. There are reasons for this but mainly it
makes life easier as PNG is just the easiest image format to work with in my honest opinion,
and it’s easier not to complicate your minds with more knowledge that likely won’t benefit you.

When you DO import the new edited bitmap when you’re done editing the weapon icons, you’ll
want to have it insert to the same offset you ripped at, which is why it’s very useful to note
offsets, or do it like I do and name the image after the offset so you can’t forget it and don’t
have to go looking for your doc on what graphic is where. You’ll want to import the graphics
and check the “abort bla bla bla” but don’t import the palette or anything else, just keep the
palette offset at whatever it was at.

It should look something like that. Because the graphics are uncompressed they should always
take up the same amount of space as they used to, so if you did everything right you should
never run into a space error. Despite this, there IS a limit to the number of actual weapon icons
you can have unless you repoint the data.
You can see after the red musical note that there is a bunch of pixels that doesn’t look like
graphics at all. They are actually other data but the program interprets all hex as a graphical
form in uncompressed mode and so that’s what the data looks like if you tried to view it. My
point is that it’s NOT stuff you can just replace, it’s important data and your game will likely
screw up badly if you mess with it. This is why if you run out of weapon icons to replace, you’ll
need to repoint. For FE7, you may need to apply the Item Icon Bug Fix patch by
Xeld/Hextator/Obviam which can be found with FEditor Adv in this directory: “FEditor
Adv\asm\Fire Emblem 7\Item Icon Bug Fix”. See the IPS patching or JFP patching tutorials on
how to do that. I don’t know about there being any problems with this in FE6 or FE8.

There’s one last thing I want you to know, and it’s about the other icons in there. What icons?
These ones:
Woah how’d I get them to show the right palette? Well, the palette for these should be the one
right after the palette for the weapon/item icons. Thus all you have to do is click up on the
palette index once and you should get it.

Like above, where it says “Palette index”.

With that, you’ve the knowledge to make your complete custom weapons, so congratulations!

And in the case that you need to add more weapon icons, you’ll have to repoint the data—but
there’s a slight glitch with repointing it (at least in FE7, I’m not sure about the other games) so
you may need to apply FEditor Adv’s item-icon bug fix patch, located in the asm folder of
FEditor Adv (it is in multiple patch formats which you can find out how to use in the later
chapters that cover patching formats).

Chapter 61: Map Sprites

Before you get started on learning how to edit map sprites, I suggest you read:

- Chapter 45, Working with GBAGE

- Chapter 60, Weapon Icon Editing

As they prepare you for use with using GBA Graphics Editor and I am not going to explain things
as detailed here as I have done in previous chapters.

First you must find the location of the graphics. You can either:

A) Scroll through GBAGE until you find the map sprites (I suggest using greyscale width 2 as
it will make it much easier to recognize them).

B) Use the offsets from a map sprite module, if one exists for your ROM—I don’t think one
exists for FE6.

In the case of A, open up GBAGE, open your ROM, and scroll through until you find them. They
will be compressed and they will all be bunched together so feel free to skip sections of the
ROM that you know they won’t be in (for example, if you start seeing spell animations, skip past
them, the map sprites won’t be in between spell animations). They are likely in the first half of
the ROM (though I don’t guarantee anything).

In the case of B, you’ll need to open up Nightmare and take the offsets from the map sprite
modules. The standing one is for idle poses, the other one is for moving poses—yes, they are
separate images.

You’ll want the “animation pointer” (which should really be labeled graphics pointer, as the
“another pointer” is really the animation data… heheh). Stick that into GBAGE. If you are using
the other module (for standing sprites), use the “Pointer to graphics”.
Note that the size should change depending on the size of the image. A width of 1 is equal to 8
pixels; thus a width of 2 is equal to 16, and 4 is equal to 32. The height does not matter much as
the data is compressed so GBAGE will only show as much data as there is. I just keep my height
at 32 and set the width to 2 or 4, usually 2, depending on what is needed. This is important in
viewing the image properly.

We now need an appropriate palette. Depending on the game, type in or copy/paste the map
sprite palette to the palette offset slot.

FE6: 0x100968

FE7: 0x194594

FE8: 0x59EE20

After applying the palette the image should look nice. If it isn’t aligned change the width/height
accordingly. If the palette is still messed up double-check you did the right offset.
For different palettes (allegiances, greyed out, and secret ones), press up on the palette index.
You can get various different palettes. For example, this one:

To edit the image or save it to import it elsewhere, use save as bitmap and preferably save it as
a PNG. I suggest using a program like Usenti that will maintain the colors and order of the
palette so that when you re-insert the image, the palette does not screw up (see weapon icon
tutorial for a more length talk about this issue). When you import a bitmap you’ll want to check
the following:
As usual a palette menu will come up, hit okay and it should insert. However, if it does not, this
means the old graphics take up more space than the new ones (and for the record, this may
happen even if the size is the same or the image is less complex, so do not freak out). In this
case you must repoint the graphics by typing in a new graphics offset to free space and
checking “repoint graphics pointers” on the above menu, then reinserting.

That is all there is to it. Good luck! With your custom classes!

Chapter 62: Proper Betatesting

There’s a proper way to do most things in life, and that includes beta testing. You might think
it’s not a big deal—just play the game and look for glitches—but if you want a professional
hack, you need it professionally tested, or the next closest thing, which is what I’m going to
detail in this chapter.

To start, a beta patch may or may not come with a README and other files. If the betatest is
one that is practically meant to be released to the public (has patching instructions, readme,
etc., along with the patch, of course) you’re going to want to make sure that all the files are
clear and it is not confusing as to what is what and how one should go about playing the game.

Once you actually start playing the game, it’s time to analyze everything you can while playing
the game. For example, if there are different modes (normal, hard) you’re going to want to play
both (or at least test it out, maybe use cheats to expedite the betatesting process if you don’t
have time). You want to check out the balance of the game, the graphics, and of course TRY and
cause glitches, because it’s better that a betatester encounters it when they are testing than
when an ordinary person is playing the game.

This chapter is/is going to be (I just know as I’m writing this that it’s going to be) text heavy. But
to make it easier (wall of texts get boring quickly) I’m just going to write 50 things you should
know about betatesting a game, and call it a day.

50 Things to Know About Betatesting

1. Make sure that the download isn’t confusing, nor is extracting files or patching the
game.

2. Watch all the scenes in a game. Don’t even skip the opening, even if the creator of the
patch hasn’t altered it—it might have been accidentally edited.

3. Check for spelling everywhere. If you’re not a good speller, have a spell-checker nearby
for words that you think might be spelled wrong.
4. Check for grammar everywhere. I guess in part to be qualified as a good betatester, you
kind of need good grammar. Simple stuff like “your” and “you’re” is given, but also run-
on sentences and stuff. Of course, if the author intends to use bad grammar in dialog as
a means of one’s personal type of speech, or if the game leans toward bad grammar for
humorous purposes (or some other obscure purpose), you might want to just ignore the
grammar part. But in general, good grammar = good game.

5. Press buttons. Just try pressing random buttons, and see if something odd happens.

6. Check all modes of the game in the main menu to see that they are working properly.

7. In games like Fire Emblem, you may need to check help menus. In Fire Emblem, this is
done by pressing “R”, and may also give character or class descriptions, which hackers
often forget to change.

8. Listen to all the songs in the sound room (if there is one).

9. If you hear a song play in game, make sure it also appears in the sound room (applicable
only to some games).

10. When you hear a song in game and it’s custom, have it loop at least once if possible, not
only to make sure it loops, but to make sure that the whole song plays without any
problems. Songs from the original game are less likely to be glitchy (and if they are,
they’ll probably be obvious).

11. On games with maps (like Fire Emblem, of course) check all the tiles on the map.
Sometimes tiles may act funny (you may move onto non-existant tiles, or tiles may
appear crossable but not be, or something else weird).

12. In dialog, make sure that there are pauses in between to let the player read the text.
This may mean having to press a button to continue, or just having text go slowly.

13. Always look for weird pixels or graphics that might show up somewhere.

14. If you do encounter a problem, take screenshots and videos to show where it is.

15. If a problem occurs, it is very helpful to take a savestate (shift+F1-F10, then press the
‘F#’ button to reload a savestate slot) and then give that savestate to the author of the
hack so s/he can access the glitch without having to play through the game.

16. Use all characters in the game at least once.

17. Keep animations on to ensure that you see that battle sprite are working and are
colored properly, amongst other things.

18. Look at stats to make sure that they aren’t working weird either (crazy high stats, stats
that change on their own, “--“ stats, etc…).

19. Also test animations off to make sure map sprites are working right.

20. Listen to sounds—make sure the right sound effects are being played at the right time.

21. Look for balance in enemy numbers and your numbers. In a game like Fire Emblem, you
typically don’t want 20 allied units and only 10 enemy units.

22. Look for balance in unit strength. One of your units shouldn’t be so broken that they can
solo an entire chapter (barring the first few chapters, where there are usually only a few
units on the entire map…). Similarly, the enemies shouldn’t be so hard that they’re
better than your own units, or so weak that they have a 30% chance of doing only 2
damage, or something as ridiculous as that.

23. Analyze the map. Boring maps with a simple path to the area one is trying to go to are
boring and should be edited. The terrain should be as diverse as possible while still
adhering to the plot (if the characters are in a desert region, there’s typically not going
to be a lot of grass or trees or civilization, of course…).

24. Pay attention to consistency in the plot. This includes names, characteristics, and plot
details in general.

25. Visit all villages and other places on a map you can possibly go to. This includes looking
for secret shops.

26. Analyze the plot to see which characters can be recruited or perhaps check for character
relations. Also check for gaiden/secret chapters and how they might be reached.

27. Think to yourself “if I weren’t a very smart person”, and question how confusing the plot
may or may not be? Is there something that doesn’t make sense, or perhaps a character
doesn’t get enough time to develop themselves?

28. Check for repetitiveness. If every enemy has the same inventory, or only 1 or 2 classes
are used for all the enemies on a map, or the same reinforcements constantly come,
players won’t feel very excited to play on the map. These things may detract from the
enjoyability of the game.
29. Always try both paths. Try killing off units to check their death quotes, or losing to get
game overs. It’s possible someone forgot to code in a game over event!

30. Look for suspicious areas on the map. Sometimes there may be hidden secrets on tiles
you don’t expect.

31. Check enemy inventories to see if there are any weapons that they have, but can’t be
used, as well as droppable items. It’s possible a hacker meant to make an item
droppable but didn’t, so question it, even if it’s meant to be stolen by a thief.

32. Question things that might be right, because they might be wrong. If some unit has
lethality as a skill, it might have just been a test. A weapon might accidentally have 100
critical because the player was testing a critical!

33. If there are custom animations, test all different aspects of the animation. This includes
dodge, magic swords (if applicable), close and far range, etc.; and the same thing applies
to custom spell animations.

34. Check to see if something is missing in a game. If one of the characters mentions that
“the enemy has ballista” but you don’t see ballista on the map, the hacker likely forgot
it, and it’s your job as a betatester to let them know.

35. Expanding on the “multiple path” idea, use savestates to test out possible split choices.
A chapter may have two ways to beat it—try both. You may be given a choice to do X or
X. Use a savestate, try one, go back , and try the other. Do this every chance you get to
make sure things turn out right.

36. Custom cutscenes are often full of problems. For instance, the camera may not follow a
person, or may jump around if multiple people are loaded. It might even glitch up
sometimes while not glitch other times. One thing is that cutscenes sometimes glitch up
if you watch the scene, get to the battle preparations, save, and then restart the
chapter, so try it out to see if there’s some major problem.

37. If a certain weapon is broken, suggest to the author that they tone it down.

38. Make sure PRF weapons are actually limited to a certain character (or maybe class) and
aren’t apocryphal.

39. Check to see that custom classes behave as they should—for example, a class on horse
will need the “move again” ability, and will need the “knight” icon. A custom flying unit
will need the movement ability to flow over mountains.
40. Always look for unedited text and other aspects of the game that should probably be
edited. This is tricky because it’s not a glitch or a bug as much as it is something the
author simply didn’t do. Sometimes character/class/item descriptions, death quotes,
battle quotes, or even certain dialog may have been forgotten to be edited. Someone
may have left a support of two characters who aren’t supposed to support anymore, or
have left an enemy with a weapon that has been edited to be a customized weapon
enemies aren’t supposed to have.

41. Try all the different menus in the game. For example, a hacker may have edited a
background somewhere, and that same background may be shared in the ‘Options’
menu, but they may have forgotten to edit the palette (coloring) of the background, and
so it may look weird. If you don’t check that menu, you won’t know!

42. The game shouldn’t be too difficult or too easy in most cases (unless that is the purpose
of the hack). Take into thought that you may be a better player at a game than most
other people, and so the game might be too difficult for the average person.

43. Actually test a little bit of hard mode to make sure that it’s working right not just in
theory, but in actuality and that hard mode itself isn’t harder or easier than the hacker
may have intended. In this case it’s best to just comment on the difficulty level in
general rather than say whether it is too high or low.

44. Check for weird occurrences when you suspend and resume the game. For instance,
there was this one glitch where certain stats would increase if the game was suspended
and resumed (I won’t get into it, but the point is, check).

45. Check for portrait colors (consistency and general appearance). Portraits shouldn’t be a
mixture of FE7 and FE8 colors if it can be avoided. Also, really bright colors can hurt the
eyes, so make sure the hacker doesn’t give reason for anyone to be blinded.

46. Don’t forget to promote all the units you can too! Savestates are quite useful here. One
promotion item can be used to promote units of all classes. You may need to abuse
arenas to level units up to level 10, play the game multiple times, or hack the game to
help with this, but it’s necessary, because it’s possible the author forgot to do every
single promoted battle palette.

47. When you are actually betatesting, write down everything nice and neat, in bullet or
numbered form, in a word or notepad file or something. Do it WHILE you are playing the
game, not after—because you’ll probably miss something if you just keep it in your
head.
 48. While writing your report, be detailed and include specifications as to where things are
and when they might occur. As said before, use screenshots, videos, and savestates as
necessary. It might be helpful to organize your comments into different categories, like
“Text”, “Forgotten Things”, and “Glitches”, because it helps them tackle down all the
problems in one category at a time. It also helps because “glitches” are usually a priority
of beta-fixing.

49. Don’t be too harsh or bias with your betatesting. You don’t want to anger the hacker
and make them not want to fix something, or give your opinion on something they don’t
care about, like “this portrait looks really ugly, whoever made it sucks at spriting”, or
“the plot is really bland, it needs a complete overhaul…”.

50. Enjoy your time betatesting, because if you don’t play normally, it’ll be more of a job
than it is a special privilege!

Chapter 63: VBA’s Tools

I’m going to (relatively quickly) cover the various tools in VBA’s “Tools” dropdown menu.

Disassemble: this lets you disassemble ARM or THUMB assembly. If you don’t know ASM, it
won’t prove very useful to you. If you do, it can prove very useful.

Logging: I’m no expert on this, but to my knowledge, logging lets you keep track of various
functions and operations whose purposes I do not know.

I/O Viewer: This viewer enables you to view the input/output area of the RAM and even edit
the values here to some extent, in real time.

Map Viewer: The map viewer is one of the more useful tools for average hackers that lets you
see backgrounds, as well as information such as their size and # of colors. FYI, “stretch to fit”
stretches the background in the viewing window so that it fits the window, and “auto update”
makes it so that the background is automatically updated as it changes in-game. (The latter
applies to other viewers as well). On the bottom left you can select a square/color (which is
selected by clicking on a place in the window) and see it’s RGB.

Memory Viewer: The memory viewer lets you view the game’s RAM (memory) in real time (if
you click “automatic update”) and save it as a memory dump (which you can load later) or edit
it (although the game might change it by itself right back anyway, depending on what you’re
editing). To edit, just click on a byte and type in the new value. Type in an offset in the “Go” box
to go to a specific offset.
OAM Viewer: Essentially the same thing as the map viewer, this lets you view sprites, which are
essentially smaller “object” graphics that are on top of the backgrounds.

Palette Viewer: The palette viewer is one of the most useful tools in VBA as it lets you find a
palette and view any of the colors in the palette. It gives you the RGB and hex value and can let
you save either the background (BG) or sprite (OBJ) part of the palette viewer as a .PAL file. It’s
very useful for finding palettes in a hex editor as one can search the values of colors to find and
edit them.

Tile Viewer: This last viewer lets you view graphics as 16bpp or 256bpp (depending on which it’s
meant for—likely the former) as well as scroll through a selection of palettes (as different
palettes fit with different tiles in the viewing window). Its other functions are much like the
Map Viewer’s own functions.

Well, there’s nothing else of major interest I want to talk about in this dropdown just yet. There
is the ability to record videos and sound, but that is for a future chapter. ^_^

Chapter 64: Other VBA Options

In this chapter I’m going to detail some of VBA’s semi-obscure but not totally obscure options.
Knowing how to use VBA will help you test your game in various ways.

The file menu has many options, most of which you should be familiar with. Pause obviously
pauses the game (and also unpauses it) and ‘reset’ restarts the came (but doesn’t reload the
cartridge, meaning if you hack the ROM and hit ‘reset’ in VBA, IIRC the changes won’t show up).

The Recent tab lets you load a recently played ROM. “Import” lets you import gameshark code
files, battery saves (the “main” saves), and gameshark snapshots. Battery files and gameshark
snapshots can be exported with the export tab, of course.

“Screen capture” takes a PNG screenshot and saves it to your computer, which is very useful.

“Rom information” gives very basic information of the ROM based off of the header and some
other crap, and “close” simply closes the ROM without loading another one or exiting the
program.

Now the more interesting and less basic stuff is in the “Options” menu at the top. There are a
bunch of categories/tabs with lots of options, some with even more tabs. I’ll go through
whatever I know well enough to teach. Haha.
“Frame skip” lets you skip frames, like you’d imagine. Lowering the frame rate makes each
frame play—making it higher skips a lot of frames, which will make everything seem kinda
laggy. Just try ‘9’ and try moving your cursor on a map in Fire Emblem, for example, and you
should notice the difference. “Automatic” sets the frame skip to whatever VBA thinks is best.

Throttling forces the game to go at a certain speed (or close to said speed). Thus you can speed
the game or slow the game down (of course, you can always speed the game up to max speed
by pressing the spacebar too). 100% is normal speed, 25% is 1/4th said speed, and 200% is twice
as fast as normal. You can also set your own emulation speed via the “Other…” (just enter a
number in the dialog box).

The “video” tab affects the graphics display. There are a bunch of rendering options that I don’t
care about, an ‘x1, x2’ etc. with zoom options (you can force the screen to be twice its normal
size all the time, or just manually drag the screen yourself if you want), and most importantly,
you can set which layers are on/off, which is useful for more advanced graphical hacking to see
which graphical aspects are on the same graphic layer, as well as ripping graphics (because you
turn the layers you don’t want to rip off).

The “emulator” tab has a lot of stuff that I don’t care about, even if I know what it does. The
most relevant things to hacking are the automatic IPS feature (just keep it checked—all it does
is have IPS patches with the same name as the ROM automatically be soft patched when you
play the ROM-will cover in detail in the IPS patch chapter), and the PNG/BMP format which is
for taking screenshots, which should be checked to PNG, of course, because BMP’s take up a
ton of space.

In the sound menu you can turn sound off (which speeds up the game because it doesn’t have
to load sound), mute it (which doesn’t speed up the game), or just have it on (…). The various
channels (which should all be checked) control which… ‘layers’ (not terminologically savy) of
sound are playing. So if you turn some channels off, you won’t hear certain music/sound. You
can also edit the sound… type (again, terms = fail), with the 11khz, 22khz, etc., and adjust the
emulator’s volume (not sure why you’d do that with the computer’s own volume changer
though… lol).

The gameboy category doesn’t have anything I want to talk about. The end. Neither does
priority.

So next is filtering, which is used for when your emulator is zoomed in. Filters edit the way
zoomed in pixels are “interpreted” and displayed. You can make the game look like fine lines,
smoothen things out, add motion blur, whatever, but the window has to be more than 1x
zoomed in. Try out the filters yourself and see what you like. Here’s an example:
(This one is kinda smoothier than normal, if you can tell).

Joypad and Language also don’t have any interesting (to me) features, so I’m not gonna go over
those… which means that, we’re done!

Chapter 65: Recording Videos & Sound

VisualBoyAdvance has two great features that separate it even more from most emulators. It
can record both video and sound (even though video has a desync problem which will be
covered in the next chapter). You can find these amazing features near the bottom of the
“Tools” menu in VBA.

If you go to the ‘record’ tab and hit ‘start sound recording’, you’ll be prompted to type in the
name for a .WAV file, which is an uncompressed file with recorded sound that can be played by
a program like Windows Media Player. They tend to be big though, so watch out.

When you’re done recording the sound, you go back to the ‘record’ tab and hit ‘stop sound
recording’, and then enjoy your file. Bam.

In a similar manner, one can record an AVI file, which is an uncompressed video file. Like the
WAV, it tends to be huge, except that since it’s video and contains graphics, it will be even
larger than you might imagine. Depending on how long the video is, it can definitely get over
100MB as an AVI. No worries, though, I’ll cover how to save space and make uploading such a
huge file quicker in the next chapter.

The only difference between this and sound is that you have to select a basic video
compression.
“Full Frames (Uncompressed)” is completely uncompressed. All the other options will compress
the files, but with different features and quality. So I kinda lied about AVI’s not being
compressed, it’s just that they aren’t compressed nearly as well as MP4’s… XP.

I typically use “Microsoft Video 1” as it doesn’t really change the quality of the video but gets
the job done, and it shouldn’t lag like “Full Frames” does (that records every single frame—it’ll
be huge and unless your computer is super uber, it’ll be slow). Other codecs may also be
installed into the system due to installation of other programs (or you’re just an extremely
competent video renderer), but those aren’t necessary or anything.

Finally, you can record a “movie”, which is not for sharing with others. A movie is a clip of the
game that you can play (using the play tab) which shows you part of the game that you played.
If you ever use the movie feature, savestate before, then do it.

As you can see, none of that is really any hard or anything, which is why it’s more convenient
(and results in better quality!) to use VBA to record stuff from your hack than it is an external
program!

Chapter 66: Fixing the Desync with VirtualDubMod & Video Rendering

In the last chapter, I mentioned a desync… an audio desync, to be exact. The video frame rate
and audio frame rate don’t match up. As a result, the audio starts to lag behind, and after a
couple of minutes, when the audio and video don’t match up, it can get really bad.

This is solved by a program called VirtualDubMod. The program and the method to fix the
desync were introduced to me by Shadow of Chaos, who was introduced to it by some youtube
video, IIRC.

Download and install virtual dub mod (I won’t tell you how though, it’s just installing a program.
>_>). Load it up and hit Ctrl+O (or file->open video file) and load the AVI that VBA produced.
Now, since I’m really nice, I created a file that loads settings that automatically fix the frame
rate issue and set the program to quickly but efficiently recompress the AVI. You can download
it below.

[Link]

Hit ctrl+L or file-> load processing settings and load the file I just linked to above (make sure you
do that AFTER the video is loaded, though). Then hit “save as” under the file menu and save the
AVI again. It’ll take a little bit to render, but once it’s done, you may be done for good, as the
file may be small enough that you can just upload it as it is and be happy.

If you aren’t happy, you can try recompressing it, while also making it youtube friendly, with a
program called Free Zune Converter (yes it’s free). Download that and extract it or whatever
and when you open it, you should see this:

Those are the settings I have, which youtube doesn’t complain about. You can change the
resolution which will affect the various quality settings youtube and possibly other sites offer.
1280x720 is for 720p [HD], 1920x1080 is for 1080p [HD], and the one I have hightlighted,
640x480, is for HQ (480p). Granted, if you save it as an HD file, the game will not only be
stretched and kinda appear as awesome HD (GBA was never meant for HD resolution though
XD), but the file will be large, so keep that in mind.

You can mess with some of the other settings if you want, but once I pick the resolution and the
output format (which is always the same for me), I’m done, which means I just drag my videos
onto the program and hit “convert”, and it’ll create a new MP4 file from the AVI file I got from
VirtualDubMod which I got from VBA.

All of this may seem like a long process, but it’s necessary for an awesome video, and once you
learn how to do it, the actual work isn’t long—you just have to wait for the videos to render,
and everything else pretty much takes 5 minutes.

But yes, that’s the basics of rendering videos. With that, there’s no excuse for crappy youtube
videos of hacks (unless the hacks are crappy, but that’s what the REST of this tutorial is for!).

Chapter 67: IPS Patching & General Patching Information

Ah, IPS patching, one of the oldest types of patching. What is patching? Why, it’s applying a
patch—like you know, a fix or an update—to something. In the case of ROM Hacking, it means
applying the edited parts of a hack to an un-hacked ROM.

Why do we do this when we can just share ROMs? Well, sharing ROMs is mostly taboo on the
internet, at least on most forums. However, by sharing only the changes, which is what sharing
a patch is, you kind of avoid being attacked by this taboo. Furthermore, patches only include
the changes… I know I just said this, but the point is that they are MUCH smaller files than
entire ROMs, which includes everything. Thus it’s easier to share patches (though now as
technology advances, patches are becoming a little more obsolete in that you can download
larger files super-fast, and space is rarely an issue).

There are two things you can do with most patchers: apply a patch and create a patch. I am
going to mostly teach these things. I am NOT going to cover how patchers work, I am only going
to explain the practical use of patchers.

Back to IPS patching—this is the most basic patch format. IPS patches cannot add data to the
ROM. They can only change the values at already existent places. Thus let’s say you’re hacking
FE7 which is 16MB. If your edited ROM is 18MB, you can’t use IPS patching because it won’t
support it as the files aren’t the same size.

The best IPS patcher I know of is Lunar IPS, AKA LIPS, so google that and download it and
extract it, then open it up.
“Create a Log File” really isn’t necessary. “About LIPS” is pretty self-explanatory. So let’s do
“Create IPS Patch”.

You’ll want to navigate to the folder where your original, unedited ROM is. I made things easy
on myself and put the clean ROM next to the Edited ROM so that I don’t have to go searching
very far.

Double-click/open the unedited ROM. For me that’s “Fire [Link]” (named so because it’s
the original copy of FE7). Then it’ll ask you to select the new modified file, so do so:
And then you type in a name for your patch that it will create.

Hit save and it should tell you you were successful. Wala, you’ve just made an IPS patch. Now let’s apply
it.

Hit “Apply IPS Patch” in the “main menu”. This time, you select your IPS patch you just made (hint: it
ends in .ips) followed by a clean, unedited ROM (hint: it’s not the hack). It should say “The file was
successfully patched”, in which case you have successfully learned how to deal with IPS patching.
Chapter 68: UPS Patching

I suggest you read the IPS patching tutorial (at least the beginning) if you haven’t done so as I
will not be as thorough with this chapter as I was the previous.

UPS patching was revolutionary as it allowed patches between two differently sized files. The
UPS patch would simply have all the extra data attached to it. It’s better in other ways too but I
won’t get into that.

The best UPS patcher, the one I want you to download, is called NUPS. However, if you search
that on google, you actually probably won’t be too successful in finding it. Thus I suggest
searching “Nintenlord’s UPS Patcher” and go through some forums and you should find a
download. You’ll need the latest version of .NET Framework or the Mono equivalent if you
aren’t running Windows (see google to find these) for this to work as it is one of Nintenlord’s
programs and all of his programs have this requirement as far as I know.

Extract the files, open it up and you should see this:

Shiny. “Exit” is self-explanatory. The rest isn’t as much. Let’s create a new UPS patch.

Here you have a nice menu. You hit “Browse…” and select the file you want, which is labeled on the left.
Thus the first entry should be the unedited, original, clean ROM. The second entry should be the hacked
ROM. The 3rd entry should be the UPS file you are going to create—just name it something and save it
somewhere you’ll find it. Once you’re done, hit “create patch” and NUPS should create a patch with the
differences, then take you back to the main menu.

In an extremely similar manner you can apply patches. Take a look.

The file to patch is the clean ROM you want to patch. The UPS patch is any UPS patch—for testing
purposes use the one you just made.

Where it says “create backup of the file”, this is in case you aren’t sure if the UPS patching will work. It
will make a back-up that you can go back to if the patch screws up your ROM. Pretty useful.

Another safety check is the “If file is invalid”. If a patch is applied to a file that wasn’t the same file the
patch was based off of—i.e. the clean ROM—then NUPS will take an action depending on what you have
selected. It will either abort it and not patch it, ask if you want it patched, notify you that the files don’t
match (meaning your ROM isn’t clean/unedited), or ignore it as a whole and patch anyway as if though
nothing odd happened. Take your choice and hit “patch” to apply the patch.

Lastly, we have a brand new feature not seen in IPS patching: “Get patch data”. What you do here is
browse for a UPS file and hit “Check” and NUPS will tell you the offset of any data that was changed and
the length of bytes changed at that offset.
Like so, where the offset tells where and the length (misspelled as “lenghts”) tells how long. You might
think “this is so pointless” or something like that, but it’s actually useful for more advanced hackers. It
tells you what data was changed, and where—you can use this to track what data was changed in small
fix patches or ASM patches. If by some chance you don’t want part of a patch’s data, you could use this
to help you find out where the part you don’t want is, and revert it back to normal, or vice-versa if you
only want a specific part. There are many other uses for this feature but they are rather specific so I
won’t get into them, but this feature has definitely saved me in a few instances by helping me solve my
own bugs/glitches. Thus I’d keep it in mind for the future.

And with that, you can now use all of NUPS features!

Chapter 69: JFP Patching

WARNING: This chapter will not be as detailed as the others/assume you know little to nothing.
Rather, it assumes you are familiar with the basics of patching. If you are new to patching as a
whole, I suggest learning IPS and UPS patching first.

First of all, JFP patching was invented by Hextator as a better patch format than UPS. It has its
advantages but I can’t think of them all now—I’m pretty sure that it uses a better format for
checksums, is more compatible with FEditor Adv, and allows you to save the patched file
separately from the unpatched file.

Second of all, you need the latest version of Java for this to work, so get that installed if you
don’t have it already (chances are if Xeld’s other programs are working, you have it). Then
extract the files (you’ll need WinRAR or 7zip probably, the archive will probably be a .7z) and go
into the “Java Implementation” folder. Double-click on the “Drive” batch file which will load up
a command prompt and then ask you:

“Are you creating a patch instead of applying one?”

Hit “yes” to create a patch, where you select the original file, edited file, and the path for the
.jfp patch, in that order. Hit “no” to apply a patch, where you select the JFP patch, a clean ROM,
and a path to save the new patched ROM (it does not apply the patch to the original file, but
saves it as a separate file).

…And that’s all I have to say about that. It’s relatively easy and not complex even if it doesn’t
have the greatest GUI. At least now you can deal with JFP patches without freaking out, right?

Chapter 70: XDelta Patching

This type of patching is unique in that it results in very small files and can be used for NDS
hacking, though the latter is irrelevant for this tutorial.

There are two methods I will teach here: one with GUI, one without GUI. The one with GUI is
nice and all, but the one without GUI is easier for the “final user”, the person who will
ultimately play the patch, as it results in a simple drag-and-drop patching method. And what’s
easier than a drag-and-drop patch? Not much. The downside is that non-Windows users won’t
find Delta Patching very fun or easy.

First Method: Formal Program with GUI

First, download this:

[Link]

The download link is at the bottom.

Extract the files as usual. There are two programs here: DeltaPatcher and DeltaPatcher Lite. The
difference is that the DeltaPatcher Lite can only apply patches. Thus it was intended to be
included with the patch download so that people could apply patches without having to worry
about the feature of creating one. To be honest, both are pretty easy to use, and if you can use
the main one, you can use the Lite one, so I’m just going to teach the main one.
Boom, I explained most everything there. When you’re ready to apply the patch, hit “apply
patch” (duh) and you’re all done.

To create a patch, you need to hit “Create xdelta patch”, which will change the top left area a
little bit.
If you’ve been following the other patching tutorials this is all a complete, obvious piece of
cake, except the compression level dropdown, which I explained above. Just hit “create patch”
and you’re all done, and that’s method one. (Teehee, I rhymed)

Second Method: Batch File Editing, without GUI

This is not for the weak-hearted. The main purpose of this patch format is to make it so that the
people who patch files only have to drag and drop the file to patch it.

Download this version of XDelta from my site:

[Link]

Extract it and you should see 3 files: Patch Creator, Patch Applyer, and xdelta itself. To start,
never rename “xdelta” to anything else. Ever. Just don’t do it and you’ll be safe. I realize that
people who know how this works can get away with renaming it to something else, but if you’re
reading this tutorial you shouldn’t know how this works, or else you shouldn’t be reading this
tutorial. :P

The other 2 files are batch files. Scary? Not really. You can edit them in any old text editor. I just
right-click it and edit it with Notepad++, you can do something similar with Textpad or plain old
Notepad or something. But don’t try Microsoft Word or Wordpad, those programs probably
won’t work. You want something simple.

First, open the patch creator. Boom.

The black line points to the name of the original, clean, unedited file/ROM. In this case it’s
“[Link]”, change it to whatever you want though, like “[Link]” or something. The
green line points to the name of the patch file. This can be whatever you want, under any
extension. To make life simple, keep everything lowercase and without spaces. If you didn’t
already notice, the “.blz” extension is for “blazer” as I used this patch creator for my own
patches. Heheh. =P

Once you’re done renaming that stuff, you need to actually put the unedited ROM there. So in
my case I’d put “[Link]” in the folder. To make the patch, you simply drag the
edited/hacked ROM onto the patch creator file, and a file called “[Link]”, or whatever the
heck you named it, will pop out.

Now, how do we use this patch? We use the patch applier. To setup the patch applier, edit it
like you did the patch creator.
I realize this can be pretty intimidating at first but you really don’t have to do anything but
change the “[Link]” to whatever you named your patch to. Remember, it has to match
what’s in the file!

Save it and close it. Test your patcher by dragging a clean ROM onto “Patch Applyer” (which I
now realize should be spelled “Patch Applier”). A new ROM called “[Link]” should
appear, where the “bla’s” are the name of the file and the extension of the file respectively. The
point is, it’ll end in ‘-patched’, so you can’t not know which file is patched and which isn’t.
Unless you’re dumb. But if you’re reading this I’d like to think you’re not dumb.

That’s that, for the most part. But let’s imagine we’re some internet guys just playing a hack for
fun. We don’t need the patch creator, just xdelta, the patch applier, and the patch itself. Thus if
you want to share a patch with someone easily, just include the patch applier, xdelta, and the
xdelta patch file you made. The player just has to get a clean ROM and drag it onto the patch
applier file and they’re done patching. It LITERALLY takes 1 second to drop it, maybe 3 seconds
to make the patch if they’re unlucky, and maybe 6 seconds to find the ROM and get it to the
right folder if they’re having a bad day. And if they can’t do that 10 second process successfully
then they PROBABLY aren’t meant to play the hack.
And I can’t write a tutorial on THAT.

Chapter 71: Nightmare Module Format

At some point in your hacking career it may have occurred to you, or may occur to you, that
there has to be some format to nightmare modules, given all the people that have made them,
myself included. The truth is, there is, and making Nightmare Modules is actually pretty easy. In
fact, that’s why they were used in the first place—Nightmare modules along with the
Nightmare program serve to make editing tables and arrays very, very easy. It divides a huge
amount of data into different entries and allows you to edit any of those entries and its
contents easily, helping by making the format of those entries match the data type, and
labeling what each entry is.

That may all sound confusing but as we go through the nightmare format, you should find that
it’s actually relatively basic. To start, I’m going to post the nightmare format documentation
included with the original Nightmare download.

NIGHTMARE MODULE FORMAT

-----------------------

Blank lines are ignored, so you can use them to divide stuff up and make it

more readable.

Lines beginning with # are comments.

Numbers are assumed to be decimal; to indicate hex, include a "0x" prefix.

You can even indicate octal with a "0" prefix, if you're so inclined. :D

All numeric values can be decimal or hex interchangably, with the exception

of table files - the values there are assumed to be hex. (This allows

copying and pasting from existing table files.)

THE MODULE FORMAT

-----------------

The first line holds the module file version. For this file, that's "1".

No decimal points or anything fancy.

The second line is the module description, which appears on the title

bar when the module is loaded.

The third line is the root address of the data table.

The fourth line is the number of table entries.

The fifth line is the length of a single entry.

The sixth line is a filename, indicating a list of names to be used by

the entry selector. If "NULL", the entry selector will only use

numbers. If names run out before numbers do, the selector will continue

with just numbers.

The seventh line is also a filename, indicating the table file to be used

by TEXT entries. Tables here can only be letter-matching, that is, of

the form XX=Y; multiple bytes or multiple characters, such as XXYY=Z,

or XX=yz, are not permitted. If "NULL", standard ASCII is assumed.

Here follow entry-component handlers, until the end of the file.

It is recommended (for reasons of readability by humans) that a newline

be placed here, and also after each entry-component handler.

ENTRY-COMPONENT HANDLER FORMAT

------------------------------

The first line contains a textual description.

The second line contains the offset from the start of the entry.

The third line contains the number of bytes used by the component.

The fourth line indicates type, which is one of the following:

TEXT - Text editbox

HEXA - Hex array (useful for indicating and changing unknowns)

NEHU - Numeric editbox, hex unsigned

NEDS - Numeric editbox, decimal signed

NEDU - Numeric editbox, decimal unsigned

NDHU - Numeric dropbox, hex unsigned

NDDU - Numeric dropbox, decimal unsigned

Binary toggles should use NEHU with something like "(binary)" in their

description, and an explanation in comments within the module file.

Types are not case-sensitive.

The fifth line is the parameter file, a name list for dropboxes. It

follows this format:

 <number of entries to follow>

<numeric value> <written description>

<numeric value> <written description>

...

<numeric value> <written description>

The numeric value is displayed in the context specified by Type

(hex or decimal, for example). This value is what is written to the

rom when a dropbox entry is selected and Save is used. This parameter

is unused ("NULL") for editboxes.

That information should be referenced frequently as I don’t want to have to constantly

reiterate myself about understood things, such as “#” denoting a comment.

For me, the easiest way to make a Nightmare module is to just copy someone else’s. After all,
it’s so much easier to just steal the format than to make it from scratch. Thus it’s relatively
harmless to use it as a basis for your own nightmare module (granted if you use the same
offsets and stuff or you’re just making an update then you should give/leave credit to the
original maker). I am going to use the FE7 Item Editor for my explanation of the format.

1 – Always 1

FE7 Item Editor by SpyroDi, updated by Nintenlord – the name. a super long name might not fit.

0xBE222c – the starting offset of the data. I can’t help you with finding this. When you find an
array of data and you want to make a nightmare module for it, you’ll know the offset then.

159 – the number of entries, in decimal.

36 – the number of bytes in each entry, in decimal. Note that the starting point of the last entry
+ its length should be this number.
FE7 Item [Link] – the filename of a list of names to use for each entry. It must be a text file
in the same folder, and each name should have its own line.

NULL – don’t worry about it

After the header, we start breaking apart the data into different entries, like so:

Item Name Pointer – the name of the entry. Should identify what it is

0 – the starting point of that data entry, always starts at 0.

2 – the length of that entry, in bytes, in decimal.

NEHU – the type of data it is.

NULL – a dropdown list for dropdown data types, including the number of values, followed by
the values themselves, with the label for the value accompanying every value. You’ll see for
yourself in a minute.

Item Description Pointer – name redux

2 – starting point. Note that the last entry started at 0 and was 2 bytes, and 0+2=2.

2 - length

NEHU - type

NULL - text – NULL means that no dropdown list is used.

The file continues like this all the way to the bottom. And that’s all there is in broad sight.
However, I’ve yet to cover the different data types. The nightmare format tells what each is but
you may not understand that, so I will just use a few more words to make it more clear:

TEXT - Text editbox – allows for there to be a text parameter, meaning an ASCII text string.
Let’s say a certain 8 bytes is not like a statistic but an actual string of text, you’d use this to
make it so that Nightmare will let you edit the text as text and not numbers.

HEXA - Hex array (useful for indicating and changing unknowns) – this lists the values out as
individual bytes. Like its description says, its mainly useful if you have a bunch of unknown
values that you want to compare between entries.
 NEHU - Numeric editbox, hex unsigned – a standard old edit box where you can type in the
numeric value you want. Hex means hexadecimal, you know the counting system we’ve been
using since forever in hacking, and unsigned means that the values aren’t signed, meaning… oh,
I guess I should teach that. If a value is signed, it means that it can change sign—any value after
127, which is equal to 0x7F, becomes negative. That’s right, you can have negative values.
That’s how things like negative growths come about. You can never have signed hex values
though, hex values just aren’t negative, ever—the whole point of the signed/unsigned system is
to make it so that hex values come out as signed in the decimal system.

NEDS - Numeric editbox, decimal signed – see above, a standard edit box where the value is in
decimal and is signed (can be negative)

NEDU - Numeric editbox, decimal unsigned - a standard edit box where the value is in decimal
and is unsigned (cannot be negative)

NDHU - Numeric dropbox, hex unsigned – a dropbox entry, see NEHU for info about “hex
unsigned”

NDDU - Numeric dropbox, decimal unsigned – a dropbox entry, the values are in decimal and
aren’t signed

Here are a few examples:

Weapon Ability 1 - name

8 – offset from start of entry (8)

1 – length of 1 byte

NDHU – type, Numeric Dropbox Hex Unsigned, meaning it’s a dropbox where the values are in
hexadecimal and unsigned

Weapon Ability [Link] – the list of values possible to use, if it were NEHU instead of NDHU this
would have to be NULL since “NEHU” doesn’t use lists, the “E” being for “editbox” and all,
whereas the “D” in “NDHU” is for dropbox and all. And all. :D

Here’s an excerpt from a list:

256

0x00 None

0x01 Weapon
0x02 Magic

0x03

0x04 Staff

As you can see, the top number is the number of entries, followed by a new line with the hex
and the name. If there is no label it still works fine though.

Just remember the following:

- You can’t have an entry be outside the length of the nightmare module that is specified
in the header

- The difference between decimal, hexadecimal, signed, and unsigned

- Test small nightmare modules first and then build on them, or you may find yourself
with so many errors that you don’t know where they come from

- Nightmare modules are meant for simplifying tables. Not every little thing needs a
nightmare module! (Despite the fact that I made many small and near-pointless
nightmare modules, haha, I only did that to make it easy on people who don’t like hex
editors…)

- There’s this tutorial to help you at all times, so you can do it!

You’re on your way to helping the community, starting small, but that’s how every normal
person starts. This is the final chapter dedicated to a specific teaching purpose; the rest are
very general or aren’t meant to teach anything about hacking. This means that you have
now completed learning most everything there is to being an awesome Fire Emblem hacker,
and now you can start contributing to the hacking scene yourself in every way possible!

Chapter 72: Miscellaneous Information Archive

This chapter is an archive of sorts for information. It will include documentation, links to help,
instructions, anything I can think of that might not fit in a specific chapter. Thus it may get
longer and longer through time, or it may stay short. I encourage people to submit knowledge
to this section that may not fit into any other category or may fit into too many categories.

Miscellaneous Notes, Tips, etc.

- First of all, check out this thread dedicated to obscure hacking tips, as it has a lot of
random but useful information that you may just need to utilize at some point!
[Link]
 - There’s some interesting ASM hacks that can be found in the FEditor Adv folder, as well
as documentation for much of the program within the doc folder.

- You can find source for most programs, hacks, etc. regarding Fire Emblem, so just look
around. Very useful if you ever plan to fully maximize the potential of what’s around you
or learn how various codes etc. work just by looking at existing codes.

- Playing around, guess and check, etc. are great ways to learn!

- Back-ups, back-ups, back-ups. You always want to back-up, and keep notes of important
things you do, important offsets, etc., to make the process as easy for you as possible,
and to limit how much you have to go back and change if by some chance you mess
something up.

Battle Animations

- Did you know you can load a spell animation even for physical units? In fact, the final
boss of my hack, The Last Promise, attacks with both a physical weapon and a spell
simultaneously, which makes for an epic duo effect (at least in my opinion).

- You can actually dump the code for animations using a program Camtech made, located
here: [Link] It will only dump
the code, though, and not the frames—but it’s still very useful if you’re creating
animations similar to existing ones, but with different graphics, as you can copy the
timings amongst other things from the ripped code.

- There’s somewhat of a fix to looping battle animations covered briefly in this topic:
[Link]

- A topic with a bunch of animations you can use in your hack (but always give credit and
if needed, ask for permission!) can be found here -
[Link]

General Graphics

- There’s this cool program called FERecolor which can help make recoloring sprites etc.
easier. You can find a tutorial on it (with a link to the actual program included in the
tutorial itself) here: [Link]

- Making custom battle frames (AKA battle templates) is difficult, but if you want to,
there’s a tutorial here: [Link]
 - There’s another tutorial on how to find most palettes in the ROM located here:
[Link]

- Some alternate tutorials on inserting map sprites and weapon icons can be found at
[Link] and
[Link] respectively.

- Here are a couple of tutorials on inserting tilesets -

[Link] and
[Link] (video tutorial)

Music

- The FE7 native instrument map, located here

[Link] lets you use the same
instruments that the original Fire Emblem 7 did. The selection isn’t perfect, but it’s nice
as it does make the songs sound more like they belong in Fire Emblem. Just copy the
data in the .bin file to your ROM and repoint the instrument map (the second word of
the header of the song) to the beginning of the instrument map; e.g. if your song header
is at 0xD00000 and the instrument map is at 0xD20080, you’d type “80 00 D2 08” at
0xD00004.

- A guide on changing instruments mid-song is located here -

[Link]

- A topic on GBAMusRiper can be found here -

[Link]

- And a lot of information on how sound works can be found here -

[Link]

Other

- A way to calculate average stats is here:

[Link]

- Some thoughts on creating original plots and worlds can be found here -
[Link]

- A workaround for multiple proof weapons can be found here -

[Link]
 - If you haven’t already seen it, a bunch of obscure hacking tips can be found here, and a
lot of them are pretty useful!
[Link]

Chapter 73: Useful Links & Websites

First, I suggest you look at my website’s documentation page. Included on it is some of my own
documentation as well as lots of other documentation thanks to various hackers across the
internet. I also suggest googling Hextator’s Doc, a very thorough compilation of all of a veteran
FE hacker’s hacking stuff, which isn’t even limited to Fire Emblem, but has a ton on Fire Emblem
regardless… tl;dr it’s important.

[Link]

Some other good hacking websites are:

- [Link]

- [Link]

- [Link]

Some decent Fire Emblem websites are:

- [Link] | [Link] (My own website, has lots of neat

stuff if you ask me :P)

- [Link] | [Link] (Very good for

everything, the biggest Fire Emblem fansite to exist really)

- [Link] (this one just looks cool)

- [Link] (has some miscellaneous resources)

Need a file host? Here are some:

- [Link] (more than just a file uploader, also has direct links)

- [Link] (deletes files for inactivity)

- [Link] (deletes files for inactivity and requires registration, but has
1GB of space and direct downloads)

- [Link] (people like this one, but I don’t, especially due to ads)
Need an image host or some way to upload images:

- [Link] (registration required, but many features and lots of

space. DO NOT UPLOAD BMPs TO THIS WEBSITE, IT DISTORTS THEM)

- [Link] (this is actually a program used to take screenshots very quickly:

usually works and is really neat, but not great for all purposes)

Chapter 74: Bonus – Assembly Hacking

Okay… I can’t believe I’m writing this.

If you want to learn some basic assembly hacking for the GBA, more specifically how it applies
to FE7, then you’re in the right place, I suppose. Just don’t expect it to be easy.

In fact, before you read this chapter, please make sure you know a lot about modding Fire
Emblem. Like, you should have strong grasp over other topics because I am going to assume
you know a lot so that I don’t have to teach you a lot. Assembly is a programming language and
it’s even more obscure when you start trying to make hacks of other people’s programming.
You’re essentially going into code that you haven’t written and the way you see it it’s mostly
just simple opcodes and numbers. You have to get a sense for what is what and what does what
on your own, which is why it’s so difficult. If video games were open source (I’m pretty sure
they don’t write them in raw Assembly…) this would probably be a LOT easier.

Now, even if you are prepared, there is no guarantee this will help you do what you want. I’m
not a great or highly experienced ASM hacker myself: I taught myself a little, and I’m going to
teach you what little I know. Often times, you’ll see me saying “I don’t know what this does” or
“you’ll have to play around” or things like that. It’s a programming language: it requires you to
have your own logic and intuition. You WILL need trial and error. You will need to have
patience, persistence, and maybe some food to snack on. Personally, I get dehydrated
somewhat quickly, so having water next to me is essential.

…Seriously though. I didn’t intend to have this in the Ultimate Tutorial, but here we go. The
bonus chapter—added after the initial completion of this tutorial. Something that most people
never even touch outside of just applying other people’s assemblies hack.

Assembly hacking.

Preparations:

First, we need to get you some materials.

 - [Link] – GBATek. Contains hardware information
regarding the GBA and NDS. Yes, a lot of what we’re learning applies to the Nintendo DS
as well. Same programming language and all. Of this huge resource, the THUMB and
ARM instruction sets will likely grab your attention more than anything else, at least at a
basic level.

- [Link] - Thumbref. For me, it’s even more useful

than GBATek. It’s a very nice reference used as a reminder as to how codes work in
terms of what their name is, their parameters, and other information. Note that it’s a
reference—something you use as a tool or guide, like a cheat sheet. It won’t really teach you
anything. Also, you may want to save this PDF to your computer to make things easier.

- [Link] - Necessary to actually compile your ASM

routines into something you can use. Sadly, we’re already at a point where I can do little
to help you: I managed to install this and get the necessary programs working after
some magic that I don’t remember, but people tend to have problems with it. For now,
try installing the program and once it’s done, restart your computer. We’ll worry about
actually making use of it later.

- A Windows computer. I won’t even bother trying to support Macs here. I’ve got no clue.
I’m all for convenience and compatibility, which is why I use Windows. I wouldn’t even
know where to start in terms of supporting Macs here, so I’m not even going to try. :(

- [Link] – Extract this

ZIP and you should get a batch file that will help you compile Assembly. If you edit it
with a text editor, you should note that it requires some files in the directory
C:\devkitPro\devkitARM\bin\, which is why it’s important to install devkitPro.

- [Link] - Notepad++. It’s just too good to

pass up. Way better than writing in plain old notepad. It’ll color code things and just
help you with your organization and general programming happiness. Use it, please.

Now that you’ve got some setup, let’s get into things. This is your last warning, by the way: I’m not going
to be teaching this very easily where I go into unnecessary amounts of detail and explain every little
thing, assuming you know hardly anything. You’ll be expected to know how events work, how to make
changes using Nightmare, how to use a hex editor quickly and efficiently, lots of general hacking terms
etc., and how to memory hack (here’s a short video: I suggest you fool around a little more than what I
did there though, so you can learn more/master it a little) and use VBA as I’ve taught in previous
chapters.

It’s assumed that if you’re continuing, you’re prepared, and you’re ready to put some effort and time
into this. If you’re not happy, try finding another ASM tutorial out there that’s actually practical—I
never could, so I spent dozens of hours teaching myself, having the hardest time just doing the most
basic ASM hacks. I’m not trying to complain, I’m just trying to prevent you from complaining.

But alright, enough of that. Let’s get on with this. Assembly hacking might be tiring and difficult, but it’s
also the pinnacle of hacking, letting you actually edit how the game works, and can some of the most
rewarding hacking you will ever do. It’s also a programming language, meaning if you learn this well
enough, you can write it on your résumé (though I’m not sure how impressive people would find it) and
apply some of the basic concepts towards learning new programming languages, if this is your first one.

Part 1: Background Info

- Assembly, ASM hacking, whatever: I’ll likely just use terms loosely and call what we’re doing
“ASM hacking”, meaning hacking assembly. We might sometimes actually write our own
routines, in which case we’re doing less modding and more creating, but I’ll still call it an ASM
hack, because whatever, proper terminology isn’t a huge deal to me.

- Assembly can be viewed in a hex editor, like anything else. In fact, certain nightmare modules,
like the vulnerary editor, actually edit assembly itself. Also, assembly can be found in various
parts through the game, but the core of it is found in the first… roughly a megabyte, though I
think it’d be more accurate to say it goes around to somewhere in the 0x080C0000 section.

- Assembly codes, known as opcodes, usually take up 2 bytes. However, what it does is more
dependent on the bits (review binary if you need to: I won’t explain it here). There are several
exceptions in which case opcodes may take more than 2 bits or in the case of the ldr function,
may have values stored at the end of a routine, as opposed to in the middle. This will make
more sense later. (Also, function/code/opcode, it’s all the same to me, FYI.)

There are multiple ways to “hack the ASM”. You can edit it through a hex editor directly, but this is often
too difficult because you would have to know what the hex for various opcodes are, and figuring them
out can be a pain, to say the least. However, if you’re just editing a parameter, which may be one byte
(e.g. 0x14, or 20, the level cap) then it’s probably much easier to just edit that parameter directly.

You can also write a text file that is usually saved as a .asm file and contains code for an assembly
routine. FYI, an assembly routine is the generic term I use for any code of assembly that does something.
It’s sort of like a script, except I might reference “the damage calculating routine”, which might in fact be
part of many other routines, because the game WILL reuse code where relevant (for instance, the
Random Number Generator code is used a lot).

Part 2: Inserting an Assembly Hack

Before you go making your own, let’s get you familiar with how to insert some pre-existing ones.

[Link] – Here is a
hack I made that forces the game mode to be Hector Hard Mode. It’s very simple and we’ll use it as an
example.
First, put the Assemble ARM batch file in a folder where you’ll stick your ASM hacks. It’s good to be
organized so I suggest making a folder for every ASM hack you make once you’re done with it, naming it
appropriately and taking notes ALL THE TIME. Taking notes is super important, especially in finding bugs
in your own code—and if you ever have to go back to edit code, you’ll be happy you took notes because
it can be a serious pain to figure out what the heck you wrote a few months or even weeks ago.

Extract it and take the .asm file and drag it onto the “Assemble ARM”. If devkitPro was installed
successfully and everything, it should work fine. If not… well, we have a problem. Try restarting and
changing your installation method or other random stuff. I’m really not too sure how it works but people
tend to have problems with this. Sadly, I’m really no help here—hey, I warned you earlier.

It should give you a dialog message in a command window like so:

It may occasionally mention something about a “pipe”… I really don’t know what it means, but it doesn’t
really affect anything, so don’t worry.

Two files should be outputted once it’s done: a .dmp file and .symbols file of the same name. The
.symbols file is, as far as I know, useless. I don’t know what it does because I didn’t learn the
programming language properly but I never needed it and I got pretty far.

The .dmp file is super important though. It contains the raw hex/binary (remember, it just depends on
whether you look at it through a hex, binary, or even text editor—utlimately, the file is still the same).

To insert this ASM hack into your ROM, find some free space, copy all the data from the .dmp file, and
paste it there. Note the offset.

Now the way this ASM hack works is that you have to call it somehow. Sometimes you can call ASM
routines through events and other times you’ll want to insert your ASM into an already existing routine
meaning you have to find the routine first and then insert over that routine or even expand the routine
to branch elsewhere, put your code there, and then tell the game to go back to after you branched at
the original point (meaning, where you were before you branched, but after the branch code itself, or
else you’d infinitely branch: we’ll get to this later).

This one is easy because you can just write an event using the event assembler to activate it. You should
know the code already, but if not, it’s:

ASMC 0xOFFSET

There’s a catch here though. 0xOFFSET is the offset in hex, okay. You know this. But if you insert it to
say, 0xD50000, it won’t work. This is because the routine is written in THUMB and there’s a difference in
how things work between THUMB and ARM.

What the hell are THUMB and ARM? Don’t ask me, I don’t really know. But we can use either THUMB or
ARM to write our programs and we’re going to use THUMB. To let the game know we’re using THUMB,
we’re going to make it start at an odd offset—meaning we add +1 to the offset we inserted the routine
at. Yes, that’s right—you would actually type “ASMC 0xOFFSET+1”, or in our example, “ASMC
0xD50001” for it to load the routine at 0xD50000.

Go ahead and test the event: you probably won’t see anything happen because it’s such a simple event.
However, secretly, it forced the game to be hector hard mode. In fact, if you beat the chapter you were
on and save, you should be able to tell because in FE7, Hector Hard Mode playthroughs have grey-
colored chapter titles. Granted you might have changed that in your hack, but that’s the default in
vanilla (non-edited) Fire Emblem 7.

If you’re not convinced/don’t want to beat the chapter though, you can check the memory. Go to
0x0202BC13 in VBA’s memory viewer and you should see “0x03” there. 0x01 = Lyn’s mode, 0x02 =
Eliwood’s mode, 0x03 = Hector’s mode. At 0x0202BC0C, you should see “0x40”. 0x40 is the value for
hard mode (it’s likely a bit map though, meaning what actually matters is the bits in the ‘4’ that act as
the flag for hard mode… anyhow, this hack FORCES it to be 0x40, so the other bits are set to 0 here).

Congratulations: you’ve now inserted your first ASM hack. A couple notes: using “ASMC” runs the code
once. If you want to run it again, you use the code again. The program needs to… you know, end, or else
it’ll go into an infinite loop and freeze, so you can’t “make the program loop” in that regards. Thus if you
were trying to say, make sure someone’s HP was always at max all the time, using an ASM hack like this
wouldn’t be a good idea because if it’s just constantly forcing that HP, it can’t do anything else… as in
like, you couldn’t play the game, because the game runs on ASM. XP

Anyhow, next let’s figure out what the ASM hack actually did.
Part 2: Breaking Down Your First ASM Hack

Before breaking them down, make sure you can insert ASM hacks with little trouble. There are some
ASM hacks on the Fire Emblem Shrine Forums and Serenes Forest Forums: look for them and try them
out. Some might just ask you to edit hex directly, while others might ask you to use a patcher of some
sort or copy some data. Whatever it is, be familiar with it: the more you know going into these things,
the easier it’ll be, because you’ll have less new things to learn, if that makes sense.

So, ASM hacks are written in a .asm file, which is really just a text file with the extension .asm. Thus you
can just right-click the Hector Hard Mode [Link] text file and edit it in Notepad++ and you’ll be off.

Oh gosh, what does THIS mean?

Don’t worry, I’ll teach you. But again, I’m not going to go over things constantly and repeat myself a ton,
meaning once I teach what the .thumb code does, you’ll be expected to know it henceforth. If you need
to look back on things I taught, by all means, look back—it’s not expected that you learn this all in one
reading, on your first time.

To start, every code starts on a new line. There are two main types of codes here: a code that the
assembler uses in terms of like, writing the program, which are codes that start with periods, and actual
assembler codes, which will be inserted into the ROM—they’re usually indented and don’t start with
dots. You don’t have to indent, but it’s nice for organization purposes to indent once or twice when you
write an opcode and also to keep all the parameters on the same level as well. It makes scanning
through code and the such easier. Good programming habits can go a long way.

Now, let’s begin:

- .thumb sets it so that the instruction set use is THUMB. You’ll want this at the beginning of your
files pretty much all the time, unless you’re using ARM, which I am NOT teaching here, because I
am only teaching you what little I know about ASM hacking.
 - .org sets the offset. It’s just like the event assembler code, ORG—in fact, Nintenlord, the maker
of the Event Assembler, knows ASM, and borrowed a lot of the ideas in his event assembler
from knowing assembly and programming in general, I’m pretty sure. I’d go into making
comparisons and such, but it’s not really relevant. For this example, we want the program to
write to the offset 0x00, so we tell it that. 0x00 is the same as 0x0000000000, FYI. Also, this code
is totally important, just like the .thumb code.

- There is a blank line at the end. Well, several, in this case, but in general, you just need one. The
assembler will complain if you don’t have one. Give it one. Don’t let it complain.

Okay, we’re done for now. Yeah, I totally just avoided the actual assembly there. Teehee. That’s next:

ldr: ldr is a very important code. It loads a word to a register. Oh man, what’s a register?! Looks
like I need to take a break already so I can introduce registers:

Registers are like little slots where you can store values. They’re like boxes, each one with their own
value, up to a word long. You can store information in them and load information from them, but
they’re just temporary—they don’t really do anything. However, they’re also variables.

What are variables? Study up on’em, bud, the general idea is important—how it applies here is that
when I say “r1”, I’m really talking about whatever is in r1. We don’t know exactly what it is because it
depends, so we just reference it as a variable here. Instead of saying “move the specific value ____ in
box r1”, we just say “move box r1”. It’s actually a lot simpler in practice than I’m explaining here, so let’s
just continue on.

ldr: ldr is a very important code. It loads a word to a register. What the word is depends on what
comes after the comma. In this hack we have the code:

ldr r1, =0x0202BC13

ldr tells us it’s loading a word, or 4 bytes, into a register—the register r1 (technically the 2nd register
because there is an “r0” as well). The value we are loading is designated by what is after the “=”,
0x0202BC13. In the ldr code, the equal sign is needed so that it knows it’s loading that value. I don’t
know the specifics, but just use it. XP

Okay, so before I continue introducing codes, I need to tell you something else. It’s a very good idea to
keep track of what register holds what. On that note, you may want to keep a separate text file with
notes (including what the heck that word “0x0202BC13” is might be helpful too :P) but you may also
want to add comments.

To add comments, just add the @ sign, followed by a space (I’m actually not sure if the space after the
“@” sign is necessary, but I do it anyway because I was never taught formally so I just copied what I saw,
haha), followed by the comment. You can do this on a new line or append it to a line of code. So we
could type in
 ldr r1, =0x0202BC13 @ Loads the word 0x0202BC13 to r1

and it would have the same effect as before. The @ sign and everything after it are ultimately ignored.

Furthermore, you may want to keep track in general when you edit values in registers (which is pretty
much all the time) so that you know what register holds what. Often times you have some intended
operation you’re trying to do and when finding bugs/glitches, it’s good to know what EXACTLY are the
numbers going through the system. Sometimes though, you’ll load a variable into the system, in which
case you just have to put in some example value and run through the program in your head and test
things to see how it turns out in various situations (you must always test multiple situations once we get
onto conditional branching, which says “if this, do this, or else, do that”, a common theme in
programming languages.

Oh boy, more rants and information for you to absorb. I told you it wouldn’t be easy. I’m not even giving
lots of nice pictures to work with. Text, text, text, and more text.

By the way, it might seem silly to keep track of all of this in your head—that’s why eventually, I’ll teach
you about using debuggers, which will let you run through the code systematically, using a program, and
really help you keep track of what’s happening. It’ll also help with a lot of other things. But step-by-
step—you’ve got a while to go before we get to that point.

mov r0, #0x03

The “mov” opcode does what you might think—it “moves” values around. In this case, we are “moving”
the value 0x03 into register 0, r0. As for where we’re moving it FROM… don’t think too much about that,
alright? Think of it as just saying “r0 = 0x03” in this case. We can also do something like mov r0, r1,
which would say r0 = r1… which is slightly confusing, because you might wonder “so does r1 become r0
or does r0 become r1?” and the answer is “r1 becomes r0” because if mov r0, #0x03 makes r0 = 0x03,
then mov r0, r1 makes r0 = whatever value is in r1.

By the way, the “#” sign next to 0x03 is key. It has to know it’s a numeric value. Don’t forget the # sign.

strb r0, [r1]

We’re making progress! This code sort of does the opposite of ldr—it stores values instead of loading
them. However, this code actually stores a byte, not a word. How do we know? Because the opcode is
“strb”, which stands for “store byte”, where the “b” is for “byte”. If there wasn’t a “b”, it would store a
word. If there was an “h”, i.e. “strh”, it’d store a half-word, or 2 bytes. Of course, the load function has
similar variations, though it also has two more variations. Let’s take a look at thumbref:
LDR (okay, they capitalize it, I don’t, big deal) loads a word into a register. We know this. Thumbref tells
us this too—the first column is the name or “mnemonic” of the opcode. The second is a very short
description of what it does. The third is a list of possible formats you can use the code in—essentially,
you have a little bit of freedom as to how you use the code, i.e. what parameters you use. The fourth
column specifies what the variables are and the such—right now, they don’t make too much sense, even
to me, but thumbref DOES give definitions of the symbols.

Let’s break down Rd = [Rn + Rm], which is under every row in the fourth column of that image I showed.

Rd = destination register, according to this. In other words, it’s the register that is being effected.

Rn = a register. “n” here is generic. We can put whatever we want. It’s just saying that it’s some register
we choose.

Rm = another register, this time just called “Rm”.

+ means plus/add, meaning we’re adding the register Rn and Rm together. I’m sure you guys can handle
some addition.

[ ] are brackets that… it’s hard to explain, but it’s like instead of loading the value Rn + Rm, it loads the
value at the ADDRESS Rn + Rm. Essentially, it treats whatever is in the bracket as an offset, instead of
just some arbitrary value.

Anyhow, they’re important, and they’re there because the opcode format expects it. Similarly, be sure
that you don’t forget it—thumbref is useful like this because you can always check the code format to
make sure you’re using it right, or using the variant that you want to use. (The assembler will likely give
an error if you use a code in a completely wrong format, since it won’t know what to do with it.)

Some of the other symbols we’ll get to later, and some of the others I still don’t really understand
myself, so yeah…

I digressed a lot, but back to the point:

strb r0, [r1]

So strb stores a byte. How does this code work? Well, this one’s a bit tricky. We’re actually storing the
byte of r0 into r1. It’s been a while, but in this example, r0 = 0x03, and r1 = 0x0202BC13. Now that we
know how to use thumbref, let’s see what it says about this.

STRB Store Register (unsigned byte)

STRB Rd, [Rn, #] [Rn + (#<<2)] = Rd

STRB Rd, [Rn, Rm] [Rn + Rm] = Rd

No pic this time because there’s this stupid grey line plaguing my thumbref and it looks ugly. So raw text
instead.

Anyhow, what we’re doing doesn’t really match either of these formats. However, you can kind of think
of it as either one, except we’re ignoring a parameter. There is no extra # or register we’re dealing with.
Our code is just strb r0, [r1, #0x00] if you want to think of it that way, though I wouldn’t write it that
way.

So what it’s saying is that it’s storing a byte from Rd into Rn. Which is odd, because we said “into Rn”,
and yet “Rd” is the destination register. Yeah, I don’t really understand it myself, but that’s how it works.
Back to the example, that means we are storing r0, 0x03, into the OFFSET 0x0202BC13. Why offset?
Because as I mentioned earlier, brackets denote an offset, giving an actual meaning to the word
“0x0202BC13”.

Okay, so now we know 0x0202BC13 is an offset. What’s at this offset? We made it so that we changed
the value at 0x0202BC13 to 0x03. That’s what “strb” does. Well, what we did is kind of like memory
hacking—0x0202BC13 contains the value for the mode, which I actually mentioned a while back. If it’s
0x03, the game reads it as “Hector’s mode”. So what we did was changed the value so it’s 0x03. We
essentially memory hacked using assembly, except we did it FOR the player. Cool beans, huh?

Now, I’ve taught a lot, so let’s do some practice. Well, just one little practice. I’m going to give you
something just like before and you’re going to tell me, to the best of your capability, what it does.
 ldr r1, =0x0202BC0C

mov r0, #0x40

strb r0, [r1]

…It’s actually the next part of the ASM hack we’re looking at here. Look through it and try to figure out
what it does. Think about what value is stored in each register. Try to figure out what the values
“0x0202BC0C” and 0x40 do—I specify it a while back. Then, read on.

What it does is load 0x0202BC0C into r1, replacing the old value that was there. We don’t need
whatever was in r1 before, so we’re just overwriting it.

Then, it moves the number 0x40 into r0, meaning r0 is now equal to 0x40.

Lastly, it stores the value 0x40 at the offset (denoted by brackets) 0x0202BC0C.

From a practical stand point, we “memory hacked” the offset 0x0202BC0C to be 0x40, which sets the
mode to “hard mode”.

If you understood all of that, great job—if not, I suggest you review it before you move on. Remember
that there are other resources to make use of besides this tutorial. ^_^

Now, we only have one line left. W00t! ALMOST THERE! It’s taken forever, but there was a lot to teach
besides just the opcodes. You’ve learned a lot. Let’s wrap this up.

bx r14

Our shortest code yet, but there will be another long explanation.

…You see, there are 16 registers. r0-r15. I think. (I know, I’m never sure of anything.)

But some registers have special purposes. Generally speaking, r0-r7 are free for you to use. r8-r13, I
dunno, don’t ask. r14 and r15 are a bit special though. r14 contains the address that the “game” or
“processor” or whatever you want to call the “thing” that runs through ASM was at before it last
branched. I think. Don’t quote me. On the other hand, r15 contains the address of where you are right
now.

Thus it’s a little bit risky to mess with these, but they’re also very important to have a working
knowledge of. FYI, r13 is also called sp (stack pointer), r14 is also called lr (link register), and r15 is also
called pc (program counter). They’re all super important in more complex hacks. For now, what this
does is “branches and exchanges” to r14. Since r14 contains the address of where the game was at its
last branch, what it does in this case is takes you back to where you just were before you started
running this code.
Think about this from the game perspective: everything runs through ASM, correct? So before the game
ran this ASM routine, what was it doing?

…Wasn’t it running ASM related to the event codes right before it?

I think it was.

So what will it do?

It will return to that point and start running from right after the ASM call you did with ASMC. In other
words, it’ll run the next event code.

IN OTHER WORDS, it ends the ASM routine. It says “we’re done here—go back to whatever you were
doing before you were running me”.

IN OTHER WORDS, we’re done here.

Part 3: Second Example – More Codes, More Fun

Before we go onto more examples, I suggest doing some experimenting. Take that simple ASM hack I
gave you that makes the mode Hector Hard Mode and change some of the values. Change the 0x40 to
something else. Change the offset to something else. Be careful you don’t choose an offset that breaks
the game though—if you’ve memory hacked before, which you should have, you should know how to
edit characters stats through memory. Well, find the address of say, the level of some unit, and type
that in instead. Make their level 99 because no one’s level in Fire Emblem has ever gone that high and
it’d be interesting. (I shouldn’t be saying this because it’s such a fundamental, but use MS Calculator or
something if you need to convert from hexadecimal to decimal, decimal to binary, or anything like that.)

Once you feel comfortable enough making small edits how you like, let’s continue on to learn more
opcodes. Also, I’m going to expect you to experiment and play around on your own from here on out. I
might not say so explicitly but it’ll take good practice to really know these codes. Your hacks don’t have
to make some awesome change or even be useful—it’s all for learning purposes. However, you CAN
make useful hacks with what knowledge you have right now—after all, making the game use Hector
Hard Mode allows one to use the bonus levels feature, which autolevels enemies according to a value
you can set using the Chapter Data Editor, which is a nice feature to have handy.

The next example is a huge step up from the last one, but whatever, you can study and perfect things on
your own time—let’s get to it.

[Link] – This hack is

known as the Character Data Clearer hack and is capable of clearing unit data by a table. I used it in TLP
to clear all the character data for use in the post-game, because everyone’s levels are reset.
Furthermore, I *think* that it is also used in Elibian Nights to reset the character data after a tale has
been completed. The manual way is to spam the KILL code on every possible unit which is not only a
stupid copy/paste job but is also time-consuming in game as the player has to wait for characters to be
killed in the background (with the worst part being that you can hear the death sound -_-).

So we know what it does—let’s open it up and see what it’s all about. Keep in mind that I am not always
the best note-taker myself because I tend to be lazy and some of these codes are so common/simple for
me that I didn’t always feel the need to document them if I already knew what they did. However, other
times I write a LOT of notes, mainly when I’m using new codes or combinations of codes or am trying to
fix bugs. In general, if you have the time, write notes—aside from taking up time, it doesn’t hurt, and it
might ultimately save you more time than it took to write them.

These first four lines are just notes. Okay, so we DON’T need spaces after the “@” symbol. Seems I just
forgot about that detail. :P Anyhow, I don’t note every register here, but I do note some things. As for
what it means, you’ll figure it out later.

We know what the first two lines do. However, the third line is new. However, don’t be alarmed: it’s just
like the Event Assembler. “Initial” is a label. We can reference it. Whatever offset we are at, that is what
“Initial” is equal to. Right now, that means offset 0x00. However, when writing code, that offset isn’t
always obvious. If you want to jump between parts of the code, you create labels and reference them.

HOWEVER (you’ll be reading me “however” you a lot), you won’t see this when disassembling the
game’s assembly. These disappear. The assembler uses them, but in terms of actual code, they aren’t
there. It’s just like the .thumb codes—they’re used to write the code, but the output will ultimately all
be nonsensical numbers.

Let’s move on.

push {r0-r6, lr}

This is an important code and a difficult concept to teach. What it does is it “pushes” registers. The basic
idea is that it stores the values in the registers for later use—you can bring them back later. It stores
them in what’s called a “stack”. It puts them on the top. When you use the opposite of the push
command, which is pretty much a must, you bring back what’s currently on top of the stack. In this case,
we are “pushing” r0 THROUGH r6 (the hyphen means through) as well as lr, or r14 (the comma is used
to specify a separate one). You could type push {r0, r1, r2, r3, r4, r5, r6, lr}, but it’d be pretty silly and
inefficient.
If you need some analogies as to how this push thing works, here’s a Skype chat with a friend I had (I am
“ballin1337”, FYI) where I casually explained the push/pop. FYI, the pop works the same way, except you
type “pop” instead of push, and if you “push” lr, you must “pop” pc in return (and of course you must
also pop all the other registers that you pushed). Anyhow, here is the conversation—read it if you want,
or skip ahead if you get it already.

[1/18/2013 7:14:30 PM] ballin1337: next is a new rather important but complicated code

[1/18/2013 7:14:33 PM] ballin1337: the "push" code

[1/18/2013 7:14:39 PM] ballin1337: it actually kind of does what it says

[1/18/2013 7:14:43 PM] ballin1337: and works with another code, called the "pop" code

[1/18/2013 7:14:46 PM] ballin1337: what they do

[1/18/2013 7:14:54 PM] ballin1337: is they move data into stacks

[1/18/2013 7:14:56 PM] ballin1337: and move them out of stacks

[1/18/2013 7:15:04 PM] ballin1337: so lemme give you an analogy

[1/18/2013 7:15:19 PM] ballin1337: so let's say you're working at your desk.

[1/18/2013 7:15:33 PM] ballin1337: on your desk, you have a bunch of folders

[1/18/2013 7:15:38 PM] ballin1337: because you were working on this stupid history project

[1/18/2013 7:15:57 PM] ballin1337: so now it's all cluttered

[1/18/2013 7:16:01 PM] ballin1337: and you don't have ANY space on your desk

[1/18/2013 7:16:06 PM] ballin1337: annoying, right?

[1/18/2013 7:16:12 PM] Jubbeeh: most defs

[1/18/2013 7:16:21 PM] ballin1337: so you're like

[1/18/2013 7:16:27 PM] ballin1337: "I can procrastinate on my history homework"

[1/18/2013 7:16:31 PM] ballin1337: "but math is due TOMORROW"

[1/18/2013 7:16:38 PM] ballin1337: thing is, you don't have any space to work with

[1/18/2013 7:16:44 PM] ballin1337: so what do you do?

[1/18/2013 7:16:48 PM] ballin1337: you push everything off the desk

[1/18/2013 7:16:55 PM] ballin1337: and make room for your math homework.
[1/18/2013 7:17:08 PM] ballin1337: now everything's on the floor

[1/18/2013 7:17:16 PM] ballin1337: you roughly know where it was on the table though

[1/18/2013 7:17:18 PM] ballin1337: so you can put it back easily

[1/18/2013 7:17:25 PM] ballin1337: but right now, you're doing math

[1/18/2013 7:17:32 PM] ballin1337: not only that

[1/18/2013 7:17:38 PM] ballin1337: but you made a note of where you were in your history project

[1/18/2013 7:17:46 PM] ballin1337: to make sure you could start it back up at any time

[1/18/2013 7:17:52 PM] ballin1337: without having to figure out what the hell you were doing

[1/18/2013 7:17:58 PM] ballin1337: now

[1/18/2013 7:18:00 PM] ballin1337: you do your math homework

[1/18/2013 7:18:05 PM] ballin1337: while screaming in agony

[1/18/2013 7:18:14 PM] ballin1337: eventually though

[1/18/2013 7:18:15 PM] ballin1337: you finish

[1/18/2013 7:18:23 PM] ballin1337: and the next day, you decide it's time to get back to that history
work

[1/18/2013 7:18:26 PM] ballin1337: so what do you do?

[1/18/2013 7:18:40 PM] ballin1337: you take the folders

[1/18/2013 7:18:45 PM] ballin1337: "pop"'m on the desk

[1/18/2013 7:18:48 PM] ballin1337: and pop'm open

[1/18/2013 7:18:52 PM] ballin1337: ready to use

[1/18/2013 7:18:58 PM] ballin1337: ready to get straight back to work, right where you left off.

[1/18/2013 7:19:02 PM] ballin1337: and that's push/pop.

[1/18/2013 7:19:06 PM] Jubbeeh: XD

[1/18/2013 7:19:16 PM] Jubbeeh: pop'm back

[1/18/2013 7:19:18 PM] Jubbeeh: winning

[1/18/2013 7:19:22 PM] ballin1337: XD

[1/18/2013 7:19:27 PM] ballin1337: a little bit of a stretch but eh

[1/18/2013 7:19:41 PM] ballin1337: as for how this applies

[1/18/2013 7:19:42 PM] ballin1337: easy

[1/18/2013 7:19:47 PM] ballin1337: registers often have values in them already

[1/18/2013 7:19:49 PM] ballin1337: and said values are important

[1/18/2013 7:19:55 PM] ballin1337: you don't want to just screw up whatever is in there!

[1/18/2013 7:20:00 PM] ballin1337: the game might need it!

[1/18/2013 7:20:05 PM] ballin1337: so what you do is

[1/18/2013 7:20:09 PM] ballin1337: you "push" them

[1/18/2013 7:20:11 PM] ballin1337: to save them

[1/18/2013 7:20:20 PM] ballin1337: then, you can use them freely

[1/18/2013 7:20:22 PM] ballin1337: and once you're done inserting your own code

[1/18/2013 7:20:25 PM] ballin1337: you "pop" them back

[1/18/2013 7:20:35 PM] ballin1337: so that the game is right back where it left-off

[1/18/2013 7:20:46 PM] ballin1337: how it's done is

[1/18/2013 7:20:52 PM] ballin1337: push {r0} for instance

[1/18/2013 7:20:56 PM] ballin1337: anything in these curly brackets

[1/18/2013 7:20:57 PM] ballin1337: is pushed

[1/18/2013 7:20:59 PM] ballin1337: remember though

[1/18/2013 7:21:01 PM] ballin1337: ANYTHING you push

[1/18/2013 7:21:04 PM] ballin1337: MUST be popped back

[1/18/2013 7:21:06 PM] ballin1337: the game will freak out otherwise

[1/18/2013 7:21:11 PM] ballin1337: it's like pushing it off your desk

[1/18/2013 7:21:18 PM] ballin1337: and losing the project information

[1/18/2013 7:21:27 PM] ballin1337: now you have no idea what the **** to do anymore

[1/18/2013 7:21:32 PM] Jubbeeh: right

[1/18/2013 7:21:37 PM] ballin1337: [s]and you were sleeping during class and you don't have any
friends[/s]

[1/18/2013 7:21:52 PM] Jubbeeh: seems close enough to irl XP

[1/18/2013 7:21:57 PM] ballin1337: you can also do push {r0, r1, r2}

[1/18/2013 7:21:58 PM] ballin1337: LOLOL

[1/18/2013 7:22:08 PM] ballin1337: I was totally kidding, just for the record xD

[1/18/2013 7:22:15 PM] Jubbeeh: (jk i have a couple friends XP)

[1/18/2013 7:22:15 PM] ballin1337: so you can separate them by comma's

[1/18/2013 7:22:18 PM] ballin1337: but often it's easier to do

[1/18/2013 7:22:25 PM] ballin1337: something like push {r0-r6}

[1/18/2013 7:22:31 PM] ballin1337: which pushes ALL the registers between r0-r6

[1/18/2013 7:22:33 PM] ballin1337: also, "lr"

[1/18/2013 7:22:41 PM] ballin1337: is like a special name for "r14"

[1/18/2013 7:22:46 PM] ballin1337: it stands for "last register", IIRC

[1/18/2013 7:22:57 PM] ballin1337: just make sure you pop'm back accordingly.

[1/18/2013 7:23:01 PM] ballin1337: I've had glitches cuz of forgetting to do that

[1/18/2013 7:23:06 PM] ballin1337: or typing "push" both times and stuff

[1/18/2013 7:23:07 PM] ballin1337: XD

[1/18/2013 7:23:14 PM] ballin1337: it's the worst because like

[1/18/2013 7:23:17 PM] ballin1337: even when debugging

[1/18/2013 7:23:19 PM] ballin1337: you might not realize

[1/18/2013 7:23:21 PM] ballin1337: until the VERY end of the code

[1/18/2013 7:23:23 PM] ballin1337: lol

Now that that text pillar is done with (or your scrolling down is done with, whichever suited your fancy),
let’s cover the next code.

mov r2, #0x00 @ Starts off memory table check counter at 0

You should already know what this does—it stores the value 0x00 into r2. Remember, there might
already be a value in r2 because we’re just interrupting the game with our ASM routine. For that reason,
we used the push {} opcode to make sure we stored the values safely for registers r0 through r6 (and the
mysterious “lr”). Now we can put whatever we want in the registers r0-r6 without worry because we can
bring back the old values once we’re done using the pop {} command. See how useful those are?

Now, the comment says we’re making some memory table check counter. What’s that?

It is a method of making a loop. We are setting the loop counter to “0x00”. Every time we go through
the loop, r2 will increase by 1, meaning the loop counter will increase by 1. Thus we can keep track of
how many times we go through the loop, and we can also use r2 in other ways, like to say “let’s check
entry #r2”, where r2 corresponds to which run we’re on. If we’re on run #3, then it will check entry #3. If
you’ve programmed in other languages, this idea of a loop is probably pretty basic, but if not, make sure
you pay close attention and practice this once I’m done explaining.

Main: specifies that this part of the code is called “Main”. I did this because it is the main loop. Now if I
need the code to jump back to this part, I can reference it as “Main”.

Add r2, #0x01 is a simple code. It just adds values and/or registers together. If you look at thumbref, you
can see all the variants. This one says “ADD Rd, # Rd = Rd + #”, meaning that since Rd = R2 and
the # is 0x01, R2 = R2 + 0x01. In other words, we’re adding 1 to R2, or increasing the loop counter by
one. Subtraction works very similarly.

Cmp r2, #0x2A introduces another major concept: conditional branching. What it does is compares two
values and looks for some condition—if they’re equal, not equal, if one is greater than the other, less
than or equal to the other, etc., according to what you choose, and then if it means the condition, it
branches you off to somewhere else, and if it doesn’t, then it continues reading from where you left off.

In this case, it is comparing the value in r2 to 0x2A. If this is the first loop, then r2 is 0x01 right now. So
what’s the condition? We can tell by the next code, “beq”. “b” stands for branch and what comes after
is the part of the mnemonic that decides what condition it’s looking for.
It’s the first one on the list here, “EQ”, meaning “Equal”. In other words, if checking to see if the two
values in the “cmp” code above are equal to each other, and if it is, it goes to the offset after it, called
“End”. Before I explain that, let me quickly mention the other two columns above: the “Opcode” column
refers to the bits that control what opcode it is (you probably won’t ever need to worry about this), and I
have no idea what the status flags do, sorry. I never had to use them so I never learned them. XP

Okay, so we had

So “cmp” is compare and it’s comparing r2 to 0x2A (42) and if they are EQUAL, it goes to the end; if not,
it just keeps going to the line after. Now, what is “End”? “End” is a label, just like “Initial” and “Main”. I
specify the location of the label “End” by putting it at a certain part in the code some time down below.
The assembler will find the offset of “End” and jump to it. Fun times.

Now, what is the significance of this? It says that “if the loop counter has reached 0x2A, or if this is the
42nd time it is going through, then go to the end”. It’s letting the routine quit, or stop. There has to be
some way for a loop to stop, after all. This one will stop after 42 checks. The significance of 42 is that the
game starts to get glitchy (at least in my experience) after about 42 characters are deployed. In fact, I
had to limit the player to only 40 characters in the post-game, I think, due to some silly glitches I
couldn’t figure out that only happened to characters 42 and on or something, forcing them to make
some choices (though they can re-recruit any character if they so wish, so it’s tolerable).
We’re going to tackle this next part a lot faster than we have the last few parts—we’re learning more
and more codes and you’ve already seen variations of some of these. Practice and/or use thumbref if
you need to!

First, we load the word 0x0202BD08 into r5. We intend for this to be an offset. It’s actually one entry
before the first character slot in the memory, as the note mentions. Character data in FE7 starts at
0x0202BD50—each entry is 0x48 bytes. 0x0202BD50 – 0x48 = 0x0202BD08. As for why we choose this
offset, it has to do with the math, which we’ll see ahead.

Then we load the value 0x48 into r3. Next, we use the “mul” opcode to multiply two registers together.
The “mul” opcode is pretty cool, but it’s limited in that it can ONLY multiply two registers together,
which means you have to waste a register “mov”ing the value to multiply by beforehand (as I did with
mov r3, #0x48). The first register is the destination register, or the register whose value changes, as per
almost every code except the confusing str code. So mul r3, r2 says that r3 = r3 * r2. On our first loop, r3
= 0x48 (this is actually for every loop because it gets set to 0x48 right before the multiplication) and r2 =
0x01 (the loop counter is set to 1 on our first loop). In THIS case, r3 is STILL 0x48, but on every
subsequent loop, r3 will be some other multiple of 0x48.

Next, we add the two registers r3 and r5 together. What this does is adds the value in r3 to r5 and stores
it in r3. Since r5 contains the base address 0x0202BD08, if we add 0x48 to that, we get 0x0202BD50.
That’s the address of the first character in the memory. On the 2nd loop, we’ll add another 0x48 to that,
getting the offset of the second character in the memory. So on and so forth: we just made the game
calculate the offset of the character in the memory respective to our loop counter.

Next, we use ldr r4, [r3] which instead of loading a word that we specify, loads a word at the offset r3.
R3 is currently 0x0202BD50. The first word in a unit’s memory is a pointer to their character data,
though the GBA Codebreakers Code on gamefaqs calls it something like “portrait” (it DOES change the
portrait, but it changes like, a lot of other things as well). By doing ldr r4, [r3] we are loading the word AT
r3, because that’s what the brackets [] mean. The destination register Rd is r4, so we’re loading it into
r4. Now, this offset will vary, but for this example’s sake let’s say it is 0x08BDCE4C. Thus r4 =
0x08BDCE4C.

The next command loads a byte into r4. What it loads is what’s in the brackets: it says [r4, #0x04]. A
look at thumbref says that what it’s loading here is the byte (ldrb) at the offset of (r4 + 0x04). In other
words, it’s loading the 4th byte in the character data. If you’re experienced enough, you should be able
to look at the character editor Nightmare Module and see the base offset is 0x08BDCE4C and that the
4th byte in a hex editor is the character ID. The character ID is significant because it is an index that is like
a shortcut as to what character we’re referring to. In FE7, 0x01 is Eliwood, 0x02 is Hector, 0x03 is Lyn,
etc.

The code after starts another counter, though this time it stores it in r6. And so once we find our
character ID, we continue on to the next part:

From a practical standpoint, we haven’t really done anything yet, but in actuality we’re making good
progress. Next is this “TableCheck” part of the code. I wouldn’t label it “TableCheck” if I wasn’t going to
reference it later—keep that in mind. (Otherwise I could just use a comment like @ Table Check,
right?—on a side note, I don’t think labels can have spaces and certain other characters, so be careful.)

We have add r6, #0x01 which works just like the last time, which is why I didn’t even make a comment
for it—we’re adding 1 to the counter.

Next, we load the value 0x08DDFFFF into r5. You should know this without me telling you, but I’m noting
it because 0x08DDFFFF is an odd offset. As it turns out, it’s 1 before 0x08DE0000. I chose it for a reason,
and while in retrospect (it’s been a while) I probably could have coded this better to avoid choosing
weird offsets, you’ll see why I did soon.

The next code does something like the ldrb opcode we saw before, but now it takes the byte at the
offset (r5 + r6) and loads that into r5. A look at thumbref will once again tell you this. On our first run, r6
is 0x01, so it loads the byte at 0x08DDFFFF + 0x01, or 0x08DE0000. Aha! We set the offset to be one
before 0x08DE0000 before because we knew that on our first loop, we’d be adding one, because we’re
using the loop counter like that.

Now, we have this byte from 0x08DE0000, a place in our ROM (because the ROM is stored in the
memory at 0x08000000), stored in r5. What is this value? It is, in fact, data that the user of the hack is
defining. We are dealing with a user-created array or table. What it expects here is a value of a character
ID—a character ID of a character whose data we want to remove. In other words, this hack expects the
user to put their list of characters they want removed at 0xDE0000 in a hex editor. Then, when the hack
is used, it will load the byte at this offset. Thus, r5 now contains the character ID of the character we
want to remove.

Keep in mind that before, we got the character ID of the first character in the memory, and we stored it
in r4. That was the first loop.
Next, we’ve got some fancy conditional branching.

We’re going to start by comparing the character ID we got from the table at 0x08DE0000 to 0x00. If it is,
then that’s supposed to mean it’s the end of the table, and we return to “Main”, or the beginning of the
first loop. You’ll see why this is important in a short bit.

Then, it it’s NOT 0x00, it checks to see if r4 and r5 are equal, i.e. if they have the same value. If they are,
then that means the character ID of the current character in the memory is EQUAL TO (beq) the
character ID in the table, and that we should thus remove the character from the data. To do so, it
jumps to some code under the label “MakeChange”, which we’ll get to later. If NOT, then it’s supposed
to keep reading after the beq code—and what’s after that is the “b TableCheck”, which is a direct
branch to the code under the label “TableCheck”. TableCheck is what we’re in right now. Let’s say the
first character ID we got from the table wasn’t a match—it was 0x0A, and our character ID was 0x15.

It jumps back to “TableCheck”, where it adds one to the loop counter, r6. Then it does the SAME THING,
but this time it will check 0x08DDFFFF + 0x02, or 0x08DE0001. It will load the byte there, by virtue of

ldrb r5, [r5,r6] @ Loads the byte/char # there

and check to see if THAT matches.

And if THAT doesn’t, it will continue on until it hits a 0x00, meaning “you can stop checking the table
now—there are no more entries”, or a match. If it hits a 0x00, it will go back to the MAIN loop and check
the NEXT character in the memory—and go through the code ALL over again. That’s quite a bit of
looping and checking for it to do, but the processor will be fine—it can do all of this in a fraction of a
second. You probably won’t even be able to notice it in-game.

Let’s say it finally finds a match in the table—then it goes to “MakeChange”. I wonder what’s that…

We FINALLY get to the part where we actually DO something. This ain’t called “MakeChange” for
nothing. It’s a simple but effective code that stores 0x00 into r0 and then stores the value of r0 into the
address of r3 via str r0, [r3]. First, note that when I move 0x00 into r0, it will replace all the other “digits”
in the register with 0 as well, meaning r0 = 0x00000000 (a register is technically a word long).
Thus when we store r0 into r3, we are actually storing the WORD 0x00000000 into the offset r3. What is
r3? Well, way back when, we calculated the offset of a character in the memory. So what r3 is, is the
offset of the current character in the memory we are checking—checking to see if they should be
removed. Funny thing with Fire Emblem is that when you change the character data pointer, the first
word in a unit’s/character’s memory data, to 4 00’s (0x00000000), the game will end up deleting it and
moving up all the entries below. In other words, it’s an easy way of getting rid of the character. That’s
exactly what we’re doing here—we’re replacing the first 4 bytes of the character’s data in the memory
with 00’s, and once this routine is done, the game will do the hard work and shift everything up for us.

…Sadly, it’s not done. It then uses the basic branch command to go back to the first loop—that’s what “b
Main” is for. It will NOT end until it reaches that code near the very beginning:

cmp r2, #0x2A @ If its entry 0x2A

beq End @ Go to the end

In other words, until it has checked 41 characters/reached its 42nd check, it will not stop checking to see
if any of the characters in the party should be removed. After all, we have to be thorough!

Once it IS finished though, it will go to “End”.

What is “End”?

I said it a while ago, but that doesn’t change how important it is. We pushed some registers at the
beginning, so we’d better push them back, or the game’s going to fuss. Remember also that the
opposite of pushing “lr” is popping “pc”.

My final explanation for this example: what it does is pushes the offset of where we were before the
code starts. Then, when we pop it, we are popping it into r15, meaning we are making the game GO to
the offset where we were, because pc/r15 is the offset of where we are. So if we change r15, we are in
fact changing where we are in the game’s ASM. Again: we are changing pc/r15 to where we were
BEFORE we started running this code. This is our way of ending this routine and returning back to
whatever we were doing before it.

…Wooh.

With that knowledge, go ahead and make a table at 0xDE0000 for characters to remove, add the ASMC
code to an event, and try magically removing characters from oblivion. You know a LOT about ASM
hacking now—practice what you can by making small edits, and…
And actually, you can do a lot more now—however, there is one major problem. To be able to make
changes, you have to know offsets to change. How did we know to use 0x0202BD08, and in part 2,
0x0202BC13, etc.?

Well, one way to know is to debug.

Another way to know is to look at other people’s doc.

I am tired of ranting (it may seem impossible but the pain in my left hand is too great), so I will say it
clearly now (and I’m sure I’ll remind you because I’m like that and love adding parantheses all the time,
like right now).

READ OTHER PEOPLE’S DOC.

In programming in general, it is so important to read documentation. You don’t want to do what other
people have done. You want to learn from their work, their mistakes, and their successes. You want to
save time by taking knowledge and using it for your own purposes. That’s the whole idea behind “open
doc”, “open source”, etc.—it’s seriously, SERIOUSLY helpful. I practically learned assembly and made a
lot of my ASM hacks by stealing from other people. Only until MUCH later did I figure out how to obtain
offsets myself.

If you read people’s documentation, you can actually go off on your own from here and do some serious
work. I’ve taught you that much.

Hextator has one of the largest folders of documentation on Fire Emblem, if not the largest, and a LOT of
it is ASM-based. Nintenlord also has some amazing work, some of which I never had any idea existed
before I checked, which made me feel somewhat stupid after because I could have had an easier time
had I known about all the useful information in there. There’s also other doc spread about on various
websites and the such, including mine, though in a way I consider this entire 300+ page tutorial to be a
large portion of my hacking career’s “documentation”. :P

That being said, I don’t intend to stop teaching now. I am going to teach you more codes, more
examples, and eventually teach you how to use a debugger and some tricks on how to find your own
offsets, although I don’t know everything there is and finding locations of ASM routines in the games
you are hacking is one of the harder parts of hacking for sure (for me, right now, it is probably in a way
harder than the actual ASM-writing itself).

Part 4: More Examples – “Speed-Analyzing”

Time to run through more hacks.

Here’s your next one - [Link]

It’s thumb. Write to offset 0. Start with label “Initial”. Push 5 registers and the last register, then start a
loop counter in r2 with starting value 0x00.

… I think we can go a little faster.

New label HealLoop: add one to the counter. Load the base offset. Note that the base offset works like
before and is one entry before the actual 1st entry for player character (0x0202BD50) but also accounts
for which byte the turn status byte is (0x0C).

Take 0x48 and multiply it by the loop counter to get a relative offset, then add it to the base offset to get
the offset of some character’s turn status in the memory. Then make it 0x00, which will make them
“alive” so to speak (a bit combination of ‘0x04’ and ‘0x01’ renders them dead… though this is technically
the inappropriate way to relate bits, I’m too lazy to think of it in binary: in short, if a character is dead,
they will usually have a turn status value of 0x05, or at least have those bits activated).

Then it loads the max HP byte, which is 6 bytes after the character’s offset in the memory (which is in r0)
and stores THAT in the current HP byte, which makes it so that they are fully healed.

Then it checks to see if it’s entry 0x2A and if it is, it continues to “End” which pops the registers we
pushed, but if not, it keeps going, forcibly reviving characters.
[Link] – This hack lets
you choose who can seize and stuff by using a table. Let’s check it out.

Note that we set the offset to 0x034884 this time. The reason why is because this ASM hack is an actual
hack of an existing routine at 0x034884. In this case, the new routine is shorter than the old one, so we
lucked out and don’t have to repoint it. Repointing ASM routines is a pain in the butt (definitely harder
than repointing tables/arrays) but we’ll get to it eventually.

This time we only push r2-r5. It’s been a while, but I think I did this because I needed some extra
registers to work with and only r0 and r1 were free by default, so I pushed r2-r5 so I could use them and
will re-pop them later.

Before I continue, how the seize option appears is that it checks for a value 0x00 or 0x01, where 0x01 is
true and 0x00 is false (I really hope I didn’t get these confused… >_<’). We don’t have to worry about
when it checks that though—we just need to change how it decides to output either 0x00 or 0x01.
Before, FE7 used a bunch of checks on the mode to see who can seize. Now, we’re going to use a table.

First, we start our counter. Then we load the offset of the table. In another register, we load the offset
of the chapter value in the memory, 0x0202BC06. We use ldrb to load the byte there, which is the actual
chapter value.

Next, a new code: lsl—this is a logical shift left, which essentially moves bits over to the left. I don’t
really feel like explaining it, but due to how bits work this also doubles the value… or rather, it multiplies
it by 2^(#), where the # in this case is 0x02. So lsl r1, r1, #0x02 multiplies r1 by 2^0x02 and stores that in
r1, effectively multiplying it by 4. This saves us a register as we don’t have to use the mul code, and is
thus more efficient. People don’t like the mul code in general and try to switch to this and its opposite,
which is lsr, which shifts to the right, and divides by a power of 2. To divide by a power of non-2 though,
things get a bit more complicated, which is why you either have to use some special bios function (not
preferred) or do some fancy multiplication/division combinations… *sigh*
Anyhow, the point of this is that the table has 4 bytes for every chapter, and those 4 bytes are actually a
pointer. So this user-created table has one pointer for every chapter, and the game finds what chapter it
is and then calculates which pointer to use.

To do that it does a little math and loads the word, which you should be familiar with, and then it loads
the first byte there into r3, because in this line:

ldrb r3, [r2,r4] @ Loads the byte there (based on loop/counter #) into r3

r2 + r4 on the first loop is r2 + 0x00 or just r2.

What it’s doing is trying to load a “list” of characters who can seize on that chapter. Thus it first checks
to see if the byte is 0x00, and if it is, then it’s the end of the list (if it’s on our first run then that means
there’s no entries and no one can seize!) and it marks the true/false marker as false, which is under
“E3”, and I’ll briefly go into a little bit more later.

Otherwise, it loads the current character ID, which so magically can be done with the code

ldr r5, [r0, #0x00] @ Otherwise, load current character ID

ldrb r5, [r5, #0x04]

You can’t tell just by looking, but r0 contained the offset of the current character in the memory.
Remember that the first word there is the character data pointer, and that the 4th byte in the character
data pointer Is the character ID—so that’s what those two codes do. Get familiar with them, I know I at
least used them plenty (and similar things with like classes and items).

Next, we see if they’re the same (organization is important here so that you know to check r5 with r3). If
they are, we go to “E4”, which is my oddly named label which has code for setting the “can this unit
seize?” value to true. Otherwise, we add one to the loop counter and go again, checking the next entry
in the table, until we find a match or the table ends. :P

As for those ending codes:

First, we pop back those registers so they have their original values.

Then, for the false one, I’m not sure why, but we load the character ID yet again, and then set r0 equal
to 00 for some reason. I really don’t know why but for some obscure reason I was encountering some
problems with the code when I removed these lines, so I kept them. That’s one of the potential issues
with hacking existing routines: you have to really understand the code to minimize your chance for
breaking things.

Lastly, we do bx lr, which I believe we’ve seen before, though it may have said “bx r14”. This is our way
of going back to where we started. I’m guessing the original code also used this, since I based my hack
off the original code.

The E4 one is similar but just moves 0x01 into r0 so that when the game checks r0 to see if it’s “true”
(0x01) or “false” (0x00), it knows it’s true (meaning the character can seize).

[Link] – Next up, we’ll be

looking at this rather old “Gold Requirement Code”.
We can do this. We’re writing thumb code to 0x00, starting by loading the location of the funds address,
which happens to be 0x0202BC00 in FE7. Then we load the entire word there, because the funds value
(how much money you have) is a word.

Next, we load something called “GoldAmount” into r1. What I did here was specify GoldAmount below
using a label, just like how we do with branching codes (e.g. “beq End”). However, at the end, I used
.long to write a “long” word, 0x000BDE31. IIRC, .short writes a half-word, .byte writes a byte, and .align
can align the data to make sure that it is word-aligned (which can be important for “relative offsets”,
something I will sadly eventually have to explain to you).

Next, it compares the amount needed (“Gold Amount”) with the amount of current funds, and if the
amount needed is greater, it goes to end one and marks it as false, which has apparently changed to be
the value 0x01 now (I really get confused by this myself, as you can see—idk, just try switching them
until it works >_>’, I really don’t know if 0x01 is true or false or what), and then uses bx r14 to return
back to whatever it was doing (cough, events). Otherwise, it uses the “sub” command to subtract the
needed gold amount from the current funds and then stores it at the funds address. It then marks the
result as “true” (which is apparently 0x00 now… I don’t even know).

Now, you might be wondering, what do we do with this 0x00/0x01 result now?

The trick is the code IFAT/IFAF BLA… Here’s a copy/paste from the EA doc:

FE7:
 IFAT *Conditional ID* *ASM routine pointer*

You can type in the offset of your ASM routine (don’t forget the +1 for thumb, lol) and whatever comes
after is what happens if it’s true and whatever comes after the “else” is what happens if it’s false. Or
something. I’m tired right now and can’t be bothered to check since this is one of those things I just use
trial and error with until it works. Look, I seriously am NOT qualified to be teaching this, didn’t we
establish this near the beginning? XD

[Link] – This hack

changes the list of text names used for tiles in a certain map in TLP where you are in a “constellation”
and so if the tile said “floor” it’d be awkward and yet I don’t know enough about tilesets (surprisingly
enough) to really make my own proper tileset and stuff… so I came up with something that would just
use an entirely different set of names for a specific chapter.

I may have mentioned this before, but finding where to hack routines is difficult. And I’m sure I
mentioned that finding space for them is difficult.

One of the issues is that when you repoint, you can’t magically repoint to anywhere in the ROM. Basic
branching codes use relative offsets, which to put simply, means they have like, one byte, and that one
byte is a “pointer” to where to branch to. That’s a problem because if you’ve worked with pointers,
you’ll know they’re usually 4 bytes. Yeah, well, in ASM, they save space by saying “this thing is X bytes
ahead of or before me”. The thing is with only 1 byte for this value, it limits how far you can branch from
one instruction to another.

Thus you have the bl command, which is better, but still not perfect. The bl command is an opcode that
uses 4 bytes: it has… I believe 3 bytes (it might actually be like 20 bits, I don’t know and I don’t feel
checking—thumref or GBATek could tell you exactly how it works but I’m more about the practicality of
all) and can link to much farther locations, but still not anywhere in the ROM. So now the issue is getting
a location close enough to the original routines, which are usually at the beginning of the ROM.

What I did is use the fact that weapon icons in FE7 start at about 0xC5EA4 or something (this is off the
top of my head) and expanded them elsewhere. Because of that, I now had a bunch of free space from
where the icons used to be. I could use this to put ASM codes. The issue is that for other people to use
my codes, they would also have to expand their weapon icons, or else repoint the ASM on their own,
both of which could be troubling since it isn’t exactly user-friendly, though you shouldn’t have too much
of a problem with repointing weapon icons if you’re this far into my ASM tutorial. :P

So another thing with bl commands is that for it to work right, you have to pretend the file you are
making uses the actual offsets the ROM would use. Actually, you could probably technically write
directly to a ROM, and there are programs which make this process easier. However, I am uncultured
and taught myself this, so I am going to teach you my barbaric ways of copying and pasting ASM codes
from offsets (at least until I make a program that I like and can use to make this easier OR figure out
some other method that already exists that I like).

With that, I will now post the ASM hack:

It’s not super long, but it’s got some new things we need to learn. Let’s get started.

First, we write the first part to 0x019B0A. As it turns out, this is the location of an existing ASM routine,
and for us to write to this offset, we will be replacing codes there. As for how to find this offset, I’ll be
writing a section on how to do that soon, or else I’ll just slowly integrate it into our teachings.

Now, when we overwrite those codes, we have to make sure we ultimately use them or else the output
at the end will be different and things will go awry. Just like with the Seize hack, we have an ultimate
goal, and we’re just sort of changing one or two values on our way or else just changing the conditions
with which to output those values.

In this case, the ultimate lines we use (and replaced) are:

ldr r1, =0x08BE50E8

lsl r0, r0, #0x01

or
 ldr r1, =0x09461900

lsl r0, r0, #0x01

depending on how the conditional check goes. Now, those are 2 opcodes we replaced, and they’re both
2 bytes, and 2*2 = 4 bytes, and a bl (branch with link) is 4 bytes, so we replaced 4 bytes with 4 bytes:
sounds great.

Now with the actual code, we have

bl Event

Initial:

.org 0x0C6048

Event:

We start by branching the normal routine to the routine we’re writing. This is our way of “repointing”.
However, we also note where we left off using the label “Initial”. The assembler doesn’t like when you
use offsets, it prefers using label. So if we need to reference the offset after our branch instruction—
since ultimately, we will want to continue where we left off, we need to give it a name.

Next, we set the offset for our hack—I used 0x0C6048 probably because that’s in the middle of where
the weapon icons used to be, and was the next chunk of free space I had for ASM hacks. We call this
part “Event”, as we referenced with the bl above.

The rest is comparatively trivial:

ldr r1, =0x0202BC06

ldrb r1, [r1]

cmp r1, #0x44

beq StarTiles

cmp r1, #0x45

beq StarTiles

We load the offset of the chapter value at 0x0202BC06, which you should have seen before, and then
load the value. We check if it’s 0x44—if it is, we go to “StarTiles”. If not, we check 0x45, and if the
chapter is 0x45, we also go to StarTiles. If it’s neither of those, we continue reading the code, and…

ldr r1, =0x08BE50E8

 lsl r0, r0, #0x01

bl Initial

we end up loading the default list of text IDs at 0x08BE50E8 into r1, EXACTLY as the original code does,
and then multiply r0 by 2 and store it in r0, which I don’t know what it does, but all I did was copy the
code I replaced from earlier to make sure we still had it. (As for how I knew where that code was and
what it was, we’ll figure that out later.)

Lastly, I branch to “Initial” to make the game go back to where I was before I left off. Note that the only
register I used before loading the offset of tile text IDs was r1, and that ultimately we replaced r1 with
the “ldr” opcode so it didn’t matter that we did it. If we needed to use other registers, we’d have had to
push them, like I did in another example, and pop them back later.

The “alternate ending” though, if you will, has it load a NEW list of text tile IDs. This is only if the special
conditions were met as shown before.

StarTiles:

ldr r1, =0x09461900

lsl r0, r0, #0x01

bl Initial

This time it loads a list at 0x09461900, a somewhat obscure offset that you could check at 0x01461900
in a hex editor, and then I use the lsl code again because I want to keep things the same, and then
return back with the bl. As you can see, the only different there was the offset—everything else was just
doing checks to see which offset I’d load. But the effect is pretty nifty, I think.

[Link]
p this is just another short and similar example since branch links are important.
You branch from one offset to the next (this seems to be the first routine I wrote in the new space
actually, since it uses 0x0C5EA4, which is exactly where weapon icons start, I believe…) and then I check
the chapter to see if it’s less than 0x43—if it is, I laod the normal palette, but if not I load a new palette
at some offset 0x09BB4200 that doesn’t really matter (all we need to know is that it holds the palette).
Mov r1, #0xe0 is some code that I replaced and so I put it back.

[Link] – This turns

the critical damage to only 1.5x. I made it 2.5x in a hack of mine and someone requested 1.5x so I did
that too.
I actually stuck this right in the middle of the critical damage routine or something. I branch to the hack
and pop r2—not sure why I popped it but it probably had something to do with the original code…
anyhow, I move 0x03 into r2 and multiply it by r1, which presumably contained the damage. Then I
pushed r2 for some reason and used lsr, the opposite of lsl, to divide by 2^0x01, or 2, which means I
multiplied the damage by 3 and divided it by 2… 3/2 = 1.5, I made it to 1.5x damage. bl Return makes it
return back to where it was.

By the way guys, this might sound shocking, but I used to write a lot longer codes. Check this one out --
[Link] I think it’s like 300
some lines. Why? Because I only knew a few codes so I just copied and pasted them to get my desired
effect instead of using a loop: I manually edited each value of the enemies’ stats. Yeah, I was a serious
noob back then; it also makes me look GOOD now, even though I’m really not. FYI, that’s only part 1—I
had to split it into 2 parts because the assembler got mad after writing so many lines. People didn’t even
know that could happen. >_>’

To end this part of the tutorial (I know my parts are super long, sorry, there’s a lot to teach and I want
this to be thorough), let’s do a long script that could probably be more efficient but isn’t as bad as the
last one, I don’t think.

[Link] – This hack is used in TLP to allow

the player to max their stats if they had the money. It had a “cost” for each stat and calculated how
much the player needed, then subtracted it. Fun times.
“Oh man Blazer, you really hate us, don’t you?”

Nah, this is actually not so bad. We’ve done a lot of practice: hardly any of it really needs explaining. Just
some more practice with some different circumstances, really.

We push registers for use, including the last register, so you can expect us to return using pop {pc}. We
set 3 registers to 0x00, where r2 is a counter and r7 is another check and r3 we just set to 0 because
we’ll want it to be empty later.

In “Main”, we add one to the counter, load the memory table one entry back as usual, and do a little
multiplication and addition to get the character memory address in r3. Then we load the byte there, and
see if it’s 0x00: if it is, we go to the end, because we’re done checking (this might be risky in retrospect:
what if the byte happens to be a 00 because the character data pointer happens to end in 00? I’m not
sure what I was thinking since I’ve used other methods besides this but oh well).

If it’s not 0, we check the turn status byte and see if it’s active. 0x01 and 0x41 are the two values you’ll
ever see for active, though a more proper solution would probably be to check the actual turn status bit
that says “this character is active”… also, 0x01 has other uses besides the bit for “active”, which is kind
of weird, but whatever, details don’t matter too much.
Anyhow, if it IS the active character, then we’ve found the character we’re trying to max. Why? Because
how this hack works is that the character talks to another character who asks if they want to max their
stats. While talking to a character, the character who initiates the talk is active—so we find which
character it is by checking for the active character. Clever, no?

By the way, if it doesn’t find a match, it goes back and loops until it either finds an active character or
doesn’t find anyone (which would be awkward given the nature of the ASM hack, but I have to let it end
somehow).

Now we set r6 to 0x00. This will serve as the register that contains how much money we need to max all
the stats. We will keep adding to r6 until we calculate how much money is needed, then check with our
funds to see if we have that much money.

Under “StatChecks” we load the pointer to the class data from the memory into r0 (it says r1, that’s a
typo or something—trust the code more than the notes, haha). If you don’t know, a unit’s/character’s
memory data has the character pointer (1 word) and then the class pointer (1 word) which is why we
used [r3,#0x04], it loads the memory address of the current character from r3 and adds 0x04 to it and
then loads the word there into r0… meaning the pointer.

Next what it does is it goes through every stat and does some math to calculate how much money is
needed. We’ll go through Strength and the rest are just copies but with slightly different numbers due to
different offsets and other small details. We load the max strength from the class data, which we can tell
using Nightmare + a hex editor is the 14th byte. Then we load the current strength from the memory,
which also happens to be the 14th byte, into r2 (we don’t want to overwrite r3 as we want to keep that
handy so we can keep working with it).

Then we subtract r2 from r1 (r1 – r2) and store that in r4. This tells us the difference between the max
strength and current strength. If it’s 00, then r1 = r2 or max strength = current strength. Otherwise it
should be some positive #.
Then we move 0xFA into r5 and multiply it by 2 to get 500, because this is how much gold is required to
up strength one time.

Then we multiply it by how much we need to (r4) and find how much it costs to totally max strength,
and add that to r6, our total cost for EVERYTHING. Then we have this seemingly odd check where we
check if this is the “first time”. What the hack does is the first time it goes through, it just calculates it—if
it turns out it can go do the change, it goes back AGAIN, but this time makes the change. To know
whether or not it can make the change or not, r7 contains either 0x00 (false) or 0x01 (true). I actually
wrote the code to check if r7 is true or false here, by the same logic as in other times or like with the
IFAT command which checks the result for you and lets you do events based on it.

In the case that it’s the second time, it just uses:

strb r1, [r3,#0x14] @ Otherwise, store the max stat into the offset of the current stat

to store the max strength into the offset of the current strength in the memory. The actual gold
subtraction will be done at the end.

It goes through all the other stats similarly, except for HP, the max is 60, and for luck, the max is 30, as
those do not vary between classes in this hack.

At the end of the check for the luck stat, we have

cmp r7, #0x00 @ If r7 is 0x00, i.e. this hasn't been done before

beq MoneyCheck @ Then see if there's enough money to actually make

the change

On our first time, this will be true, so we go to “MoneyCheck”. On our second time, it’ll go to End1,
which marks the result as true (so that I can use an event to have a different text output depending on
whether or not it was successful) and pop registers accordingly. (End2 is the same thing but marks the
output as false and occurs if you don’t have enough money to max all stats.)

Here, we do something like the gold requirement code before, where the gold required is in r6. We
check to see if we have enough and if not, we go to End2, marking the result as false/a failure, and if we
do, we go ahead and subtract the money and then set r7 to 0x01, so that this time when we go back
through the checks, it will actually make the stat changes.

Again, this isn’t the most efficient code, and it’s not even the most complex or fancy—I mean, you can’t
choose what stats to max, you can’t choose how many of them to max, the gold cost for east stat is a
constant, etc.—it’s simple, but for my intents and purposes, it works, and is fun enough for me. :P

With that, you are FINALLY freaking done with this part. Next up I will cover how to find routines and
how to debug. After that, I will have taught you practically everything I know, so we will be done!

Part 5: Finding ASM Routines & Basics of Using a Debugger

First, no$GBA debugger is essential to this section. Find it, download it, and use it. The password is
“veta” which it should say either on the download site or in the zip or something.

Now, this section will be much shorter than the others. Aside from my hand hurting a lot, I’m going to be
vague and just give general tips for some things.

There are a few tricks to finding routines. First is looking at doc. Most ASM hackers have doc and will use
offsets in them. Look at the offsets. For instance somewhere above I have a hack having to deal with the
critical damage. You could look around that offset in a debugger to see what’s around it and what’s
happening. That’s one way to find one. FYI, -I-found the offset by looking in Hextator’s doc, I believe. I
already mentioned the doc earlier, so I’ll stop here.

Next is using some hex editor tricks. Certain pointers can often be found embedded in the ASM. This is
nice because they’re things you can know/predict/find by other means. For example, you know the text
shown in the support conversation room in the extras menu of FE7 says “Select whose conversation you
want to read”, so you search part of that text as a string in FEditor Adv and find the text slot—0x0FC4.
Fun. Now search 0xC4 0x0F 0x00 0x00, the text ID as a word in little endian. You’ll find a match at
0x9B9B0 in a hex editor (keep in mind this would be referenced in ASM etc. as “0x0809B9B0”). As it
turns out, this is a somewhat simple case as no other instance of this string occurs in vanilla FE7 (though
technically I searched on a hacked ROM but it was only slightly hacked so… DETAILS). If you look at this
offset in a debugger, which I’ll explain how to do shortly, you can search for where exactly it loads that
word, 0x0000FC4, and then look around for clues as to what’s what. It helps give you a general idea of
where to look, at the very least.

Similarly, you can do such things with graphics offsets, palette offsets, and TSA offsets, which are often
embedded in ASM if they aren’t in tables. If they ARE in tables, you can sure as heck go search up the
tables, and the pointers for those will also be in the ASM. In general though, the less common
something is, the easier it is to find the routine you’re looking for—if you’re looking to hack character
abilities and go searching using the character table, you’ll probably have a harder search than normal
because the character table is referenced several times throughout the ASM, being a major data table
and all.
I used this to find some routines such as the ones that loaded certain palettes—then I expanded them so
that they only loaded certain palettes in certain chapters. Thus is the idea behind my “custom palette
for the post-game” hack which changes the general color scheme of the post-game to be purple and
some slightly obscure shade of blue as opposed to blue and red.

Now you need to know how to actually figure out what’s happening in the routines and how to decipher
them. Having practiced ASM as much as you have, you should have a good idea as to what most codes
do, and should even be familiar with some memory offsets. It’s also nice to keep lists of hex values in
store—if you’re trying to change the Nils portrait that appears in the support conversation room, which
is hardcoded via ASM, you’ll want to know his portrait is 0x41, so that you can look for something like
mov r1, #0x41, and then change that 41. (Just searching “41” in a hex editor probably won’t do you
much good since there will be too many instances of that, FYI.)

As it turns out I explained this before to somebody on an instant messenger (*glances towards that one
conversation I ACTUALLY dared to use in this tutorial*) so I have a poorly labeled image to help explain
things:

WARNING: TERMS MAY NOT BE ACCURATE. IN FACT, THEY ALMOST DEFINITELY AREN’T ACCURATE, AS
YOU’VE PROBABLY FIGURED OUT BY NOW.
- A is the assembly window, it has all the codes and will update to whatever offset it is running if
you play the game and then pause and check it out. More specifically, A is actually referencing
the offsets here, but it’s in the assembly window, so yeah…

- B is the opcode column. Right now it’s set to arm, so… yeah…

- To the left of C is the column of parameters. Again, it’ll be more obvious once we go into Thumb
mode, hopefully.

- D is no$GBA’s version of the memory viewer. It works practically the same—you can edit values
as you like. If you right-click it you can switch between the “data window” (memory viewer) and
the break/watch window (contains a list of breakpoints, which shall be explained later).

- E is the stack. If you remember the push/pop explanation, it like, stores stuff here… yeah, it’s
another one of those things I really don't understand it all too well but it IS useful sometimes.
Essentially, code sometimes pushes offsets while going through routines, so if you check the
stack, you can sometimes find useful offsets of pointers, and thus "trace" the routine to find out
where it loaded from (real hackers will probably say this is complete and utter bogus and
nothing like true “tracing”.)

- F contains all the registers and their values. Sadly, I don’t know what cpsr and spsr are though,
since I never had to learn… XP

- I don’t know what the flags do either, but they’re there, right next to the window. That’s G.

- H is the game window. The game can also pop-up on a separate window.

- For the buttons above I, the only ones I feel like explaining are Trace, Run Next, and Reload. The
rest are either self-explanatory, not very useful, you can figre out on your own, or a combination
of the above, AFAIK. Trace is very useful in that it lets you trace the routine. To me knowledge,
it’s almost exactly like Run Next, except if you encounter a “sub-routine” (a bl opcode which
branches elsewhere) it will actually follow to that code and keep going, whereas “run next” will
just run through the entire sub-routine automatically and then keep going from there, without
actually seeing what the sub-routine does. “Reload” just reloads the ROM, which is useful, and
can also be done with Ctrl+R.

Next, for the main menus to the top:

- Files – you can open files via filename or a special list file that I don’t bother to use, and also
reload recent ROMs. Snapshots are no$GBA’s versions of savestates, they’re slightly less
convenient I think, but they work alright. There’s a couple other things near the bottom idk
about and you can also quit (lulz).

- The search menu lets you search for strings, set bookmarks, find the next breakpoint, and some
other stuff, but the only thing I use and thus the only thing I can really tell you about is the Goto
 option—click on the assembly window or memory viewer/data window and hit ctrl+G, then type
in an offset in hex (remembering the “+0x08000000” if you’re trying to access the ROM!) and hit
“Ok” (or enter) to go there.

- Run – it’ll let you run around the code. Seriously I don’t know much about it except that there
are some shortcuts for the buttons. Maybe you can play around and update this tutorial once
you figure out what everything does.

- The debug menu is pretty useful, it’ll let you make, clear, and toggle breakpoints, and some
other stuff. I only ever really use it to clear all breakpoints though.

- The “window” menu has a lot of stuff like the VBA “tools” menu—it’s too much to go into but if
you’re familiar with VBA you should be able to figure most of it out on your own.

- “Utility” has more things I don’t use though taking screenshots is useful. I’m sure it CAN be
useful, I just don’t use it…

- “Options” menu has way too many options—fiddle around and get it to how you like. You may
want to turn the brightness up and check out some other stuff like the controls to start with. Be
sure to hit “Save Options” after your changes so that they save for the next time.

- “Help” menu just contains some basic help stuff, the typical stuff you’d expect from a help menu
in a program like this. XP

Okay. Now, the basic idea behind debugging is that you say “this area is suspicious: let’s stop the game
in this code and see what it does”. To stop it, you make a breakpoint: what I do is just click on the code I
want to set a breakpoint on and it turns red. To get rid of it, click on it again or use the debug menu to
clear all breakpoints.

As for where to set breakpoints—suspicious places, of course! I covered some tips on how to find
routines before.

Now, once you stop the game, you need to figure out what the heck it’s doing. If there are notes on the
routine already, it’s pretty helpful, but otherwise you need to use all your knowledge thus far on figuring
out what the numbers might mean. Knowing offsets and other such values can be REALLY useful—just
recognizing one byte can help you identify what one register holds, e.g. a character ID, and then you can
be like “oh, it’s multiplying the character ID by this to get this offset, and… oh!!!” or something like that.

Yeah, it’s very… difficult to explain as a science. It takes intuition. Thought. Trial and error. Playing
around. Research. Such skills are important to have and if you have them, you’ll get pretty far.

Anyhow, what you want to do once you find a routine is go through each code and see how each
opcode affects the registers. See what the heck it’s doing to not only the registers, but also the values in
the memory. If you see some offset in the memory that you don’t know about, try changing its values—
it might break the game, but you might also find out something interesting.
Of course, don’t neglect to use this on your own codes. I taught you the hard way first, but now that
you can debug your own code by going to the offset you put it at, you can check to see exactly what it’s
doing—and when it does something you don’t expect, you know exactly what opcode to blame. Check it
out, see how to fix it, fix it, re-insert it, and try again. Then you’ll really be using a “debugger” by, well,
getting rid of the bugs in your codes. It’s a pretty fitting name to call this thing a debugger, huh?

Wooh.

This may be my longest section in the tutorial.

With that, the ASM hacking tutorial is done.

I’ve more or less taught you everything I know. Okay, I haven’t taught you every little offset, every little
doc, or every little code. But that’s where YOUR work, YOUR effort comes in. If you’ve gotten this far,
you have the potential to succeed and do great things. Surpass me, to start—it’s not hard. I am not very
smart and I managed to get this far. Someone who IS smart can do much better. Hey, you can even write
a better tutorial than this long, confusing, vague one when you’re done.

Lastly, I have a little special request of you. I can’t force you to do anything, but I’d appreciate if you
shared the ASM hacks you made and any documentation you have. Sharing information and
knowledge with others, including hacks, will help the community grow. It will help other people learn
and prevent people from having to do the same work. Would you be able to make ASM hacks if others
hadn’t shared their doc? I learned almost purely by looking at others’ works and trial & error, so I know I
almost definitely wouldn’t. That’s why I took the time out to write this huge tutorial—so that the
information is out there for people to take and make their own.

Again, it’s just a request—you don’t have to, but it’s nice. It’d be nice to have a chain of sharing, where I
share my knowledge with some people, and they share their knowledge with some people, etc., because
if nothing else, some day it might come back that someone shares something with you again. =)

You have learned the most obscure and feared aspect of ROM Hacking for many people—something
many people wish they could learn, and something many others shudder to even think about or discuss.
You have something to be proud of, if nothing else.

Congratulations and best of luck in all your hacking endeavors, especially ASM hacking!

I hope to hear of your achievements in the near future!

Final Chapter: Credits, Thanks, and the Epilogue

This tutorial took quite a bit, but so did Fire Emblem hacking. Thus I’d like to thank people for all their
work and effort. Please note that my memory is vague as well as not all-inclusive. If you feel you
contributed a lot to the Fire Emblem hacking community and deserve to be here, just kindly contact me
(don’t flame and get pissed). If I said something incorrect, please do the same. And if I forgot you, as I
am quite forgetful, please do alert me as I want this to be a thorough list of people who deserve to be
here. However, I’m not going to include everything everyone has done (or this list would be at least a
dozen pages), but for major people, I will post their general accomplishments.

Major, Veteran Hackers:

Lute/Iggy – One of the original FE hackers who posted a page of data on FE hacking that got
Pukachi/SpyroDi to make Nightmare modules.

Pukachi/SpyroDi – One of the original FE hackers. She created the original set of modules and has
contributed in hacking games from FE4 to FE8, IIRC. An inspiration to others and the instigator of Fire
Emblem hacking.

Xeld/Zeld/Hextator – One of the original FE hackers. He started with assembly hacks and miscellaneous
stuff but eventually created FEditor Adv, one of the most used and best Fire Emblem hacking programs
out there, which is capable of editing text and portraits better than any other program, and is also
capable of importing battle animations in seconds, and making custom battle animations and spell
animations (the former would be really difficult without him—the latter would pretty much be
impossible without him). He’s also made several patches and in general has had a lot of
accomplishments throughout his hacking career.

Blazer/Fire Blazer/Keriku/Luffy/FireShrine – One of the original FE hackers. I’ve been doing it for a long,
long time, and I’ve helped lots of people with their questions and hacking. Whenever a new innovation
came out, I’d almost always be there to test it out, help find bugs/glitches, or expand on information,
write tutorials, etc… I helped Xeld and Nintenlord in the few ways I could (testing programs and
reporting glitches) and have done my best to make use of everyone’s programs and finds by making
hacks like Prince of Durand and Tactics Universe. I have a site dedicated to Fire Emblem with lots of
hacking information, as well as forums with many hackers who can help out, and I am a member on
most Fire Emblem forums. With this tutorial I hope that I have left hackers with most everything they
need to make a hack on par with or better than my own hacks—not to be arrogant, but people have a
hard time making use of things unless they know how, and I was often times one of the few people who
knew how to do something (events, insert music, battle and spell animations, etc…). This tutorial is also
to remedy that as I shouldn’t be the only one able to make full use of the knowledge out there that
simply hasn’t been put in an easy-enough fashion for people who can’t figure everything out on their
own. The reason why this paragraph is so long is because I made this tutorial, so of course I have to say a
lot about myself. And there’s no way this paragraph could not sound egotistical and narcissistic no
matter how I phrased it, if you ask me. =D
Flyingace24 – an inspirational hacker who has helped the community in ways most people don’t know.
Has made nightmare modules and helped other hackers with their projects. He’s also one of the original
FE hackers and one of my long time friends.

Arch – a veteran hacker who has lived through a lot of the changes in the FE hacking community. He was
the driving force of the forums that were once renowned as the best Fire Emblem hacking forums, Fire
Emblem Universe. Arch is also the creator of extremely popular hacks such as Elibian Nights and Fire
Emblem 4 Advance (now discontinued).

Raydonn – a hacker whose name was a bit lost. He made use of information given by people to make
Nightmare Modules and do other stuff. If you’ve hacked with Nightmare, you’ve most likely used one of
his Nightmare Modules.

Icy Toast – he helped re-spark the FE hacking community, to some extent. Icy Toast made a
revolutionary tutorial on how to insert custom maps and make your own events, amongst other stuff.
This inspired me to try it out and I made a hack that I think got Nintenlord into Fire Emblem hacking—
the reason why I say this is because I still have a PM from Nintenlord on youtube from years ago.
Anyway, he has also contributed Nightmare Modules and his tutorials are still referenced today, even
though there are programs that have made the things done in his tutorials much easier. I still miss Icy
Toast to this day. 

Nintenlord – One of my favorite Fire Emblem hackers. Even if you aren’t too into meeting nice people, if
you like smart, helpful, and unselfish people, Nintenlord is the guy. He’s made many programs like GBA
Graphics Editor and the MAR Array Inserter that have helped tremendously with Fire Emblem hacking.
He also has many Nightmare Modules he has made and many ASM hacks that give cool effects (like the
move-after-attacking skill in FE10, for instance). He also made the Event Assembler, which is just
another one of his awesome creations. I consider Nintenlord a good friend. :D

Honorable Mentions:

Zahlman – has helped a lot with improving FEditor Adv and has also made a Song Editor for music
insertion. Is continuously making efforts to improve hacking amongst other stuff.

Shadowofchaos – although not the oldest hacker and doesn’t have a full-fledged hack of his own, he has
taken the initiative to make use of programs like FEditor Adv to make battle animations, spell
animations, insert music, import music, and has recently even done ASM hacks and other useful fixes for
the community. He always likes learning new things, whatever that may be, and is a great help to people
and their hacks when they need something done that they themselves cannot do on their own.

FurryYunSeong – a veteran Fire Emblem hacker who has made GhebFE and GhebSaga. Although his
hacks are joke hacks, he knows how to hack, and has been one of the (unfortunately few) successful
hackers around the community. He appears to have retired from hacking, however.
MageKnight404 – although he has never directly contributed anything to hacking innovation, he has
inspired others to try out hacking, and the more people the better. He’s also made some popular
hacks—one being called “MK404’s FE7 Hack”, and the other being “Fire Emblem: A Sacred Dawn”.

More Honorable Mentions:

(In no particular order, as I remember them)

Celice
VincentASM
Ryrumeli
Felover3
Kate
Atrius
CharontheFerryman
Camus the Dark Knight
Twilkitri
Mariobro3828
Mercenary/Rutger
SandwichSage
MageGirl
CrypticGirl
Markyjoe1990
Seph1212
Creators of all the many programs
Creators of all the many patches

Epilogue:

I hope I’ve helped you a lot with your Fire Emblem hacking. I’ve spent a lot of time on this tutorial and
it’d be a shame if it wasn’t even used well, right?

With that being said, I have some favors to ask. First of all, there’s a large list of people in the credits. I’m
not going to ask you to credit every single one of them just for being a decent part of the Fire Emblem
hacking community. However, if you make a hack, you should probably credit the major hackers (and
not just because I am there >_>) because it’s almost unavoidable that they have some sort of impact—
whether direct or indirect—on your game. Especially people like Pukachi, Xeld, and Nintenlord, who
have spent so many hours unselfishly working to help others with their hacking (and you’re bound to
use one of their programs or modules). Just saying “thanks” isn’t much, but it’s a good thought.

Also, please don’t upload this tutorial to other sites without permission. If you need to share it, you can
always link to my site or the online version of the Ultimate Tutorial so that people can download the
latest version and older versions aren’t uploaded and spread about. I simply cannot keep version control
of the Ultimate Tutorial everywhere, which is why it’s nice to have one place where people can always
find various links to various formats of the latest version, and I’d like to keep it this way. Furthermore,
please notify me of where said links (which I do encourage you to post around) are posted so that I can
keep things up to date as much as I can regardless and answer anything related to the Ultimate Tutorial.

If this has done you any good, let me know, because I like knowing when I help others. I’m just that kind
of guy (and I’m not a narcissist…). I’m looking forward to some epic hacks to play when I myself “retire”,
and I really hope that the Ultimate Tutorial will help make those hacks epic, and come fast!

For everything… thank you!

~FIN