Fehler im SD2IEC (Schreibschutz)

Es gibt 68 Antworten in diesem Thema, welches 4.557 mal aufgerufen wurde. Der letzte Beitrag (20. Oktober 2024 um 11:02) ist von markusC64.

  • Was macht die Firmware wieder anders?! Wird sich zeigen, siehe mein Edit. Ich mache das demnächst doch... Zumindest bis zu der Stelle, wo man Floppies erkennen kann, ist das eigentlich zuverlässig. Danach kann es natürlich je nach erkannter Floppy anders sein.

    Off topic: Am Ende landet man dann bei einer Regressionsanalyse - ob der Teil von thierer, auf den meine Firmware aufbaut, jenes abweichende Verhalten auch schon hat oder nicht. Das gibt nämlich einen Hinweis darauf, wo man zu suchen hat.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • achso, ganz vergessen:

    Meine Firmware kann das per Befehl "EL:$" setzen.

    Willst Du Geos-User nerven ;) ? Das setzt das Schreibschutz-Flag in jeder Geos-Datei. Das führt nur dazu, daß z.B. bei GeoWrite beim Öffnen eines so "geschützten" Dokuments jedes mal nachfragt, ob das Dokument geöffnet werden soll ("Ignorieren") oder nicht ....

  • Kehrtwende - extra die Firmware zu nitzen ist zu umständlich. Ich bin im Jiffydos 6.01 Quelltext fündig geworden:

    Dabei werden die folgenden Befehle an die Floppy geschickt:

    Und weil es so schön ist und ich glaube nirgends recht dokumentiert ist, hier noch die Liste der Befehle aus dem Quelltext, die Jiffydos selbst auswertet und die deswegen nicht oder nur abgeändert zur Floppy gehen:

    Nun ja, jetzt wissen wir, was im Hintergrund wirklich passiert.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Willst Du Geos-User nerven ;) ? Das setzt das Schreibschutz-Flag in jeder Geos-Datei. Das führt nur dazu, daß z.B. bei GeoWrite beim Öffnen eines so "geschützten" Dokuments jedes mal nachfragt, ob das Dokument geöffnet werden soll ("Ignorieren") oder nicht ....

    Da muss ich um Aufklärung bitten. Das macht inhaltlich keinen rechten Sinnzusammenhang. Es wird im BAM Block bzw. bei DNP im Track 1 Sektor 1 das Byte 2 (also das dritte Byte) geändert und mehr nicht. Und selbst das sieht GEOS nach meinem letzten Patch von gestern nicht, weil das gegenüber dem Speeder von GEOS verborgen wird. Statt dessen verhindert die SD2IEC Firmware einfach jeden Schreibzugriff auf das Dxx Image. Wirklich jeden mit einer Ausnahme: Der entsprechende Unlock Befehl EU:$.

    Es ist also gar nicht möglich, dass sich Attrinute von Geos-Dateien ändern. Was aber möglich ist wäre, dass Geos den schreibgeschützten Datenträger erkennt und selbst das Flag anzeigt, obwohl es nicht da ist.

    Nun ja, den Befehl muss ja keiner benutzen. :smile:

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Und im übrigen behauptet das SD2IEC README (weder das von Ingo noch das von mir), dass man die Befehle per Wedge ohen Anführungszeichen hinschicken kann. Sondern es geht schlicht davon aus, dass man weiß, wie man die Befehle dahin schicken kann, so dass die auch so ankommen wie angegeben.

    Aber hast natürlich Recht, wenn Infos Firmware Jiffydos seine Ersatz "L"-Implementierung versteht und andere nicht, dann muss ich schauen, woran das liegen mag.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Ich habe jetzt die Firmware von Ingo auf meinem zweiten SD2IEC aufgespielt, damit tut der @L-Jiffydosbefehl auch nichts...

    Habe jetzt wieder die letzte Firmware von sd2iec.de aufgespielt (Anfang 2023). @L:DATEINAME funktioniert hier auch auf 8 (SD2IEC). Mit der Firmware von Euch sind die Anführungsstriche Pflicht ( @"L:dateiname" )

    das kann ich daher absolut nicht nachvollziehen.

    Edit: Natürlich kann man den L-Befehl als unnütz ansehen. Aber es ist der einzige, den ein C64 Programm absetzen kann und sowohl auf CMD, auf IDE64 und auf dem SD2IEC Erfolg haben. Das ist Nutzen genug. Zum per Hand absetzen kann man natürlich auf den EL / EU ausweichen, den man von S-Jiffydos vielleicht sogar kennt.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von markusC64 (14. Oktober 2024 um 20:02)

  • Da muss ich um Aufklärung bitten. Das macht inhaltlich keinen rechten Sinnzusammenhang. Es wird im BAM Block bzw. bei DNP im Track 1 Sektor 1 das Byte 2 (also das dritte Byte) geändert und mehr nicht.

    Zitat von der Readme

    - L/EL/EU/XL/XU:

    Sets resp. clears read only flag

    L:foo toggles flag on a single file

    EL:foo sets flag on files, EL:$ locks whole image

    EU:foo clears flag on files, EU:$ unlocks whole image

    Wenn EL:$ "nur" das 3. Byte in Track 1 Sektor1 ändert, ist das zumindest für mich sehr sehr seltsam. Da steht normalerweise "1H" als Format-Kennung für DNP

    (siehe Bitte melde dich an, um diesen Link zu sehen. unter der Überschrift "Native Partitions (D2M and DNP images)" . Welche andere Software beachtet das und weiß davon, wenn da was geändert wird/ist ???? Probleme vorprogrammiert!!!!

    Alles irgendwie verwirrend und nicht nachvollziehbar. Nirgends steht etwas darüber. Deshalb: Für mich gilt ab sofort: ich bin hier raus! Ich bleibe bei der sd2iec.de - Firmware und kann/muß/werde mit den $26-Bug eben leben (können), bis er dort behoben wird...

    Werner

  • Gegenfrage: Welche Software schaut sich überhaupt Partitionen auf Sektorebene an? Und lässt nicht die Software aus dem ROM in der Floppy die Arbeit machen?

    Ja, Geos natürlich. Aber darüber hinaus?

    Zugegeben, 1,5 Jahre später sich zu erinnern ist nicht das leichteste, aber ich meine, ich hätte die Änderung exemplarisch mit 1541, 1571, 1581 und FD2k (wegen DNP) unter Vice ausprobiert. Und jeweils gefunden, dass das ROM das macht, was man erwartet, nämlich den für die 1541 eigentlich sehr bekannten Schreibschutztrick auch bei den anderen Floppies umsetzt.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Welche andere Software beachtet das und weiß davon, wenn da was geändert wird/ist ???? Probleme vorprogrammiert!!!!

    Wenn es das ist was ich denke muss das keine Software beachten, die bekommt beim Schreibzugriff nur einen DOS-Fehler (73,DOS MISMATCH?) mitgeteilt. Ich meine aber das funktioniert auch unter GEOS, da ich in GeoDesk so einen Fehler im Klartext ausgeben kann...

  • Es war nur eine Frage zum Verständnis und nicht zur Lösung.

    Beide basieren ja auf dem ursprünglich gleichen Sourcecode; und auch das PetSD+ hat ja einen IEC Bus. Ich würde bei mir das PetSD am 128er verwenden, wenn ich denn mal GEOS aufsetze.

    Bislang habe ich verstanden, dass die Probleme vor allem auf den Jiffy-DOS Erweiterungen basieren. Und das gibt es beim 128er ja auch.

  • Wenn es das ist was ich denke muss das keine Software beachten, die bekommt beim Schreibzugriff nur einen DOS-Fehler (73,DOS MISMATCH?) mitgeteilt.

    Volltreffer - Genau das ist es. Wobei ich glaube, dass das SD2IEC im Gegensatz zur Floppy den Schreibschutzfehler meldet, weil darauf eine Software eher ausgelegt ist als auf den 73er Fehler.

    Allerdings will die Kombination DNP, Geos und das Flag nicht zusammen. Ich habe hier auf Festplatte noch eine ältere (d. h. nicht aktuelle) "-D3_OpenDisk.s" von Dir, als Du die Quelletxte noch als PC Textdatei exportiert hast:

    (einfach mal nach "#$48" gesucht... und das sieht verdächttig nach einer Prüfung aus, ob es eine valide Partition ist)

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Frage: Hat das PetSD die gleichen Probleme? Dort gibt es ja IMHO kein JiffyDOS.

    Hier haben wir ein größeres Problem. Das PetSD hat keinen seriellen IEC Bus. Sondern nur einen Parallelen für die Pet Serie. Damit ist der Geos Speeder grundsätzlich nicht lauffähig.

    Falls Du jedoch eigentlich den PetSD+ meinst, zu dem gibt es das zu sagen: Bitte melde dich an, um diesen Link zu sehen. - somit läuft auf den auch nicht der Geos Speeder. Man könnte also allerhöchstens die Kernal-I/O-Version von Megapatch 3 versuchen. Jedoch ebenfalls nicht das normale Geos. PS: Jiffydos läuft auf dem PetSD+.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von markusC64 (15. Oktober 2024 um 17:54)

  • Allerdings will die Kombination DNP, Geos und das Flag nicht zusammen. Ich habe hier auf Festplatte noch eine ältere (d. h. nicht aktuelle) "-D3_OpenDisk.s" von Dir, als Du die Quelletxte noch als PC Textdatei exportiert hast:

    Ich wollte sowieso die Tage noch ein Update zu MP3 rausgeben... wenn Du mir sagst welche Bytes das bei welchem Format in welchem Block/Sektor sind, kann ich mir das nochmal anschauen.

    Und ja, das ist eine Formatprüfung, ansonsten könnte ja beim DNP-Treiber auch ein D81 gemounted sein. Bei den CMDs kann ich ja wenigstens noch nach einer gültigen Partition suchen, beim SD2IEC muss da ein Fehler gemeldet werden. Aktuell kommt da "No Directory".

    Und Du hast da genau den Beitrag gefunden, weswegen ich damals die Kernal-Treiber entwickelt habe. Die hab ich auch mit dem SD2IEC getestet, da wollte ich heute nochmal testen ob dieser Schreibschutz-Bug da mit dem neuen DTopDesk besser funktioniert. Da kann ich mir dann auch ein paar "Protected Images" erstellen...

  • Frage: Hat das PetSD die gleichen Probleme? Dort gibt es ja IMHO kein JiffyDOS.

    Hier haben wir ein größeres Problem. Das PetSD hat einen seriellen IEC Bus. Sondern nur einen Parallelen für die Pet Serie. Damit ist der Geos Speeder grundsätzlich nicht lauffähig.

    Falls Du jedoch eigentlich den PetSD+ meinst, zu dem gibt es das zu sagen: Bitte melde dich an, um diesen Link zu sehen. - somit läuft auf den auch nicht der Geos Speeder. Man könnte also allerhöchstens die Kernal-I/O-Version von Megapatch 3 versuchen. Jedoch ebenfalls nicht das normale Geos. PS: Jiffydos läuft auf dem PetSD+.

    Ja, sorry, ich meinte das PetDS+. Meines hat hinten beide Anschlusse: 6pol DIN und 24pol IEEE. Aber schön zu wissen, dass im PetSD+ für den seriellen Bus auch ein Jiffy-Dos Gegenstück enthalten ist.

    Mein SX64 hat aber auch einen Kernal-basierten IEEE Bus: Dafür wäre ja kein Turbo-Speeder notwendig. Also lediglich ein "native" Disk Driver.

  • Wenn es das ist was ich denke muss das keine Software beachten,

    So, nachdem ich durch ausprobieren herausgefunden habe, was da auf DNP verändert wird mit dem Befehl "EL:$" habe ich 2 meiner Boot-DNPs (64 und 128) so manipuliert.

    Sie booten, bis BootTrans gestartet wird. Dann sehe ich eine leere Auswahl von Listen von zu kopierenden Dateien :( . Nach "Weiter" startet irgendwann TD (bei 128 v. Dez. 2021 bei 64 vom 12.10.2024) und die Probleme gehe weiter:

    öffnen von Lfw. A: (das Boot-Lfw.) wird wegen Fehler $34 abgelehnt !

    NEIN Danke.

    Wer weiß, wieviele Programme da noch betroffen sind....

    Gruß

    Werner

    Nachtrag: Natürlich Gegenprobe: Änderung wieder rückgängig gemacht (nur MP3-64) und DNP funktioniert wie eh und je vorher ....

  • wenn Du mir sagst welche Bytes das bei welchem Format in welchem Block/Sektor sind, kann ich mir das nochmal anschauen.

    Der Einfachheit halber sind alle Zahlenangaben in Hexadezimal ohne ausdrückliche Kennzeichnung

    DxxOffset ImageUngeschütztGeschützt
    D64 / D7116502 ( Trk dez 18 Sec 0 )413C
    D8161802 ( Trk dez 40 Sec 0 )443D
    DNP102 (Trk 1 Sec 1 )483E


    Jeder Hexeditor sollte den Patch mit jedem Image hinbekommen.

    Nachtrag: Bitte beachte, dass die Standard SD2IEC Firmware das Byte incht auswertet und nicht als Schreibschutz interpretiert. Dafür kommt es jedoch bei Geos an.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

    2 Mal editiert, zuletzt von markusC64 (15. Oktober 2024 um 18:17)

  • NEIN Danke.

    Wer weiß, wieviele Programme da noch betroffen sind....

    War irgendwie zu erwarten, moderne Geos Megapatch Bootdisketten sind einfach nicht mehr auf Readonly ausgelegt. Aber zumindest können die dann mangels Schreibmöglichkeit auch nichts kaputtmachen.

    Edit: Müssen die aber auch nicht, glaube ich. Nachdem die im Gegensatz zu Geos 2.0 keinen Kopierschutz mehr haben, kann man die ja einfach sichern... Wobei der Geos 2.0 Kopierschutz seit dem Burstnibbler auch nicht wirksam war, aber das ist eine andere Geschichte.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.