Aber schneller läuft er im C64 trotzdem nicht (ohne von einem echten 6502-Core wegzugehen), weil der VIC den Takt angibt (und der sich wiederum am Videostandard orientiert)
Das lässt sich ändern, das Stichwort heißt DP-RAM Dual ported RAM. Damit kann die CPU unabhängig vom VICII Takt laufen und beide haben dennoch -fast- uneingeschränkten Zugriff aufs gemeinsame RAM, das dann eben ein DP-RAM sein muss, was als Baustein schwer verfügbar ist und wenn man -um andere Probleme zu umschiffen- gleich das ganze 64KB DRAM des C64 plus das bisschen Farb-SRAM damit ersetzt auch ziemlich ins Geld geht.
Auf FPGAs hat man hingegen DP-RAM Blöcke durchaus "kostengünstig" zur Verfügung, angesichts der aktuellen Marktpreise für jegliche Halbleiter natürlich in Anführungszeichen, so richtig günstig ist aktuell ja gar nix mehr... D.h. die Systempartitionierung würde sich so verschieben, dass neben der CPU auch das RAM ins FPGA wandern würde.
Ob ein 100MHz 8-Bit Prozessor, der noch dazu im Falle der 65xx Architektur mit annähernd halbem Systemtakt aufs RAM/ROM zugreifen "möchte" um volle Leistung zu erbringen, aber von der Skalierung her noch sinnvoll ist, darüber könnte man vermutlich ewig streiten.
anderer Lösungsansatz für reale Beschleunigung (ohne FPGA und DPRAM)
OT: Ich persönlich würde einen anderen Ansatz bevorzugen, nämlich die Gleitkommaroutinen im Kernal abzufangen (so ähnlich wie es die ROM-Ersatzlösungen auf schneller Flashcontrollerbasis tun oder auch div. SID-Ersatzlösungen) und dort dann eine moderne 32bit CPU rechnen zu lassen und danach die Ergebnisse der 65xx unter zu jubeln.
Ist dann natürlich kein universeller Ansatz mehr, sondern aufs Kernal von VC20/C64 zugeschnitten (aber leicht auch für C128 und die 264er Serie sowie die großen CBM adaptierbar, da letztlich alles ähnlich implementiert), aber würde die reale Geschwindigkeit genau dort pushen, wo bislang die größten Defizite herrschen, nämlich im Fließkommabereich. Zusätzlich könnte man natürlich nach Lust und Laune auch noch String-Handling, Garbage-Collection etc. "optimieren"...