formats index
*** ARK (ARKive)
** SRK (compressed ARKive, very rare)
*** Document revision 1.1
Written by Edward Rohr, the ARKive program went through several
revisions, with the last known being version 3.0. It was intended as a
replacement for LNX as the author explained he had too many bad experiences
with LyNX destroying his data. Version 3 was also the only one to support
creation and extraction of the compressed SRK archives.
The ARK format bears a strong resemblance to LNX archives in that all the
files are simply stored one after the other, and are block aligned to take
up multiples of 254 bytes (256 on a real 1541). However, there is no BASIC
program at the beginning telling you to "Use XXX to dissolve this file",
and therefore there is no reconizeable signature to determine if the file
is actually an ARK. ARK's can contain up to 255 files, but this number is
restricted by the limitations of the drive being used for addition and
extraction.
SRK is the compressed version of ARK. The layout of the directory is the
same as below, only the files themselves (except for REL) might be
compressed. As I only seen one file (which was damaged), and my attempts to
create one with ARKive 3.0 failed badly, I can't comment on the compression
used. The biggest difference is the files contained inside the SRK are not
block-aligned since they are compressed, and therefore must be decompressed
to create the destination file, rather than just "unlinked".
The structure of the directory is very simple, where all entries take up
29 bytes (unlike LNX's variable size). Below is a sample of an ARK file,
with a few of its directory entries...
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
----------------------------------------------- ----------------
0000: 1F 82 9F 42 4F 4F 54 A0 A0 A0 A0 A0 A0 A0 A0 A0 .‚ŸBOOT
0010: A0 A0 A0 00 00 00 00 00 00 00 00 00 01 00 82 F1 úúúúúúúúú.ú‚ñ
0020: 53 55 50 45 52 20 4B 4F 4E 47 A0 A0 A0 A0 A0 A0 SUPERúKONG
0030: 00 00 00 00 00 00 00 00 00 79 00 82 FB 41 54 4F úúúúúúúúúyú‚ûATO
0040: 4D 49 43 20 48 41 4E 44 42 41 4C 4C A0 00 00 00 MICúHANDBALL úúú
0050: 00 00 00 00 00 00 0F 00 82 FE 58 45 52 4F 4E 53 úúúúúú.ú‚þXERONS
0060: A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 00 00 00 00 00 00 úúúúúú
0070: 00 00 00 2A 00 82 FF 57 45 54 20 50 41 49 4E 54 úúú*ú‚úWETúPAINT
0080: A0 A0 A0 A0 A0 A0 A0 00 00 00 00 00 00 00 00 00 úúúúúúúúú
0090: 12 00 82 5A 47 52 4F 55 4E 44 20 53 4E 49 50 45 .ú‚ZGROUNDúSNIPE
Byte: $00: Number of files in the ARKive ($1F = 31 files)
01-1D: First directory entry (29 bytes per entry)
01: File Attribute (same as a D64 attribute)
Typical values for this location are:
$80 - DEL
81 - SEQ
82 - PRG
83 - USR
84 - REL
Bit 0-2: The actual filetype
000 (0) - DEL
001 (1) - SEQ
010 (2) - PRG
011 (3) - USR
100 (4) - REL
Values 5-15 are illegal types.
Bit 3: Not used
Bit 4: Compressed flag (only for SRK). If set, file is
compressed. Not used in ARK files.
Bit 5: Not used
Bit 6: Locked flag (Set produces ">" locked files)
Bit 7: Closed flag (not set produces "*", or "splat"
files)
02: LSU byte (see "INTRO.TXT" document for description of "LSU")
03-12: 16-byte filename (in PETASCII, padded with $A0)
13: REL file RECORD size
14-19: Unused (can contain the unused locations from the D64 entry)
1A: REL file side sector block count (side sector info contained
at end of file)
1B: Number of bytes+1 used in the last side sector entry
1C-1D: Length of file, in sectors (low/high byte order)
1E-3A: Second directory entry
3B-57: Third directory entry
58-74: Fourth directory entry
75-91: Fifth directory entry
...
The starting location of the file information takes only a small
calculation to find out. As we have 31 entries, the total byte size of the
directory is 31 * 29 + 1 = 900 bytes (the 1 comes from the first byte of
the file, which represents the # of entries). Now, we take the 900 and
divide it by 254 to see the number of blocks, 900/254 = 3.543. If there is
any remainder, we always round up to the nearest integer, which in this
case makes it 4 blocks. So now we know that the file information starts at
4*254 = 1016 ($03F8 offset)
REL files are stored like a normal file except the side sectors are
stored directly following the normal file data. It would seem that the
actual contents of the side sectors are unimportant (except for the RECORD
length), just that the correct number of blocks exist.
Seeing as no emulator that I know of supports ARK format, I can't see any
usefulness in using it. It does have a better directory structure than LNX
as each entry has a consistent byte size (versus LNX's variable size).
There are also a few utilities for UnARK'ing on the PC. It would seem
that LNX is the better supported format (although I think it shouldn't be),
on both the C64 and the emulators. 64COPY supports these files on a
read-only basis, allowing you to convert them to another format, but
nothing else. Star Commander also contains a utility called Star Arkive
which will un-Arkive these files into a D64 image.
---------------------------------------------------------------------------
What it takes to support ARK:
ARK shares many features with LNX. It has a directory size that is always
a multiple of 254 bytes, and the files contained are also block aligned to
254 byte boundaries. The directory entries also have room for the unused
part of the D64 entry, used for time/date stamps, and it supports REL
files. Unlike LNX, this format uses a consistent 29-byte directory entry,
which is a very great advantage.
However, it has a few drawbacks as well. It contains no recognizeable
signature, and can only hold up to 255 files. The most annoying thing is
there is no provision for having a multi-block directory, with only a few
entries (which by the way LNX allows for). This means I cannot have a
directory with only 2 entries, yet have the directory take up 2 blocks.
For the 1541, this limitation makes no difference, but on a PC it makes a
world of difference. If I wanted to add files to an existing ARK file on a
PC, I might have to increase the directory by several blocks, and on a PC
that takes some work.
This also means that I cannot cancel a "copy" operation in the middle
because I may end with a directory with too many blocks for the number of
entries it contains.
ÿ