FE5 Tidbits

Somewhat related, there’s also a unique sorcerer in chapter 24 who is able to use the Thief staff, despite not having one. If you reverse-steal it into his inventory, he’ll start using it on you, which is pretty funny.

Not to be confused with the sorcerer that can use the Unlock staff in the same chapter and actually spawns with it.


Any idea what causes this weird behaviour?

Off the top of my head, nope. I’ll try digging around if I get the chance, but no promises.

So, FE5 had a mostly-functional guide menu, similar to FE8’s. It still exists but is normally unreachable. You can check out a write-up and translation by the wonderful bookofholsety here.


Always cool to see features that developers pulled from games. Good find.

1 Like

Ready for a long explaination on why FE5s AI is dumb and does that? Here we go…
First things first: The game determines who to target based on their current HP stat and the one with the most HP gets targeted as long as they meet 3 other requitements (explained a bit below). Leif is a special case where his current HP is treated as 1 since it just skips part of the routine and saves his deployment slot (which is always 1) over it. In addition to the HP the game also checks if the unit has a higher magic stat, if the target already has a status (in which case the next target gets chosen instead) and if the target has the Immortality skill. If all checks are met, the enemy casts their status staff.

The main issue llies within the allegiance check though. It loads in the first unit of each allegiance and checks if the current selected unit can target that allegiance. Enemy using berserk on a player unit? All fine. Enemy using berserk on another enemy? Don’t do that… unless the first unit of the allegiance is berserked…
The first unit that gets loaded in the final chapter turns out to be the sorcerer in the bottom middle. So berserking that one makes enemies target players… and enemies as well since it only checks the first deployment slot and not the unit using Berkserk.

Another fun example:
Berserking this sorcerer in Ch24 while keeping him away from other sorcerers (so he doesn’t get poisoned by their Jörmungandrs, overwriting his berserked status)…

…leads to the Silence staff sorcerer to silence one of his allies…

…and also the Sleep staff sorcerer to sleep Galzus, making him unable to be recruited.

TLDR: FE5 dumb.


Aka. Another mission for the hackermen: Turning FE5 AI into literally anything that ain’t FE5 AI.

Time to learn a bit about the SNES along with FE5. The next batch of these will probably all be about things that happen in FE5 on booting up.

Certain SNES games have “fast” ROM chips in them that can be accessed at 3.58MHz instead of 2.68MHz. To do so, these games have to set a bit in an I/O register while running, which is called MEMSEL. This seems like something you’d only like to do once at startup unless you’re running some weird hardware with different access timings.

We’ll get back to that in a moment. We need to talk a bit about I/O registers. An I/O register is a way for the CPU to interact with other bits of hardware such as the picture processing unit (PPU), audio processing unit (APU), etc. These registers are implemented as places in RAM that the CPU can write to and read from.

It can be advantageous to keep a buffered copy of these I/O registers before they are actually written to. This buffer is copied to the I/O registers once per frame. The buffer is typically easier to write to/read from than the actual registers, thanks to quirks such as some I/O registers being read/write only or having sizes that are different from the data being fed to them, such as a 9-bit value being fed a byte at a time.

Some registers need to be written to immediately, so that typically happens at the same time as writing to the buffer. The buffer mostly serves as a way to keep track of what value the register holds, in the case of a write-only register.

It should be noted that not all I/O registers are buffered. Also, there are quite a lot of I/O registers that the SNES has, and they’re quite the pain.

Alright, back to MEMSEL. FE5 keeps track of MEMSEL in the I/O buffer as one of the registers that get a spot in the buffer because they’re read-only. If you’ve got a turbo button, you probably want it to activate immediately on being pressed, right?

There’s no reason for FE5 to ever change ROM access speed, however, and it never messes with it from what I can tell. MEMSEL being buffered is probably the result of IntSys reusing code from other projects.


Goku going Super Saiyan for the first time vs Frieza, 1995, 16-bit color.


So, FE4 was originally going to be called Holy Sword Elm Kaiser according to Masahiro Higuchi, who was a graphic designer at Intelligent Systems at the time. You can read about that here.

Although that name didn’t stick around and the project eventually became another Fire Emblem game, references to the old name still exist within both FE4 and FE5. FE4’s sound engine is labeled ELM SND1960327W internally. FE5’s is labeled FE5 SND19907074, though. We’re getting off-track, oops.

The common reference to the old title between the two games occurs during their boot sequences. When the games start up successfully* they write a short string right before the stack (oh, uh, the stack is a part of memory used by the CPU for temporarily storing return addresses during subroutine calls and register contents. A register is…). That string reads ELM0.

Also during startup, the games check to see if ELM0 is already written to RAM. If it is, the game has been reset by software and we skip checking for bad things*.

