Hallo Besucher, der Thread wurde 2,6k mal aufgerufen und enthält 18 Antworten
letzter Beitrag von 8R0TK4$T3N am
100 MHz 6502 Ersatz [2021]
-
-
J. Müller hat einen 100 MHz 6502 Ersatz gebastelt.
Okay, Zeit, den MEGA65 einzumotten (sobald man ihn bekommen hat). Der kann nur 40 MHz.
-
Beeindruckend. Auch wenn es ein 65C02 kompatibler ist - Stichwort "Illegale Opcodes" - die dürften also nicht unterstützt werden.
-
Nett, das Ding jetzt als 6510
Und dann vielleicht so das man auch was von dem Turbo hat,
müssen ja nicht gleich 100 Mhz sein.
Mfg Jood
-
Das Problem ist, egal wie schnell die 6510-CPU kann, den Takt gibt erstmal das VIC vor.
Da muss man ein wenig anders vorgehen, hier mal ein Test von mir (das cc65-Plasma-Beispiel):
-
Naja, im Prinzip kann man den Zugriff auf diverse Dinge (RAM/SID/VIC usw.) ohnehin nicht
nur per CPU beschleunigen, man könnte aber z.B. das RAM in der CPU bereitstellen und nur
beim Zugriff auf die Hardware bremsen.
Mir ist klar das das nicht so einfach ist, vor allem muss auch den VIC synchronisieren...
Mfg Jood
-
RAM in der CPU bereitstellen und nur
beim Zugriff auf die Hardware bremsen.
ja, allerdings musst Du buchhalten, auf welchen Speicherbereich der VIC zugreift bzw. wenn die Bank verändert wird, ob Du noch Änderungen nur intern hast und die dann rausschreiben!
-
Sehr interessant vor allem Der Schachcomputer mit 6502
-
man könnte aber z.B. das RAM in der CPU bereitstellen und nur
beim Zugriff auf die Hardware bremsen.
Mir ist klar das das nicht so einfach ist, vor allem muss auch den VIC synchronisieren...
Das ist im Grunde das, was die SuperCPU gemacht hat: das war ein eigener Rechner,mit eigenem RAM. Du konntest konfigurieren, wie viel von den untersten 64 KB pro Frame mit dem RAM des C64 synchronisiert werden sollten - Nichts, die aktuelle VIC-Bank, alles.
Sprich: Im C64 wäre das dann doch "etwas" komplexer als nur den Prozessor zu tauschen. Lustiger ist das eher für neue Projekte, oder den besagten Schachcomputer...
-
Stichwort "Illegale Opcodes" - die dürften also nicht unterstützt werden.
Steht auch auf der Seite, daß die nicht unterstützt werden. Sollte aber doch grundsätzlich möglich sein, das Teil auch 6502-kompatibel zu machen.
Das Problem ist, egal wie schnell die 6510-CPU kann, den Takt gibt erstmal das VIC vor.
Für sowas wurde der Cache erfunden. Auf der Seite wird erklärt, daß beim Start der gesamte Adressraum ins interne CPU-RAM kopiert wird. Das würde sich allerdings durchaus am C64 etwas kompliziert gestalten. Man müßte RAM, ROM und I/O separat behandeln und die jeweilige Speicherkonfiguration intern buchhalten.
ja, allerdings musst Du buchhalten, auf welchen Speicherbereich der VIC zugreift bzw. wenn die Bank verändert wird, ob Du noch Änderungen nur intern hast und die dann rausschreiben!
Genau da muß man eigentlich nicht buchhalten. Im Prinzip müßte man die gesamten 56kb, auf die der VIC Zugriff hat, immer rausschreiben, weil man die Bank jederzeit umschalten kann. Möchte man das bedingungslose rausschreiben unterbinden, sind spezielle Konfigurationen denkbar, wie sie die SCPU bietet, aber davon kann natürlich nur speziell für diese Hardware angepasste Software profitieren.
-
Im Prinzip müßte man die gesamten 56kb, auf die der VIC Zugriff hat, immer rausschreiben, weil man die Bank jederzeit umschalten kann.
Warum ?
Es schaltet doch der Prozessor um, also weiss er auch welche Bank aktiv ist...
Mfg Jood
-
Es schaltet doch der Prozessor um, also weiss er auch welche Bank aktiv ist...
Die CPU "weiß" das nicht. Das Register für die Auswahl der VIC-Bank ist aber im I/O-Bereich: $DD00 (also CIA2).
Im Prinzip müßte man die gesamten 56kb, auf die der VIC Zugriff hat, immer rausschreiben, weil man die Bank jederzeit umschalten kann.
Das mit der Bankumschaltung klingt nachvollziehbar. Die fehlenden 8 KB sind die jeweils 4 KB CharROM ab $1000 und $9000 aus Sicht des VIC-II? Würde man der Einfachheit halber dann nicht doch die kompletten 64 KB rausschreiben?
-
Es schaltet doch der Prozessor um, also weiss er auch welche Bank aktiv ist...
Der VIC greift aber sofort auf die neue Bank zu, man kann den nicht mal eben anhalten um bis zu 16 KByte Daten rauszuschreiben, die man bisher zurückgehalten hat.
-
Eben - sobald mehr als eine VIC-Bank benutzt wird, bleibt einem nichts anders übrig als alle benutzten Bänke zu synchronisieren. Und da das der Anwender machen müsste, bräuchte man dann eine ganze Schalterbank, um jede mögliche Kombination abzudecken. Deswegen "Nichts" (für lange Berechnungen), "VIC-Bank" oder "Alles".
-
Es schaltet doch der Prozessor um, also weiss er auch welche Bank aktiv ist...
Der Prozessor könnte sich schon merken, welche Bank aktiv ist. Bringt aber nichts, denn er kann nicht wissen, ob und wann in die anderen Bänke umgeschaltet wird, also darf er dem VIC auch nichts vorenthalten.
Die fehlenden 8 KB sind die jeweils 4 KB CharROM ab $1000 und $9000 aus Sicht des VIC-II? Würde man der Einfachheit halber dann nicht doch die kompletten 64 KB rausschreiben?
Ich bin kein FPGA-Experte, aber ich denke mal nicht, daß das so viel spart. Eine Entscheidungslogik ist ohnehin vorhanden, um zwischen RAM, ROM und I/O zu unterscheiden, und ein paar Extrabits für die Entscheidung dürften doch höchstens ein paar Logikzellen ausmachen.
Sicher könnte man da die SCPU als Vorbild nehmen und das konfigurierbar machen, damit angepasste Software Spiegelungen für nichtbenötigte Bereiche deaktivieren kann.
Außerdem wären "8kb Plug&Play FastRAM" doch bestimmt werbewirksam.
-
Die Lösung für das VIC-II Timing-Problem vs. schnelle CPU ist einfach, altbewährt aber teuer: Dual-Port-RAM (DP-RAM) 64KB. Kostet so in etwa 80 EUR in Form von 2 Chips und ermöglicht einen Betrieb bis ca. 40MHz ohne Waitstates (bei den schnellsten mit 25ns Zugriffszeit), die neue CPU sitzt dann aber bestenfalls samt RAM-Ersatz auf einer riesigen internen piggy-back-PCB (da man auch an den CPU-Sockel mit ran muss) oder man macht sich gleich eine neue PCB für einen derartigen Turbo-C64...
Der VIC-II kann über seinen Port gemächlich zugreifen, die CPU absolut asynchron dazu und deutlich schneller aber auf dem anderen Port schreiben. Abbremsen muss die CPU nur für Zugriffe auf die Register der CIAs, des SID und eben des VIC-II selbst.
OT: Eine ähnliche Technik waren die V-RAMs der ersten "schnellen" VGA-Karten, dort kam aber eine spezielle Art von Dual-Port-RAMs zum Einsatz, zum Einen auf dynamischen statt statischen RAMs basierend und zum Anderen war eine Seite nur seriell austaktbar, also kein echte RAM (random access = wahlfreier Zugriff) sondern eine Art riesiges Schieberegister. Das reichte für die eh sequenziellen Videodaten aber und der zweite Port war normal realisiert (CPU-Seite).
Das DP-RAM passt aber heute in große FPGAs gleich mit rein, wird dann aber auch nicht günstiger als Systemlösung, aber geht auch nicht einfach im Stecksockel des 6510, da die RAM-Anbindung im C64 dem im Wege steht. (oder aktives Rausschreiben ins DRAM, aber dann wirds aufwändig, siehe SCPU...)
-
die neue CPU sitzt dann aber bestenfalls samt RAM-Ersatz auf einer riesigen internen piggy-back-PCB
So wie ich das sehe, war die Idee hier eher nur die CPU zu ersetzen, ohne daß weitere Umbauten erforderlich sind.
Andererseits darf man am C64 den DMA nicht vergessen. Es ist schließlich möglich, das RAM von außen zu beschreiben, wie es mindestens die REU macht. Den Bus permanent überwachen, könnte der FPGA natürlich auch dann, wenn aus VIC-Sicht gerade kein CPU-Zyklus dran ist, aber um Schreibzugriffe zu erkennen, müßte es zusätzlich wohl auch noch das Schreibsignal vom RAM abgreifen.
-
Oder man bleibt ständig im DMA und macht alles selber... siehe TC64...
Mfg Jood
-
Wäre doch etwas für Selbstbau-Computer à la Steckschwein
