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 for the latest changes, and the HISTORY.TXT file for the changes to previous versions. 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. * 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 drive(s) for a certain file (ALT-F7) * Many user definable options (ALT-F6) * 6502 disassembler (SHIFT-F4) * D64 sector editor * BASIC unlister * Built-in text viewer/HEX editor (for DOS files). * full retention of last 15 command-line commands (Alt-F8) * screen saver, with several modules * 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 .CHK, where 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 and greater (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) can 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. A text viewer and a HEX viewer/editor are now included, but the text editor 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, and whether to use the internal or external one. 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 Text 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 still like to make user-definable. * Keyboard repeat rate/delay * Confirmation on delete * Mouse tracking speed * 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. :-)