docs/Commodore/BINARY.TXT

*** Binary/Raw files
*** Document revision: 1.3
*** Last updated: March 11, 2004
*** Compiler/Editor: Peter Schepers
*** Contributors/sources: none

  This is really a non-format, as it has no specific layout whatsoever, but
instead is simply a data file. This does make it difficult to describe  any
general layout, as there are many  possibilities.  It  is  assumed  that  a
binary is  a  single  file,  usually  having  no  special  extension  (like
LNX/SFX/SDA, etc), sitting on a PC hard disk, not  inside  of  *any*  other
file (like in a D64/T64/LNX  etc).  By  looking  at  the  whole  file  (but
especially the beginning) with a HEX editor, and a  well-trained  eye,  you
can usually determine what file type it is by the BASIC code, load address,
and text strings contained within.

  Two possible file extensions that binary files  can  use  are  "BIN"  and
"PRG". There is a distinction in the 64 community between  these  two  file
types. A "BIN" (binary) file is one without a load address  preceeding  the
file data, and a "PRG" (program) file has a load address in the  first  two
bytes of the file.

  If the file is a normal C64 program, then the first  two  bytes  are  the
load address, stored in low/high byte format. If it is a BASIC program  (or
has a BASIC header), then the first two bytes might be $01 $08 (or $01  $04
for PET, $01 $1C for C128, the numbers  vary  for  different  systems  like
VIC-20, Plus4, C61, etc), and  the  rest  is  line  number  pointers,  line
numbers and BASIC code.

  If it is not a BASIC file (like part of a game loader), then it could  be
a machine language file, requiring a SYS call to  execute.  Many  secondary
files with multi-file games have load  addresses  other  than  $0801  (like
$C000, or $8000 for cartridges), and some  have  none  at  all,  where  the
loader program will actually specify where to load the  file.  Below  is  a
typical header for a game, using a SYS call to start  (in  this  case,  SYS
2064).

      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F        ASCII
      -----------------------------------------------   ----------------
0000: 01 08 0E 08 E9 03 9E 20 28 32 30 36 34 29 00 00   ....<2E>.<2E><>(2064)<29><>
0010: 00 78 A2 FF 9A A0 00 84 01 A2 CC BD 57 08 9D 33   <20>x<EFBFBD><78><EFBFBD><EFBFBD><EFBFBD><EFBFBD>.<2E>̽W.<2E>3

  One reason this  "non-image"  format  is  important  is  because  of  the
filename limitations imposed by  the  PC  architecture,  and  some  of  the
problems that it can cause. The PC has an 8.3 filename convention (assuming
DOS, and not OS/2 or Windows 95/NT long filenames), allowing for, at  most,
a filename of 11 characters. The  PC  also  has  character  limitations  on
filenames, most of which don't apply to the C64. When converting a C64 file
from any image/archive, you *cannot* use the C64 filename directly  on  the
PC since, first of all its likely too long, and  secondly  it  may  contain
characters illegal in  the  DOS  world  (i.e.  ASCII  46,  the  'extension'
separator).

  One other reason that binary is not a good way to keep C64 files is  that
you lose the C64 filetype. You *can* set the file  extension  to  show  the
type (xxx.PRG, xxx.SEQ), but  this  is  not  typically  done.  If  the  DOS
extension is not set, it is much more difficult to  know  what  format  the
file originally was.

  In order to convert a filename from C64 to  DOS,  the  use  of  translate
tables (translating illegal  characters  to  legal  ones)  as  well  as  an
algorithm to reduce the filesize down to useable  size  (typically  only  8
characters from 16) must be used. Included  within  the  PC64  distribution
archive is a 'C' program which does just what I have described. It contains
an algorithm which will remove illegal characters, then reduce the filename
down using several different rules, all to make the filename conform to the
DOS 8.3 naming standards.

  There are some people who feel that with Windows95 (or OS/2,  or  Windows
NT) long filename support, we should be able to have  C64  files  with  the
full 16 character filename on the PC hard disk. This is a  fallacy  as  the
useable character limitations of the C64 and those  of  any  OS  supporting
long filenames are not the same.  If  you  convert  a  C64  filename,  many
characters must be removed and or changed to allow it to be used in DOS (or
Win95).

  There is very little benefit or disadvantage to using binary.  About  the
only thing which is important to remember is you could  lose  most  of  the
original C64  filename,  which  *will*  cause  problems  when  you  try  to
reconstruct them. Binaries have no way of preserving the actual long names.

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

Overall Good/Bad of BINARY Files:

  Good
  ----
  * Easily determined filesize (the DOS filesize is the C64 filesize)

  * It is the *native* C64 file, so emulators can *easily* support it



  Bad
  ---
  * No 16 char filename, no real C64 filename at all 

  * No filetype, or special attribute bits 

  * No REL, GEOS or FRZ file support 

  * No signature or file description 

  * Difficult to support multi-file, as  original  C64  filenames  are  not
    retained

  * Since there is no filetype, you may not always be able to determine  if
    the file is a SEQ, USR or really a PRG without knowledge  of  the  file
    contents