RUBIN@graf.poly.EDU (David Rubin) (11/11/88)
I have just purchased a hard drive for my ST and unfortunately have not been paying much attention to the hard drive discussions going on here. What I basically want to know is: 1. What is the best way to fix the 40-folder bug? I have seen several programs: FOLDRXXX, GEMBOOT, and another. What are the differences and which one is best? 2. Does the 40-folder limit apply only to NEW folders accessed, or also to repeated accesses of the same folder? In other words, will the system crash after re-accessing the same folder 40 times? 3. Is it safe to use TURBODOS to speed up my drive, or are there possible side effects/dangers in using it? I would appreciate any responses via E-Mail. Please do not send replies to the discussion. Thank you. David Rubin | INTERNET: RUBIN@graf.poly.edu Polytechnic University | BITNET: RUBIN@POLYGRAF Brooklyn, NY |
#FJMORA@WMMVS.BITNET (11/14/88)
In a previous digest, David Rubin writes: > What is the best way to fix the 40 folder bug? I think that FOLDERxxx (where xxx is the number of active folder you want to add) is the standard fix around. It has been around since enough time to be considered as safe. I use FOLDR100.PRG and it eats 13K. >Is it safe to use TURBODOS to speed up my drive? I use TURBODOS since more than 1 year now to speed up my SH205, and I did not have any problem (nevertheless, I backup my disk regularly. Do the same thing, I found that Michtron BackUp! is okay. I know that some PD backup are better). If anybody is aware of a danger resulting of the use of TURBODOS, please let us know. TURBODOS is basically a cache (and a RAM hog, BTW). However, I wrote a letter to Atari-France to get a technical explanation about what the hell really does this utility, and they never wrote back, although they own the product. Typical Atari user-support, I'm affraid. Regards, Frederic Mora BITNET: The College of William and Mary #fjmora%wmmvs.bitnet Dept. of Computer Science INTERNET: Williamsburg, VA. 23185 fjmora@cs.wm.edu USA GEnie: F.MORA ************************************************************************** * * * "Was uns nicht toetet, macht uns staerker." * * Friedrich Nietzsche * * What does not kill us makes us stronger * * * ************************************************************************** - Come, come, little line eater, I won't harm you (evil grin)... - Come, come, little line eater, I won't harm you (evil grin)... - Come, come, little line eater, I won't harm you (evil grin)...
to_stdnet@stag.UUCP (04/12/89)
From: stag!thelake!steve@bungia.mn.org (Steve Yelvington) Xorg@cup.portal.com (Peter Ted Szymonik) writes... > How fast are the trasnfer rates, again, this depends entirely on > the drive mech and which host adaptor you use. As a benchmark, my > Supra 30meg drive transfered 350Kps at 60-65ms, the 100meg ICD drive I > just put together flies at 550Kps and 35-40ms, it all depends on the > drive mech supplied with your drive (or the one you buy.) > I hacked together a Wren I (nominally 36 megabytes), one of the bargain Adaptec boards from Timeline and a Supra host adaptor. The ICD RATEHD program says I'm running a respectable 377kb/sec data transfer rate, but a shameful 527ms average seek rate. This is an old drive, but that seems more than a bit much. I have the drive mounted vertically -- is there a possibility that could affect the stepper's positioning of the heads? I'm running a 1:1 interleave -- could that be involved? > Is there caching? Yes, there are lots of PD and commercial > cacheing programs, but I haven't found them to be at all necessary > given the ST's blazing HD data transfer rates. Probably the only > thing left to speed drive access with be the new TOS 1.4 which will > improve FAT handling. > Because of the horribly slow seeks I'm getting, PATH searches can be painful. For that reason, I've installed Atze Dijkstra's DCACHE program with the argument cde=c18, creating a common cache for drives C, D and E of 18K. That's enough to keep all the directories in RAM as well as some smaller utilities, such as the file pager I use for UUCP stuff. It helps a lot and it's worth the RAM even on my small system (512K). DCACHE was published in this newsgroup about nine months ago. /* * UUCP: {uunet!rosevax,amdahl!bungia,chinet,killer}!orbit!thelake!steve * ARPA: crash!orbit!thelake!steve@nosc.mil * #member <STdNET> The ST Developers Network */
SQ79@liverpool.ac.UK (Mark Powell) (08/18/89)
I'm new to the hard disk game. I should be getting my first ever, in about
a week for my ST (primarily for Minix use.) It'll be a TCT 65Mb. However,
I'd like a few questions about hard drives answered, if possible...
1. What controls the data transfer rate for a drive?
I am led to believe that this is in the hands of the controller. After
reading the documentation that comes along with the ICD utilities I was
susrprised to learn about data transfer rates ranging from 300Ks to 1010Ks.
What's the big difference with these controllers. Does the 1010Ks one cost
the price of a small island in the Pacific?
2. I've heard that hard drives spin at about 3600 rpm. Therefore if your
recommended interleave factor is one, will the controller read the track
in a single revolution? If so doesn't that mean it is reading the track
in 1/3600th of a second? (This can't be right!) I know the seek and
latency times come into this, but if we just talk about the transfer rate
i.e. the head sits over one track and just keeps continualy reading it, then
why then can't it read the track 3600 times a second? I'm pretty sure this
isn't what happens, but could someone explain why?
3. Also, when given a list of bad sectors, what does the controller do with
it? Does store this info. somewhere on the disk so that in the future, it
appears to all software that the disk has no bad sectors? Reference this
to the Adaptec RLL controller if possible, as that's the one that comes
in the TCT drives.
I'd appreciate any info. on hard disks that anyone can supply. Thanks.
Reply to the net as I think other people may find the info. of some use.
(also a CC: by e-mail if possible as news quite likes to go down, here.)
Mark Powell
ARPAnet : sq79%liv.ac.uk@{ucl-cs.arpa,cs.ucl.ac.uk}
USENET : ...!mcvax!ukc!liv.ac.uk!sq79verwer@ruuinf.cs.ruu.nl (Nico Verwer) (08/21/89)
In article <8908181535.AA13948@ucbvax.Berkeley.EDU>, SQ79@liverpool.ac.UK (Mark Powell) writes: > > 2. I've heard that hard drives spin at about 3600 rpm. Therefore if your > recommended interleave factor is one, will the controller read the track > in a single revolution? If so doesn't that mean it is reading the track > in 1/3600th of a second? (This can't be right!) I know the seek and Rpm means `revolutions per _minute_', and since there are 60 seconds to one minute, and the controller reads the track in a single revolution, it reads the track in 1/60th of a second. That is 16.6ms, not 0.3ms. -- Nico Verwer @ Dept. of Computer Science, University of Utrecht, The Netherlands (verwer@cs.ruu.nl)