[comp.sys.amiga] Disk Alignment

KENNEDAM%WWPS@dupont.com (Tony Kennedy) (08/11/89)

HI all,
	Is there a drive head alignment program floating about the net? My df0:
is giving me read/write errors on a few disks. Those disks read just fine on my
brand new df1: drive. Could the alignment be the problem or maybe dirty heads?

		Help!
			...Tony

>-----------------------------------------------------////---------------< 
|    Tony Kennedy      | Any resemblance       |     //// AMIGA          | 
|   Project Engineer   | between these and my  |\\\ //// The computer    |  
|    Setpoint Inc      | employers opinions is | \\\/// For the best     | 
|                      | pure coincidence.     |  \\\/ of us.            | 
>------------------------------------------------------------------------<  
| INTERNET : kennedam%wwps%dupont.com@relay.cs.net                       |  
>------------------------------------------------------------------------<  
| "Don't tie your sister up with dental floss." My girlfriend to the     |
|                                            children she's babysitting  |
>------------------------------------------------------------------------<

armhold@topaz.rutgers.edu (George Armhold) (08/19/89)

Hi,
	I'm working in an environment where I'm shuffeling between an
A1000 at home and an A2000 at work.  It seems that one of these
machines (or possibly both) has an alignment problem with one of their
floppy drives.  Sometimes when I try to boot from a Workbench disk the
machine just grinds away at the disk.  It takes about 5 minutes to boot
from a disk that usually boots in 3.  If I try booting a few times the
problem sometimes goes away.  I used to fix this problem in the past
by simply replacing the bad disk, but this is starting to happen on 1
week-old disks now.  Are there any programs in the public domain that 
will test the alignment of a disk drive? 

Thanks,
-George

cmcmanis%pepper@Sun.COM (Chuck McManis) (08/22/89)

(George Armhold) writes:
>          ...   Sometimes when I try to boot from a Workbench disk the
>machine just grinds away at the disk.  It takes about 5 minutes to boot
>from a disk that usually boots in 3.  If I try booting a few times the
>problem sometimes goes away. ...

What your problem is, is called disk validation. When you write to an 
Amiga floppy the "bitmap" which shows which blocks are free on the floppy
gets updated but not initially written. (This is an optimizing solution
to prevent having to write all the time to the disk) Anyway, after a 
your last write to the disk *WAIT 3 SECONDS*, the disk will suddenly
write again! That is the handler flushing the bitmap back to the disk.
If you don't wait and pop out the disk, there won't be anything wrong
with it, rather it will just not be validated. The next time you pop
it into a drive to boot or just read it, the handler will note that it
isn't validated an then proceed to read *EVERY* directory and file header
to make sure the bit map is correct. This can take a noticebly long time
especially if you have lots of files on the disk. Once it's been validated
thought you won't have to validate it again (until it has been written to)
and so reboots from that point on will happen much more quickly.


--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.
"A most excellent barbarian ... Genghis Kahn!"

hull@hao.ucar.edu (Howard Hull) (08/22/89)

