[comp.sys.cbm] 1581

fred@cbmvax.UUCP (Fred Bowen) (12/12/87)

Well, it's time to clear the air regarding the 1581 problems.  This fairly
long posting will hopefully address the most commonly expressed grievances,
provide an explaination of the situation and describe what to do about it.

The 1581 3.5" disk drive had undergone fairly complete and extensive testing
both in-house and through numerous beta sites.  It is as clean and reliable
a system as one could hope for, and I and satisfied with what we have created.
Unfortunately, a couple of early production-related hardware problems crept
into some of the first systems, affecting 500 to 2000 drives.  These have been
investigated and corrected as quickly as possible, and service centers have
been sent bulletins.  Repairs should be made as warranty repairs for these
particular problems, even if your warranty has expired.

Now, the gory details.  Here are the complaints:

From:      Robert Oyung	laba-1ay@web3a.berkeley.edu
> Looking at the "filecopy" program on the "1581 test/demo" 
> disk included with the new drive, I noticed a bug. There is a line that says:
>
>       60 :if su<4 or su>31 or du<4 or du>31 or su=du then 10
>
>       but line 10 does not exist.  I believe it should read "then 25"
>	which is a jump to a subroutine that restarts the program.

	Correct.  Actually, someone changed my original FILECOPY program
	for the 1581 Test/Demo disk and this was the result.  Newer 1581's
	are shipping with a version 2.0 Test/Demo disk with this and other
	rather minor changes.

> Using the "uni-copy" program to transfer all my old speedscript
>	files onto the 3.5" disk, the program seems to work fine.  But
>	when I list the directory, the middle portion looks like:
>
>	2  "captured"     prg
>	0  "quest"       *prg
>	2  "
>	0
>	0
>	0
>	17732 L
>	1  "report"       prg

From: mjw@aluxp.UUCP (Michael Weber)
> Has anyone noticed any problems with thier 1581 "floppy" disk drive?  I've
> owned mine for about a month and found that it managed to trash a disk
> while I was using it during a heavy download session on Quantum Link.  In
> particular, it looks as though any files written past track 40 were
> completely corrupt!  Further investigation on one of the Q-Link discussion
> areas showed that others have also encountered problems with this drive but
>
> I could find no official or unofficial comments from CBM in reply.
> Also mentioned was that Commodore will issue a bulletin in the (near?)
> future describing the problem and its solution/resolution to all
> authorized service centers.
>
> One message described that the WD1770 drive controller should be replaced
> with a WD1772 controller chip (a real pain, the 1770 is NOT socketed).
> A 47 ohm J1 jumper resistor would also be necessary.  Please note that I
> am only repeating the messages I encountered on Q-Link, they are in no
> way supported or recommended by myself and definitely did not come from CBM!

From: wjt@wp3b01.UUCP (Bill Taggart)
> I had this same problem with my 1581, but it only really
> manifested itself in the CP/M mode.  I could duplicate it in
> the C128 mode by having one of the devices connected to the
> serial port turned off.  Also in the C128 mode I had many
> "DRIVE NOT READY" errors -- including right after successful
> disk accesses.  I emailed my problem directly to Fred Bowen
> at CBM and he was extremely helpful and responsive in narrowing
> in on the cause of the problem.  I don't know if CBM has
> issued an 'official' fix for the problem -- but I fixed it by
> replacing the WD1770 with a WD1772 and adding a 47 ohm
> resistor at J1 as described on QuantumLink.     [...]
> After the 'fix' I have never lost any data and find the drive to be reliable.

From: cbmbob@pnet02.cts.com (Robert Umfer)
> I agree. I now rarely use my 1581, for fear that I will lose more information.
> I bought it to save disk space. Now it seems I'm using more 5.25's than ever
> to backup what I'm saving to the 3.5's. No one on Plink is satisfied with
> his 1581, and CBM doesn't seem to be in any hurry to rectify that.

	Okay.  There are two problems.  The first one was easy:  pin 10 of
	U10 was not properly grounded in some units.  This was caused by some
	unmodified pre-production boards sneaking into a final production
	run.  The number of units affected, I am told, is about 500.  The
	symptions vary from occasional "device not present" errors to data
	not being written or retrieved from disk correctly.  The fix is a
	simple one- ground pin 10.  If you value your warranty, a service
	center will do this for you as a warranty repair.

	The second problem was more difficult to isolate.  Some (not all)
	disk drives with a WD1770 controller chip (U4), occasionally did
	not correctly write data to disk.  The previous example of a
	corrupted directory following a disk copy is typical.  This was caused
	by a particular lot or two of WD1770 controllers.  The number of units
	affected is around 2000 I am told.  The fix is simple but hard to do-
	replace the WD1770-00 controller with a WD1772-00 controller.  The
	1581 was built to use either one and, in fact, the vast majority of
	systems did use WD1772 controllers.  I recommend you see a service
	center to have this repair made.

	Associated with the controller is a jumper, J1, physically located
	adjacent to U4.  The jumper should always be shorted with a 47-ohm
	resistor for a 6ms step rate.

	Following this posting will be a BASIC program which will tell you
	which controller chip your 1581 has, and the status of the J1 jumper.
	You need not crack open your 1581 to determine these things.  It is
	impossible, however, to check for proper U10 grounding with a program.

	While it perhaps seemed like a long time to you, it truly took several
	weeks to properly find, analyze, document, and distribute effective
	corrections for these things.  I've worked with alot of very helpful,
	patient folks to accomplish this, and without their help it would have
	taken much longer to isolate the problems.  Some of these people, in
	an honest attempt to aid others in their position, passed on some
	previously "unofficial" fixes for these problems.  After a necessary
	review and thorough testing, they are now official.  Sorry, but that
	is the way the system works.  Authorized CBM service centers should
	have all the info necessary to help you now.  I apologize for any
	aggravation or inconvenience this caused any of you.

	I occasionally hit a few services such as QuantumLink, People Link,
	and GEnie.  I haven't the time or $$$$$ to peruse all the postings
	and answer many questions, so please pass this info along.

	Now, on to new things...
--
-- 
Fred Bowen			uucp:	{ihnp4|rutgers|caip}!cbmvax!fred
				arpa:	cbmvax!fred@RUTGERS.EDU
				tele:	215 431-9100

Commodore Electronics, Ltd.,  1200 Wilson Drive,  West Chester,  PA,  19380