[ASM & Hex] End of table markers

[MegaMetapod]

So, just starting in this hacking show and have a few HEX doubts. I have seen that there are a few things that end with the "FF FF FF" marker, so:

1. Why does this happen only with a few of them? Why not add markers in all tables? It would be easier to identify the number of elements in such tables.

2. Is "FF FF FF" used in all cases? Are bytes different than FF ever used to mark similar no-data marks?

3. Does Gen 4 DS games work the same? FF as empty byte, "FF FF FF" as end of some tables? (I am still wondering if I should look into Gen3 or Gen4 games)

Now, about pointers:

4. When you need to repoint a table you look around the file for ZZ YY XX 08 and replace them, get it. Is this risky? I mean, can you accidentally change a ZZ YY XX 08 value that is not a pointer but actual data that just happens to look like a pointer? If so, how can we avoid mistakenly confusing data with pointers and changing the wrong bytes?


Thanks,

 

[Blah]

They should use 00 00 00 00 for the table end instead of 0xFFs. My old routines are guilty of this, and the reason they should be 00s is because Free space finding algorithms in tools search flag 0xFFs as free space. As for DS games, they should work the same for free space in hex, yes. the FFs are just representing the highest byte value possible.

As for your other question about distinguishing pointers for data, the best way is to check cross references and if your "pointer" is in the middle of a function or similar. I think a hex editor in conjunction with a disassembler will show you this, otherwise a program like IDA can help you with cross referencing.

 

[MegaMetapod]

They should use 00 00 00 00 for the table end instead of 0xFFs. My old routines are guilty of this, and the reason they should be 00s is because Free space finding algorithms in tools search flag 0xFFs as free space. As for DS games, they should work the same for free space in hex, yes. the FFs are just representing the highest byte value possible.

Wouldn't that be conflicting with some tables? I have not been here for long but I think that, for example, the move table has entries with 00s that could be challenging if 00 00 00 00 is the end sequence there.

 

[Buffel Saft]

The DS games tend to store most of their tables in individual archives, so there's no need for a byte to signify the end of a table; the header of each archive includes the number of entries in it. There's no need to repoint tables, you just expand the archive (and maybe mess with some code elsewhere if needed) instead, them insert it back into the ROM and rebuild it. FF bytes are still used to terminate each entry, though.
The only exceptions are things like mart data, which are found in one of the games overlay or arm9 files. From what I've seen these work exactly like the GBA tables.

 

[Blah]

Wouldn't that be conflicting with some tables? I have not been here for long but I think that, for example, the move table has entries with 00s that could be challenging if 00 00 00 00 is the end sequence there.

No, so the 00s signify NULL in these examples. How the values in these tables are read and used are completely at the discretion of functions reading the, tables. However, all modern tools which search for free space flag 0xFF, so it is unwise to use that, and instead better is to use 00s. You could use the ASM NOP as well, but 00s suffice to appease any poor soul reading a table in hex.