
ͻ
                                                                         
   Chapter 1:                 Introduction                               
                                                                         
ͼ

  64COPY is a general purpose utility which provides both DOS and C64
file maintenance. It will convert most of the popular file formats for
the C64 emulators (LNX, D64, T64, P/R/U/Sxx, ZipCode and binary) to any
other filetype. It also provides a CheckDisk/CheckTape function for D64
and T64 images, as well as an Editor, File Viewer, HEX Editor, D64 HEX
editor, D64 Directory Customizer and a whole mess of DOS commands.



*** Disclaimer and User Liscence!

  64COPY is shareware, not freeware, postcard-ware, pizza-ware, etc. It
is not guaranteed to work under *any* circumstances, but appears to work
under most. It has been tested on many different hardware platforms where
I work, and anything that comes up as incorrect has been fixed. This
method has caught many wierd video and drive bugs (like network drives,
plasma screens, strange video modes, etc). If this program fails to work
for you, I will not be held liable for any loss of information, time,
etc. You use this program at your own risk (as I do all the time).

  This program is constantly tested on a 486dx/40 (clocked at 50Mhz)
running OS/2 Warp 3.0 with an ATI Ultra Pro video card. If it works under
those conditions, it should 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 486dx/40 (also at 50Mhz), ATI Graphics Vantage,
running OS/2 Warp Connect. In the shop where I work, we repair many PC
compatibles, and any chance I get, I try this program out. So far,
anything that I have found wrong, I have fixed.



*** Shareware Cost

  Since the program is shareware, you can continue to use the program for
30 days, worry-free. If you like it, and want to continue using it
worry-free, please pay for it. Any program takes a lot of time, testing,
learning, and correcting before it is a good product, and programmers
should get paid for their efforts. If you like this program, please send
something for it, even a token amount. Twenty ($20.00, Canadian) dollars
would be a good starting point.




ͻ
                                                                         
   Chapter 2:             Special Considerations                         
                                                                         
ͼ


*** Keeping everything internal to the program

  From the moment I started developing 64COPY, I wanted to create a very
useful and functional program that the whole emulator community would
enjoy, not only for manipulating C64 files, but general DOS useage as
well. At first, the program was only really useful for C64 files, and had
little functionality, but by the time 2.00 rolled out, most of the
limitations were gone.

  I didn't want to take the same route as the author of Star Commander did
with the external utilities (StarZip, StarLHA, StarLNX, etc). Our design
goals are different where Joe (SC author) will only include functions
*directly* relating to emulation in the program, all else will go as
external utilities. The external utilities do have their place, and I can
only praise Joe for his efforts as I also use them from time to time.
Limiting the program to certain tasks, and leaving the rest for external
programs does cause distribution problems, as you now have to manage
multiple programs, but it does also have its advantages.

  For the immediate future, I will still be developing 64COPY as ONE
utility, trying to encompass everything I come across, but I have the
feeling that my attitude might have to change, as I am starting to push the
640k memory limitation. In the future I might convert the layout of the
.EXE file into an "overlayed" executable, meaning I cannot compress the EXE
file, as I do now. This does have the advantage of using less RAM, even
though the executable might be greater than 640k. It also has the
disadvantage of not being able to run effectively off of floppy, as I have
to do from time to time. Only time will tell what I will do!



*** Screen Layout

  Anyone familiar with Norton Commander will understand how to operate
the program once it comes up. It does takes some familiarity with the
F-keys, and the key definitions for the panels just to get somewhere. Be
patient, as once you learn how to use it, you will find that the Norton
method of file/directory navigation is very powerful!



*** Differences from Norton Commander

  I did model the program after Norton Commander, since I found it to be
the best for file maintenance, and being very familiar with it didn't
hurt either. But modelling it doesn't mean "copying" it. I did not strive
to make it look 100% like NC, only have its operations similar. Some of
the keys don't work the way they do in NC (F9 doesn't bring up the
pull-down menus, there are no pull-down menus, there is no mouse support,
I support the F11/F12 keys, the F2 user menu is *very* different, etc).
Most of the changes, from the perspective of a die-hard NC user will
likely be annoying (at the very least), to downright frustrating. Oh
well, its not meant to be NC, just work like it.



