last post from darkvision at the
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?
Arndt
Ist glaube ich ein bekanntes Problem... hat mich bei MegaPatch am Anfang auch gewundert. Wenn ich das teste nehme ich SCPU+RAMCard+GeoRAM... sonst C64+GeoRAM+REU.
In der Tat ein bekanntes Problem. Einzig die Frage ist, ob das irgendwann mal gegenagen gegangen hat.
In der Tat ein bekanntes Problem. Einzig die Frage ist, ob das irgendwann mal gegenagen hat.
Mist! Wo kann ich denn dazu was nachlesen? Vielleicht auf der VICE-Seite?
Arndt
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
Ich hatte gehofft, dass ich die Vorteile der REUs auch unter SuperCPU-Verhältnissen mit GoDot nutzen kann.
Ich schalte in VICE/x64 den WARP-Modus an. Hab meine Version auch so gepatched das ich auch 1000% angeben kann. Dann steigt zwar reSID aus, aber ab&zu sehe ich dann da auch %-Werte von um die 6000-7000%. Da braucht es keine SCPU mehr. Ja, dann geht die Uhr falsch... aber das nehm ich in Kauf.
Mit der VICE/SuperCPU-Version teste ich nur noch ganz selten.
Und eine echte SCPU kann sich ja kein Mensch leisten...
Das muss man heute ja auch nicht mehr, gibt ja Alternativen...
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
Also ich bin ziemlich sicher, dass die CBM-REU in xscpu64 schon mal funktioniert hat. Ist aber schon länger her und ich kann nicht sagen, welche REU-Größe damals unterstützt wurde....
Gruß
Werner
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
Gibt es irgendeine programmtechnische Möglichkeit, von einem laufenden Programm aus zu erkennen, ob es auf einem Emulator läuft?
Nur wenn der Emulator einen Bug hat.
Es gab hier mal den Hinweis auf $dfff, wo %10101010 drinstehen soll. Tut's bei mir nicht (VICE 3.1).
Dafür muss das Emulator Identification-"Cartridge" aktiviert sein.
Also ich bin ziemlich sicher, dass die CBM-REU in xscpu64 schon mal funktioniert hat.
habe es gefunden:
Es war wohl die erste Version mit SCPU-Unterstützung. Zu finden ist sie hier: http://www.zimmers.net/anonftp…VICE/WinVICE-2.4-SCPU.zip .
Zumindest das aktuelle MegaPatch3 64 konnt ich damit problemlos mit CBM-REU (16 MB) installieren und nutzen. Ist nur schon ganz schön alt ....
Gruß
Werner
Keine Ahnung, wann ich dazu komme. Aber das eröffnet die Chance, falls sich die Version als Tag zumindest so etwa in der Versionsverwaltung wiederfindet, mal zu suchen, welcher Commit eigentlich den Fehler einführt. Mit etwas Glück verrät er etwas über die Ursache. Und mit noch mehr Glück passt das auch heute noch.
Dafür muss das Emulator Identification-"Cartridge" aktiviert sein.
Was ist das denn?
Arndt
Was ist das denn?
Das ist ein irgendwann 2010 oder 2011 rausgeworfenes Ding, um von einem im Emulator laufenden Programm heraus festzustellen, ob und in welchem Emulator das Programm läuft. Rausgeflogen ist es, weil sowas dem Ziel widerspricht, ein echtes System möglichst gut nachzubilden, damit Programme erst gar nicht wissen müssen, ob sie im Emulator laufen oder nicht.
Es war wohl die erste Version mit SCPU-Unterstützung. Zu finden ist sie hier
Hängt nach einiger Zeit ebenfalls. 
Ding, um von einem im Emulator laufenden Programm heraus festzustellen, ob und in welchem Emulator das Programm läuft
Und wo gibt's das?
Arndt
Gibt es irgendeine programmtechnische Möglichkeit, von einem laufenden Programm aus zu erkennen, ob es auf einem Emulator läuft?
Keine 100%-ige. Man kann aber 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.
Beim P64 Image einer Diskette würde es nicht klappen. Aber zum einen benutzt fast keiner P64, zum anderen hat P64 leider noch Bugs.
Edit: Dazu sollte man aber sicherheitshalber einen Sektor der Speedzonen 3 oder 0 nehmen.
Und wo gibt's das?
Welcher Teil von "rausgeworfen" war unklar?
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!
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...
