65f02 CPU at 100 Mhz

Es gibt 24 Antworten in diesem Thema, welches 3.792 mal aufgerufen wurde. Der letzte Beitrag (30. Juni 2022 um 15:53) ist von 1570.

  • Ü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.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Aber schneller läuft er im C64 trotzdem nicht (ohne von einem echten 6502-Core wegzugehen), weil der VIC den Takt angibt (und der sich wiederum am Videostandard orientiert)

    Das lässt sich ändern, das Stichwort heißt DP-RAM Dual ported RAM. Damit kann die CPU unabhängig vom VICII Takt laufen und beide haben dennoch -fast- uneingeschränkten Zugriff aufs gemeinsame RAM, das dann eben ein DP-RAM sein muss, was als Baustein schwer verfügbar ist und wenn man -um andere Probleme zu umschiffen- gleich das ganze 64KB DRAM des C64 plus das bisschen Farb-SRAM damit ersetzt auch ziemlich ins Geld geht.

    Auf FPGAs hat man hingegen DP-RAM Blöcke durchaus "kostengünstig" zur Verfügung, angesichts der aktuellen Marktpreise für jegliche Halbleiter natürlich in Anführungszeichen, so richtig günstig ist aktuell ja gar nix mehr... D.h. die Systempartitionierung würde sich so verschieben, dass neben der CPU auch das RAM ins FPGA wandern würde.

    Ob ein 100MHz 8-Bit Prozessor, der noch dazu im Falle der 65xx Architektur mit annähernd halbem Systemtakt aufs RAM/ROM zugreifen "möchte" um volle Leistung zu erbringen, aber von der Skalierung her noch sinnvoll ist, darüber könnte man vermutlich ewig streiten.

    anderer Lösungsansatz für reale Beschleunigung (ohne FPGA und DPRAM)

    OT: Ich persönlich würde einen anderen Ansatz bevorzugen, nämlich die Gleitkommaroutinen im Kernal abzufangen (so ähnlich wie es die ROM-Ersatzlösungen auf schneller Flashcontrollerbasis tun oder auch div. SID-Ersatzlösungen) und dort dann eine moderne 32bit CPU rechnen zu lassen und danach die Ergebnisse der 65xx unter zu jubeln.

    Ist dann natürlich kein universeller Ansatz mehr, sondern aufs Kernal von VC20/C64 zugeschnitten (aber leicht auch für C128 und die 264er Serie sowie die großen CBM adaptierbar, da letztlich alles ähnlich implementiert), aber würde die reale Geschwindigkeit genau dort pushen, wo bislang die größten Defizite herrschen, nämlich im Fließkommabereich. Zusätzlich könnte man natürlich nach Lust und Laune auch noch String-Handling, Garbage-Collection etc. "optimieren"...

  • Danke für die Info.

    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.

  • 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.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Der Bank Switching-Support des Projekts geht doch schon in die Richtung? Es wird nicht ganz genau beschrieben, wie das funktioniert (internes RAM nur als Cache mit kleinen Seiten wäre natürlich schön, aber ich vermute, dass einfach bei einem Bank-Wechsel alles entsprechend umkopiert wird...?). Und beim C64 ist's natürlich nochmal ein Stück schwieriger - spätestens im Ultimax-Modus wird das dann nichts mehr mit 100MHz, jedenfalls nicht kompatibel, weil die CPU nicht auf die in dem Modus "offenen" potenziell am Expansionsport hängenden Adressbereiche mit 100MHz zugreifen kann.

    Gibt's das VHDL gerade irgendwo? Der Link auf der Website dazu ist 404.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.