Starfox Adventures ZLB?

[KCat]

Does anyone have any info on this? Looking through my Starfox Adventures ROM, there's several files that have a .zlb extension, and have one or more ZLB markers/headers in the files (some only have a .bin extension instead of .zlb). I've been googling for information related to this for a couple days, and it's been mostly fruitless so far.

At first, I thought it migh t've been some kind of packfile/compression marker. After googling for a bit, I found that ZBL is short for Zero-Length Body, which is basically a control packet with an empty L2PT header. After looking over the specs though, it doesn't seem to be valid as the "version" is set to 0, and the specs say it must be 2. It also says a ZLB is a control packet, yet the control bit is off.



Scoping out the data reveals that each of these ZLB "blocks" starts with:
"ZLB\0" (the letters Z, L, B, and a NULL byte) 0x00 0x00 0x00 0x01

From here, things start getting funky. According to this output, the further along you follow the data, the more likely it is to not be identical. Early on, it appears to be uniform and patterned in some way. About 16 bytes out, it appears mostly "random", however, some blocks remain identical for several more bytes (and by several, I mean around 32 more bytes or so). I see nothing indicating the length of these headers, or how to decode the individual blocks.

At this point, I have no real idea of where to go to figuring out this format. If anyone has any clues or information about what this might be, I'd love to hear.

[ShizZy]

Sounds like some sort of archive format, but I could be wrong.

[KCat]

Doesn't seem very likely. This one file (called TEX0.bin) has 225 "blocks", and the average length is 616 bytes per. The longest one is about 3,132 bytes long (both including the possible header). If these are textures, they'd have to be awefully small.

[ShizZy]

Compression?

[KCat]

Rather likely, since some of the files with a .zlb extension and can have only one ZLB block. It'd have to be a generic form though, since this is used quite a bit. I thought it might be zlib compression (zlb, zlib..), but I wouldn't know how to try to decode it as such.

[ShizZy]

Probably some variation of LZMA, like yaz0.

[KCat]

Interesting possiblity. Though I wouldn't even know how to start trying to decode it without knowing what the decoded data is supposed to look like.

[thakis]

First four bytes are 'ZLB\0', next four probably block version (always 0 0 0 1?), then four bytes which are probably the size of the block if uncompressed, then four bytes which are the size of the block as-is (it's compressed 99% sure), then that many bytes follow (the block data). The block is padded with zeros to a 32byte boundary, then the next block starts.

Probably zlib compression, but might be something different.

This is very interesting...

ps: data that looks "random" is most certainly compressed in general.

[KCat]

Here's two examples of what I've been able to decipher. The first is taken from a file called TEX0.bin, and the other from TEX1.bin:

ZLB found at 0000:0000 (1)
- 00 00 00 01 (1)
- 00 00 01 00 (256)
- 00 00 00 6d (109)
- 58 85 63 60 (1485136736)
* -1 extra bytes at EOB!

ZLB found at 0000:0000 (1)
- 00 00 00 01 (1)
- 00 00 01 00 (256)
- 00 00 00 6d (109)
- 58 85 63 60 (1485136736)
* 22143 extra bytes at EOB!

The ZLB block is not always at a 32-byte boundary. I find ZLB blocks starting at offsets: 0000:11b4, 000:3ecc (these are just two examples, there's more blocks that start on 4 and 12 byte boundaries). Could be a 4-byte boundary.

The next is always a big-endian 32-bit integer 1. At first, I thought the next appeared to be the uncompressed size of the block and the following 4 bytes might be the compressed size, but testing shows that the number sometimes over-shoots the beginning of the next block, or can be too short.

PS: they are not always 256 and 109, but it's interesting that two different files start out identical, except the second file's first block simply has a lot more bytes on it before the second ZLB block starts. After that, they don't seem to match up as well. The second file is, overall, much bigger than the first.

The following two bytes are always 0x58 0x85. Sometimes you can see a small pattern between blocks from this point , but the "farther out" into the block that you go, the less of a pattern you can find.

I'm not quite sure what this board's policy is about posting select files from a game, but I'd go on the side of caution and assume it's not allowed. If any of you happen to have the game and can get at those files though, I attached the source for the program I'm currently using to "read" the blocks.

[thakis]

ZLB blocks don't always start on 32byte boundaries, but they seem to be always padded to a 32byte boundary (if you start counting at the "Z" of ZLB).