🚀 go-pugleaf

In regards to disk speeds on the ST...

>During this discussion about disk transfer rates, I have not seen
>anyone mention the effects of the interleaf (interleave?) factor.
>By the way, Atari, what is the interleaving factor for the standard
>formatter?

Good question!  The interleave factor AND the formatting (interleave)
algorithm seems to have changed from the disk-based TOS to the ROM
based TOS.  I picked at the original disk-based TOS (from ST Internals)
and it appears to work correctly (true sector interleave), but the 
ROM base version seems a bit wierd.  Try setting the interleave factor
to a fairly large number ( < 32 ) with the flpfmt() call and you will
find your disk reads to approach the 'theoretical' limit as far as
transfer rates are concerned, but you will have a fairly volatile disk!
At least all of the disks I formatted this way were quirky.  I noticed
that as your interleave factor increases (0 < interleave < 32), the
disk read times decrease.  On the original interleave subroutine in
TOS (disk), this shouldn't happen.  If I remember correctly, you will
get sectors numbered 1 2 3 4 5 6 7 8 9 with any interleave factor
greater than 9, meaning any disk formatted with 9 < interleave < 32
will provide the same disk transfer rate.  So, what's the poop: did Atari
change their flpfmt() routine, and if so, why?  

>Some programs take more time than others to process what they have
>just read. If they take too long, they will miss the next logical
>sector and will have to wait one whole revolution to get it.

Bravo!  Someone figured it out!  I have been sitting by quietly while
people have been stating that the ST is SLOW on disk transfer rates,
even though the actual data rate is high.  This is entirely possible, but
it isn't the hardware!  Let's face it, most software for most computers
rarely take advantage of the hardware's full capability.  That would require
more research by software engineers (extremely time consuming)!

Which just happens to bring up another thing:  For those of you that read
this months Byte with the 1040 ST review, you will have noticed the
traditional ritual of roasting Atari (could the ST possibly be a better
machine than the Mac or IBM?  Naaaaaa...) by Byte.  Clearly the 'review'
(har har!) was done by an idiot, or else he would have noticed that Atari
Basic is the pits!  In fact, he kinda liked it!  But look at the disk
reads and writes for the ST that were quoted in the article.  Are you kidding?
Does this tell me anything about the disk transfer capability of the ST?
HELL NO!  It tells me that Atari Basic is the pits, and that is all.  Anybody
interested in an ST that read the review will take one look at those figures
and laugh all the way to the nearest Mac or IBM dealer.  But hey, Byte
says that it "is a good machine with only a few problems".  Byte wouldn't
be slightly biased, would they? 

>If one knows in advance how a particular disk will be used, one can
>tweak the interleave to suit. For example, my original copy of
>ST Raider loads more quickly than my backup copy. You can actually
>hear the difference in the head stepping rate. I think the original
>must have different interleaving, tuned to the loading of programs
>into memory (little processing needed).

Yes, they do have different interleaves.  Not all formatting programs
use the same interleave factor.  

>The standard formatter must strike a compromise. If sequential logical
>sectors are too close, some programs will read (or write) more slowly
>than necessary. If the sectors are spread too far apart, fast programs
>are penalised and have to wait for the sector to come around.
>     Gerry

True, there is some optimum spacing between sectors, though I haven't
dinked around enough to figure it out.  It can be done with just paper
and pencil.

I (unfortunately) haven't had the opportunity to finish writing a
program to do my own formatting, but the concept is simple.  The floppy
controller can do a 'track write' which is used to format a complete
track with a sector layout.  One would only need layout a typical track
in memory (with all of the necessary inter-rec gaps, etc., in place),
tell DMA where the buffer is, then give a 'track write' command to the
floppy controller.  That is all the TOS routine is doing, but you could
play around with the inter-record spacing, interleave, etc.  You could
easily get 10 sectors on a track, and possible 11 if you get rid of
a large chunk of the end-of-track gap, though you get closer and closer
to losing your data in the bit-pit if there isn't enough gap (e.g. when
writing to the last sector on the track, you could wipe out the first
sector, the start of track mark, etc.).

By the way, all of this stuff (including the necessary track layout)
can be found in ST Internals, most of which you will have to get from
the BIOS listing (flpfmt()).  It isn't difficult to understand or decode.

Mike

-----------------------------------------------------------------------
 Michael Horne - KA7AXD             FDI group, Tektronix, Incorporated
 Packet:  KA7AXD@KA7AXD             Phone: 503-626-2647 h, 627-6796 w
 Domain:  mhorne@tekfdi.fdi.tek.com
 CSNET:   mhorne@tekfdi.fdi.tek.csnet@csnet-relay.csnet
 UUCP:    {decvax,hplabs,hp-cd,reed,uw-beaver}!tektronix!tekfdi!mhorne
-----------------------------------------------------------------------