1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
|
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)
|
