
*NOTE* Please read the CHANGES.TXT file that should be with the
       distribution archive. I am starting to record all of the changes
       I make to the program (a daunting task, actually!), so take a
       look at this for info on any new things I may have put in.


     Always remember, you use this at your own risk. I will not be held
responsible with regards to data integrity, loss of data, abuse, failure
to read instructions, full moon and tidal influences, etc.

     64COPY supports *only* extended keyboards. I don't think a
non-extended keyboard will work since it uses scan codes which only
extended keyboards can generate. This is an unfortunate occurance, which
effectively eliminates XT's and many laptops, but I cannot get around
this.

*** NOTE ***

The first beta release (pre-beta 3) does have a confirmed bug in the
file convert section dealing with .D64 copying. If you copy a file in a
D64 archive across to another D64 and back several times, you would lose
1 byte off the end of the file each time you copied it. I would
recommend not using that version anymore.

Also, the P00 file creation had (has?) a bug in it where files will not
get converted at all, but a munched 26 byte file, with the correct name,
gets created. It was very hard to simulate, but I experienced it several
times, and I think I finally squashed this one.

The multi-file T64 routines are NEW (as of 11/17/94, beta 4), so use
with caution. I have used them for some time, and they seem stable. I
also changed the underlying code for most of the C64 file conversion
area. Proceed with caution! Testing is not complete yet.


*YOU HAVE BEEN WARNED*


Enjoy!   :-)


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


     Welcome to 64copy V2.02, a project which I started many moons ago,
but got severely out of hand, even moreso since V1.0 was released. This
is the third full release, and there are a few changes. Thanks to all
those who take the time out to give me hints and tips (you know who you
are), so if you are using this program, please send me email, telling me
what you think about it, and any comments you have. That is where I get
the list, available at the end of this document, regarding future
enhancements, and user requests.

     I modelled this version after Norton Commander, with very similar
features, key combinations, and feel. Press F1 to show you how to use
the keyboard. For those of you who do not like Norton Commander, oh
well, I am not going to change this program. I find the interface which
NC uses to be one of the best ones to do file operations (and of course
I am very familiar with it).

     Operation is very easy, and once you master the keyboard layout,
you will find that this program is also very useful for general DOS
operations as well. Here is a small list of the most useful functions...

     * creation/conversion of files to C64 file format (F11/F5/F6)
     * verifying the integrity of a D64/X64 archive (Alt-F3)
     * moving directories (F6)
     * deleting a directory and all contents (F8)
     * editing/viewing files (F3/F4/Alt F4)
     * changing attributes on dir's/files (CTRL-A)
     * calculating sizes of directories (ALT-F5)
     * searching the drive for a certain file (ALT-F7)
     * full retention of last 10 command-line commands (Alt-F8)
     * 10 User-definable menus (with wildcards) (F2)
     * Saving of defaults in .INI file (ALT-F6 editor/viewers, F2 menu
        items,etc)

   Just like Norton Commmander, you are presented with a list of files
and subdirectories (in both panels) when the program comes up. In order
to convert any C64 file, you first have to go into it by hitting ENTER.
64COPY treats C64 archives like subdirectories, and pressing ENTER on
them makes the program read the central directory of the C64 archive,
and present you with a list of all of the files. Simply trying to
convert a D64/T64 file, by using F11 (Convert) will only result in an
unuseable file, since it is treated as a DOS file, and not a C64 file.
Once you are inside the archive, you can use F5/F6/F11 to convert to any
other format. The only exception to this rule is the P00 format (used in
the PC64 emulator). These are treated as if you *have* gone into them,
since they only contain one file per archive, and making you actually
enter them was a waste of time.

   Use the TAB key to switch between panels, ALT-F1 and ALT-F2 change
the drive for the corresponding panel. Keypad '+', '-', '*' and INS keys
are used to select/deselect files (for copying, converting, moving,
deleting etc). Use the cursor keys to move the hilight line around.

     When you press the ALT or CONTROL keys, the keybar at the bottom of