In article <122819@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes:
>(George Armhold) writes:
>>          ...   Sometimes when I try to boot from a Workbench disk the
>>machine just grinds away at the disk.  It takes about 5 minutes to boot
>>from a disk that usually boots in 3.  If I try booting a few times the
>>problem sometimes goes away. ...
>
>What your problem is, is called disk validation...
>...
>isn't validated an then proceed to read *EVERY* directory and file header
>to make sure the bit map is correct. This can take a noticebly long time
>especially if you have lots of files on the disk...
>
GAWRSH, Chuck, you usually get _everything_ when you report the cause of a
problem.  It's a surprise to see you screw up like this!  :-) You should've
noted that there's a problem with situations where the Workbench is sooooo
full that there's not even a single block left in which to write the new bitmap
(keeping in mind that AmigaDOS insists on writing the new bitmap before it
"unlinks" the old one).  Under such circumstances, AmigaDOS will not write
the bitmap until it can find a free block - but since the file writes go ok,
it doesn't report any kind of error (that's just as well, since there isn't
any error, just a pending operation it can't finish).  Thus if you remove
your completely full Workbench, it comes out with the bitmap valid flag set
to zero (on a 880K floppy that's Root Block (880) longword 78 in the ever so
famous track 40).  A validated floppy has -1 in this longword.  So if you
filled your Workbench to where the Info command shows 0 blocks remaining,
issue a "DiskChange DF0:" command (assuming DF0's the device where you had
the workbench placed) before you pull out the disk - or pull it out and put
it back again before you try to reboot with it).  DiskChange will cause
AmigaDOS to check the root block in order to identify the disk, and will
result in a call to the l:Disk-Validator handler when the BMFLAG is found
to be cleared.  One other thing...if you ever get a disk that causes a crash
when you try to Read, Copy or Delete a file or directory you can usually
recover (first make a copy of the disk with DiskCopy - but be warned that
the copy will crash in the exact same delightful way...).  Use a disk editor
(i.e., Sectorama, DiskZap, or DiskEd) on the copy to fetch block 880; clear
longword 78, correct the checksum, and write the rootblock back to the copy.
When the editor releases the disk back to AmigaDos, the validator will be
summoned before very much is done with the disk's filesystem, and the problem
causing the crash will likely be cleared up before the file system can get
involved with it.  This procedure will work on disks that are so hosed that
they cause a crash upon insertion - if one merly opens the disk editor on a
formatted blank disk, and then (after the editor has locked the disk away
from AmigaDOS' access) substitute the hosed disk before pulling the root
block into the editor's buffer and clearing the BMVALID flag.  Have fun...
>
>--Chuck McManis
>uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
>These opinions are my own and no one elses, but you knew that didn't you.
>"A most excellent barbarian ... Genghis Kahn!"
						Howard Hull - more barbaric
						than Genghis Kahn, but not
						nearly as excellent...
						hull@hao.ucar.edu

ecarroll@csvax1.cs.tcd.ie (Eddy Carroll) (08/23/89)

(George Armhold) writes:
>           ...   Sometimes when I try to boot from a Workbench disk the
> machine just grinds away at the disk.  It takes about 5 minutes to boot
> from a disk that usually boots in 3.  If I try booting a few times the
> problem sometimes goes away. ...

In article <122819@sun.Eng.Sun.COM>, (Chuck McManis) replies:
> What your problem is, is called disk validation.
       [ Good explanation of disk validation deleted ]
> This can take a noticebly long time especially if you have lots of files
> on the disk. Once it's been validated thought you won't have to validate
> it again (until it has been written to) and so reboots from that point on
> will happen much more quickly.

The disk validator itself isn't too slow; the real problem is that it's
trying to validate the disk at the same time as the startup-sequence is
executing. This results in two seperate processes trying to access the disk
at the same time, and sends AmigaDOS scurrying back and forth over the disk
surface reading blocks alternately for each process. This makes things MUCH
slower than you might otherwise expect, and is accompanied by what sounds
like AmigaDOS trying to eat your disk (it doesn't actually do any damage,
other than adding a little extra wear and tear to the drive mechanism).

When this happens, the best idea is to stop the startup-sequence from
executing, and let the disk validator get on with its work. You can do
this by pressing CTRL-D, and then rebooting after the drive has stopped for
more than 4 seconds or so. An alternative is to just press SPACE, which will
pause the startup-sequence, the next time it tries to output a message. When
all disk activity has stopped, just press BACKSPACE to resume the
startup-sequence.
-- 
Eddy Carroll               ----* Genuine MUD Wizard  | "You haven't lived until
INTER: ecarroll@cs.tcd.ie                            |    you've died in MUD!"
 UUCP: {..uunet}!mcvax!ukc!cs.tcd.ie!csvax1!ecarroll |  -- Richard Bartle

douglee@becker.UUCP (Doug Lee) (08/24/89)

In article <Aug.19.12.26.52.1989.18198@topaz.rutgers.edu> armhold@topaz.rutgers.edu (George Armhold) writes:
>
>Hi,
>	I'm working in an environment where I'm shuffeling between an
>A1000 at home and an A2000 at work.  It seems that one of these
>machines (or possibly both) has an alignment problem with one of their
>floppy drives.
I suggest that you disassemble your drive and give it a thorough cleaning with 
PURE isopropyl alcohol, especially the heads, but be sure and clean out any
hair or fuzz that may be migrating to the head area. Also make sure that nothing
is blocking the optical sensors for track 0, write protect and disk inserted.
Some drives have little mechanical switches for disk inserted and write protect.
Make sure they move freely and aren't bent. If they are bent and binding, bend 
them back VERY carefully.
>Are there any programs in the public domain that 
>will test the alignment of a disk drive? 
To do this, You need and oscilloscope and a special alignment disk made on 
a calibrated drive. You can get these from drive manufacturers and people who
make drive testing equipment. I got mine from a company called Lynx in Markham
Ont Can, who make drive exercisers. It cost $100.00 Can. Once you have one of 
these, you have to move the head to the track indicated on the disk where a
' cat-eye ' pattern is found. What this amounts to is a couple of analog signals
recorded just before and just after the track you're on. Their amplitudes 
change sinusoidally, and are out of phase, so the result is that you see two
humps on the oscilloscope, which should be of equal amplitude. If they are not,
you have to loosen the screws holding the head stepper motor and rotate it. 
This is VERY touchy and you could easily lose the track you're on completely.
If this happens, just step the drive in and out until you find the signal, 
and then you know where you are and which way to adjust. Unless you feel 
comfortable with mechanical stuff requiring extremely delicate tweeking, 
you may not feel like doing this. The other part is adjusting the index pulse
from the drive so it matches areference pulse recorded on the disk. In other
words, you want the index pulse out of the drive to happen at the proper
time relative to the pulse recorded on the disk. I forget if it's at the 
same time or there is an offset, without hauling out a drive manual.
The oscilloscope must be a dual-trace model and is connected to test points
in the drive, with the scope channels added together and inverted with respect 
to each other. The test points are on the front of the NEC drives, beside the
light connector. (The two outside ones). On one variation of Matsushita drive, 
the test points are on the bottom labelled T1 and T2. You will have toi solder
little wires to them to hold the scope probes on. Various models of drive will 
be different.

As far as software, I have just hacked on the example trackdisk device code
in the RKM to make it do what I want, for the occasion at hand. You could have 
a look at this. I have thought of making a program just for stepping drives
for servicing, but never gotten around to it. If there's any interest, I may.

Does anyone on the net reading this know where to get manuals and parts for
all these various floppy drives? If so, mail or a posting would be appreciated.

>
>Thanks,
>-George


-- 
Doug Lee
douglee@becker
416-461-5357

new@udel.EDU (Darren New) (08/25/89)

Another method, if you notice the GRONKs right away, is to reboot.
Before the DOS has openned the window, start typing over and over
(e.g., jkljkljkljkljkljkljkl).  Dow will start the console in the
initial window and then try to put out the copyright, which will
block because of typeahead. Let the disk finish, and the ^X. -- Darren