Beiträge von Mike im Thema „Disk-Befehl Scratch funktioniert in manchen Vice-Versionen nicht richtig?“

    [...] der unbedarfte C64 Anwender denkt dann [...]

    Hier ist schon mal eine grundsätzliche Fehlannahme drin. Es gibt keine unbedarften C64-Anwender. Die Kenntnis des C64- und 1541-Handbuchs darf man einfach mal voraussetzen.

    Aus meiner Sicht sind für einen Editor, gleich welcher Art, nur drei Datei-Funktionen zwingend notwendig: 1. Speichern (mit automatischem Löschen einer vorher existenten Datei, um der Semantik des CBM DOS gerecht zu werden), 2. Laden und 3. Verzeichnis der Disk anschauen. Das habe ich so z.B. in Bitte melde dich an, um diesen Link zu sehen. auf dem VC-20 so realisiert.

    Alles darüber hinaus sind Komfort-Funktionen, die im wesentlichen in Richtung Arbeitsorganisation gehen. In dem Fall hättest Du das aber auch noch nicht zuende gedacht: Umbenennen und Löschen einer Datei, in Ordnung, was macht der User wenn alle Disketten voll sind und er erst mal eine neue Diskette formatieren muß? Wenn Du das zuende denkst, kommst Du darauf, daß Du im Grunde die komplette Funktionalität die Du von einem Dateimanager kennst, gleich noch in dein spezielles Anwendungsprogramm mit hinzupacken müßtest. Deswegen meine Frage, ob Du gerade eine DOS SHELL programmierst.

    Ich wiederhole mich hier zwar, und andere Gesprächsteilnehmer sehen das ja auch so ähnlich, aber nochmal: Nein - der erfolgreiche Betrieb deines Programms hängt eben nicht von der Rückmeldung des Scratch-Befehls ab! Was zählt ist: der User soll in der Lage sein, seine (unter Umständen stundenlange) Arbeit auf einem Speichermedium sichern zu können. Das möglichst, ohne daß das Programm zwischendurch abstürzt. Wenn von vornherein klar ist, daß das Programm als Dateioperationen "nur" Speichern, Laden und Verzeichnis anschauen ermöglicht, ist es Sache des Anwenders vorher dafür zu sorgen, daß er eine formatierte Diskette zur Hand hat. Sowas, etwas netter formuliert, stand dann auch in den Anleitungen der Programme drin.

    Du kannst es gerne etwas aufwendiger machen. Irgendwann kommst Du aber an den Punkt, wo Du einen vollwertigen Dateimanager geschrieben hast, der zufällig auch noch Zeichensätze editieren kann und das heißt, den Programmieraufwand an einen Nebenkriegsschauplatz zu verschwenden.

    [...] ich würde alles tun, damit mein Programm darauf funktioniert.

    Also bitte: die Meldung "FILES SCRATCHED" von CBM DOS ist rein informativer Natur und nicht im eigentlichen Sinne eine Fehlermeldung (steht auch so im Handbuch!). Von so einer Art Meldung kann das Funktionieren deines Programms also nicht wirklich abhängen. Wenn nach dem Erzeugen der neuen Datei - mit dem gleichen Namen - was anderes als "00, OK, 00, 00" kommen sollte, dann kannst Du ja immer noch reagieren.

    Anders gesagt: es sind nach einem Scratch-Befehl ja auch noch andere Rückmeldungen denkbar. Etwa DRIVE NOT READY, wenn keine Diskette eingelegt ist. Diverse READ ERRORS, wenn das Laufwerk dejustiert ist und Sektoren nicht lesen kann. WRITE ERRORS, wenn sich die Floppy zuvor beim Schreiben "verhaspelt" hat (kommt bei Gleichlaufschwankungen vor).

    Generell sind die Rückmeldungen erst ab Nr. 20 relevant als Fehler. Alles bis dahin ist wie oben geschrieben informativer Natur (bei der 1581 gibt es z.B. auch 02, PARTITION SELECTED, ...) - insofern ist das Verhalten vom TheC64 mini hier auch einfach mal inkorrekt. Workaround, der aber auch auf originaler Hardware geht, s.o.

    Aber trotzdem muss ich mein Programm nun so ändern, dass es mit beidem funktioniert.

    Ein Programm an eine kaputte Emulation anzupassen ist nicht die allerbeste Idee.

    Und vielleicht auch gar nicht nötig: wenn es nur darum geht, eine nur möglicherweise zuvor vorhandene Datei zu löschen, damit eine neue Datei unter gleichem Namen gespeichert werden kann, dann reicht es doch einfach den Scratch-Befehl abzuschicken ohne die Rückmeldung zu überprüfen.

    Auf dem PC mit Vice Emulator bekomme ich im Fehlerkanal folgende falsche Rückmeldung:

    01, FILES SCRATCHED, 00, 00

    Nein, die Meldung ist schon richtig: die "Track"-Nummer hinter "FILES SCRATCHED" gibt die Anzahl der gelöschten Dateien - hier 0(!) - an.

    Ein halbwegs aktuelles VICE mit TDE on kannst Du derweil einfach mal als Referenz ansehen, das DOS hat bei deinem einfachen Programm einfach keine Idee, daß es in Emulation läuft. Dagegen basiert die Emulation auf dem TheC64 meines Wissens auf VICE 2.4, ist also technisch gesehen ca. 10 Jahre hinterher. Das VDrive da nutzt dann scheinbar eine andere Rückmeldung, die für sich gesehen in Ordnung geht - aber nicht dazu paßt, daß zuvor ein Scratch-Befehl abgesetzt wurde.

    Du brauchst zum Lesen der Fehlermeldung übrigens keinen zweiten Kommandokanal zu öffnen. Die Meldung kannst Du in deinem Beispiel auch in File Bitte melde dich an, um diesen Link zu sehen. abrufen, wenn Du die Zeilen 20 und 50 wegläßt, und Zeile 30 auf 30 INPUTBitte melde dich an, um diesen Link zu sehen.,... änderst.