braner@batcomputer.UUCP (05/11/87)
[] Format+ (the "dead sector" speed-up scheme - I use only 80 tracks, though) seems to read a bit faster than Twister. It does not speed writing. (Does Twister? Without turning verify off?) My only complaint is that I have no idea how it works... My experience says: use Sony disks only. A local outlet sells "bulk" Sony DSDD 3.5" disks for about $1.45 each (at small quantities - "bulk" means they come without box, polyethylene sleeves or labels, and sometimes they are not marked as "Sony" although the (big) box is). They are either blue or _white_ (I prefer the (matt) white - write on them with pencil!). - Moshe Braner
sansom@trwrb.UUCP (Richard Sansom) (05/13/87)
In article <967@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu.UUCP (braner) writes: >Format+ (the "dead sector" speed-up scheme - I use only 80 tracks, though) >seems to read a bit faster than Twister. This has to do with the way the tracks are laid out. In Format+, all tracks are written with the following format: |BOT|1|2|3|4|5|6|7|8|9|[10]|bad| Where "BOT" is the beginning of track, and "bad" is(are) the bad sector(s). 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. Twister lays out its track with a staggered (twisted) scheme as follows: |BOT|1|2|3|4|5|6|7|8|9|10| |BOT|9|10|1|2|3|4|5|6|7|8| |BOT|7|8|9|10|1|2|3|4|5|6| |BOT|5|6|7|8|9|10|1|2|3|4| |BOT|3|4|5|6|7|8|9|10|1|2| |BOT|1|2|3|... When reading a "twisted" disk, the read sequence looks something like this: |BOT|1|2|3|...|10|(return to TOS) (seek to next track) |BOT|9|10|1|... The FDC has to wait for sector 1 to show up before it can continue reading. Since two sectors must be skipped, it takes roughly 1.2 revolutions of the disk to read each track. Therefore, the (approximate) relative speeds of the formatting schemes for reading a disk are: formatter revs/track efficiency --------- ---------- ---------- Format+ 1.0 100% Twister 1.2 80% TOS 2.0 50% As far as writing speeds are concerned, you must turn off write verification in order to fully take advantage of these fast formats (or even with TOS formatted disks). With write verify OFF, the relative write speeds of the formatting schemes are the same as above. With write verify ON, performance will be degraded by (roughly) a factor of 2. -Rich -- /////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ /// Richard E. Sansom TRW Electronics & Defense Sector \\\ \\\ {decvax,ucbvax,ihnp4}!trwrb!sansom Redondo Beach, CA /// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////
fischer-michael@YALE.ARPA (Michael Fischer) (05/14/87)
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 -------
woodside@ttidca.UUCP (05/14/87)
In article <967@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu.UUCP (braner) writes: >[] > >Format+ (the "dead sector" speed-up scheme - I use only 80 tracks, though) >seems to read a bit faster than Twister. It does not speed writing. (Does >Twister? Without turning verify off?) My only complaint is that I have no >idea how it works... > My understanding is as follows: TOS doesn't know how many sectors are on a track, despite the information being present in the boot sector. It move to the next track when it gets an error looking for a sector. The 1772 searches three revolutions of a disk before deeming a sector "not found" and returning an error. So, when TOS is looking for sector n+1, where there are n sectors per track, it takes three revolutions of the disk to get the error, and move to sector 1 of the next track. Format+ writes a bad sector ID for sector n+1 on each track, so TOS sees the error in one revolution instead of three, resulting in faster I/O. TOS also checks after a step/seek to see if it got to the right track by reading the first address mark it can find. Unfortunately, the combination of step/settle/read-address causes sector one on the destination track to be missed, and another revolution to be wasted. TWISTER compensates for the track step/head settle/position verify time by staggering the sectors on the tracks in relation to the index mark, like this: INDEX---+ Sectors (TRK 00) ! 1 2 3 4 5 6 7 8 9 10 (TRK 01) ! 3 4 5 6 7 8 9 10 1 2 (TRK 02) ! 5 6 7 8 9 10 1 2 3 4 NOTE!!! Twister does put TEN sectors on a track, which is the cause of a lot of the problems copying things to "TWISTED" disks in any manner other than file by file. (Standard TOS disks have nine sectors). In double sided disks, the stagger is applied to each side, as well as each track. So, the best performance is probably a combination of the stagger of "TWISTER" and the bad address mark of "FORMAT+". Also nice would be options for nine or ten sectors per track, 80, 81, or 82 tracks. Since "TWISTER" is copyrighted, everything would have to be re-written from scratch. I'm working on it, and should have it in a couple more weeks (he said hopefully). Yes, I will be posting it when I have it done. GENERIC WARNING - We are dealing with a collection of random data here, and any/all of it could be wrong. This is just the way I have come to understand the different techniques being used. My format program isn't working yet, so I can't test these things enough to see what really does impact the performance.
braner@batcomputer.tn.cornell.edu (braner) (05/18/87)
[]
There is no need to "twist" disks using the "dead sector" format ("format+")
since they already read at the maximum possible speed (one track per
revolution) (i.e. 5 per second) (that's single sided).
From some postings I now gather that it works (or is necessary) due to a bug
in the 1772 chip. Is that right? Is there/will there be a fixed version of
the chip? Why do people design computers with chips with known bugs?
- Moshe Branersansom@trwrb.UUCP (Richard Sansom) (05/18/87)
In article <719@ttidca.TTI.COM> woodside@ttidcb.UUCP (George Woodside) writes: >TWISTER compensates for the track step/head settle/position verify >time by staggering the sectors on the tracks in relation to the index mark, >like this: > > INDEX---+ Sectors >(TRK 00) ! 1 2 3 4 5 6 7 8 9 10 >(TRK 01) ! 3 4 5 6 7 8 9 10 1 2 >(TRK 02) ! 5 6 7 8 9 10 1 2 3 4 I think that twisting is backwards - shouldn't it be: (TRK 00) ! 1 2 3 4 5 6 7 8 9 10 (TRK 01) ! 9 10 1 2 3 4 5 6 7 8 (TRK 02) ! 7 8 9 10 1 2 3 4 5 6 otherwise, you'll have to wait for 7-8 sectors to pass before sector 1 comes around again. Also, if you look at the original code (file mmtwst.c, I think) you'll see that is the way Twister actually does it. I modified Twister to allow user spcification of sectors per track and tracks per side. I was hoping to get Atari's permission to post using the (Atari copyrighted) FDC code which was published with Twister, but, unfortunately, never got a reply (and I'm too lazy to completely rewrite the code). -Rich -- /////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ /// Richard E. Sansom TRW Electronics & Defense Sector \\\ \\\ {decvax,ucbvax,ihnp4}!trwrb!sansom Redondo Beach, CA /// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////