1541 diskdrive questions
Luc Van Braekel
"Commodore Dossier":
> Remember that even renowned programs like Vizawrite use the disk-
> corrupting 'SAVE "@0:...."'-command. Using a new name and
> scratching is safer.
Why is that command disk-corrupting ? Is it unsafe just because if
something goes wrong during saving, your file is corrupted, or is
there more to it (like a bug in the drive o.s.) ?
2) I frequently have read-errors when trying to save files when my
diskdrive has been on for, say, more than 2 hours. After switching
it off and letting it cool for a few minutes, everything is OK
again. Any solutions ?
3) I heard that the annoying clicking sound of the 1541 drive has
something to do with the head positioning on track 1. Does this
mean that if you don't use track 1, the drive won't click ?
I noticed that there's a lot of clicking before bad reads.
Luc Van Braekel, Department of Computer Science, Katholieke
Universiteit, Leuven, Belgium (...seismo!prlb2!kulcs!luc)
rra...@uiucuxa.cso.uiuc.edu
The problem with the SAVE"@0:filename" command on a 1541 (and I think EARLY 1571) is that it scratchs the file FIRST and then writes the new one. If the new one has grown so large it overflows the disk, or if some other problem occures after the scratch but before the file is written completely, you lose.
Later 1571's write the new file first, scrtch the old one , and then rename the new one to the old ones name. It means you need lots of empty space on the disk , but this problem doesn't occure
The rattling comes from the read arm hitting it's stop. Many programs send the
arm out as far as it will go, as a means of getting to a known possision
Try formatting a blank disk, and the rattle you hear at the begining is this.
Gavin Bell
1) Is there a bug in the drive OS [regarding SAVE@]...
Yep, there sure is a bug, and it apparently shows up in almost every drive
Commodore has ever made. It is pretty obscure, but nasty-- it can even
hit you if you scratch the file and then immediataly resave (it has
happened to me). What happens is you get a weird file in the directory,
consisting of bits of other files (I think...) which is impossible to
get rid of without a lot of knowledge about DOS and a disk doctor program.
I hear you can avoid the problem by ALWAYS specifying the drive number
in your commands (i.e. "s0:file" save "0:file"), but I make it a practice
to re-initialize the drive after scratching any file ( "s0:file" ...
"i0" ... save "0:file").
>2) I frequently have read-errors when trying to save files when my
> diskdrive has been on for, say, more than 2 hours. After switching
> it off and letting it cool for a few minutes, everything is OK
> again. Any solutions ?
taking off the top cover and metal shielding of the drive (keeps
mine nicely cool even during hot California summers) or buying
an inexpensive muffin-fan and sitting it on top of the drive (they
can be bought for < $15 at some electronics dealers).
>3) I heard that the annoying clicking sound of the 1541 drive has
> something to do with the head positioning on track 1. Does this
> mean that if you don't use track 1, the drive won't click ?
> I noticed that there's a lot of clicking before bad reads.
stop-- the clicking before a bad read is the drive head moving around
trying to find the right track. A good "disk doctor" program will let
you adjust the end-stop to stop any clicking, and will also let you
re-align the head so your read errors should go away (all this with
just a phillips screwdriver, too.)
Frederick J. Bear (I have too much hair-- SCARE Fred Bear!)
UUCP: ...allegra!psuvax1!pucc.bitnet!6080733
BITNET: 6080733@PUCC
Don Gentner
> something goes wrong during saving, your file is corrupted, or is
> there more to it (like a bug in the drive o.s.) ?
There is a more serious problem then just trying to do a save with
replace when your disk is full. There is a real bug in the DOS that
corrupts the disk on occasional save with replace commands. I've been
bitten three times (I'm a slow learner) and have finally completely
forsaken the command. In my experience, the problem occurs when you
are using SAVE@ with two files. Under some circumstances, when you do
a SAVE@ of file A, the directory entry is updated properly, but the BAM
is not updated. You are now in trouble, but it is not obvious because
file A will load and list properly. Presumably validating the disk at
this point would cure the problem. If instead you load file B, edit
it, and then do a SAVE@ of file B, it will overwrite file A because the
space for A was not allocated in the BAM. The end result is that the
directory entries for both A and B point to file B, and file A is
lost.
For more details and a demonstration of the bug see "SAVE with Replace
Exposed!!" in the July 1985 issue of The Transactor, and "Save with
Replace: Debugged at Last" in the October 1985 issue of Compute!.
The basic advice in Compute! is, "Therefore, the key to avoiding the
SAVE@ bug is to always specify drive 0 when performing any disk drive
function, or to always reset the drive before any SAVE@ operation."
Because I've forsworn this evil command, I can't verify that this
advice works.
Don Gentner
philabs!gen...@seismo.arpa