formats index
*** 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.
ÿ