Erzeugung von .P00 Files deaktivieren

Quote from Ballblazer

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

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.

Quote from Ballblazer

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

Ja, das steht sogar im Please login to see this link..

Quote from Ballblazer

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

Ja, siehe Doku:

- XEnum    Sets the "file extension mode". This setting controls if
             files on FAT are written with an x00 header and extension or not.
             Possible values for num are:
               0: Never write x00 format files.
               1: Write x00 format files for SEQ/USR/REL, but not for PRG
               2: Always write x00 format files.
               3: Use SEQ/USR/REL file extensions, no x00 header
               4: Same as 3, but also for PRG
             If you set mode 3 or 4, extension hiding is automatically enabled.
             This setting can be saved in the EEPROM using XW, the default
             value is 1.


             For compatibility with existing programs that write D64 files,
             PRG files that have D64, D41, D71, D81, DNP or M2I as an extension
             will always be written without an x00 header and without
             any additional PRG file extension.

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.

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

Quote

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.

Quote from Ballblazer

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

Die ersten 26 Bytes sind P00-Header, alles danach ist Daten.

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

Quote from Ballblazer

geht das nicht einfacher?

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

Quote from 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?