Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!evax!cs4344af From: cs4344af@evax.arl.utexas.edu (Fuzzy Fox) Newsgroups: comp.sys.cbm Subject: Re: @: (save/replace) bug? Message-ID: <1991Mar20.065653.28557@evax.arl.utexas.edu> Date: 20 Mar 91 06:56:53 GMT References: <1991Mar20.095745.9860@cc.newcastle.edu.au> Organization: Computer Science Engineering Univ. of Texas at Arlington Lines: 50 In article <1991Mar20.095745.9860@cc.newcastle.edu.au> c8923075@cc.newcastle.edu.au (Chris (Polar) Baird) writes: > >Could someone please explain what the 'save/replace' bug was on the > original (grey) 1541? How it happens, why it happens, does it > still exist, or does anybody really know? I believe it was Compute's Gazette, although it could have been RUN, in which a definitive article was printed that finally explained this extraordinarily elusive CBM DOS bug. The bug itself came from the fact that the 1541 DOS was actually ported from the Commodore 4040 device, which had two disk drives, called drive 0 and drive 1. The exact problems I do not remember, but essentially it surfaced when the 1541 became confused and actually thought that it had two drives in it, instead of the one that it actually does. Here's the bug in a nutshell. Whenever the bug surfaced, it caused a problem in disk allocation, or rather, the lack thereof. The bug would cause the disk BAM (block allocation map) to not be written back to the disk, when using @-save. But the file was intact on disk, just not allocated. This means that you can LOAD or VERIFY the file on disk just fine, since it is stored there, but the NEXT time you write to the disk, there is a good probability that the new file would overwrite the old one. THIS is what caused the bug. Due to the nature of the bug, the methods of avoidance were outlined as follows: 1. Don't use @-save. If you are unsure of your DOS, just stay away from it. Scratch, then save. This helps when the disk is full, anyway. The new 1571 ROMs (upgraded!) do not have this bug, and I believe the 1581 does not have it either. It is still best to avoid the use of @-save if possible. 2. Always give an absolute drive reference to drive 0. That means that you should never give the drive the oppurtunity to even think of referencing the invisible "drive 1" that it might think it has. When you open a file, open it as "0:filename". When you initialize the disk, use the command "I0:". Basically, ALWAYS ALWAYS use a drive number on any drive reference, and the bug will not be allowed to surface. 3. Validate the disk after @-save. Since the bug causes the BAM to be updated incorrectly, the Validate command will rebuild the BAM and put everything the way it should be. -- David DeSimone, aka "Fuzzy Fox" on some networks. /!/! INET: an207@cleveland.freenet.edu / .. Q-Link: Fuzzy Fox / --* Quote: "Foxes are people too! And vice versa." / ---