GEOS MegaPatch V3 Release 2018

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

  • APP Links in MP3??? Wäre mir neu :bgdev :wink: :bgdev (Sch... Copy & Paste)

    Ja, das war copy'n'paste, aber wo ist das Problem? OK, GeoDesk64 wird nicht mehr weiterentwickelt, aber tut unter MP3 nach wie vor seinen Dienst (nutze ich jedesmal wenn ich MP3 aktualisieren muss). Die AppLinks nutze ich daher auch unter MP3. Ich würde mal vermuten das einige der bisherigen AppLink-Fehler da noch enthalten sind, aber da die meisten unter MP3 eh auf TopDesk setzen, hat das hier keine größere Priorität...

    Bitte melde dich an, um diesen Anhang zu sehen.

    Also ja, es geht!!! 8o

  • Moin,

    ja teilweise Copy & Paste. Nutze unter MP3 64 immer noch beide “Desktop's“.

    Gestartet wird mit Topdesk und danach Start von Geodesk. Habe ich, warum auch immer, nie geändert. Da ja für beide Desktops Updates erschienen, habe ich es einfach, zum ausprobieren, so gelassen. :)

    Der Geodesk ist mit seinen Möglichkeiten (z. B. AppLinks) eindeutig mein Favorit. Schade, dass es keine 128er Version davon gibt.:weg:

    Liebe Grüße,

    Jojo

  • Mal ne Frage:

    Gibt es irgendwo eine Anleitung, wie man das aktuelle MP3 64/128 aus dem aktuellen Quellcode selbst assemblieren kann?

    Ich weiß, daß es vor Jahren (muß so 2018/2019) wohl sowas gab :wink: und ich damals auch MP3 erfolgreich selbst assembliert hatte (in WinVICE, müßte hier im Forum noch irgendwo nachlesbar sein). Mit dem aktuellen Source-Code bekomme ich das aber irgendwie nicht mehr hin. Keine Ahnung was ich damals anders gemacht hatte...

    Ich bin in MP3-128 (aktuell), kopiere MegaAss (V5.2), die 6 Source-D81 fileweise auf C: (RAMNative 12 MB). Dazu nutze ich geoDOS (aktuell), da TopDesk mit den vielen Dateien nicht klar kommt. Schon beim Kopieren der 2. Disk werden 2 Dateien als schon vorhanden angemeckert: src.GEOS_MP3.64 und src.GEOS_MP3.128. Habe sie mal überschreiben lassen und das Assemblieren (Auto-Assembler) mit ass.MP3 gestartet. Nach einiger Zeit kommt ein schwerer Fehler "SuperMouse64" nicht gefunden...

    Kann mir mal jemand auf die Sprünge helfen? Danke.

    Gruß

    Werner

  • Moin,

    nun auch das Geos-Megapatch-3.3r11r240731-dev Update , auf mein Realsystem gebracht. Jeweils auf eine RL81er Partition und einer HD81er Partition installiert.

    Auch hier habe ich beim "rumspielen" keine Probleme festgestellt.:thumbup:

    Schaut bei mir hier soweit gut aus.:)

    Liebe Grüße,

    Jojo

  • Hallo,

    im aktuellen MP3 (64 und 128 Version) scheint ein Fehler zu stecken:

    Es gelingt mir nicht mehr, mit geoDirSelect V1.8 D81-Images auf dem SD2IEC zu wechseln. Ich starte geoDirSelect von Lfw. B: RAM1581, wechsele auf Lfw. A: SD1581 (das aktuell gemountete D81 ist vorhanden) und dann in der Dateiauswahl auf "... (ZURÜCK)" . Ergebnis: Nur noch Müll in der Datei-Auswahl (Dateiliste) und hektisches Blinken der roten LED am SD2IEC.

    Ich kann das wieder reparieren indem ich mit der TopDesk-Funktion (Image-Wechsel), uiecSwitch oder mit GeoDesk auf das SD2IEC gehe und ein neues D81 auswähle. Da funktioniert das ohne Probleme.

    Mir ist klar, daß man geoDirSelect eigentlich nicht mehr braucht, aber früher hat das doch auch mal funktioniert .... :

    Als Gegenprobe habe ich eine ältere Version von MP3-64 (war eine von 1999 :wink: ) probiert. Da funktioniert der Wechsel von D81 mit geoDirSelect V1.8.

    Und es scheinen nur D81 auf SD2IEC betroffen zu sein. DNP kann ich hier auch weiterhin problemlos mit geoDirSelect wechseln...

    Ich habe mal mein aktuelles Boot-D81 (MP3-64) angehängt (spezieller Tastaturtreiber u.ä. sind entfernt ;) ) . geoDirSelect ist mit drauf. Konfiguration: A :SD1581 (BootLfw), B:RAM1581, C:1541 .

    Gruß

    Werner

  • Moin,

    werde ich bei mir auch mal probieren. Kann leider etwas dauern.

    Nach einem Starkregen hatten wir gestern mal wieder den Keller unter Wasser. Haben wir zwar alle 2 bis 3 Jahre mal, aber gestern war schon ziemlich extrem. Jetzt muss ich erstmal reinemachen.........:/

    Liebe Grüße,

    Jojo

  • Es gelingt mir nicht mehr, mit geoDirSelect V1.8 D81-Images auf dem SD2IEC zu wechseln. Ich starte geoDirSelect von Lfw. B: RAM1581, wechsele auf Lfw. A: SD1581 (das aktuell gemountete D81 ist vorhanden) und dann in der Dateiauswahl auf "... (ZURÜCK)" . Ergebnis: Nur noch Müll in der Datei-Auswahl (Dateiliste) und hektisches Blinken der roten LED am SD2IEC.

    Kann ich nachvollziehen.........

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bei mir ist das SD2IEC LW:C von dem ich Dein Image starte........


    Mir ist augefallen, das nach dem Desktop- und Verzeichnisaufbau, eine misteriöse "5" in der RAM81 (LW:B) ist..

    Bitte melde dich an, um diesen Anhang zu sehen.


    Wenn ich eine RAM81 unter LW:A anlege steht da eine "1".

    Auch wenn ich nach dem Absturz neu starte, wird erst in der RAM81 (LW:B) nur das leere Verzeichnis mit der "5" angezeigt. Wenn ich auf den Rollpfeil unten klicke, ist auf einmal Geoselect und die "1" da.

    Liebe Grüße,

    Jojo

  • Kann ich nachvollziehen.........

    Danke. Bin ich also nicht alleine mit dem Problem...

    Mir ist augefallen, das nach dem Desktop- und Verzeichnisaufbau, eine misteriöse "5" in der RAM81 (LW:B) ist.

    Da ist nichts mysterös :wink: .

    Wenn mein Image hier von A: gebootet wird, werden automatisch Dateien in die RAM1581 (Lfw. B:) kopiert (mit BootTrans). Ich habe mir das so eingestellt, daß immer beim Laden von TopDesk das Lfw. B (RAM) an Position 5 geöffnet wird (die Dateien davor (TD, Druckertreiber, ...) will ich nicht sehen). Das ist in "TopDesk.win" über Menü "Fenster" - "Einstellungen speichern" so gespeichert.

    Gruß

    Werner

  • also das beschriebene Problem mit geoDirSelect ist in der neuen Version wohl behoben. Aber ich habe jetzt ein anderes größeres Problem:

    WinVice 3.8 r45256 (GTK3 3.24.43, GLib 2.80.4, Cairo 1.18.0, Pango 1.54.0) Windows 10 x86_64 (64-bit)

    als Lfw. 8 ist eine FD4000 konfiguriert. Das funktioniert auch mit einem D4M im Native-Mode mit einer Partition (soweit ich das bis jetzt einschätzen kann). Was aber irgendwie nicht geht, ist ein D2M in der FD4000 im Native-Mode. Entweder hängt sich das Setup irgendwann auf oder (wenn es durchläuft) klappt das Neubooten nicht mehr. Sitze jetzt schon ein paar Stunden hier und probiere damit herum. Habe sogar ein neues leeres D2M mit VICE ersellt und darin installiert. Nachdem die Installation durchlief, habe ich die zusätzlichen Dateien auf die Disk kopiert. Wieso kann dann "ExitAutoBoot_MP3" plötzlich die 1. Datei im Directory sein?

    Vorherige Versionen von MP3 funktionierten in der angegebenen Konfiguration problemlos, egal ob D4M oder D2M in der FD4000.

    Das kaputte D2M (es bootet ins Nirvana) hänge ich hier mal an ....

    Gruß

    Werner

  • Wie immer... kaum oder keine Informationen zum SETUP... kein Ausschluss-Test um fremde Software auszuschließen.

    Wie auch immer, ich hab heute stunden damit verbracht MP3 von 0314/0731/0906 auf 0731/0906 zu aktualisieren. Sowohl MP64 als auch MP128. Die Setup-Dateien lagen dabei auf D:1581 und installiert wurde auf A:FD4000/Native mit einem D2M. Zuvor wurde immer neu gebootet, dann SETUP von D: gestartet und auf A: installiert, dabei immer eine Installation überschrieben.

    Dabei wurde VICE immer mit FD4000 als A: gestartet, also nicht nachträglich über die VICE-Settings von 15xx auf FD4000 geändert (da gab es mal einen VICE-Bug dazu). Anschließend die Installation durchgeführt und nach Rückkehr zum BASIC erneut mit LOAD"GEOS... neu gestartet.

    Nach mehr als einem Dutzend verschiedener Installationen zwischen den verschiedenen Versionen gab es hier keine Probleme. Grundsätzlich funktioniert das also. Ich hatte zuerst den Verdacht das der Bug in 0731 auch auf Native Probleme verursacht wenn man damit 0906 neu installieren will. Aber die Tests haben hier keine Probleme gezeigt.

    Ich könnte das ja an realer Hardware testen... ich hab aber erstmal auf dieser "ominösen" Testdisk die AutoStart-Datei "ExitAutoBoot" in eine Anwendung umgewandelt und danach startet die Bootdisk "normal". Warum die Datei am Anfang steht kann ich nicht sagen, aber wenn diese Datei nicht ausgeführt wird klappt alles wie es soll. Ist auch logisch, denn damit wird der GEOS.Editor gar nicht erst ausgeführt... GEOS-Editor muss die erste AutoExec-Datei sein...

  • Kleiner Nachtrag:

    Gibt es irgendwo eine Anleitung, wie man das aktuelle MP3 64/128 aus dem aktuellen Quellcode selbst assemblieren kann?

    Ich hab die SourceCode-Disks zu MP3 aktualisiert, auf der DiskBitte melde dich an, um diesen Link zu sehen./Symbol findet sich jetzt eine Anleitung wie man MP3 assembliert.

    Deine Variante war bisher so nicht angedacht, hätte man aber über eine Anpassung der ass.Drives.*-Dateien selbst erstellen können. Ich hab jetzt eine Vorlage erstellt (RAMD), aber mann muss die AutoAssembler-Dateien selbst anpassen+assemblieren, wenn man nicht die Vorgabe (RAMNM, Native+SubDir) verwenden will (die wohl bisher nicht mehr funktioniert hat). Ich selbst verwende CMDRL, alle SourceDisks liegen auf verschiedenen RL81-Partitionen. Alles andere ist extrem unpraktisch... zumindest wenn man regelmäßig Backups der einzelnen RAMLink-Partitionen machen muss.

  • Wieso kann dann "ExitAutoBoot_MP3" plötzlich die 1. Datei im Directory sein?

    Ich hab dazu nach wie vor keine Antwort... aber ich teste aktuell GDOS64 auf einer anderen Konfiguration, und bei der BootDisk sind ebenfalls andere Dateien am Anfang der Diskette. Da scheint es ein grundsätzliches Problem zu geben, muss ich mir genauer anschauen.

    Hattest Du irgendwann das Verzeichnis gelöscht? Also nicht formatieren, sondern "Verzeichnis löschen"? Das hatte ich aktuell bei den Dutzenden Tests ab&zu verwendet... Unter ganz dummen Zufällen könnte es ggf. hier zu solchen Problemen kommen.

    Außerdem:

    Wer MP3 oder GDOS64 selbst assemblieren will, bitte MegaAss V5.2 verwenden. Die Version bietet aktuell den größter freien Symbolspeicher, mit V5.1 kann ich z.B. GeoDesk aus GDOS64 nicht mehr assemblieren.

  • ich teste aktuell GDOS64 auf einer anderen Konfiguration, und bei der BootDisk sind ebenfalls andere Dateien am Anfang der Diskette.

    Ich hab dazu heute weitere Tests gemacht, kann das aber nicht mehr nachvollziehen.

    Ich hab mir die Diskette von WW und mein d2m mal angeschaut. Die Dateien, die vor allen Systemdateien im Verzeichnis angezeigt werden, beginnen ab Sektor $01/$22. Das ist immer der erste Verzeichnisblock. Bei der Disk von WW ist da nur eine Datei am Anfang, danach folgen die Systemdateien. Bei meinem d2m sind es sogar 2 ganze Blöcke (16 Dateien). Die Linkzeiger selbst sind aber i.O., d.h. von $01,$22 geht es nach $01,$23, $24, $25 usw... also alles durchgehend.

    Da müssten ja Verzeichnis-Einträge von "hinten" nach vorne umkopiert worden sein oder ganze Verzeichnis-Blöcke in einer anderen Reihenfolge beschrieben worden sein.

    Sowas könnte passieren wenn ein Programm beim kopieren von Dateien nicht ab der ersten Verzeichnis-Seite Dateien anlegt. TopDesk (nicht DTopDesk) macht das z.B. beim anlegen von Ordnern so: Die werden immer erst ab der zweiten Verzeichnis-Seite erstellt. D.h. ich erstelle auf einer leeren Diskette einen neuen Ordner und kopiere anschließend Dateien auf die Diskette in den Hauptordner. Die Dateien werden dann vor dem Ordner angezeigt. TopDesk (und DTopDesk) suchen aber beim kopieren selbst immer ab der ersten Verzeichnis-Seite nach freien Einträgen. Sollte in dem Fall also kein Problem sein.

    Ich werde am WE weitere Tests dazu machen. Falls jemand sowas beobachtet wäre ein Original-Image und dann ein Image nach dem installieren von MP3 hilfreich.

  • Ich hab die SourceCode-Disks zu MP3 aktualisiert, auf der DiskBitte melde dich an, um diesen Link zu sehen./Symbol findet sich jetzt eine Anleitung wie man MP3 assembliert.

    Danke. Wollte das eigentlich nur nochmal probieren, weil es in Vice seit Ende Juli (Bitte melde dich an, um diesen Link zu sehen.) eine neue Funktion gibt , die automatisch im Warp-Mode den Sound-Support deaktiviert (assembliert schneller) ...

    Wer MP3 oder GDOS64 selbst assemblieren will, bitte MegaAss V5.2 verwenden

    Wäre bei mir gegeben ;) .

    Hattest Du irgendwann das Verzeichnis gelöscht? Also nicht formatieren, sondern "Verzeichnis löschen"?

    Nein, das war ein direkt in WinVice (Menü "File" - "Create and attach an empty disc image ...") völlig neu erstelltes D2M. Darauf erfolgte dann die Installation aus RAMNM (REU; B: 12 MB) auf A: FD2000 (als FD4000 konfiguriert in Vice). Danach habe ich die 10 zusätzlichen Dateien auch von RAMNM auf die Bootdisk kopiert. Unterverzeichnisse oder TD-Ordner waren nicht im Spiel...

    Bei der Disk von WW ist da nur eine Datei am Anfang,

    Ja, und die gehört normalerweise an Datei-Position 28 (direkt nach BootTrans) und wurde als 2. Datei (von 10 Dateien) kopiert...

    kann das aber nicht mehr nachvollziehen

    Geht mir hier genauso. Habe gestern und heute etliche Versuche durch, aber das Problem ist nicht mehr aufgetreten. Alle Installationen hier sind inzwischen ohne Fehler aktualisiert.

    Das neue MP3 funktioniert also grundsätzlich. Werde aber weiter beobachten ...

    Gruß

    Werner

  • Ich hab die SourceCode-Disks zu MP3 aktualisiert, auf der DiskBitte melde dich an, um diesen Link zu sehen./Symbol findet sich jetzt eine Anleitung wie man MP3 assembliert.

    So, jetzt habe ich mir die Zeit genommen, das Assemblieren von MP3 nochmals auszuprobieren ;) .

    Es funktioniert so wie beschrieben. Nochmal Danke.

    Was mir beim ersten Assemblieren (MP3-64, gilt aber auch für MP3-128) aufgefallen ist: Die 2 Hintergrundbilder müssen von der "Symbol"-Disk per Hand auf die "Target-Disk" kopiert werden, sonst werden sie beim Erzeugen des Setups nicht gefunden. Das sollte zumindest in der Anleitung noch erwähnt werden...

    Gruß

    Werner

  • Hallo zusammen,

    Ich hatte bis 2004 einen echten C64 mit 1581, 1541 und einer GeoRam.

    Geos 2.0 fand ich immer sehr nützlich.

    Aber den MP3 habe ich nie zum laufen gebracht.

    Jetzt nutze ich Vice mit 1541, 1581 und einer REU mit 1MB.

    Geos 2.0 läuft darauf super.

    Aber auch hier lässt sich MP3 nicht installieren.

    Es läuft alles durch ohne Fehler.

    Wenn ich dann von der neuen Disk (D81) booten möchte lädt es bis zum karierten Hintergrund. Dann meldet Vice einen CPU-Jam...

    Ich habe die neueste Version hier aus dem Thread verwendet.

    Was mache ich falsch?

    Muss ich im Emulator bestimmte Werte einstellen?

  • Wenn ich dann von der neuen Disk (D81) booten möchte lädt es bis zum karierten Hintergrund. Dann meldet Vice einen CPU-Jam...

    Du hast MP3 von dem gleichen Laufwerkstyp und der gleichen Laufwerksadresse wie bei der Installation gebootet? Der JAM deutet darauf hin das die Installation z.B. auf B:RAM81 ausgeführt und dann die Dateien auf ein A:D81 kopiert wurden. Das funktioniert so nicht.

    MP3 bekommt bei der Installation (oder beim erstellen einer BootDisk über GEOS.MakeBoot) einen festen Laufwerkstreiber und eine feste Adresse zugewiesen. Jegliche Abweichung von der Konfiguration führt zu Fehlern.

  • Das habe ich tatsächlich die ganze Zeit falsch gemacht.
    Ich habe jetzt im Vice eine Konfiguration erstellt bei der die 1581 Laufwerk 8 ist.
    Jetzt läuft es tatsächlich.
    Vielen Dank :smile: