Autor Thema: GK mit RPi für TT ua.?  (Gelesen 39141 mal)

0 Mitglieder und 2 Gäste betrachten dieses Thema.

Offline Arthur

  • Benutzer
  • Beiträge: 10.311
  • Mein Atari erinnert mich an die gute alte Zeit..
Re: GK mit RPi für TT ua.?
« Antwort #20 am: Do 15.11.2018, 07:34:42 »
Bei 4K Auflösungen am TV geht 30Hz ja auch ohne Flackern... dann wird eben erst jedes 2te Bild aktualisiert und eins wird zwischengespeichert o.ä.. Das ginge also schon so wie Ingo es schrieb.

Ist aber fürn ST bzw STE nicht zu stemmen.

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: GK mit RPi für TT ua.?
« Antwort #21 am: Do 15.11.2018, 10:07:49 »
Im Moment geht´s nur um Ataris mit VME-Bus. Für die ´Kleinen´ fehlt wohl etwas Ü-Rate.

Wenn 30Hz für´s Kino reicht, dann doch wohl auf ´nem Atari erst recht... Aber ´FrameBuffer´ geht dann immer noch nicht: Bei 2K Auflösung mit 1Byte Farbtiefe müßte man 60MB/s schaffen. Aber via ´VDI-Terminal´ käme man wohl mit einem kleinen Bruchteil davon aus. Dann sollte doch auch 50Hz mit 2 oder sogar 3 Bytes Farbtiefe möglich sein?
Ein VDI wäre doch in BeePi schon vorhanden. Ein GDOS auch? Dann müßte nur der via VME übertragene MetaFile auf dem RPi dargestellt werden...
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Online joejoe

  • Benutzer
  • Beiträge: 232
Re: GK mit RPi für TT ua.?
« Antwort #22 am: Do 15.11.2018, 18:46:46 »
Na, wenn es denn USB sein soll, dann braucht doch "nur noch jemand" z.B. für diese fertige Hardware:

https://www.amazon.de/Valueline-CMP-USBVGA11-VGA-DVI-Grafikadapter-USB/dp/B003ZVJPXE/ref=sr_1_24?ie=UTF8&qid=1542303323&sr=8-24&keywords=usb+grafikadapter

einen GDOS-Treiber schreiben. ;)

btw. ich habe damals Tage gebraucht, eine vergleichbare Hardware für meinen auf Stromsparen getrimmten Linux Server (gänzlich ohne dauerhaft eingebauten Grafik-Adapter) an diesem System ans Laufen zu bekommen. Und da ging es nur ums Bauen, Installieren und Konfigurieren des im Source vorhandenen Treibers.


Offline Lukas Frank

  • Benutzer
  • Beiträge: 13.431
  • fancy Atari Musik anDA Dance "Agare Hinu Harukana"
Re: GK mit RPi für TT ua.?
« Antwort #23 am: Do 15.11.2018, 18:59:03 »
Setzt das ganze nicht zwingend USB 2.0 voraus? Der Atari kann ja nur USB 1.1

Online joejoe

  • Benutzer
  • Beiträge: 232
Re: GK mit RPi für TT ua.?
« Antwort #24 am: Do 15.11.2018, 19:29:49 »
Ich hatte gehofft, durch die Anführungsstriche um das "nur noch jemand" schon darauf hinzuweisen, dass das nicht ganz Ernst gemeint ist.
Denn vermutlich braucht das schon USB 2.0, die aktuellen exterenen USB-Grafikkarten sogar USB 3.0.
Wenn man sich überlegt, was so ein Teil vermutlich macht /bzw beinhaltet ist das so etwas wie ein per USB angebundener Shifter, denn der Framebuffer wird im PC/MAC-RAM angelegt sein und die USB-Schnitte liefert passende Datenhappen an den externen Adapter, welcher diese an den HDMI-Wandler weitergibt. Die Daten müssen aber immer noch aktiv über den USB-Bus geschaufelt werden, eine GHz X86-CPU macht das, eine 8/16/32MHz CPU dürfte damit bereits ausgelastet sein. Was nützt mir ein hochauflösendes Bild, wenn kein Dampf für eine Anwendung übrig bleibt?