*** Theory of Operations

  Norton Commander works on the premise of "from" and "to" (or "source"
and "destination") directories and drives. Wherever the moveable hilite
bar is situated is the "from" location, the opposite panel drive/path is
the "to" location. This design makes it very easy for the user to move
objects around, since typing in the destination drive/path is not
necessary, assuming the "to" location is already displayed. Functions
such as Copy, Move, Rename/Move and Convert work on this premise.



*** Ctrl-C Emergency Exit

  Ever since the earliest days of 64COPY, I have included an emergency
exit system, but it never has functioned very well. If I have a
badly-coded section which gets into an endless loop (very easy to do in
C), pressing CTRL-C won't get you out of the program. Also, when pressed,
the '^C' string shows up on screen, something which I would like to get
rid of.

  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.



*** Insert-key repeat feature

  For some unknown reason, the INSERT key is one that the BIOS does not
repeat. Making 64COPY do so was an idea I've had for some time, but I
couldn't see a way to program it. Once Star Commander came out with this
feature, I contacted the author and he told me how he did it.
Unfortunately, his method would not work under OS/2 (which I use), but I
figured it was better than nothing. I tried to make it work, but had no
luck in doing so, and gave up. Then, one day, as I was mulling it over, I
had a vision and went right to work. The result is what you see when you
press and hold the INS key. It works under *any* OS that I know of, but has
not been extensively tested. The worst that will happen is it will not
repeat, or repeat too fast, but the key will always work at least once.



*** Dynamic drive letter scanning

  Another nice feature of NC (and most other NC-type programs) is the
ability to detect and display drive letters. It is no great feat to
determine what drives exist in a given system, but what about when
another disk is added by using SUBST, or running under an OS like
95/NT/OS2 and you mount a drive over the network? No problem, because
whenever you press ALT-F1 or ALT-F2, the system is again scanned for all
available disks, and displayed. If its not on the list, its not there.



*** System Requirements

  The *minimum* machine required is a 286, an AT-style keyboard and DOS
3.1. This program should not work with XT's, but might. I have not had
the chance (and really wouldn't want to try) to work on XT's lately, so
no testing can be done. Besides, I use the extended scan codes that the
AT keyboard puts out, and XT's don't (F11, F12).

  The memory requirements are the most important here. Right now, it uses
~420kb of memory, even though when you run 64MAIN by itself and do a 'MEM
/C", it shows the program only using about 340kb. As I continue to add
features (internal editors and the like), the memory useage will continue
to increase. I will run into a wall eventually.

  Disk useage is only a few kbytes more than the program size itself,
since certain files are created automatically by the program. Most of
them are small and inconsequential in size. If you want more info on
them, see the section regarding Support Files.



*** Screen Size Requirements

  Early in the history of the program, I had hard-coded most of the
routines for an 80 column screen, no more and no less. I began to realize
that this was an unrealistic limitation, seeing as 80 columns is only one
of several different sizes that PC video cards can do. I have used 132
columns (albeit rarely), and have also now seen a 90 column mode. I
removed the hard-coded sections, made them flexible, but never had the
chance to test how the program would react to a screen greater than 80
columns, until recently.

  I downloaded some font editors, and one of them included a COM file
called VGA90, which changed the video size to 90 columns. I ran it and
the program seemed to work.



*** Command-Line Switches (/c, /m, /q)

  These options might not seem to useful to the average user, but here
where I work we use them more often. Most used are the /C (for color
mode) and /M (for MONO mode). When this program is run on a laptop (like
the Toshiba with gas plasma display), sometimes the screen is almost
unreadable since the contrast between colors is not very good. Using the
/M switch forces the program to use only black and white, but I don't
change the video mode to mono.

  You can also use the /Q (quiet) switch to disable the "Welcome To..."
startup dialog box, if it annoys you. All of the switches can be combined
any way you like.



*** Panel Limitations

  The original release allowed you to work with directories and T64
images of up to 1499 files (which are incredibly cumbersome to use). I
changed this later on by reducing the file count to 999. The amount of
memory saved could be used for later features, and I have only
encountered *one* directory with >600 files, which was a Netscape CACHE
directory.




ͻ
                                                                         
   Chapter 3:                  Operations                                
                                                                         
ͼ


*** Basic Panel operations (keys, shortcuts, etc).

  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.   Use the ESC
key to get you out of almost anything (cancels all dialog boxes, file
copies/moves/deletes/conversions, etc).

  When you press the ALT/CONTROL/SHIFT 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).



