formats index
*** FilePacked ZipCode (A!xxxxxx, B!xxxxxx, etc)
** Document revision 1.1
This is another rarely seen format, and is very similar to the Diskpacked
(4-pack) Zipcode in structure. It is comprised of a series of files denoted
by A!xxxxxx and B!xxxxxx, with letters instead of numbers as the first
characters of the filename. It also contains one other file called X!xxxxxx
which contains a directory of the files stored in the overall archive. Here
is the layout of the files:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
----------------------------------------------- ----------------
0000: FF 03 A6 11 0A 01 08 0E 08 CE 07 9E 20 28 32 30 (20
0010: 36 34 29 00 00 00 78 A9 34 85 01 A2 05 BD 42 08 64)x4B
0020: 9D 2D 00 CA 10 F7 9A A0 00 C6 32 CE 2C 08 B1 31 -2,1
0030: 99 00 00 C8 D0 F8 A5 32 C9 08 D0 ED B9 48 08 99 2H
0040: 00 01 C8 D0 F7 4C 00 01 01 08 46 4D F3 BB B1 2F LFM/
Bytes: 00-01: Load Address, low/high format, usually $FF $03, or $03FF)
02: Number of sectors in the file (maximum 166, or $A6)
03-??: Zipcoded sector data starts here
If 166 sectors was not enough to store the file then more x!xxxxxx files
are needed, and the layout is the same. This makes the resulting file size
of each section approximately the same as the 4-pack zipcode would be, as
166 sectors is 1/4 of a normal D64 (664 sector) disk.
The sector information is zipcoded in the same manner as Diskpacked
4-pack Zipcodes, but the sector size (excluding the t/s link) is 254 bytes,
not 256 as in 4-pack zipcode. The compression is still stored in the top
two bits of the track link, and the remainder of the sector (254 bytes) is
encoded. Each block of the file is stored in full, even the last one,
though it is rarely completely used.
Bits
----
00 - No compression, the sector is stored in full. The next 254 bytes
contains the remainder of the sector information.
01 - Sector is filled with *one* character. The next character is the
fill byte. Repeat it 254 times, and fill the sector.
10 - Sector is compressed using RLE compression (see 4-pack ZipCode for
details)
11 - Unused
If the track is decoded as $00, then we are on the last block of the
file, and the sector represents the number of bytes used.
The special file, X!xxxxxx, as mentioned above, contains a listing of all
the files in the archive. It has most of the information that the D64/1541
entry would. Here is the layout:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
----------------------------------------------- ----------------
0000: 01 08 0B 08 00 00 9E 32 30 36 31 00 00 00 A0 00 2061
0010: 8C 20 D0 8C 21 D0 B9 C7 08 F0 06 20 D2 FF C8 D0 Ќ!й
0020: F5 85 FF 85 FB A0 0A 84 FC 85 FD 85 FE A0 11 B1
0030: FB 48 AA C8 B1 FB 48 A8 20 4B 09 20 41 09 8A 20 HȱHKA
0040: 41 09 98 20 41 09 68 AA 68 18 65 FD 85 FD 8A 65 AAhhee
0050: FE 85 FE 20 39 09 20 3C 09 A0 00 B1 FB C9 A0 F0 9<ɠ
0060: 08 20 41 09 C8 C0 10 D0 F2 20 3C 09 C0 13 F0 06 A<
0070: 20 39 09 C8 D0 F6 A0 10 B1 FB 29 7F 20 41 09 20 9)A
0080: 3F 09 A5 FB 18 69 15 85 FB 90 02 E6 FC E6 FF A5 ?i
0090: FF CD FF 09 D0 97 AA A0 00 20 4B 09 8E 08 09 8C ЗK
00A0: 09 09 A6 FD A4 FE 20 4B 09 8D 1A 09 8E 1B 09 8C K
00B0: 1C 09 AD FE 09 09 30 8D 2D 09 A0 00 B9 F7 08 F0 0-
00C0: 06 20 41 09 C8 D0 F5 60 93 9B 11 11 11 11 11 11 A`
00D0: 11 11 11 11 11 11 11 11 11 11 48 4F 4C 44 20 53 HOLDS
00E0: 54 4F 50 20 54 4F 20 50 41 55 53 45 20 4C 49 53 TOPTOPAUSELIS
00F0: 54 49 4E 47 3A 0D 0D 00 0D 0D 54 4F 54 41 4C 20 TING:TOTAL
0100: 46 49 4C 45 53 20 20 3D 20 30 30 0D 54 4F 54 41 FILES=00TOTA
0110: 4C 20 42 4C 4F 43 4B 53 20 3D 20 30 30 30 0D 50 LBLOCKS=000P
0120: 41 43 4B 45 44 20 46 49 4C 45 53 20 3D 20 30 0D ACKEDFILES=0
0130: 05 5B 5A 43 20 49 49 5D 0D 00 A9 20 2C A9 22 2C [ZCII],",
0140: A9 0D 20 D2 FF A5 91 C9 7F F0 FA 60 8E 92 09 8C `
0150: 93 09 A0 02 A9 30 99 96 09 88 10 FA A2 02 AD 92 0
0160: 09 38 FD 8F 09 8D 94 09 AD 93 09 E9 00 8D 95 09 8
0170: 90 11 AD 94 09 8D 92 09 AD 95 09 8D 93 09 FE 96
0180: 09 D0 DB CA 10 D8 AD 98 09 AE 97 09 AC 96 09 60 ح`
0190: 01 0A 64 00 00 00 00 31 32 33 00 00 00 00 00 00 d123
01A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04
0200: 0E 4D 55 53 49 43 20 53 45 4C 45 43 54 4F 52 A0 MUSICSELECTOR
0210: A0 D0 B6 00 11 00 31 30 30 31 20 4C 45 54 54 45 ж1001LETTE
0220: 52 20 2D 56 2D A0 D0 72 00 13 00 4E 45 57 20 4D R-V-rNEWM
0230: 41 49 4C 2F 44 44 A0 A0 A0 A0 A0 D0 1E 00 19 00 AIL/DD
0240: 4A 41 43 4B 20 54 48 45 20 4E 49 50 50 45 52 A0 JACKTHENIPPER
0250: D0 C0 00 1A 06 54 55 52 4E 45 52 20 49 49 A0 A0 TURNERII
0260: A0 A0 A0 A0 A0 D0 2B 00 07 00 53 43 52 45 45 4E +SCREEN
0270: 20 20 30 A0 A0 A0 A0 A0 A0 A0 D3 07 00 05 00 53 0S
0280: 43 52 45 45 4E 20 20 31 A0 A0 A0 A0 A0 A0 A0 D3 CREEN1
0290: 0C 00 05 01 53 43 52 45 45 4E 20 20 32 A0 A0 A0 SCREEN2
02A0: A0 A0 A0 A0 D3 0B 00 04 00 53 43 52 45 45 4E 20 SCREEN
02B0: 20 33 A0 A0 A0 A0 A0 A0 A0 D3 02 00 04 01 53 43 3SC
02C0: 52 45 45 4E 20 20 34 A0 A0 A0 A0 A0 A0 A0 D3 03 REEN4
02D0: 00 04 03 53 43 52 45 45 4E 20 20 35 A0 A0 A0 A0 SCREEN5
02E0: A0 A0 A0 D3 07 00 04 07 53 43 52 45 45 4E 20 20 SCREEN
02F0: 36 A0 A0 A0 A0 A0 A0 A0 D3 08 00 03 00 53 43 52 6SCR
0300: 45 45 4E 20 20 37 A0 A0 A0 A0 A0 A0 A0 D3 07 00 EEN7
0310: 03 01 53 43 52 45 45 4E 20 20 38 A0 A0 A0 A0 A0 SCREEN8
0320: A0 A0 D3 0B 00 03 09 .. .. .. .. .. .. .. .. .. .........
Bytes: 0000-01FE: BASIC program which lists the contents of the archive
(a SYS 2061 call to an ML program)
01FF: Number of archive (x!xxxxxx) files. Since the upper
value is 4, we have A!xxxxxx, B!xxxxxx, C!xxxxxx,
D!xxxxxx and X!xxxxxx.
0200: Number of C64 files contained in the directory (14)
0201: Start of the directory
Each file has a directory entry in the X!xxxxxx file, starting at $0201,
each 21 bytes long, and laid out as follows:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
----------------------------------------------- ----------------
0200: .. 4D 55 53 49 43 20 53 45 4C 45 43 54 4F 52 A0 .MUSICSELECTOR
0210: A0 D0 B6 00 11 00 31 30 30 31 20 4C 45 54 54 45 ж1001LETTE
0220: 52 20 2D 56 2D A0 D0 72 00 13 00 4E 45 57 20 4D R-V-rNEWM
0230: 41 49 4C 2F 44 44 A0 A0 A0 A0 A0 D0 1E 00 19 00 AIL/DD
0240: 4A 41 43 4B 20 54 48 45 20 4E 49 50 50 45 52 A0 JACKTHENIPPER
0250: D0 C0 00 1A 06 54 55 52 4E 45 52 20 49 49 A0 A0 TURNERII
0260: A0 A0 A0 A0 A0 D0 2B 00 07 00 53 43 52 45 45 4E +SCREEN
0270: 20 20 30 A0 A0 A0 A0 A0 A0 A0 D3 07 00 05 00 53 0S
0280: 43 52 45 45 4E 20 20 31 A0 A0 A0 A0 A0 A0 A0 D3 CREEN1
0290: 0C 00 05 01 53 43 52 45 45 4E 20 20 32 A0 A0 A0 SCREEN2
02A0: A0 A0 A0 A0 D3 0B 00 04 00 53 43 52 45 45 4E 20 SCREEN
02B0: 20 33 A0 A0 A0 A0 A0 A0 A0 D3 02 00 04 01 53 43 3SC
02C0: 52 45 45 4E 20 20 34 A0 A0 A0 A0 A0 A0 A0 D3 03 REEN4
02D0: 00 04 03 53 43 52 45 45 4E 20 20 35 A0 A0 A0 A0 SCREEN5
02E0: A0 A0 A0 D3 07 00 04 07 53 43 52 45 45 4E 20 20 SCREEN
02F0: 36 A0 A0 A0 A0 A0 A0 A0 D3 08 00 03 00 53 43 52 6SCR
0300: 45 45 4E 20 20 37 A0 A0 A0 A0 A0 A0 A0 D3 07 00 EEN7
0310: 03 01 53 43 52 45 45 4E 20 20 38 A0 A0 A0 A0 A0 SCREEN8
0320: A0 A0 D3 0B 00 03 09 .. .. .. .. .. .. .. .. .. .........
Bytes:$00-0F: 16 character filename (PETASCII, padded with $A0)
10: Filetype: (the character "P" "S" or "U" OR'd with 0x80).
This means that the write-protect and splat bits are *not*
transferred, neither are custom file types, and REL is not
allowed either.
11-12: Length of the file in sectors (0 for no size)
13-14: Original starting track/sector of the file
In order to extract *one* specific file, you would have to read the
entire archive until you came across the directory entry that you wanted,
then process that specific file. This format does not contain any offset
references in the central directory for each file, just the original file
size, which means that we don't know anything about where a file might be
in the archive, since the original sector size doesn't apply as the stored
file in compressed.
Since this format seems to be uncommon, I can't see any benefit of using
it over LNX as a native C64 file. The only plus is it uses simple
compression, whereas LNX does not. However, LNX only uses one file for the
entire archive.