Hallo Besucher, der Thread wurde 3,3k mal aufgerufen und enthält 18 Antworten

letzter Beitrag von baxt3r am

Frage: C16 oder Cplus4 core für den MiST?

    Hallo,
    alle möglichen Systeme wurde erfolgreich für den MiST portiert und werden fröhlich weiterentwickelt, was jedoch fehlt ist eine C16 bzw. Cplus4 portierung, hat einer von Euch irgend etwas in diese Richtung schon eventuell irgendwo gefunden?
    Gibt es vielleicht irgendwo im verborgenen einen Entwickler der an einem solchem "Core" arbeitet? :?:
    Ich habe hier im Forum einen Beitrag aus dem Jahre 2009 gelesen in dem über ein solches Projekt (C16 FPGA) gesprochen wurde, aber leider wurde dieses Thema nicht weiter verfolgt.


    Viele Grüße
    woj

    Ein C16 kompatibler FPGA Core würde mir auch sehr gut gefallen.
    Habe, wie Du schon gefunden hast, mal ganz ganz grob damit angefangen, aber wegen einigen Gründen dann nicht weiter gemacht.


    Leider ist der FPGA64 und 6502 Source in HDL geschrieben und nutzt mir so gut wie gar nichts.
    Eine komplette Neuerschaffung in Verilog ist etwas zu komplex für mich alleine, deswegen der andere Thread... aber bis jetzt hat sich noch niemand für eine Zusammenarbeit gefunden.

    Zitat von BoingBall

    Leider ist der FPGA64 und 6502 Source in HDL geschrieben und nutzt mir so gut wie gar nichts.
    Eine komplette Neuerschaffung in Verilog ist etwas zu komplex für mich alleine


    Warum willst du den existierenden Code unbedingt komplett in Verilog umschreiben? Auch Quartus sollte Projekte mit Sprachmix unterstützen.

    Zitat von BoingBall

    Es ist keine Frage von Code Übernahme, sondern VHDL (das V habe ich oben wohl vergessen).


    Ist das eine Allergie bei dir oder so? "Du sollst keine andere HDL neben Verilog haben"-Aberglaube? VHDL- und Verilog-Module in einem Projekt zu mischen, obwohl man nur eine der beiden Sprachen vernünftig kann ist nun wirklich nicht schwer.

    Zitat von mc71

    Es wird wohl kaum reichen, fertige Module zu importieren- spätestens für die TED-Register, die 121-Farben-Bildausgabe und die völlig anders laufenden Bildzähler wird man nicht-triviale Änderungen am Code vornehmen müssen. Und wenn man dann mit der Sprache nicht klarkommt...


    Ok, du hast es auch nicht verstanden... Erklär mir doch mal, wieso er den TED in VHDL statt in Verilog implementieren soll.

    Für eine schnelle C16-implementierung gibt's leider ein paar Probleme:
    1. die CPU ist zwar 6510/6502-kompatibel, hat aber einen anderen
    IO-Port (was sich aber leicht anpassen lassen sollte)
    2. statt VIC-II arbeitet im C16 der TED, der für mehr als nur Graphik
    zuständig ist. Ausserdem arbeitet er nicht so wie der VIC II. Der TED
    müsste also fast komplett neu implementiert werden (sehr aufwendig,
    insbes. ohne die umfangreiche Doc wie beim VIC-I/II)
    3. Den PAL-Chip müsste man komplett ersetzen, dazu müsste man
    das Timing der C16 untetsuchen (kann auch aufwändig werden).


    Also nicht so einfach machbar. Alleine den TED zu schreiben kostet
    sicher ein Jahr Hobby-Aufwand.

    was mich sehr freut ist die Tatsache, dass ich nicht alleine mit dem Wunsch nach einem C16 / plus/4 "core" bin ;)


    So wie Jotta beschrieben, scheint die Implementierung des TED´s die meißte Arbeit zu bereiten, bei allen anderen Modulen könnte man sich aber, wie von Unseen beschreiben/vorgeschlagen an den vielen vorhandenen VHDL Sourcen anderer Projekte bedienen, die dementsprechend natürlich angepasste werden müssten jedoch trotzdem eine gewisse breite Basis darstellen könnten oder?


    zu mir: ich kann (was die Programmierung angeht) leider überhaupt nich mit helfen, hierfür fehlen mir sämtliche dafür benötigten Fähigkeiten, ich kann Euch aber virtuell mit Kaffee und Keksen versorgen :whistling:

    Zitat von Unseen

    Erklär mir doch mal, wieso er den TED in VHDL statt in Verilog implementieren soll.


    Gegenfrage: Warum sollte man das Rad komplett neu erfinden, wenn man 80% vom TED und 95% der CPU vom 64er-Core übernehmen kann- und die nunmal in VHDL vorliegen?


    Zitat von Jotta

    1. die CPU ist zwar 6510/6502-kompatibel, hat aber einen anderen
    IO-Port


    Das ist nicht das Problem. Die CPU im 264er läuft zuweilen mit 2 MHz; das ist kein Problem für heutige FPGAs, aber es braucht Anpassungen im generellen System-Timing.


    Zitat von Jotta

    2. statt VIC-II arbeitet im C16 der TED, der für mehr als nur Graphik
    zuständig ist. Ausserdem arbeitet er nicht so wie der VIC II. Der TED
    müsste also fast komplett neu implementiert werden (sehr aufwendig,
    insbes. ohne die umfangreiche Doc wie beim VIC-I/II)


    Ähm... nein. Sound udn Keyboard sind recht trivial (vielleicht abgesehen vom Raiuschgenerator?), und den Video-Teil kann man durchaus vom VIC ableiten. Man braucht 'nur' eine zweite Badline (für das Farb-RAM) und man muß die Zähler anders setzen (anderer Pixeltakt macht andere Zahl Pixel pro Zeile, TED zählt nicht vom oberen Bildrand, sondern vom oberen linken Bildpunkt- das bedeutet andere Zeilen für VLI udn andere Werte für Scherze wie 'border opening', FLD, pp) und natürlich gibt es ein paar andere/zusätzliche Register. Und leidlich gut dokumentiert ist das Ganze auch- sogar im Datenblatt...


    Zitat von Jotta

    3. Den PAL-Chip müsste man komplett ersetzen, dazu müsste man
    das Timing der C16 untetsuchen


    Trivialer Adreßdecoder. Den Zirkus mit phi0 und phi2 kann man eh knicken, weil das in FPGAs ganz anders geregelt wird- und die phi2-Erzeugung mittels Gatterlaufzeit eh nicht klappen würde.

    Zitat von Unseen


    Ok, du hast es auch nicht verstanden... Erklär mir doch mal, wieso er den TED in VHDL statt in Verilog implementieren soll.


    Zitat von mc71


    Gegenfrage: Warum sollte man das Rad komplett neu erfinden, wenn man 80% vom TED und 95% der CPU vom 64er-Core übernehmen kann- und die nunmal in VHDL vorliegen?


    Wenn euch VHDL und die 264 Technik liegt, seid ihr gerne eingeladen mitzumachen :)


    Für mich ist diese Sprache nunmal total unpassend und das ist nicht nur eine "Abneigung" sondern es ist eine wiederholte Feststellung.
    Deswegen kann ich nur Verilog behandeln und würde entweder eine Konvertierung oder eine Neuerschaffung anstreben.


    Aktuell ist mir das Ganze aber sowieso zu viel. Wer an meinem extrem rohen Grundgerüst weiter bauen möchte, ist natürlich willkommen.

    Zitat von BoingBall

    Für mich ist diese Sprache nunmal total unpassend und das ist nicht nur eine "Abneigung" sondern es ist eine wiederholte Feststellung.
    Deswegen kann ich nur Verilog behandeln und würde entweder eine Konvertierung oder eine Neuerschaffung anstreben.


    Nee, Verilog fasse ich nach Möglichkeit nicht an. Gerade wenn es um ein zusammengestöpseltes System mit CPU und diversen Peripheriebausteinen geht tippt man sich da ja in den Instanziierungen die Finger wund weil man alle Signale einzeln übergeben muss statt sie einfach in zwei Records (vgl. struct in C) zusammenzufassen. ;)