Fehler im SD2IEC (Schreibschutz)

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

  • NEIN Danke.

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

    Sorry, Dir fehlt da der Kontext (siehe weiter oben, Software *MUSS* das nicht beachten, MP3 nutzt es zur Erkennung einer korrekten CMD-Partition/DiskImage, sowas macht "normale" Anwendersoftware ja wohl eher selten bis gar nicht).

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

    Danke, dann muss ich nicht lange suchen, evtl. erlaube ich dann beide Angaben... hängt von der 128er-Version ab die da ständig meckert "Zu weniger Speicher..."

  • Meine Firmware kann das per Befehl "EL:$" setzen. Siehe README. Dazu muss man im Root-Verzeichnis des Images sein. Sollte sich eigentlich wie ein Schreibschutz auswirken.

    Ja, manchmal. Habe es jetzt auch mit Wheels 128 probiert: Da kann ich trotz diesem "tollen" Schutz mit EL:$ Dateien von Disk löschen ......

    War irgendwie zu erwarten, moderne Geos Megapatch Bootdiskette

    Nichts modernes. BootTrans ist ein uraltes Geos-Programm (Auto_Exec) zum automatischen Kopieren von Dateien beim Booten. Das Programm speichert (ich glaube) 16 Listen mit Programm-Namen. Eine solche Liste kann dann beim Booten ausgewählt (oder für Automatik festgelegt) werden und die Dateien werden dann von Laufwerk auf RAM kopiert. Und wenn das Programm schon nicht mehr will, welche (wieviele) Programme haben dann noch Probleme mit diesem seltsamen EL:$ ...

    Meiner Meinung nach gehört das schnellstens entfernt! Mindestens aber sofort eine deutliche Warnung in der readme, EL:$ auf Geos-Disketten oder -Images NICHT zu benutzen! Gibt nur Probleme.

    Denn das Ganze wird ja noch größer: Ein solches DNP auf der 1541UII+ in MP3 zum Füllen einer Native-RAM funktioniert zwar (das Füllen), aber die RAM kann dann nicht mehr geöffnet werden. Toll ......

    Gruß

    Werner

  • Mindestens aber sofort eine deutliche Warnung in der readme, EL:$ auf Geos-Disketten oder -Images NICHT zu benutzen! Gibt nur Probleme.

    Auf den Teil können wir uns glaube ich einigen. Selbst falls darkvision den Typ zulässt, bleiben ja noch immer die anderen Geosvarianten.

    Muss demnächst sowieso die README aktualisieren, wir haben da ja noch den Tippfehler, den Du gefunden hast.

    ---
    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 das letzte von mir zum Thema:

    Besonders gut ist der EL:$ - Schutz nicht. Wie schon erwähnt, in Wheels keinerlei Wirkung, ich kann Löschen und Validate auf ein "geschütztes" DNP ausführen. Da ist der Schreibschutz auf das Image (PC-seitig) wirkungsvoller. Keine Change für Wheels.

    Kein C64/C128 hat z.B. ein Schreibschutzflag, welches am PC gesetzt wurde zu entfernen

    Siehe zz. B. CMD HD/CMD FD/IDE64. Da gibt es tatsächlich einen Befehl dafür.

    Wenn Du @L:Test meinst, muß ich Dich enttäuschen. Der manipuliert den CBM-File-Typ (z.B. $82 bzw. $c2 bei PRG). Das kann ich sogar in Geos wieder ändern (Datei - Info)...

    Gruß

    Werner

  • Macht "L" im Image auch. Außerhalb eines Images wird das eben durch das FAT Attribut repräsentiert, ist aber eigentlich das selbe.

    Besonders gut ist der EL:$ - Schutz nicht. Wie schon erwähnt, in Wheels keinerlei Wirkung, ich kann Löschen und Validate auf ein "geschütztes" DNP ausführen. Da ist der Schreibschutz auf das Image (PC-seitig) wirkungsvoller. Keine Change für Wheels.

    Klingt nach einem Bug in der Firmware... Nun gut, ich habe ja die verfügbaren Wheelsversionen. Probiere ich das demnächst also genauer aus.

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

  • Klingt nach einem Bug in der Firmware... Nun gut, ich habe ja die verfügbaren Wheelsversionen. Probiere ich das demnächst also genauer aus.

    Ich hab gerade ein D81 "geschützt" (HEX-Editor), in BASIC bekomme ich beim speichern auf einer 1581/Vice einen Fehler "73", unter GEOS kann ich aber Dateien ändern. Dachte zwar das würde nicht gehen, aber betrifft wohl nur Zugriffe über die Floppy-Befehle/Kernal-Routinen, die Job-Codes haben damit wohl kein Problem. Dann müsste sich so eine geschützte Diskette über Job-Codes auch wieder entsperren lassen... Ich werde mal die Kernal-Treiber testen, die müssten bei so einer Disk versagen...

    P.S. Annahme bestätigt:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Was mit den GEOS-Treibern geht, geht mit den Kernal-Treibern nicht mehr... Hier war es "Schreibschutz" bei einer Datei setzen... GeoDesk kann auf so einer Disk dann auch nicht mehr validieren (Fehler $73). Also funktioniert der Schutz, nur nicht wenn über GEOS-TurboDOS-Treiber Blöcke manipuliert werden...

  • Ich glaube, darkvision hat Recht. Wobei seine Feststellung für echte Floppies gilt.

    2 von 4 Möglichkeiten habe ich bereits durchgetestet, mit meiner SD2IEC Firmware wirkt der Schreibschutz bisher. Testszenatio:

    test.dnp auf dem SD2IEC. In dem ist Wheels installiert(*). Dann mit "EL:$" gelocked und Wheels gestartet. Versucht, den nicht benutzten EIngabetreiber (Maus) zu löschen, da ich für den Test der Einfachheit halber gerade mit dem Joystick auskommen wollte...

    (*) Bereits mit Wheels 64 4.2 und Wheels 64 4.4 getestet. Wheels 128 4.2 und Wheels 128 4.4 stehen noch aus.


    Somit kann ich auf dem SD2IEC zumindest bisher kein Problem finden.

    Nachtrag: Wheels 128 4.4 und SD2IEC beachten zusammen auch den "EL:$" Schreibschutz.

    Nachtrag 2: Wobei eine echte 1541 unter Kernal I/O das Byte auch nur beim Initialize (der beim Diskettenwechsel auch implizit passiert) auswerten. Wenn man also per "U1" und "U2" das Byte setzt, so wirkt es sich nicht sofort aus.

    Nachtrag 3: Auf einer 1581 (nicht SD2IEC!) ist dieser Schreibschutz in der Tat unter Geos nicht aktiv. Auch dann nicht, wenn die Diskette vor dem Start von Geos bereits von CBM Dos initialisiert worden ist und seitdem im Laufwerk verblieben 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.

    3 Mal editiert, zuletzt von markusC64 (19. Oktober 2024 um 11:07)

  • Wobei seine Feststellung für echte Floppies gilt.

    Kannst Du Deine Tests um die CMD-FD erweitern? Ich hab damit ebenfalls verschiedene Ergebnisse erzielt.

    Ansonsten funktioniert der neue MP3-Build jetzt auch wieder mit dem Directory-Schutz auf DNP... die Images lassen sich jetzt wieder öffnen/wechseln. Die alte Version hat mit DTopDesk den Fehler $34 produziert... das war "No directory".

    Die Prüfung wurde ergänzt weil TopDesk beim wechsel des Laufwerks erst das Ziel-Verzeichnis setzt, und erst danach die Partition wechselt. Das muss einen Fehler melden, da bei CMD-Laufwerken dann ein Verzeichnis geöffnet wird, das auf der aktuellen Partition nicht existiert. Der Verzeichnis-Test hatte halt nicht auf dem Schirm, das der Schreibschutz auch bei DNP funktionieren könnte (tut er hier mit der alten Firmware auch nicht).

    Vice64 und C64 hab ich durch, Vice128 fehlt noch.

  • Kannst Du Deine Tests um die CMD-FD erweitern?

    Die habe ich leider "nur" in VICE... Und da es in diesem Thread eigentlich um den SD2IEC geht, habe ich mich auf Ikmageformate beschränkt, die der SD2IEC beherrscht.

    Was nicht mehr SD2IEC ist, sollte vielleicht in den GEOS-Thread...

    Aber ja, das Ergebnis interessiert mich auch... werde ich demnächst mal testen.

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