miller@uiucdcs.UUCP (07/16/84)
#R:iddic:-175000:uiucdcs:36100087:000:2165 uiucdcs!miller Jul 16 15:07:00 1984 >One other thing from Midnite GAZETTE: the service man that mentioned squeak >problems also said that in his experience, 100% of SAVE "@:" problems were due >to drive misalignment. I'm not so sure about this; I had it trash some of my >files, and will not try it again. > Gary Hanson Tektronix IDG Gary is right, the service man is wrong. The save and replace bug always reacts the same way, something you would not expect from a variable misalign- ment. Furthermore, the problem does not arise in the file you are writing; it kills an innocent file either before or immediately following it in the direc- tory. What happens is that it resets the track/sector bytes in an adjacent file directory entry, so that the innocent file is lost and points to the start of the save/replace file. The save/replace operation requires a temporary spot to hold the current file start location while it reclaims the old sectors for the BAM. When certain (unfortunately unknown) conditions arise, it uses another file's pointer area to save these 2 bytes. Boom, you're dead. I have heard rumors that the bug dates all the way back to the 4040 days, although I can't confirm this. I wish I knew the conditions under which it occurs so that I could use it in other instances. But it has killed files on me on disks of >1 PRG, 100% Basic programs, on an aligned 1541. So who knows? Use it only if you don't care about saving your files... Here's another 1541 bug for you to chew on: when using the scratch command, sometimes all of the sectors are not released to the BAM. It deletes the file properly, it just doesn't update the BAM correctly. This causes no great problems really, unless this happens a lot or your disk is almost full. Then, you may find that you have no more room on disk when you really should in reality. To check for this, add up the file sizes and the unused sector size. If it doesn't add up to 664, then this has probably occured. Fortunately, the cure is quite simple: use the validate command and all should be set correctly again. (Warning: this does not apply if you have random files on the disk.) A. Ray Miller Univ Illinois
garyh@iddic.UUCP (07/17/84)
>>><<<
Before we hear a chorus of "I knew that the 1541 was a piece of junk", and
"I'm afraid to buy a 1541 'cuz I've heard that it's a piece of junk" replies,
I would like to say that my 1541 knocked itself out of alignment about seven
months ago. I fixed it myself using a combination of information, mis-
information, guesswork, and trial-and-error, and it's been fine since then.
I keep it cool, and don't do SAVE "@:".
Hints to keep the drive cool:
1) Elevate the drive about an inch on small wood blocks or whatever to allow
air circulation under the drive.
2) Run it without the plastic top cover on (probably not necessary, but I never
put it back on (except for when not in use) after it broke).
3) Use a small muffin fan to blow air across the back of the case (I don't do
this)
4. Tilt the two bridge rectifiers in the back towards the back of the unit, and
the small electrolytics away from heat sources (the rectifiers and regulator
heat sinks) to promote long-term reliability. The rectifiers get quite warm,
and I will someday make some sort of clip-on heat sinks for them.
For anybody interested, my drive is a V3 rom short-board model in a white case
(ie. before they made the anti-misalignment mods).
Now, the new stuff:
(credit where due: much of this information came from Midnite GAZETTE # 19).
Does your drive occasionally make squeaking-type noises while a disk is turning?
This is caused by a spring in the top disk-clamping assembly wearing into softer
metal washers. This is not a good thing. A permanent fix involves getting
different parts at the critical points. (The writer in MG mentioned that he was
trying to put together a parts kit for that). As an interim measure, remove,
clean, lubricate, and reinstall the top disk-clamp assembly. Here's some brief
instructions for doing that: remove the drive from the rest of the unit (if
you can get that far, you will have no problems; it's really very easy).
Remove the top clamping assembly by taking out the two large screws at the back.
Remove the clip washer at the top that holds the clamping hub on. Carefully
remove the clamp hub assembly (the spring will want to shoot the washers
off, and it's helpful to know which ones go where for re-assembly. The offending
washers are the shiny ones on either side of the spring with the noticeable
bevel worn in them. Clean the metal dust and whatever else off them, lubricate
(I used a tiny quantity of light high-quality grease; probably not the best
choice actually), and re-assemble. No more squeaks. (I lied above about no more
problems- I had (and fixed) the squeak.
But the drive hasn't knocked itself out of alignment again, and aside from a
few (seemingly) random "DRIVE NOT READY" errors, it's been fine, really).
One other thing from Midnite GAZETTE: the service man that mentioned squeak
problems also said that in his experience, 100% of SAVE "@:" problems were due
to drive misalignment. I'm not so sure about this; I had it trash some of my
files, and will not try it again.
Gary Hanson Tektronix IDGrwh@aesat.UUCP (Russell Herman) (07/18/84)
I always thought that scratching a file isn't SUPPOSED to update the BAM.
If it did, the trick of un-scratching accidently scratched files by setting
2**7 of byte zero of the directory entry wouldn't work after any further
file allocation, because some of those blocks might have been reused.
For those of you that don't realize what "validate" does, it searches
through all unscratched files on the disk, rebuilding the BAM from the
file chains. That's why you can't validate a disk with type relative
files on it: the side-sectors will be treated as unused.
--
______ Russ Herman
/ \ {allegra,ihnp4,linus,decvax}!utzoo!aesat!rwh
@( ? ? )@
( || ) The opinions above are strictly personal, and
( \__/ ) do not reflect those of my employer (or even
\____/ possibly myself an hour from now.)anthro@ut-ngp.UUCP (Michael Fischer) (07/19/84)
<> The @SAVE bug dates back to the 2040 disk drive in 1978. It is true that all the circumstances related to it are a mystery within and out of Commodore. There is a related bug in the 2040/4040 that involves the same problem after a DISK FULL error. Files merge. This is an almost certain way to cause the merge problem. I have not used the @ mode since those early days, since I respect my files, and am careful about filling disks for the same reason. Has anyone observed this problem with DISK FULL on the 1541? By the way, the problem seems not to occur with the 8050. A note of interest...Commodore has committed to a large number of 3.5'' disk drives. By Christmas we may see a 500k single disk drive for the 64/TED/C16/Vic.
paul@ism780b.UUCP (07/27/84)
> I always thought that scratching a file isn't SUPPOSED to update the BAM. > If it did, the trick of un-scratching accidently scratched files by setting > 2**7 of byte zero of the directory entry wouldn't work after any further > file allocation, because some of those blocks might have been reused. The trick may well NOT work if any file allocation has been done since the file was scratched, because the BAM IS (usually) updated. For the same reason, you'd better run the "validate" command after unscratching a file, or DOS will think the blocks in it are still available. > For those of you that don't realize what "validate" does, it searches > through all unscratched files on the disk, rebuilding the BAM from the > file chains. That's why you can't validate a disk with type relative > files on it: the side-sectors will be treated as unused. Basically right, but I think you are confusing "relative" and "random" files. I have "validated" disks with relative files, and it sure SEEMED to work. According to the wretched 1541 manual, only "random" files are incompatible with the validate command. This makes sense, because "random" files are not really files at all, just a way to access the drive as an array of blocks; relative files are real files in that they have a name, sector links, etc. Paul Perkins -- INTERACTIVE Systems USENET: ...{uscvax|ucla-vax|vortex}!ism780!paul ...decvax!cca!ima!ism780!paul MILNET(?): decvax!cca!ima!ism780!paul@ucb-vax Signoff: "A tangled net catches no fish." Disclaimer: This message is provided AS IS. The reader assumes all risk as to the accuracy of the content and its usefulness for any particular purpose.
miller@uiucdcs.UUCP (08/02/84)
#R:iddic:-175000:uiucdcs:36100089:000:221 uiucdcs!miller Jul 26 23:12:00 1984 Gary, I tried twice to reply personally to your mail concerning this topic, but our routing tables must be wrong for iddic. Please mail to me again so I can get a correct route for my reply. A. Ray Miller Univ Illinois