the screen will change to show what keys they support (at least, it
shows most of the combinations, there are a few which are on the help
screen, but are not listed on the keybar, due to space limitations).

     Use the ESC key to get you out of almost anything (cancels all
dialog boxes, file copies/moves/deletes/conversions, etc).

     One other handy feature is the ALT-F3 key, which when inside a
D64/X64 archive will perform a Checkdisk, to verify integrity of a disk
which has been generated using X1541, Disk64e or Trans64. It looks for
such things as cross-linked files, illegal track and sector values,
invalid directory entries (such as separators, and illegal file start
track and sectors). It will also, on your ok, clear out unmapped sectors
(by filling them with zero's, which allows for better compression if you
plan to store them). It also does a few more things, so give it a try.
It is a very fast way to see if the disk transferred ok (by using
Trans64, Star Commander, X1541, COM1541 etc). Of course, it does not
verify if the data in a sector is valid (no known way to do this without
CRC error information). I found it very useful by checking out the
archives on Watson (like all of RIK's disks). It also logs all of the
output by appending to a file called <filename>.CHK, where <filename> is
the file you are currently checking). The log contains all of the
information seen in the on-screen output window.

     Much work has gone into the CheckDisk routine. With features such
as file undeletion, truncation (rather than deletion) of files with bad
track/sector links, recovery of lost chains (allocated and linked
sectors, but no corresponding directory entry), and better detection of
wrong sector links, it has become a very useful tool for detecting most
faulty tranfers.

     The undelete, sector clear and lost chain recover routines are all
after the main CheckDisk code. Once the program has checked the normal
files for integrity, the program will ask if you want to continue with a
more extensive scan of the disk. If you had any errors reported which
you did not correct, *DO NOT CONTINUE*. If you continue, you *could*
cause severe disk corruption, but only if you answer YES to any of the
questions which would follow.

     I can't think of too many other things to add to the Checkdisk
function, so I am likely finished with this routine. (It already
comprises the largest chunk of code in the program). If you have any
more ideas for enhancing this feature, I am all ears (as the Ferengi
would say).

     Multi-file T64 is also supported. I was very hesitant to support
this format, because of (my!) perceived problems with certain older T64
files. (Some of the original files created with a program called Conv64
contained bad header information, which I thought would cause me no end
of grief. However, I was wrong!). After a very long time considering the
possibilities, I decided (with some prodding from other people as well)
to write in the routines. They are very robust and forgiving. If an
image contains more than 1499 files, this program will only display the
first 1499, but this will not cause any problems with deleting or adding
files to the archive. It just can't display more than 1499.  Also, if an
error happens during the conversion to a T64 image, the T64 will not
become corrupted, since I write the dir entry first. All the important
data is correct. It should also be compatible with other multi-file tape
images, but we shall see. The only trouble with a large archive (i.e. a
high number of entries) is that the C64s emulator will only read the
first 99 (and maybe less?). This makes the creation of large images
(greater than 99) basically useless, but you do have the ability to
store large numbers if you need to.

     You can use CTRL-C (or CTRL-BRK) to emergency-quit from the
program. It will close off all the files, free all memory, and restore
the screen. It will also rewrite the INI file, so any changes you made
to the configuration, such as changing editor names and panel
directories will not be lost.

     If, for some reason, the program looks weird (wrong screen colors)
upon startup, quit 64COPY, delete the 64COPY.INI file, and restart the
program. It it possible the INI file got corrupted, and the starting
screen colors are stored in the INI file. It is completely safe to
delete the file at any time, since if it cannot be found, it will be
rewritten upon exiting.

     The program also supports file associations (see the 64COPY.EXT
file for the layout of the entries and sample associations). What this
does is allow you to execute a program/batch file when you hit return on
a filename. If you have set up an association for a .TXT file, when you
hit return on that file (docs.txt), whatever program you setup as the
association will be executed, with the filename as the argument.

     If you want to force either COLOR of MONO mode when starting
