Hello, Guest the thread was viewed7.5k times and contains 41 replies

last post from GeTE at the

C16 kompatibles Motherboard

    Hallo alle zusammen,
    Ich arbeite gerade an einem Projekt für eine kleine Platine, die ursprünglich als Ersatz für das Motherboard meines Pus4 gedacht war. Nach kurzem Austausch mit Interessenten ergibt sich nun folgendes:


    Das ganze wird ein komplett neuer Homecomputer mit Binärkompatibilität zum C16, Plus4. Diese wird über eine spezielle Firmware erfolgen, deren hauptsächliche Aufgabe es ist 6510 Maschinencode AOT in den nativen Maschinencode des verbauten Mikrokontrollers zu kompilieren. Hierbei wird das gesamte Speicherlayout sowie die Funktionalität des C16 (TED etc.) per Codeinduktion simuliert (d.h. nativer Maschinencode zur Simulation kompiliert). Das Speicherlayout wurde hierfür auch etwas erweitert um neuere Funktionen zu adressieren. Der Compiler wird erweiterbar sein, d.h. es wird möglich sein nach Bedarf weitere Systemfunktionalität umzusetzen (etwa weitere Grafikmodies, andere ISA, etwa 65816 etc.).


    Platine:
    - PIC32MZ DA (abzüglich Treiber etwa 200 MHz, 512 KByte RAM, 2 MByte Flash)
    - 16 MByte SRAM
    - VGA*
    - USB 2
    - SD
    - Ethernet
    - 2x D-Sub (Atari)
    - 2x Klinke (Sound)
    - User Port
    - Mini USB (Strom)


    Falls jemand Interesse hat, bitte melden. Das ganze wird unter 100 Euro kosten, wie viel hängt primär von der Anzahl an Interessenten ab.


    * Endversion: HDMI, momentan keine Ahnung wie, aber irgendwie wird es gehen.

    Quote from Fulgore

    Wird das Board dann auch in ein org. Gehäuse passen ?


    Prinzipiell Ja. Da allerdings sowohl das Gehäuse vom C16 als auch C116 und Plus4 ziemlich unterschiedlich ausfallen plane ich zwei Platinen. Eine für die Anschlüsse sowie eine wesentlich kleinere mit dem Mikrocontroller und RAM. Beide Platinen werden dann mit einem kurzen Flachbandkabel verbunden sein. Dies hat den Vorteil alle drei Gehäuseformen abdecken zu können und für mich den Nachteil mehrere Platinen layouten und bestücken zu müssen. Soweit der Plan. Ich muss hierbei allerdings auch die Kosten im voraus gut abschätzen, da ich realistischerweise von einer Kleinserie ausgehe. Insofern kann es sein, das es insgesamt besser wäre die Platinengröße zu minimieren und ein eigenes Gehäuse zu entwerfen (hier habe ich übrigens Anfragen nach dem Gehäuse vom nicht produzierten C364). Das würde ich aus Kosten und ästhetischen Gründen komplett aus Bambus fertigen lassen (inklusive Tastatur).

    Quote from Larry Underwood

    Definitiv Interesse. Aber bitte mit Gehäuse. Muss nicht unbedingt das Original Tastaturgehäuse sein.


    Ist bisher von mir nicht angedacht. Wenn, dann eine sehr kleines Gehäuse aus Bambus mit eigener, externer Tastatur.

    Puh :) Klingt ja nicht schlecht, ich befürchte aber, dass es am Ende ein unabsehbar langes Projekt wird. Das ist nicht mit dem 6502-Core und der TED-Emulation getan. Da sind noch Eigenheiten wie das Banking und das komplette I/O. Und darauf müssen dann die originalen ROM-Images laufen. Das Ganze im passenden Timing, sowohl normal wie erhöhtem Takt, das ist alles nicht mal eben so gemacht.


    Tja, ich wünsche viel Erfolg, werde es auch weiter verfolgen, habe aber so meine Zweifel an der "mal eben" Umsetzbarkeit. :)

    Wie genau ist das mit AOT-Compiler gedacht? Dazu müsste man ja wissen, was in einem Binary Code und was Daten sind!? Von selbstmodifizierendem Code gar nicht zu sprechen. Mir ist nicht klar, wie das gedacht ist. Just in Time ...ja, ok. Aber Ahead of Time? Kannst du das genauer erläutern?

    Mit Ahead-of-time ist hier ein statischer trace Compiler gemeint. Das funktioniert vereinfachend ausgedrückt so:


    Der gesamte Adressraum des 6510 Prozessors wird zur Übersetzungszeit als zusammenhängender Speicherbereich abgebildet. Jede virtuelle Speicherstelle besteht hierbei aus einigen Feldern mit Informationen zur Optimierung sowie einigen Flaggen, die u.a. signalisieren, ob die virtuelle Speicherstelle Teil einer Maschinencodesequenz ist oder eine E/A Adresse etc. Nun wird während des kompilierens jede Speicherreferenz überprüft wodurch es beispielsweise möglich wird selbst modifizierenden Code zu detektieren. Es ergeben sich darüber hinaus gewisse Muster an Speicherzugriffen, die charakteristisch für spezifische Algorithmen sind (trace), anhand welcher der native Maschinencode generiert wird. Jede übersetzte Maschinencodesequenz (der Codeblock) ist eingebettet in eine kurze Routine, die über einen Timer die Synchronisation zur entsprechenden Ausführungszeit des 6510 Prozessors sicherstellt. Diese wird mitkompiliert.


    Wo eine statische Synchronisation nicht ausreichend wäre (Video und Soundgeneration) erfolgt eine Emulation als 'parallel' laufender Thread. Das gesamte Programm wird nach diesem Prinzip übersetzt und anschließend ausgeführt.


    Ich beschäftige mich nunmehr seit fast einem Jahrzehnt u.a. mit der Programmierung solcher Compiler sowie VM Design und habe ausreichend Erfahrung um das auch umzusetzen.

    Quote from Mat4

    Ich beschäftige mich nunmehr seit fast einem Jahrzehnt u.a. mit der Programmierung solcher Compiler sowie VM Design und habe ausreichend Erfahrung um das auch umzusetzen.

    :thumbsup:

    Ja wenn das klappt und die Kiste hinterher ähnlich funktioniert wie ein U64 bin ich auf jeden Fall dabei.
    Der C16 plus/4 war für mich eigentlich derzeit der Grund wieder mit den alten Kisten anzufangen.
    Und mal ehrlich ein Ersatzboard für 264er ist wesentlich dringlicher denn die 264er sind ja wirklich recht fragil und anders als beim 64er hege ich jedes Mal Zweifel wenn ich den Power Schalter betätige.

    Melde hiermit auch Interesse an! :)

    Quote from Mat4

    Jede virtuelle Speicherstelle besteht hierbei aus einigen Feldern mit Informationen zur Optimierung sowie einigen Flaggen, die u.a. signalisieren, ob die virtuelle Speicherstelle Teil einer Maschinencodesequenz ist oder eine E/A Adresse etc. Nun wird während des kompilierens jede Speicherreferenz überprüft wodurch es beispielsweise möglich wird selbst modifizierenden Code zu detektieren.

    Hmm, aber genau dieser Punkt war ja meine Frage. Woher kommt die Erkenntnis, wie ein Bereich zu markieren ist? Ja, klar...du kannst absolute und relative Sprünge auswerten und gucken, wo die landen. Das ist dann Code. Alles, wo nichts hinspringt und was zu keinem Chip gehört, ist dann Daten (grob gesagt). Aber ich kann ja z.B. dynamisch Code erzeugen, dann eine Einsprungadresse (dynamisch erzeugt) in diesen Code irgendwo im Speicher ablegen und dann dynamisch mit JMP ($hhll) an diese Stelle springen...oder eben Varianten davon. Mir ist nicht klar, wie du das im Vorfeld erkennen willst? Natürlich ist das kein "normaler" Anwendungsfall, aber gerade auf den alten 8-Bittern wird ja alles gemacht, was irgendwie geht...

    Also ich finde die Idee sehr gut und hätte definitiv Interesse.


    Was das Board betrifft, würde ich an deiner Stelle auf das C64-Layout setzen, ähnlich wie Gideons Ultimate64. Das perfekte Case wäre dann ein neues C64C-Gehäuse in Retro-Black vom Tommes. So wie der nun zum Ultimate64 passende Gehäuseaufkleber ins Angebot aufgenommen hat, würde der auch für dein Board die passenden Lables mit "Commodore 264 Reloaded" (oder so ähnlich) produzieren. Joystickports sind so oder so besser im Atariformat auszuführen und auf der Rückseite wäre ein 1551-kompatibler Cartridge-Port, S-Video und Kopfhörerklinke am TV-Modulator (wie beim C64 Reloaded MK2) und alle anderen Anschlüsse (HDMI, USB, Mini-DIN für 1531 etc.) in den User- und Kassettenportschlitzen perfekt aufgehoben. Optisch wäre das der C16, den ich so immer hätte haben wollen.


    Wir hier müssten uns dann nur intensivst auf die Suche nach völlig defekten C16 machen, um die Tastaturen zu retten und zu restaurieren, damit dein 264er damit in der Form ausgestattet werden kann. Vielleicht aber wird das doch noch was mit neuen Tastaturen für den C64 und dann wäre natürlich auch die C16-Bedruckung neu machbar. Ich glaube da aber erst mal nicht dran und fände die Lösung so am elegantesten, weil man da wirklich nur C16-Tastaturen gebraucht verwenden muss und sonst nicht zum Schlachten der alten Originale im Ira Velinsky Design genötigt ist (116, plus/4 und rare 232er und 264er). Für die hoffe ich ja noch darauf, dass das FPGATED-Projekt einen Ersatzchip zur Wiederbelebung eines Tages fertig haben wird.


    Eins ist aber bedenkenswert, Jens Schönfeld (Wiesel) hält sich mit seinen Features für das C64 Reloaded MK3 sehr bedeckt, damit Gideon die Ideen nicht vorher klauen und umsetzen kann. Im Gegensatz zum MK2 soll das auch kein Board für die alten Chips sondern eine FPGA-Implementierung werden. Ob dort - anders als beim Ultimate64 - auch Keyrah mit integriert und damit der Anschluss von VC20- und C16-Tastaturen möglich sein wird, wissen wir heute nicht. Wäre das möglich, wäre natürlich auch dort die Implementierung eines Emulations-Cores für 264er für Entwickler interessanter als beim Ultimate64 oder TC64 und das wäre dann natürlich eine direkte Konkurrenz für dein Projekt.


    PS: Wenn das Endprodukt in der Bauform "Commodore V364" käuflich erscheinen würde, täte ich obszön viel Geld ausgeben wollen. Aber nur dann! 8o

    Quote from EgonOlsen71

    Hmm, aber genau dieser Punkt war ja meine Frage. Woher kommt die Erkenntnis, wie ein Bereich zu markieren ist? Ja, klar...du kannst absolute und relative Sprünge auswerten und gucken, wo die landen. Das ist dann Code. Alles, wo nichts hinspringt und was zu keinem Chip gehört, ist dann Daten (grob gesagt). Aber ich kann ja z.B. dynamisch Code erzeugen, dann eine Einsprungadresse (dynamisch erzeugt) in diesen Code irgendwo im Speicher ablegen und dann dynamisch mit JMP ($hhll) an diese Stelle springen...oder eben Varianten davon. Mir ist nicht klar, wie du das im Vorfeld erkennen willst? Natürlich ist das kein "normaler" Anwendungsfall, aber gerade auf den alten 8-Bittern wird ja alles gemacht, was irgendwie geht...

    Nun der Trace signalisiert während der Codeanalyse in diesem Fall einige Speichermodifikationen, einmal als Resultat der Zeigerarithmetik des Codeblocks zur Generierung von 6502 Maschinencode sowie dem Speichern des Zielzeigers. Diese Änderung wird ja während des kompilierens registriert und ergibt einen charakteristischen Trace. Der Sprung kann daher im voraus zurückverfolgt werden und identifiziert den modifizierten Speicherbereich zunächst einmal als potentiell variablen Codebereich. Hierdurch erfolgt des weiteren eine Klassifizierung des zu kompilierenden Codeabschnitts als Generator. Es wird dann einfach der zu kompilierende 6510 Code analysiert und wenn die Routine einem statischen Muster der Codegenerierung folgt entsprechend äquivalenter Maschinencode hierfür kompiliert. Wenn dies nicht möglich ist, wird stattdessen ein für diesen Codeabschnitt optimierter Interpreter kompiliert (Codeinjektion). Folgende Verzweigungen in den als potentiell variablen Codebereich markierten Speicherbereich werden im folgenden durch den vorher kompilierten Interpreter ausgeführt. Die Interpretation endet, sobald eine Verzweigung ausserhalb des markierten Speicherbereichs erfolgt.

    Verstehe. Also ein bisschen so, wie das moderne JIT-Compiler für Javascript machen...nur anders herum. Dort wird erstmal kompiliert und wenn man später merkt, dass das nicht stimmig war, wird für die Stelle wieder der Interpreter angeworfen. Hier wird dann schon vorher erkannt, dass es ein Problem geben könnte und man nutzt gleich den Interpreter. Ok, das wird wohl klappen. Bin gespannt auf das Ergebnis, viel Erfolg damit!


    Edit: Da fallen mir auch noch so coole Sachen ein, wie die Zähler der Timer als dynamische Sprungziele zu verwenden. D.h. man schreibt vor die Speicherstelle mit dem Timerwert den statischen Teil des Sprungbefehls und springt dann dort hin, was indirekt an eine Speicherstelle anhängig vom Stand des Timers springt. Gott, bin ich froh, das ich diesen Compiler nicht bauen muss... :D

    Quote from Superingo

    Ja wenn das klappt und die Kiste hinterher ähnlich funktioniert wie ein U64 bin ich auf jeden Fall dabei.
    Der C16 plus/4 war für mich eigentlich derzeit der Grund wieder mit den alten Kisten anzufangen.
    Und mal ehrlich ein Ersatzboard für 264er ist wesentlich dringlicher denn die 264er sind ja wirklich recht fragil und anders als beim 64er hege ich jedes Mal Zweifel wenn ich den Power Schalter betätige.

    Schließe mich dem @Superingo kommentarlos an!