Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!rpi!netserv2!deven From: deven@rpi.edu (Deven T. Corzine) Newsgroups: comp.sys.amiga.tech Subject: An asynchronous track-by-track disk copier... Message-ID: Date: 13 Apr 90 11:12:33 GMT Distribution: comp Organization: Rensselaer Polytechnic Institute, Troy, NY Lines: 62 As an experiment, I am going to split apart the long posting I already made into its component subjects, so people won't be so put off by the length, hopefully. (and they can easier read the parts that interest them.) I am doing this because I am looking for feedback, and have a number of difficult questions for which I am seeking answers. I have been working on writing an asyncronous track-by-track disk copier recently. I have a working prototype, but bugs remain. This posting is to describe the usage of the copier and to solicit feedback on how it may be improved. When the program is run, it opens the trackdisk units for both drives and inhibits the drives from AmigaDOS intervention. The program uses DF0: and either DF1: or DF2: -- tries DF2: if DF1: fails. Single drive copies are not supported yet, but will be soon. It then prompts for source and destination disks in the drives. A "source" disk is defined as a write-protected disk, and a "destination" disk is defined as a write-enabled disk. Any disks in the drives when it prompts are considered "invalid". Ejecting and reinserting a disk validates it. Pressing return in response to the prompt will validate any disks in the drives. The copy does not begin until neither drive contains an invalid disk, and there is at least a valid source disk in either drive. If there are two valid disks in the drives with the same protection status, the user is prompted to fix the source or destination disk, as appropriate. The copier starts reading the source disk, and when the destination disk is available, will simultaneously write to the destination disk with whatever has been read already. It will keep reading until it has read the entire source disk, or until it runs out of memory for tracks, at which point it will wait for a track buffer to be available after a write so it can continue the read. Track buffers will be freed after writing unless a read is waiting for a track buffer. (Which only happens when there is not enough free memory to simply allocate a new buffer.) If the destination disk is not in the drive, it will read from the source disk until it is out of memory, or until you insert the destination disk, when it will start writing and freeing the dynamic buffers for further reads. The entire copy operation will run to completion even with memory for only a single track buffer, albeit synchronously. A Control-C will cleanly abort the diskcopy. Unfortunately, in practice, the blitter is a bottleneck in the I/O, since the trackdisk.device uses the blitter for encoding, decoding and shifting the tracks. Hence, the async copy tends to run lockstep waiting for the blitter, which is beyond my control. Perhaps ECS or 1.4 trackdisk might be better. Anyway, it would have been nice if an asynchronous copy could have done at the speed of a format, (i.e. about 50 seconds) but actual timings have always been between 83 and 84 seconds, which is still pretty good. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.