Grafik per ACSI/DMA?

[goetz @ 3rz]

Hallo,

gab’s nicht mal eine externe Box, um per ACSI einen Grafikausgang an den ST zu hängen? WIMRE war das dadurch ausgebremst, dass es in der Frühzeit der sauberen Programmierung war, und daher der Treiber den Grafikspeicher aus dem RAM dauernd umkopieren mußte, was das reichlich träge macht.

Wenn man dagegen einen VDI-Treiber hätte, analog einer „modernen“ Grafikkarte, sähe das schon anders aus. Ich kam drauf, weil nebenan hat akuker im Projekt RaSCSI nun einen Reifegrad erreicht (Massenspeicher als Image auf einem RasPi, der per speziellem kleinem Hat am SCSI-Bus hängt, und damit Massenspeicher „emuliert“, und „durchreichen“ des Ethernet-Interfaces des Pis zum Hostcomputer), dass nun andere (jcs) darauf aufsetzen und einen Framebuffer am Mac hängen haben, per SCSI zum Raspi, der das Bild per HDMI ausgibt.

Das könnte man auch schöner haben ohne Framebuffer-Kopiererei … und da wollte ich gucken, wie das damals genau war.

Aber ich erinnere mich nicht mehr an den Namen der „DMA-Grafikkarte“. Jemand?

[Lukas Frank]

Nie von so etwas gehört oder gelesen aber das heißt ja nichts ...

Ungewöhnliche Grafikkarte am ST war die Odin Erweiterung.

[Thorsten Otto]

Das könnte man auch schöner haben ohne Framebuffer-Kopiererei … und da wollte ich gucken, wie das damals genau war.

Die kopiererei kannst du vermutlich nur vermeiden, indem du für beide Seiten einen Treiber schreibst: einen auf Atari-Seite der die VDI-kommandos an ACSI schickt (dürfte nicht mal schwer sein, ist im wesentlichen das gleiche wie metafile Ausgabe, nur daß man sie evtl. buffern musst damit sie Sektor-weise geschrieben werden können), und einen auf der "anderen" Seite (vermutlich RasPI was dann da dran hängt?) der die Kommandos auswertet, umsetzt, und in einen Framebuffer schreibt der dann dort ausgegeben wird. Auch das sollte gar nicht mal so schwer sein (muss ja vermutlich am Anfang erst mal funktionieren und nicht gleich hoch-optimiert sein).

[czietz]

Am Atari hat der CosmosEx wimre doch eine Screencast-Funktion, die das (schlichtere) Prinzip des Framebuffer-über-ACSI-Kopierens umsetzt. Habe ich schon einmal im Netz gesehen, finde ich aber gerade nicht wieder.

[goetz @ 3rz]

Die kopiererei kannst du vermutlich nur vermeiden, indem du für beide Seiten einen Treiber schreibst: einen auf Atari-Seite der die VDI-kommandos an ACSI schickt (dürfte nicht mal schwer sein, ist im wesentlichen das gleiche wie metafile Ausgabe, nur daß man sie evtl. buffern musst damit sie Sektor-weise geschrieben werden können), und einen auf der "anderen" Seite (vermutlich RasPI was dann da dran hängt?) der die Kommandos auswertet, umsetzt, und in einen Framebuffer schreibt der dann dort ausgegeben wird. Auch das sollte gar nicht mal so schwer sein (muss ja vermutlich am Anfang erst mal funktionieren und nicht gleich hoch-optimiert sein).

Das meinte ich. Für den Mac gab es das für QuickDraw, das spielt prinzipiell ungefähr auf der Höhe von VDI. "ScuzzyGraph" war eine externe Box, die per SCSI angeschlossen dann RGB-Outputs bot für 1024x768 in 256 Farben, und die wurde mit einem spezifischen Treiber angesteuert, der die QD-Kommandos eben per SCSI verschickte. Die Gegenstelle in der SCSI-Box war mit einem 68000/8 mit bissl lokalem RAM und einem VDC realisiert.

Den SCSI-Adapter für Raspi samt Raspi hätte ich hier, wenn ich den verleihen soll … :-)

[Thorsten Otto]

Nachteil einer solchen Lösung wäre natürlich, daß du dann die Ausgaben erstmal *nur* auf dem RasPi hast. Auf Twitter war eine Lösung zu sehen, wo der Bildschirm quasi gespiegelt wird. Dazu müsste man die Ausgaben auch an den ursprünglichen Bildschirm-Treiber durchreichen.
Denke mal, so eine Lösung (mit framebuffer kopieren) ist auf jedenfall einfacher zu realisieren. Da der Mac ja auch nur einen 68000 hat, müsste das auch von der Performance her irgendwie gehen. Auf 50 Frames/sec wird man dann wohl allerdings nicht kommen.

[KarlMüller]

gab’s nicht mal eine externe Box, um per ACSI einen Grafikausgang an den ST zu hängen?

Neben dem genanntem Odin fällt mir zur Zeit nur noch Omega Cad ein. Das wurde allerdings an den ROM Port angeschlossen.
https://www.stcarchiv.de/stc1988/01/omega-cad

[goetz @ 3rz]

Nachteil einer solchen Lösung wäre natürlich, daß du dann die Ausgaben erstmal *nur* auf dem RasPi hast. Auf Twitter war eine Lösung zu sehen, wo der Bildschirm quasi gespiegelt wird.

Beim Mac geht Multi-Monitor-Betrieb. Am ST geht das halt nicht. Aber das ist ja nicht anders, wenn man eine ET4000 einbaut -- den ST-Videomodus verliert man für die tägliche Arbeit in GEM dann ja auch.

