Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!mordor!styx!ames!ucbcad!ucbvax!decvax!decwrl!sun!imagen!atari!apratt
From: apratt@atari.UUcp (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Re: A challenge to you disk experts
Message-ID: <496@atari.UUcp>
Date: Tue, 23-Dec-86 14:39:53 EST
Article-I.D.: atari.496
Posted: Tue Dec 23 14:39:53 1986
Date-Received: Wed, 24-Dec-86 00:01:23 EST
References: <1895@batcomputer.tn.cornell.edu>
Organization: Atari Corp., Sunnyvale CA
Lines: 67

> What I would like is to take a SS disk, say "open, sesame" and end up with
> a normal DS disk, that may be used anytime without loading any special
> drivers, just like standard SS and DS disks may be mixed in a session.

The only way I can think of to say, "open, sesame" on an SS disk is to
write a program which would (A) format the second side, (B) compact
the data from its current, all-on-one-side format to the DS
alternating-sides format, and (C) diddle with the boot sector to
inform the system that this is a DS disk.  That would take
considerable head movement (which I take it you want to avoid) but
could be done, and would only need to be done once per disk.  The
formats are just too different to allow some simple changes to make it
all work out.
 
> Hint for making AUTOCOPY (current version) work as fast as it can:
> Put the files to be copied close to the beginning of the disk (simply
> by writing them on the disk first, then the rest of the files...).
> Write them to the disk in the order they are to be copied.

The first suggestion is good: it will minimize the distance from the
directory and FAT to the data.  However, the second doesn't matter.
The head-seek distance is conserved no matter what permutation of
those files you use (provided they are all contiguous and the first
files on the disk).

The thing which will speed up your copy operation the most is a
disk-block caching program like Beckmeyer's hard-disk accelerator.  If
it could be instructed to cache the blocks in the FAT and root
directory, you would only have to read them once for the first file,
and the directory searches involved in opening the subsequent files,
as well as the FAT hits to determine where they are, would be done
without any disk head movement at all.  In that case, it really would
pay to copy the files to the disk in the order they're to be copied to
RAM, because then the head would march across the disk in one
direction, until all the files were copied.

The reason people don't write block-caching programs for floppies is
that they can be asynchronously dismounted: you can pop the disk at
any time.  When you do that, you have to invalidate your cache.  But
to determine that this has been done, you have to ask about media
change.  Sometimes the routine which determines media change has to
hit the disk, to check its serial number (that is, when the state it
"maybe media has changed").  Hitting the disk undoes all the benefit
of having a cache in the first place.  Therefore, people don't write
such caching programs, and you are out of luck.

Finally, the way to read lots of disk blocks without stopping is to use
a large buffer and the GEMDOS system call Rwabs.  The Fread call uses
this to get its blocks.  You shouldn't have to touch it.  If you are
using the runtime library (GEMLIB's fread call), this explains your
troubles.  Also, you mentioned using a 27K buffer.  Why not use a
buffer as large as you can (whatever's left after your ramdisk and
copy program have started)?  You can find out how big it is, and
where it is, by examining your own basepage.

Finally, consider the time you have spent worrying about this.  You
will not make up that much time in saved disk accesses.  Moreover,
head seeking is exactly what disk drives are made to do -- I wouldn't
worry about the wear and tear, especially if you have preventive
maintenance done occasionally -- make sure no screws are loose, speed
is within spec, etc.  Things like that, and head wear, will cause
failures long before your stepper motor gives out.

/----------------------------------------------\
| Opinions expressed above do not necessarily  |  -- Allan Pratt, Atari Corp.
| reflect those of Atari Corp. or anyone else. |     ...lll-lcc!atari!apratt
\----------------------------------------------/