Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!ucbvax!YALE.ARPA!fischer-michael From: fischer-michael@YALE.ARPA (Michael Fischer) Newsgroups: comp.sys.atari.st Subject: Re: Twister, Format+ Message-ID: <8705141445.AA01019@yale-celed.arpa> Date: Thu, 14-May-87 10:45:24 EDT Article-I.D.: yale-cel.8705141445.AA01019 Posted: Thu May 14 10:45:24 1987 Date-Received: Sat, 16-May-87 10:37:09 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 74 Richard Sansom writes in reply to Braner: > >Format+ (the "dead sector" speed-up scheme - I use only 80 tracks, though) > >seems to read a bit faster than Twister. > > Format+ gets its speed from the fact that attempting to read the "bad" > sectors at the end of each track results in an FDC error which returns to > TOS in time to seek to the next track, and continue reading _without having > to wait for sector 1_: > > |BOT|1|2|3|...|9|[10]|bad|(return to TOS) > (seek to next track) > |BOT|1|2|3|... > > Since sector 1 is the next sector to be read, it takes 1 revolution to read > a single track. > > On TOS formatted disks, there is no bad sector area at the end of each > track, so the FDC does not return to TOS in time to seek to the next track > _and_ pick up the first sector without having to do another full revolution > of the disk - i.e., it takes 2 revolutions to read each track. This does not completely explain what I have observed from reading the TOS driver code and from experiments. The driver issues a FDC "seek-with-verify" command before every I/O operation, even if the head is already on the correct track. The FDC steps the head to the desired track, waits for the next sector header to arrive, and then reads the track number written there to check that the head is indeed on the correct track. This would seem to guarantee that at least one valid sector will be missed between reads and would explain the fact that TOS takes two revolutions per track read, even if there were no "bug" in the read-multiple-sectors FDC command. Robert Fischer and I have patched the driver code to bypass the seek when the head is already on the same track. This eliminates the "dead" revolution in the case of a read ending at sector 9 followed by another read beginning at sector 1 of the SAME track. When seeking to another track, 2 sectors are missed due to the seek, but it is possible with that patch to get roughly 80% efficiency with standard format disks by "twisting" the order in which sectors are read, e.g. |1|2|3|...|9| (seek) |2|3|...|9| |1| (seek) |4|5|...|9| |1|2|3| (seek) |6|7|8|9| ... Note that seeking to the same track also occurs when TOS writes with the verify flag on, for it writes the data, seeks to the same track, and then does the verify operation, causing a dead revolution between the write and the verify. What I do not understand is why FORMAT+ works. According to my understanding, the bad sector would terminate the previous read immediately, but the following seek-with-verify would wait for sector 1 of the new track, causing it to be missed by the following read. Is it perhaps the case that the FDC remembers enough of the sector header so that a read immediately following a seek-with-verify can catch the same sector? Or does the read-multiple-sectors command in fact terminate properly, and FORMAT+ works because the bad sector causes the seek-with-verify to terminate early? Or is something else going on? --Mike Fischer Arpanet: fischer@yale.arpa UUCP: ...!imagen!yale!fischer ...!ucbvax!decvax!yale!fischer Bitnet: fischer@yalecs -------