*** P00/S00/U00/R00 (Container files for the PC64 emulator)
*** Document revision: 1.4
*** Last updated: March 11, 2004
*** Contributors/sources: Wolfgang Lorenz
These files were created for use in the PC64 emulator, written by
Wolfgang Lorenz. Each one has the same layout with the filetype being
stored in the DOS extension (i.e. Pxx is a PRG, Sxx is a SEQ, Uxx is a USR
and Rxx is a RELative file), and the header is only 26 bytes long. This is
a dump of a Pxx file (PRG)...
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
----------------------------------------------- ----------------
0000: 43 36 34 46 69 6C 65 00 43 52 49 53 49 53 20 4D C64File.CRISIS.M
0010: 4F 55 4E 54 41 49 4E 00 00 00 .. .. .. .. .. .. OUNTAIN.........
Bytes: $00-06: ASCII string "C64File"
07: Always $00
08-17: Filename in PETASCII, padded with $00 (not $A0, like a
D64)
18: Always $00
19: REL file record size ($00 if not a REL file)
1A-??: Program data
The 'xx' in the extension of the file is usually 00, except when we have
two DOS filenames which would be the same, but the C64 filenames are
different! If we have two C64 filenames which are the same, they *cannot*
co-exist in the same directory. If we have two files which do convert down
to be the same DOS filename, the extension is incremented until an unused
one is found (x01, x02, x03, up to x99). We can have up to 99 different C64
files with the same corresponding DOS names as that's all the extension
will hold (from P00 to P99).
Each PC64 file only has one entry, there are no multi-file containers
allowed. This could result in a large number of these files in a directory,
even for only a few programs, as each C64 file will result in a PC64 file
entry. The best use for a PC64 file is a single-file program, one which
does not load anything else.
The DOS filename is generated by an algorithm used inside PC64 when a
file needs to be created. It compresses the 16-byte name down to one that
fits the DOS 8 character size limitation.
One thing which most people might not know is you *musn't* rename the
P/S/R/U DOS files. If you do, PC64 won't be able to load them. When PC64
goes searching for files, it takes the 16-byte C64 filename, does its magic
to reduce it to 8.3, then looks to see which DOS files match. Remember,
there could be several files with the same 8 character name, but the
extensions will be P00, P01, P02 etc. If it can't find the 16-byte C64
filename in amongst those that match, it will report a "File not found".
I've tried this with the DOS version (PC64 1.20) and it does report an
error locating the file, both in the PC64 File Manager and the 64 emulator
window.
---------------------------------------------------------------------------
What it takes to support PC64 files:
The biggest benefit to this format is that the layout and usage is fairly
simple to implement. With a consistent 26-byte header and a signature,
there's very little difficulty in working with them. Also, PC64 files
perform best when used on single-file games as they have *no* wasted space.
One good design aspect of PC64 files is how REL files are supported. LNX,
D64 and ARK all require storage of the side sectors, either preceeding or
following the file. R00 does not need to store these, making it more
efficient.
The biggest drawback to this format is when converting small C64 files
(those of only a few sectors), you could waste hard disk space due to a
large DOS "slack" area. When DOS stores files of any size, each one takes
up a minimum of one cluster, which on small drives may only be 2
kb/cluster, but on vary large disks could be as high as 32 kb per cluster.
Any file which is only a few Kb would, on the large disks, only use a small
portion of the total cluster, and thus a lot of wasted DOS storage space
results.
Another drawback (not obvious right away) is since some games are made up
of a large number of files or varying sizes, it would be best to store each
game in a different sub-directory. If you don't, then you might not be sure
what files belong to what programs, and if you ever want to give a program
to someone else, there would be difficulties re-assembling the program.
This makes file management much more user intensive. The D64 format seems
to be the best one for multi-file games.
The last negative is that GEOS files cannot be put into the PC64 format.
They must reside on a native D64 disk in order to work.
---------------------------------------------------------------------------
Overall Good/Bad of PC64 Files:
Good
----
* Has a 16 character filename
* Filetype is available in the DOS file extension
* Can easily calculate the file size of the C64 file from the DOS file
size (DOS size - 26)
* Efficiently supports 1541 REL files (R00) i.e. no side-sector info
needed (unlike LNX and ARK)
* A very simple, easy to support file header
* Can have multiple C64 files with the same name in a DOS directory since
the file extension will simply change slightly
* Due to each P00 being a separate DOS file, the emulators can easily
rewrite any P00 file they need to. This can be useful for
debugging/cracking etc. This is not really an intentional *file* design
benefit but only an emulator side effect. However it could be useful
Bad
---
* Filenames are padded with $00, not the standard $A0 character
* No directory customization, as each PC64 file only holds one C64 file
* Since the filetype is the DOS extension, no special attribute bits
(write-protect) or non-standard file types (DEL) are kept
* Unless the user keeps the P00 files organized, you can end up with a
mass of confusing files in one directory. File management is crucial,
especially with PC64 files. It is best to keep each multi-file program
in separate directories. However, each DOS directory entry used for
organisational purposes also takes up space.
* Not yet as widely supported as D64 or T64
* No GEOS VLIR file structure support
* No labels/description field in the file header
* No multi-file support (since it wasn't designed to do this)
* Each file contains a separate C64 name, and in order to get a list of
all the real C64 names, *each* file must be read individually to get
this
* Can't rename the DOS P00 file since PC64 depends on the filename being
an algorithmic reduction of the C64 filename. Changing it likely will
likely render the file useless to PC64
* No 00's allowed in filenames, as this is the truncation character
* I don't think PC64/WIN supports the original PC64/DOS files
* Depending on the PC64 filesize and the DOS hard disk cluster size,
there could be significant cluster slack-space loss, especially
noticible with many average-size P00 files
This last detail is the most insidious, and the most difficult to
explain. The easiest way to check it out is the following:
1. Generate P00 files from games in other images like D64 files
(multi-file games of course).
2. Figure out how many clusters *each* file takes based on the
present cluster size (this is the more difficult part), for the
whole directory of P00 files. Multiply the resulting cluster count
by the cluster size. This is the *actual* useage in hard drive
space that the P00 files take.
3. Total up, in bytes, the whole P00 directory.
4. Divide the number from (3) into (2) (and multiply by 100) to get
the percentage efficiency. Subtract this number from 100 to get
the %-Loss.
From some experiments I did, I came up with some example %-loss charts,
one for P00 and one for D64 based on cluster sizes from 32k (large hard
disk) down to 512 bytes (floppy disk).
100 P00 files, totalling 1,829,629 bytes.
Cluster Actual
Size Usage %-Loss
------- --------- ------
32k 3,899,392 53.1%
16k 2,719,744 32.7%
8k 2,285,568 19.9%
4k 2,068,480 11.5%
2k 1,943,552 6.0%
1k 1,886,208 3.0%
512 1,854,976 1.4%
Given what would seem to be average hard disk sizes, I would estimate
the %-loss for P00 files to be around 20-40%. When you have a large
number of P00 files, you are wasting a lot of hard disk space.
12 D64 files, totalling 2,098,176 bytes (these were used to
generate the above 100 P00 files). Note that these D64 files were
*not* necessarily full, but it is assumed that they are used to
capacity. If they are not, then the %-Loss must be increased.
Cluster Actual
Size Usage %-Loss
------- --------- ------
32k 2,359,296 11.1%
16k 2,162,688 3.0%
8k 2,162,688 3.0%
4k 2,113,536 0.7%
2k 2,113,536 0.7%
1k 2,101,248 0.2%
512 2,101,248 0.2%
From the above charts, it becomes clear that D64, regardless of hard
disk size, is *much* more efficient at storing files (average of 1-3%
loss, assuming the files are full). In fact, almost *any* other
filetype (T64, LNX, ARK) will be more efficient than P00 since they
are usually much larger than a single cluster.
|