     Since this is a beta release, there are bound to be some things which
don't work 100%. I have tested it very extensively over the past several
months while I work with it, but when you write it, you tend to overlook
certain idiosyncracies that really bug the heck out of someone else.
Please mail me with *any* suggestions, improvements, gripes... flames will,
as always, be directed to /dev/null.

     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, etc.

     64Copy supports *only* extended keyboards. I don't think a non-extended
keyboard will work. It uses scan codes which i think only extended keyboards
can generate. This is an unfortunate occurance, but I cannot get around this.
This limitation effectively eliminates XT's (also due to the speed of the
screen routines, this program is *painfully* slow on an XT, and a slow AT). Not
only that, the convert routines use F11 and F12, which are not available on
most XT's, and many laptops.


*** NOTE ***

The first beta release 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. I think I finally killed this one. It is hard to simulate, but I
experienced it several times.


Enjoy!   :-)


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


     Welcome to 64copy V2.0beta3, a project which I started several months
ago, but go severely out of hand, even moreso since V1.0 was released. This is
the third release of the beta, and there are a few changes which will be
noticable. I changed the way F5/F6/F8 work, and altered the windows for the
copy, move and delete output- they now use the resizable windows that Norton
uses. Because of code compression, I am bound to have introduced many new bugs
(some of which I found and killed), but be on the lookout for them. I also have
fixed *numerous* inconsistencies (a new word for BUGS) which I found just by
using this program every day. I have received very few bug reports from
anywhere else, so if you are using this program, please send me email, telling
me about it (and any comments you have).

     I modelled this version after Norton Commander 3.0, 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 better 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 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)
     * showing sizes of directories (ALT-F5)
     * searching the drive for a certain file (ALT-F7)
     * full retention of all command line commands (Alt-F8)
     * User-definable menu (F2)
     * Storage of defaults (ALT-F6 changes F2 menu items) in .INI file

   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 dialog
boxes, file copies/moves/deletes/conversions, etc).

     To convert or see the files inside T64's, D64's and P00's, hit return
when the hilight line is on the filename, and 64COPY treats it like a
directory, containing sub-files which you can copy out using F5/F6/F11,
and convert to other formats.

     One other handy feature is the ALT-F3 key, which when inside a D64
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 unused sectors (by filling them with zero's). 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. Of course, it does not verify if the data in a
sector is valid (no easy way to do this). I found it very useful by checking
out the archives on Watson.

     I have been working on the Checkdisk routine lately, and added some more
nice things, like undeleting files, truncation (rather than deletion) of files
with bad track/sector links, recovery of lost chains (sectors with links to
other sectors, but no corresponding directory entry), and better detection of
wrong sector links. The undelete/sector clear/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.

     You can use CTRL-C 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).
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.
See the included 64COPY.EXT file for the layout, and sample associations which
I use daily.

     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.

     Here is a useful shortcut which I accidentally discovered about the
selection/deselection functions (grey +,-,*). If you want to select *just*
directories, do the following... grey +, set pattern match to *.*, hit enter,
hit grey *. This will select all (excluding directories), and then invert all
selections, making just the directories highlighted. Very neat. The only
reason this works was because I altered the way 'grey *' works. It use to
do the same as 'grey +, *.*', but I figured it is supposed to invert *all*
selections, so now it does just that. If none are selected, it will select
all (including directories), or invert all, selecting just the directories.
It is the only one which will select directories (well, INS does as well, but
one at a time).



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


Here are some of the improvements I have already in mind...

I don't support the File Tree, mouse movement and the menu structure. Mouse
movement, with the present windowing system I have (my own), is no easy task
to implement, so don't expect it any time soon. Besides, I find that the
keyboard interface more than sufficient, and with no menu system in place,
there is very little use for it.

