A8CAS - software for reading/writing Atari 8-bit cassettes

The file in CAS format is composed of chunks, each having a common structure - an 8-byte header and some data. Each chunk consists of:

So, each chunk has size chunk_length+8 bytes.

All numeric values stored in a CAS file are little-endian.

There are several possible chunk types, each identified by a 4-letter string. Those are:

A CAS file must begin with a FUJI chunk. This chunk holds the tape's description (as an UTF-8 string) in data. The chunk_length field holds the description's length. The description may be empty - then the chunk_length is 0.

A CAS file may contain more FUJI chunks - they can be used to label different parts of a tape, such as separate files recorded one after another. However the current version of liba8cas ignores all but the first FUJI chunk.

A baud chunk holds the baudrate of the following data chunks (until a next baud chunk). The chunk's length is always 0 (+8 bytes of the header), and the baudrate is stored in the baudrate field. If no baud chunk is encountered before a data chunk, its baudrate is set to the default value of 600.

A data chunk contains a standard tape record as read or written by Atari's SIO. Those records normally have a length of 132 bytes, start with two 0x55 bytes, and end with a checksum byte - however those are not necessary. The record's baudrate is the baudrate stored in the previous baud chunk (if no baud chunk has been encountered yet, a standard baudrate of 600 is assumed).

The irg_length field holds length of an Inter-Record Gap (IRG) before this chunk, in milliseconds. The chunk_length field contains number of bytes in the record. data contains all the record's bytes.

An fsk  chunk holds a raw sequence of lengths of FSK signals (0s and 1s). It is needed to store special signals written on a tape, or any data that could not be recognised as a standard tape record.

The irg_length field holds length of an Inter-Record Gap (IRG) before this chunk, in milliseconds. The data field consists of chunk_length/2 16-bit unsigned numbers (LSB first) - each number represents length of a single signal (0 or 1) in 1/10's of milliseconds.

Example: the sequence 0x66 73 6b 20 0a 00 11 01 00 01 10 01 80 00 20 00 80 02 is an fsk  block that means:

A pwms chunk has similar meaning for turbo transmission as a baud chunk for normal SIO transmission. It defines parameters for decoding all subsequent pwmc, pwmd and pwml chunks (until a next pwms chunk). The chunk's length is always 2 (+8 bytes of the header).

A pwmc chunk holds a sequence of signals. A signal is simply a sinewave of specified frequency, lasting a specified amount of pulses. Such signals appear at the beginning of each turbo data block and are used for synchronisation.

The data field contains signals, each one defined by 3 bytes. Therefore a pwmc chunk holds chunk_length/3 signals.

Each signal is defined in terms of 2 values: length of a single pulse and number of pulses. For example, a signal defined by bytes 0x03 20 01 is a signal that consists of 0x0120 = 276 pulses each of length 0x03 = 3 (total signal's length = 276x3. See samplerate field in the last encountered pwms chunk for length's base rate).

A pwmd chunk has similar purpose as a data chunk, but for turbo transmission - it holds a block of bytes encoded in PWM. The fields pulse_0_length and pulse_1_length contain lengths of pulses that are used do encode bits in this chunk. The data field contains the block's bytes. Bit order of the block's bytes is defined by the bit_order field in the last encountered pwms chunk.

A pwml chunk has similar purpose as a fsk  chunk, but for turbo transmission - it holds a sequence of raw PWM states. Each state can be high = rising edge, or low = falling edge. pwml chunks are used as a last-resort method of storing PWM data that cannot be encoded into bytes (in other words, into a pwmd chunk).

A pwml chunk contains chunk_length/2 states - each state is encoded as a 2-byte number in the data field. Like always, a signals length should be divided by samplerate from the previous pwms chunk to get the length in seconds.

Interpretation of the values in the data field depends on the previous pwms block's pulse_type value:

• If pulse_type equals %10, then the first value in data is length of a rising ednge, the second value is length of a falling edge, the third value - again a rising edge, and so on.
• If pulse_type equals %01, then the first value in data is length of a falling ednge, the second value is length of a rising edge, the third value - again a falling edge, and so on.