Fehler im SD2IEC (Schreibschutz)

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

  • Okay. Meine vorletzte Firmware liefert (ich schreibe hier mal alles in eine Zeile, damit es übersichtlicher wird):

    0, 38, 38, 38, 0.

    Meine letzte Build liefert

    0, 38, 0, 0, 0

    Gerade noch mit 1541 vergleichen, aber ein Gefühl sagt mir, das sollte passen.

    Edit: Yupp, 1541 liefert das selbe wie der letzte Versuch. Bitte melde dich an, um diesen Link zu sehen.

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

  • Noch etwas anderes: ich habe gesehen daß die Anleitung für die Firmware auf der Web-Seite steht und in den Source-Code-Downloads enthalten ist. Wäre es nicht sinnvoll die aktuelle readme auch in den Release-ZIPs mit aufzunehmen?

    Gute Idee. Im Release ZIP. In der automatischen Build für jeden Commit denke ich, da spare ich mir das weiterhin.

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

  • Gerade noch mit 1541 vergleichen, aber ein Gefühl sagt mir, das sollte passen.

    Da paßt aber leider immer noch etwas nicht. Testprogramm liefert das richtige, aber:

    Ich kopiere in MP3-64 mit DT64-R02 eine Datei auf ein schreibgeschütztes DNP. Die rote LED blinkt und blinkt. Ich bekomme 2x die Schreibschutz-Fehlermeldung und dann blinkt die Error-LED weiter. Und dann passiert etwas seltsames: Es wird auf das SD2IEC zugegriffen und nach einigen Sekunden wird die 1. verfügbare Partition im aktuellen Verzeichnis der SD2IEC (bei mir Boot MP3-128) geöffnet. So haben wir aber nicht gewettet :wink: .

    Beim Validate passiert genau das was vorher auch passiert ist: 2x Fehlermeldung (Schreibschutz) , dann wird ein leeres Fenster angezeigt und die rote LED blinkt und blinkt und blinkt ....

    Selbst wenn ich das DNP neu mounte: Fenster leer und Blinken ohne Ende. Erst ein anderes DNP (ohne Schreibschutz) beendet den Spuk.

    Mache jetzt mal den Gegentest auf MP3-128. Da ist en andere TopDesk drauf ....

    Gruß

    Werner

    Nachtrag: Unter MP3-128 die gleiche Vorgehensweise aber anderes Ergebnis (liegts am Workaround den es im DT64 gibt???):

    bei beiden (Kopieren + Validieren) erscheint 2x der Fehler 26, dann schließt sich das Fenster und die rote LED blinkt fröhlich weiter. Auf die Diskette besteht kein Zugriff mehr, es kommt sofort Fehler $26. Erst wenn ich das Image neu Mounte (geoDirSelect, bei der ersten Anzeige sind keine Dateien zu sehen) kann ich wieder auf das Image zugreifen.

    bei Delete einer Datei wird 2x das Fenster neu aufgebaut und dann ist Ruhe, spricht das klappt (natürlich wurde nichts gelöscht ;) ), die LED blinkt nicht mehr....

  • So ein Chrüsimüsi... was ähnliches kommt mir bekannt vor: Bei C64 OS 1.0 (also ohne irgendwelche Updates) hatte ich den Fall, dass innerhalb eines DNP Images nicht gestartet werden konnte, irgendwie verließ der immer das Image. Ohne erkennbaren Grund.

    Es gibt anscheinend da ein Bug, der das Image zu verlassen vermag.

    Was das mir jetzt sagen will, weiß ich nicht so genau - denke aber daraus zu lesen, dass es ein alter Bug ist. Den Geos jetzt nur triggern kann, weil wir nicht alles mit einem vermeintlichen Fehler abbrechen.

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

  • Eine kleine Frage, die uns helfen könnte, das einzugrenzen: Was passiert, wenn Du den Schreibschutz auf die Dxx Datei ersetzt durch ein anderes DOS Versionsflag?

    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.

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

  • Danke für den Hinweis. Okay, die Topdesk Version macht also einen größeren Unterschied.

    Ich habe Dir mehr oder weniger gleichzeitig auch noch eine Frage gestellt.

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

  • gleichzeitig auch noch eine Frage gestellt.

    Ja, und jetzt werde ich langsam sauer.

    1. Kein C64/C128 hat z.B. ein Schreibschutzflag, welches am PC gesetzt wurde zu entfernen (siehe Diskussion zur 1541UII+ vor einigen Tagen). PUNKT!

    So ein Flag hat eine Bedeutung und wenn jeder daran rumpfuschen kann, was hat ein Schreibschutz dann überhaupt noch für eine Bedeutung?

    Man hat den aus einem Grund gesetzt (z.B. Backup einer Boot-Disk zur Archivierung, um im Notfall darauf zurückzugreifen). Wenn man dann "versehentlich" den Schreibschutz entfernt und drin rum fuhrwerkt, dann ist das Geschrei hinterher groß .......

    2. Was bedeutet das L, EL, EU, XL, XU ... überhaupt genau?????

    3. Was soll der Sch...ß?

    4. Das Entfernen des Schreibschutzes (am PC) und das Setzen von "EL:$" im Hauptverzeichnis des DNP (es hat sowieso keine UVs oder TD-Ordner) am C128 führt dazu, daß ich das Image überhaupt nicht mehr in MP3-128 und MP3-64 öffnen kann. DANKE!!! Es kommt sofort beim Öffnen "Diskettenfehler $34", was lt. FD- und 1571-HB "Syntax Error Dateiname fehlt" bedeutet. Seltsame Meldung beim Öffnen einer Disk...

    Gruß

    Werner

  • Die rote LED blinkt und blinkt.

    Kleine Info am Rande: Das blinken kommt vom SD2IEC und würde normalerweise gelöscht wenn man den Fehlerkanal ausliest. Oder vermutlich wieder auf das Laufwerk zugreift. GEOS löscht den Fehlerkanal aber nicht, daher bleibt das blinken nach so einer Fehleraktion erstmal aktiv. Ist das bei einer 1541 nicht auch so, wenn ich da unter GEOS ohne Disk das Laufwerk öffne? Blinkt da nicht auch die Fehler-LED? Mit MP364/KernalMode dürfte da nichts mehr blinken.

    Was bei DT64 anders ist als bei TD ist, das beim öffnen eines Laufwerks, wenn kein Image aktiv ist, der ImageBrowser gestartet wird. Hier passiert das mit der fehlerhaften Firmware aber auch wenn der Fehler $20 auftrat, da dann der Fehler hartnäckig im SD2IEC verbleibt...

    Und dann passiert etwas seltsames: Es wird auf das SD2IEC zugegriffen und nach einigen Sekunden wird die 1. verfügbare Partition im aktuellen Verzeichnis der SD2IEC (bei mir Boot MP3-128) geöffnet. So haben wir aber nicht gewettet :wink: .

    Vorsicht! TopDesk (und DTopDesk) hat ein grundsätzliches Problem wenn eine Fenster-Aktion ausgeführt und man dann den Mauszeiger bewegt. In Deinem Fall könnte der Mauszeiger nach dem Bildaufbau zufällig auf dem "DiskImage wechseln" Gadget gewesen sein und DTopDesk will dann die Partition wechseln. Auf Grund eines Laufwerksfehlers kann es durchaus sein das dann beim beenden das erste gefundene DiskImage aktiviert wird (wie wenn man die Image-Auswahl über ABBRUCH beendet...)

  • 1. Kein C64/C128 hat z.B. ein Schreibschutzflag, welches am PC gesetzt wurde zu entfernen (siehe Diskussion zur 1541UII+ vor einigen Tagen). PUNKT!

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

    2. Was bedeutet das L, EL, EU, XL, XU ... überhaupt genau?????

    S-Jiffydos hat EL und EU, in der Tat auch imt "$". "L" ist glaube ich die Variante vom IDE64, da müsste ich nachschauen. Für XL/XU weiß ich incht mehr, bei welchen Speeder ich das gesehen habe. Alles vom klassischer 1541 mit Speeder bzw. IDE64 inspiriert.

    Und andere erwarten, dass sich außerhalb vom Image alles wie ein CMD bzw. IDE64 verhält. Man also inbs. Befehle, um den Schreibschutz zu steuern.

    EL und EU sind Lock und Unlock. Ein anderer Speeder nennt das halt XL und XU. Und CMD hat das als Toggle implementiert und kommt deswegen mit einem Befehl aus, nämlich "L".


    Aus Sicht des SD2IEC ist ein Dxx auch nur eine Datei, also kann man die damit dann auch schreibschützen und den Schreibschutz aufheben.

    4. Das Entfernen des Schreibschutzes (am PC) und das Setzen von "EL:$" im Hauptverzeichnis des DNP (es hat sowieso keine UVs oder TD-Ordner) am C128 führt dazu, daß ich das Image überhaupt nicht mehr in MP3-128 und MP3-64 öffnen kann. DANKE!!! Es kommt sofort beim Öffnen "Diskettenfehler $34", was lt. FD- und 1571-HB "Syntax Error Dateiname fehlt" bedeutet. Seltsame Meldung beim Öffnen einer Disk...

    "EU:$" setzt den Typ wieder zurück... aber den Zustand muss ich mir nochmal ansehen. Mit einer D64 hat es heute Nachmittag bei mir geklappt - ansonsten hätte ich das auch nicht geschrieben.

    Wenn man dann "versehentlich" den Schreibschutz entfernt und drin rum fuhrwerkt, dann ist das Geschrei hinterher groß .......

    Die Diskussion war per UI bei der Ultimate. Das ist was anderes als manuell einen Befehl abschicken zu müssen. Zumal in der Nähe von "L" gar nichts verdächtiges auf der Tastatur liegt, was man gemeint haben könnte.


    Aber so ist es immer, verschiedene Leute wollen verschiedenes. Wollen wir am Ende da landen, dass man deswegen Features abschaltbar macht und keiner sich mehr auf das Vorhandensein vom Features verlassen kann, obwohl die Firmware stimmt?

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

  • Hier passiert das mit der fehlerhaften Firmware aber auch wenn der Fehler $20 auftrat, da dann der Fehler hartnäckig im SD2IEC verbleibt...

    Richtig, deswegen musste ich im Speeder auch jede Menge Rücksetzaktionen einbauen: Bitte melde dich an, um diesen Link zu sehen.

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

  • Kleine Info am Rande: Das blinken kommt vom SD2IEC und würde normalerweise gelöscht wenn man den Fehlerkanal ausliest. Oder vermutlich wieder auf das Laufwerk zugreift. GEOS löscht den Fehlerkanal aber nicht, daher bleibt das blinken nach so einer Fehleraktion erstmal aktiv.

    Ich bin jetzt zurück auf die Firmware von Januar 2023 (sd2iec.de; atendead0-36) .

    MP3-64 mit TD R02 (12.10.2024) und MP3-128 mit TD128 12/2021 Das blinken hört nach 2x neuaufgebautem Fenster auf (ja, es kommt die falsche Meldung, aber ...). Könnte es sein daß die Firmware das macht??? Mit der von heute Mittag/Nachmittag blinkt es ohne Ende....

    Kann es ja bei schwerwiegenden Fehlern auch (ist, wie ich das verstehe eh fake), aber eben nur nicht bei $26, weil das eigentlich kein schwerwiegender Fehler ist.

    Aber für heute reichts, eigentlich wollte ich was ganz anderes machen .......

    Gruß

    Werner

  • MP3-64 mit TD R02 (12.10.2024) und MP3-128 mit TD128 12/2021 Das blinken hört nach 2x neuaufgebautem Fenster auf (ja, es kommt die falsche Meldung, aber ...). Könnte es sein daß die Firmware das macht??? Mit der von heute Mittag/Nachmittag blinkt es ohne Ende....

    Das das Blinken aufhört? Nein, da finden vermutlich Disk-Zugriffe statt, die dann dazu führen das das blinken aufhört. Was Du machen kannst: Wenn das SD2IEC blinkt, einfach mal "GEOS beenden" auswählen und über JiffyDOS den Fehler-Kanal des SD2IEC auslesen...

  • Dann zunächst erstmal zur Readme, die zur Firmware gehört ;) :

    Lustig finde ich den Befehl A:H=foo.

    Nee, er macht genau das was beschrieben wird. Die Datei foo wird auf hidden gesetzt. Ich hoffe nur, ihr habt Euch den Dateinamen gemerkt, die Datei ist fortan auf sd2iec nicht mehr sichtbar. Wiederherstellen (wenn man den Namen nicht mehr genau weiß) am PC...

    Zitat

    L/EL/EU/XL/XU:

    Sets resp. clears reqad only flag

    ich habe länger gebraucht, das zu verstehen :wink: . Tippfehler, das soll wohl "Sets resp. clears read only flag" heißen.

    Zitat

    L:foo toggles flag on a single file

    Was macht eigentlich dieser Befehl (außer Ärger)?

    Ich habe die deutsche JiffyDos- und FD-4000-Anleitung diesbezüglich gelesen. Aber hier bei mir passiert folgendes:

    Im Hauptverzeichnis der SD-Karte:

    @L:PUZIP64.PRG (RETURN) ; @ (Return) Ergebnis: 00, OK,00,00

    es scheint also funktioniert zu haben, aber im neu geladenen Directory kein "<" bei PUZIP.PRG sichtbar

    das Gleiche auf ein DNP (ohne irgendeinen Schutz)

    Gleiches Ergebnis

    Dann ein DNP geöffnet und darin @L:Name auf ein C64-Programm

    Fehler blinkt, @ sagt: 98,UNKNOWN DRIVECODE,44,235

    Also was macht @L: ?????

    Wäre sowieso eigentlich unnütz, da

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

    das Gleiche macht.

    Gruß

    Werner

  • Gestern Abend gab es noch einen neuen Commit dazu (mit neuer Version). Hier meine Testergebnisse:

    Datei löschen auf DNP mit Schreibschutz in MP3:

    128: einmal Fehlermeldung $26, 2x Fenster-Neuaufgebau, Blinken weg alles geht normal weiter

    64: 2xFehlermeldung mit Fenster-Neuaufbau, Blinken weg, alles geht normal weiter

    Diskette Validieren auf DNP mit Schreibschutz in MP3:

    128: 1x Fehlermeldung $26, Fenster zu, kein aktives Lfw., 1x Fehlermeldung $26, blinken und kein aktives Lfw., auf B:RAM geoDirSelect gestartet, blinken weg, sehe leere DB vom DNP, (ROOT) macht nichts (db wird neu aufgebaut, (ZURÜCK) und Neuöffnen vom DNP geht dann

    64: Fehlermeldung $26 mit blinken, Fenster-Neuaufbau, Fehlermeldung $26 mit blinken, 2xFenster-Neuaufbau (1x kurz und dann sofort leeres aktives Fenster), blinken, geoDirSelect von B: gestartet, Blinken weg, auf A: (DNP) gewechselt, befinde mich im Hauptverzeichnis, das schreibgeschützte DNP erneut geöffnet, blinkt wieder mit leerer DB, (ROOT) oder (ZURÜCK) machen dem Spuk ein Ende, wenn ich im Hauptverzeichnis ein anderes DNP öffne ist auch Ruhe.

    Interpretieren dürfen das andere :wink: .

    Gruß

    Werner

    Vergessen: bei MP3-64 Validate nach dem leeren Fenster MP3 beendet und Fehlerkanal abgefragt: $26 Write Protect Error 6, 0. Beim 128 geht das nicht. Beim Verlassen erfolgt Reset, so daß Fehlerkanal die Firmware-Version des SD2IEC anzeigt.

  • 64: Fehlermeldung $26 mit blinken, Fenster-Neuaufbau, Fehlermeldung $26 mit blinken,

    Dann funktioniert die Firmware noch nicht korrekt. Ich hab das eben auch mit einer FD81 versucht nachzustellen: Da kommt nach der ersten Meldung kein weiterer Fehler und die Dateien werden angezeigt und da blinkt auch nichts.

    Wenn nach der ersten Fehlermeldung und dem Neuaufbau des Fensters eine zweite Fehlermeldung kommt, dann ist das Problem mit dem hartnäckigen Fehler noch nicht beseitigt.

    Mir stellt sich die Frage ob die Firmware bzw. der GEOSLoader bei einem erneuten Job nicht vorher den Status der Laufwerks-LED "löschen" müsste? Ich hab eben ein Testprogramm geschrieben das bei der FD nur die BAM speichert und dann direkt den PANIC auslößt... da blinkt nichts. Gleiches Programm auf meinem SD2IEC (alte Firmware): LED blinkt.

    Wäre es möglich in die weiter vorne aufgeführten Fehlerroutine, die den Fehlercode an GEOS sendet, am Ende den LED-Status zu löschen? Nicht das der blinkende LED-Status dafür sorgt das der nächste GEOS-Job durch die blinkende LED wieder einen Fehler gemeldet bekommt.

  • Also was macht @L: ?????

    Ich benutze ja S-Jiffydos, da hat de Befehl das getan, was er soll. Mit Jiffydos werde ich das gleich mal testen - es kann aber sein, dass man damit den Befehl ebenfalls in Anführungszeichen setzen muss (bei S-Jiffy muss man das immer).

    Ich hoffe nur, ihr habt Euch den Dateinamen gemerkt, die Datei ist fortan auf sd2iec nicht mehr sichtbar. Wiederherstellen (wenn man den Namen nicht mehr genau weiß) am PC...

    Man kann die sich dennoch anzeigen lassen

    LOAD"$*=H",9

    dann sind die sichtbar. Übrigens IDE64 kompatibel.

    Edit: Innerhalb eines Dxx Images gibt es noch eine Möglichkeit: mittels »@"XH-"« die Unterstützung für Hidden innerhalb von Images einfach ausschalten.

    Also was macht @L: ?????


    Wäre sowieso eigentlich unnütz, da


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

    Stimmt, aber da CMD Software nun mal "L" absetzen wird...

    Zu "@L:dateiname", da grätscht Jiffydos rein und macht irgendwas anderes, es übermittelt zumindest nicht den Befehl an das Gerät. Da muss man auch unter Jiffydos explizit »@"L:dateiname"« schreiben, dann geht es. Habe extra nach Jiffydos gewechselt, um das für Dich auszuprobieren. Nun ja, dass Jifyfdos bei der Kurzschreibweise mal was nicht unverändert zur Floppy überträgt, das ist nun mal so, da kann das SD2IEC nichts für.

    So nebenbei: IDE64 benutzt "EH" für das Hidden toggeln. Leider ändert S-Jiffydos damit den Header. Die Doppelbenutzung konnte ich nur umgehen, dass man bei EH den Pfad angeben muss, wenn man CMD Bedeutung meint. Ein facher Slash für das aktuelle Verzeichnis reicht da jedoch.

    Der A-Befehl ist am ATTRIB Befehl von MS-DOS und somit von windows angelehnt, aber mit vereinfachter Syntax. Man gibt einfach die neuen Attribute an. Also »A:R=FOO", damit die Datei FOO nur das Read only Attribut hat, »A:RH=FOO« für Read Only + Hidden usw. Auch »A:=FOO" klappt...


    Dann funktioniert die Firmware noch nicht korrekt.

    Da kannst Du Recht haben. Ich habe das Zurücksetzen nur bei Block lesen und Schreiben eingebaut. Weil ich nur da absolut sicher bin, dass man im Timing die Zeit dafür hat. Wahrscheinlich müsste das noch an anderen Stellen rein. Vielleicht, nachdem der Fehlerstatus gesendet worden ist?!

    Gestern Abend gab es noch einen neuen Commit dazu (mit neuer Version).

    Ja, der Commit ist nicht der schönste Workaround für EL:$, dass es GEOS wieder tut. Anderseits ist jedoch das DOS Version Flag das nächste an Schreibschutz, was sich einigermaßen wie eine echte Disk verhält. Die kannst Du weitergeben, verleihen etc. ohne dass sich der Schreibschutz von selbst" ändert. Mach das mal bei einem Dxx - sagen wir mal per E-Mail. Da passiert es schnell, dass das Attribut sich selbst entfernt.

    ---
    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 (14. Oktober 2024 um 19:11) aus folgendem Grund: Ist natürlich XH-, nicht EH-, welches Hidenunterstützung im Image abschaltet.

  • dass Jifyfdos bei der Kurzschreibweise mal was nicht unverändert zur Floppy überträgt, das ist nun mal so, da kann das SD2IEC nichts für.

    Das versteheich nicht. Ich habe hier einen C128DCR (JiffyDOS) mit interner 1571 als 10 (JiffyDOS), 11 ist das 1541UII+ (JiffyDOS), 8 ist das SD2IEC. Wo wechselt man am SD2IEC das JiffyDOS? Denn:

    Der Befehl @L:dateiname funktioniert so wie im Handbuch auf 10 und 11 problemlos. Nur auf 8 heißt er plötzlich @"L:dateiname" . Falsch in der Firmware???

    Das JiffyDOS ist übrigens komplett gekauft, teils bei Jim Brain und als Chip für C128DCR und 1571 bei Shop von Bobble.

    Gruß

    Werner

  • Hat jemand Lust, den Jiffydos Quelltext zu lesen? [Edit: Braucht aber niemand zu machen, ich kann auf der Ultimate auch eine Techpreview Firmware starten, die Befehle ans IEC Device einfach mitloggt, dann sieht man, was gemacht wird.]

    Jedenfalls wertet Jiffydos auf dem C64 bzw. dem C128 (also nicht in der Floppy oder im SD2IEC) manche Befehle selbst aus und macht was anderes. Im Fall vom @L:... gehe ich davon aus, dass er mittels M-W Code überträgt und den ausführen will. Deine Fehlermeldung liest sich nämlich so. Und das macht ja auch Sinn, man will was machen, was original CBM DOS nicht kann, also überträgt man den Befehl in die Floppy.

    Mit Anfühtrungszeichen überträgt Jifyfdos aber immer das, was man schreibt zur Floppy. Ohne Ausnahme.

    Ja, recht kompliziert, vor allem, woher soll man wissen, welche Befehle abgeändert werden und welche nicht? Da ist S-Jiffydos auf dem C64 sauberer. Ohne Anführungszeichen gehen nur die Befehle, die der C64 auswertet und anders macht. Alles andere braucht Anführungszeichen. Dafür kann man dort dann auch @A$ screiben, wenn der Befehl in der Stringvariablen A$ ist. Bei genauer Überlegung einfach konsistenter.

    Der entsprechende OPEN 1,x,15,"L:dateiname":CLOSE 1 tut es übrigens auch bei allen Geräten (CMD, IDE64 und SD2IEC). Es ist wirklich der "@"-Befehl, der am C64/128 mit Jiffydos / Jaffydos ohne Anführungszeichen den teilweise selbst interpretiert. Berühmtes und vermutlich bekanntes Beispiel: »@Q«. Da ist es recht offensichtlich, dass der nicht zur Floppy geht, sondern vom C64 bearbeitet wird.

    Das JiffyDOS ist übrigens komplett gekauft, teils bei Jim Brain und als Chip für C128DCR und 1571 bei Shop von Bobble.

    Weiß ich doch. Ich habe mein Jiffydos auch schon bevor Bobbel überhaupt den Jiffydos Markt betreten hat bei Jim Brain als Download gekauft. Für den C64 einafch weiteren Download gekauft und selbst ins Eprom geschrieben.

    ---
    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 19:16)

  • Hat jemand Lust, den Jiffydos Quelltext zu lesen?

    Warum???

    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" ) , also die Firmware von Euch hält sich nicht an die vorhandenen Anleitungen...

    Man kann das ja ändern, aber dann muß es in der readme stehen.

    Gruß

    Werner