The Tape Image file formats
TAP and TZX files store images of Sinclair Spectrum tapes. Because the Spectrum stored it’s data by outputting pulses of sound to an audio device, emulators originally used wave recordings which recreated the sounds on the tape. Later, the .tap format came along. It was found that the format of these sounds matched identically with the bits of bytes being saved, and that when a certain section of the Spectrum ROM was entered, you could discover exactly what was being saved and what was being loaded. To this end, the .tap format stored a copy of each block of memory saved by the ROM. This has the advantage of being a lot smaller than a corresponding wave-sound file.
Each file on a tape comes, most usually, in two parts. The “header” gives information to the Spectrum about the file that is coming from the tape, such as the name, the type of data (a program, a memory block or a variable) and the size of the data. Following this header is the main body of the file.
Note: It is worth mentioning that BASin treats each header and body pair as a single file, unless the data has no header in which case it is flagged as “headerless”.
Because the data saved to the tape image is a direct copy of the bytes saved, it is trivial to just “inject” the data back to memory – after all, the header provides information about where it came from originally. Unfortunately, the .tap format cannot reproduce the sounds made by the newer, faster loaders employed by games companies in their nigh-on constant fight to get quicker load times and prevent software piracy. The .tzx format, however, can reproduce any sound the Spectrum can produce. The .tzx format, as far as BASin is concerned, is very similar to the .tap format – it just adds a couple of extra bytes to the blocks with some more detailed information about it.
The .TAP File format
For the technically minded, the .tap format for a block is as follows:
Byte offset |
Contents |
0..1 |
Length of the block |
2 |
Flag byte (0 for a header, 255 for the body of the file) |
3..xx |
These bytes are the data of the block itself - either the header or the main body |
Last Byte |
Checksum Byte |
The .TZX File format
The .tzx equivalent is as follows:
Byte offset |
Contents |
0 |
ID Byte (16 for a ROM-Saved block) |
1..2 |
The length of the pause after this block in milliseconds (1000ms default) |
3..4 |
Length of the block |
5 |
Flag byte (0 for a header, 255 for the body of the file) |
6..xx |
These bytes are the data of the block itself - either the header or the main body |
Last Byte |
Checksum Byte |
The header format is similar to that employed by
.bsc and .bsd files, as follows:Byte offset |
Program |
Number Var |
String Var |
Memory Block |
Notes |
0 |
0 |
1 |
2 |
3 |
Data Type |
1..10 |
Filename |
Filename |
Filename |
Filename |
10 Characters |
11..12 |
Length |
Length |
Length |
Length |
|
13..14 |
Auto Start |
Variable a..z |
Variable a..z |
Start Address |
Various |
15..16 |
Program Length |
Unused |
Unused |
Unused |
Note that the Number and String variable types have their “name” from A to Z stored in one byte – the high byte at position 14, and do not use the byte at position 13. Programs store their length twice – once for the whole block and once for just the BASIC text, without the variables.