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