Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!ucbvax!OAC.UCLA.EDU!CSYSMAS
From: CSYSMAS@OAC.UCLA.EDU (Michael Stein)
Newsgroups: comp.sys.atari.st
Subject: speeding floppies?
Message-ID: <8712222223.AA29981@ucbvax.Berkeley.EDU>
Date: 22 Dec 87 22:15:31 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 68

I have timed the ST floppies with various sector skews on
consecutive tracks.  Here are the timings for writing a 32k file
onto a "just formated" disk (single sided).  The timings are for
a TOS Fwrite of a contiguous 32K storage area (on good boundary)
from assembly.  The timing was done with the TOS 200 Hz counter.

                      times in seconds
                   w/ verify   no verify
standard (TOS fmt)     6.32       3.26
skew 2 (1,3,           6.11       3.08
     3 (1,4,           5.79       2.94
     4 (1,5            5.61       2.76
     5 (1,6            5.43       2.38
     6 (1,7            5.45       2.39
     7 (1,8            5.26       2.21
     8 (1,9            6.49       3.44

6 or 7 might be a good choice (if I was going to use this).

The following were measured (some time ago) using a normal format w/ a
modified TOS routine (1 bit changed):

"fast" TOS             3.375      1.765

The change to TOS consists of removing the "seek verify" bit
from the seek command (just one bit).

This has three effects:

1. The one sector time the verify takes is saved.
2. The head settling time is also skipped (30 ms which
   costs about one more sector time).
3. A seek to the wrong track isn't detected until a read or
   write is tried (both read and write include the seek
   verify operation when they check the ID field).

#1 has no bad effects and saves a full disk rev when sequential
tracks are being read/written (which is a usual case with large
program fetches for example).

#2 sounds bad, however lets look at the actual cases:

a. motor off
   (motor spin up delay is 1 sec, head should settle here)
b. seek to the same track (no actual head movement)
   No problem here.
c. seek to other side of DS disk.
   Same as a.
d. seek to next track (1 track seek = 3 ms seek time)
   The time between sector 9 and sector 1 on a NORMALLY formated
   disk crosses the index point.  There is about 24 ms of gap and
   padding here so the head will settle for at least 20 ms before
   sector 1 is encountered.  I doubt that the heads really take
   30 ms to settle, more like 10 to 15 ms (I don't have the drive
   specs).
e. long seek
   TOS floppy routine could add 10 to 20 ms delay after seek.
   (This isn't a frequent case)

#3 can be fixed with better code in the read/write routines
to handle a previous seek error (which would be detected during
the read or write).

The result of this is that I think it is a mistake to use
skewing.  Corrected TOS routines would run slower on the skew'ed
disks (ie:  all the skew'ed disks would need to be reformated
back to the std fmt to get the fastest speed) and might possibly
have problems with head settling time (#2d above).