c8923075@cc.newcastle.edu.au (Chris (Polar) Baird) (03/20/91)
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?
--
}`oo'{
`' Chris "Polar" Baird
Impoverished BSc Undergrad @ Newcastle Uni (OZ!)
C8923075@cc.newcastle.edu.aujbell@gara.une.oz.au (Justin Bell) (03/20/91)
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? > -- > }`oo'{ > `' Chris "Polar" Baird > Impoverished BSc Undergrad @ Newcastle Uni (OZ!) > C8923075@cc.newcastle.edu.au There is a way round this by including at the end of a basic program a subroutine that erases the original program and writes the new one. I have not got the details now but e-mail me if you would like an in-depth explanation, or have a look at the 1990 Australian Commodore & Amiga review Commodore ANNUAL. :) jbell@gara.une.oz.au
c9037544@cc.newcastle.edu.au (David Williams) (03/20/91)
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? Commodore's DOS allows a filename to take the form : "@[device]:filename" (eg: save "@0:fred",8) The device bit is purely optional and is only there as early drives contained two units, specified as devices 0 and 1. The @ however, meant for the DOS to erase any previous file on the disk of this name. The way it worked was for the new file to be saved, and then the old one erased. This meant that it would fail if you did not have enough space on your disk for the new version. The famous 'bug' however, is that often is just did not work. I cannot remember the details, but I do remember that it could corrupt your disk directory. This was only with the very old 1541's (I have done this on occasion, and have certainly never had a problem). The solution is just to erase your old file first, before saving. ------------------------------------------------------------------------------- | David Williams | University of Newcastle, Australia | | c9037544@cc.newcastle.edu.au | Computer Science student | | c9037544@jupiter.newcastle.edu.au | | |-----------------------------------------------------------------------------| | "The decision of Random Numbers is too important to be left to chance !" | -------------------------------------------------------------------------------
cs4344af@evax.arl.utexas.edu (Fuzzy Fox) (03/20/91)
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." / ---
treesh@vangogh.helios.nd.edu (03/21/91)
It has been my expirence that this command can be used safely only if you do two things frist....#1 make sure there is room on the disk, and #2, always be sure to specifiy the drive zero in your statment. save "@0:program",8 ctfm
dattier@vpnet.chi.il.us (David W. Tamkin) (03/21/91)
cs4344af@evax.arl.utexas.edu (David "Fuzzy Fox" DeSimone) posted <1991Mar20.065653.28557@evax.arl.utexas.edu>, and I'm glad he did, because it says most of what I planned to say and saves me the typing, but I have a few things to add: | 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? | 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. It was "Transactor" that uncovered it and found a way to reproduce it. Other magazines have also covered it, but none I've seen in the depth of the T. | 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. Yes, and the 1540, the 1541, and the original 1571 all copied code that assumed there were two drives and enough buffers for handling two at once. The @: code required borrowing a buffer normally used for the disk in the other slot. Since it didn't exist, anything could happen. [Fuzzy Fox details some ways around it:] | 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. Sorry. Several people posting to this thread have recommended scratching and then saving as the cure. It isn't. Scratching and then saving (unless you follow one of the other items Fuzzy Fox enumerated) can also fall afoul of the bug. Scratching, initializing, and saving will work, though. | 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. The 1571 with upgrade ROM's, the 1581, and the MSD drives all can save @: with impunity. You might still want to avoid it to keep from getting into the habit in case you sometimes use a drive that cannot handle it safely. | 2. Always give an absolute drive reference to drive 0. When | you open a file, open it as "0:filename". When you initialize the disk, | use the command "I0:". That's right. Even when you open a file for reading or loading, specify drive 0:. (The series in "Transactor" showed that a previous open for reading without specifying the drive can drag up the bug.) However, the initialize command is "i0" with no colon. "i0:" is accepted by the 1571 but gives a syntax error on the 1581. | 3. Validate the disk after @-save. Yup. That'll do it too. And another way around it: 4. Initialize the disk (preferably specifying the drive number, "i0") *immediately* before using save @: or open @:. David Tamkin PO Box 7002 Des Plaines IL 60018-7002 dattier@vpnet.chi.il.us GEnie:D.W.TAMKIN CIS:73720,1570 MCIMail:426-1818 708 518 6769 312 693 0591