Hallo Besucher, der Thread wurde 141k mal aufgerufen und enthält 1104 Antworten

letzter Beitrag von Juergen Johannes am

GEOS MegaPatch V3 Release 2018

  • So, bis eben die MP3 3r9 03.06.21 Current ohne Fehler installiert.


    1. Auf 1581 RL Partition, jeweils 64+128er Version erstellt.

    2. Auf 1581 HD Partition, jeweils 64+128er Version erstellt.


    Alle Versionen lassen sich ohne Probleme installieren, starten und einstellen.:)


    Sieht soweit sehr gut aus....... :thumbup:


    Gruß Jojo

  • In den letzten Tagen auch auf WinVice #40270 getestet................. ,:)


    MP3 64 Ram SCPU (4von16MB), Installationsort, LW08 CMDHD 81er Partition.


    64er Version auf SCPU64: LW08=CMDHD 81er Partition (Installpartition)

    LW09=CMDRL N16MB leer

    LW10=C1581

    LW11=C1541II



    MP3 128 Ram REU (4von16MB), Installationsort, LW08 CMDHD 81er Partition.


    128er Version auf SC128: LW08=CMDHD 81er Partition (Installpartition)

    LW09=C1581

    LW10=RAM1581

    LW11=C1541I



    Hat alles Super geklappt, die Installation ging ohne Probleme. Habe das jeweils mit Geodesk64 und TD64 bzw. TD128, letzte Versionen, danach die üblichen Sachen probiert ( Kopieren, validieren, löschen usw.). Ich konnte keine Probleme feststellen.............. KLASSE......................:thumbsup:


    Gruß Jojo

  • Hurra, auch ich habe mal wieder was geschafft........:rolleyes:


    Eben auch die MP3 64 + 128er Versionen (03.07.21) auf dem realen System installiert.

    Jeweils eine Version (64+128) auf RL1581 + HD1581. Lies sich ohne Probleme installieren und hat bis jetzt keine Fehler gemacht.


    Klasse......:thumbup:


    Werde in den nächsten Tagen (hoffentlich) noch ein wenig weiter probieren.


    Gruß Jojo

  • Lies sich ohne Probleme installieren und hat bis jetzt keine Fehler gemacht.

    Ich hab eben einige Installationen unter VICE vom D:RL81 nach C:RL81 getestet und dabei gab es einen "BAD BAM" Fehler. Ich hab das zwar mit GD3 getestet, könnte aber auch mit MP3 auftreten da gleiche Code-Basis.


    Das Problem war das ich die Ziel-Partition zuvor gelöscht hatte. Ich vermute hier einen Bug in VICE da der BAD-BAM-Fehler die BAM der gelöschten Disk zurückmeldet obwohl zwischenzeitlich ja Daten durch SETUP auf die Partition geschrieben wurden.


    Ich muss das mit der echten RAMLink mal testen, glaube aber nicht das es hier Probleme gibt. Sieht eher so aus als ob das Lesen von Sektoren aus dem RAMLink-Image die geänderten Daten auf der Partition übergeht.


    Wer Lust+Zeit hat: VICE/RAMLink + Ziel-Partition = RL81 löschen und direkt danach MP3 von RL81 nach RL81 installieren. Getestetet mit Warp-Modus... ca. 2000-3000%...


    Es könnte auch eine Race-Condition sein... d.h. das die geänderten Partitionsdaten nicht schnell genug den anderen Prozessen zur Verfügung gestellt werden und VICE dann veraltete BAM-Daten an GEOS übermittelt.


    Ab&Zu hab ich auch ein BAD-BAM-Fehler beim kopieren von Dateien unter GEODESK von einem RL-Laufwerk auf ein anderes, ebenfalls extrem selten. Ich würde das auch auf eine Race-Condition zurückführen wollen, denn 100%ig reproduzieren kann ich es nicht.


    Ansonsten: Danke an wweicht und Juergen Johannes für das testen... :thumbsup:

  • Ich hab das Problem mit "BAD BAM" bei der Installation den ganzen Tag zurückverfolgt... und ich gehe von einem Problem in VICE mit der RAMLink-Emulation aus. Am realen System passiert das nämlich nicht.


    Es reicht aus an bestimmten Stellen ein "INITIALIZE" an das RAMLink-Laufwerk zu senden. Dann scheint VICE die Laufwerksinhalte irgendwie zu synchronisieren. Ohne den "I"-Befehl landen Daten von der alten BAM (von der zuvor gelöschten Partition) im Speicher und nicht die zwischenzeitlich geänderte BAM nach dem entpacken der SETUP-Dateien. Wenn dann Dateien gelöscht werden sollen -> BAD BAM (weil ja alle Sektoren schon freigegeben sind).


    Da es extrem schwierig werden dürfte hier für den VICE-Bugtracker ein Szenario zu entwickeln damit die Entwickler das nachvollziehen können habe ich mich dazu entschlossen das VICE-Problem zu umgehen:

    Da zu Beginn des Updates eh alle Laufwerke erkannt werden müssen sende ich hier vorher ein "I" an das Laufwerk. Außerdem wird jetzt auch bei den RAMLink-Treibern der "I"-Befehl beim wechseln der Partition an das Laufwerk gesendet. Bei den anderen CMD-FD/HD-Treibern war das schon der Fall. Bei der RAMLink eigentlich unnötig, aber für VICE eben als Workaround erforderlich.


    Das könnte auch die Probleme beim FileCopy beheben, die ich ab&zu nur unter VICE hatte (siehe oben). Dabei verwende ich ja noch MP3 und damit dürfte das Problem nicht nur in GD3 auftreten, sondern auch in MP3. Daher teste ich den Fix jetzt unter GD3 und wenn alles klappt wird das auch in MP3 ergänzt.


    [EDIT]

    Bei MP128 müsste ich allerdings testen ob da noch Platz in den RAMLink-Treibern vorhanden ist. Falls nicht wird das ein "bekanntes Problem" unter MP128 und VICE+RAMNLink bleiben.

    [EDIT]


    Bei einer realen RAMLink sollte der Fix/Workaround keine Auswirkungen haben.

  • [EDIT]

    Bei MP128 müsste ich allerdings testen ob da noch Platz in den RAMLink-Treibern vorhanden ist. Falls nicht wird das ein "bekanntes Problem" unter MP128 und VICE+RAMNLink bleiben.

    [EDIT]

    Es war extrem knapp... :puhh:


    Zuerst war der Fix 16 Bytes zu groß für den RAMLink-Native-Treiber. Dann etwas optimiert, jetzt ist noch genau 1 Byte frei aber der Fix geht auch in MP128 (auch wenn es unter VICE128 aktuell keine RAMLink gibt).


    Da aber die FD+HD-Treiber nach dem CP-Befehl schon ein "I" senden, da wollte ich das dann grundsätzlich gleich machen...


    Kommt mit dem nächsten Update, ist aber glaub ich nicht ganz so wichtig, zumindest für die meisten.

  • neuer MP3-Snapshot (17.07.21) mehrfach getestet. Bisher keine Probleme. Danke.


    Gruß

    Werner


    Auch bei mir Keinerlei Probleme.........


    Vielen Dank

    Kann ich mir nur anschließen............... läuft bisher ohne Probleme.

    Klasse.:thumbsup:


    Winvice #40270 w10/64bit, xscpu64 (Scpu Ram 4MB für MP3)


    Mein CMDHD Image als LW8, MP3 auf einer 1581er Partition installiert (Zieldisk).

    LW09 Ramlink 16MB Native,

    LW10 1581 (Quelldisk für MP3 17.07.21),

    LW11 erst 1541, dann wahlweise als Ram1581, RamNative und Superram probiert.


    Gruß Jojo

  • Bin auch wieder da :rolleyes:


    Nachdem ich seit über einem Jahr nichts mehr mit dem C64/128 gemacht habe (weiss nicht mal ob die noch funktionieren), wird es wieder Zeit dies zu ändern.


    Nur habe ich natürlich den Überblick verloren, es ging ja einiges u.a. 1581 Unterstützung für die Ultimate 2+ :thumbsup:


    Was ist im Moment die aktuellste MP3 - Version (64/128)? Snapshot vom 17.07.21?

    Und kann direkt von einer alten Version (keine Ahnung r5 oder r6) auf die neuste Version geupdatet werden?


    Gruss C=Mac.

  • Danke an die vielen Tester der letzten SnapShot-Version... :thumbsup:


    Hab aber bereits einen eher unbedeutenden Fehler gefunden (Tritt nur auf wenn man SETUP "manuell" von einem bestimmten Laufwerkstyp aus durchführt und nachdem man den Code selbst assembliert hat und das Update manuell anschubst -> Kein SETUP ausgeführt) und eine kleine "Optimierung" in Verbindung mit TopDesk ergänzt (nur unter VICE mit WarpMode=On wenn man den TaskManager über "GEOS" aufruft und gleich wieder beendet).


    Gut wenn die Standardinstallation funktioniert... aber ich teste hier und da auch mal was außerhalb der Spezifikation, aber die Probleme dabei werden immer weniger. :)

  • Hab endlich die neuste MP3-Version installiert, naja wenigstens die C64 auf dem C128. ;)


    Scheint bis jetzt ohne Probleme zu funktionieren inkl. GeoDesk64. :thumbsup:


    Und auch die Emulation der 1581 auf der Ultimate 2+ wird ohne Probleme erkannt.


    Einfach so, für wenn es auch immer interessiert.

    Ladezeit MP3 64 bis GeoDesk64 erscheint, gestartet von der 1581 in der Ultimate 2+:


    Ohne JiffyDOS: 202 Sekunden

    Mit JiffyDOS: 95 Sekunden


    Gruss C=Mac.

  • Ebenso einfach so: Es besteht die Vermutung, dass die Ultimate die 1581 etwas zu schnell emuliert - oder anders formuliert, dass eine emulierte 1581 schneller lädt (schreibt) als eine echte 1581.


    Sollte man vielleicht bei der Einschätzunf der Zeiten im Hinterkopf haben...


    PS: Das Geos MP3 mit der emulierten 1581 (und auch 1571) geht, ist kein Wunder: Ich habe die Alphaversionen u. a. mit Geos ordentlich durchgeschüttelt - um damalige Bugs zu fiunden.