Datei Byte für Byte überschreiben

Es gibt 17 Antworten in diesem Thema, welches 2.813 mal aufgerufen wurde. Der letzte Beitrag (6. Februar 2014 um 14:35) ist von mc71.

  • Hallo Kompetenz,

    mir war immer so, daß sich die Spielstände mit und ab dem zweiten Speichern bei mir nicht mehr verändern. Jetzt ist es Fakt....

    Fragen:

    1. Wie überschreibe ich eine bestehende Datei Byte für Byte?

    Wenn ersteres beim C64er nicht so einfach ist.....
    2. Wie lösche ich eine Datei von der Diskette (in Basic SCRATCH)?

  • 1. Gar nicht.
    Mit @SAVE bzw. @OPEN kann man eine Datei theoretisch ersetzen, aber praktisch ist diese Funktion auf der 1541/1571 verbuggt und kann andere Files beschädigen - daher sollte sie niemals benutzt werden.
    Mit Direktzugriffsbefehlen geht es natürlich auch, das ist aber nicht nett gegenüber den Besitzern modernerer Massenspeicher, daher sollte man es auch eher vermeiden (außerdem müsstest Du Dich in das Thema erst einarbeiten).
    Und über REL-Files ginge es natürlich auch, aber die haben dafür andere Einschränkungen; das willst Du auch nicht machen.

    2. Schick den String "s0:filename" über den Befehlskanal und die Datei "filename" wird gelöscht. in Basic: OPEN1,8,15,"S0:FILENAME":CLOSE1

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Code
    @O:test.std

    Der Zusatz @O: bewirkt eine Überschreibung einer bestehenden Datei test.std.

    Nein. @ bewirkt das Überschreiben und triggert bei einigen Laufwerken den Bug, der dann Daten schreddert. O: gibt es überhaupt nicht, was du meinst ist 0: -- das wählt explizit Laufwerkseinheit 0 und ergibt eigentlich nur bei Doppellaufwerken einen Sinn, soll aber angeblich den Bug vermeiden. Hilft nur nichts, denn wenn vorher auf dem Laufwerk andere Befehle ohne explizites 0: verwendet wurden, passiert der Mist trotzdem. Da hilft nur eines: auf @ (Überschreiben) komplett verzichten.

    Bitte melde dich an, um diesen Link zu sehen.

  • Es hiess der @-Fehler sei im ROM der 1541-II behoben. Weiss das jemand genauer?

    Computer says yes (Google, verschiedene Quellen). Hilft aber dem Entwickler nicht weiter, man weiß ja nicht, was der User für Hardware hat ;)

  • Es hiess der @-Fehler sei im ROM der 1541-II behoben. Weiss das jemand genauer?


    Ich gehe schwer davon aus. Ich habe von diesem Fehler noch nie was gehört und mein Leben lang immer SAVE"@: statt Scratch benutzt. Hab nur ne 1541-II gehabt und kann mir das schwer als Zufall erklären.
    Bin aber ebenfalls an genaueren Infos interessiert.

    EDIT: achso, mit "genauer" meine ich jetzt eher sowas wie ROM-Code Vergleich und nicht lediglich die Aussage "wurde gefixed" (die ich zwischenzeitlich auch ergooglen konnte).

  • Es hiess der @-Fehler sei im ROM der 1541-II behoben. Weiss das jemand genauer?


    Der Save@ Bug betrifft nur alte 1541-I ROMs, trotzdem codet man NIE einen HighscoreSaver mit Save@, Kollege Spider, sondern macht es immer so:

    2. Schick den String "s0:filename" über den Befehlskanal und die Datei "filename" wird gelöscht. in Basic: OPEN1,8,15,"S0:FILENAME":CLOSE1


    Also sauber scratchen und dann speichern.
    Shice auf die Sekunde, die es länger dauert, und die paar Bytes mehr, die man für den Code braucht, wenn der andere Fall dazu führt, dass es ein - egal wie geringer - Teil von Usern die Software nicht gebrauchen kann.

    @VM: Auf der Codebase findest Du alle möglichen KERNAL-DISK-OP Codeschnipsel (iirc von Graham), die Du brauchst.


  • Also sauber scratchen und dann speichern.

    Nein, auf keinen Fall so, dann gibt es nämlich einen Zeitraum in dem dir ein Systemcrash die Highscores vernichtet.

    Korrekt geht das so:

    - Datei mit Namen <X> speichern.
    - Alte Datei mit Namen <Y> löschen
    - Datei nochmal mit Namen <Y> speichern
    - Datei <X> löschen.

    Ist man etwas weniger paranoid kann man die beiden letzten Aktionen durch

    - Umbenennen von <X> nach <Y>

    ersetzen.

    Dazu natürlich noch beim Laden der highscores nicht nur nach <Y> suchen sondern, wenn <Y> nicht gefunden wird, auch nach <X> und wenn diese Konstellation gefunden wird, erstmal korrigieren.

  • Es hiess der @-Fehler sei im ROM der 1541-II behoben. Weiss das jemand genauer?


    Selbst wenn es stimmt: Es gibt hier im Forum einen Erfahrungsbericht eines Users, bei dem der Fehler auch mit einer 1541-II aufgetreten ist! Es kann natürlich sein, dass im 1541-II-Gehäuse dieses Benutzers in Wirklichkeit eine alte Platine bzw. ein altes ROM steckt. Aber dieser Fall wäre für mich Grund genug, auch 1541-II-Besitzern vom Benutzen von SAVE-WITH-REPLACE abzuraten; auch im Direktmodus - in Programmen verbietet sich der Einsatz wegen der möglichen Verbreitung ja eh.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Code
    @O:test.std

    Der Zusatz @O: bewirkt eine Überschreibung einer bestehenden Datei test.std.

    Schade, daß ersteres nicht möglich ist. Aber Danke für die Info. :)

    Überschrieben wird da gar nichts. @: schreibt die neue Datei auf die Diskette und löscht danach die alte Datei. Aus diesem Grund funktioniert @: auch nur, wenn mindestens soviele Blocks auf der Diskette frei sind, wie die Datei gross ist. Ansonsten gibt es Datenverlust. Dazu kommt natürlich noch, dass @: verbuggt ist.

    Am besten ist es also, dass ganze "von Hand" zu machen. Im einfachsten Fall heisst das, dass man erstmal mit S: die alte Datei löscht und dann die neue Datei ohne @: speichert.

  • - Datei mit Namen <X> speichern.


    Und was ist, wenn der Strom ausfällt während die Floppy gerade den BAM-Sektor aktualisiert?

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.


  • Und was ist, wenn der Strom ausfällt während die Floppy gerade den BAM-Sektor aktualisiert?

    Für diese Sicherheit braucht man eine USV. Ansonsten ist es aber eine normale Vorgehensweise erst zu speichern und dann den alten Stand zu löschen.

  • Nein, auf keinen Fall so, dann gibt es nämlich einen Zeitraum in dem dir ein Systemcrash die Highscores vernichtet.


    in der praxis hat das allerdings bei ca 100000 spielen bisher niemand gestört :)

  • hehe, den von Gerrit beschriebenen Fall und seine empfohlene Vorgehensweise halte ich allerdings auch schon in der weniger verschärften Fassung für sehr paranoid. Man müsste für diesen Fall ja auch beim Programmstart eine Plausibilitätsprüfung einführen, deren Fehlerreport dazu führt ein Ersatzfile zu laden und dieses wiederum auf Plausiblität zu prüfen. Das erschlägt man bei Cracks meiner Erfahrung nach eher dadurch, dass man entweder LOAD/RESET HS anbietet oder einfach für den Fall Whatever-Load-Error eine neue Tabelle mit Default-Werten generiert/speichert.

    Save@ halte ich weiterhin für Pfusch/fahrlässig

  • In der Filebase unter "Commodore » Commodore 8 Bit » Alte Hardware » Firmware" findet man in

    "1541_Save-with-Replace_-_Debugged-at-Last_(Compute + The Transactor)"

    genaueres über den @-Fehler (Save-with-Replace) der Commodore-Floppies

  • Leider steht da nichts über die Korrektur in der 1551, 1541-II und (hoffentlich) 1581 drin. Und der Code ist dermaßen strubbelig daß selbst die besten kommentierten ROM-Listings nicht wirklich verständlich sind... also kaum eine Chance die Modifikationen zu verstehen, geschweige denn auf Fehlerfreiheit zu prüfen.

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.