*** Copying, Moving and Renaming Files


   * Copy Files (F5)

     Here we can copy files/directories to other locations/drives, or we
     can convert/copy emulator files around. Select the files you want to
     copy, press F5, and, if you need to, change the destination location
     by typing into the line in the window.

     If we are in an emulator file in either panel, we can either be
     presented with a "copy into emulator" window, or a "convert files to
     another format" window. See the next section on "Move Files" for
     more information.


   * Move/Rename Files (F6)

     This key also has multiple uses... you can move the selected files
     over to another location, or you can rename a file. If you have
     selected several files, it is assumed you are moving and not
     renaming. If you have not selected any files, the program has to
     determine what you are attempting to do.

     If you are in an emulator file (D64/T64), several possible things
     will happen, depending on what is being displayed in the opposite
     panel.

     1. If you have another emulator file in the opposite panel (other
        than LNX/PC64), you will be presented with a "copy into another
        archive" window.

     2. If you have a DOS directory open, you will be presented with a
        "convert files to another format" window.

     It seems confusing, but it was the only way to handle the various
     archive formats that exist.


   * Rename Files (Shift-F6)

     Using F6 to rename files under DOS does work, but its not the
     easiest way. Unfortunately, you *can't* use F6 to rename any
     emulator files (inside a D64), so I included a short-cut method to
     only do renaming. From here, you can rename *any* file/directory,
     even the files inside the emulator archives.



*** Convert Files To Emulator Formats (F5,F6,F11)

  In order to convert any C64 file, you first have to go into it by
hitting ENTER on it. 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.

  Once you get the Convert dialog box up, you are presented with a series
