Hallo Besucher, der Thread wurde 1,9k mal aufgerufen und enthält 10 Antworten

letzter Beitrag von mc71 am

Erzeugung von .P00 Files deaktivieren

    Wenn ich von BBSen Daten direkt auf mein SD2IEC (aus der Sammelbestellung von @Bobbel, aktuelles nightly build SD2IEC V.1.0.0ATENTDEAD0-19-M644P-SW2-MINI) speichere, geschieht dies oft als .P00 File. Problematisch ist das z.B. bei Mulitpart-Zipcode Files, die lassen sich so nicht entzippen (z.B. mit zip2disk: "File corrupted"). DirMaster v3.1.1 kommt mit diesen .P00 Files auch nicht weiter, der Versuch endet mit einem unbrauchbaren .D64 je Zipcode-File. Manchmal kopiere ich mit einem Filebrowser (SDBrowse V.697) ein .PRG in ein anderes Verzeichnis, wo es dann mit abgekürztem Dateinamen und .P00 Extension landet. :poop:


    Ein .PRG als .P00 lässt sich zwar starten, in anderen Fällen bedeutet .P00 aber Datenverlust. Ärgerlich :thumbdown:
    Lässt sich das Schreiben von .P00 Files, die original keine .P00 Files waren, abstellen? Wenn ja, wie?

    Zitat von Ballblazer

    in anderen Fällen bedeutet .P00 aber Datenverlust. Ärgerlich :thumbdown:

    P00 ist nur ein zusätzlicher Header vor der Originaldatei und bedeutet somit niemals Datenverlust. Wenn ein Tool damit nicht klarkommt, konvertiert man die Datei eben erst zurück.

    Zitat von Ballblazer

    Lässt sich das Schreiben von .P00 Files, die original keine .P00 Files waren, abstellen? Wenn ja, wie?

    Ja, das steht sogar im README.

    Zitat von Ballblazer

    Lässt sich das Schreiben von .P00 Files, die original keine .P00 Files waren, abstellen? Wenn ja, wie?

    Ja, siehe Doku:


    Allerdings gibt es noch die zusätzliche Einschränkung, dass Dateinamen, die mit FAT nicht darstellbar sind immer als P00-Datei gespeichert werden. Die Prüfung ist dabei etwas strikter als unbedingt notwendig, zB habe ich Leerzeichen in der Liste vergessen (Fix kommt) und bei mehr als einem Punkt im Namen wird auch P00 erzwungen, obwohl das auf FAT nicht immer problematisch ist.

    Zitat von Unseen

    Ja

    Leider hatte ich mit
    @"XE0"
    und dann
    @"XW" (zum abspeichern im EEPROM)
    keinen Erfolg, .P00 werden weiterhin geschrieben. nota bene: @"XD?" erwidert wie auch beide Befehle zuvor keinerlei Infos, womit unklar ist, ob das überhaupt ankommt. JiffyDOS V6.01 via EF3. OPEN15,8,15,"XD?":CLOSE15 lässt die rote LED dauerhaft blinken. Hmm …


    Filenamen wie 1!blah+-6hd oder 1!sonst was/lxt kommen häufig vor, wäre es nicht sinnvoller, statt in diesen Fällen ein .P00 zu schreiben, kritische Zeichen durch etwas unverfängliches zu ersetzen?

    Zitat von Ballblazer

    @"XD?" erwidert wie auch beide Befehle zuvor keinerlei Infos

    Dass die @-Befehle nichts ausgeben ist aber nicht das Problem von sd2iec, sondern von JiffyDOS. Das sendet zwar das entsprechende Kommando ans Laufwerk, fragt den Fehlerkanal aber nur ab, wenn man ein @ ohne Argumente als Befehl eingibt.


    Aber warum willst du das Laufwerksmapping abfragen? Du hast doch vermutlich eh keine ATA-Laufwerke und auch keine zweite SD-Karte angeschlossen, so dass der Befehl eh nicht funktioniert.


    Zitat

    wäre es nicht sinnvoller, statt in diesen Fällen ein .P00 zu schreiben, kritische Zeichen durch etwas unverfängliches zu ersetzen?

    Nein, dann sind Dateinamen nicht mehr eindeutig.

    Zitat von Unseen

    Dass die @-Befehle nichts ausgeben ist aber nicht das Problem von sd2iec, sondern von JiffyDOS. Das sendet zwar das entsprechende Kommando ans Laufwerk, fragt den Fehlerkanal aber nur ab, wenn man ein @ ohne Argumente als Befehl eingibt.

    OPEN15,8,15,"XE0":CLOSE15 erwidert aber auch nichts, dito OPEN15,8,15,"XW":CLOSE15 und OPEN15,8,15,"XD?":CLOSE15. Oder wie kann ich mich vergewissern, dass diese Befehle ankommen und korrekt sind? Am eigentlichen Problem ändert sich dadurch nichts, leider.

    Zitat von Mac Bacon

    Wenn ein Tool damit nicht klarkommt, konvertiert man die Datei eben erst zurück.

    Meinst du: .P00 zu […] konvertieren? Womit würde das gehen?


    Zitat von Mac Bacon

    P00 ist nur ein zusätzlicher Header vor der Originaldatei […]

    Könnte ich den z.B. mit einem Hexeditor oder einem anderen Tool entfernen, und so an die eigentliche Datei kommen? Wie könnte ich den Header insgesamt identifizieren?

    In der Shell: tail -c +27 blah.P00 > blah
    Auch wenn das evtl. etwas obsessiv klingt, das würde ich mir gerne noch mit zip2disk zusammenscripten. Trotzdem wäre es mir lieber, .P00 komplett deaktivieren zu können. Das gelingt mir weder in JiffyDOS noch mit dem original Kernal, wie oben beschrieben.

    Zitat von Ballblazer

    Oder wie kann ich mich vergewissern, dass diese Befehle ankommen und korrekt sind?

    Nach dem Befehl ein weiteres @ ohne weitere Parameter eingeben. Im nackten CBM-BASIC 2.0 ist das Auslesen des Fehlerkanals leider etwas komplizierter- siehe Benutzerhandbuch zur 1541.

    Zitat von Ballblazer

    geht das nicht einfacher?

    Doch, arbeite mit .d64-Diskettenabbildern und hole Dateien nut bei Bedarf auf dem PC daraus hervor.

    Zitat von Ballblazer

    .P00 komplett deaktivieren zu können. Das gelingt mir weder in JiffyDOS noch mit dem original Kernal, wie oben beschrieben.

    Unseen hatte ja schon geschildert, daß das scheitert, sobald Zeichen im Dateinamen vorkommen, die nicht von FAT/DOS/Windows unterstützt werden. Es gab Versuche, solche Namen in extra Dateien zu speichern, aber das ist noch wesentlich beschwerlicher als ein voprgesetzter Header.
    Und mal ganz ehrlich- wenn Du Deine Dateien weder auf dem PC noch am 64er wiederfindest wäre das ja auch keine Lösung für Dein Problem?