Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!chinet!dag
From: dag@chinet.UUCP (Daniel A. Glasser)
Newsgroups: comp.sys.atari.st
Subject: Re: SH204 hard disk
Message-ID: <2134@chinet.UUCP>
Date: 25 Jan 88 13:10:37 GMT
References: <2697@dadla.TEK.COM>
Reply-To: dag@chinet.UUCP (Daniel A. Glasser)
Organization: Chinet - Public Access Unix
Lines: 53

In article <2697@dadla.TEK.COM> jrb@dadla.TEK.COM (Jim Binkley) writes:
[query about SUPEDIT removed]
>In reference to Atari hard disks in general, is there an equivalent of
>"chkdsk"; i.e. a file system consistency checker, fixer-upper anywhere,
>available for the average atari owner for rent or purchase?  Mr.
>Harris, not having such a utility provided with your system is
>unfathomable.
MichTron sells a program called "TuneUp!", which I have purchased, which
allows reordering and consistancy checking of hard-disk structures.  It is
not perfect -- It is not robust when the hard drive is almost full and you
have large files, so back up your files before doing a reorder on a nearly
full drive and it does not supply a method for fixing problems that the
checkdisk feature reports -- but it is the first program I've come across
that offers these features.  It costs < $50.
>
>Also... I have an atari SH20? hard disk and am using the driver
>supplied. Unfortunately for the sake of atari it sits next to a zenith
>150-pc clone running good old msdos 2.2. Said ibm machine has a NEC
>20meg drive and a 1010 winchester controller using the driver buried
>away in the bios or somewhere. "To make a long story short, too late,
>said the man in the audience...", My klunky old pc beats the atari's
>performance on disk writes to pieces. This is curious.  The pc disk is
>currently fragmented beyond belief with about %90 full; i.e., I won't
>buy any reformat and try again explanations. Reading seems to be
>comparable. I recently put together a little piece of code that was the
>equivalent of the unix find utility and read all the directories on my
>15 meg C: partition. That was fairly speedy. Writing is another matter.
>Why?  Flicking the bit that turns off write-verify for "floppies"
>doesn't seem to do any good on the hard disk. Did the supra driver that
>Moshe used do any good on the atari disk?
>
From conversations I've had with people "in the know" at Atari, the problem
here is with the TOS code for handling directory and FAT caching and lookups.
Though a rewrite has been underway in-house, the ROMs for the Blitter (the
ones in the current Megas) do not contain any of the re-written code because
it had not been tested in the timeframe required.  Look to Atari to eventually
release a version of TOS that will outperform the old versions by quite a bit.
The most expensive (time-wise) operation on the ST is opening a new file.  On
a hard disk with a lot of activity but over 50% free has sometimes taken over
six seconds.  This is the reason that Mark Williams recommends using a RAMdisk
for the temporary files (TMPDIR) and supplies a RAMdisk with their package.

>One other observation:
[Observation about relative speeds of the PC using RAMdisk vs. Atari using
RAMdisk vs. Atari using RAMdisk deleted.]

						Daniel A. Glasser
-- 
					Daniel A. Glasser
					...!ihnp4!chinet!dag
					...!ihnp4!mwc!dag
					...!ihnp4!mwc!gorgon!dag
	One of those things that goes "BUMP!!! (ouch!)" in the night.