FM Fusion Table description

The fusion table is stored from 0xB87800 to 0xB977FF inclusive in the WA_MRG.MRG, and that includes the small bit of spare room vanilla FM has at the end (which it just pads with EE bytes). There are six more copies of the fusion table, each 0x75800 bytes along from one another, making seven total copies for the seven fields.

To use the example of vanilla FM, the rough structure of the fusion table is

001 fusions:
    EMPTY
002 fusions: (223 fusions)
    008 -> 638
    009 -> 470
    ...
    649 -> 551
003 fusions: (10 fusions)
    004 -> 031
    ...
    603 -> 031
004 fusions: (310 fusions)
    006 -> 031
    ...
    719 -> 039

and so on.

(As an aside, note that the fusion x + y -> z is only stored under x's subtable, where x <= y. Storing it under y's subtable is just a waste of memory.)

The bulk of the fusion table is just these subtables laid out consecutively in memory. The exceptions are the EE padding at the end, and the first 1446 bytes.

The first 1446 bytes provide offsets to the start of all of the subtables. The first two bytes are the offset for card 000 (so 0x0000), the next is for card 001, the next is for card 002, and so on. These two-byte numbers are stored in little endian, so for example 002's offset is 0x05A6, which is stored as A6 05.

Since the 'offset header' is always 1446 bytes, you can just figure it out after figuring out the layout of the rest of the table.

One trick by the game should be noted here: if a subtable is empty (like BEWD's in vanilla FM), then the offset is just 0x0000, and this tells the game there are no fusions. In this case, the subtable in the list of tables takes up no memory, so 002's offset is just 1446 = 0x05A6.

With that said, all that's left is to describe the structure of the subtables. The subtable starts by giving the number of fusions in the subtable. If this is <= 255, then it's just the first byte. However, if this is > 255 but <= 511, then it stores this number in two bytes, but not in the obvious way. Instead, the first byte is 00, and the second byte is 511 - N, where N is the number of fusions. E.g., for Baby Dragon, N = 310, so the start of its subtable is 00 C9, since 511 - 310 = 201 = 0xC9. FM never attempts to have a subtable of size > 511 (I think Baby Dragon was the biggest), so you probably shouldn't either.

The rest of the subtable can be thought of as a list of pairs, but packed efficiently. A card ID needs 10 bits to be specified, and 4 x 10 = a whole number of bytes, so the game takes two fusions and packs them together (we'll come to the case of 1 left over fusion shortly).

It'll be easiest to explain by example. For 002, the first two pairs are (008, 638) and (009, 470). In hex, this is (0x0008, 0x027E) and (0x0009, 0x01D6). If we look at the table in the hex editor, we see the first 5 bytes (after the number of fusions in the subtable) are 48 08 7E 09 D6. It's easy to see where the last four of these five bytes come from, they're just the less significant byte of the four card IDs.

The 48 is just the two spare bits of each ID packed together. To explain, the spare bits for the four cards are 00, 10, 00, 01 in order, and 48 in binary is 01 00 10 00, which is just the four pairs of spare bits in reverse.

The only thing left to explain is if we have an odd number of fusions in a subtable, so after repeating the above we're left with the job of dealing with one fusion. In this case, the game will pack the fusion in three bytes. It's the same procedure, with the spare bits of the two IDs going in the same place in the first byte. However, the game just doesn't pad out the fusion table with 00 00. For example, the last fusion in 002's subtable, 649 -> 551, gets stored as 0A 89 27.

One last note, the game's code doesn't handle the case of an odd number of fusions, it just blindly scans the subtable in twos. So sometimes the start of the next subtable gets read as an extra fusion that the game can end up trying to execute, and that's where glitch fusions come from. As I see it, you have four main ways of trying to deal with this:
1. Ignore it.
2. Pad all subtables of odd size with a 00 00 at the end. This will work but may cost more memory than you'd like.
3. Carefully check the resulting table to see where glitch fusions can actually crop up, and only put 00 00 at the end of those situations.
4. Just figure out all the resulting glitch fusions (there will usually not be many, vanilla FM only has 15) and add them to your log.