Beiträge von Unseen im Thema „65f02 CPU at 100 Mhz“

    Weder auf der XILINX "Distributed Memory Generator" Webseite noch in der Dokumentation "Distributed Memory Generator v8.0" gibt es irgend einen Hinweis auf die maximal erstellbare RAM Größe, sodass ich eher negativ überrascht bin.

    Das ist halt wie bei Programmiersprachen: Da steht in der Doku der Funktion zur Speicheranforderung auch nicht wie viel man darüber insgesamt anfordern kann weil das von dem System abhängt, auf dem das Programm am Ende läuft.

    Xilinx verkauft dir auch gerne Chips, die die Einstellmöglichkeiten des Distributed Memory Generators fast komplett ausnutzen können (und nochmal ein vielfaches davon als Block-RAM mitliefern), aber wenn man bei den üblichen Distributoren danach Bitte melde dich an, um diesen Link zu sehen. dann stehen da Stückpreise dran bei denen man vielleicht doch noch mal auf die Idee kommt, das gewählte Design etwas zu überarbeiten.

    Übrigens: Das mit dem 64 KByte XILINX FPGA Limit ist nicht so ganz richtig:

    Stimmt, eigentlich hat ein XC6SLX9 576Kbit RAM, aber aus irgendwelchen historischen Gründen ist das mit 9 Bit pro Byte organisiert. Wenn man nur 8 Bit pro Byte braucht ist es am einfachsten wenn man das 9. Bit ignoriert weil es im Modus mit 9 (oder 18) Bit Breite keine bitweisen Write-Enable-Signale gibt und die Modi mit weniger als 9 Bit Breite das "Bonusbit" nicht als zusätzlichen Speicher zugänglich machen.

    Prinzipiell kann man auch ungenutzte Logikresourcen als RAM verwenden (nennt sich bei FPGAs dann "Distributed RAM"), aber das geht halt auf Kosten der Logik und beim XC6SLX9 bekommt man so maximal 90 Kbit zusätzlich.

    Bei 64k x 8 Bit ergibt sich daraus 64 KByte; Bei 64k x 16 Bit => 128 KByte; ... Bei 64k x 1024 Bit theoretisch 8 MByte....

    Das ist das, was das Hilfsprogramm im Synthesetool basteln kann wenn man den Code nicht von Hand schreiben möchte. Wenn der als Ziel eingestellte Chip weniger Resourcen hat als man sich damit zusammengeklickt hat bricht es beim Map- oder Place&Route-Schritt mit einer Fehlermeldung ab.

    Nun, für den Betrieb im C64 sind noch Modifikationen und Ergänzungen notwendig

    Natürlich, aber wenn ich die Kommentare hier lese habe ich immer wieder das Gefühl, dass manche Poster hier das Ding für einen 6502 mit 100MHz externem Takt und sonst nichts halten. Dabei hat der Projektautor sich doch so viel Mühe gegeben, Implementierungsdetails wie das Bitte melde dich an, um diesen Link zu sehen., die Unterstützung von Bitte melde dich an, um diesen Link zu sehen. und auch clevere Dinge wie Bitte melde dich an, um diesen Link zu sehen. für zeitkritischen I/O-Code zu beschreiben.

    Ich zerrede ja auch gerne Projekte, aber Sachen als Problem darzustellen, die dort für andere Zielsysteme schon gelöst wurden bringt doch irgendwie nix.

    (und es wäre nicht mal der ersten interne C64-CPU-Beschleuniger...)

    aber aufgrund der C64-Komponenten, die nur 1 MHz vertragen, müssten noch weitere Hardware-Anpassungen/Ergänzungen addiert werden.

    Die Sache mit dem ~1MHz Originalsystemtakt ist ja in einem Apple II oder CBM 8032 nicht anders, warum muss es dann gerade beim C64 angepasst werden?

    Irgendwann hat man dann auch noch das PLA integriert und zieht Strippen

    Korrekt, denn sonst könnte man ja die Bankinglogik nicht nachbilden.


    und fragt sich dann, wieso man es nicht gleich so wie das Chamaeleon oder die Super-CPU macht.

    Am Modulport sind nun mal manche Dinge einfacher und andere Dinge komplizierter. Schon mal versucht, mit Chameleon oder aktiver SuperCPU auf den Datasettenport zuzugreifen?

    Das funktioniert alles aber nicht mit *dieser* CPU. Es scheitert schon an sowas banalem wie dem Bankswitching.

    Du hast dir nicht die Mühe gemacht, die umfangreiche Beschreibung zu dem Projekt zu lesen, oder? Da gibts sogar eigene Abschnitte zu den Themen Video-RAM und Bankswitching.

    Wie greift der VIC dann auf seinen 16 kB-Bereich (innerhalb des FPGA) zu?

    Gar nicht, der greift natürlich weiter auf das reguläre RAM zu.

    Oder blendest du das aus und definierst es als "I/O", damit die CPU es extern (und damit mit 1 MHz) anspricht?

    Das ist eine von mehreren Möglichkeiten. Eine andere wäre ein Write-Buffer (oder gar ein Writeback-Cache), damit die CPU nicht auf jeden einzelnen Schreibzugriff warten muss - meines Wissens macht die SuperCPU sowas in der Richtung.

    Das Chameleon implementiert die Luxuslösung: Das reguläre RAM wird komplett weggeblendet und dem VIC immer Just-in-Time aus dem FPGA/Modul-Speicher das gerade benötigte Byte geliefert. Das bräuchte aber etwas mehr Signale als man am CPU-Sockel zur Verfügung hat.

    Dann bleibt der Geschwindigkeitsvorteil nur noch für (interne) Berechnungen.

    Das kann ja durchaus einiges sein.