Machbarkeitsfrage: Drop-In-Ersatz für 6510 auf FPGA-Basis?

Es gibt 95 Antworten in diesem Thema, welches 17.167 mal aufgerufen wurde. Der letzte Beitrag (20. September 2015 um 14:29) ist von Jotta.

  • einen komplette C64+Zubehör im FPGA

    der Cevi für die Ewigkeit

    Ich wage es mal zu bezweifeln, daß sich aktuelle FPGA-Boards (egal ob generisch, TC64 oder sonst irgendwas) in 30 Jahren noch so gut halten btw. reparierbar sind wie originale 64er es heute sind.

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.

  • und warum nicht?

    Selbst wenn die nicht halten, so ist es im Gegensatz zu den MOS-ICs möglich jederzeit neuen Ersatz zu fertigen.

    Aber ich glaube auch dass die originalen Platinen noch lange halten werden, bis auf einige ICs kann man ja auch alles selbst reparieren. Das macht ja auch die Hardware des Cevis aus. Dreh- und Angelpunkt sind die MOS-ICs. Ich glaube aber in 10 Jahren sind die auch komplett geknackt, so dass ein Nachbau möglich wird. Wir sind ja nun wirklich schon recht nahe an den 100%

  • Aber nur, wenn du zudem auch noch die alte Fabrik mit den entsprechenden Halbleiterprozessen hast. Ansonsten nutzen dir die Masken gar nichts.

  • Einzige Chance ist also das Reverse Engineering. Egal ob die Ergebnisse dann in Software, Hardware oder in Kombination genutzt werden. Ich denke, wie gesagt, dass wir die originalen Teile nicht mehr lange brauchen werden. Na gut, die Leute die sammeln werden auch weiterhin auf originale Sachen stehen. Mit ist hingegen nur die Funktion wichtig. Ich brauche keine 10 Cevis die irgendwo rum stehen.

  • Wieder ein bisschen Off-Topic:

    Kann ein Chameleon oder eine 1541U(2), welche ja eigene KERNAL-ROMs "mitbringen", einen C64 mit defekten ROMs (gerne auch KERNAL und CHAR gleichzeitig defekt) wieder zum Leben erwecken? Also, defekte ROMs drinlassen, Modul dranbauen, weitermachen?

  • Ich wage es mal zu bezweifeln, daß sich aktuelle FPGA-Boards (egal ob generisch, TC64 oder sonst irgendwas) in 30 Jahren noch so gut halten btw. reparierbar sind wie originale 64er es heute sind.


    Bei der Simulation des C64 spielt das konkrete FPGA-Board keine Rolle. Wenn das Design unabhängig gestaltet ist, dann kann es auch noch in 20 Jahren an ein neues Board angepasst werden usw.

    Ich habe FPGA-Boards, die mehr als 10 Jahre alt sind und noch perfekt arbeiten. Schätze mal, die halten noch weitere 10 Jahre bei guter Pflege.

    Der FPGA-Ansatz ist IHMO mit der beste Ansatz zum Konservieren alter Schätze.

  • Kann ein Chameleon oder eine 1541U(2), welche ja eigene KERNAL-ROMs "mitbringen", einen C64 mit defekten ROMs (gerne auch KERNAL und CHAR gleichzeitig defekt) wieder zum Leben erwecken? Also, defekte ROMs drinlassen, Modul dranbauen, weitermachen?

    Wenn die defekten ROMs sich einfach taub stellen, vielleicht. Leider gibt es noch den anderen möglichen Fehler wo ein defektes ROM den Bus blockiert weil es meint dauernd angesprochen zu werden.

  • Hallo liebes Forum,
    auch ich habe mich schon mit dem Thema Drop In Ersatz für 6510 und auch 6526 beschäftigt.

    Ich bin neu in diesem Forum und möchte mich kurz vorstellen,
    mein Name ist Jörg, bin 42 Jahre alt und Elektro-/Software Ingenieur und aus Hessen :)

    Meine Ansatz zu Drop In Ersatz geht allerdings nicht über FPGA sondern einen geeigneten Cortex Controller und Software Emulation.
    Der Cortex sollte auf eine DIL 40 Adapterplatine passen und 5V TTL Pegel direkt ausgeben können. Die IO Pins sollten z.b für
    den Datenbus bidirektional arbeiten können.
    Mit diesen Anforderungen habe ich einen 48Pin Cortex M0 von Nuvoton ausgewählt (M0516). Der uC hat 40 verfügbare IO Pins.
    Der Prozessor kann über PLL bis 50Mhz getaktet werden was mir erstmal ausreichend erschien.

    Das Projekt habe ich aber vorerst auf Eis gelegt weil die 50Mhz höchstwahrscheinlich nicht ausreichend sind.
    Das Hauptproblem sind die Buszugriffe im PH2 Takt. In dieser Zeit kann der uC einfach nichts tun als zu warten bis
    der Buszugriff lesen/schreiben gestartet und beendet ist. Bei 1Mhz Takt verbleiben also nur 500ns für die Emulation der Core.
    500ns für das Hauptprogramm mit Opcode Decoder/Operations Ausführung und IRQ/NMI etc. handling erscheinen zu wenig wenn man wie ich
    das Programm in C entwickeln will. Allerdings ist das im Moment eher ein Bauchgefühl statt wirklich Daten herausgefahren zu haben.
    Was ich vorerst noch machen will ist einen worst case Zyklus zu konstruieren und die Zeit zu messen die das Target dafür benötigt.
    Auch wäre noch interessant zu wissen welcher Compiler den optimalsten Code erzeugt. Im Moment habe ich nur den GCC.
    Ein weiteres Problem könnte die Hochlaufzeit des UCs sein (Init, PLL etc). Die Lösung wäre den Reset Pin zum System hinaus aktiv zu
    schalten solange der uC sich initialisiert. Erst wenn die Emulation gestartet wird gibt die Software den Reset frei. Ob das für ein C64 System problematisch
    sein könnte weiß ich auch nicht.

    Nun hat Nuvoton einen zum M051 pinkompatible Version mit M4 Core und 72Mhz herausgebracht. Mit Cortex M4 sehe ich da eher Licht am Ende des Tunnels ..
    We will see.


    Gruß Jörg

  • Bei 50 MHz hast du bei einer Zykluszeit von unter 500ns (nicht vergessen, die PLA und die TTLs wollen auch noch Zeit haben) auf einmal nur noch max 25 Taktzyklen in denen du die Anfrage bearbeiten musst.

    Das wird eher knapp. Denk lieber in Richtung FPGA.

  • Das Problem bei einem uC-basierten Ansatz ist immer die
    teilzyklengenaue Steuerung (Setup/Hold etc, die Diagramme
    sind über mehrere Datasheets verteilt).

    Mit einem uC kannst Du zwar bei hoher uC-Taktrate (50MHz
    ausreichend?) eine zyklengenaue Emulation bauen, es fehlen
    aber Anforderungen wie Setup- und Hold-Zeiten etc. Dazu
    kommen noch Input-Signale wie AES (Addressbus-Enable)
    oder IRQ/NMI, auf die Du ja auch noch reagieren musst.

    Und was passiert, wenn dein uC mal abstürzt und die IOs
    auf Ausgang bleiben und nicht automatisch in den TriState
    Modus schalten? Auch ein FPGA kann "abstürzen" (FSMs
    können durch SEUs ungewollt beeinflüsst werden), das ist
    aber bei guten Designs in der Praxis so gut wie nie der Fall.

    Diese Überlegungen gelten sowohl für Prozessor- als auch
    für Peripheriebausteine.

  • Danke Euch beiden,
    ja die externen Signale und Auswertung und zyklengenaue Reaktion auf Diese sind das Problem...
    50Mhz sind dann auch nicht ausreichend.
    Vor Abstürzen habe ich weniger Angst, Überwachungs Funktionen kosten allerdings wieder zusätzliche Laufzeit.
    Jedenfalls wäre ein M4 mit 200Mhz die richtige Richtung, aber gibts für 5V (noch) nicht.

    Gruß,
    Jörg

  • Ich glaube nicht, dass sich ein *wesentlich* besserer ARM-compiler wie der GCC findet. Die Alternative wäre vermutlich was auf LLVM-Basis - aber die tun sich mal hier was, mal da was - aber im Schnitt gibt es keinen klaren Sieger. Da ARM übrigens durchaus ein gutes Target für einen C-Compiler ist, würde ich auch bei handgeliebtem Assembler keinen Vorteil sehen, der da jetzt eine Größenordnung ausmacht, sofern man in C hinreichend "low-levelig" bleibt (also in der Art "besser formatiertes Assembler" - da müsste das allermeiste direkt übersetzbar sein).

    25 Takte für einen Zyklus auf dem M0 wird tatsächlich wohl zu knapp. Da sind so einige Befehle im M0, die nicht in einem Takt laufen - der M4 sieht da viel besser aus.

    Auf ARM-Interrupts würde ich vermutlich ganz verzichten wollen - selbst beim M4 gehen da 12 Takte ins Land, bevor die ISR drankommt. Vielleicht besser alles in eine große Schleife packen und vorne gucken, ob der Interrupt-Pin gezogen ist? Das Original ist ja auch nicht zu beliebiger Zeit unterbrechbar, sondern bringt den aktuellen Zyklus noch zum Abschluss, wenn ich mich nicht täusche.


    Aber vielleicht ist der M0 ja stark genug für einen CIA, auch wenn der vom Timing her auch nicht ohne ist - die CIAs sind ja häufiger mal kaputt ;)

  • Das mit den 25 Takten (bzw. 500ns-Fenster) sehe ich
    anders: Man kann ja die anderen 25 Takte/500 ns
    als Vorbereitungszeit nutzen (LUT-Geraffel, Decoding
    etc.). Damit hat man dann 50 Taktzyklen. Ist aber
    immer noch wenig (von mir geschätzt, in C/C++).
    Wenn man einen STM32F4 mit 150MHz taktet, dann
    müsste es eigentlich in Assembler klappen. Ich fänd's
    aber in HDL/FPGA trotzdem einfacher (aber immer
    noch ein extremer Brocken!).

  • Nein, hat man nicht, weil man erst wenn _CS low geht weiss, das man gemeint ist. Zumindest beim CIA-Replacement. Dann muss man rausfinden was gemeint ist (lesen/schreiben) und in der verbliebenen Zeit das korrekte Ergebnis liefern.

    Des weiteren ist zumindest ein CIA nicht so einfach, der hat 2 Timer und wenn du deren Verhalten nicht 100% zyklengenau nachbildest gibt es Probleme. Siehe der Unterschied von 1 Zyklus zwischen 6526(NMOS) und 6526(HMOS-II). Das hat damals die Funktion von diverser Software aus dem Tritt gebracht.

    6502-Cores für FPGA sollte es doch schon fertig geben, oder? Dann fehlt 'nur' noch der I/O-Port und die Adressbuspuffer. Vorausgesetzt diese Cores enthalten auch alle illegalen Befehle...

    Die Original-HW gibt das Timing vor, daß musst du zu 100% nachbilden. Hier und dort mal einen Zyklus langsamer sein geht nicht.

  • Nein, hat man nicht, weil man erst wenn _CS low geht weiss, das man gemeint ist. Zumindest beim CIA-Replacement. Dann muss man rausfinden was gemeint ist (lesen/schreiben) und in der verbliebenen Zeit das korrekte Ergebnis liefern.


    Bei Peripheriebausteinen hast Du da iDR recht, ich wollte mich primär auf den 6510
    beziehen, aber auch eine SID-Emu wird um jeden Taktzyklus betteln (und beim CIA
    intern z.B. die Timer ebenfalls, die laufen ja unabhängig von CS#).


    6502-Cores für FPGA sollte es doch schon fertig geben, oder? Dann fehlt 'nur' noch der I/O-Port und die Adressbuspuffer. Vorausgesetzt diese Cores enthalten auch alle illegalen Befehle...

    Die Original-HW gibt das Timing vor, daß musst du zu 100% nachbilden. Hier und dort mal einen Zyklus langsamer sein geht nicht.


    Das Problem der meissten 6502/6510-Nachbildungen ist, dass sie für
    FPGA-internes Arbeiten designed wurden um ein "gesamtes System
    nachzubauen, aber nicht halbzyklengenau arbeiten. Z.B. arbeitet der T65
    (sehr beliebt) nicht syncron zum echten 6510 (hab's selber mit FPGA
    ausgemessen). D.h. selbst für einen 6502/6510 als Replacement musst
    Du schon einiges an Arbeit investieren, einfach nur instatiieren und die
    Pins rausführen ist zu wenig.