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
|
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)
|
