SSP Format
Format type | Archive |
---|---|
Max files | 200 |
File Allocation Table (FAT) | Beginning |
Filenames? | Yes, 8.3 |
Metadata? | None |
Supports compression? | No |
Supports encryption? | No |
Supports subdirectories? | No |
Hidden data? | Yes |
Games |
The SSP Format is how most files in the game Space Chase by Safari Software are stored. Different versions of the game may use different versions of this format, and the earliest known demo version does not use this format at all.
Files that the game expects to find inside the SSP archive must be stored in that archive. The game does not appear to support external files as an alternative.
File format
Signature
There is no known signature for this format. And to make things worse, there are at least three known versions of the SSP format. And not one of them stores a version number (or anything similar) to identify which version of the format is used.
The only thing that all (known) versions of this format have in common is that they all start with a UINT16LE that defines how many file entries are used in this file. This value is followed directly by an array of UINT32LE values that store the size of each file.
This information can be used to calculate the total size of the File Allocation Table (FAT), assuming that the SSP archive has no unused bytes at the end of the file or between the files, and also assuming that there are no overlapping files. Simply sum up the size values of all the used file entries and subtract the sum from the total size of the SSP file.
Based on the size of the FAT, you can read the actual file entries as described below.
FAT Structure
All known files in the SSP format use the following layout:
Type | Name | Description |
---|---|---|
UINT16LE | iCount | Number of file entries used |
UINT32LE[] | iSizes | Size of each sub-file |
CHAR[][] | cNames | NULL-terminated name of each sub-file (fixed-length entries, usually padded with NULLs) |
BYTE[] | padding1 | usually NULLs |
UINT32LE[] | iOffsets | Offset of each sub-file (relative to the beginning of the sub-file data!) |
BYTE[] | padding2 | usually NULLs |
BYTE[] | data | Beginning of the sub-file data |
The number of file entries in each array, the length of the file names, and the length of the padding in between the blocks of data varies depending on the version of the game. Known versions of the SSP format are as follows:
FAT size | Max. Entries | Names Start | Name Length | Offsets Start | Description |
---|---|---|---|---|---|
9478 | 128 | 514 | 64 | 8834 | used in v4.00 of Episode 1 |
2334 | 100 | 402 | 13 | 1802 | used in v2.14D of Episode 1 |
4534 | 200 | 802 | 13 | 3602 | used in v2.00D and v2.02D of Episode 1 |
The FAT size is also the offset of the beginning of the sub-file data. This value needs to be added to each value in the iOffsets array to get the actual offset within the SSP file.
Safety Checks
- The number of used file entries should not exceed the maximum allowed by the current version of the SSP format. More than 200 file entries are not allowed in any known version of the format.
- Offset and Size of any used file entry should never exceed the size of the SSP file minus the FAT size.
While the following is true for all known archives that shipped with the games, these restrictions are not part of the file format per se. The the game will most likely still be able to read these files even if the following conditions are not met.
- The data for the sub-files is usually stored in the same order as the entries in the FAT, so all used entries in the iOffsets array should be in ascending order.
- Unused entries, as well as the padding between the blocks, are usually set to NULLs.
- File names should fit the 8.3 naming scheme.
Tools
The following tools are able to work with this game.
Name | Platform | Group/archives | Levels | Graphics | Music | Sounds | Text | Saves | .exe patch | Notes |
---|---|---|---|---|---|---|---|---|---|---|
SSP extractor | Win32 | Extract | No | No | No | No | No | No | No | |
Stormer | Win32 | Extract | No | No | No | No | No | No | No |