
   Welcome to 64COPY, a project which I started many moons ago, but got
severely out of hand, even moreso since V1.0 was released. This is the
latest release, and there are always 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 how I get the list,
available at the end of this document regarding future enhancements,
and user requests.

   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.

   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, 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)
     * UnLynx and Un-Zipcode archives.
     * creation of ZipCode files from D64/X64 files only.
     * 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)
     * Many user definable options (ALT-F6)
     * 6502 Disassembler (SHIFT-F4)
     * full retention of last 15 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, user configuration options)
     * Memory-saving feature, if you execute the 64COPY.EXE loader,
        versus loading MAIN.EXE directly.

   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 Star Commander, 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 (using any of the above mentioned programs). Of course,
it does not verify if the data in a sector is valid (no practical 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. The routines 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 directory entries
first. All the important data is correct. It should also be compatible
with other multi-file tape images, but we shall see. There are two
problems with using large T64 files.

    1. 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. The size will always default to 30.

    2. Deleting entries at the beginning of the tape file takes an
       enormous amount of time, since all the entries after it must be
       moved back overtop of the space the deleted file occupied. With a
       file of several megabytes, and deleting several entries at once,
       this could take a minute or so.


   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, internal
defaults are used, and it will be rewritten upon exiting.

   The program also supports file associations (see the 64COPY.EXT file
for the layout of the entries, sample associations and comment layout).
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.

   Ever since I changed the program to allow for DOS shelling (for
reduced memory requirements, I find it very easy to forget that I
already have 64COPY loaded, and I will happily load it again. Doing a
MEM /c from DOS will show that I now have TWO copies loaded (silly me),
and I have to EXIT several times to get back to the first loaded copy.
You may find the same situation happening as well. At least you won't
run out of memory anymore.

   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.


*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.


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

  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 it changed 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. You
  will be informed (by an info box) that the INI is old and won't be
  used.

* The windowing routines are mine, all mine! If you don't like 'em, oh
  well. I developed them, just to see if I could. 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 encryption 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).

* 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.


  Thats all for now.  Enjoy the emulators...


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


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

  * Changing D64 file attributes
  * Save@ and unclosed ("*") files validated and/or restored in the
     CheckDisk routine.
  * Copying of REL files (conversion to other formats, specifically R00)
  * Add a repeat to the INS key (won't work under OS/2 though!).

  * Some more user configuration options (see below)
  * Mouse control (part-way done already!)
  * Built-in Hex/Text viewer/editor for DOS files
  * 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!)
  * Petascii-ASCII conversion
  * D64 defragmenter/optimizer

  * Directory Tree (F10)
  * 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...

  * Keyboard repeat rate/delay
  * Confirmation on delete
  * Mouse tracking speed
  * Clock on/off
  * Editor/Viewer (internal/external, but this will be a while)
  * Save/Don't save settings on QUIT


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



    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. :-)

