Beiträge von markusC64 im Thema „Geos Issue im Github von Gideon“

    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.

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

    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.

    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.