prindle@NADC.ARPA (05/07/84)
(let me try that again - my mailer, for some reason, sent out the un-edited copy instead of the final!!) There are numerous public domain backup programs, most of which utilize the standard kernel functions to fetch bytes one at a time from the serial bus and write bytes the same way. These typically take 25 to 30 minutes to backup a full disk, slightly less if they blank the screen and utilize the slightly shorter interbit interval on data from the 1541 to the 64 when the 1541 is sent the "UI-" (VIC-20) command. SuperCopy, a commercTelecommunications, directly accesses the serial bus I/O port on both the 64 and the 1541, and can backup a disk in approximately 7 minutes; error checking is substantially less than when using the kernel and the 1541 DOS though. Warning: do not use the "Allocated Block" backup option of SuperCopy version 2.0 (the latest available as of this date) unless you fix their bug, or it will put the wrong ID on your copied disk (a little time bomb which may cause the disk to self destruct sometime in the future!). You'll have to change the byte at $19C8 from AA to AB to fix the bug, but this is not an easy thing to do. Better still, a public domain program from the Compuserve Commodore Programmer's special interest group called 4MINUT.IMG (I call it 4 MINUTE BACKUP) beats the pants off of them all; it only works on a single drive, eschews all error checking, blanks the screen, formats as it writes, never stops the drive motor, and can't be stopped without hitting the reset button, but amazingly, does the job in a tad over 4 minutes if you can switch disks (3 passes) like lightning. If you are very confident that the disk you are duping and the new diskette are error free, this is the one to use; other- wise, it's best to stick with one of the 25 minute programs or get two drives and shave that down to 15 minutes or so. Frank Prindle Prindle@NADC
prindle@NADC.ARPA (05/11/84)
It seems that SuperCopy and 4 MINUTE BACKUP both have a bit more error checking than I gave them credit for in my previous note, at least for hard read errors on the source disk. Frank Prindle Prindle@NADC