Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!mit-eddie!genrad!decvax!tektronix!tekcrl!vice!tekfdi!mhorne From: mhorne@tekfdi.UUCP Newsgroups: comp.sys.atari.st Subject: Re: Disk speeds on Atari ST and Macintosh Message-ID: <756@tekfdi.TEK.COM> Date: Wed, 4-Feb-87 05:07:52 EST Article-I.D.: tekfdi.756 Posted: Wed Feb 4 05:07:52 1987 Date-Received: Sat, 7-Feb-87 09:47:10 EST References: <8701290450.AA16048@cory.Berkeley.EDU> <2165@batcomputer.tn.cornell.edu> <211@mks.UUCP> Reply-To: mhorne@tekfdi.UUCP (Mike Horne) Organization: Tektronix, Inc., Beaverton, OR. Lines: 96 Keywords: disk speed I/O interleave transfer formatter 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 -----------------------------------------------------------------------