Non-ATARI > Hardware
Raspberry Pi im Amiga als ...
Chocco:
--- Zitat von: ari.tao am Mo 29.04.2019, 20:44:43 ---To pi or not to pi, that is the question!
--- Ende Zitat ---
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:
--- Zitat von: Chocco am Di 30.04.2019, 01:01:52 ---... 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...
--- Ende Zitat ---
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:
--- Zitat von: Chocco am Di 30.04.2019, 01:01:52 ---AES und VDI sind im regulären TOS eng verknüpft. Ein AES, welches mit einem Terminal-VDI funktioniert, müsste entsprechend vorbereitet sein.
--- Ende Zitat ---
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.
--- Zitat ---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.
--- Ende Zitat ---
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:
--- Zitat von: mfro am Di 30.04.2019, 07:49:34 ---...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.
--- Ende Zitat ---
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:
--- Zitat von: ari.tao am Di 30.04.2019, 11:05:28 ---Verstehe ich das richtig, daß der CT60 ein eigener Video-Port fehlt?
--- Ende Zitat ---
Die CT60 benutzt ohne Zusatzhardware das ganz normale Falcon-Videosystem.
--- Zitat von: ari.tao am Di 30.04.2019, 11:05:28 ---Das wäre ja mit dem RasPi anders.
--- Ende Zitat ---
... und was würde das nutzen, wenn der Bus dahin ein Bummelzug ist?
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln