🚀 go-pugleaf

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.