ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º º º 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 .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. *** 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. :-)