*** Introduction to the various Emulator Formats


Compiled by:    Peter Schepers
     Started:   August 24, 1996
Last updated:   October 9, 1998


---------------------------------------------------------------------------


  There are always questions asked regarding the various formats which  are
commonly used on either the emulators or  the  real  C64.  Most  often  the
question involves conversion... "What do I do with LNX files?" or "How do I
make these files work on the C64s emulator?". This document is  an  attempt
to explain their internal structure, what to do  with  them,  and  some  of
their respective strengths and weaknesses.

  Some of what is contained in this document has been compiled from various
sources, and I have given the appropriate attributions in the  CONCLUDE.TXT
file. Some of the information may not be accurate as it may have been taken
from other documents, and I have no first-hand experience with it.  I  will
try to make it as thorough as possible, but if there  is  something  wrong,
please alert me so I can make the appropriate changes for future releases.


  So far, this document covers the following emulator types:

  * D64 (1541 disk representation, with a description  of  RELATIVE  files,
         and some D64 variants)
  * X64 (for the X64/Vice emulator)
  * T64 (Tape images for the C64s emulator)
  * T64 .FRZ (FRoZen Files, saved emulator sessions)
  * PC64 (P/S/U/Rxx)
  * PC64 .C64 (saved emulator sessions)
  * D71 (1571 disk representation)
  * D81 (1581 disk representation)
  * G64 (GCR image of a 1541 disk)
  * F64 (not an image file, but a companion file to D64's)
  * N64 (64NET's custom files)
  * L64 (64LAN's custom files)
  * C64 (PCLINK's custom files)
  * CRT (CCS64 ROM cartridge files)
  * 64x (PC64 ROM files)
  * TAP (CCS64 TAPe files)

  ...as well as the following native C64 types,  some  of  which  are  also
  supported on the various emulators:

  * 4-file diskpacked ZipCode (or .Z64, 4 or 5 files, #!xxxxx)
  * 6-file SixPack ZipCode (or .Z64, #!!xxxx)
  * Filepacked ZipCode (or .Z64, x files, x!xxxxx)
  * LNX (LyNX)
  * ARK & SRK (ARKive & compressed ARKive)
  * LHA & LZH (header description only)
  * SFX (SelF-eXtracting LHA/LZH)
  * SDA (Self-Dissolving Archive)
  * ARC (ARChive)
  * ZIP (PKZIP)
  * CKIT (Compression KIT)
  * CPK
  * WRA (Wraptor)
  * LBR (LiBRary, C64 only, not the C128 CP/M .LBR files)
  * GEOS VLIR (Variable Length Index Record)
  * CVT (GEOS ConVerT files)
  * SPY (SPYne)
  * Binary

  Also included is a very basic look at some C64 graphic bitmap formats (in
BITMAP.TXT), and the  saved  session  layout  of  the  Macintosh-based  C64
emulator "Power64" (in POWER64.TXT). Thanks to Peter Weighill for the above
info.

  At  the  end  of  the  CONCLUDE.TXT  document  is  a   BINARY/HEX/Decimal
conversion chart, useful when you don't know  how  to  convert  the  number
bases around. It might come in handy when working  with  and  understanding
the GCR conversion that the SixPack ZipCode format uses.

  Right now there are several good utilities available to work with most of
the mentioned formats. The first is 64COPY, my own conversion program.  The
second is Star Commander, by Joe Forster/STA. Included with his program are
many smaller utilities such as Star ARK, Star LHA and Star ZIP, which  will
convert specific formats to D64 images.

                                                 Peter Schepers,
                                                 University of Waterloo.

                                          Email: schepers@ist.uwaterloo.ca


---------------------------------------------------------------------------


Most recent changes:

June 2/98 - Added new section to D64, D71, D81, PC64, LNX, T64  and  BINARY
            dealing with the good/bad aspects of the layout
          - Updated F64 topic
          - Updated GEOS topic

June 8/98 - Added CCS64 ROM cartridge file (CRT)
          - Added a "document revision" number to each TXT file. This  way,
            version history can be tracked, and you will always know if you
            have the latest revision.
          - Added description of PC64 ROM files (64x)

 Oct 9/98 - Updated SDA topic
          - Added new G64, a 1541 GCR disk image

Feb 16/99 - Added a basic TAP description

Aug 13/99 - Added PSID/Sidplay formats
          - Updated G64 format


---------------------------------------------------------------------------


*** Terms and acronyms

  Many strange terms have come along with computers in general, and I  will
not attempt to explain them all, but some of the ones in this document  may
not be entirely clear. I will attempt to make things  a  little  easier  by
explaining some of the more common ones.


   - Short form for a Carriage Return ($0D) symbol.

   - Short form for a Line Feed ($0A) symbol.

  ASCII - This is an acronym for "American Standard  Code  for  Information
          Interchange". The standard  is  a  7-bit  code  covering  control
          codes, punctuation, alphanumeric (A to Z, 0 to 9) as well as math
          and a few other symbols. Since it is a 7-bit code, it ranges from
          $00 to $7F (0-127). This leaves the top 128-255 definable by  the
          vendor. The PC world has corrupted this standard making it 8-bit.

  BAM - An acronym for "Block Availability Map". Here  is  where  the  disk
        operating system keeps track of  what  sectors  are  allocated  (or
        available) for each track.

  BLOCK - This refers to sectors which  on  a  logical  level  are  grouped
          together. On a 1541 disk, it could be a series of sectors  linked
          together in a file, or a partition on a  1581  disk.  In  the  PC
          world it represents a "cluster"  of  sectors.  Generally  if  I'm
          referring to a grouping of sectors thats *not* 256  bytes  large,
          then I talk in blocks.

  BYTE - A group of 8 bits, the contents of 1 memory location.

  CHAIN - A series of sectors linked  together.  One  sector  will  have  a
          pointer to another, and that sector will point to another,  until
          the chain has no more forward pointers. A file stored on  a  1541
          disk would be considered a chain of sectors, but it  also  has  a
          directory entry explaining what the chain is for.

  FILETYPE - In the Commodore world, this would be the kind of file, be  it
             SEQ, REL, PRG, USR, GEOS etc. In the  DOS  world,  this  would
             possibly be the file extension, be it EXE, TXT, DOC. It  tells
             the user what file it is, making usage easier.

  GCR - An acronym for "Group Code Recording". This is the encoding  method
        Commodore uses to physically store the  information  on  the  disks
        (i.e. 1541). It encodes an 8 bit sequence into a 10 bit sequence so
        that long repeated sequences of 1's or 0's are avoided. These  must
        be avoided so that the timing of reading/writing to the disk  won't
        become "out of sync". As a user, you would not normally see the GCR
        information since the drive does all the conversion to  normal  HEX
        data before it gives it to you.

  HIGH/LOW - The bytes here are stored backwards compared to  the  LOW/HIGH
             method. See LOW/HIGH for more information.

  LINK - This is the track/sector values, stored in the first two bytes  of
         a sector, which point to (or "link" to) the t/s  location  of  the
         next sector. A  series  of  these  links  comprise  a  "chain"  of
         sectors.

  LOW/HIGH - This is how values are stored when they  exceed  one  byte.  A
             good example of this is the sector count of  a  D64  file.  To
             calculate the actual value, take the second value, multiply it
             by 256 and add the low  value.  You  will  now  get  the  real
             decimal value. i.e. (HIGH*256)+LOW=result.

             If you look at is as a HEX value, swap the  bytes  around  and
             put them together for the 16-bit HEX value. i.e. $FE $03 would
             be $03FE as a 16-bit HEX value.

  LSB/MSB - See LOW/HIGH.

  LSU - This is my own acronym meaning "last  sector  useage".  It  is  the
        value stored in byte position $01 (the "sector" value  of  the  t/s
        link) of the last sector of a file. This value is the offset  into
        the sector where the last byte is stored. It  also  represents  the
        byte count + 1, since a value of 255 would actually mean  only  254
        bytes of file data exists (full sector less the  2  bytes  for  t/s
        chain). Without reasonable knowledge of the disk layout, this  byte
        can be confusing, and hard to explain.

  NYBBLE - A grouping of 4 bits (half a byte), either the first or  last  4
           bits of an 8-bit binary number,  or  one  half  of  a  two-digit
           hexadecimal number.

           Typically, a byte will be broken down into two parts, the top  4
           bits and the bottom 4 bits. These are referred to as  the  upper
           and lower  nybble  respectively,  and  are  represented  by  two
           hexadecimal digits in base 16.

  PETASCII - (or PETSCII) This is Commodore's version  of  ASCII  (the  PET
             part of the name comes from the  first  computer  to  use  the
             code, the PET or Personal Electronic Transactor).

             Most of the codes from 0-127 are the same as ASCII, but  there
             are differences, especially  noticible  when  converting  text
             from a C64  to  a  DOS  machine.  Where  ASCII  has  uppercase
             characters, PETASCII has lower  case  ones,  and  vice  versa.
             Also, the top 128 characters (128 to 255) are quite  different
             from the PC "standard".

  RLE - An acronym for "Run Length Encoding". This is a simple  compression
        method, employed by most compression programs,  and  also  used  by
        some archive formats  (ZipCode,  CPK).  It  encodes  sequences  (or
        "runs", hence the name "RUN length...") of the same byte  (i.e.  00
        00 00 00 00  00)  into  a  smaller  string  using  a  shorter  code
        sequence, making the resultant file smaller than the original. This
        is the simplest form of file compression.

  SECTOR - It is best described as the method that the drive uses to  store
           the smallest group of bytes physically on the disk. On the  1541
           this refers to a group of 256 bytes stored together in a  single
           sector. On a PC disk, this is typically 512 bytes.

  SIGNATURE - A group of bytes, usually near or at the front of  the  file,
              which are used to identify the type of file. i.e. a PC64 file
              will always have the signature string "C64file" contained  at
              the beginning of the file.

  TAR - An acronym for "Tape ARchiver", a UNIX application, and  method  of
        backing up information.