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).