*** 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.