mirror of
https://github.com/aaru-dps/docs.git
synced 2025-12-16 11:14:37 +00:00
226 lines
9.8 KiB
Plaintext
226 lines
9.8 KiB
Plaintext
|
|
*** P00/S00/U00/R00 (Container files for the PC64 emulator)
|
|
*** Document revision: 1.4
|
|
*** Last updated: March 11, 2004
|
|
*** Compiler/Editor: Peter Schepers
|
|
*** 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.
|
|
|