Posts by GoDot

    Update:


    Alle Module, die mit Clips arbeiten, stellen jetzt nach Beendigung ihrer Aufgabe den Renderbereich auf jeden Fall auf Full (das spart einen Klick für das Anschauen des Ergebnisses und einige weitere, wenn man an diesen Klick nicht gedacht hat :-) ). Betroffen sind zusammen acht Modifier.


    Arndt

    So, fertig (und im Download bereits vorhanden). NewPointer ist so sehr überarbeitet, das ich ihm die Versionsnummer 2.00 verpasst habe:


    mod..NewPointer


    zum Bearbeiten von GoDot-Mauszeigern. Hier nochmal ein Screenshot, der zeigt, dass das auch farbig geht mit den Mauszeigern! :-)



    Arndt

    Danke für den Hinweis! Sollte das irgendwo bei der Erstanmeldung mal erwähnt werden? Oder kann die Standardeinstellung auf Berlin geändert werden?


    Arndt

    Damit keiner meint, ich wäre untätig:


    Ich beschäftige mich gerade damit, mod..NewPointer etwas zu verbessern. Aus einem bisherigen reinen Lader wird jetzt ein (relativ einfacher) Mauszeiger-Editor. Bis auf die Scroll-Funktion ist er fertig. Bei der Gelegenheit hab ich auch das Dateiformat für Mauszeiger "durchgestylet"... :-)



    Arndt

    Hallo zusammen,


    die Uhrzeit im Wiki ist wieder falsch, ihr seid noch auf Sommerzeit eingestellt! Ist da kein Automatismus drin?

    :syshack:


    Arndt

    Mehrere Updates im Zusammenhang mit der Einbindung von SuperCPUs:


    Booter 1.46 (im Link werden die Änderungen am Booter aufgezählt)

    mod..REUTool 2.00 (gibt auch SuperCPU-Infos)

    god.main (Kernel) 1.35 (die Änderung am Kernel ist im letzten Satz erklärt: man kann jetzt die Directory-Augabe mit STOP unterbrechen)


    Alle Updates bereits im Download enthalten (aber nicht im d81, bitte auf Github selbst erzeugen).


    Arndt

    dass das eine sehr alte Version und nicht fehlerfrei ist

    Für meine Zwecke ideal! Meine GoDot-Anpassungen an die SuperCPU sind fertig (hier nachzulesen). Wer also eine SuperCPU sein Eigen nennt (oder sie emuliert, aber bei VICE besser ohne REU-Einbindung, hehe...) kann jetzt mit GoDot gewohnt schnell auf seine Module zugreifen, mit der zusätzlichen hohen Arbeitsgeschwindigkeit einer SuperCPU!


    Danke für eure Hilfe!


    Arndt

    Welcher Teil von "rausgeworfen" war unklar?

    Oh! Rausgeworfen aus VICE?! Verstehe! :-)


    einen Sektor, sagen wir mal Track 1 Sektor 0 von der Floppy einmal mit Speedzone 3 und einmal mit Speedzone 0 lesen. Wenn beides ohne Fehler klappt (und das klappt derzeit in quasi allen Emulatoren mit d64 und g64 Images), dann ist es ein Emulator.

    Hm. Zu umständlich. Es geht einfach darum, dass GoDot eine erkannte REU beim Booten mit (beliebig vielen) Modulen beschreibt, die dann im Betrieb schnellstmöglich eingebunden werden können. Bei der aktuellen Version hängt VICE beim allerersten Schreibzugriff, bei der Version, die Werner aufgetrieben hat, ist dann nach zwei bis drei erfolgreichen Lade- (und Schreib-) Vorgängen Schluss. Immerhin. Wenn es was mit Timing zu tun hat, war es früher mal günstiger eingestellt.


    Edit: Ich hab's gerade noch mal ausprobiert. Diesmal wurden alle 25 Module anstandslos geladen! Auch alle weiteren Schreibvorgänge in die REU (1750) - wie z.B. Undo - funktionieren! Darum: Allerbesten Dank an Werner! Du hast mir einen großen Dienst erwiesen! :-)


    :thnks:


    Arndt


    Und als Dankeschön ein Bild, das ich eben (aus vorhandenem Material) gebastelt habe, um zu zeigen, wie ich mich gerade fühle: Wie im Himmel! :-)



    Hehe... ;-)

    Dann hab ich eine Zusatzfrage:


    Gibt es irgendeine programmtechnische Möglichkeit, von einem laufenden Programm aus zu erkennen, ob es auf einem Emulator läuft?


    Es gab hier mal den Hinweis auf $dfff, wo %10101010 drinstehen soll. Tut's bei mir nicht (VICE 3.1). Kann man irgendwas künstlich erzeugen, das sich dann im Emulator anders verhält als auf dem Realthing? Manche Spiele laufen auf Emus doch nicht, das hat doch sicher hierfür ausnutzbare Gründe?


    Arndt

    ich kann nicht sagen, welche REU-Größe damals unterstützt wurde....

    Ich hatte eine Größe von 512K eingestellt, also eine Standard-1750. Lesezugriffe klappen anstandslos, der erste Schreibzugriff beendet xscpu. Reproduzierbar und exakt lokalisierbar (Bank 4, Byte 0).


    Arndt

    Da braucht es keine SCPU mehr.

    Ich finde es ganz schön, wenn ich GoDot auch ohne Warp in Blitzgeschwindigkeit arbeiten sehe. Aber ohne REU-Unterstützung ist doch eine ganz wichtige Eigenschaft abhanden. Schade eigentlich! Eine Anwendung, durch die die SuperCPU an Nützlichkeit gewinnen würde.


    Und einen GoDot-Treiber für das SuperRAM zu schreiben, lohnt sich in meinen Augen nicht. - Aber, wer weiß, was mir noch so alles in den Sinn kommt... ;-)


    Arndt

    Bug #417 bzw. #434 ... ist schon etwas älter.

    Ah, danke für den Hinweis. Jetzt weiß ich wenigstens, dass der Fehler nicht bei mir liegt. Trotzdem: Ich hatte gehofft, dass ich die Vorteile der REUs auch unter SuperCPU-Verhältnissen mit GoDot nutzen kann. Mit diesem Fehler ist für GoDot jedenfalls der Geschwindigkeitsvorteil der SCPU dahin. Dann lieber auf x64 laufen lassen, das geht wesentlich bequemer als mit SuperCPU. Und eine echte SCPU kann sich ja kein Mensch leisten...


    Arndt

    Kann einer das bestätigen:


    Bei mir stürzt VICE (xscpu 3.1 unter Win10, SuperRAM ausgeschaltet) bei Schreibzugriff auf das RAM einer REU (die Register machen kein Problem) komplett ab! VICE friert ein, der Windows-Mauszeiger hat den Schlafkringel und nach ein paar Sekunden verschwindet VICE aus dem System, als wär es nie dagewesen. Die Geschwindigkeit der SCPU spielt dabei keine Rolle, bei Slow und Fast das gleiche Ergebnis.


    Ist das ein VICE-Problem oder mach ich was verkehrt?

    :kaputt


    Arndt