Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site druxp.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!drutx!druxp!mab
From: mab@druxp.UUCP (BlandMA)
Newsgroups: net.micro.cbm
Subject: Re: save-replace bug on 1541
Message-ID: <669@druxp.UUCP>
Date: Thu, 10-Jan-85 10:55:27 EST
Article-I.D.: druxp.669
Posted: Thu Jan 10 10:55:27 1985
Date-Received: Sat, 12-Jan-85 00:48:59 EST
References: <310@snow.UUCP>
Organization: AT&T Information Systems Laboratories, Denver
Lines: 58

There's a book out by Datamost, I think it's called "Inside Commodore DOS"
that does a very good job of describing how the 1541 ROM works and how
to play tricks with it.  It also includes a well-annotated memory map of
the ROM.  Highly recommended for anyone who wants to hack at the 1541, or
who just wants to know how it works.

Anyway, they claim that there is really no bug in the save-replace command,
but the symptoms that everybody reports can be caused in the following
two situations:

	1) If you scratch an unclosed file, you have just poisoned the BAM.
	   An unclosed file shows up in a directory list with a * next to the
	   file type.  An unclosed file does not have the last block written
	   to disk.  When a file is scratched, the DOS follows the chain of
	   block pointers, deallocating as it goes.  The last block of an
	   unclose file contains garbage, so it's possible that the block pointer
	   points at some other block on the disk.  If that block happens to be
	   in a good file, the blocks in the rest of that file get deallocated!
	   The correct way to get rid of unclosed files is to do a validate on
	   the disk.  The validate command clears the BAM, then goes through
	   all files on the disk, following the pointers and allocating all
	   blocks it finds.

	2) If the disk fills up while you're writing a file, the BAM also
	   gets wasted.  I don't recall the details, but they basically said
	   that you had better make sure there's enough space on the disk
	   before you write.  They included a sample program that showed how
	   to check the free space before each write.  Pretty messy.

>	I think the problem with save-replace on the 1541 is only
>	caused when a disk is changed i.e. when you are transfering
>	a program from one disk to another.
>	The DOS in the 1541 fails to get the new BAM for the second disk
>	even if its ID is different!!!
>	Therefore when an attempt is made the DOS uses what was spare space
>	on the first disk for the program, thus overwriting if those spare
>	blocks were not so spare on the second disk.

This also sounds plausible to me.  The Datamost book mentioned that
there were times when the DOS failed to read the BAM for the new disk,
although I can't recall if they mentioned any specific circumstances
when this happened.  For this reason, every sample program in the book 
begins with an Intialize command just in case.  They say it's a good
habit to get into if you like to hold onto your data.

Based on the discussions in this book, I have decided that save-replace
is safe to use as long as you're careful.  The times I have lost data
because of the save-replace "bug" was after I had scratched an unclosed
file (I didn't know what that asterisk was, but a scratch seemed to
get rid of it ok!!).  After a year of abstention, I've began using
save-replace again several weeks ago with no ill effects so far.

Anyone who finds out other situations where you can corrupt a disk,
please post them.
-- 
Alan Bland
{ihnp4, allegra}!druxp!mab
AT&T Information Systems Labs, Denver