
*** P00/S00/U00/R00 (PC64-native files)
*** Document revision 1.2

  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  archives
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.
An emulator 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. Note, this also applies to normal small DOS files as well!

  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 to
    keeping a good archive, 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
     emulator filetype (T64, LNX, ARK) will  be  more  efficient  than  P00
     since they are usually much larger than a single cluster.

