REPLACE
REPLACE denotes a disk drive function that overwrites an old file when saving a new one.
On the C64, this is done using BASIC with the command SAVE "@:Name",8
.
Save-@-Bug[edit | edit source]
The built-in CBM-DOS V2.6 REPLACE in the 1541 drive (and variants) has a bug that can lead to data loss. In the updated ROMs of the 1541-II and 1571, an attempt was made to fix the issue; however, in exceptional cases (e.g., when files are open while saving), the error can still occur even with the newer versions.
This bug is caused by an issue in the use of the block buffers managed by CBM-DOS.
The drives have five buffers, all of which are needed by Save-@ (two buffers for deleting the old file, two buffers for writing the new file, and one buffer for the BAM).
However, buffers can be occupied by open files, for example. Also, typically one buffer is already permanently occupied by a leftover in the ROM of the 1541 (BAM of the nonexistent subdrive 1:
).
In this case, a mechanism to "steal" buffers comes into play, but it is poorly implemented and in certain cases leads to incorrectly written data or a corrupted BAM.
Error Conditions[edit | edit source]
Three conditions must be met for the error to occur.[1]
- The internal CBM-DOS flag for Don't write BAM must be set.
- This is always the case with Save-@. In the case of Open with Replace with secondary address 2 to 14, this flag remains unset, so everything works fine here. Accordingly:
SAVE"@:xyz",8
can trigger the error.OPEN 2,8,1,"@:xyz"
can trigger the error.OPEN 2,8,2,"@:xyz,p,w"
is error-free.
- This is always the case with Save-@. In the case of Open with Replace with secondary address 2 to 14, this flag remains unset, so everything works fine here. Accordingly:
- One or more blocks must get marked as occupied on at least three tracks.
- This causes the BAM entry/entries of the first track(s) to be stored in the block RAM buffer rather than in the BAM cache.
- If only a single block is free on the first two tracks, the bug can occur when saving a three block file already.
- This condition is met in any case if the new file is 43 blocks or longer.
- This causes the BAM entry/entries of the first track(s) to be stored in the block RAM buffer rather than in the BAM cache.
- The BAM buffer must be stolen in this condition. With Save-@, this happens if...
- the newly saved file ends on the same track where the old file, which is being deleted, begins
- AND a buffer is irreversibly occupied (in addition to the Drive 0 BAM buffer), leaving only three buffers available.
- In the 1541(-I), this is always the case unless access to Drive 1 is explicitly excluded for every action (
0:
). - In the 1541-II, a buffer must be occupied by opening a file, which could have happened unintentionally and unnoticed by the saved program.
- In the 1541(-I), this is always the case unless access to Drive 1 is explicitly excluded for every action (
Avoiding or Fixing the Error[edit | edit source]
There are several approaches to avoid or fix the error:
- Avoid using Save-@. Instead scratch the old file, then save the new file, or (if free space permits), save the new file under a new name, then scratch the old file, then rename the new file to the original name.
- Reset the drive using the disk command "UI" (or by using the reset button on the drive, or simply by turning the drive off and on) before each SAVE"@:.... - This will release all buffers, so the error cannot occur.
- Use patched drive ROMs.[2]
- 1541-I only: Explicitly specify the drive number[3] (in English, drive number) in the filename in all commands before and including the Save command, as used with dual drives:
LOAD"0:$",8
,SAVE "@0:Name",8
, and so on.- This approach prevents CBM-DOS from reserving a buffer for the BAM of the nonexistent drive
1:
. - However, no file should already be open (e.g., after a program crash, a file that was not properly closed by CLOSE could still be open).
- This approach prevents CBM-DOS from reserving a buffer for the BAM of the nonexistent drive
- Some BASIC and DOS extensions (typically hardware fast loaders) or newer DOS versions in modern drive models (in the 1571 from ROM revision 04[4] [5]) claim to fix the issue, but often only partially, as certain (though rarer) circumstances can still trigger the bug, meaning they do not reliably prevent it. Any claims of fixes should be carefully checked and questioned. If in doubt, it is recommended to follow the instructions mentioned above.
Sources[edit | edit source]
- ↑ Error conditions can be found on page 5 of
Save-With-Replace-Bug.pdf
, in the appendix of Thread: 1541/71 Save-With-Replace- and other Patches 1 on Forum64.de - ↑ Attachments with patches for the 1541/1541-II/1571/JiffyDOS and documentation at Thread: 1541/71 Save-With-Replace- und andere Patches 1 on Forum64.de by Jochen Adler
- ↑ "Save With Replace: Debugged At Last" - Part 1, Phillip A. Slaymaker, COMPUTE! Magazine, October Issue, 1985, p. 79
- ↑ comp.sys.cbm USEnet-News-Posting: 1571 ROM RELEASE NOTES: 310654-04 (Revision 04)
- ↑ English Wikipedia "Commodore DOS" discussion: For the 1571, there are practically only revisions 03 and 05, with revision 04 being replaced before production due to another bug fix by 05.
References[edit | edit source]
Wikipedia: Wikipedia: Commodore DOS: The save-with-replace bug |
- Thread: 1541/71 Save-With-Replace- and other Patches 1 on Forum64.de by Jochen Adler
- "Eliminating SAVE@ and Other 1541 Bugs", Phillip A. Slaymaker, The Transactor, Volume 7, Issue 02 (September 1986), p. 33
- "Save With Replace: Debugged At Last", Phillip A. Slaymaker, COMPUTE! Magazine, October & November 1985