Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!cornell!batcomputer!braner
From: braner@batcomputer.tn.cornell.edu (braner)
Newsgroups: comp.sys.atari.st
Subject: Re: A challenge to you disk experts
Message-ID: <1895@batcomputer.tn.cornell.edu>
Date: Sun, 21-Dec-86 02:41:10 EST
Article-I.D.: batcompu.1895
Posted: Sun Dec 21 02:41:10 1986
Date-Received: Mon, 22-Dec-86 05:36:41 EST
References: <1866@batcomputer.tn.cornell.edu> <492@atari.UUcp>
Reply-To: braner@batcomputer.UUCP (braner)
Organization: Theory Center, Cornell University, Ithaca NY
Lines: 48
Summary: Why I don't like file-by-file copy

[]

> [Allan Pratt wrote that file-by-file copy is OK, just have coffee...]

File-by-file copy of a whole disk, especially when there are many small
files on the disk, not only takes a long time (no big deal) but also
puts a big load on the disk drive (including a lot of (unnecessary, in
my view) head movement back and forth over the tracks).  My home computing
is critically dependent on the one drive in my 1040ST, and I do my best
to make its job light.

> [suggestions about special drivers to read SS disks expanded to
>  a nonstandard DS format]

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.

So I would still like to see a realization of the programs I described.
The more urgent one is a real fast AUTOCOPY, and I would write one if
I knew the way to read a bunch of tracks as fast as possible (ever used
STCOPY? :-).  The version of AUTOCOPY I posted recently already uses a
27K buffer, and will not be very much faster just by reading tracks instead
of files.  (It now takes me about 55 seconds of disk-turning time from
the time I turn on the ST until all my usual stuff is on the RAMdisk ready
for use, including micro-C-Shell, microEMACS, and Megamax compiler, linker
and libraries.  Not bad, but far from the theoretical limit!)

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.
Also, when possible, copy a few large files rather than many small ones.
In extreme cases it may be faster to transfer an ARC file and ARC.TTP
and then extract the files on the RAMdisk (an operation easily incorporated
into the login file of the shell you run off the RAMdisk).

- Moshe Braner

PS:  I would love to see a program that allows the use of programs for
one monitor (b&w or color) with the other.  But I'm afraid the recent
suggestion (process a video line during Hblank) won't work, since there
isn't enough time then even for an optimized AL routine.  Perhaps it
could be done during Vblank, and if not the whole screen, then part of
it each time.  E.g. if I'm using the b&w monitor (70 frames per second)
and transfer the color (logical) screen (with some translation) to the
physical screen, one QUARTER each Vblank, I would still get 17.5 full frame
redraws per second, quite enough for most purposes.