[comp.sys.atari.st] speeding floppies?

CSYSMAS@OAC.UCLA.EDU (Michael Stein) (12/23/87)

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

dsmall@well.UUCP (David Small) (01/02/88)

In the referenced article, there's much discussion about speeding
up floppies from Michael Stein.

There's no point in using a disk with interleave on it on the ST; the
ST is more than capable of 1:1 reads and writes. Since the ultimate
limiting factor is the head rubbing against the media at a certain speed,
and the ST is doing r/w as fast as physically possible, there's no
possible gain there.
  It is dangerous to remove the seek verify bit in the manner you have.
Let's say you step to a new track. The head rattles back and forth
awhile as it settles. During that time it is reading well enough to
return track dta to the controller, yet the head is still wobbling. If you
try a sector write, which lasts 16 msec, during this time, it's written in
a yo-yo pattern on the disk -- and is often unreadable the next time.
  This comes from hard experience; I did this on the Magic Sac Motivator, and
could consistently kill the first sector of each track. Weird, but true.
  You're right that a full disk rev is saved. A better way is to just twist
the track two sectors around, leaving one sector (#9 or 10) for the settle
time and one sector (#8 or 9) for the seek verify. Then you don't lose any
time at all track to track, and keep full compatability with unmodified
ST's. That's how we did Twister.
   As for using the index pulse as the delay time for seek, well, maybe. On
9 sector tracks you'll get away with it.. remember, 16.667 millisec per sector.
On 10 sector tracks you won't, there is no room. But worse, the step only
happens on the next-sector-read command, which may take awhile to
happen, all of which time the disk is spinning.
  Since you're stuck with 30 msec head settle, and lots of machine have
seek-with-verify, I think it's the optimal solution to twist the track by 2.
You just can't physically get data off multiple tracks any quicker without
speeding up the RPMs of the drive.

  .. perhaps we should plug it into a 220 Volt outlet?

 -- Thanks, Dave

dave small/bottlewasher/data pacific inc