Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!ucbcad!ucbvax!COGSCI.BERKELEY.EDU!bryce
From: bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt)
Newsgroups: comp.sys.cbm
Subject: Re: C64 Manual****Saving Files
Message-ID: <8708150243.AA10235@cogsci.berkeley.edu>
Date: Fri, 14-Aug-87 22:43:05 EDT
Article-I.D.: cogsci.8708150243.AA10235
Posted: Fri Aug 14 22:43:05 1987
Date-Received: Sun, 16-Aug-87 06:46:28 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: You want it?  We got it, Inc.
Lines: 59


In article <252@uwslh.UUCP> lishka@uwslh.UUCP (Christopher Lishka) writes:
>In article <2214@cbmvax.UUCP> eric@cbmvax.UUCP (Eric Cotton) writes:
>>In article <295@dsacg3.UUCP> nfs1677@dsacg3.UUCP (Harold Chodnoff) writes:
>>>2. Is it normal to save a file on disk, after modifications...???
>>
>>The syntax for save-with-replace is:
>>	save "@0:filename",8
>>
>>A word of caution here: It is not advisable to use save-with-replace on
>>the old 1541 disk drives.  Delete the file first and then save the new
>>version.
>>	Eric Cotton Commodore-Amiga
>
>Hmmmm... I *have* been using the @0: command on my old 1541 drive
>since I have had it (four or five years now), and have NEVER had any
>problems.  I also thought that a Commodore Representative posted a
>message saying that as long as one specified the drive number (i.e.
>the 0 in @0:) that the porblem would NOT occur;

Wrong, wrong!  There is a definite bug in the 1541 (and family) ROMs
that is the cause of this bug.  Certain combinations of BAM (Block
Availability Map) setup will bring it out.  Essentially, blocks
that have actually been allocated are left marked as free on the disk
surface.  Another file saves over that and "boom".  You may not get bit
for a *long* time, but save to a well used disk enough times and it
*will* bite!

The bug can be patched to "dissappear" from the lower half of the ROM
($C000-$DFFF) or *fixed* in the other half ($E000-$FFFF).  You can
also prevent the conditions by the use of the the "0" drive specifier:

>> You will not see the save @ bug *if*, after a drive reset, you and
*all* the programs you use *specify* drive 0 *every* time there is a
disk access. <<

If drive "1" is *ever* specified the 1541 will be poisoned.
If *no* drive is specified in a command the 1541 will say. "Hey, drive
"1" has not been initialized... I'd better do that!".  Drive "1" does
not exist, an error is created for that drive and the system is poisoned.

The actual patch to fix the problem is only about 16 bytes long.  It is not
the same as Slaymaker (sp?) et all have been providing.
As far as I know, Commodore has not yet fixed this on the newer drives.  The
one "fix" I saw for the 1571 just shifted the conditions of the bug, and did
not address the real, deep seated bug.
I have not explored this much since digging and digging under layers of bugs
to find the *real* cause of save @ problems, many moons ago.  Maybe I should
tell CBM about that one... and that other bug... and how about...

The save @ is a rare bug in that I know of no programs that depend on
it in order to run without trouble.


|\ /|  . Ack! (NAK, EOT, SOH)
{o O} . 
( " )	bryce@cogsci.berkeley.EDU -or- ucbvax!cogsci!bryce
  U	Poet:   "To be or not to be?"
	Hacker: "$ff"