DAT Format (Zool)

From ModdingWiki
Jump to: navigation, search
DAT Format (Zool)
Format typeArchive
Max filesUnlimited
File Allocation Table (FAT)Beginning
Filenames?Yes, 8
Supports compression?Yes
Supports encryption?No
Supports subdirectories?No
Hidden data?No

The Zool DAT Format is used by Zool for storing game data. Data is stored in chunks of 512 bytes.

As the offset of the last chunk is stored in a UINT16LE field, its maximum value is 65,535. Multiplied by the 512-byte chunk length, this yields a maximum DAT size of 33,553,920 bytes (512 bytes less than 32MB.)

File format


There is no signature, and the fields must be checked to correctly detect files. Since the first two bytes multiplied by 512 must equal the size of the DAT file, this is one good check.


The header is very simple.

Data type Name Description
UINT16LE len Length of DAT file, in units of 512 bytes.

This value is multiplied by 512 to give the size of the DAT file, which is also used as the offset of the end of the last file in the archive.

File entry

The header is followed by one or more file entries in the following structure.

Data type Name Description
char[8] filename Filename, padded with spaces (char 0x20), not null-terminated.
UINT16LE len Offset of file, in units of 512 bytes.

The list of file entries takes up a minimum of 512 bytes, and if more files are needed, space is allocated in chunks of 512 bytes.

The file's size must be calculated from the offset of the following file.

This structure is repeated until the first byte in filename is 0. This immediately terminates the structure and the rest of the filename and the length are not present. (However as the FAT is padded to chunks of 512 bytes, there will always be enough bytes available in the padding data to read the full field.)

In the event that 51 files are present, the last valid file entry will end exactly on a 512 byte boundary. This will cause the FAT to be extended by 512 bytes, simply to store the terminating null (with 511 bytes of padding.) This does not require any special handling when reading the archive, but is mentioned to illustrate the importance of the terminating null byte.

Extra data

Since both the FAT and each file are padded to occupy a multiple of 512 bytes, there is unused data at the end of most files. This is especially noticeable in the FAT itself, which seems to contain old high score data leftover from the game's development.

The padding data found in later files does not seem to be compressed, suggesting that decompression happens outside the archive format.


The following tools are able to work with files in this format.

Name PlatformExtract files? Decompress on extract? Create new? Modify? Compress on insert? Access hidden data? Edit metadata? Notes
Camoto Linux/WindowsYesNoYesYesNoN/AN/A


This file format was reverse engineered by Malvineous. If you find this information helpful in a project you're working on, please give credit where credit is due. (A link back to this wiki would be nice too!)