64COPY, use the /MONO or the /COLOR command-line switches. It will force
64COPY to display using either black/white colors, of full color, but
the video mode will not be changed. This may be necessary when using
this program on a monochrome screen, or especially a laptop (like the
Toshiba 5100, with the gas plasma display). These switches also override
the color setting stored in the 64copy.ini file. You can also use the
/quiet switch to disable the "Welcome To..." startup dialog box, if it
annoys you. The switches can be combined any way you like.


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

  Here are some details about 64COPY which might interest you...


* It creates filenames which will work on PC64 release 1.0 (but no
  longer for the C64neu beta's). Anytime a DOS filename is generated
  from a C64 filename (D64, T64, P00), I use this algorithm. The author
  of PC64 uses an algorithm for generating DOS filenames from the C64
  filenames, and he changed it from beta 11/12 to the release version. I
  have rewritten the filename conversion part of the program (from
  64COPY beta 3 and on) to correspond to the new algorithm, but have not
  yet fully tested it. It works for the sample filenames I threw at it.

* You are limited to 1499 filenames in a directory or a T64 archive. If
  this isn't enough, you might consider splitting up the directory into
  smaller ones. I don't want to increase it any more than necessary. If
  you have this many files in a sub-dir, DOS operations are already
  crawling anyway. I realize you cannot have 1499 files in a D64
  archive, but the program treats DOS dir's and D64 files as the same
  entity. I do all the internal checks to make sure you do not exceed
  the 144 filename limit for the 1541 drive.

* It will use the full length of the screen (either 25, 43 or 50 line
  modes are recognized), and allows mode switching (ALT-F9). It will
  also use MONO mode, at whatever number of lines mono supports.

* If order for a T64 file to be valid, the tape file must start with the
  characters "C64". If not, the tape file is assumed to be invalid, and
  this program will not process it.  If this is the case, you will
  receive the error "Not a valid .T64 file". You can correct it with a
  hex editor, if necessary.

* The Copy(F5) and Move/Rename(F6) do not work *exactly* as Norton
  Commander does. When copying individual files, the filename must be
  included (if you type in your own pathname). If it is not, you will
  get an error). However, when copying/moving multiple files (tagged),
  no filename should be specified. If one is, you will get an error.

* This program was tested on a 486/40 (clocked at 50Mhz) running OS/2
  Warp 3.0, with an ATI Ultra Pro video card. If it works under those
  conditions, it will work anywhere :-)   It works on my ATI card in
  mono mode, but I have not tested it on an MDA card (or Herc...). I
  also use it at work on another 486/50, ATI Graphics Vantage, running
  OS/2 Warp. In the shop where I work, we repair many PC compatibles,
  and any chance I get, I try this program out. This method has caught
  many wierd video and drive bugs (like network drives, plasma screens,
  strange video modes, etc). So far, anything that is found wrong, I
  fix.

* If you encounter a C64 filename which does not convert to P00 format
  properly (you will know when the PC64 window cannot find the file,
  even though you know it is there), send me the filename (the C64
  filename, not the DOS name), and I will try to fix my program. I had
  to guess at how he converted filenames, so I hope I got the conversion
  algorithm right. There are too many combinations to test, but all the
  ones I converted out of the .D64 and .T64 files worked ok.

* The text editor (F4), hex editor (ALT-F4) and viewer (F3) use external
  programs to do their dirty work. I use EDIT for the text editor and
  viewer, and FED to do the hex editing. I have not included FED.EXE with
  the release of 64COPY, since you can download it from the more popular
  MSDOS sites, such as OAK.OAKLAND.EDU. I might put in a text/hex
  editor, but this is sometime in the far future (since I really have no
  idea how to do this yet). You can use the ALT-F6 command to change the
  defaults for the editors. When you quit (ALT-F10) these changes will
  be saved. If you don't have DOS EDIT (available after DOS 5.0), you
  can set up a batch file called EDIT.BAT, that calls your favorite
  editor, or change the default with Alt-F6.

* The INI file (64COPY.INI) must be located where the program is
  executed from. If it is not, the program will use internal defaults,
  and when you quit, the INI file will be re-created (if possible). When
  the program quits, the program will tell you where it is saving the
  INI file, and if it was successful or not. This means if you use this
  program from a floppy, and quit with the floppy ejected, the .INI file
  will not get created.

