home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
GEMini Atari
/
GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso
/
files
/
diskutil
/
ff32bin
/
fastflop.doc
< prev
next >
Wrap
Text File
|
1993-08-05
|
11KB
|
224 lines
FASTFLOP: Speeds floppy disk I/O
Copyright 1989 by Robert Fischer
FastFlop is a program which speeds up reads and writes to
your floppy disks. Unlike Twister, it works with normal-format disks.
FastFlop does not speed up formatting or the few
programs (mostly games) which read and write large quantities of data
directly with Floprd() and Flopwr().
To install FastFlop, run FASTFLOP.PRG first in the AUTO folder. A
sign-on message should come on. The program may tell you that you
have an unsupported version of the ROMs, in which case you will have
to get a new version of FastFlop. Contact me or read, comprehend and
act on the file REBUILD.DOC if your ROMS are different. FastFlop
currently works on the following ROMs:
TOS version | Date
-------------+-----------
1.0 | 11-20-85
1.2 | 4-22-87
1.4 | 8- 8-88
1.4 | 4- 6-89
If your disks are Twisted and you plan to use FastFlop, reformat the
disks so they are untwisted. For reasons explained below, Twister
plus FastFlop is slower than TOS 1.0 alone. Note that TOS 1.2 and
above automatically twist disks when formatting from the desktop, so
some other format program must be used if you have a later version of
the ROMs. The accompanying program called FORMAT.PRG is one such
possible program.
I (Robert Fischer) MAKE NO WARRANTIES, EXPRESSED OR IMPLIED, ABOUT
FASTFLOP, AND I AM NOT LIABLE FOR ANY DAMAGE RESULTING DIRECTLY OR
INDIRECTLY FROM ITS USE OR MISUSE.
The rest of this document is technical and need not be read.
Here's how FastFlop works:
Let's say that TOS (without FastFlop) needs to read many sequential
tracks starting at track 1 on a disk. Let's also say the drive just
finished reading track 0. It first positions the head on
track 1 (taking 2 ms, or .002 seconds) and waits 30 ms (.03 sec) for
the drive head to settle down, since moving the drive head makes it
vibrate. Since about 10 sectors fit on a track and the disk spins at
300 rpm, or 5 rev. per seconds, then .03 seconds is the time it takes
for about 1.5 sectors to pass across the disk head. Since the read
request starts at sector 1 and assuming that the drive head was on
sector 1 before it waited the 30 ms, the controller has to wait about
80% of a track before it can read anything. So, after waiting not
only 30 ms, but also another 170 ms then reads track 0 and seeks to
track 1. Clearly, this gives about 50% efficiency. For every two
times the disk turns around, data is only read on one revolution.
FastFlop tries to start reading the track at the place the drive head
is currently positioned. It may read track 0 starting at sector 1 and
seek the head just as before. Now the drive head is on sector 3, so
it starts reading at sector 3 and reads sectors 1-2 when those two sectors
come around again. It starts reading the next track at sector 5, and
so on.
There is one problem with the approach above -- as was stated, when
the drive head seeks from track to track, it must wait thirty
milliseconds or the drive head to settle before it can read or write.
It seems natural that if the head is already on that track and does no
seeking, that it shouldn't have to wait when you use floprd() or
flopwr(). Unfortunately, BIOS was programmed so that every floprd()
or flopwr() call waits that 30ms for the drive head to settle down,
even if the drive head is already on the track which is being read.
FastFlop reads most tracks in two blocks and the Atari BIOS prevents
doing this with any efficiency. So, I had to write FastFlop so that
it copies the BIOS floppy driver from your ROMs (floprd(), flopwr(),
and a few support routines) and then makes the following little patch
to it:
cmp dcurtrack(a1), d7 ; already on correct track?
bne gotover ; (no), wait the 30 ms
move.w #$10, d6 ; (yes) use "seek w/o verify"
(The "verify" referred to here is the "verify" command in the Atari
Hardware manual which causes the disk drive to wait 30 ms.)
All memory locations about where the floppy disk driver is, or where
to make the patch are, of course, undocumented. Be careful that many
different ROMs of the same TOS version number may have their magic
locations in different places. I am hoping that there are no two
different ROMs with the same date and version number. FastFlop has a
table of the locations for many of the ROM versions (listed above).
The technical file INSTALL.DOC tries to tell an experienced programmer
how to make FastFlop work on his brand new TOS 1.6 (or whatever).
I really do not know everything about how the floppy drive works, or
about the safety of this approach. What I do know is that FastFlop
_does_ wait 30 ms for the drive head to settle down when it actually
seeks. Possibly (but this is unlikely), the drive head must settle
down even when it doesn't move tracks. What I _do_ know is that I've
used FastFlop since March, 1987 and have had NO problems with it.
FastFlop and DCFormat
There's a handy Public Domain disk formatter from Double-Click
Software, called DCFORMAT. In addition to formatting disks faster
than I know how to format them, it gives you the option of a "fast"
format, making normal TOS read and write disks at approximately twice
the speed of TOS 1.0 disks, and faster than FastFlop could ever be.
DCFormat does this by writing erroneous sectors at the end of each
track, causing the disk head to immediately skip to the next track and
start reading without waiting 30 ms to settle down. I personally
believe that the slight time advantages of this approach does not
justify the risk of losing data, but other people may prefer DCFormat.
When presented with a DCFormatted disk, FastFlop will read it at the
same speed as it will read a regular disk, PLUS it will circumvent the
not waiting 30 ms. To explain why, assume that the drive just read a
track on a DCFormatted disk. It encounters the error at the end of
the track and skips to the next immediately, ready to start reading at
sector 1, which is right under the drive head. FastFlop, allowing
time for the drive head to settle down, will tell the drive to start
reading at sector 3. Thus, in spite of the error on this disk which
allows fast reading, FastFlop will still wait the 30 ms, reading
DCFormatted disks exactly the same as it would regular disks.
FastFlop and Twister
As stated above, Twisted disks are slower with FastFlop than normal
disks. To understand this, one must understand how Twister works.
Very simply, Twister is like FastFlop in hardware. FastFlop reads the
tracks starting at whatever sector it believes will be the most
efficient, and Twister simply formats the disks so that sector 1 (the
one read first by normal TOS) will be under the drive head when it is
ready to start reading a track. So, when reading a Twisted disk,
FastFlop may start reading at sector 3 on a disk where sector 3 is
at the same position as sector 5 on the previous track. Because of
this, FastFlop wastes time on a Twisted disk. It's as if Twister and
FastFlop are both "twisting", resulting in an "over-twist".
Maybe some clever programmer could figure out how to tell a Twisted
disk and read it efficiently. The problem is telling a Twisted disk
when reading the boot sector in Getbpb(), or something. I've seen
CHKFMT.PRG, which can tell a twisted disk after inspecting over one
track's worth of data! If I could tell easily, I could simply turn
off most of FastFlop when working with a Twisted disk, speeding up the
Twisted disk to FastFlop speeds where Twisted disks don't work that
fast.
According to the above simple analysis of reading a single-sided disk,
Twister and FastFlop should be the same speed. Writing is a different
story, because TOS verifies what it just wrote. This is _NOT_ the
same verify that was talked about above, but the flag at location
0x444 of your Atari. (Some people like to turn this feature off
because disks will write faster, but others feel that turning it off
is like playing Russian Roulette... I always leave it on.)
The real speed comes with FastFlop when the disk drive must do many
operations on one track before moving the head. For example, writing one
track on a double-sided disk takes four operations on the same track!
(Write side 0, Read side 0, Write side 1, Read side 1). Because
Twister only speeds things up when seeking from one track to another or
changing from reading or writing on one side of the disk to the other,
it starts to really slow down compared to FastFlop when doing
operations other than reading a single-sided disk.
Timings and Comparisons
Following are some real-time results from running the accompanying
DISKTEST.C, which I ran on my 1040ST with TOS 1.4 in ROM. It requires
a double-sided drive. With the accompanying DSPEED.C, I clocked my
drive at exactly 300 RPM. For each run, DISKTEST turns on the drive
and sets the disk head on the first track to read or write. Then, it
reads or writes 20 tracks of data 10 times over, recording the time
used and computing the average time per track in milliseconds.
The disks for the "Twister" run were formatted with the TOS 1.4
desktop, _not_ with the original Twister by Dave Small. The last two
timings show how FastFlop interacts with Twisted and DCFormatted
disks.
/ Single Side \ / Double Side \
| Read | Write | Read | Write |
-----------------+-------+-------+-------+-------|
TOS 1.0 | 400 | 805 | 805 | 1595 |
Twister | 265 | 665 | 495 | 1300 |
DCFormat | 205 | 415 | 410 | 820 |
FastFlop | 250 | 505 | 480 | 1010 |
-----------------+-------+-------+-------+-------|
Fflop + DCFormat | 240 | 510 | 480 | 1015 |
Fflop + Twister | 470 | 870 | 860 | 1635 |
-----------------+-------+-------+-------+-------+
As was explained above and can be seen from the table, FastFlop plus
Twister is a very slow combination, even slower than TOS 1.0 alone.
It surprised me that it's THAT slow, but that's what my tests show...
If you use DCFormat's fast format option and you don't personally
believe that it's a bad idea, then continue using it and forget
FastFlop. As the tables show, FastFlop + DCFormat works the same
speed as FastFlop, and slower than DCFormat.
If you were using DCFormat and are not sure if it's safe, you don't
have to reformat your disks. DCFormatted disks are "safe" to use with
FastFlop, meaning that FastFlop forces the drive head to settle down
for 30 ms before reading, even on DCFormatted disks, which try to
circumvent this necessary step.
FastFlop by:
Robert Fischer
80 Killdeer Road
Hamden, CT 06517
(203) 288-9599
E-mail: fischer-robert@cs.yale.edu