C64 - Basic V2 - Datei mit Save überschreiben?

Es gibt 35 Antworten in diesem Thema, welches 8.157 mal aufgerufen wurde. Der letzte Beitrag (1. November 2016 um 19:28) ist von Paradroid.

  • Hallo an alle Coder,

    ich schreibe zur Zeit an einen kleinen Programm mit meinen C64 unter Basic V2.
    Sowie ich einige Zeilen mehr programmiert habe, speicher ich das Programm unter den gleichen Namen mit SAVE "Name",8 auf
    meinem Laufwerk.

    Sowie ich aber genau dieses soeben gespeicherte Programm erneut mit LOAD "Name",8,1 lade, habe ich den alten Code.
    Es ist zu lange her, aber kann man nicht immer unter den selben Namen abspeichern ?

    Das ist echt nervig, und ich speicher jetzt immer unter Name1, Name 2 usw. Da zumindest ist der aktuelle Code ja dann auch vorhanden.


    Mit freundlichen Grüßen to all....SwiftCoder :winke:

  • Es gibt ein SAVE was die alte Datei ersetzt, aber da gibt es 2 Tücken: Erstens muss noch genug Platz auf der Diskette sein für die Datei die man speichert, und dann gibt es Bugs im Laufwerk die den Befehl ab und zu mal versagen lassen.

    Am besten also: Alte Datei von Hand löschen, und danach erst SAVE.

    Löschen geht so:

    OPEN 15,8,15,"S:<dateiname>":CLOSE 15

    Naja und SAVE geht so:

    SAVE "<dateiname>",8

    Wenn du nen Cartridge hast, geht es einfacher.

    Wildcards gehen beim Löschen auch, wenn man z.B. "S*" als Namen angibt, wird jede Datei gelöscht wo der Name mit "S" anfängt.

  • Sowie ich einige Zeilen mehr programmiert habe, speicher ich das Programm unter den gleichen Namen mit SAVE "Name",8 aufmeinem Laufwerk.

    ...und anschließend blinkt die Laufwerks-LED. Das tut sie nicht zum Spaß. ;)
    Würdest Du den Statuskanal abfragen, käme die Fehlermeldung "FILE EXISTS" zurück.

    Es ist zu lange her, aber kann man nicht immer unter den selben Namen abspeichern ?

    Jein. Es gibt ein DOS-Feature, um beim Speichern eine vorhandene Datei zu ersetzen. Dieses Feature (save"@0:name",8) ist aber verbuggt und sollte daher niemals benutzt werden, denn es kann beliebige Dateien auf der Diskette zerstören.

    Das ist echt nervig, und ich speicher jetzt immer unter Name1, Name 2 usw. Da zumindest ist der aktuelle Code ja dann auch vorhanden.

    Bleib dabei.

    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..

  • Bitte melde dich an, um diesen Link zu sehen.:
    ups das wusste ich nicht, gut zu wissen, vielen dank.
    ähm - warum ein :CLOSE 15 und kein :CLOSE 1 ?

    Bitte melde dich an, um diesen Link zu sehen.:
    jepp die Led hat immer wild geblinkt. War mir schon klar das da was nicht stimmt.
    Vielen Dank dafür. Ärgert mich nur, da ich gut 20 Zeilen Code geschrieben habe und die weg waren.
    Na aus Schaden wird man klug, :cry:

    SwiftCoder

  • Bitte melde dich an, um diesen Link zu sehen.:
    ups das wusste ich nicht, gut zu wissen, vielen dank.
    ähm - warum ein :CLOSE 15 und kein :CLOSE 1


    Da ich OPEN mit Filenummer 15 gemacht hab, ist auch CLOSE 15 angesagt. Kannst auch 1 nehmen oder 2 oder 3, aber da ich mir nie gemerkt hab was nun die Filenummer ist, nehm ich einfach 2 mal 15, Filenummer 15 und Kanal 15. :)

    EDIT: So grad mal nachgesehen, OPEN 1,8,15,"S:<datei>":CLOSE 1

    Hab aber immer 15 genommen, hehe.

  • ...oder jedes Mal beim Speichern der Datei, eine neue, frische Diskette auspacken und einlegen. Dann kann man immer unter dem gleichen Namen speichern... :weg:


    <Edit>

    OPEN 1,8,15,"S:<datei>":CLOSE 1

    Das 15 in OPEN 1,8,15,"S:<datei>":CLOSE 1 ist wichtig, weil das der Bitte melde dich an, um diesen Link zu sehen. (Sekundäradresse 15) ist, mit dem man der Floppy eben Befehle, wie Formatieren, Löschen etc. übergibt.

    ___________________________________________________________
    Meine Kreationen: 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. | Bitte melde dich an, um diesen Link zu sehen.
    | Bitte melde dich an, um diesen Link zu sehen.
    Avatar: Copyright 2017 by Saiki

    2 Mal editiert, zuletzt von syshack (19. Oktober 2016 um 11:58)

  • Da ich OPEN mit Filenummer 15 gemacht hab, ist auch CLOSE 15 angesagt. Kannst auch 1 nehmen oder 2 oder 3, aber da ich mir nie gemerkt hab was nun die Filenummer ist, nehm ich einfach 2 mal 15, Filenummer 15 und Kanal 15.

    Alles klar. hab mich schon gewundert :) Also 1,8,15 war und ist mir geläufig. Dabei bleibe ich auch :saint:

  • Alles klar. hab mich schon gewundert :) Also 1,8,15 war und ist mir geläufig. Dabei bleibe ich auch :saint:


    Ist halt Gewohnheit, hatte damals mal das Problem dass ich das immer verwechselt hab und dann einfach beide Parameter mit "15" gefüttert. :)

  • Bitte melde dich an, um diesen Link zu sehen.:
    Nun ja, soviel Disketten habe ich aber auch nicht am Start. Dann lieber Scratchen und speichern oder halt
    die Methode: N1, n2, n3, usw. abspeichern. Dennoch danke für den Tipp von dir :D

  • Achtung! Es passen nur 144 Einträge auf die Diskette, auch wenn sie in der Summe weniger als 664 Blocks brauchen.
    Also rechtzeitig neue Diskette besorgen oder Rückseite formatieren ;)

    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?

  • Ah, einen hab ich noch:
    Wenn Scratchen dann immer erst speichern unter anderem Namen, dann scratch und dann mit Rename umbenennen. So vermeidet man Datenverlust.

    Aus C64-WIKI:
    Datei umbenennen (RENAME): R:NeuerName=AlterName

    • Beispiel unter BASIC 2.0: OPEN 1,8,15,"R:SPIEL2016=SPIEL2000": CLOSE 1


    Edit:
    Und Scratchen IMMER nur den Fachmann machen lassen:
    Bitte melde dich an, um dieses Medienelement zu sehen.

    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?

  • Jein. Es gibt ein DOS-Feature, um beim Speichern eine vorhandene Datei zu ersetzen. Dieses Feature (save"@0:name",8) ist aber verbuggt und sollte daher niemals benutzt werden, denn es kann beliebige Dateien auf der Diskette zerstören.

    SAVE"@:name",8 ist eigentlich die problematische Variante, während SAVE"@0:name",8 ohne schädliche Nebenwirkung funktionieren sollte.
    Siehe Bitte melde dich an, um diesen Link zu sehen.

    Neuere Laufwerke (hängt aber mitunter auch von der ROM-Version ab) oder diverse Speeder beheben nicht selten nebenbei auch diesen Bug, aber das sollte man im Einzelfall für die eigene C64-Umgebung abklären.
    Mit dem allgemein gültigen Rat, vorher mit Scratch die Datei zu löschen, liegt man definitiv auf der sicheren Seite. ;)

    Aus meiner Praxis kann ich nur sagen, dass mir das vorhergehende löschen ein Graus und war und mir zu langwierig ist. Ich speichere immer Revisionen mit "-1", "-2" usw. am Ende. Gut, das beansprucht 2 bis 3 Zeichen des Dateinamens, aber man gewinnt weitaus mehr an Sicherheit, hat nebenbei noch alte Versionen oder zu sich ähnliche Sicherheitskopien ... auch wenn das zu Lasten der Disk-Kapazität geht. Falls man die Zwischenversionen nicht mehr braucht oder fertig ist, benennt man dann die aktuelle Revision mit Rename-Floppy-Befehl um ("R:NAME=NAME-x"), und löscht eventuell die anderen mit "S:NAME-*".

  • SAVE"@:name",8 ist eigentlich die problematische Variante, während SAVE"@0:name",8 ohne schädliche Nebenwirkung funktionieren sollte.

    Irgendwo hier im Forum hat jemand (NLQ? x1541?) beschrieben, dass bei der vermeintlich "sicheren" Variante der Fehler immer noch auftreten kann, nur deutlich seltener - da es sich eigentlich um zwei Bugs handelt. Ich suche mal eben...

    EDIT: Es war NLQ, Bitte melde dich an, um diesen Link zu sehen.. Aus dem dortigen PDF:

    Zitat von NLQ

    Im Gegensatz zur Aussage der 'Compute!' verhindert das ausdrückliche Angeben von Drive 0 bei jedem Kommando ('0:') den Save@-Bug nicht zuverlässig, wie das Beispielfile '@BUG-1FILEOPEN' zeigt.
    [...]
    Die CBM-Patches der 1541-II (und der 1571) verhindern den Save@-Bug nicht zuverlässig.

    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..

    2 Mal editiert, zuletzt von Mac Bacon (19. Oktober 2016 um 13:59)

  • Irgendwo hier im Forum hat jemand (NLQ? x1541?) beschrieben, dass bei der vermeintlich "sicheren" Variante der Fehler immer noch auftreten kann, nur deutlich seltener - da es sich eigentlich um zwei Bugs handelt. Ich suche mal eben...
    EDIT: Es war NLQ, Bitte melde dich an, um diesen Link zu sehen.. Aus dem dortigen PDF:

    Ahja, kannte ich auch, wunderbare Arbeit von NLQ. Genau genommen steht im PDF auch genau drinnen, warum das nicht zuverlässig arbeitet, nämlich nur dann, wenn noch eine offene Datei einen Puffer belegt. Das ist sicherlich nicht der Regelfall, aber blöderweise, wenn man gerade an einem Programm herumbastelt, dass mit einem Fehler bei einer Dateioperation mit Fehler abbricht, hätten wir die Situation, deren Brisanz man sich in diesem Moment vermutlich nicht bewusst ist. Genau das provoziert auch das genannte Beispielprogramm. Das gleiche Leiden haben auch die seitens CBM in höheren ROM-Revisionen gemachten Adaptionen der im Compute! veröffentlichten Behebungsvariante. Allesamt zwar qualitativ ein Verbesserung, aber so ganz sicher ausgeschlossen ist der Fehler so nicht.

    Eine andere, aber zuverlässige Variante wäre ja vor jedem SAVE-@ ein "UI" ans Laufwerk zu schicken. Das ist wirklich zuverlässig, abgesehen von den DOS-Patches von NLQ.

    Das ist jetzt im Bitte melde dich an, um diesen Link zu sehen. auch genauer ausgeführt. Danke für den Hinweis!

  • ich glaube da is dir etwas weg gekomm Jeek,
    die wiki beendet bei mir so

    Code
    Manche BASIC- und DOS-Erweiterungen (typischerweise Hardware-Schnelllader) bzw. neuere DOS-Versionen in moderneren Laufwerksmodellen (bei 1571 mit ROM Revision 05) beheben diesen Fehler, aber möglicherweise auch nur teilweise. Dies muss man entsprechend


    salute

  • ich glaube da is dir etwas weg gekomm Jeek,
    die wiki beendet bei mir so

    Code
    Manche BASIC- und DOS-Erweiterungen (typischerweise Hardware-Schnelllader) bzw. neuere DOS-Versionen in moderneren Laufwerksmodellen (bei 1571 mit ROM Revision 05) beheben diesen Fehler, aber möglicherweise auch nur teilweise. Dies muss man entsprechend

    salute

    Oops, danke. Hab's korrigiert. Ich hoffe, es liest sich jetzt besser. :D

  • Interessant!
    Ich muß zugeben, den Save@: Bug kannte ich garnicht.
    Hatte aber auch noch nie Probleme deswegen, und ich speichere ständig Files auf die Weise. (hab' 'ne 1541 II)
    Gibt es vielleicht auch weniger Probleme wegen dem Action-Replay, oder hatt' ich einfach nur Glück?

    Projekte von The7A3: Giana-Sisters 30th Anniversary (in Arbeit) 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., - Videos auf Bitte melde dich an, um diesen Link zu sehen..

  • What Fröhn sez.

    Dem 1541-I-Save@-ROM-Bug wird man zwar nur selten in freier Natur begegnen, aber unverhofft kommt öfter als man denkt oder so.

    Und es gibt wenig ärgerlicheres, als Datenverust wegen NICHT

    [...] genug Platz auf der Diskette [...] für die Datei die man speichert


    Daher immer

    Code
    open1,8,15,"s:foo":close1
  • Ich hoffe, es liest sich jetzt besser.

    Gut gut.
    Die Erklärung zu den 1571-Revisionen in Fußnote/Quelle 4 kann aber eigentlich raus, weil's IMO nicht weiter wichtig ist, worauf genau sich der Slaymaker (was für ein Name...) da bezieht. Im Grunde hat er ja nichtmal wirklich unrecht mit seiner Erwähnung von Revision -04, denn da tauchte der Fix erstmals auf:
    Bitte melde dich an, um diesen Link zu sehen.

    Nur trifft man diese Revision halt nicht in der freien Wildbahn an (zumindest wurde sie noch nie gesichtet), weil der gute Fred Bowen noch kurz vor Ultimo einen Bug gefunden und die 04 mit der gefixten 05 ersetzt hat bevor's in Produktion ging:
    Bitte melde dich an, um diesen Link zu sehen.

    (Das Stückchen dazu unten auf der verlinkten Wikipedia-Diskussionsseite stammt von mir. Hätte ich vielleicht damals besser ausführen sollen. :) )

  • Die Revision 4 würde ich einfach schon mit dem Hintergrund "Historisches Wissen erhalten" drin lassen. Egal ob es eine Relevanz für den "Endnutzer" hat, es ist ein schönes kleines Detail.

    GREETINGS PROFESSOR FALKEN
    A STRANGE GAME.
    THE ONLY WINNING MOVE IS NOT TO PLAY.
    HOW ABOUT A NICE GAME OF CHESS?