1 files changed, 0 insertions, 80 deletions
diff --git a/doc/fileformat.txt b/doc/fileformat.txt
deleted file mode 100644
index 7d87000..0000000
--- a/doc/fileformat.txt
+++ /dev/null
@@ -1,80 +0,0 @@
-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 additivie, *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 the Atari can't deal with really
-  large files. From examining the disassembled code of UNALF14.COM,
-  it looks like the highest byte isn't even looked at, meaning the
-  maximum size for a single file is 16MB. I have actually tested the
-  Atari ALF and UNALF programs with an emulator (and emulated hard
-  drive) with a file of 200KB in size, and it worked fine.
-
-Author: B. Watson (urchlay@slackware.uk)