Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!orchid!egisin
From: egisin@orchid.UUCP
Newsgroups: comp.sys.atari.st
Subject: Re: Disk R/W times for large files
Message-ID: <9682@orchid.UUCP>
Date: Fri, 10-Jul-87 15:25:14 EDT
Article-I.D.: orchid.9682
Posted: Fri Jul 10 15:25:14 1987
Date-Received: Sat, 11-Jul-87 13:40:41 EDT
References: <383@uop.UUCP> <781@atari.UUCP> <1643@batcomputer.tn.cornell.edu>
Sender: egisin@orchid.UUCP
Lines: 19

In article <1643@?>, braner@batcomputer.tn.cornell.edu (braner) writes:
> But my experiments (when modifying microEmacs, etc) show that, with typical
> text files (<50K), a buffer of 9K (one DS track) yields a performance that
> is very close to that of larger buffers.  That is with standard
> ("slow") formatted disks.  (The performance gradually levels off as you
> increase the buffer size through 4.5, 9 and 18K.)

There isn't any point in making IO buffers a multiple of the
track size when using gemdos IO; it is unlikely the file begins at side 0, sector 1.
Making the buffer large is what matters.


I've been using disks formatted with 10 sector/track, and
was wondering if this is within the specs for the floppy controller,
or outside IBM specs, or what. Has anyone had problems with this format?

Does anyone have some C code that does floppy IO at the controller level.
I want to do a "track read". (I don't want assembler, I can get that
from the bios listing).