Geos Issue im Github von Gideon

Es gibt 10 Antworten in diesem Thema, welches 912 mal aufgerufen wurde. Der letzte Beitrag (11. März 2025 um 15:48) ist von markusC64.

  • Hallo zusammen,

    auf Bitte melde dich an, um diesen Link zu sehen. habe ich gefunden:


    The content of previously mounted 5.25" disk appears in Geos MegaPatch 3 RAM1541 (Issue #487)

    Reproduction step;

    I set the configuration in U2+:

    • DriveA 1541, DriveB OFF
    • REU2MB
      I load System Geos 2.0 in the configuration: DriveA 1541, DriveB RAM1541.

    I change the configuration in U2+ to:

    • DriveA 1581, DriveB OFF
    • REU 16MB
      I load Geos MegaPatch3.3 in the configuration: DriveA 1581, DriveB RAM1541....

    ....and suddenly Desk Top 2.0 from Geos2.0 appears because the contents of the System Geos 2.0 disk appear in RAM1541. 🎉

    When using Geos 2.0 we can change the disk in DriveA to another one in U2+, then it will appear in RAM1541.

    All with JiffyDOS, but that doesn't matter, I guess.

    As for the option of saving to file and loading from file for RAM Disk (MP3) implemented in Bitte melde dich an, um diesen Link zu sehen.

    It works for me correctly for both, Geos 2.0 and MegaPatch 3.3.

    It does not work correctly for CMD gateWay.



    Ich habe den Eindruck, Gideon kann damit nicht allzu vuiel anzufangen wissen... Können wir ihn mal unterstützen und herausfinden, was es damit auf sich hat? Erster Eindruck ist jedenfalls: Wird wohl kein Fehler sein.

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

  • Für mich ist der Bugreport nicht ganz Eindeutig:

    I load System Geos 2.0 in the configuration: DriveA 1541, DriveB RAM1541.

    Hat der User danach noch etwas gemacht oder direkt nach dem Start GEOS beendet? Hat er z.B. den "DESK TOP" auf die RAMDisk kopiert?

    contents of the System Geos 2.0 disk appear in RAM1541.

    Wirklich alle Dateien? Also ein 1:1 Abbild der GEOS-Systemdiskette?

    Wenn ja, dann vermute ich hier einen Fehler in der Firmware, denn unter GEOS 2.0 kann man eine Systemdiskette nicht (ohne Hilfsmittel) mit allen Dateien auf eine RAMDisk kopieren. Selbst Disk/Copy wird vom DeskTopV2 verweigert.

    ....and suddenly Desk Top 2.0 from Geos2.0 appears

    Das wäre nur dann kein Fehler, wenn der User die Datei "DESK TOP" unter GEOS 2.0 auf die RAM1541 kopiert hat. MP3 lädt den DeskTop bevorzugt von einer RAMDisk, der Inhalt einer RAMDisk wird beim booten aber nicht automatisch gelöscht. MP3 findet dann den DESKTOPv2 auf der RAMDisk und startet den.

    Es gibt eine weit hergeholte Variante mit A:Shadow1541 und B:RAM1541, bei der nach einem Start von MP3 tatsächlich die erste Verzeichnis-Seite der GEOS-Systemdiskette als B:RAM1541 angezeigt wird, inkl. evtl. DeskTop. Allerdings befindet sich der DeskTop nicht im Shadow-Cache, daher stürzt MP3 dann beim laden des DeskTop ab. Man hätte den DeskTop auf die Systemdiskette kopieren müssen damit er im Cache landet. Bei einer Original-Systemdiskette verbietet das aber der DeskTop selbst.

    Interessant wäre der Inhalt von driveType+0 bis driveType+3 ($848E - $8491) und ramBase+0 bis ramBase +3 ($88C7 - $88CA).

    Sofern aber tatsächlich der gesamte Inhalt der GEOS-Systemdiskette auf der RAMDisk auftaucht muss man da nicht wirklich weitersuchen.

    As for the option of saving to file and loading from file for RAM Disk (MP3) implemented in #316

    It works for me correctly for both, Geos 2.0 and MegaPatch 3.3.

    It does not work correctly for CMD gateWay.

    Gateway != MP3/GEOS2.x, auf den ersten Blick scheint ramBase anders genutzt zu werden. Man kann daraus also nicht schließen wo im GEOS-DACC die RAMDisk liegt. Irgendwie muss der Treiber das ja aber wissen, müsste sich jemand genauer anschauen...

  • Ich habe mich schon gefragt, ob da Typ 1541 Shadow irgendwie reinspielen kann. Das dürfte zwar prinzipell unvollstädig sein, weil man in der Regel doch nicht alles lädt, aber solche Kandidaten wie Desktop und Directory sollte man schnell im Shadow haben. Allerdings hast Du Recht durch Geos laden allein könnte das evtl. nicht passiert sein.

    Und ob der User jeden Dateiinhalt kontrolliert hat, das wage ich zu bezweifeln.

    Allerdings reichen meine Geos-Kenntnisse nicht aus, um die Möglichkeit zu Ende zu prüfen. Bei Fragem, was wo in der REU landet, damit es anschließend ein anderes Programm wieder findet, da spielt ja doch ziemlich viel rein.

    So wenig, wie in dem Bug Report steht, kann man zumindest nicht ausschließen, dass der Benutzer "1541 Shadow" verwenden könnte.

    Und jetzt stell Dir das Ganze mal aus Sicht von Gideon vor, der sich mit GEOS überhaupt nicht auskennt. :sad:


    Und sowieso: Wie unvollständig ist der Issue eigentlich? Firmwareversion? Unbekannt. Geos Konfigurationsdetails? Unbekannt! Eventuelle weitere Autostarts auf der Startdiskette? Wer weiß, der Issue Leser jedoch bestimmt nicht.

    ---
    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 (10. März 2025 um 17:44)

  • Gateway != MP3/GEOS2.x, auf den ersten Blick scheint ramBase anders genutzt zu werden. Man kann daraus also nicht schließen wo im GEOS-DACC die RAMDisk liegt. Irgendwie muss der Treiber das ja aber wissen, müsste sich jemand genauer anschauen...

    Nun ja, den Teil lassen wir erst mal außen vor, der hat mehr von einem Feature Request als von einem Bug. Durch den Klammervermerk "(MP3)" schreibt der User ja selbst, dass das Feature eigentlich für MP3 ist.

    Wenn wer Gateway sagt, kommt als nächstes die Frage nach Wheels (geht das eigentlich? Ich fürchte nicht).

    ---
    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 mich schon gefragt, ob da Typ 1541 Shadow irgendwie reinspielen kann. Das dürfte zwar prinzipell unvollstädig sein, weil man in der Regel doch nicht alles lädt, aber solche Kandidaten wie Desktop und Directory sollte man schnell im Shadow haben

    Ich hatte das heute morgen vor dem Post kurz getestet, da ist MP3 immer abgestürzt. Allerdings war ich wohl noch nicht ganz wach: Du hast natürlich Recht das auch beim laden Daten in den Cache wandern.

    Allerdings initialisiert GEOS an verschiedenen Stellen das Shadow-RAM (NewDisk, OpenDisk und PurgeTurbo). Unwahrscheinlich das der DeskTop nach dem Laden und dem öffnen des Fensters noch gültig im Cache liegt. Das erklärt dann auch warum nur die erste Seite des Verzeichnisses überlebt und warum MP3 beim laden des DeskTop aus dem Cache abstürzt (es wird nur der erste Block geladen, die Link-Bytes sind nach der Initialisierung = 00,00). Aktuell frage ich mich ob der Cache in MP3 mit TopDesk/GeoDesk überhaupt noch einen Vorteil bringt.

    Das ganze kann man auch in VICE ohne Ultimate testen, ein Shadow-1541 halte ich daher für wenig wahrscheinlich: Wenn es in VICE abstürzt dürfte das auch bei realer Hardware der Fall sein, der Inhalt der REU dürfte der gleiche sein. Durch die Abfrage der 2x4 Bytes in GEOSv2 könnte man das aber ganz sicher ausschließen (oder der User macht einen Screenshot von CONFIGURE).

    Allerdings reichen meine Geos-Kenntnisse nicht aus, um die Möglichkeit zu Ende zu prüfen. Bei Fragem, was wo in der REU landet, damit es anschließend ein anderes Programm wieder findet, da spielt ja doch ziemlich viel rein.

    Der Inhalt eines D64/G64 wird doch auch irgendwo in den Flash-Speicher gelesen, oder? Kann es da Überschneidungen mit dem Speicher für die REU geben?

    Und jetzt stell Dir das Ganze mal aus Sicht von Gideon vor, der sich mit GEOS überhaupt nicht auskennt. :sad:

    Ersetze Gideon durch meinen Namen und GEOS durch Ultimate ;)

    Und sowieso: Wie unvollständig ist der Issue eigentlich? Firmwareversion? Unbekannt. Geos Konfigurationsdetails? Unbekannt! Eventuelle weitere Autostarts auf der Startdiskette? Wer weiß, der Issue Leser jedoch bestimmt nicht.

    Das meinte ich ja mit nicht ganz eindeutig. Da muss man zu viel rätseln... entweder man bittet den User um mehr Details (insbesondere was wirklich auf der RAMDisk nach dem booten von MP3 vorhanden ist: Systemdisk -> Firmwareproblem) oder man tagged das als "Invalid" wenn der User tatsächlich den DeskTop auf die RAM1541 kopiert hat -> Anwenderfehler.

  • Nun ja, den Teil lassen wir erst mal außen vor, der hat mehr von einem Feature Request als von einem Bug. Durch den Klammervermerk "(MP3)" schreibt der User ja selbst, dass das Feature eigentlich für MP3 ist.

    Wenn wer Gateway sagt, kommt als nächstes die Frage nach Wheels (geht das eigentlich? Ich fürchte nicht).

    Naja... zumindest ramBase steht bei einer B:RAM81 auf $01 was für BankBitte melde dich an, um diesen Link zu sehen. stehen würde, das wäre also so wie unter GEOSv2/MP3 auch. Wheels könnte also gehen...

    Unter gateWay steht dort $ff,$ff,$ff,$fe... wenn das die Firmware als "Startadresse" innerhalb der REU interpretiert, dann kann das laden nicht funktionieren. Sieht eher nach einer Art Bank-Tabelle aus, jedes Bit steht für 64k. 1=Belegt.

  • Der Inhalt eines D64/G64 wird doch auch irgendwo in den Flash-Speicher gelesen, oder? Kann es da Überschneidungen mit dem Speicher für die REU geben?

    Eine berechtigte Frage. Eigentlich sollte Gideon das Memory Management passend haben. Jedoch kann man ja einfach mal Diskimages einladen und dann den REU Speicher abspeichern lassen. Wenn es da was wäre, müsste es im REU Speicher ja auftauchen.

    Ersetze Gideon durch meinen Namen und GEOS durch Ultimate ;)

    Logisch.


    Naja... zumindest ramBase steht bei einer B:RAM81 auf $01 was für BankBitte melde dich an, um diesen Link zu sehen. stehen würde, das wäre also so wie unter GEOSv2/MP3 auch. Wheels könnte also gehen...

    Weil man per Ultimate auf den C64 Speicher nur sehgr erschwert zugreifen kann, wird statt dessen der Speicher in der REU zur Erkennung genommen. Wegen rboot etc. wird der Teil ja in der REU auch gespeichert damit daraus für rboot der entsprechende Teil wiederhergestellt werden kann. Und jetzt kommt das ABER: Ändert man was an den REU Block, der dazu genommen wird, ist das auf einmal wo anders. Da reicht schon selbe Offsets in anderen REU Block.

    Unter gateWay steht dort $ff,$ff,$ff,$fe... wenn das die Firmware als "Startadresse" innerhalb der REU interpretiert, dann kann das laden nicht funktionieren. Sieht eher nach einer Art Bank-Tabelle aus, jedes Bit steht für 64k. 1=Belegt.

    Was belegt, dass dort mehr geändert ist...

    warum MP3 beim laden des DeskTop aus dem Cache abstürzt (es wird nur der erste Block geladen, die Link-Bytes sind nach der Initialisierung = 00,00).

    Zu viele Ungewissheiten. Wir können ja nicht jede irgendwie verfügbare Version von configure durchprobieren. Wenn da eine von auch nur minimal anders in die REU schreibt, könnte der Absturz ja wiederum entfallen.


    Ich stimme Dir zu: Es braucht mehr Details. Sowohl im Text als auch meinetwegen im Anhang, die Diskimages könnte der User ja beifügen, damit man über die nicht rätseln muss. Es ist zwar nicht immer ganz einfach zu sagen, was da dann wirklich drin ist, insb. wen/falls gecrackte Versionen beteidigt sind. Aber ok. muss man vielleicht auch nicht. Wenn man es nachstellen kann, kann man Zwischenstände von RAM und REU prüfen etc.

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

  • Rein aus Interesse hab ich GEOS 2.0 nach dem Start und dem laden des DeskTopV2 angehalten und GEOS beendet, bevor DeskTopV2 gestartet wird. In dem Zustand ist der Cache "Valide" und enthält die Sektoren des Verzeichnisses und die von DeskTopV2, zumindest vom Haupt-Modul.

    Danach MP3 gestartet und der DeskTop wird aus der "RAMDisk" (Cache des Shadow1541-Laufwerks) geladen und gestartet und das Verzeichnis zeigt den "Inhalt" der Systemdiskette (aber nur den Inhalt, bis auf DeskTopV2 ist da nichts auf der RAMDisk).

    Was auch geht: Unter GEOSv2 1x Validate auf der Systemdisk ausführen und danach den C64 per RESET zurücksetzen. Danach MP3 starten. Da DeskTopV2 nach dem Validate kein "OpenDisk" ausgeführt hat, sind alle gelesenen Sektoren noch im Shadow-Cache und damit unter MP3 in der RAMDisk. Dadurch wird dann der DeskTop von B: geladen und gestartet. Ein "Disk/Validate" funktioniert dann auch auf der RAMDisk und sogar CONFIGURE lässt sich starten.

    Beendet man aber GEOSv2 korrekt über "Opt/BASIC", dann wird bereits wieder einmal OpenDisk ausgeführt (beim nachladen des BASIC-Moduls) und der Cache neu initialisiert. Dann lässt sich MP3 nicht mehr starten, da der DeskTopV2 nicht mehr korrekt aus dem Shadow-Cache geladen werden kann.

    Also ist ein Shadow1541-Laufwerk unter GEOS 2.0 eine mögliche Konfiguration im Bugreport, ohne "Validate" und Mithilfe des Users würde das aber nicht funktionieren. Es ist aber dennoch kein "Bug" sondern eher Unwissenheit über die Funktionsweise von GEOS/MP3. Abhilfe schafft hier "RAMDisk bei jedem System-Neustart löschen" im GEOS.Editor wenn man die RAMDisk installiert. Wenn ich das richtig sehe kommt die Abfrage aktuell aber nur wenn man die Option "Treiber in RAM" nicht aktiviert hat, muss ich mir anschauen, ist aber so gewollt da die Einstellung sonst nicht im Treiber auf Disk gespeichert wird.

  • Na, das erklärt doch einiges.

    Abhilfe schafft hier "RAMDisk bei jedem System-Neustart löschen" im GEOS.Editor wenn man die RAMDisk installiert

    Oder man coded sich ein C64 Programm, welches die komplette REU löscht (d. h. mit $00 überschreibt). Das kann man dann vorher starten. Ist sowieso manchmal nützlich. :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.

  • Oder man coded sich ein C64 Programm, welches die komplette REU löscht (d. h. mit $00 überschreibt). Das kann man dann vorher starten. Ist sowieso manchmal nützlich. :smile:

    Das TC64 hat dazu die F2-Taste im Hauptmenü. ist manchmal ganz nützlich ;)

    Ich hab jetzt im Bugreport mal ein paar Fragen gestellt. Mal sehn ob sich das dann aufklärt. Das einzige was mich noch verwirrt hat ist dieser Satz:

    When using Geos 2.0 we can change the disk in DriveA to another one in U2+, then it will appear in RAM1541.

    Das klingt für mich irgendwie nicht nachvollziehbar... mal abwarten...

  • Ich zitiere das hier nicht - aber Du hast im Github Antwort bekommen. Die Kurzfassung: Es ist genau so, wie wir uns gedacht haben.

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