Dazu müsste man die Ausgaben auch an den ursprünglichen Bildschirm-Treiber durchreichen.
Denke mal, so eine Lösung (mit framebuffer kopieren) ist auf jedenfall einfacher zu realisieren. Da der Mac ja auch nur einen 68000 hat, müsste das auch von der Performance her irgendwie gehen. Auf 50 Frames/sec wird man dann wohl allerdings nicht kommen.

Am Mac Plus war’s schon eher laggy, so bei geschätzt 10fps. Der ist zwar eine Ecke langsamer als der ST, aber umkopieren hat halt auch den Nachteil, dass man über ST-Hoch nicht hinauskommt. Schick bei der Ausgabe per Raspi-HDMI wäre ja, dann bspw. 1024x768 in monochrom oder so haben zu können. Oder auch in 16 Farben.

[Lukas Frank]

MATRIX hatte mal eine Dual Monitor Betrieb Lösung meine ich mit Werkzeug Palette auf dem SW Monitor und das Bild auf dem Farbschirm. Und für Calamus SL war da mal was meine ich ...

[tuxie]

Am Atari hat der CosmosEx wimre doch eine Screencast-Funktion, die das (schlichtere) Prinzip des Framebuffer-über-ACSI-Kopierens umsetzt. Habe ich schon einmal im Netz gesehen, finde ich aber gerade nicht wieder.

Ja hat es und funktioniert ganz gut. Da wird das ganze zu einem anderen Rechner geschickt und du hast das Display im Browser. Aber ob das jetzt für mehr als für simple GEM Anwendungen geht wage ich zu bezweifeln.

[mfro]

Am Mac Plus war’s schon eher laggy, so bei geschätzt 10fps. Der ist zwar eine Ecke langsamer als der ST, aber umkopieren hat halt auch den Nachteil, dass man über ST-Hoch nicht hinauskommt. Schick bei der Ausgabe per Raspi-HDMI wäre ja, dann bspw. 1024x768 in monochrom oder so haben zu können. Oder auch in 16 Farben.

Framebuffer kopieren? Na ja - gehen tät' das wohl schon, aber Spaß macht's keinen, denke ich.

Einfach zu rechnen: "einfach" mal den Framebuffer kopieren: ACSI schafft 1 MB/s.
640x400 in monochrom sind 32000 Bytes oder eben 0,03 MB - theoretisch schafft man also 32 Hz.
Bloss das dann der ST nichts anderes mehr macht.

Farbe: 1024x768 in 16 Farben wäre wohl das Geringste, was man haben wollte?
Da schafft man nur noch 2,6 Hz ohne was anderes zu tun.

Wenn man nur die veränderten Bildschirmteile kopiert (ähnlich wie VNC, z.B.), geht's natürlich schneller, dafür beschäftigt man dann die CPU - mehr als die dreifache Geschwindigkeit würde ich da nicht erwarten und das wäre (leider) immer noch zu lahm, um damit was Vernünftiges anzufangen.

Anderer Ansatz: Linien malen (Farbe, x1, y1, x2, y2) sind 9 Bytes. Nichts anderes getan und davon ausgegangen, daß der Pi oder was auch immer das packt, würde man damit 116000 Linien (oder Kreise, Flächen mit und ohne Füllmuster, ...) in der Sekunde schaffen. In 256 Farben, wohlgemerkt.

Deutlich schneller als jeder ST (und Falcon, TT, ...).

[Arthur]

Da macht Framebuffer mit der ganzen kopiererei keinen Sinn... dann schon eher Grafikbefehle die auf dem Zieldevice ausgeführt werden... wie @mfro schrieb. Aber die Odin zeigte  zumindest was mit FB möglich war. Viele wären ja schon zufrieden wenn wenigstens die Bildfrequenzen vga-kompatibel wären.

[goetz @ 3rz]

Am Mac Plus war’s schon eher laggy, so bei geschätzt 10fps. Der ist zwar eine Ecke langsamer als der ST, aber umkopieren hat halt auch den Nachteil, dass man über ST-Hoch nicht hinauskommt. Schick bei der Ausgabe per Raspi-HDMI wäre ja, dann bspw. 1024x768 in monochrom oder so haben zu können. Oder auch in 16 Farben.

Framebuffer kopieren? Na ja - gehen tät' das wohl schon, aber Spaß macht's keinen, denke ich.

Ja, äh, aber das schrieb ich doch oben? VDI-Einbindung, und dass Framebuffer kopieren eher oll’ ist? :-)

[Chocco]

Eine ähnliche Diskussion hatten wir 2018 schon (https://forum.atari-home.de/index.php/topic,14793.0.html)

Framebuffer ist indiskutabel, weil die Framerate unterirdisch wird.
Die Übertragung der VDI-Befehle wäre möglich, würde Speed bringen und tatsächlich relativ einfach zu realisieren sein. Wir hatten damals festgestellt, dass einzig die Übertragung von Bitmaps problematisch wird, weil Caching zwar angezeigt wäre, aber aktuell kein Mechanismus existiert, der eine Änderung der Bitmap auf dem ST feststellen könnte.

Alle Mausbewegungen müssten natürlich permanent in kleinsten Datenpäckchen übertragen werden. SCSI/ASCI arbeitet (glaub ich) Block orientiert, was die Effizienz deutlich vermindern würde. 

[goetz @ 3rz]

Eine ähnliche Diskussion hatten wir 2018 schon (https://forum.atari-home.de/index.php/topic,14793.0.html)

Was wir seitdem wissen: Der GPIO (mindestens) des RasPi 3 B+ ist mehr als schnell genug für ACSI/DMA.  Mit einem RasPi 4 kommt man bis zu 1,4 MB/s in der Spitze. Benchmarks.