GEOS mit Ultimate 64 Turbo Modus (Technische Diskussion)

Es gibt 47 Antworten in diesem Thema, welches 3.344 mal aufgerufen wurde. Der letzte Beitrag (27. August 2025 um 16:37) ist von uwe1972.

  • Der SuperCPU Registersatz hilft Dir nichts, denn sobald Dein Code meint, eine SuperCPU zu erkennen, lädt es 65C816 Code fr den Zugriff auf das SuperRAM. Und das passt ins FPGA nicht rein, eine 65C816 wird die Ultimate nie nachmachen können. Ergo schaden Dir die SuperCPU Register nur, es ist gut, dass man die abstellen kann. Und daher sind die auch bei allen abgeschaltet, die Geos MP3 / GDOS verwenden.

    Und der 65C816 Code crashed bereits sehr schnell auf einer 6510.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von markusC64 (10. August 2025 um 15:01)

  • controlport2 syshack Von löschen halte ich nichts, aber auslagern im extra Thread, damit es nicht offtopic wird, das wäre doch eine gute Idee. WÜrdest Du das machen

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von markusC64 (10. August 2025 um 19:50)

  • Ich mache das gerne.

    Aber - wie ich schon so oft deklariert habe... bitte nennt die Postings und einen passenden Titel für den neuen Thread.

    Ich bin nicht im (Technik-)Thema und kann das nicht beurteilen.

  • Vorschlag meinerseits:

    988 bis 1008 verschieben

    Da das Off Topic dann gelöst ist, kann aus 1007 dann die Löschandrohung durchgestrichen werden, denke ich. Im neuen Thread wäre die Diskussion dann ja völlig On Topic, und keiner muss drauf antworten, wenn er nicht möchte.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Jetzt noch ein passender Titel und dann geht's ab hier! ;)

  • Bin ich momentan, der ezoge, der dazu was sagen will?

    Okay, ein Vorschlag:

    Geos MP3 & GDOS64 mit Ultimate 64 Turbo Modus (Technische Diskusion)

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Jetzt gibt es den eigenen Thread.

    Habe die letzten Posts mit rüber genommen, dann bleibt der Zusammenhang bestehen.

  • Geos MP3 & GDOS64 mit Ultimate 64 Turbo Modus (Technische Diskusion)

    Jetzt gibt es den eigenen Thread.

    Habe die letzten Posts mit rüber genommen, dann bleibt der Zusammenhang bestehen.

    Danke euch beiden. Bitte noch den Rechtschreibfehler korrigieren, dann haben wir es (Diskusion -> Diskussion). :emojiSmiley-06:

  • Hab jetzt mal auf 3 MHZ "Runtergetaktet" er ist noch schnell, und der Mauszeiger steht still.

    ab 4 MHZ geht das "Gezapple" los...........

    Aber ich denke mal, das wird wohl bald behoben werden..............

    Ich habe bereits einen Man vor Ort, die Sache wird erledigt werden, so wie immer.............

  • Mal meine 5 Cent dazu: Ich prüfe bei meinem BBS Code, welche Hardware verwendet wird und reagiere darauf entsprechend. D.h. auch beim GEOS Mouse Treiber müsste dann auch auf U64 Hardware geprüft werden, damit das nicht mit einer SCPU verwechselt wird. Es spricht ja wahrscheinlich nichts dagegen, dass dafür vom User verlangt wird, das UCI aktiv sein muss.

    Beispiel Auszug aus meinem Code:

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Jetzt gibt es den eigenen Thread.

    controlport2 : Könntest Du den Titel noch ändern in

    "GEOS mit Ultimate 64 Turbo Modus (Technische Diskussion)"

    Das Problem existiert schon seit GEOS 2.0 und dem erscheinen der SuperCPU, ist also nicht MP3/GDOS64 spezifisch, sondern GEOS allgemein.

    Zum Thema:

    Das Problem dürfte in GEOS die Tastaturabfrage und die Mausabfrage sein. Ich hab im C64-Wiki das hier gefunden:

    Zitat

    In theory, reading the "position" of paddles is as easy as reading byte values from the SID registers at 54297-54298, but to allow for a total of four paddle knobs/potentiometers, the C-64 hardware uses a multiplexer to "switch" between the two control ports. And this complicates matters a bit.

    The two most significant bit lines in port A of CIA-1 are used to "tell" the multiplexer which of the joystick ports to connect with. At the same time, these lines are involved in the scanning of the keyboard matrix, and so gets manipulated constantly as the computer scans for keypresses. So reliably reading the paddles implies temporarily disabling the keyboard scan as the reading takes place.

    The SID measures the two analog inputs once per 512 machine cycles, or about 1950 times a second, independent of (and thus asynchronous with) the timing of the program the CPU is running, i.e. when the program commands the multiplexer to switch to the other port. So the programmer has to "assume" that the keyboard scan and/or other activities have recently caused the multiplexer to switch ports, set up the multiplexer and disable anything that may interfere with it, then wait for 512 machine cycles to allow the SID to do a full reading, before finally reading the analog input register.

    Interessant ist der letzte Abschnitt, daher übersetze ich den mal (mit DeepL):

    Zitat

    Der SID misst die beiden analogen Eingänge einmal pro 512 Maschinenzyklen, also etwa 1950 Mal pro Sekunde, unabhängig vom Timing des Programms, das die CPU ausführt (und somit asynchron dazu), d. h. wenn das Programm den Multiplexer anweist, zum anderen Port zu wechseln. Der Programmierer muss also „davon ausgehen”, dass der Tastatur-Scan und/oder andere Aktivitäten kürzlich dazu geführt haben, dass der Multiplexer den Port gewechselt hat, den Multiplexer einrichten und alles deaktivieren, was ihn stören könnte, dann 512 Maschinenzyklen warten, damit der SID eine vollständige Lesung durchführen kann, bevor er schließlich das analoge Eingangsregister liest.

    Das passt zum aktuellen "Fix" im Maustreiber, das nach der Tastaturbehandlung und setzen von PortBitte melde dich an, um diesen Link zu sehen. den Treiber in den 1MHz-Modus schaltet, etwas wartet, und dann zurück in den Turbo-Modus wechselt. Dann liest der Treiber die Paddles aus und "bewegt" den Mauszeiger.

    Wenn das nicht gemacht wird, dann wird während der Tastaturabfrage ggf. der Multiplexer dazu veranlasst den Port zu wechseln. Wenn dann der Maustreiber abgefragt wird, dann wechselt der zwar zurück auf den MausportBitte melde dich an, um diesen Link zu sehen., aber ohne die Verzögerung ist der SID noch nicht bereit und ließt ggf. die Paddles von anderen Port.

    Ich hatte zum testen mal den GEOS-IRQ komplett ausgesetzt und nur den Maustreiber abgefragt. Dann war das zittern beim TC64 mit 10MHz verschwunden. Dann geht zwar auch keine Tastatur, aber wenn der Port nicht "gewechselt" wird, ist für den SID immer PortBitte melde dich an, um diesen Link zu sehen. aktiv, und somit sind immer die richtigen Paddles im Fokus.

    Kaum hatte ich zum testen die IRQ-Routine inkl. der Tastaturabfrage teilweise nachgebaut, war das zittern zurück.

    Das kann auch erklären warum bei der Nutzung bestimmter GEOS-Programme das Zittern beim U64 nicht auftritt, nämlich dann wenn der IRQ-Vektor manipuliert wird und so der zeitliche Abstand im Kernal zwischen Tastaturabfrage und Mausbabfrage vergrößert wird. Und ja, das ist möglich, da die IRQ-Aufgaben von GEOS über einen Vector ausgeführt werden, den eine Anwendung manipulieren kann. Wenn dort dann zufällig PortBitte melde dich an, um diesen Link zu sehen. gesetzt wird bevor der restliche IRQ abgearbeitet wird, dann zittert da evtl. nichts mehr.

    Wenn ich das richtig sehe müssten zwischen setzen von PortBitte melde dich an, um diesen Link zu sehen. und Mausabfrage mind. 512 CPU-Takte liegen. Aber ich vermute bei 1MHz, da es eben um den Zeitraum von 512Takten bei 1MHz geht, da der SID ja im TurboModus nicht schneller "läuft" (asynchron). Würde das auch einen virtuellen SID im U64 betreffen oder "läuft" der schneller?

    Ich hab jetzt mal meinen Sourcecode zu GEOS von 1997 angeschaut, auch im Original GEOS 2.x wird zuerst die Tastatur bearbeitet (inkl. diverser Schreibzugriffe nach $DC00 was ggf. den Multiplexer im SID dazu veranlasst den Port zu wechseln) und danach die IRQ-Routinen über den IRQ-Vector aufruft, der als erstes die Maus aktualisiert. Und da es für die SuperCPU damals einen angepassten Maustreiber gab, dürfte das damals schon über den Maustreiber, und nicht über den Kernal gelöst worden sein.

    Schön wäre es natürlich, der Kernal würde das lösen, dann müsste man die Maustreiber nicht anpassen. Der Kernal weiß aber nicht welcher Mausport aktiv ist, das regelt der Maustreiber. Es dürfte einem daher nichts anderes übrig bleiben, als den Maustreiber für das U64 anzupassen.

  • controlport2 21. August 2025 um 08:53

    Hat den Titel des Themas von „Geos MP3 & GDOS64 mit Ultimate 64 Turbo Modus (Technische Diskussion)“ zu „GEOS mit Ultimate 64 Turbo Modus (Technische Diskussion)“ geändert.
  • Gemacht. :thumbup:

    Danke :thumbup:

    In Ergänzung: Ich sehe gerade der der SuperCPU-Maustreiber aus dem Patch von MauriceRandall auf die Register D07A/B geht. Das scheint ja im Ultimate vorhanden zu sein. Es wäre also einen Versuch Wert mal den Maustreiber zu testen (dazu müsste man ggf. unter VICE eine SuperCPU mit GEOS 2.0 nutzen um den Patch zu installieren, damit man an den Maustreiber rankommt...).

  • Nö, hab ich getestet, das Zittert genauso..............:thumbdown:

    Trotzdem Danke

    Ich habe bereits einen Man vor Ort, die Sache wird erledigt werden, so wie immer.............

  • Nö, hab ich getestet, das Zittert genauso..............:thumbdown:

    Trotzdem Danke

    Danke fürs testen... ich hab nochmal genauer draufgeschaut... und der Treiber testet auch das Register $D0B8, welches die U64-Firmware nicht abbildet. Also das gleiche Problem wie bei meinen Treibern: Unvollständig integrierte Emulation der SuperCPU-Register... Firmware-Problem.

    Weil mir die Informationen aus dem C64-Wiki keine Ruhe gelassen haben, hab ich mal einen Treiber provisorisch angepasst. Und siehe da, das Feedback vom Tester ist erstmal positiv: Der Mauszeiger scheint beim U64 ruhig zu bleiben.

    Es besteht also Hoffnung... ;)

    Ich hab die Takte jetzt von bisher weit über 1000 auf 768 reduziert. Am U64 scheint es zu gehen, TC64 und SCPU muss ich noch testen. Aber die Informationen aus dem Wiki haben mir jetzt eine (für mich) plausible Erklärung für das Zittern geliefert. Von daher fließen die Infos auch in die GDOS64-Treiber mit ein. Die Treiber könnten dann auch in MP3-64 genutzt werden... ob ich die separat anpasse weiß ich nicht. MP3 ist für mich EOL. Da die Treiber auch unter GEOS 2.0 funktionieren sollten, hat sich die Fehlersuche gelohnt.

    Allerdings passe ich (wieder mal) meine Software an eine "fehlerhafte" Firmware an... ob die Treiber den Weg in das Release finden weiß ich noch nicht, evtl. gibt es eine (inoffizielle) AddOn/Treiber-Disk für das U64 bzw. den C64U.

  • Ich vermute hier liegt ein Missverständnis vor. Das U64 samt Firmware hat nicht den Anspruch die SCPU zu emulieren. Sie bietet lediglich ein paar Adressen, die es dem User / Coder vereinfachen sollen mit dem TurboMode des U64 zu arbeiten, bzw. bestehende (SCPU) Software zu nutzen. Genau wie das TC64 nicht den Anspruch auf SCPU Emulation legt.

    Ich, d.h meine Meinung, sehe das daher nicht als "Firmware-Problem" obwohl die Firmware so einige Probleme hat, besonders die Aktuelle.

    Wenn man den TurboModus des U64 als Programmierer unterstützen möchte, kommt man wohl um einen eigenen Treiber, bzw. erweiterten, bestehenden Treiber nicht herum.

    Das wäre ja bei anderen Turbo Karten wie der Flash-8 oder TurboMaster etc. auch nicht anders.

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Ich vermute hier liegt ein Missverständnis vor.

    Glaub ich nicht.

    Das U64 samt Firmware hat nicht den Anspruch die SCPU zu emulieren. Sie bietet lediglich ein paar Adressen, die es dem User / Coder vereinfachen sollen mit dem TurboMode des U64 zu arbeiten, bzw. bestehende (SCPU) Software zu nutzen.

    Ja, und genau da scheint das Problem zu liegen: Es macht es nur halbherzig was die Register angeht. Und macht es damit Programmierern unnötig kompliziert: Man muss dennoch gezielt für das U64 programmieren.

    Schon der Maustreiber von MauriceRandall testet das Register $D0B8 (Bit%7=0, Turbo, =1, Normal). In der von markusC64 verlinkten Doku wird das Register nicht aufgeführt. Laut SCPU-Handbuch "Read only with hardware registers disabled, Read/Write with hardware registers enabled, write access reserved for system only". Es dient also nur als Abfrage ob Turbo an/aus. Nichts kompliziertes, man kann damit nur vorher abfragen was aktiv war, bevor man auf $D07A/$D07B zugreift.

    Der Maustreiber verwendet dann $D07A/$D07B um den Takt auf 1MHz (Write $D07A) zu setzen oder wieder zurück auf "Turbo" (Write nur wenn $D0B8-Bit%7=0 war).

    Für $D07A/$D07B steht dort in der U64-Doku:

    Zitat

    This register is only available when the Turbo Mode selector is set to ‘U64 Turbo Registers’ or ‘Turbo Enable Bit’. This register is write only

    D.h. mit U64TurboReg oder TurboEnable-Bit hätte auch der alte Maustreiber funktionieren müssen. Zumindest das runtertakten auf 1MHz. Das zurücksetzen würde aber nur dann funktionieren, wenn in $D0B8 das Bit%7 gelöscht ist. Jetzt weiß ich leider nicht welches Bit dort steht wenn es vom U64 nicht emuliert wird. Vielleicht kann das mal jemand auslesen.

    Wenn dort z.B. $FF stehen sollte (und damit Bit%7=1=Normal ist), dann würde der Maustreiber den Takt nach der Wartezeit für den SID nicht wieder hochsetzen. Und wenn doch dann nur (laut Doku) auf 20MHz. In beiden Fällen aber dürfte die Maus nicht zittern, das runtertakten auf 1MHz sollte ja mit passendem TurboControl immer funktionieren. Der Unterschied wäre nur ob nach der Installation des Maustreibers die CPU mit 1MHz oder 20MHz läuft (statt den 48 oder 64).

    Die Maustreiber von GEOS64 kennen das "Problem" nicht (sollten immer zittern), der Treiber aus dem SuperCPU-Installer von Maurice sollte aber zumindest den CPU-Takt auf 1MHz setzen können (es wird nach $D07A geschrieben).

    Wenn mit dem alten von MP64/GD64 Maustreiber die Maus zittert, dann dürfte man die TurboControl auf "Off" oder "Manuell" gestellt haben. Vielleicht kann das ja nochmal jemand testen (TurboControl = U64TurboRegister oder TurboEnable-Bit, und MP364/GDOS64 mit den originalen MP64/GD64-Maustreibern, was passiert mit dem CPU-Takt?).

    Ich hab ja zwischenzeitlich ein Bitte melde dich an, um diesen Link zu sehen. mit angepassten Maustreibern bereitgestellt. Diese verwenden jetzt das Register $D030. Das gibt es bei der SuperCPU64 nicht, beim TC64 müsste man das in den Optionen einstellen.

    Damit passt die SID-Routine nicht mehr in den Standard-Treiber (SuperCPU +TC64 +U64 ist eine Anpassung zu viel). $D030 hat aber den Vorteil das es den CPU-Wert wieder auf die Menü-Einstellung setzt, nicht fest auf die 20MHz wie $D07B. Es erfordert aber eine noch spezifischere Einstellung in der Firmware: Es geht nur TurboEnable-Bit.

    Die neuen Treiber hätte es also vermutlich nicht gebraucht, wenn $D0B8 mit abgebildet worden wäre und der Anwender TurboControl passend setzen würde (Entweder U64TurboReg oder TurboEnable-Bit). Sollte Gideon das noch einbauen, dann müsste MP64 oder GD64 auch mit den normalen Treibern funktionieren, da diese keine Hardware-Erkennung durchführen. Diese schreiben nur in die entsprechenden Register was bei einem "normalen" C64 keine Auswirkungen haben sollte.

    Allerdings kann man die Treiber auch für GEOS64 2.x mit U64 verwenden, falls jemand es gerne "pur" hat ;)

    Also war die Arbeit nicht ganz vergeblich...

  • Wobei man aufpassen muss - die SuperCPU Register einschalten darf man derzeit keineswegs. Dann erkennt MP3 (nicht derMaustreiber!) nämlich eine SuperCPU und lädt den 65C816 Code dafür. Das kann natürlich nur nach hinten losgehen.

    Ergo: Ich würde aufd ie SuperCPU Register an der Stelle nicht unbedingt setzen wollen... Aber ja, die ein bisschen mehr echter zu haben würde definitiv auch nicht schaden.

    u. A: wegen solcher Inkopmpatibilitäten (Software entscheidet sich für 65C816 Code) kann man die SuperCPU Register inzwischen nämlich separat ein- oder ausschalten. Die Doku beinhaltet den Hinweis darauf nicht, aber die Register an sich scheinen weiterhin zu stimmen.

    ---
    Meine Github-Projekte: Bitte melde dich an, um diesen Link zu sehen. Vice 3.2 Improved: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II / Ultimate 64 Firmware Releases: Bitte melde dich an, um diesen Link zu sehen.
    1541 Ultimate II Update instructions: Bitte melde dich an, um diesen Link zu sehen.

  • Wobei man aufpassen muss - die SuperCPU Register einschalten darf man derzeit keineswegs. Dann erkennt MP3 (nicht derMaustreiber!) nämlich eine SuperCPU und lädt den 65C816 Code dafür. Das kann natürlich nur nach hinten losgehen.

    Naja... in der Doku steht:

    Zitat

    SuperCPU Detect ($D0BC)

    • SuperCPU Mode Detect Register

    This register is only available when it is separately enabled. This register is read only

    u. A: wegen solcher Inkopmpatibilitäten (Software entscheidet sich für 65C816 Code) kann man die SuperCPU Register inzwischen nämlich separat ein- oder ausschalten. Die Doku beinhaltet den Hinweis darauf nicht, aber die Register an sich scheinen weiterhin zu stimmen.

    Also wenn man das separat einschalten kann, dann lässt man $D0BC aus und die SuperCPU wird nicht erkannt. Oder verstehe ich das falsch?

    Der Maustreiber benötigt das Register $D0BC nicht. Es wird nur $D0B8 gelesen und nach $D07A/B geschrieben. Egal ob SCPU vorhanden oder nicht. Daher funktionieren die Treiber auch ohne SuperCPU mit GEOS64. Also würde TurbpoControl alleine schon ausreichen.

    Auch für meine WiC64-Tools wäre das $D0B8 praktisch, dort wird allerdings vorher auf $D0BC getestet, was ich wie beim Maustreiber auch weglassen könnte. Das stammt noch aus den Anfängen, wo es darum ging auch mit 20MHz Dateien zu übertragen und die TimeOut-Zähler dann entsprechend angepasst werden mussten. Braucht es jetzt aber nicht mehr da ich generell auf 1MHz runtertakte.

    Für Uwe hab ich zwei kleine Helfer geschrieben, die per Mausklick auf 1Mhz schalten bzw. auf die Menüeinstellung zurück gehen. Damit kann man meine WiC64-GEOS-Tools auch mit dem U64 nutzen und hinterher wieder den CPU-Takt hochschalten ohne mit den Buttons herumspielen zu müssen ;)

    Ist das $D031-Register nur "ReadOnly"? Damit könnte man für das U64 ja den aktuellen Takt und den BadLine-Modus auslesen. Aber kann man diese Werte auch dort reinschreiben um den Takt gezielt zu wechseln? Dann könnte man für Anwender ja ein Programm schreiben was, ohne das Menü aufzurufen, den Takt ändern kann (so wie bei der SuperCPU/TC64 in GD.CONFIG von GDOS64).