Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Archive » net.micro.cbm » 1541 reliability update
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
1541 reliability update [message #69069] Wed, 22 May 2013 23:54 Go to next message
Anonymous
Karma:
Originally posted by: garyh@iddic.UUCP
Message-ID: <1750@iddic.UUCP>
Date: Tue, 17-Jul-84 00:57:48 EDT
Article-I.D.: iddic.1750
Posted: Tue Jul 17 00:57:48 1984
Date-Received: Thu, 12-Jul-84 05:18:36 EDT
Organization: Tektronix, Beaverton OR
Lines: 56

>>><<<
 
  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 IDG
Re: 1541 reliability update [message #69086 is a reply to message #69069] Wed, 22 May 2013 23:54 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: anthro@ut-ngp.UUCP (Michael Fischer)
Message-ID: <758@ut-ngp.UUCP>
Date: Thu, 19-Jul-84 04:55:51 EDT
Article-I.D.: ut-ngp.758
Posted: Thu Jul 19 04:55:51 1984
Date-Received: Sat, 21-Jul-84 03:08:06 EDT
References: <1750@iddic.UUCP>, <36100087@uiucdcs.UUCP>
Organization: Comp. Center, Univ. of Texas at Austin
Lines: 13

<>
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.
Re: 1541 reliability update [message #69090 is a reply to message #69069] Wed, 22 May 2013 23:54 Go to previous message
Anonymous
Karma:
Originally posted by: paul@ism780b.UUCP
Message-ID: <29@ism780b.UUCP>
Date: Fri, 27-Jul-84 00:21:22 EDT
Article-I.D.: ism780b.29
Posted: Fri Jul 27 00:21:22 1984
Date-Received: Tue, 24-Jul-84 03:33:38 EDT
Lines: 32
Nf-ID: #R:iddic:-175000:ism780b:26500002:000:1702
Nf-From: ism780b!paul    Jul 20 11:26:00 1984

> 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.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: C64 CP/M questions
Next Topic: Re: VIC20 assembly lang. - (nf)
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Tue Apr 23 10:28:29 EDT 2024

Total time taken to generate the page: 0.05503 seconds