I also might support multi-file T64's... not sure about this one yet, as it
might not be worth including it. It is also a pain, what with the all the
bad Conv64 tape files floating around. (It is really only two bytes in the tape
file which are damaged, but they indicate the length of the file. Since these
bytes are wrong, I hesitate to work with any tape files. If you go adding
filenames to a damaged file, you could screw up several files.)

Support for error bytes on the end of D64's, created by the registered version
of PC64. These error bytes tell PC64 which track/sector 1541 disk errors are
located (like 21, 20, 29, etc). At present, I don't support this at all. I also
have no samples to work with.

I will likely include (somehow, somewhere, sometime) the transfer routines
from Trans64. This would be a very nice addition, since you would be able
to do almost everything from inside this program (i.e. read/write
1541/1571/1581 disks, create D64 archives, convert files, and all kinds of
DOS operations as well). However, I will wait for a more stable release than
is currently available. I have rarely had a reliable connection to a 1541 on
my machine with *all* releases of Trans64 (last used version was 1.12)

I also hear through the grapevine that Wolfgang Lorenz (author of PC64) has
proposed a file standard for supporting GCR disks (low-level bit copies of a
C64 disk). This will greatly enhance software support, since many of the
protection schemes can be implemented this way. It also adds a great headache
about how to decode such disks with this type of program. It certainly gives
plenty of food for thought about future upgrades... (as Monty Python use to
say in one of the Gumby skits, "My brain hurts!".) I have a feeling that if
this file format catches on, there will be very little need to use this type
of program since the disks will be protected, and very likely you will not
want or need to copy any of the files off of one of them. These files will also
be quite large, since it would likely contain all the sync and header bits,
which add a lot to the overhead.



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


  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 some of the
  sample filenames I threw at it.

* You are limited to 1500 filenames in a directory or a D64 archive. If
  this isn't enough, you might consider splitting up the dir 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 1500 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.

* In order for a .D64 file to be a valid file (besides having the
  extension .D64), the file must conform to the 1541 DOS standard. At
  position 2 of track 18, sector 0, there must be a hex 41 ("A")
  character, which indicates this disk is a 1541/4040 format. If this
  byte is not there (and there are a few on Watson), you will get the
  error "Not a valid .D64 file".  You can correct this with a hex
  editor. I did this so that people can't try to fool the program
  into thinking another file was a D64 just by changing the extension, and
  thereby really mucking the program up.

* The same goes for .T64 files. If the file does not start with the
  characters "C64", then the tape file is assumed to be invalid, and
  this program will not process it.  If this is the case, you will
  recieve the error "Not a valid .T64 file". Once again, you can correct
  it with a hex editor.

* 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 does *not* use the multi-file capability of the T64
  format, due to bugs in many of the tape images.  I realize this might
  be unpopular, but this feature seems to be rarely needed, since the D64
  format is more popular.

  Addendum: I noticed the shareware release of C64s10c uses a multiple
  file T64... I might have to support this in the future.

* This program was tested on a 486/40 (clocked at 50Mhz) running OS/2
  2.99 (beta 1), 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 2.1
  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 QEDIT for the text editor, FED
  to do the hex editing, and the DOS MORE command to view. I have not
  included these with the release of 64COPY, since you can download them
  from 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.

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

* 64COPY uses all BIOS calls for its video writes, since I am not fluent
  enough to do direct memory writes. Direct writes would make the video
  much faster, but I doubt too many people will have problems with the
  speed. It can get annoying under OS/2, with many other processes
  running, since you can see the screen re-drawing bit by bit. I have also
  seen it running on a 286, and it was not unreasonable, just slightly
  annoying. On an XT, I would rather watch paint dry! (PS... it really doesn't
  run on an XT, but it looks like it does, try it).

  (I am now using the new Watcom version 10.0, instead of version 8.0. Version
  10.0 includes some functions which allow direct screen-writes, so I will be
  doing some re-writing of the screen routines when I can.)

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

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


  Thats all for now.  Enjoy the emulators...


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

    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, flames and suggestions but money
    is the most interesting.