* If you have just replaced an old version of 64COPY with a newer
  version, you may find that the defaults have disappeared. This will
  happen when I change the layout of the INI file (for more settings).
  64Copy checks the existing INI file for the proper version number, and
  if it does not match, it uses its internal defaults (just like the INI
  file didn't exists). I do this to prevent possible problems with
  mixing and matching version of the files. When 64Copy exits, it will
  replace the older version of the INI file with the proper one.

* The windowing routines are mine, all mine! If you don't like 'em, oh
  well. I developed them, just to see if I could. You know, the mountain
  was there, so I climbed it. Just getting the basic windowing to work
  was easy, but making it robust (different video modes and mouse
  support as well) is proving to be a job of a scale I didn't
  anticipate. Bear with me!

* The minimum DOS version that 64COPY can operate under (that I am aware
  of) is 3.1.  This might actually be higher, but I don't think so. I
  only use the most basic of BIOS calls.

* I will not be supporting the encoding that Miha used on the T64's and
  D64's under C64s 1.0e. It has been removed under 1.1b, and hopefully
  it is gone for good. I would recommend using the later versions of
  C64s anyways.

* I have seen the preliminary specs for the new D64 format (maybe called
  D69, nobody knows yet), and it is going to prove very interesting. It
  encompasses compressed and uncompressed tracks, direct GCR
  information, and simple sector copies. I have no idea how (or IF) I
  am going to support it, since I suspect this new format will be used
  mainly for copy-protected disks. If my suspicions are correct, then I
  will have no need to support it, since nobody will need to screw
  around with those type of disks (and I don't want the headache of
  supporting compression).


  Thats all for now.  Enjoy the emulators...


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


Here are some of the improvements I have already in mind (in order of
general importance)

  * CheckTape T64 integrity checker (with result logging). Includes:
    - verification of file pointers (no overlapping addresses)
    - should be no empty space in file
    - correct file count (used/free)
    - correct ending address
    - anything else I can think of (or you can)
  * Color configuration
  * More user configuration options (see below)
  * D64/X64 BAM display/sector editor
  * Support for different archive formats, such as:
    - Ark, LZH and Powerpacker (did this exist on the 64?)
      (I have the source code for all the above)
  * Mouse control (part-way done already!)
  * Show and allow changing of disk/tape labels on T64's and D64's
  * Built-in Hex/Text viewer/editor/lister
  * Improve DOS file search routine (show found files in a list, rather
      than going to each directory individually)
  * Pull-down Menus
  * Add a keyboard handler to trap CTRL-C, CTRL-P, CTRL-BRK (I already
      tried this and failed miserably!)
  * Dis-assembler
  * Petascii-ASCII conversion
  * Detokenize BASIC programs (I have the code for this as well)
  * D64 defragmenter/optimizer
  * Directory Tree (F10)
  * Inclusion of Trans64 conversion routines (source code is available,
      but I don't find it too stable yet)
  * Extended D64 format (supported by PC64, sector error bytes)
  * Other extended D64 formats (like 40 track disks), used by C64s
  * De-Isepic (maybe?)
  * C64 file compares


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


Here is a list of defaults I would like to make user-definable. This
list is by no means exhaustive, just top of my head things...

  * Screen colors
  * Keyboard repeat rate/delay
  * Startup color mode (b/w or color)
  * Startup line mode (25/43/50)
  * Confirmation on delete
  * Default conversion to a specific C64 filetype (P00/D64/T64/Bin)
  * Mouse tracking speed
  * Clock on/off
  * Editor/Viewer (internal/external)
  * Confirmation for QUIT (F10)
  * Inclusion/Exclusion of hidden files with +/- selection keys
  * Display of hidden files.
  * Save/Don't save settings on QUIT
  * Error beep on/off
  * CheckDisk Log on/off


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



    If you need to contact me, my email address is...

    schepers@dcs1.uwaterloo.ca

    and my present snail-mail address is...

    Peter Schepers
    4-1227 Nellis Street,
    Woodstock, Ont., Canada
    N4T 1N8

    Remember, I accept all donations and suggestions but money is the most
    interesting. :-)

