Erzeugung von .P00 Files deaktivieren

  • 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?
  • Ballblazer schrieb:

    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.

    Ballblazer schrieb:

    Lässt sich das Schreiben von .P00 Files, die original keine .P00 Files waren, abstellen? Wenn ja, wie?
    Ja, das steht sogar im README.
    Yes, I'm the guy responsible for the ACME cross assembler
  • Ballblazer schrieb:

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

    Quellcode

    1. - XEnum Sets the "file extension mode". This setting controls if
    2. files on FAT are written with an x00 header and extension or not.
    3. Possible values for num are:
    4. 0: Never write x00 format files.
    5. 1: Write x00 format files for SEQ/USR/REL, but not for PRG
    6. 2: Always write x00 format files.
    7. 3: Use SEQ/USR/REL file extensions, no x00 header
    8. 4: Same as 3, but also for PRG
    9. If you set mode 3 or 4, extension hiding is automatically enabled.
    10. This setting can be saved in the EEPROM using XW, the default
    11. value is 1.
    12. For compatibility with existing programs that write D64 files,
    13. PRG files that have D64, D41, D71, D81, DNP or M2I as an extension
    14. will always be written without an x00 header and without
    15. any additional PRG file extension.
    Alles anzeigen

    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.

    Quellcode

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

    sd2iec Homepage
  • 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?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Ballblazer ()

  • Ballblazer schrieb:

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

    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.

    Quellcode

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

    sd2iec Homepage
  • Unseen schrieb:

    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.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Ballblazer ()

  • Mac Bacon schrieb:

    Wenn ein Tool damit nicht klarkommt, konvertiert man die Datei eben erst zurück.
    Meinst du: .P00 zu […] konvertieren? Womit würde das gehen?

    Mac Bacon schrieb:

    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.
  • Ballblazer schrieb:

    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.

    Ballblazer schrieb:

    geht das nicht einfacher?
    Doch, arbeite mit .d64-Diskettenabbildern und hole Dateien nut bei Bedarf auf dem PC daraus hervor.

    Ballblazer schrieb:

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