*** CPK
*** Document revision: 1.3
*** Last updated: March 11, 2004
*** Contributors/sources: Andre Fachat
This format, created by Andre Fachat, was not designed for the emulators
specifically, but was made primarily for Andre's own purposes.
It is a very basic format using simple RLE compression, with each file
following in sequential order (as Andre put it, "its similar to a UNIX TAR
file"). There is no central directory, none of the files are byte aligned,
and it uses compression so every file will be different.
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
----------------------------------------------- ----------------
0000: 01 40 41 2E 41 4E 4C 2C 50 00 01 08 24 08 64 00 .@A.ANL,P?..$.d?
0010: 99 22 93 20 20 20 41 4E 4C 45 49 54 55 4E 47 20 ?"????ANLEITUNG?
0020: 5A 55 4D 20 40 41 53 53 45 4D 42 4C 45 52 00 4E ZUM?@ASSEMBLER?N
0030: 08 6E 00 99 22 11 40 41 53 53 20 49 53 54 20 45 .n??".@ASS?IST?E
0040: 49 4E 20 32 2D 50 41 53 53 2D 41 53 53 45 4D 42 IN?2-PASS-ASSEMB
0050: 4C 45 52 2E 20 44 45 52 00 78 08 78 00 99 22 11 LER.?DER?x.x??".
The first byte of the file is the version byte. Presently, only $01 is
supported.
0000: 01 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ................
The filename follows, stored in standard PETASCII, and no padding
characters ($A0) are included.
0000: .. 40 41 2E 41 4E 4C .. .. .. .. .. .. .. .. .. .@A.ANL.........
The filetype is attached to the end of the filename in the form of ',x',
where x is the filetype used (P,S,U), and it is in PETASCII upper case. The
filename ends with a $00 (null terminated). REL files are *not* supported
as there is no provision made for the RECORD size byte.
Note that not *all* CPK files will have the ",x" extension added on. If
it doesn't exist, assume that the file is a "PRG" type.
0000: .. .. .. .. .. .. .. 2C 50 00 .. .. .. .. .. .. .......,P?......
Following the filename, we get program data.
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
----------------------------------------------- ----------------
0000: .. .. .. .. .. .. .. .. .. .. 01 08 24 08 64 00 ............$.d?
0010: 99 22 93 20 20 20 41 4E 4C 45 49 54 55 4E 47 20 ?"????ANLEITUNG?
...
0270: 00 83 0A E6 00 99 22 11 20 20 31 32 33 F7 08 20 ??????".??123?.?
0280: 2D 44 45 5A 49 4D 41 4C 00 A4 0A F0 00 99 22 11 -DEZIMAL??????".
0290: 20 20 24 33 34 35 F7 07 20 2D 48 45 58 41 44 45 ??$345?.?-HEXADE
The data requires some explanation as it uses RLE (Run Length Encoding)
compression. When creating CPK files, data in the file to be compressed is
scanned for runs of repeating bytes, and when a string of 3 or more (up to
255) is found, then the following sequence of bytes is output...
$F7 $xx $yy - where F7 is the code used for "encoded sequence follows",
$xx is the number of times to repeat the byte and $yy is
the byte to repeat. Using the sample below, we see the F7
code, then a "repeat 7 times the number $20"
0290: .. .. .. .. .. .. F7 07 20 .. .. .. .. .. .. .. ......?.?.......
Using $F7 as the encoder byte presents one problem: When encoding a file,
and we encounter an $F7, what does the packer do? Simple, it gets encoded
into $F7 $xx $F7 meaning repeat $F7 for as many times as is needed (if its
only 1 $F7, then the value for $xx is $01). The code 'F7' was chosen
because it is not a 6502 opcode, a BASIC token, or any commonly used byte,
but *not* because it has the least statistical probability of occuring.
The stored program ends when the string $F7 $00 is encountered, since
this sequence can not occur in the file naturally. If you need to search
through a CPK file for the filenames, do a hex search for all $F7 $00
sequences, since they preceed all filenames except the first.
The end of a CPK file can be found two different ways:
1. When an EOF (end of file) occurs, after an $F7 $00 byte sequence.
This is the normal method.
2. When a filename of $00 occurs, meaning there is no filename, just a
null termination. This is not much used anymore.
Using method #1 for ending the file is more common because it makes
adding files to the CPK file very easy. All you have to do as append the
new filename/data to the container. Using method #2 means you have to check
and see if the last three characters are $F7 $00 $00, and start writing the
new file into the container starting after the first $00.
In order to extract *one* specific file, you would need to read the whole
file until you find the filename you want, then output that file only. As
this format has no central directory and no file location references, there
is no other way to do it.
This format has not been used for some time now, as when it came out D64
and T64 were also being developed and accepted into common use. It is
unlikely you will find *any* files in this format. 64COPY V3.2 (and up)
does support extraction of these files just in case any are encountered.
|