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

letzter Beitrag von AVRFan am

"Grafikkarte" bzw. Beschleunigerkarte per DMA?

    Nicht, daß ich da persönlich was machen wollte, aber ich habe mich kürzlich gefragt, ob es jemals einen Ansatz gab, eine Art Grafikkarte bzw. 3D-Beschleunigerkarte für den C64 zu bauen, die per DMA direkt in den Bildschirmspeicher schreibt. Mit ist bewußt, daß es Karten mit externer CPU wie die "Final Chess Card" oder die SuperCPU gab und daß natürlich u.a. (?) die 1541 Ultimate (II) per DMA in den Grafikspeicher schreibt, aber ich denke mehr an so etwas wie eine parallele Grafikbeschleunigung.

    Sprich: der C64 schreibt Befehlssequenzen mit Koordinaten, Grafikdaten für Sprites, Polygondaten, usw. in einen Datenbereich, den das Modul im Expansionsport abscannt und das Modul erzeugt daraus ein Bild und schreibt es direkt in den Grafikspeicher.

    Außerdem könnte man natürlich komplexe Float-Berechnungen und/oder Matrixoperationen über das Modul berechnen lassen, um die CPU des C64 zu entlasten.


    Zu Zeiten des C64 war das vermutlich zu teuer, aber heute könnte man so etwas ja relativ preiswert machen. Also wurde sowas jemals versucht?

    Ich fände es jedenfalls irgendwie faszinierend, wenn man mit einem bezahlbaren kleinen Modul einen originalen alten Brotkasten dazu bringen könnte, flüssige 3D-Grafik usw. auszugeben.

    Also natürlich müßte so eine Modul auch RAM mitbringen und könnte die Funktion der REU integrieren.

    Oder meinst Du sowas ein einen Blitter? Das meinte ich ja mit "Grafikdaten für Sprites". Ich hatte mir gedacht, daß man so den Grafikmodus für Spiele benutzen kann, wenn das Modul das Zeichnen von Tiles und Sprites übernimmt.

    Kann ja auch sein, daß schon klügere Leute über dieses Thema nachgedacht und es als unpraktikabel verworfen haben, weil die CPU dann der Flaschenhals wird.

    Ich hätte ohne tieferen Analysen halt gedacht, daß man so z.B. ein Elite mit vollflächigen Polygonen, Stunt Car Racer, Driller usw. mit besserer Grafik und höherer Wiederholrate und vielleicht sogar sowas wie Rescue on Fractalus mit einer Polygonlandschaft hinbekommen könnte.

    Ich weiß nicht genau was ein Blitter im Detail alles kann. Mir ging es dabei um AND und OR Verknüpfungen. Damit könnte man schon mal einiges an Bildschirmmanipulation

    bewerkstelligen. Es würden damit auch "Riesensprites" möglich, die tatsächlich ja nur eingebundene Grafiken wären. Aber kein zusätzliches C64 RAM benötigen würden.

    Oder eben auch für Sprites. Dadurch könnte man sich die Spriteblöcke aus dem C64 RAM halten und man bräuchte nur einen Block pro Sprite.


    Bei solcher Art von Spielen würden sich natürlich die Ladezeiten derbst erhöhen. Aber was das angeht, sind wir doch Kummer gewohnt. :D

    Na ja, wenn schon, denn schon. Weil so eine Karte ja dann den Modulanschluß blockieren würde und damit auch Lösungen wie das U2+, müßte sie aus meiner Sicht heutzutage auch eine Möglichkeit mitbringen, Daten von einer SD-Kart oder einem USB-Stick zu laden und per DMA o.ä. ins RAM zu schreiben. Eventuell könnte man auch eine Easyflash-Simulation integrieren. Aber das sind ja letztendlich Details, über die man sich Gedanken machen könnte, wenn es an die tatsächliche Implementierung eines Moduls ginge.

    Zwei Eigenschaften fände ich persönlich ganz wichtig:


    1.Das Modul müsste 100%ig kompatibel mit dem C128 Modus sein.

    2. Die integrierte REU sollte abwärtskomaptibel zur Originalen sein.

    Wäre gut für GEOS und man könnte zusätzlich einen Windowbeschleuniger bauen.

    Zitat von 0xdeadbeef

    Na ja, wenn schon, denn schon. Weil so eine Karte ja dann den Modulanschluß blockieren würde und damit auch Lösungen wie das U2+, müßte sie aus meiner Sicht heutzutage auch eine Möglichkeit mitbringen, Daten von einer SD-Kart oder einem USB-Stick zu laden und per DMA o.ä. ins RAM zu schreiben. Eventuell könnte man auch eine Easyflash-Simulation integrieren. Aber das sind ja letztendlich Details, über die man sich Gedanken machen könnte, wenn es an die tatsächliche Implementierung eines Moduls ginge.

    Stimmt schon. Die Programme würden wahrscheinlich auch irgendwann zu groß für eine 1541 Disk. Ich hab ein SD2IEC am seriellen Bus. Bin damit eigentlich zufrieden. Aber ich bin auch nicht die breite Masse.

    Gedanken an eine "Grafikkarte" gab es tatsächlich schon. Sie scheitern aber an Folgendem:


    1.) Die Bitmap-Grafik beim C64 ist tile-basiert. Pro Tile (= Kachel) stehen nur 4 Farben zur Verfügung. Möchte man in eine Bitmap sowohl Hintergrundgrafik als auch bewegliche Objekte einfügen, darf die Anzahl der Farben pro Tile nicht 4 überschreiten. Dies führt zu erheblichen Colour-Clashes, sofern man sich nicht von vornherein auf 4 Farben beschränkt, wie dies in den meisten 3d-Spielen der Fall ist (einzig mir bekannte Ausnahme: "Space Rogue").


    2.) Der DMA ist sehr langsam. Um eine vollständige Bitmap-Grafik ohne Farbram zu übertragen, braucht man schon 8000 Zyklen. Sehr, sehr grob geschätzt (ohne Bad-Lines etc) verfügt man pro Frame über 65 * 280 = 18200 Zyklen, d. h. fast die Hälfte geht bereits drauf zum Kopieren der Bitmap-Grafik. Wichtig: In dieser Zeit ist der Prozessor lahmgelegt. Er kann weder die Grafikkarte mit neuen Daten füttern, irgendwelche Berechnungen ausführen oder einen Interrupt bedienen (Ade Rasterinterrupt).


    3.) Es reicht nicht aus, nur das Malen der Polygone zu beschleunigen. Ein Großteil der Rechenarbeit steckt in der Animation der 3d-Objekte, d. h. die Bewegung durch den Raum, die Rotation der Objekte und die Kollisionserkennung. Ein Blitter kann diese Vorgänge nicht beschleunigen. Schaut man sich dir Grafik in einem 3d-Spiel wie "Elite" an, so sieht man zudem, daß die Polygone nur äußerst selten wirklich groß sind, z. B. wenn man sehr nahe an die Raumstation heranfliegt. Daraus ergibt sich auch, daß im Normalfall des Fluges durch den Raum der Einsatz eines Blitters kaum Beschleunigung ergeben kann. Für eine echte 3d-Beschleunigung ist es unausweichlich, auch andere Berechnungen per Hardware auszuführen.


    Aus den genannten Punkten ergibt sich jedoch, daß

    a) die Grafikdaten nicht umständlich in den Speicher des C64 kopiert werden können, weil dies zu viel Zeit beansprucht. Es ist vielmehr notwendig, der "Grafikkarte" einen eigenen Bildschirmspeicher mitzugeben mit gesondertem VGA-/HDMI-Anschluß.

    b) die Grafikkarte über einen eigenen Prozessor verfügen muß, um 3d-Berechnungen zu übernehmen. Da es sehr, sehr viele Möglichkeiten gibt, 3d-Daten zu berechnen ("Rescue on Fractalus", "Elite", "Driller", "Stunt Car Racer" etc funktionieren alle komplett anders in ihren Berechnungen.) kommt man mit einer einfachen Punktberechnung über Matrizen nicht weit. Es gibt einfach zu viele weitere komplizierte Berechnungen, die den Einsatz eines Prozessors erfordern.


    In Summe hätte man dann eine "Grafikkarte", welche über ihr Ram eigene Bilder erzeugt, einen ARM-Prozessor verwendet für die Berechnungen und den C64 nur gebraucht als Stichwortgeber. Es mag jeder für sich entscheiden, ob das dann noch ein C64 ist.

    Daß das Modul die Berechnungen mit übernimmt, war ja von Anfang an Teil des Plans. Und natürlich auch, daß das Modul über einen eigenen Speicher verfügt, aus dem sie sich Spriteobjekte, Polygondaten usw. holt.

    Natürlich müßte der C64 das Modul trotzdem irgendwann mit den Daten füttern.

    Aber OK, das Timing hatte ich mir nicht ganz so dramatisch vorgestellt. Wenn der Prozessor mindestens die Hälfte jedes Frames stillgelegt ist, kann man ja nicht mehr wirklich von paralleler Ausführung reden.

    Ein eigener Bildschirmausgang hat zwar natürlich viele Vorteile, aber nimmt dem ganzen Ansatz natürlich auch so ein bißchen den Charme. Fühlt sich dann ja ein bißchen an wie ein Turbo Chameleon.

    OK, war ja nur so eine Idee. Hatte ja befürchtet, daß es seine Gründe hat, daß es sowas noch nicht gibt...

    Man kann natürlich auch pro Frame nur die geänderten Daten übertragen oder sogar die Cycles für DMA pro Frame begrenzen, nur die "wichtigsten" visuellen Änderungen übertragen und die restlichen Änderungen für später, wenn die Bandbreite da ist, aufsparen. Das machen letztendlich viele Kompressionsalgorithmen für Video auch so. Würde sicher funktionieren, aber viel zu beweisen oder Neuland zu betreten gibt's da nicht.

    Witzig, ich gehe schon seit einiger Zeit mit genau dieser Idee schwanger. Ich habe mir auch schon erste FPGA Hardware Komponenten besorgt, die dann die technische Basis liefern sollen. Aber es scheitert wie so oft an der Zeit. Es waren immer andere Sachen wichtiger.


    Meine Grundidee wäre, dass das Bild aus dem VIC-II kommen soll. Dieser läuft dann in ein erweiterten FLI Farbmodus, wodurch mehr als nur 4 Farben pro tile möglich werden. Die nötigen genau getimeten Registerzugriffe werden per DMA zum richtigen Zeitpunkt gemacht, damit die CPU möglichst wenig damit zu tun hat. In der "Grafikkarte" gäbe es eine Schattenkopie des Grafikspeichers, damit dann nur die Updates seit dem letzten Bildzyklus per DMA zum C64 übertragen werden müssen. Das spart Bandbreite auf dem Bus.

    An Fähigkeiten dachte ich an Polygone-zeichnen, gewisse Berechnungen in Hardware (3D Matrix-Operationen, Mandelbrot Berechnungen, ...) und die Möglichkeit von aussen eingespeiste Bilder automatisch ins FLI Format zu rendern, wodurch z.b. ein angeflanschter Raspi als Webbrowser sein Bild zum C64 übertragen könnte, oder man könnte live-video auf dem C64 anschauen.


    Das Hauptproblem sehe ich darin, dass man existierende Spiele erst Mal aufwändig umprogrammieren müsste, damit sie die neuen Möglichkeiten nutzen, und dass es mangels Verbreitung der neuen Hardware auch kaum Leute geben würde, die dafür neue Software schreiben. Ein Henne ein Problem also.

    andi6510 Wieso FPGA? Mit z.B. der Hardware des Sidekick64 hätte man wenigstens eine etwas größere potenzielle Nutzerbasis, und vermutlich ggf. auch mehr Leute, die an der Firmware mitbasteln (die Hoffnung stirbt zuletzt). Oder schafft der RPi das nicht? DAS wäre ggf. eine Herausforderung. ;)

    Zitat von 1570

    andi6510 Wieso FPGA? Mit z.B. der Hardware des Sidekick64 hätte man wenigstens eine etwas größere potenzielle Nutzerbasis, und vermutlich ggf. auch mehr Leute, die an der Firmware mitbasteln (die Hoffnung stirbt zuletzt). Oder schafft der RPi das nicht? DAS wäre ggf. eine Herausforderung. ;)

    Vermutlich, weil ich mehr Bock auf FPGA als auf Software habe... ;-) Ich hätte mir jetzt einen Hybrid aus FPGA und Raspi vorgestellt.


    Mit dem Sidekick64 könnte das auch klappen. Das habe ich mir noch nicht im Detail angesehen. Aber da wäre ich dann wohl raus. Ich bin nicht so der Software-Mensch. Musste zu viel davon beruflich machen... ;-)

    Zitat von andi6510

    Vermutlich, weil ich mehr Bock auf FPGA als auf Software habe...

    Hm, je nachdem, wie man den Code an der Stelle strukturiert, nimmt sich VHDL/Verilog und C glaube ich gar nicht so viel. Ist etwas wie beim Code eines normalen Emulators: Klar kann man klassischen C-Code schreiben, zyklengenau (und sichtbar an der Hardware orientiert) wird's aber nur, wenn man eine große klar strukturierte State Machine draus macht, und das ist dann von VHDL nicht mehr gar so weit entfernt. :)

    Zitat von 0xdeadbeef

    Sprich: der C64 schreibt Befehlssequenzen mit Koordinaten, Grafikdaten für Sprites, Polygondaten, usw. in einen Datenbereich, den das Modul im Expansionsport abscannt und das Modul erzeugt daraus ein Bild und schreibt es direkt in den Grafikspeicher.

    Außerdem könnte man natürlich komplexe Float-Berechnungen und/oder Matrixoperationen über das Modul berechnen lassen, um die CPU des C64 zu entlasten.

    so in etwa https://github.com/frntc/Sidek…onSidekick64.mp4?raw=true oder https://www.dropbox.com/s/9cem…f9w/rotozoom.mp4.mp4?dl=0 ? :D

    (der Rasterisierer ist nicht wirklich fix, daher die niedrige Framerate)


    Das Sidekick64 kann aber keinen DMA-Transfer, das ist on-the-fly generierter Speedcode, der Differenzen der Bilder überträgt, d.h. die Geschwindigkeit ist maximal STA $addr * #geänderte Bytes (zzgl. LDA #val pro vorkommenden Wert). Natürlich könnte man auch die HDMI-Ausgabe nehmen und einen "beliebigen" Grafik-Chip, z.B. beschränkt und Farbe und Auflösung, emulieren. Im Endeffekt dreht es sich aber immer wieder um die schon aufgeworfene Frage, ob es noch ein C64 ist? (ich würde sagen: ähnlich, wie wenn man einen FPGA-basierten Grafikbeschleuniger baut -- aber sinngetrieben ist das ohnehin alles nicht ;-))

    Zitat von Hoogo

    Der Beamracer kommt dem doch in großen Teilen nahe, hier ein Thread dazu.

    Nach meinem Verständnis wird die Grafik dabei gar nicht zum C64 geschaufelt, sondern dem VIC bei seinen Halbtakten untergeschoben.


    Zitat von 1570

    Ja, aber das ist nicht nur FPGA-basierte Spezialhardware, sondern auch noch als VIC-Zwischensockel realisiert.

    Da kann man den VIC ja auch gleich komplett durch einen FPGA ersetzen...

    freut mich dass sich auch andi6510 schon Gedanken gemacht hat. ich auch.


    Der Beamracer Ansatz ist sicher die ultimative Lösung, erfordert aber einen Zwischensockel. Man könnte aber nahezu das gleiche auch per Steckmodul erreichen. Im Ultimax Modus addressiert auch der VIC-II externen Speicher. Da kann man dann auch per Modul beliebige Daten auf den Bus legen, der VIC-II liest das und stellt es dar. Lediglich die Registerzugriffe müssten dann die CPU anhalten und per DMA erfolgen. Kleiner Nachteil gegenüber Beamracer, der solche Zugriffe unabhängig von der CPU machen kann.


    den DMA Zugriff auf den Videospeicher kann man sich also komplett sparen. Allenfalls wäre DMA Zugriff auf das Farbram notwendig.