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

GK mit RPi für TT ua.?

<< < (7/12) > >>

Arthur:

--- Zitat von: ari.tao am Fr 16.11.2018, 03:15:48 ---Der Vampir ist hier OT - bitte anderswo diskutieren*. Hier geht es darum, ob eine GK mittels RPi möglich ist.

--- Ende Zitat ---

Sorry

joejoe:

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

--- Ende Zitat ---

genau, daher wird es nicht um schneller, sondern maximal um höhere Auflösung (und damit eher langsamer) gehen


--- Zitat ---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.

--- Ende Zitat ---

Klar, die CSI2 Schnitte ist übrigens sowieso unidirektional (bis auf einen IIC-Bus)
Daher kann eine realistische Lösung für den Legacy-Mode nur heißen, der ATARI verwaltet den Bildschirmspeicher weiterhin selbst. Dieser wird parallel (wie synchronisiert?) von dem zu konstruierenden CSI-Treiber (vermutlich mit eigener CPU/oder DMA) ausgelesen und zum Rpi transportiert.

Allerdings könnten Beschränkungen aufgrund der vorhanden ATARI Grafik-Hardware entfallen, welche sich aus Pixeltakt, Farb-Mode, erwartetes Monitor-Timing etc. ergeben.

Heißt, der Bildschirm (und damit der verwendete ATARI Speicher) dürfen größer werden, das Timeing zum Monitor besorgt der RPI. Wie die Daten transportiert und vom RPI (bzw dessen GPU?) interpretiert/gemappt werden müssen, ist zunächst unklar, Auch, was das für einen Aufwand bedeutet.

Gast160608:
Es wurde bereits darauf hingewiesen, daß BeePi ein VDI enthält.
Die Sicherung von Bild-Hintergründen könnte im RPi erfolgen, dafür muß man nix in den TT zurücktransportieren: Eben deshalb bliebe es zunächst mal offen, ob überhaupt die Konstruktion eines CSI für den TT erforderlich wäre. Das nämlich war die Idee mit dem MetaFile - besser müßte man wohl von einem MetaStream sprechen: Dem Grunde nach die in GEM eingebaute Bild-Komprimierung.
Die gesamte Verwaltung des Bildschirmspeichers läge ausschließlich beim RPi und wäre dort blitzschnell: Das ist der Terminal-Gedanke.
Das etwas ungewohnte an diesem Entwurf ist natürlich, daß der schnelle RPi das Terminal stellt, und der langsame TT den Server.

PS: Muß ich Dir, Thorsten, jetzt auch noch erklären, was im Deutschen ein Komparativ bedeutet?

Thorsten Otto:

--- Zitat von: ari.tao am Fr 16.11.2018, 11:52:03 ---Es wurde bereits darauf hingewiesen, daß BeePi ein VDI enthält.

--- Ende Zitat ---

Und wo soll das herkommen? Auf jeden Fall ist es nicht für die hier besprochene Lösung.


--- Zitat ---Die Sicherung von Bild-Hintergründen könnte im RPi erfolgen, dafür muß man nix in den TT zurücktransportieren:

--- Ende Zitat ---

Das wird nicht funktionieren. vro_cpyfm in den Speicher muss auch in Speicher kopieren der vom Atari angesprochen werden kann. Stichwort z.B. Snapshot-Programme.


--- Zitat ---Dem Grunde nach die in GEM eingebaute Bild-Komprimierung.

--- Ende Zitat ---

Wie kommst den denn jetzt darauf daß da irgendwas komprimiert ist???


--- Zitat ---Das etwas ungewohnte an diesem Entwurf ist natürlich, daß der schnelle RPi das Terminal stellt, und der langsame TT den Server.

--- Ende Zitat ---

Nein eigentlich nicht. Im Grunde wäre das ähnlich wie bei X11. Der Server wäre in dem Fall der RPi, während auf dem Client (TT) die Programme laufen. Unterschied ist nur daß Tastatur/Maus am TT hängen.

mfro:

--- Zitat von: Thorsten Otto am Fr 16.11.2018, 13:03:44 ---Wie kommst den denn jetzt darauf daß da irgendwas komprimiert ist???

--- Ende Zitat ---

Ich denke, er meint das VDI-Metafile-Format. Komprimiert ist da aber nix, das sind im Wesentlichen die Inhalte der VDI-Parameterfelder 1:1 in eine Datei geschrieben.

Schlimmer: VDI Metafile-Treiber (und damit Metafiles) kennen etliche VDI-Funktionen nicht, die Bildschirmtreiber haben müssen, damit die AES sie akzeptieren. Z.B. - wie schon genannt - die Rasterfunktionen, sämtliche v_cur_xxx VT52-Funktionen, keine Locator-Funktionen, keine virtuellen Workstations, keine vex_xxx "Funktionszeiger" und noch ein paar mehr.

Kurz: das Metafile-Format wäre so gut oder schlecht wie jedes andere, "selbstgebaute" Format auch bzw. schlechter (weil es ohne GDOS nicht liefe).

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete