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

letzter Beitrag von Juergen Johannes am

GEOS MegaPatch V3 Release 2018

    Hallo Jojo,


    das Problem ist genau das, was gerade nebenan diskutiert wird. Dualtop 128 steht auf 40- und 80-Zeichen, Dualtop 64 auf nur 40 Zeichen. Da kann man nichts verhindern.......


    Entweder: aufpassen, was Du wo startest ;-) .


    oder


    ändere mit geoDOS (siehe im geoDOS-Thema) den Bildschirmmodus auf:


    DualTop128 "Nur Geos 128"
    DualTop64 "Nur Geos 64"


    Damit sollte das Programm im "falschen" System nicht mehr starten.


    Gruß
    Werner

    Hallo Werner,


    werde ich mir mal anschauen.


    In der Regel kennt der Geos User ja meistens die Programme mit denen er startet. Wenn nicht, hat er einmal einen Systemabsturz. Danach weiss er ja dann Bescheid und könnte es z.B. im Infoblock des Programms hinterlegen. :)

    Zitat von Juergen Johannes

    Hallo Werner,
    werde ich mir mal anschauen.


    In der Regel kennt der Geos User ja meistens die Programme mit denen er startet. Wenn nicht, hat er einmal einen Systemabsturz. Danach weiss er ja dann Bescheid und könnte es z.B. im Infoblock des Programms hinterlegen. :)

    Nachtrag: Habe geschaut und bin begeistert. Habe die Einstellung in Geodos schon mal gesehen, aber irgendwie verdrängt. Also, einfach bei Problemprogrammen, nur Geos 64 oder Geos 128 wählen und speichern. Keine Probleme mehr. Super. :)


    Guß Jojo

    Zitat von spacer

    Wo gibt es bitte das GEOS 2.5 IMG für dieses Experiment hier?

    Das sind keine Experimente :D
    Findet sich in der Wolke => /Software/Geos/System/Deutsch => GEOS64_V2.5_DE_uninstalliert.7z


    Wobei ich das ältere GEOS64_V2.01_M&T_DE_uninstalliert.7z verwendet hab.


    Je nachdem was und wie Du wo installieren willst... hier die Anleitung für TC64-StandAlone. Den aktuellen TopDesk für hinterher gibt es irgendwo hier.


    P.S. An dieser Stelle noch der Hinweis für das TC64, das ja auch die Möglichkeit bietet den REU-inhalt zu speichern/zu laden, das eine 1541-Disk mit RBOOT*/RBOOT.BOOT-Dateien ausreichend sind um nach dem laden des REU-Inhaltes GEOS wieder aus der REU zu starten. Das dauert dann nur 1-2sek.

    Kleine Rand-Notiz:
    Unter MegaPatch64 gibt es einen Bug in der ToBasic-Routine. Aktuell kann man keine BASIC-Programme starten.


    Der Bug ist mir aufgefallen als ich die "GEOS beenden"-Funktionen in meinen neuen GeoDesk eingebaut hab und die BASIC-Programme einfach nicht starten wollten. Auch das ist ein 20.Years-Bug da in der Symboltabelle "SymbTab64" die Adresse "VARTAB" falsch definiert ist (IST: $002b, SOLL: $002d).
    Außerdem wurden der Puffer für Befehle und Tasten nicht korrekt gesetzt. Daher wurden auch BASIC-Befehle nicht korrekt ausgeführt.


    Daher kann auch DualTop keine BASIC-Programme starten. Das ist für mich ein echter BUG der jetzt ein MegaPatch 3.3r5 nach sich zieht.
    Werde das aber erst noch etwas testen...


    Nur so zur Info: GeoDesk macht kleine Fortschritte... Neuer Dateifilter, AppLinks funktionieren, Drucker/Eingabegerät wechseln klappt, Hintergrundbild ein/aus, Einstellungen speichern, Dokumente öffnen,... so langsam ist der Kern komplett und ich kann mich der Partitionsauswahl und den Disk-/Datei-Funktionen widmen. Erster SnapShot folgt evtl. mit MP64 3.3r5.

    GEOS MegaPatch 64/128 V3.3r5 released...


    Hab jetzt fast 6h damit verbracht die Versionen zu kompilieren und die Release-Disks zusammenzustellen. Ich hoffe mal das hat alles funktioniert...


    Gab seit r4 nur drei Bugs... CMD-HD+PP-Kabel = Falsche Disk-Größe im Editor bei NativeMode, C128/Editor und Systemlaufwerk wechseln sowie den ToBASIC-Bug (Nur MP64)... Wer sonst keine Probleme hatte kann auch bei v3.3r4 bleiben.

    Hallo @darkvision,


    habe mal eine Frage:


    Die 4 Laufwerks-Icons A: B: C: D:, die man z.B. in Dialogboxen (z.B. "Neues Dokument erstellen") einsetzen kann, sind die Daten dazu (die Grafiken) irgendwie für den Programmiere erreichbar?


    Hintergrund: In TD 128 sind sie auch als Grafiken vorhanden. Da Pusti64 aber immer nach Platz sucht ;-) wollte ich vorschlagen, die GrafikDaten direkt aus dem Kernel zu nehmen. Da müssen sie ja irgendwo vorhanden sein. Habe auf die Schnelle nichts gefunden......


    Danke.


    Gruß
    Werner

    Zitat von wweicht

    Die 4 Laufwerks-Icons A: B: C: D:, die man z.B. in Dialogboxen (z.B. "Neues Dokument erstellen") einsetzen kann, sind die Daten dazu (die Grafiken) irgendwie für den Programmiere erreichbar?

    Die Icons liegen in einer externen Routine im GEOS-DACC-Speicher und werden von DoDlgBox in den Speicher geholt wenn die Icons benötigt werden. Glaube nicht das sich dadurch was sparen lässt...

    P.S. Warum schmeißt man nicht diese GEOS->Info-Box raus? Wer ließt sich das schon durch? Ich würde da ein geoWrite-Dokument mit dem Text auf die Disk packen, da könnte man dann auch die Veränderungen auflisten.


    Das spart dann etwas Code (DoDlgBox) und den Code für die DialogBox selbst.


    Weiß aber nicht ob der Code dafür an einer Stelle liegt wo man auch was damit anfangen könnte.

    Zitat von darkvision

    Die Icons liegen in einer externen Routine im GEOS-DACC-Speicher und werden von DoDlgBox in den Speicher geholt

    Danke.


    War ja nur eine Idee ;-) . Wenn es nicht so einfach ist, müssen wir woanders suchen ........
    Gerade die 4 Icons (Grafik-Daten) wären ideal gewesen. Das sind 132 Bytes die auch noch direkt hintereinander liegen.

    Zitat von darkvision

    Das spart dann etwas Code (DoDlgBox) und den Code für die DialogBox selbst.

    Naja, die Info-Box wurde ja schon drastisch gekürzt und wird wohl noch weiter gekürzt werden. Da sowieso niemand Anleitungen und Texte liest, besteht zumindest die theoretische Change, das da mal einer draufklickt und so erfährt, wer das Teil programmiert hat ..... ;-)


    Gruß
    Werner

    Ich hab so den Verdacht das es ein Problem mit dem SuperMouse-Treiber von MegaPatch64 und dem TC64 gibt.


    Ich hatte ja am C64 schon länger den Tom+-Adapter mit USB-Maus im Einsatz. An der SuperCPU war alles OK.


    Jetzt, mit dem TC64 und Tom+ hat die Maus ständig rumgezickt... 10-20 Pixel hoch/links/rechts/runter... der Mauszeiger hüpft wild herum.


    Ich hatte zuerst den Tom+-Adapter im Verdacht, aber es ist wohl eher der Maustreiber.


    Ich hab jetzt den MicroMysV5 und da zuckelt die Maus genauso, egal ob PS/2 oder USB-Maus.


    Takte ich das TC64 auf 1MHz runter ist das ruckeln kaum noch sichtbar. Der Maustreiber hat auch Code der die SCPU auf 1MHz kurzzeit heruntertaktet. Das geht mit dem TC64 auch, das setzt dann aber das $d030-Bit voraus (Siehe Turbo-Options im TC64).
    Das passt auch zum Code wo ich vor 20Jahren einen Kommentar hinterlassen hab, das es eine Warteschleife erfordert, um bei Verwendung einer SuperCPU ein "zittern" des Mauszeigers zu vermeiden.


    Ich werde bei Gelegenheit mal versuchen das noch in den Treiber einzubauen. Es wäre allerdings schöner wenn das auch ohne das $d030-Bit funktionieren würde. Evtl. Timer abfragen? Mal sehn...

    Ich hab den Treiber SuperMouse64 jetzt soweit umgebaut das er auch beim TC64 den Takt auf 1MHz zurücksetzt. An meinem C64+TC64v2 klappt das jetzt mit dem Tom+-Adapter als auch mit dem MicroMysV5 soweit ganz gut... zumindest kein Zittern mehr. :lol23:


    Der Tom+-Adapter mit meiner USB-Maus (Inateck/Beleuchtet) funktioniert jetzt perfekt. Auch das Tempo ist ganz angenehm.


    Mit dem MicroMys hab ich eine PS/2-Maus von Perixx getestet. Die ist auf jeden Falls etwas flotter unterwegs und bei sehr schnellen Bewegungen springt der Mauspfeil trotzdem noch etwas. Ich hoffe mal das liegt an der Maus. Hab leider keine andere PS/2-Maus um das zu testen und die Inateck-USB-Maus geht mit USB/PS2-Adapter nicht am MicroMys.


    Mit einer C=1351 tritt das Problem auch auf. Mit dem neuen Treiber funktioniert auch die 1351 an meine C64 ganz gut, nur etwas langsam. Aber dafür gibt es ja die CTRL-Taste für den DoubleSpeed :D


    Mit der CMD-SmartMouse kann ich es nicht mehr testen, die mag grundsätzlich nicht mehr.


    Für Nutzer ohne TC64 bringt der neue Treiber keine Änderung, der alte Treiber kann daher weiter verwendet werden. Wer keine Probleme mit einem zitternden Mauszeiger mit dem TC64 hat braucht den Treiber auch nicht auszuwechseln...


    Ich hab den Treiber auf das D64 im Anhang gepackt.


    P.S. Ich hab den Treiber eben auch mit GEOS64 V2.0 getestet. TC64-Anwender die nur GEOS2.x einsetzen können den Treiber daher auch verwenden.

    How does the MP3 recognizes SD2IEC? Till now I was using a 'cableless' SD2IEC device (initial status message: 73, SD2IEC V1.0.0ATENTDEAD0-24,00,00) as a boot device - I boot it from DNP image. I moved the SD card to another unit (petSD+ unit, 73,NODISKEMU V1.0.0ALPHA-20181028-12B2387,00,00), assigned it the same drive number, but GEOS MP3 no longer boots, it stops at the white-gray grid without any error message, desktop background is never displayed. After switching back to 'cableless' SD2IEC unit GEOS boots again.

    Zitat von FeralChild

    I moved the SD card to another unit (petSD+ unit, 73,NODISKEMU V1.0.0ALPHA-20181028-12B2387,00,00), assigned it the same drive number, but GEOS MP3 no longer boots, it stops at the white-gray grid without any error message,

    The petSD+ is untested with Geos and MP3. I don't have a petSD+. Maybe a firmware problem .....


    Zitat von FeralChild

    How does the MP3 recognizes SD2IEC?

    I think, this must be answered by darkvision ;-) .


    Bye

    Werner

    MP3 does send a "M-R"-command to the device. The SD2IEC replies always with "00, OK, 00, 00" (M-R is not supported) while a real device like a 1581 reports some memory data.


    How is the SD2IEC configured? As 1541/71/81? If so you need the M-R-Emulation on the SD2IEC. Unsure if the petSD+ supports a similar feature.


    Also the SD2IEC in 1541/71/81/Native-mode uses the original GEOS turbodos. This is simulated by the SD2IEC-firmware. If this support is not included in the petSD+ firmware then this will not work.


    If the petSD+ does not reply with "00, OK..." MP3 will think this is a real drive and may use the 1581 disk driver where you need the M-R-emulation.


    If the drive is configured with SD2IEC-native-driver you don't need the M-R-emulation but without the correct response to M-R it will not be detected.


    P.S. Are SD2IEC and petSD+ using the same disk mode and same disk-id? You can not boot from drive #8 , put the disk in drive #9 and boot from this drive without using MakeBoot on this drive. Makeboot will make the disk bootable for the selected device/drive/id only.