Raspberry Pi im Amiga als ...

[Chocco]

To pi or not to pi, that is the question!

Die Frage ist doch, was tatsächlich das Ziel sein soll. Möchte man native 68K-Software auf nativer Hardware laufen lassen, dann ist die Vampire sicher eine sehr elegante Wahl. Möchte man 68K-Software in einer Emulation laufen lassen, dann ist die Wahl des Host-Systems relativ egal, weil inzwischen alle Systeme schnell genug sind. Da reicht dann eben auch ein 30€ RPi.

Weiterhin kann man über ein Hybrid-System nachdenken. Ähnlich XWindows, könnte man ein "Terminal-VDI" einsetzen, um Grafik-Ausgaben und User-IO an einen Bildschirm zu schicken, der nicht zwangsweise Bestandteil eines (Atari) GEM-Computers ein muss. Da über das VDI alle IO-Funktionen bereitgestellt werden, könnte man sowas sicher realisieren.

AES und VDI sind im regulären TOS eng verknüpft. Ein AES, welches mit einem Terminal-VDI funktioniert, müsste entsprechend vorbereitet sein. Sämtliche mir bekannten AES wären aktuell dazu nicht in der Lage. Die AES gehen aktuell immer davon aus, per open workstation das Handle einer (internen) Grafikeinheit zu erlangen, die einen direkten Zugriff auf den Grafikspeicher erlaubt. Bei einem Terminal-VDI funktioniert das nicht.

Die VDI-Raster-Funktionen erwarten, dass ein Raster im Arbeitsspeicher adressiert werden kann. Damit kann auch der Bildspeicher gemeint sein, der bei einem Termial-VDI natürlich nicht adressiert werden kann. Sauber arbeitende Programme, die als Quell-/Zielrasterfür den Bildschirm NULL angeben, könnten weiterhin funktioneren. Hier wäre nur die Anbindungsgeschwindigkeit zum Transport der Rasterdaten der begrenzende Faktor.

Einen RPi als Client für ein Termial-VDI zu verwenden hätte den Charme, dass er über eine GPU verfügt, die im Vergleich zu allem, was sonst für die Atari-Plattform verfügbar ist, rasant schnell ist.

Andererseits ist auch sicher, dass nur Software, die sauber nach VDI/AES Regularien entwickelt wurde, mit einer solchen Lösung klar kommt.

[mfro]

... AES und VDI sind im regulären TOS eng verknüpft. Ein AES, welches mit einem Terminal-VDI funktioniert, müsste entsprechend vorbereitet sein. Sämtliche mir bekannten AES wären aktuell dazu nicht in der Lage...

Prinzipiell ist das - bei ausreichend Platz und ausreichend Performance - ein lösbares Problem (bzw. ist schon - zumindest teilweise - gelöst). Dem AES ist das relativ egal, es greift immer auf das VDI zurück, um irgendwelche Bildschirm-Manipulationen durchzuführen.

Im CT60 TOS gibt es eine ähnliche Problematik: der Speicher auf der Beschleunigerkarte is um ein Vielfaches schneller als der Grafikspeicher auf der "Legacy-" (Falcon-) Seite. Der fVDI VDI-Treiber im CT60 TOS führt deswegen (optional) *zwei* Bildschirmspeicher mit. Jedes direkt geschriebene Pixel wird *zweimal* geschrieben: im eigentlichen Bildschirmspeicher *und* im Shadow-Speicher im schnellen RAM.

Komplexere (read-modify-write) Screen-Memory Operationen können dann im schnellen RAM vorbereitet und nur das Ergebnis *einmal* in den (langsamen) "echten" Bildschirmspeicher übertragen werden.
Damit spart man in vielen Fällen eine (langsame) Leseoperation. Anscheinend ist es für komplexere Operationen (z.B. das Invertieren eines Menüpunktes - "lesen"-"XOR"-"schreiben") in der Summe schneller, das  im schnellen RAM zu tun und nur das Ergebnis in den "echten" Bildschirmspeicher zu schreiben. Die zusätzliche (schnelle) Schreiboperation kostet wohl weniger als die dadurch gesparte (langsame) Leseoperation.

Für einen ST wäre das allerdings ziemlicher Overkill und (wahrscheinlich) schnarchlangsam.

[Thorsten Otto]

AES und VDI sind im regulären TOS eng verknüpft. Ein AES, welches mit einem Terminal-VDI funktioniert, müsste entsprechend vorbereitet sein. 

Ganz so eng sind die nicht verküpft, zumindest nicht in TOS 2.x/TOS 3.x, und auch nicht in EmuTOS. Sonst wären ja auch andere VDI nicht so leicht in der Lage das zu ersetzen. Was dort verknüpft ist sind allerdings die BIOS-Funktionen die auf den Bildschirm ausgeben, die müssen dann auch entsprechend abgefangen werden. Ausserdem natürlich Line-A, das schon seit 1989 "deprecated" ist aber immer noch fleissig von einigen Programmen benutzt wird.