Nett wäre es aber, einen NOVA-Ersatz zu haben. Mit den gegebenen Beschränkungen bezüglich Auflösung und Farbtiefe, aber moderner Video-Schnittstelle (HDMI). Ein RPI hat das bis auf das Dualported RAM zum ATARI-Bus alles onboard. Der ATARI schreibt (und liest) die Grafikdaten in ein per 68000er oder VME-Bus angeschlossenes RAM, auf dieser Karte sitzt dann statt z.B. der ET4000 GPU  ein logic device, welches ähnlich wie ein RAM-DAC die Daten serialisiert und nur in eine Richtung (z.B. über die CSI-2 Schnittstelle) an den RPI liefert. Der hat dann genug Speicher und Power, um die Daten ggf. passend zu verwürfeln und sie in den eigenen Framebuffer zu schreiben. Das wird dann aber keinen Deut schneller als mit einer originalen (VME-)Grafikkarte. Ob das billiger als ein Nova-Adapter wäre, glaube ich allerdings auch nicht.

Das wäre dann der Kompatibilitäts-Modus eines ATARI/RPI Gespanns.
Im Emulationsmodus läuft alles bis auf das I/O (ausser Grafik) auf dem RPI, der bisher nicht ealisierte Zugriff auf vórhandene ATARI-Hardware am ATARI durch den RPI (die nächste Aufgabe) würde den Retro-Charme erhöhen.
 
« Letzte Änderung: Do 15.11.2018, 19:48:19 von joejoe »

Online joejoe

  • Benutzer
  • Beiträge: 232
Re: GK mit RPi für TT ua.?
« Antwort #25 am: Do 15.11.2018, 19:38:23 »
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.
Damit dürfte die USB1.1 Variante, egal wie umgesetzt, auch gestorben sein.

Offline Arthur

  • Benutzer
  • Beiträge: 10.311
  • Mein Atari erinnert mich an die gute alte Zeit..
Re: GK mit RPi für TT ua.?
« Antwort #26 am: Do 15.11.2018, 20:55:31 »
Gabs die Vampire nicht auch mit Grafikanschluss?

Offline tuxie

  • Benutzer
  • Beiträge: 6.836
  • Falcon! Milan! Schuetzt die Raubvoegel!
Re: GK mit RPi für TT ua.?
« Antwort #27 am: Do 15.11.2018, 22:52:14 »
Jup die Vampire hat einen eingebauten SAGA Core mit HDMI Ausgang.
Tschau Ingo

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: GK mit RPi für TT ua.?
« Antwort #28 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.
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!
« Letzte Änderung: Fr 16.11.2018, 03:25:32 von ari.tao »
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: GK mit RPi für TT ua.?
« Antwort #29 am: Fr 16.11.2018, 06:26:04 »
2)  Dann müßten zunächst mal zwei kleinere Software-Teile geschrieben werde,

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

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.

Offline Arthur

  • Benutzer
  • Beiträge: 10.311
  • Mein Atari erinnert mich an die gute alte Zeit..
Re: GK mit RPi für TT ua.?
« Antwort #30 am: Fr 16.11.2018, 08:09:34 »
Der Vampir ist hier OT - bitte anderswo diskutieren*. Hier geht es darum, ob eine GK mittels RPi möglich ist.

Sorry

Online joejoe

  • Benutzer
  • Beiträge: 232
Re: GK mit RPi für TT ua.?
« Antwort #31 am: Fr 16.11.2018, 10:10:13 »
Zitat
Wieso abgespeckt? Irgendwer wird auch irgendwann mal die ganzen VDI-Befehle ausführen müssen.

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.

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.
« Letzte Änderung: Fr 16.11.2018, 11:04:09 von joejoe »

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: GK mit RPi für TT ua.?
« Antwort #32 am: Fr 16.11.2018, 11:52:03 »
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?
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: GK mit RPi für TT ua.?
« Antwort #33 am: Fr 16.11.2018, 13:03:44 »
Es wurde bereits darauf hingewiesen, daß BeePi ein VDI enthält.

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:

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.

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.

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.

Offline mfro

  • Benutzer
  • Beiträge: 1.640
Re: GK mit RPi für TT ua.?
« Antwort #34 am: Fr 16.11.2018, 14:50:35 »
Wie kommst den denn jetzt darauf daß da irgendwas komprimiert ist???

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).
« Letzte Änderung: Fr 16.11.2018, 14:52:12 von mfro »
And remember: Beethoven wrote his first symphony in C

Offline CDAR-504

  • Benutzer
  • Beiträge: 93
  • Bin wieder da!
Re: GK mit RPi für TT ua.?
« Antwort #35 am: Fr 16.11.2018, 16:05:01 »
Seid Ihr nicht alle ein wenig am Ziel vorbeigeschossen?  :P
Eine Grafikkarte für den TT durch aktuelle Hardware (RPi) emulieren....!?

Da kann man doch glatt einen kompletten Atari-Emulator auf aktueller Hardware laufen lassen.

Hier geht es doch um klassische alte 16/32bit-Hardware. (siehe Forum-Subthema)
Ich sehe da wenig Sinn, diese noch außerhalb der bisherigen Standards aufzublasen.

Offline Lukas Frank

  • Benutzer
  • Beiträge: 13.431
  • fancy Atari Musik anDA Dance "Agare Hinu Harukana"
Re: GK mit RPi für TT ua.?
« Antwort #36 am: Fr 16.11.2018, 17:11:42 »
Ich finde es etwas befremdlich als Grafikkarte einen kompletten modernen Mini Rechner zu benutzen. Eine CosmosEx ist/wäre auch genauso nicht mein Fall.

Offline Chocco

  • Benutzer
  • Beiträge: 228
  • May the force be with you
Re: GK mit RPi für TT ua.?
« Antwort #37 am: Fr 16.11.2018, 20:22:59 »
Seid Ihr nicht alle ein wenig am Ziel vorbeigeschossen?  :P
Eine Grafikkarte für den TT durch aktuelle Hardware (RPi) emulieren....!?

Da kann man doch glatt einen kompletten Atari-Emulator auf aktueller Hardware laufen lassen.

Für mich war es eher ein Gedanken-Experiment. Was könnte man tun, wenn man so etwas wollte und auf welche Probleme stößt man dabei?

Es kommt ja auch immer darauf an, was man mit seinen alten Atari-Kameraden anstellen möchte und in den meisten Fällen ist die  komplette Emulation der Maschine über eine 35€ RPi oder etwas x86 basiertes absolut sinnvoll, was im Emulation-Forum ja auch besprochen wird.
Atari TT030 mit CrazyDots
Milan 060 (ATI Rage Pro)
Apple MBP

Offline ari.tao

  • Benutzer
  • Beiträge: 2.248
  • Gesperrter User
Re: GK mit RPi für TT ua.?
« Antwort #38 am: So 18.11.2018, 05:01:46 »
Die Sinnfrage einer GK mit RPi als Grafik-Prozessor beantwortet sich direkt aus der Machbarkeit; ggü. zB. einer Nova hätte sie nämlich drei dicke Vorteile:
a) HW deutlich billiger und leichter zu beschaffen.
b) wesentlich kleiner, paßt in den VME-Schacht: Kein Kloben mehr oben auf dem TT.
c) Dennoch eine deutlich höhere Grafik-Auflösung.
Wer eine noch günstigere Lösung weiß, der möge sie aufzeigen (in einem anderen Thread bitte)! Es wäre ja nicht das erste Mal, daß ein weiterer Prozessor im Atari Platz nimmt, der für einen speziellen Zweck leistungsfähiger ist als sein 680x0er Chef... Daran kann ich nix befremdlich finden, und der TT wird dadurch auch nicht weniger ´klassisch´.
-------
vro_cpyfm in den Speicher muss auch in Speicher kopieren der vom Atari angesprochen werden kann. Stichwort z.B. Snapshot-Programme.
Da hast Du Dir aber ein sehr schlechtes Bsp. als Beleg für Deinen Widerspruch ausgesucht: Ich wäre gern bereit, auf einen SnapShot vom gesamten Bildschirm mal 7 sec zu warten.
-------
Eine weitere Frage an unsere HW-Experten: Könnte man den RPi nicht asynchron als CoProzessor an den TT anbinden? Und dann den VDI-Trap so modden, daß alle Aufrufe direkt an den RPi gehen? Das müßte doch eine deutlich schnellere Anbindung ergeben als via USB mit seinem lahmen Stack. Oder hatte tuxie genau das in #1 schon abgehakt?
Falcon+ddd32MHz, TT+CrazyDotsGK und noch ein paar andere.

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 1.315
Re: GK mit RPi für TT ua.?
« Antwort #39 am: So 18.11.2018, 06:11:29 »
Da hast Du Dir aber ein sehr schlechtes Bsp. als Beleg für Deinen Widerspruch ausgesucht: Ich wäre gern bereit, auf einen SnapShot vom gesamten Bildschirm mal 7 sec zu warten.

Ja und weiter oben hatte ich ein anderes Beispiel genannt, herunterklappende Menüs. Wilst du da auch jedesmal 7sec warten?

Zitat
Eine weitere Frage an unsere HW-Experten: Könnte man den RPi nicht asynchron als CoProzessor an den TT anbinden? Und dann den VDI-Trap so modden, daß alle Aufrufe direkt an den RPi gehen?

Das würde zwar (wenns denn möglich wäre) das Problem der langsamen Schnittstelle  möglichweise entschärfen, andererseits kann ein Co-Processor soviel ich weiss nicht selber auf den Speicher zugreifen.