Hardware > Hardware (Classic 16-/32-Bit)

GK mit RPi für TT ua.?

<< < (6/12) > >>

joejoe:
hier noch die billige USB2.0 /USB3.0 Lösung:

https://www.ebay.de/itm/USB-3-0-2-0-zu-VGA-1080P-Multi-Display-Adapter-Konverter-Schwarz-Heis/153183756877?hash=item23aa76a24d:g:u20AAOSwDkVaJ67K


Allerdings:

--- Zitat ---System Requirements:

    Windows 7/8/10;
    CPU: Intel/AMD single Core 1.5GHZ or Higher processor;
    RAM: 512MB memory or higher;
    Available USB3.0/2.0 Hi-speed port.

Note: In USB 2.0 mode, the maximum resolution is 800x600 only, and in USB 3.0 mode, the maximum resolution can be 1080p.
--- Ende Zitat ---
Damit dürfte die USB1.1 Variante, egal wie umgesetzt, auch gestorben sein.

Arthur:
Gabs die Vampire nicht auch mit Grafikanschluss?

tuxie:
Jup die Vampire hat einen eingebauten SAGA Core mit HDMI Ausgang.

Gast160608:
Der Vampir ist hier OT - bitte anderswo diskutieren*. Hier geht es darum, ob eine GK mittels RPi möglich ist.
Ich fasse mal den Stand der Diskussion zusammen:

1) Eine auch für Spiele vollkompatible FrameBuffer-Lösung erscheint ausgeschlossen (das gilt wohl für jede Grafik-Karte, also auch hier).

2) Eine Lösung als ´VDI-Terminal´ sähe so aus: Man könnte den USB des Lightning an den RPi stöpseln. Dann müßten zunächst mal zwei kleinere Software-Teile geschrieben werde, nämlich ein abgespeckter GK-Treiber auf der TT-Seite (der nichts weiter tut, als alle VDI-Aufrufe an die USB-Schnittstelle weiterzuleiten) und ein abgespecktes Terminal auf der RPi-Seite (das nichts weiter tut, als die Daten vom USB in Empfang zu nehmen und an den Bildschirm-Treiber des BeePi weiterzuleiten). Damit könnte man schon mal einen Proof of Concept unternehmen. Wenn sich dabei erwartungsgemäß herausstellt, daß die Performance für die Raster-Ops. nicht ausreicht, müßte für die Richtung TT -> RPi eine schnelle Hardware-Anbindung des RAMs im TT an die CSI2-Schnittstelle des RPi konstruiert und bzgl. der Raster-OPs. in GK-Treiber & Terminal eingebunden werden. Damit sollte es bereits möglich sein, zB. Bilder in HiColor bequem anzusehen. Stellt sich dann aber heraus, daß auch rückwärts mehr Performance nötig ist, müßte ein CSI-2 für den TT konstruiert werden (für ca. 2 MegaPixel) und irgendwie schnell an das RAM im RPi gebunden werden. Der RPi samt TT-CSI2 würde auf einer Karte im VME-Schacht Platz nehmen.

3) Eine Emulator-Lösung sähe so aus: RPi & Arduino-Tastatur-IF kämen evtl. in´s ButterFach und wären da mittels BeePi auch sehr schnell betriebsbereit. Für die übrigen typischen Atari-Komponenten wie Midi, Romport, ACSI, SCSI, Floppy etc. müßten nach und nach weitere IFs für den RPi geschaffen werden. Platz dafür gäb´s auch noch im ButterFach, aber notfalls auch im VME-Schacht oder indem die interne Floppy entfernt würde.

Spiele wären in den letzteren beiden Fällen weiterhin mit der orig- Hardware des TT möglich.

*Eine solche Diskussion analog der hiesigen wäre ja durchaus wünschenswert!

Thorsten Otto:

--- Zitat von: ari.tao am Fr 16.11.2018, 03:15:48 ---2)  Dann müßten zunächst mal zwei kleinere Software-Teile geschrieben werde,

--- Ende Zitat ---

Ohne auch nur die geringste Ahnung davon zu haben wie das umzusetzen ist, weisst du also schon jetzt daß das nur "kleine" Software-Teile sind?


--- Zitat ---ein abgespecktes Terminal auf der RPi-Seite (das nichts weiter tut, als die Daten vom USB in Empfang zu nehmen und an den Bildschirm-Treiber des BeePi weiterzuleiten).

--- Ende Zitat ---

Wieso abgespeckt? Irgendwer wird auch irgendwann mal die ganzen VDI-Befehle ausführen müssen.

Ausserdem wird dabei wohl vergessen, daß eine Einbahnstrassen-Lösung nicht funktionieren wird. Jedes Menü, das herunterklappt, und jede Alert-Box, die dargestellt wird, hat zur Folge daß der Bildschirm-Hintergrund mittels vro_cpyfm gesichert wird, was auch eine Übertragung RPI->TT erfordert.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete