ALF Archive Structure
---------------------

An ALF archive is laid out almost exactly like an ARC archive that
only uses compression types 2 or greater: A 29-byte header for each
file, followed by the compressed data, followed by either EOF or the
next file's header.

See the file Arcinfo for the original ARC file format. For ALF files,
"Byte 2: Compression version" will always be $0F.

Header structure:

Offset | Length | Description
-------+--------+------------------------------------------------------
0      | 2      | ALF signature bytes: $1A $0F
2      | 13     | Filename (null-terminated)
15     | 4      | 32-bit compressed size (little-endian)
19     | 2      | File date in MS-DOS format (same as ARC)
21     | 2      | File time in MS-DOS format (same as ARC)
23     | 2      | Checksum (simple additive, *not* a CRC)
25     | 4      | 32-bit original size (little-endian)
-------+--------+------------------------------------------------------

The compressed data for the file starts at offset 29.

The differences are:

- ALF files use $0F for the 'compression type' (offset 1), whereas
  ARC files use compression types 1 through 8.

- ALF always uses the 29-byte header; ARC uses 29-byte headers for
  compression types >= 2, but only 25 bytes for type 1 (stored).

- The actual compressed data is incompatible with any of the
  compression types supported by ARC. Although ALF uses an
  implementation of Lempel-Zev, it's not the same implementation
  as any of the ones that ARC uses.

- For ARC, the last file's compressed data is followed by a 0 byte
  (in place of the $1A header), to signal "end of archive". For
  ALF, there's no data after the last byte of the last compressed
  file.

- Because ALF doesn't use a 0 byte to signal end-of-archive, it's
  possible to append two ALF archives together; the result is also
  a valid ALF archive... unless there's "junk at EOF" on the first
  file.

- ARC uses CRC-16 for its checksums; ALF just adds the bytes together
  and uses the low 16 bits of the result as the checksum.

- Not really a file format difference, but the dates stored inside
  ALF files might be wrong or gibberish, if they were created on
  an Atari DOS other than SpartaDOS (or, on SpartaDOS, but without
  the R-Time 8 cartridge).

- ARC and ALF are both limited to 12 character filenames, with a
  null terminator. With ALF, any remaining bytes in the field after
  the null will be set to $20 (ASCII spaces, *not* more nulls).

- Atari filenames with no extensions (e.g. "FOO") are stored with
  a trailing period (e.g. "FOO.") in the ALF header. Upon extraction,
  Atari DOSes will remove the period, so the file will be called
  "FOO" again. I'm not sure whether the ARC for the Atari shares this
  behaviour, but ARC on MS-DOS or Linux doesn't do this.

- ALF files are never embedded inside a self-extracting executable,
  so the first file's header always starts at the first byte of
  the file.

- ARC and ALF both store the compressed and uncompressed file lengths
  as 32-bit unsigned integers, but in ALF only 24 bits are actually
  used. From examining the disassembled code of DZ.COM, it looks like
  the highest byte isn't even looked at, meaning the maximum size for
  a single file is 16MB. I have verified this by compressing large
  files with LZ.COM, running in an emulator with 'turbo' enabled. A
  16MB file (16777216 bytes) causes LZ.COM to go into an infinite
  loop, but a 16777215 byte file will compress successfully, and
  decompress correctly with DZ.COM.

Author: B. Watson (urchlay@slackware.uk)
