VirtualC64 4.0 ist fertig

Die Site http://www.dirkwhoffmann.de/virtualc64/ ist aber nicht mehr aktuell bzw. spiegelt nicht mehr den aktuellen Stand wider? Also nur noch die Github-Seite?

Ich hab zwar einige aktuellere Aspekte auf der C64-Wiki-Seite berücksichtigt, aber da ist natürlich noch etliches an Luft nach oben ... vielleicht könnten Mac-User hier mitwirken und Informationen anreichern bzw. korrigieren.

Was ich auf die Schnelle nicht gefunden habe, sind die Systemvoraussetzungen. Ich habe relativ schnell sehen können, dass Version 4 wohl eine Universal-Binary ist und Apple ARM CPUs unterstützt (Metal ja schon viel länger) aber welche OS-Version benötige ich z.B. mindestens?

Ok, hab die Wiki-Seite noch etwas angepasst. Gäbe es so einen Quick-Guide für CLI oder was alles für einen Schnellstart notwendig ist?

Hat jemand Bildmaterial, das man auf die Wiki-Seite nehmen darf? Oder vielleicht mit Erlaubnis des Autors gleich jene von dessen Github-Seite)?

Zitat von dirkwhoffmann

Das "deployment target" ist in Xcode auf 10.14 gesetzt (Mojave)

Ich bleibe wahrscheinlich noch länger auf 10.13.x (High Sierra) – wegen der 32-Bit-Kompatibilität.

Nun zu etwas Technischem: Ich habe mir die CPU-Emulation ein bisschen angesehen, https://github.com/dirkwhoffma…r/CPU/CPUInstructions.cpp

Bei der BCD-Arithmetik ist mir aufgefallen, dass bei ADC und SBC die Flags Z, N und V so gesetzt werden, als wären es keine BCD-Operationen. Nur der 6502/6510 setzt die Flags im BCD-Modus eben nicht richtig (soweit ich weiß wird nur C korrekt gesetzt). Erst die WD 65C802/816 machen es richtig, weswegen die CPU-Erkennung an dem auch scheitern dürfte. Die geht nämlich so:

Soweit ich das sehe würde der Code beim Emulator einen 802/816er erkennen.

Bei PLA dachte ich erst, dass die Flag-Behandlung nicht stimmt. PLA setzt nämlich das Z- und N-Flag entsprechend dem vom Stapel geholten Wert. Im Kommentar zum PLA-Befehl steht es jedenfalls falsch. Aber glücklicherweise verwendet PULL_A das Makro LoadA und das setzt implizit Z und N richtig.

Ich hab das in meiner Grafikerweiterung einige Male in Verwendung ...

Kommt auch im BASIC-Interpreter vor, z.B. bei $A45F oder bei $A9C1 ... da wär das wohl auch unangenehm aufgefallen.

Somit passt es also, nur die Doku im Source stimmt nicht ganz.

Zitat von dirkwhoffmann

Vielen Dank für den Hinweis in Bezug auf die BCD-Flags! Dass man daran erkennen kann, ob ein WD65C verwendet wird oder nicht, wusste ich gar nicht. Ich habe mir erlaubt, Deinen Eintrag in einen Bug-Report zu "verwandeln", damit er nicht verloren geht :

https://github.com/dirkwhoffmann/virtualc64/issues/639

Wunderbar, danke. Ich hab das nicht gleich selbst als Bug-Report gemeldet, weil ich mir nicht sicher war, ob das rein aus dem Source-Code-Review ausreichend ist, zumal ich das auf dem Emulator weder beobachtet noch getestet habe.

Ich kann leider nicht sagen, wie die Flags N, Z und V tatsächlich entstehen (falls sie überhaupt verändert werden was ich vermute). Vermutlich hat das jemand schon für alle möglichen Eingabewerte einmal gemacht ... oder schauen wie das andere Emulatoren machen (was vielleicht nicht so sportlich ist).

Futter für meinen neuen M1 Mac .

Nur ein System auf dem Archon, Fort Apocalypse und BlueMax läuft, ist ein ernstzunehmendes System.

Und Jetzt habe ich wieder ein perfekt abgestimmtes 64er System und das dazu noch frei von Microsoft und Intel. Mit dem Dark-Mode und dem perfekt abgestimmten eleganten Design der Benutzeroberfläche fühlt es sich unheimlich gut an. Fast so wie damals vor 36 Jahren.

Danke Dirk !

Zitat von dirkwhoffmann

Das "deployment target" ist in Xcode auf 10.14 gesetzt (Mojave)

Nochmal dazu: kannst du es evtl. mal auf High Sierra (10.13) setzen? ich würde die neueste Version auch gerne ausprobieren.

dirkwhoffmann

Wie wäre es mit REU Support? Für sowas hier im Browser

Dann singt Dir auch Heino n Ständchen *g*

Thank you so much anyway

Zitat von dirkwhoffmann

Das Feature wurde nicht implementiert, da die GeoRam-Erweiterung im Wesentlichen das Gleiche kann, aber viel einfacher zu implementieren ist. Die REU verwendet DMA und wäre nur mit viel Aufwand umzusetzen.

Gäbe es ein Workaround um REU dann trotzdem mit nem Trick im Emu abzuspielen?

Zitat von dirkwhoffmann

Nein, ich denke nicht. Die Programmierung der REU ist sehr unterschiedlich im Vergleich zur GeoRam:

https://www.retro-programming.…-know/reu-programmierung/

Klar, der Support der REU wäre schön, er steht in der Prioliste aber ganz weit unten, da es nur wenige Titel betrifft und der Aufwand immens wäre.

Ok - wobei REU Support ein geiles Alleinstellungsmerkmal für nen C64 Emu im Browser wäre. Mir ist zumindest keiner bekannt, der das kann.

Zitat von dirkwhoffmann

Klar, der Support der REU wäre schön, er steht in der Prioliste aber ganz weit unten, da es nur wenige Titel betrifft und der Aufwand immens wäre.

Ich kann das gut nachvollziehen. Von einigen wenigen Anwendungsprogrammen abgesehen, benötigt doch fast keine Software eine REU – Spiele schon mal gar nicht. Für mich fällt VirtualC64 dadurch eigentlich nur für die GEOS/MP3-Herumspielerei flach (da wird oft von REU gesprochen und ich weiß nicht, ob eine GEO-RAM (trotz ihres Namens) gleiche Dienste leisten kann) aber ansonsten bringt die fehlende REU-Emulation für mich keine Nachteile mit sich. Nuvie-Videos sind meines Erachtens, wenn überhaupt, nur auf echter Hardware eine Show – in einer Emulation kann die Video-Abspielfähigkeit ja "irgendwo" herkommen und somit ist der Überraschungs-Effekt ohnehin gleich Null.

Ich hatte eben nochmal versucht, die Version 4.0.1 zu öffnen. Leider liegt meine Betriebssystem-Version eine Version vor der verlangten. Gibt es einen Grund, dass VirtualC64 macOS Mojave als Minimum voraussetzt?