I like to call FE4 and FE5’s engine the ELM0 Engine because of tthis.

*FE5 (and FE4) can fail to start up. We’ll cover that in another tidbit.


Well that explains why I sometimes found ELM0 in ram when poking around.


So, what does it look like when FE5 (and FE4) fail to start up? Both games have two different screens that appear: an oops, something went wrong screen where the games assume that nothing malicious is going on and a you're a dirty pirate screen where they full-on accuse you of copying cartridges.

FE5_Disassembly-20210219-111337 FE5_Disassembly-20210219-111355

The first time the games fail to start up, the first screen is shown and the game locks up. A flag is written to your save file indicating that the last boot sequence failed. If you reset and the boot sequence fails again, you’ll be shown the second screen. If the games boot up successfully, the flag will be cleared and they’ll have to fail another two times in a row for you to see the antipiracy screen again.

I’ve seen these exact screens used for other games, although exactly which games escapes me at the moment. There are also games that use the same startup antipiracy detection techniques, such as Donkey Kong County 2 (albeit with different message screens). Check out the game’s tcrf section for more info, although this is exactly what I’ll be covering in a later tidbit.

Bonus: FE3’s antipiracy screen has a fun typo:



Enemies gaining Wexp in FE5 actually can matter, as Tina can feasibly use the Thief staff 5 times in her joining chapter, which will elevate her staff rank to D.


The following isn’t fully understood. Please forgive me for any mistakes.

To thwart pirates, the games use a checksum to ensure that the antipiracy checking part of the reset routine hasn’t been modified. They calculate the actual checksum of the routine and compare it to the known, valid checksum somewhere else in the ROM. There’s also a toggle in the ROM to disable the checksum checking, probably used until the positions of things are finalized. If the checksums don’t match, you’re a pirate.

When an irregularity or pirate is detected, some code is written to RAM before your save is flagged as suspicious. The presence of this code in RAM is also checked for, but unfortunately it’s written to the same place that FE5 keeps a buffer for sprites onscreen (dunno about FE4, though) so it gets overwritten and ends up useless.

This code is the real interesting bit, though. It contains another checksum calculation for the reset code, as before, but also does a checksum calculation for the other checksum calculator mentioned previously. It also goes and checks to see if you’re a sly fox who went and edited the known checksum values in the ROM.

This top-notch level of security is why nobody has ever pirated or hacked an SNES game. Nobody with the technical skill to modify any of this stuff could also modify this checksum-checker checker.

I’ve also not seen anything that actually jumps to this code, so, y’know.

Oh, there’s also another copy of this code in FE5, and I haven’t seen that used, either.


Alright, now that we’ve gone through all of that other boot sequence stuff, let’s talk about the bulk of the antipiracy checks.

First, we need to start with some basic stuff about the SNES itself. The SNES’s CPUis based on the WDC 65816, a 8/16-bit progression of the 65xx family of processors. The 65816 requires that a set of pointers to critical routines be placed at a fixed spot in memory. These routines are for important tasks called interrupts, and includes handling resets, breakpoints, communication with coprocessors, V-blank, and more.

For the SNES, these pointers are part of the cartridge header. Someone who wanted to change how the game started up, for instance, could change the reset pointer to point to some routine they had written themselves.

Naturally, changing that is something a pirate would do, and FE5 calls you out for it.

The game loops through RAM on startup, checking for instructions that jump to the reset routine or reference the reset pointer. Finding a jump will trigger the irregularity/antipiracy screen.

It also checks to see if there’s a stable sequence of 0x60…0x81 in RAM. Not sure what that’s about, maybe some kind of known cartridge copier/pirate thing?


This is one of my favorites.

Both FE4 and FE5 contain the mysterious string “1996/01/10 05:29 by manchan ” right before some map battle animation code used for things like staves. If I had to guess who at IntSys this is (was?), it’d be Manabu Shimada, who is credited as a programmer in FE4. They don’t appear in FE5’s credits and there isn’t anyone else with man in their name, sadly.

It appears that they also did other programming work at IntSys, with a file copying tool of theirs directing bug reports to manchan@intsys.co.jp (obviously please don’t try to spam this email or anything, thanks.)

(picture credit: @MisakaMikoto on the FEU Discord, 2019)


praise manchan


Zane just doxxed manchan. Damn.


If manchan is so great, where is womanchan?

1 Like

FE5 has two characters that are exclusive to each other: Olwen and Ilios. The game makes use of this fact to perform a space-saving optimization.

When you recruit Ilios, FE5 clears Olwen’s battles/losses and uses that space for Ilios’s. This saves two bytes of SRAM per save file. Wow!


Do those 2 bytes even matter that much?