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: net.micro.atari16
Subject: Re: Floppy Disk Speed
Message-ID: <713@batcomputer.TN.CORNELL.EDU>
Date: Thu, 24-Jul-86 15:57:04 EDT
Article-I.D.: batcompu.713
Posted: Thu Jul 24 15:57:04 1986
Date-Received: Fri, 25-Jul-86 06:43:21 EDT
References: <332@sdcarl.UUCP>
Reply-To: braner@batcomputer.UUCP (braner)
Organization: Theory Center, Cornell University, Ithaca NY
Lines: 25

[]

The ST uses a DMA chip for very fast disk reading. Notice, for example, how
fast a long program loads (listen to the clicks as the tracks go by).
The problem with many programs that read/write files very slowly is that
they do it UNIX style, char by char. (It is buffered somewhat (sectorwise?)
but not enough.) The disk spins as the data is handled, and then is not on
the next sector when it's needed, meaning that everything waits till the disk
goes around almost a whole circle. With 9 sectors per track this causes aprox.
an 8-fold slow-down. This is NOT the way to do it! My new version of
microEMACS includes a method of reading (and writing) files through a big
(18K) RAM buffer (you've got a Megabyte: use it!). The speed improvment is
VERY noticeable. It is almost as fast reading a long text file into the
editor (from floppy) as it is copying the file to RAM disk.

In the future we will all have hard disks, it seems. Then it is even MORE
important to use a good buffering scheme. Personally, I believe that this
should be done at the operating system level, as some sort of disk caching.
The methods that worked for UNIX (with big, fast hard disks and a slow CPU
managing a small (per user) block of RAM) are NOT good for us micro users
(with a great CPU (for one user) and slow hard disks (or worse)). Until
things get better, I do most of my work off a RAM disk (compile and link a
100-line program: 15 seconds! (using Megamax)).

- Moshe Braner,  Cornell Univ.