REPLACE

REPLACE (zu deutsch: Ersetzen) bezeichnet eine Floppy-Funktion (siehe auch Floppy-Befehle), die beim Abspeichern einer Datei die alte Datei überschreibt. Beim C64 wird dies z.B. mit BASIC mittels SAVE "@:Name",8 durchgeführt.

Save-@-Bug

Das eingebaute CBM-DOS V2.6 REPLACE beim Laufwerk 1541 (und Varianten) ist fehlerbehaftet und kann zu Datenverlusten führen. In den aktualisierten ROMs der 1541-II und 1571 wurde versucht, den Fehler zu beheben; in Ausnahmefällen (z.B. falls Dateien geöffnet sind, während das SAVE erfolgt) tritt der Fehler jedoch auch mit den neueren Versionen noch auf.

Diesem Bug liegt ein Problem in der Verwendung der von CBM-DOS verwalteten Block-Puffer zugrunde.

Die Laufwerke verfügen über fünf Puffer, die allesamt von Save-@ benötigt werden (zwei Puffer für das Löschen der alten Datei, zwei Puffer für das Schreiben der neuen Datei, ein Puffer für die BAM). Puffer werden z.B. durch geöffnete Dateien belegt, außerdem ist durch eine Altlast im ROM der 1541 typischerweise ein Puffer bereits dauerhaft belegt (BAM des nichtexistenten Unterlaufwerks 1:). In diesem Fall greift ein Mechanismus zum "Stehlen" von Puffern, der jedoch fehlerhaft implementiert ist und in bestimmten Fällen zu fehlerhaft geschriebenen Daten bzw. defekter BAM führt.

Bedingungen für das Auftreten des Fehlers

Es müssen drei Bedingungen erfüllt sein, damit der Fehler auftritt.

1. Das CBM-DOS-interne Flag für Don't write BAM muss gesetzt sein.
   • Dies ist bei Save-@ immer der Fall. Beim Open with Replace mit Sekundäradresse 2 bis 14 bleibt dieses Flag gelöscht, sodass hier alles fehlerfrei abläuft. Entsprechend:
     • SAVE"@:xyz",8 kann den Fehler auslösen.
     • OPEN 2,8,1,"@:xyz" kann den Fehler auslösen.
     • OPEN 2,8,2,"@:xyz,p,w" ist fehlerfrei.
2. Es müssen auf mindestens drei Spuren ein oder mehrere Blöcke belegt werden.
   • Dies bewirkt, dass der BAM-Eintrag / die BAM-Einträge der ersten Spur(en) nur noch im Block-RAM-Puffer und nicht mehr im BAM-Zwischenspeicher gehalten wird/werden. Bei Save-@ muss die neue Datei über mindestens drei Spuren gehen.
     • Wenn auf den ersten beiden Spuren nur jeweils ein einziger Block frei ist, dann kann der Bug schon beim Abspeichern eines drei Blöcke langen Files auftreten.
     • Wenn die neue Datei mindestens 43 Blöcke lang ist, dann ist die Gefahr immer gegeben.
3. Der BAM-Puffer muss in diesem Zustand gestohlen werden. Bei Save-@ passiert dies, wenn...
   • das neu abgespeicherte File auf dem gleichen Track endet, auf dem das alte, zu löschende File beginnt
   • UND ein Puffer unwiderruflich belegt ist (zusätzlich zum Drive-0-BAM-Puffer), sodass nur noch drei Puffer verfügbar sind.
     • Bei der 1541(-I) ist dies immer der Fall, solange man nicht bei jeder Aktion ausdrücklich den Zugriff auf Drive 1 ausschließt (0:).
     • Bei der 1541-II oder neuer ist das der Fall, falls Puffer durch geöffnete Dateien belegt sind, was aber unabsichtlich und unbemerkt durch das abgespeicherte Programm passiert sein kann.

Vermeidung und Beseitigung des Fehlers

Für das Vermeiden oder Beseitigen des Fehlers gibt es mehrere Ansätze:

• Vermeiden von Save-@, stattdessen Scratch, dann normales SAVE (oder, falls genug Platz auf Diskette ist, SAVE unter neuem Namen, dann Scratch, dann Rename).

• Nutzung von Patches für das DOS-ROM des Laufwerks

• Zurücksetzen des Laufwerks mit dem Floppy-Befehl "UI" (oder per Reset-Taster am Laufwerk oder einfach per Aus-/Einschalten) vor jedem SAVE"@:...". Damit werden alle Puffer freigegeben, der Fehler kann dementsprechend nicht mehr auftreten.

• Nur beim alten ROM der 1541-I: Explizite Angabe der Laufwerksnummer (engl. drive number) im Dateinamen in allen Befehlen vor und inklusive des Save-Befehls, wie sie bei Doppellaufwerken zum Einsatz kommt: LOAD"0:$",8, SAVE "@0:Name",8 und so weiter.
  • Dieses Vorgehen verhindert, dass das CBM-DOS fälschlicherweise einen Puffer für die BAM des nichtexistenten Laufwerks 1: reserviert.
  • Gleichzeitig geöffnete Dateien können den Fehler aber trotzdem auslösen (z.B. auch nach einem Programmabbruch nicht mehr mit CLOSE geschlossene und damit offen gebliebene Datei).

• Manche BASIC- und DOS-Erweiterungen (typischerweise Hardware-Schnelllader) oder neuere DOS-Versionen in moderneren Laufwerksmodellen (bei 1571 ab ROM Revision 04 ) geben zwar an, den Fehler zu beheben, tun dies aber oft auch nur teilweise, da gewisse (wenn auch seltenere) Umstände den Fehler dennoch provozieren, also nicht zuverlässig verhindern können. Etwaige Angaben zur Behebung sind stets entsprechend zu prüfen und zu hinterfragen. Im Zweifelsfall gilt die Empfehlung, sich an den oben genannten Hinweisen zu orientieren.

Referenzen

• Thema: 1541/71 Save-With-Replace- und andere Patches 1 auf Forum64.de von Jochen Adler
• Wikipedia: Commodore DOS: The save-with-replace bug
• "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 (vor Erscheinen der 1541-II)
  • Part 1: Issue 65 October 1985, p. 79
  • Part 2: Issue 66 November 1985, p. 111