of filetypes that you can select from. These are the filetypes you can
convert to. They do not all work the same. When you select anything other
than LNX, *each* file you select will be converted into a separate
archive file, and not all go into one. LNX, however, works differently in
that all the files you select go into the one LNX archive.

  If you press F11 on a ZipCode (#!xxxxxx) or a D64, you will get a
different dialog box, as the program knows what the file is. ZipCodes can
only be Converted into D64's, they serve no other function, and D64's,
when treated as a DOS file, can only be converted into Zipcode's.



*** File Viewing and Editing


   * File Viewer (F3)


   * Text Editor (F4)


   * HEX Editor (ALT-F4)


   * D64 Bam Editor



*** Working with Emulator Images


   * Create D64 File (F12)

     Press F12, enter the name of the D64 file you want to create, and
     its done.


   * Create T64 File (Ctrl-F12)

     Press CTRL-F12, enter the name of the T64 image you want, the size
     of the directory (in # of entries), and its done.

     Although the program allows you to work with T64 images of up to 999
     entries, the C64s emulator will only read the first 99 (and maybe
     less, I don't remember). This makes the creation of large images
     (greater than 99) basically useless, but you do have the ability to
     store large numbers of files if you need to. The size will always
     default to whatever is defined in the Configuration window.

     Still on the topic of T64's, 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 have
     been warned.


   * Create X64 File (Alt-F12)

     Press ALT-F12, enter the name of the X64 file you want to create,
     and its done.


   * Change D64/T64 Image Labels (Shift-F10)


   * Swap D64 Filenames (Shift-F5)

     Select two filenames (and only two, no more, no less) that you want
     to switch positions, and press SHIFT-F5.


   * Create D64 File Separators (Shift-F7)

     Simply position the hilite bar over the filename position where you
     want to insert a separator ("----------------") file and press
     SHIFT-F7.


   * Delete D64 File Separators (Shift-F8)


   * Customize D64 central directory (Shift-F2)



*** Miscellaneous File/Disk Functions


   * Create New Directory (F7)


   * Search For Files (Alt-F7)


   * Display Free Disk Space (Ctrl-L)


   * Delete Files/Directories (F8)


   * Print Files (Ctrl-F3)


   * Show Total Directory Size (Alt-F5)


   * Change File Attributes (Ctrl-A)



*** Miscellaneous Functions


   * Help Window (F1)

     In most functions, press this key to bring up a help screen, showing
     you key assignments, shortcuts etc.

     Unfortunately, this is one of the weakest aspects of 64COPY. I have
     never worked on a central help window, one which was common to the
     whole program. My goal is to include a .HLP file, with all the
     function help in that file, but it is still a ways away.


   * User Menu (F2)

     Here is where you can define a shortcut for the command-line to
     execute. Instead of having to enter a command over and over, you can
     define it here, and then simply select it.

     This feature is not the way most of the Norton-like programs work.
     It was programmed in when the program was still young, and I wanted
     something simple. Norton uses .MNU (short for menu) files to define
     what you want on the F2 menu. Each of these .MNU files can call
     other MNU files (cascade).


   * Exit Program (F10)

     This function seems fairly obvious as you use it to quit the
     program. However, several things will happen if you do quit.

     1. All the open file handles will be closed
     2. All the windows will be removed
     3. Mouse pointer is disabled
     4. All the support files will be written, such as the INI, MAC and
        CLR files. If the setting on the Configuration screen for "Save
        Settings" is not checked, this part of the exit will not be
        executed.
     5. You are then left at the DOS prompt


   * Display Opening "Welcome" Banner (Shift-F12)

     Including the "Welcome..." window was a blatant form of advertising
     on my part, but I wrote the program so I am entitled to. However,
     even I get tired of seeing my name when the program starts, so I
     included several ways to prevent the window from coming up.

     One is in the Configuration window. Checking this option will enable
     the window on startup, whichi is the default setting. The second is
     by using a command-line switch when starting the program. If you
     include the '/Q' or '/QUIET' switch (any case), the window will not
     be displayed even if the configuration setting says to display it.


   * Screen Saver

     After a period of inactivity whose time length is defined on the
     configuration screen (default is 5 minutes), the screen saver will
     start. There are a number of modules that are randomly selected
     from, and every minute a new module will be run. If the delay time
     is set to 0, then the saver will never automatically activate.

     There are also "hot spots" on the screen which also control the
     screen saver. Rolling the mouse to the top right corner (called the
     "save now" corner) will activate the saver after a delay of about 1
     second. Rolling it to the bottom right (called the "save never"
     corner) will disable the saver.



*** Check D64/T64 Files (Alt-F3)

  This, to me, is one of the most useful features of 64COPY. When inside
a D64/X64 archive, pressing ALT-F3 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 find the CheckD64 very useful when verifying the integrity of files I
download from any of the FTP sites (like ARNOLF.HIOF.NO). 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.



*** Check ZipCode files

  This is not a "check & correct" function as it only checks and reports
any possible errors it finds. If you are having problems UnZipCoding a
set of files (due to some error reported), try running CheckZipCode on
the files and see where the error comes up. If you know the format of
ZipCode files, it is *possible* to fix them.

  ZipCode's have three basic compression methods (see the FORMATS.TXT
file for much more information). If the track is incorrect, out of range,
or the sector is out of range then an error will be reported.

  The display also has a detailed listing of the RLE compression used.
When an RLE sector is encountered, you are shown this ("T/S, RLE
Compression, length xx, REP code $xx). The REP code is what to look for.
As long as this code is not encountered in the following bytes, we have
normal sector data. As soon as this code is hit, the next two bytes are
decoded as compressed data. This is displayed as "REP sequence, length
xx, fill byte xx".



*** Unlist Basic Program (Shift-F3)



*** Disassemble C64 6502 File (Shift-F4)



*** Filename Conversion Method (PC64)



*** Panel Operations


   * Turn Panels On/Off (Ctrl-F1/Ctrl-F2)


   * Change Panel Drive (Alt-F1/Alt-F2)


   * Switch Panels (Tab)


   * Re-read Panel (Ctrl-R)


   * Swap Panels (Ctrl-U)


   * Toggles Panels On/Off (Ctrl-O, ESC)


   * Jump to Root of Drive (Alt-Backslash)


   * Toggle Panel File Selections (Keypad Star)


   * Select/Deselect Files with Pattern (Keypad Plus/Minus)


   * Select/Deselect All Files (Alt-Keypad Plus/Alt-Keypad Minus)


   * Panel Bar Movement


   * Select Single Panel Files (Insert)


   * AltKey Filename Matching Shortcut


   * TAB key auto-reread panels



*** Command-Line Operations


   * Home


   * Page Up


   * Page Down


   * End


   * Cursor Up


   * Cursor Down


   * Execute Command Line (Return)


   * Filename Completion (Tab/Alt-Tab/Ctrl-Tab/Shift-Tab)


   * Display/Select Command History (Alt-F8)


   * CTRL-ENTER shortcut adding filenames to command-line



*** Program Configuration


   * Change Program Colors (Ctrl-F6)


   * Change Configuration (Alt-F6)

     Here we can alter some of the programs features. Changing the
     external editors, emulator file conversion defaults, confirmations,
     etc. Active functions are usually denoted with an 'x' in the '[ ]'
     box. Text areas have a small entry area.

     This feature continues to evolve. Eventually it will be separate
     screens for specific areas of the program you want to modify, like a
     separate screen for screen saver options, one for emulator file
     conversion, one for confirmations, etc.


   * Edit .EXT Extension File (Ctrl-F4)

     This is a hold-over from Norton Commander. On one of its menus is a
     item called "Extension Edit", and when selected it would bring you
     into an internal editor, with the extension infomation displayed.

     I wanted to simulate this feature, but without a working menu
     system, I had to include it on the keyboard menu instead. Being on
     the CTRL-F4 key, it fits right in with the rest of the Editor
     family, all of them being on various F4 keys (ALT-F4 Hex edit, F4
     text edit).



*** Supported File Formats


   * X64, D64, T64, LNX, ZipCode, P/S/R/Uxx (PC64)


   * Why X64 Support?

     At the time I wrote 64COPY, X64 was the main emulator on the UNIX
     platform, and I was asked to include support for it in my conversion
     routines. It was a simple enough change to make, but likely it is
     not used much.

     Shortly after this another emulator came out called VICE. It is the
     replacement for X64, and while it supports the X64 format, it also
     supports D64 (and likely T64). It would be a lot of work to remove
     the X64 support code from 64COPY, so I will just leave it in for
     now.


   * What about ARK, LHA?

     ARK is such an unusual format to run across that I won't (likely!)
     add support for it. It is similar to LNX, so supporting it won't be
     too difficult, but for now I have other things to work on.

     LHA is a compressed format, and as such I would need to get the
     source code, and see if it is possible to shoe-horn it into the
     program.

     Since there exists other programs to work with both of these
     formats, I would go with them instead. Joe Forster (author of Star
     Commander) has written several utilities, which are distributed with
     Star Commander, for handling most of the formats. To extract files
     from ARK file into D64's, use StarARK. To extract LHA files into a
     D64, use StarLHA.


   * Read the FORMATS.TXT file

     This very large text file is included with the program. In it is a
     very detailed description of every emulator and native C64 format I
     could find. If you ever wondered how a certain file was laid out, or
     are working on a program to manipulate a specific format, read it.


*** Macro Functions


   * Record Macro (Ctrl-F9)

     This is the "control center" for the macro capability. Here was can
     select the macro we want to change to, record, or remove.

      * to remove, press the DEL key.
      * to rename, press F1
      * to record, press F8
      * to set which one you want to work with, press RETURN

     When we want to record, position the hilite bar over the macro you
     want to alter (or an empty one). Press F8 to Record, and if the
     macro is not named, you *must* enter a name for it. Once entered,
     the message "Macro Rec" will appear in the menubar, indicating macro
     recording is active.

     You can record up to 175 keystrokes per macro. When you have reached
     this limit, recording is stopped, and you are informed that you have
     reached the limit of the macro.


   * Play Macro (F9)

     This will start executing the macro you have selected in the CTRL-F9
     Macro window. When a macro is running, the message "Macro Play" will
     appear in the menubar, indicating an active macro. If the
     Configuration setting for repeating macros is enabled, the macro
     will run continuously!


   * Integrity if the .MAC file (CheckSumming)

     It was important to me to be able to validate the integrity of the
     MAC file, and so adding a checksum value to each macro was essential
     to the design. If an error is discovered (when starting up the
     program) in the MAC file, all macros past the error will be lost.



*** Common Clipboard

  This program also incorporates a "clipboard" for copy/pasting
information between the various editors (such as the Text, HEX, D64 and
Directory editors). As an example, you can copy data from any of the HEX
editors and paste is back anywhere. Text can be copied from the Text
editor to be pasted into the HEX editor.

  Probably the most useful thing here is the pasting of HEX data into the
Text editor. Normally, you would get gibberish, as HEX information is
rarely text-readable. 64COPY will know when you are trying to do this,
and offer to convert the HEX data into displayable characters in the form
of a HEX dump, in ASCII format. You will then end up with a listing like
"00 5F E4 FF C5" instead of unreadable codes.

  I have defined three types of information that the clipboard
understands. First is "TEXT". This is the type of data that would be
copied from the text editor. Second is "HEX", from either the HEX editor
or the D64 HEX editor. Third is "DIR", used in the D64 Directory Editor.
This is basically HEX, but has some subtle changes. The program knows
what type has been copied into the clipboard, and will warn you when you
try to paste non-native data (HEX into TEXT, TEXT into DIR).



*** Video Changes

  Norton Commander has this feature in it (it's under one of the menus, and
is called EGA Lines), but mine operates a little differently. In Norton
(and almost *every* clone I have seen), using EGA Lines will toggle from
25->43 and back to 25 (in EGA mode), or if you are in 50 line mode (VGA),
it will do 50->25 and back to 50. I didn't like that feature since in order
to use 50 line mode (assuming you started in 25 line mode) I would have to
issue the command "mode co80,50". I wanted the ability to use whatever mode
was possible, so I rotate through the modes, 25->43->50->25, etc.

  There may also come a time where the screen may get corrupted (shifted
up one line). Doing an ALT-F11 will remove all windows, and redraw the
entire screen. This will not happen because of the program but due to
*external* (i.e. system) problems.



*** WipeFile Feature

  This is one of those "features" which came about because of how we use
the program here in the hardware shop at the University. When doing
maintenance on someone elses system this program will be used as a
navigator/file manager, and also as a backup/recovery program (from one
hard disk to another, by whatever means). When we have finished with the
program, it is prudent to remove all evidence of its useage. It is also
useful for removing *any* file you don't like, as there is *NO WAY* you
will ever get the data back. Just try it!



*** Opening Files in "Sharing Mode" feature.

  As of version 2.20, I converted many of the file reading operations to
"shared" mode, where several applications may open the file at once.
Note, this really only applies to that are being read only. If a file is
going to be modified, the file is accessed normally. This doesn't work
all the time as PC64, when it opens a D64 in its File Manager window
opens it in read/write mode, meaning I can't open it up in 64COPY.
However, using "shared" mode means I can now read (not edit) log files
which are open by the OS for viewing, which was not possible before. If a
file is not openable in shared mode, I can't open it.




ͻ
                                                                         
   Chapter 4:                   Trivia                                   
                                                                         
ͼ


*** External Optional Support Files

  When the program starts, several files are looked for to provide
options and defaults. Such files are the .INI and .MAC.

  The INI file contains all of the ALT-F6 configuration information, as
well as the last directory used, program colors and F2 User menu
definition strings. The INI file is also program-version dependant
meaning each version of the program usually has its own INI file. I do
change the structure of the file from time to time, generally to make
room for more configuration options, and therefore the version-checking
is necessary. If you have just replaced an old version of 64COPY with a
newer version, you may find that your defaults have disappeared. This
should only happen when I change the internal version number of the INI
file. 64COPY checks the existing INI file for the proper version, and if
it does not match, it uses its internal defaults (just as though the INI
file doesn't exist). When 64COPY exits, the old INI file will be
overwritten with the correct one. You will be informed (by an info box)
that the INI is old and won't be used.

  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 second file looked for at startup is the.MAC macro file. It
contains all the keyboard macro definitions. If it is not found, no
macro's exist. This file contains some error-checking information, to
prevent tampering. If *any* error is encountered while trying to read the
macro strings, all macros from that point on will be discarded. i.e. if
there is an error in macro#2, all macros from 2 up to 5 will be lost. It
is important to have the file intact, since a wrong key in the middle of
an operation might result in lost data, and at the speed the macro runs,
you might not even realize anything is wrong.

  When the program exits, three files are re-created, if they don't
already exist. The INI file will get re-written (with any changes you may
have made), the .MAC file will get re-written, even if there are no
macros defined, and the .CLR file will be made. The CLR file is a backup
of the colors that you may have changed in the CTRL-F6 color
configuration window. When the INI file changes, any colors you may have
changed would normally be lost. If this happens, you can reload the
colors by going into the Color Config window and re-load them.

  The last file used is the .EXT extension file. It stores all the
extensions and what command/program to execute if you hit return on such
a file. I have included a sample .EXT file with the distribution of
64COPY, and in it are some explanations as to how it is laid out. If you
want to edit the EXT file, you can press CTRL-F4 and the file will be
brought up in the internal editor, or you can find it and manually edit
it.

  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.



*** Future Considerations

  I am constantly working on 64COPY, looking for bigger and better things
to do with it. I have some features that I would like to add, but of them
all, two of them would seem to be the most important. They are mouse
support and a substantially improved HELP system. The mouse support is
turning out to be a big job, one that I hadn't anticipated, so it won't
be completed anytime soon. The help system is what I am giving a lot of
thought to, and will be top priority.


  * Improved HELP support (via external HLP file), better documentation.


  * Mouse control (part-way done already!) * Native C64 font support
  (especially useful in the D64 Dir Editor) * Save@ and unclosed ("*")
  files validated and/or restored in the CheckDisk routine. * Copying of
  REL files (conversion to other formats, specifically R00) * 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!) * Directory Tree (F10) * Extended D64 format using an
  appended 683 bytes for sector error info * De-Isepic (maybe?) *
  Petascii-ASCII conversion * C64 file compares



*** Quirks

  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 limitation, which effectively
eliminates XT's and many laptops, but I cannot get around this. I have
seen problems with some Zenith 286's as well, but these problems are
scarce.



*** Strengths & Weaknesses

  Out of all the conversion programs out there, I think this one is the
best. Assuming you already have the disks on your PC and simply want to
convert, move or view, 64COPY does it all, internally. You do not have to
run any external converter utils, you simply select what you want
converted, and select the format to convert to. While I think including
some form of 1541-PC communications would be the best thing to add to
this program, it is not my area of expertise, and I gladly leave that to
the other authors (Star Commander, Trans64).



*** What I Use 64COPY For

  Where I work (University of Waterloo, Computing Services hardware
repair shop), I found that I needed a NC-type program but with more
specialized features. We work on a lot of PC's, recovering data from
damaged hard drives, or doing some kind of file system maintenance, and a
multi-purpose utility designed for these tasks was called for.

  I always liked the layout and useability of Norton Commander, and so
decided to follow its operational style, but customizing it for our shop
needs. Such features as "Log DOS copy/move errors" and "WipeFile" were
developed specifically for my use, but I preserved them in the release
version in case others might want to use them as well. If you don't want
them, you don't enable them.



*** Why I Wrote It 

  This could be viewed as one of those "why did the chicken cross the
road?" questions... who really knows. When I started writing it, I was
also learning to program in C, and much of the core of 64COPY was written
during the summer/winter of 1994. It was at first a streamlining of two
small programs I had briefly used, CCOPY and CDIR by David Ashley. They
did the job, but weren't very efficient (no offence to David). I re-wrote
them with a better interface (anyone ever use 64COPY 1.0?), but it only
worked with PC64 P/S/R/Uxx files (which was then called C64Neu, fully
German).

  Then, some of my previously mentioned shop needs became more apparent
and I started working on a more well-rounded program to handle other
operations. 64COPY 2.xx is the result.



*** The windowing routines

  After I released 64COPY 1.0, I started reworking the interface, and
realized I would need some simple windowing routines. I scoured some the
internet site for any development packages or source code. I didn't find
anything I liked, but I did get some ideas. My first attempt was done
using ANSI screen-drawing techniques which were painfully slow but
worked. Once I became more experienced with the PC architecture, I
figured out how to do direct video-buffer writing, and converted all the
ANSI calls to direct screen writes. What a difference that made! I have
been enhancing the windowing code ever since, but mouse movement is
something which continues to elude me.



*** What About That Mouse?

  As I just stated, mouse movement (for me) is turning out to be a
difficult job to program. I have worked for a while to improve it, but my
knowledge and experience hasn't reached the point needed to get it done.
I will continue to work on it though.



*** What about 1541 support, like SC/Trans64?

  I know the source code for the transfer routines are available for
Trans64 (or at least were). I have thought about using the code, but if I
had some trouble with it not working on some machine, then I would not be
able to fix it, as I didn't write it, and would not be familiar with it.
Writing this type of program (port I/O) is not my forte, so I will not
likely write the code myself, either.



*** About the Watcom compiler

  I use to write 64COPY in Watcom C 6.0, then upgraded to version 8.0,
skipped 9.0 and went straight to 10.0. The only drawback to using Watcom
is I can't seem to find any IDE for DOS, nor does it come with a
windowing system like the Borland C compiler. That was one of the reasons
for writing my own windowing routines... I had to. It also has no HELP
system like Borland, but it produces fast and compact code (and its cheap
here at the University!)



*** Whats included in the distibution ZIP?

  The following files *should* be with the ZIP file, wherever it is.
Later versions may have more files, older versions may have only a few of
the ones mentioned.

   64COPY.EXE - Program loader for 64MAIN.EXE
   64MAIN.EXE - Main executable (the only *essential* file in the archive)
   64COPY.EXT - Supplied sample EXTensions file
   MANUAL.TXT - 64COPY user manual
  HISTORY.TXT - A complete history of program changes
  FORMATS.TXT - A detailed description of the C64 and emulator formats
  CHANGES.TXT - Program changes for the most recent release
  FILE_ID.DIZ - A short description of the program (used by BBS's)




ͻ
                                                                         
   Chapter 5:                 Miscellaneous                              
                                                                         
ͼ


*** How-To Quick Reference

  Not done yet.



*** Command Reference

  Not done yet.



*** Version Changes

  I will continue to document version changes as they are released. You
can find most of the changes I have made in the document HISTORY.TXT. Any
changes made in the latest version will be in the file CHANGES.TXT.



*** Contacting Me

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

