Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!orsvax1!pyrnj!caip!daemon
From: prindle@nadc
Newsgroups: net.micro.cbm
Subject: 1571 anomalys
Message-ID: <2143@caip.RUTGERS.EDU>
Date: Fri, 2-May-86 11:51:36 EDT
Article-I.D.: caip.2143
Posted: Fri May  2 11:51:36 1986
Date-Received: Sun, 4-May-86 04:46:07 EDT
Sender: daemon@caip.RUTGERS.EDU
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 44

From: prindle@NADC

I've already documented a reproducable problem with the 1571 drive - that of
specific situations in which a file open for writing and residing on the second
side of the diskette is written extremely slowly.  However, I've also from
time to time been the victim of another strange behavior.  Specifically, if a
program has several files open (e.g. one read and one write), and the file
being written fills up the first side and proceeds to the second side, it
sometimes happens that the "next-track/sector" chain through the file gets
broken prematurely and/or the directory entry does not point to the correct
first track/sector of the file.  The net result is that the written file,
once closed, is recorded in the directory as having a certain length, but is
much shorter than that when read, and contains incorrect or out of sequence
information.  The total block count for the diskette becomes wrong, and scratch-
ing the file does not recover all the blocks; it is necessary to do a validate
to get the block count correct again.  (Note that none of this applies when
the 1571 is being accessed by CP/M, since in this case the drive is only
being utilized to do random block reads/writes with all directory and allocation
information maintained by CP/M itself.)

Now this is about as reproducible as the infamous "@(replace)" bug, and of
course always happens when I'm busy trying to do something else and don't have
time to track down the problem or record the exact circumstances of the
failure.  However, it has happened enough times (3 or 4) with similar results,
that I am fairly convinced that it is not a result of human or random
electronic error.

I would appreciate hearing from readers of this list about their experiences
which would tend to either confirm or deny the existence of such a problem.  If
there is a problem, a simple program which will consistently demonstrate the
failure would go a long way in convincing Commodore to search for a bug and
manufacture updated roms with the fix.  I stress *simple*, because all of the
test cases which supposedly "prove" the "@(replace)" bug are so outlandishly
complicated that they won't be taken seriously by Commodore.

The 1571 is a wonderful drive in many ways, and it would be a shame for it's
reputation to suffer from readily correctable firmware bugs.  I, for one,
would be more than willing to shell out 10 or 15 bucks to get updated roms from
Commodore, provided they would break down and admit whatever problems these
were supposed to fix.

Cheers,
Frank Prindle
Prindle@NADC.arpa