Die AES gehen aktuell immer davon aus, per open workstation das Handle einer (internen) Grafikeinheit zu erlangen, die einen direkten Zugriff auf den Grafikspeicher erlaubt.

s.o., das stimmt so nicht ganz. AES selber greift in keiner Weise direkt auf den Bildschirmspeicher zu oder macht da irgendwelche Annahmen, das geht alles über VDI-Funktionen.

[ari.tao]

...Jedes direkt geschriebene Pixel wird *zweimal* geschrieben: im eigentlichen Bildschirmspeicher *und* im Shadow-Speicher im schnellen RAM.
Komplexere (read-modify-write) Screen-Memory Operationen können dann im schnellen RAM vorbereitet und nur das Ergebnis *einmal* in den (langsamen) "echten" Bildschirmspeicher übertragen werden. 

Verstehe ich das richtig, daß der CT60 ein eigener Video-Port fehlt? Das wäre ja mit dem RasPi anders (und mit dem Vampir (hoffentlich) auch).

[mfro]

Verstehe ich das richtig, daß der CT60 ein eigener Video-Port fehlt?

Die CT60 benutzt ohne Zusatzhardware das ganz normale Falcon-Videosystem.

Das wäre ja mit dem RasPi anders.

... und was würde das nutzen, wenn der Bus dahin ein Bummelzug ist?

[1ST1]

@ari.tao: TT und Falcon würde ich bei der Betrachtung außen vor lassen, die haben VGA, was vielfach von noch halbwegs modernen TFTs unterstützt wird, und VGA-zu-HDMI-Konverter sind auch kein Hexenwerk, DVI-I frisst das per mechanischem Adapter direkt, und das Bild bei VGA bei nicht übertriebener Kabellänge ist gut. Für TT und Falcon gibts auch bereits genügend Grafik-, Netzwerkkarten und tlw, USB.

@mfro : Freut mich, dass es endlich Klick gemacht hat und , Danke @Chocco.

Ob aus der Idee was werden kann, ist eine andere Sache.

[mfro]

@mfro : Freut mich, dass es endlich Klick gemacht hat und , Danke

Klick?

Beim Falcon mit CT60 reden wir von der Differenz der Speicherbandbreiten zwischen mehreren hundert MB/s und wenigen MB/s, das "doppelt halten" von Videospeicher ist nicht schlimm, weil Platz genug da und die CPU schnell genug ist.

Das ist mit der Situation in einem ST und einem - noch so schnellen - Pi (mit immer noch langsamen GPIOs) m.E. nicht mal ansatzweise vergleichbar. Wenn der ST zweimal in seinen Videospeicher schreiben müsste, um ein Bild zu bekommen, würde in keiner mehr benutzen wollen. Tut mir leid, für mich ist das weiterhin eine Schnapsidee.

[1ST1]

Wie geschrieben, es geht nicht um den Falcon.

[ari.tao]

Mal angenommen, es geht am ST: Warum sollte es dann an F30 & TT nicht gehen?
Bin mal gespannt, was bei tuxies Tests mit SPI herauskommt. Und wo der Vampir anbeißt.

=======

Kennt sich jemand mit der Einbindung von CoProcs aus?

[1ST1]

Beim TT und Falcon wird sowas schlicht nicht gebraucht, weil es dafür alles gibt.

[Chocco]

AES und VDI sind im regulären TOS eng verknüpft. Ein AES, welches mit einem Terminal-VDI funktioniert, müsste entsprechend vorbereitet sein. 

Ganz so eng sind die nicht verküpft, zumindest nicht in TOS 2.x/TOS 3.x, und auch nicht in EmuTOS. Sonst wären ja auch andere VDI nicht so leicht in der Lage das zu ersetzen. Was dort verknüpft ist sind allerdings die BIOS-Funktionen die auf den Bildschirm ausgeben, die müssen dann auch entsprechend abgefangen werden. Ausserdem natürlich Line-A, das schon seit 1989 "deprecated" ist aber immer noch fleissig von einigen Programmen benutzt wird.

Stimmt, ich habe mich ungenau ausgedrückt. Ich hatte mir explizit nur XaAES angeschaut und dort wird während der Initialisierung ziemlich viel "ausprobiert" und "gehofft", welche workstation-ID denn nun zu nehmen sei. Beim TOS-AES wird wohl einfach das XBIOS befragt (?).

Die AES gehen aktuell immer davon aus, per open workstation das Handle einer (internen) Grafikeinheit zu erlangen, die einen direkten Zugriff auf den Grafikspeicher erlaubt.

s.o., das stimmt so nicht ganz. AES selber greift in keiner Weise direkt auf den Bildschirmspeicher zu oder macht da irgendwelche Annahmen, das geht alles über VDI-Funktionen.

Danke für die Aufklärung. Ich hatte überschlägig im TOS-AES eigene Blt-Funktionen gesehen und war davon ausgegangen, dass hier seitens Atari "optimiert" wurde. Wenn diese Funktionen jedoch selbst wieder das VDI aufrufen, dann ist ja alles in Butter.