GEOS MegaPatch V3 Release 2018

Es gibt 1.222 Antworten in diesem Thema, welches 218.544 mal aufgerufen wurde. Der letzte Beitrag (2. Juli 2025 um 17:17) ist von darkvision.

  • aber die 128er Version muss man daher nicht mehr weiter testen... die hat aktuell ein Problem.

    OK, aber eins will ich doch noch zum aktuellen MP3-128 sagen :wink: :

    Wenn ich von HD81 boote kann ich die problemlos zu HD Native umkonfigurieren und die Installation des neuen MP3-128 funktioniert problemlos und läuft dann auch.

    Also konzentriere ich mich erstmal auf das neue MP3-64 .

    Gruß

    Werner

  • Also konzentriere ich mich erstmal auf das neue MP3-64 .

    Da ich den Code aber in der 64er-Version ändern muss weil sonst der Speicher wieder nicht reicht, wird sich auch da was ändern... Du kannst das zwar testen, aber die nächste Version wird wieder anders sein... also Zeit sparen und lieber was sinnvolleres machen ;)

  • also Zeit sparen und lieber was sinnvolleres machen

    Dann bleibe ich erstmal bei der Version vom 1.12. . Die funktioniert hier tadellos und ich spare mir die Installation von MP3-64 (6.12). Komme ich wohl doch noch dazu die HD-Copie auf SD2IEC fertig zu kriegen. Neue Tests, wenn es was neues gibt....

    Gruß

    Werner

  • Neuer Versuch... auch wenn mir so langsam die Ideen ausgehen :gruebel

    Ich hatte zwischenzeitlich unter VICE128 beim Installieren von Laufwerken Pixelfehler...

    Bitte melde dich an, um diesen Anhang zu sehen.

    Mit der Versionsverwaltung von GitLab hab ich den Fehler bis zum 22.12.18 zurückverfolgt, der Fehler ist also schon älter. War nur bei 1541/71/81 der Fall. Ist das jemand am realen C128 aufgefallen oder ist das ein VICE-Problem? Konnte ich mit Vice3.3 reproduzieren.

    Die Ursache ist mir nach wie vor Schleierhaft. Mittels Breakpoints hab ich das zu den Kernal-Routinen SECOND und CLOSE zurückverfolgt. Vor dem Aufruf der Routinen alles Paletti, danach Pixelfehler. Nur bei 80Z. Es scheint aber kein Problem mit den Routinen zu sein, denn da gibt es keine Stelle die in das VDC-RAM schreibt. Ich vermute eher ein Problem mit dem IRQ, denn bei CLOSE gibt es eine Warteschleife (LDX, DEX,... BNE...): Vor der Schleife alles OK, danach Pixelfehler.

    Mit dem Code vom 16.12.18 keine Probleme mehr.

    Das beim 128er vorhandene Laufwerke bei der Installation eines anderen Laufwerks mit gleicher Adresse plötzlich alle Laufwerke leuchten wie ein Weihnachtsbaum, also das scheint eine Eigenheit des 128er zu sein: Bei CLOSE gibt es eine Ausnahmebehandlung für den Fehlerkanal mit Sek.Adresse 15. Hier wurde dem GEOS.Editor auch dann "Kein Fehler" zurückgemeldet, wenn ein Laufwerk mit der Adresse vorhanden ist.

    Mit dem aktuellen Build ist mir das unter VICE nicht mehr aufgefallen. Aber was will das schon heißen...

    Ich hab an einigen Stellen weitere "Hosenträger" eingebaut... hoffentlich hilft das die Laufwerks-Installation etwas sicherer zu gestalten. Das betrifft aber alle Laufwerkstreiber. Die meisten hab ich am C64 durchgetestet, RAMLink und SCPU folgen in den nächsten Tagen, HD fällt flach.

    Aber FD, SD2IEC und 1541 sowie den RAM-Treibern RAM41/71/81 und CREU/GRAM hab ich durchgetested... mehrfache Wechsel scheinbar ohne Probleme.

    Mit VICE128 hab ich nur FD, 1581 und 1571 und einige RAM-Treiber getestet.

    Neu ist bei SD2IEC-Native-Treiber, das dieser jetzt nicht mehr auf die GEOS-Adresse beschränkt ist:

    Ich hab an Stelle des SD2IEC ein anderes Laufwerk installiert. Die Adresse des SD2IEC wird dann getauscht. Will man das SD2IEC jetzt wieder installieren, dann einfach im Editor einrichten, die Adresse wird wieder zurückgetauscht.

    Aber Achtung! Das gilt nur für ein SD2IEC/Native ohne "M-R"-Emulation. Ist eine "M-R"-Emulation für 1541/71/81 aktiv, dann verhält sich das SD2IEC auch wie so ein Laufwerk.

    Workaround: Das SD2IEC mit einer "M-R"-1581-Emulation installieren, dabei wird die Adresse getauscht. Danach das Laufwerk als SD2IEC-Native einrichten.

    Anbei eine neue Testversion. Für 128er-Anwender gilt: Die aktuellen Builds scheinen Probleme zu haben, die ich nicht direkt 1:1 nachvollziehen kann. Die Version vom 28.9. gibt es noch Bitte melde dich an, um diesen Link zu sehen..

  • Hello,

    ich bin vielleicht zu naiv, aber gibt es irgendeine Verbindung (oder Abneigung) zwischen den GEOS Experten und Entwicklern hier und unserem Falk, der GEOS auf dem MEGA65 adaptiert? Immerhin nutzt der schon die volle Geschwindigkeit (Bootet in unter 1 Sekunde) und Auflösung aus. Will nicht villeicht der/die ein oder andere von Euch bei uns mitmischen? Wir fänden das geil!

    lg

    "VHDL schreiben ist wie in Mordor zu arbeiten. Es gibt viel Streben und viel Rauch, aber nur wenig Erfolg. Und Erfolg sieht meist schlimmer aus als Misserfolg" PGS 2019

  • ich bin vielleicht zu naiv, aber gibt es irgendeine Verbindung (oder Abneigung) zwischen den GEOS Experten und Entwicklern hier und unserem Falk, der GEOS auf dem MEGA65 adaptiert

    Ich hatte bereits Kontakt und eine Einladung zu deren Team-Platform... das alleine hatte aber schon ewig gedauert. Aber noch ohne die Dev-Kits sah ja nicht so aus als würde der M65 in naher Zukunft verfügbar sein, dazu die bestimmt andere Development-Platform... (Cross-Assembler sind mir zu kompliziert...) da hab ich mich dann dazu entschieden beim MegaAss und MegaPatch zu bleiben, auch wenn das nicht nativ auf dem Mega laufen wird. Was nicht heißen soll das ich nicht Fragen zur Umsetzung beantworten würde. Ich stehe dem Projekt nicht abneigend gegenüber, mein Code steht ja online zur Verfügung... meine Lebenszeit will ich aber anders nutzen...

    Deren Floppy-Treiber hatte ich mir schon mal angeschaut, entspricht dem Weg den ich für das SD2IEC ohne TurboDOS-Supprt gehen wollte (TurboDOS raus und Native über Floppy-Befehle die Daten von Disk laden). Also da gäbe es evtl. auch Synergie-Effekte, selbst wenn man getrennte Wege geht.

    Ich habe von GEOS noch nicht wirklich viel auf dem MEGA gesehen, abgesehen von einem kleinen DEMO. Wenn da existierende Anwendungen nicht laufen ist das Nice... aber da bleibe ich dann doch lieber beim C64-Modus und meinem MegaPatch/GeoDesk;)

    Ich kann mir GEOS ohne GeoDesk und GeoDOS nur noch schwer vorstellen, aber das liegt an meinem Nutzer-Profil. Mag bei jedem anders sein.

  • Neuer Versuch... auch wenn mir so langsam die Ideen ausgehen

    Sieht schon mal gut aus. MP3-128 auf SD2IEC (Native) installiert und funzt.

    Dann aus dieser neuen Installation Lfw. D (FD1581) in CMD-HD81 umkonfiguriert: funzt. Installation auf HD1581 problemlos und bootet dann auch von HD (11).

    Wieder mit SD2IEC Native und Laufwerk D FD1581 gebootet, FD 81 in HD Native umkonfiguriert und Installation auf HD Native. Problemlos und bootet dann auch von HD Native.

    Bei MP3-64 teste ich die nächsten Tage. Kann diesmal aber u.U. etwas länger dauern......


    Ich hatte zwischenzeitlich unter VICE128 beim Installieren von Laufwerken Pixelfehler...

    Schiebe ich mal auf VICE :wink: . An meinem C128 DCR habe ich sowas noch nie gesehen. Wenn, dann hätte ich schon was gesagt :wink: .

    Mir ist aber unter WinVice (die Version von markusC64 auf csdb.dk) aufgefallen, dass ich da manchmal die Titelzeile eines aktiven TD-Lfw-Fensters nur teilweise schwarz dargestellt wird....

    Und jetzt ist wirklich Feierabend.

    Gruß

    Werner

  • Sieht schon mal gut aus. MP3-128 auf SD2IEC (Native) installiert und funzt.

    Daaanke!!!!! :thumbsup:

    Bei MP3-64 teste ich die nächsten Tage. Kann diesmal aber u.U. etwas länger dauern......

    Nicht so wichtig, das kann ich selber testen... 128er ist aber echt eine Baustelle...

    Schiebe ich mal auf VICE :wink:

    Ich auch... trotzdem will ich das nicht sehen, der alte Code funktioniert ja :)

    Und jetzt ist wirklich Feierabend.

    Verdient! 1000xDanke :verehr: :applaus:

    Da kann ich ja jetzt auch beruhigt Feierabend machen. :Peace :ChPeace

  • ich bin vielleicht zu naiv, aber gibt es irgendeine Verbindung (oder Abneigung) zwischen den GEOS Experten und Entwicklern hier und unserem Falk, der GEOS auf dem MEGA65 adaptiert

    Ich hatte bereits Kontakt und eine Einladung zu deren Team-Platform... das alleine hatte aber schon ewig gedauert. Aber noch ohne die Dev-Kits sah ja nicht so aus als würde der M65 in naher Zukunft verfügbar sein, dazu die bestimmt andere Development-Platform... (Cross-Assembler sind mir zu kompliziert...) da hab ich mich dann dazu entschieden beim MegaAss und MegaPatch zu bleiben, auch wenn das nicht nativ auf dem Mega laufen wird. Was nicht heißen soll das ich nicht Fragen zur Umsetzung beantworten würde. Ich stehe dem Projekt nicht abneigend gegenüber, mein Code steht ja online zur Verfügung... meine Lebenszeit will ich aber anders nutzen...

    Deren Floppy-Treiber hatte ich mir schon mal angeschaut, entspricht dem Weg den ich für das SD2IEC ohne TurboDOS-Supprt gehen wollte (TurboDOS raus und Native über Floppy-Befehle die Daten von Disk laden). Also da gäbe es evtl. auch Synergie-Effekte, selbst wenn man getrennte Wege geht.

    Ich habe von GEOS noch nicht wirklich viel auf dem MEGA gesehen, abgesehen von einem kleinen DEMO. Wenn da existierende Anwendungen nicht laufen ist das Nice... aber da bleibe ich dann doch lieber beim C64-Modus und meinem MegaPatch/GeoDesk;)

    Ich kann mir GEOS ohne GeoDesk und GeoDOS nur noch schwer vorstellen, aber das liegt an meinem Nutzer-Profil. Mag bei jedem anders sein.

    Danke für Deine ehrlichen Worte.

    Hier die erste Demo vom gepatchten GEOS für alle Video Modes:

    Bitte melde dich an, um dieses Medienelement zu sehen.

    Hier ist die neueste GEOS@MEGA65 Demo:

    Bitte melde dich an, um dieses Medienelement zu sehen.

    lg

    "VHDL schreiben ist wie in Mordor zu arbeiten. Es gibt viel Streben und viel Rauch, aber nur wenig Erfolg. Und Erfolg sieht meist schlimmer aus als Misserfolg" PGS 2019

  • Der SuperRAM-Treiber macht auch was er soll, eben getestet.

    Die RAMLink hab ich schonmal rausgesucht, aber da muss ich wieder dieses blöde Kabel intern verbauen... Folgt dann morgen :(

    Ein Problem hab ich aber noch gefunden: Versucht man die Super-/CREU/GeoRAM-Treiber mehrfach zu installieren sollte eigentlich ein Fehlerhinweis erscheinen. Jetzt stürzt das System einfach ab. Dürfte aber nichts großes sein. Der Treiber an sich funktioniert ja.

    P.S. Problem schon gefunden... ist dann im nächsten Snapshot gefixt.

    SuperCPU ist unter GEOS einfach schneller als das TC64... dafür musste ich aber den RetroTINK wieder rauskramen weil die SuperCPU keinen VGA-Anschluss hat... Allerdings sind meine SD2IEC wohl nicht SuperCPU-Kompatibel, die laufen nur im 1MHz-Modus, sonst bekomme ich nur "DEVICE NOT PRESENT". Am TC64 kein Problem...

    Alles hat seine Vor- und Nachteile :D

  • Leider sieht es diese Woche sehr schlecht aus mit testen. :cursing:

    Wenn ich es richtig verstanden habe ist die Version vom 08.12.19 (Beitrag 484) eher für den C128?

    Beim SD2IEC:

    Muss jetzt wieder eine MR gestartet werden wenn man D81 (1581) benutzen will oder wird die automatisch gestartet?

    Allerdings sind meine SD2IEC wohl nicht SuperCPU-Kompatibel, die laufen nur im 1MHz-Modus,

    Wenn ich auf's SD2IEC zugreife, schaltet die SCPU automatisch auf 1 MHZ (LED geht aus), ist bei den Seriellen LfW normal.

    Oder meinst Du was anderes?

    Gruss C=Mac.

  • Muss jetzt wieder eine MR gestartet werden wenn man D81 (1581) benutzen will oder wird die automatisch gestartet?

    Daran hat sich nichts geändert, ist alles wie bisher auch.

    Wenn ich auf's SD2IEC zugreife, schaltet die SCPU automatisch auf 1 MHZ (LED geht aus), ist bei den Seriellen LfW normal.

    Hm... bei mir war das eben nicht der Fall... musste manuell auf 1MHz schalten, dann erst hat das Laufwerk reagiert. Unter GEOS konnte ich dann den Turbo-Schalter wieder umlegen.

    Evtl. waren auch einfach nur zu viele Laufwerke am ser.Bus oder ich müsste mal ein andere Reihenfolge testen. Spielt aber für mich keine große Rolle.

    Wenn ich es richtig verstanden habe ist die Version vom 08.12.19 (Beitrag 484) eher für den C128?

    Nö, auch für C64... das wäre der nächste SnapShot gewesen, aber mit dem Bug des doppelten einrichten der Treiber muss ich das neu assemblieren. Aber die Version hab ich gestern am C64+TC64 und heute mit der SCPU schon sehr intensiv getestet. Werner hat das ja schon am 128er getestet.

    Wer mit dem letzten SnapShot Probleme hat kann die 8.12 nehmen.

    Ich schau mal was morgen mit der RAMLink passiert... wenn das auch geht müssten alle Treiber durchgetestet sein, dann gibt's den neuen Snapshot...

  • Nur der Vollständigkeit halber:

    Habe jetzt den gleichen Test wie gestern mit MP3-128 (08.12.) auch mit MP3-64 (08.12.) durchgeführt. Gleiches Ergebnis. Keine Probleme.

    Gruß

    Werner

  • Gleiches Ergebnis. Keine Probleme.

    Doch... nur hast Du die evtl. nicht bemerkt ;)

    RAMNative verliert beim Update den Inhalt und RAMLink ggf. die aktive Partition. Ist hier aber wie der Bug mit dem doppelten Installieren schon behoben.

    Ich brauch für den RAMLink-Test dann eh ein neuen Build, evtl. häng ich da nachher noch einen weiteren Testbuild hier dran. Wer warten kann... ich denke bis zum Wochenende bin ich mit meinen eigenen Tests durch, evtl. auch schon früher.

    Aber gut zu sehen das zumindest mit den seriellen Geräten jetzt keine Probleme mehr auftreten. :puhh:

  • Doch... nur hast Du die evtl. nicht bemerkt ;)

    RAMNative verliert beim Update den Inhalt und RAMLink ggf. die aktive Partition.

    Ich habe hier C=REU Native ca. 12 MB (191 Tracks). Da war nach der Installtion der Inhalt noch da. Zu RL kann ich nichts sagen :wink: .

    Aber in den nächsten Tagen dann der neue Test-Build .....

    Gruß

    Werner

  • Ich habe hier C=REU Native ca. 12 MB (191 Tracks). Da war nach der Installtion der Inhalt noch da. Zu RL kann ich nichts sagen :wink: .

    Das bezog sich auf RAMNative, nicht die RAM-Treiber für CREU, GEORAM, SCPU...

    Du must den neuen Build nicht mehr unbedingt testen... bis auf die RAMTreiber ist der ja identisch mit dem 8.12. Morgen teste ich noch die RAMLink durch... dazu brauchte ich aber den neuen Build. Den hab ich eben am C64 durchlaufen lassen. Keine Probleme.

    Bis auf das Kabel ist jetzt alles für den RAMLink-Test vorbereitet.

  • Die RAMLink funktioniert mit der Version von Gestern auch ohne Probleme... dann kann ich jetzt in den nächsten Tagen einen neuen offiziellen Snapshot zusammenstellen. Dauert auch etwas, ist ja doch jedesmal einiges an Arbeit ...

    Danke an alle die durch testen geholfen haben auch diese Probleme zu beseitigen. Einige schlummerten ja schon fast ein Jahr unentdeckt im Code :gruebel

  • Neuer MetaPatch Bitte melde dich an, um diesen Link zu sehen. V3.3r6. Entspricht bis auf das Datum der letzten Test-Version (Bitte melde dich an, um diesen Link zu sehen. gegenüber dem letzten SnapShot).