Beiträge von GoDot

  • GoDot Infos

    Zitat von Drachen

    Aber jetzt weiß du auf jeden Fall das man sowas braucht. :emojiSmiley-04:

    Momentan schaue ich, wie man eine True-Hires-Darstellung einerseits (Hires ohne die C64-Beschränkungen, wie es GoDot intern schon immer bietet) und andererseits eine „True Color“-Darstellung (die Pseudo-IFLI-Farben als Echtfarben, dann in 160x200) realisieren könnte. Damit wäre es erstmals möglich, die standardmäßigen GoDot-Features *direkt* auf dem „C64“ anzuzeigen! So wie z.B. das Bild aus Post #731 und eins aus dem „Heute so konvertiert“-Thread:



    Arndt

  • GoDot Infos

    Zitat von Drachen

    kann eins deiner Grafiktools aus einen PNG-Bilddatei (320x100 Pixeln und 32 Farben) ein FCM-Bild erstellen für den Mega65?

    Nein, lieber Drachen , ich fang ja gerade erst an. :-)


    Außerdem ist PNG ein ziemlich komplexes Format, da ist kein mir vorstellbarer Weg, dass GoDot mit so etwas Kompliziertem (in annehmbarer Zeit und Ausstattung) klarkommen könnte. Such dir also einen Weg ohne Stolpersteine, d.h. konvertier deine PNGs in ein anderes Format und dann wird schon irgendwie ein FCM-Konverter auftauchen, der kann, was dir vorschwebt. :|


    Oder gibt's das schon? Wie machen das denn die Leute, die auf dem Filehost die schönen Demos und Bildbeispiele gepostet haben?


    Arndt

  • GoDot Infos

    Sorry, ich hätte das von vornherein so machen müssen (aber ist ja noch früh genug)!


    Neuer Booter v1.58!


    Was ist daran neu? Ich hab die Mega65-Erkennung dahin verlegt, wo sie hingehört, nämlich in den Booter (die Startdatei "godot"). Jetzt wird allen Modulen (die es interessiert) über ein Statusbyte (sy_mega65: $2b) mitgeteilt, ob GoDot auf einem Mega65 läuft (>0) oder nicht (=0). Ich hab die Statusabfrage auch gleich in die beiden Mega65-Modifier eingearbeitet, sodass insgesamt drei Dateien neu sind.


    Alles schon online.


    Arndt


    Edit: Sources auch online. Wer 10:35 heute (13. Juni 2025) die Sachen downgeloadet hat, bitte nochmal, das REU-Management hat einen Fehler gehabt (Flüchtigkeitsfehler bei Stringlängen-Paddings). Sorry!

  • Der MEGA65-Laber-Stammtisch

    Zitat von dddaaannn

    Hot registers are relevant because FAST is on D031, and D031 participates in the hot register mechanism.

    I rewrote my GoDot modifier to act like POKE 0,65 (and 64 respectively). Since all this is WIP I will surely change it in future releases. In the meantime I will check the impact of saving $d05d.7 will have to the fast bits. ;-)


    Arndt

  • Alles über COMAL 80 V2.01 – Der ultimative Mega-Thread

    Zitat von Omega

    Was ist das für ein Programm auf dem Bild, mit dem du die Umrechnung durchführst? Ich will das sofort haben!

    Natürlich ein wunderbares TSB-Programm! :D Hier (zum Kopieren):

    In Zeile 130 musste ich die Leerzeichen weglassen, sonst passt es nicht.


    Arndt

  • Alles über COMAL 80 V2.01 – Der ultimative Mega-Thread

    Zitat von Omega

    print frequency("a0") dann kommt da 468 heraus. Außerdem kann es ja nicht sein, dass der Kammerton a in der 0. Oktave gelegen ist. Wohl eher in der vierten Oktave, also "a4". Und da liefert frequency schon 7493.

    Das ist ganz richtig, denn es wird von frequency der 16Bit-Wert ausgegeben, der in die SID-Register geschrieben werden muss, damit der Kammerton aus dem Lautsprecher kommt. In TSB:WAVE 1, 17: SOUND 1, 7493. Hier:



    $1d45 (hex) sind 7493 (dez). Und 468 müsste das tiefgestrichene A sein (27,5 Hz)


    Arndt

  • Der MEGA65-Laber-Stammtisch

    Zitat von dddaaannn

    Feel free to dig into the source and suggest something.

    I just saw that speed_sub in b65.src does the same as I do in mod.M65.Fast, except that it additionally manipulates reg $D05D to save the so called "hot reg bit". Would that solve the GoDot problem? (Still didn't find anything about POKE 0,65...)


    Arndt


    Edit: Found it in b65.src about rspeed. POKE 0,65 sets a Hypervisor flag (and 0,64 resets it) without any chance from the system to influence this bit other than via POKE 0. Ok, so I will change mod.M65.Fast to set this flag. That will do it! :-)

  • Der MEGA65-Laber-Stammtisch

    Zitat von dddaaannn

    Are you running this under the GO64 KERNAL and manipulating the CPU speed with VIC-IV registers?

    For sure! The GO64 is very much underrated in my perception of things! However, it combines the two worlds to its best: the C64 we all know and appretiate, and the Mega65 which we just learn to appreciate! And I find GoDot is the best tool to achieve this beneficient combination! ^^

    Zitat von dddaaannn

    The MEGA65 KERNAL does its own save-and-restore of the CPU speed flags before and after invoking CBDOS. The GO64 KERNAL doesn't. (See kernal64.src dos_in and dos_out.)

    Ok, good to know! But what is the difference between POKE 0,65 and setting $D031.6 and $D054.6? The former keeps the speed of the machine even while accessing disks, the latter does not! ;( Will have an immediate look at kernal64.src, though!

    Zitat von dddaaannn

    Feel free to dig into the source and suggest something.

    Wait! ^^


    Arndt (who would like to have a separate GO64-Mode board on Discord...)

  • Der MEGA65-Laber-Stammtisch

    Zitat von Goodwell

    Hm, mir ist im XEMU aufgefallen dass er von 40 auf 3,5 MHz runtergeht.

    Ja, das schwankt sogar, mal 1 MHz, mal 3,5 MHz. Ich hab die Geschwindigkeit über die beiden Flag-Bits in $d031 (VIC III) und $d054 (VIC IV) aktiviert, nicht über POKE 0,65 (wenn das verwendet wird, ändert sich nichts an der angezeigten Geschwindigkeit, sie bleibt also auf 40 MHz).


    Heißt das, dass ich tunlichst die Finger von den Flags lasse und "brachiale Gewalt" anwenden soll?


    Arndt

  • Der MEGA65-Laber-Stammtisch

    Ich stelle gerade fest, dass der Mega65 bei jedem Disk-Zugriff auf 1 MHz herunterschaltet. So weit, so gut, das macht ja auch Sinn. Aber warum schaltet er nach dem Zugriff nicht zurück in die Superspeed? Das könnte doch anwenderfreundlicher sein!?


    Wie komme ich drauf? Ich hab gerade ein GoDot-Modul zum Einstellen der Arbeitsgeschwindigkeit gebastelt. Funktioniert wunderbar:



    Ist aber unbrauchbar, denn es bringt - so wie es jetzt läuft - ausschließlich beim Rendern der Grafik was (schwupp, da ist das Bild!) Bei allen anderen zeitaufwendigen Modulen kann man das nicht gebrauchen, denn wenn ich ein Modul lade, geht die Speed auf 1 runter und ich müsste M65.Fast neu laden, um auf 40 MHz zu wechseln. Aber dann ist das Modul, das ich beschleunigen wollte, weg... :| Und eine RAM-Disk haben wir noch nicht.


    Will sagen: Wär doch schön, wenn die Maschine die Geschwindigkeit, die *vor* dem Laden galt, auch *nach* dem Laden noch hätte!


    Arndt