ekrimen@ecst.csuchico.edu (Ed Krimen) (03/07/91)
I came across a utility recently that mentioned in its docs that to
speed up the floppy drives, you can set them to 2ms and no verify.
How reliable is this? Does anyone out there have any experience with
this?
--
Ed Krimen ...............................................
||| Video Production Major, California State University, Chico
||| INTERNET: ekrimen@ecst.csuchico.edu FREENET: al661
/ | \ SysOp, Fuji BBS: 916-894-1261 FIDONET: 1:119/4.0erlingh@sigyn.idt.unit.no (Erling Henanger) (03/09/91)
I tried this for a while. Then I stopped. :^(
I suppose it's very dependent on how good your drive-mech is.
It works, it is _fast_, but it's not safe...
Erling
--
_______ _____ o ____ Erling Henanger
/___ /____/ / / /| / / Norwegian Institute
/ /\ / / / | / | ___ of Technology. (NTH)
------ / \ /____ / / |/ \____| o Atari Lives !cmm1@cunixa.cc.columbia.edu (Christopher M Mauritz) (03/10/91)
In article <1991Mar07.080136.28020@ecst.csuchico.edu> ekrimen@ecst.csuchico.edu (Ed Krimen) writes: >I came across a utility recently that mentioned in its docs that to >speed up the floppy drives, you can set them to 2ms and no verify. >How reliable is this? Does anyone out there have any experience with >this? I used to do this all the time. I think Lars-Erik Osteruud has a nice little autofolder program (when I say little I mean less than 1K!) to do the trick. There are also other programs out there that will work too, but it has been ages since I've used an Atari and I've forgotten. I never had any reliability problems at all and I used to format my disks to 10 sectors/81 tracks as well. The speedup is definitely noticeable. Cheers, Chris ------------------------------+--------------------------- Chris Mauritz |D{r det finns en |l, finns cmm1@cunixa.cc.columbia.edu |det en plan! (c)All rights reserved. | Send flames to /dev/null | ------------------------------+---------------------------
adamd@rhi.hi.is (Adam David) (03/13/91)
In <1991Mar07.080136.28020@ecst.csuchico.edu> ekrimen@ecst.csuchico.edu (Ed Krimen) writes: >I came across a utility recently that mentioned in its docs that to >speed up the floppy drives, you can set them to 2ms and no verify. >How reliable is this? Does anyone out there have any experience with >this? If the drives step reliably at this rate that's fine, any decent modern quality drive should handle this, but there are plenty of rogue drives around. I see no use for switching verify off except for bulk copying to be bulk verified later. If disks become error-free then verifying will no longer be necessary, but that will never happen, will it. You don't save any time if you are busy repairing damaged data by hand. -- Adam David.
hase@netmbx.UUCP (Hartmut Semken) (03/13/91)
adamd@rhi.hi.is (Adam David) writes: >In <1991Mar07.080136.28020@ecst.csuchico.edu> ekrimen@ecst.csuchico.edu (Ed Krimen) writes: >>I came across a utility recently that mentioned in its docs that to >>speed up the floppy drives, you can set them to 2ms and no verify. >>How reliable is this? Does anyone out there have any experience with >>this? The step rate depends only on the stepper motor of the drive. Most 5.25 inch/80 track drives will work fine at 2 ms step rate. most 3.5 inch drives will only work down to 3 ms. There are two kinds of "verify": the step verify and data verify. I suggest, never to switch of the re-read after write (date verify), cause disk drives and media are never perfect. This data verify is something done in software only. The step verify - a controller option: after a step the controller chip reads in the header of the first sector it can find and compares the track number in the sector header with the contents of the track register; if they are equal, the step succeded; if they are different, the controller says "seek error" to the MPU - can be switched off safely. It does not give more reliability if You do not step too fast for the drive mechanic. If You have a slow stepping drive - perhaps rated at 3.5 or 4 ms per step - the step verify will relax the step timing a bit and will therefore help to reduce the "drive X is not responding..." alerts. hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP Hi! (Zaphod Beeblebrox)