atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: ari.tao am Mi 14.11.2018, 08:12:28
-
... BeePi ... Die volle Auflösung des 24" HP wird mit 1920x1200 Pixel bei 32 Bit Farbtiefe unterstützt.
Kann mir jmd. auf dieser Grundlage (https://forum.atari-home.de/index.php/topic,14723.msg233102.html#msg233102) eine interne VME-GrafikKarte (für TT & MSTE) bauen? @faucon2001 @Chocco @Lukas Frank @tuxie @alle ...
-
Klar nur für dich allein... dieses Thema haben wir besprochen, und unsere Meinung ist das die GPIO des PI zu langsam sein werden. Wobei schreibst du die Software für den Pi dann kann man mal eine Bus Anpassung machen
-
Der Weg wäre vielleicht eine FPGA VME Grafikkarte der auf die Nova Treiber aufsetzt ...?
-
Der Weg wäre ein Shifter ersatz !!
-
Eine interessante Idee! Mal kurz nachdenken..
1. Möglichkeit: Framebuffer-Transport
Auf dem ST wird ein Framebuffer 1920x1200x32 gebaut und der Inhalt wird dann, wie auch immer, auf den RPi übertragen und angezeigt
Rechnung: 1920x1200 x 4 Byte/Pixel = 9.216.000 Byte pro Frame x 60 FPS ergeben eine notwendige Datenrate von knapp 56MB/s ==> geht nicht
Allein der Bildspeicher würde 9MB RAM auf dem STe verbrauchen ==> nicht praktikabel
Die CPU müsste 9MB Grafikspeicher beschreiben ==> nicht praktikabel
2. Möglichkeit: VDI-Terminal
Man verbindet den VME-Bus, wie auch immer, z.B. mit der USB-Schnittstelle RPi. Über diese Schnittstelle werden dann die VDI-Befehle übertragen und der RPI führt die VDI-Befehle aus. Das wäre dann so ähnlich, als würde der STe in ein Metafile schreiben, was nicht so schwer wäre.
Rastergrafik (MFDB Bitmaps) müssten natürlich auch transportiert werden. Die USB-Schnittstelle am RPi schafft max 35MB/s, was vermutlich schnell genug für den VME-Bus sein sollte. Ich weiß im Moment nicht, welchen Durchsatz der VME-Bus bei 8MHz hat.
Zu entwickeln wäre:
1. Ein Adapter, der den parallel arbeitenden VME-Bus mit dem seriellen USB-Eingang am RPi koppelt
2. Ein VDI-Treiber auf dem STe, der eine Workstation über den Adapter aufbaut und die Befehle/Daten überträgt.
3. Eine VDI-Treiber auf dem RPi, der über USB die Befehle/Daten übernimmt und für die Darstellung im RPi sorgt.
==> Sehr aufwändig, aber im Prinzip wohl machbar
Man darf die Nachteile natürlich nicht verschweigen. Der STe hätte keinen direkten Zugriff auf den Bildspeicher, d.h. vermutlich kein Spiel würde laufen und sämtlich Software, die nicht über VDI arbeitet, fällt auf die Nase.
Und natürlich bräuchte man sehr enthusiastische Menschen, die an der Entwicklung Freude hätten ;D
Grüße
-
VME Bus = 16Mhz
Es gibt ja die Lightning VME USB 1.1 Erweiterung. Für USB 2.0 wird der Atari ja viel zu langsam sein.
-
Wenn "das Ding" maximal kompatibel sein soll, wird wohl kein Weg an (ST-)Grafikspeicher im ST-Adressraum und dessen Verwaltung durch die 68xxx-CPU vorbeigehen. Damit wäre man auf dem Stand der bereits vorhandenen Grafikkarten für die Ataris, vielleicht mit dem Vorteil einer im Prinzip sehr variablen Monitor-Schnittstelle von FBAS bis HDMI im RPI. Ich hatte eine Weile die digitale Camera-Schnittstelle des RPI als leistungsfähigen (Grafik-) Eingang vom Atari zum RPI in betracht gezogen. Der RPI hat ein "Mobile Industry Processor Interface (MIPI) Camera Serial Interface Type 2 (CSI-2), Da wird das Bild vereinfacht gesagt Zeilenweise parallel übertragen.
Auf der ATARI Seite müsste dann eine DMA-Routine die Daten aus dem Atari-Framebuffer auslesen und in den RPI schaufeln. Das könnte ein spezieller Shifter bei dann maximaler Kompaibilität tun, aber es wäre wenig gewonnen, denn der Atari kümmert sich immer noch mit seinen wenigen MHz um die ganze Bildaufbereitung.
Da ist eine Emulation mit einem virtuellen, aber zigmal schnellere CPU/RAM etc. einfach überlegen.
Bleibt eigentlich der umgehrte Weg, aus der vorhandenen Atari-Peripherie (Tastatur, Maus, ACSI&SCSI etc) eine Retro-Umgebung für den Emu zubauen.
Was kann bzw. macht eigentlich der Cosmosex so ganz genau?
Läuft da auf dem RPI eine komplett eigene Software, oder ist das ein RaspBian mit Emulation für die Atari-Tastatur eine ACSI&SCSI - Festplatte?
Wenn man da die Atari-Emulation auch noch integrieren könnte plus die Grafik-Durchreiche per CSI-Interface hätte man einen sehr universellen Aufbau, der volle Spielekompatibilität mit original Atari-Hardware und maximale Leistung per Emulation miteinander verbinden könnte.
-
Wenn "das Ding" maximal kompatibel sein soll, wird wohl kein Weg an (ST-)Grafikspeicher im ST-Adressraum und dessen Verwaltung durch die 68xxx-CPU vorbeigehen. Damit wäre man auf dem Stand der bereits vorhandenen Grafikkarten für die Ataris, vielleicht mit dem Vorteil einer im Prinzip sehr variablen Monitor-Schnittstelle von FBAS bis HDMI im RPI.
Die Methode "Framebuffer" wird limitiert durch die max. mögliche Performance des VME-Bus. Eben las ich: "The VME bus can do about 20MB/s in D16 Mode", was ungefähr 30% der notwendigen Datenrate entspricht, die für die gewünschten Auflösung 1920x1200x32 notwendig ist.
Man kann eine maximale Kompatibilität 30 Jahre alter Hardware mit einer heute üblichen Auflösung nicht erreichen. Dazu fehlt den alten Knochen einfach die notwendige Leistung.
Die Terminal-Version besitzt den Charme, dass sie dem ursprünglichen Konzept von DR zu GDOS und VDI vollkommen gerecht wird. Ein Konzept übrigens, welches später mit XWindows unter UNIX sauber umgesetzt wurde. Mit XWindows kann ich über das Netzwerk eine Verbindung mit meinem XServer aufbauen und mein Bildschirm wird als grafisches Terminal verwendet. Mein RPi besitzt häufig keinen Monitor, sondern ich verbinde mich mit dem Mac über SSH und starte die Programme auf dem RPi, die ich dann auf dem Mac unter XQuartz äußerst flott bedienen kann.
Atari selbst hat damals nicht das Potential von GDOS/VDI erkannt und TOS genau um die Teile kastriert, die uns bis heute Probleme bereiten.
Einen Tod muss man sterben. Entweder maximale Kompatibilität bei nicht erweiterbarer Leistung (20MB/s) oder Höchleistung bei eingeschränkter Kompatiblität.
-
Atari selbst hat damals nicht das Potential von GDOS/VDI erkannt und TOS genau um die Teile kastriert, die uns bis heute Probleme bereiten.
Denke das hier nur einen Bruchteil der benötigten Zeit verfügbar war um ein OS zu entwickeln bzw. anzupassen, um noch vor dem Amiga auf der Bildfläche zu erscheinen... Für das vollständiges GDOS/VDI fehlte schlichtweg die Zeit...
-
Der interessante Ansatz in meinem Beitrag liegt in der Erwähnung der CSI-2 Schnitte des RPI, 8)
das hat Potential und dürfte im Rahmen eines Homebrew-Projekts machbar sein. Damit wäre die Inputschnittstelle für den RPI "geklärt". Es fehlt nun noch das passende Output-Interface für den Atari.
Damit ließe sich ein vollkompatibler HDMI-Ausgang für den Atari erstellen (z.B. mit einem Shifter-Ersatz).
Oder eine DUAL-Ported RAM-Karte für den VME-Bus als Grafikkarte-light ohne DA-Wandler kreieren.
Fragt sich nur, ob sich das lohnt?
-
Atari selbst hat damals nicht das Potential von GDOS/VDI erkannt und TOS genau um die Teile kastriert, die uns bis heute Probleme bereiten.
Denke das hier nur einen Bruchteil der benötigten Zeit verfügbar war um ein OS zu entwickeln bzw. anzupassen, um noch vor dem Amiga auf der Bildfläche zu erscheinen... Für das vollständiges GDOS/VDI fehlte schlichtweg die Zeit...
Ja, ich weiß. Es ist auch müssig und nicht zielführend, sich nach >30 Jahren immer noch darüber aufzuregen. Das ROM hatte halt nur 192KB vorgesehen und um die Hardware im Nachhinein auf 256KB aufzubohren fehlte die Zeit.
Ich werde versuchen, diesen Stachel in meiner Erinnerung nachdrücklich zu dämpfen.
Trotzdem ... :-X
-
Der interessante Ansatz in meinem Beitrag liegt in der Erwähnung der CSI-2 Schnitte des RPI, 8)
das hat Potential und dürfte im Rahmen eines Homebrew-Projekts machbar sein. Damit wäre die Inputschnittstelle für den RPI "geklärt". Es fehlt nun noch das passende Output-Interface für den Atari.
Damit ließe sich ein vollkompatibler HDMI-Ausgang für den Atari erstellen (z.B. mit einem Shifter-Ersatz).
Oder eine DUAL-Ported RAM-Karte für den VME-Bus als Grafikkarte-light ohne DA-Wandler kreieren.
Fragt sich nur, ob sich das lohnt?
Ich hatte natürlich deinen Hinweis auf die CSI-2 Schnittstelle bemerkt. Es ist jedoch so, dass nicht die Input-Schnittstelle des RPi den problematischen Teil dieses Abenteuers darstellt, sondern der maximale Output eines 68K Systems der limitierende Faktor ist. Auch ein Shifter-Ersatz wäre IMO nicht in der Lage 60MB/s aus dem RAM eines STe zu transportieren.
Lohnen tut sich das eh nicht, aber drüber zu diskutieren macht auch spaß :D
-
Die Methode "Framebuffer" wird limitiert durch die max. mögliche Performance des VME-Bus. Eben las ich: "The VME bus can do about 20MB/s in D16 Mode"
Im MegaSTE und TT deutlich weniger als 20MB/s.
-
Also, ich weiß ja nicht warum man gleich mit Kanonen auf Spatzen schießen Muss ?
1. Würde auch eine HD Auflösung ausreichen -> 1280x720x32
2. Warum 60 FPS ? genügen nicht 30 FPS ?
Dann sieht die ganze sache nämlich anders aus!
-
Also, ich weiß ja nicht warum man gleich mit Kanonen auf Spatzen schießen Muss ?
1. Würde auch eine HD Auflösung ausreichen -> 1280x720x32
2. Warum 60 FPS ? genügen nicht 30 FPS ?
Dann sieht die ganze sache nämlich anders aus!
Ich bitte um Entschuldigung. Habe den Taschenrechner zu schnell bearbeitet oder bin um eine Stelle verrutscht. Es ist noch heftiger als gedacht:
1280x720x32
= 3.686.400 Bytes / frame
= 110.592.000 bei 30 FPS => 110 MB/s
1920x1200x32
= 9.216.000 Bytes / frame
= 552.960.000 bei 60 FPS => 550 MB/s
Wie man es auch dreht, Framebuffer geht IMO nicht.
-
^^-- Muß auch nicht für den GK-Ansatz.
Für 30 fps gibt´s keine LCD-Monitore. Viele starten ab 50, manche erst ab 55 fps. Aber um den Bildspeicher zu füllen genügt auch deutlich weniger (wenn es nicht um schnelle Bewegungen geht).
Meine CrazyDots-GK kann jetzt bloß 1024x768x8 und 640x480x24. Deshalb wäre ich anstatt mit 1920x1200x32 auch schon mit 1920x1200x8 und 1280x960x24 sehr zufrieden. Reicht die VME-Leistung dafür, @czietz ?
In meinem TT habe ich 10MB ST-RAM; da wäre also noch ein Adressraum von 6MB frei für die Einblendung von Video-Speicher einer GK.
Vor meinem 3. Auge stand ungefähr das, @Chocco , was Du als VDI-Terminal skizziert hast. Zwar wäre für ´normale´ VDI-Befehle wohl die Leistung vom Lightning ausreichend, aber der Flaschenhals wird offenbar, wenn man die Raster-Ops. betrachtet. Zur Übertragung aus dem RAM des TT in den VideoSpeicher des RPi könnte man vielleicht CSI-2 zusätzlich einspannen, aber der Rückweg wird ja (wenn auch in gewöhnlichen GEM-Prgen. viel seltener) auch gebraucht - deshalb wäre wohl ein VME-Bus am RPi unerläßlich?
-
Atari selbst hat damals nicht das Potential von GDOS/VDI erkannt und TOS genau um die Teile kastriert, die uns bis heute Probleme bereiten.
Denke das hier nur einen Bruchteil der benötigten Zeit verfügbar war um ein OS zu entwickeln bzw. anzupassen, um noch vor dem Amiga auf der Bildfläche zu erscheinen... Für das vollständiges GDOS/VDI fehlte schlichtweg die Zeit...
Zeit (man bekam ja nichtmal das TOS ohne GDOS rechtzeitig ROM-fertig, drum mußte es ja von Diskette geladen werden und die ersten STs hatten nur 32 KB ROM als Bootloader, um von Diskette weiterzumachen) – und auch Platz im ROM.
-
Also, ich weiß ja nicht warum man gleich mit Kanonen auf Spatzen schießen Muss ?
1. Würde auch eine HD Auflösung ausreichen -> 1280x720x32
Das wäre "720p", kein HD. Ich weiß ja nicht wie’s euch geht, aber ich brauche keine 32 Bit Farbe am Atari. Mir reichen 256 Farben mehr als auch, schon HiColour (15/16 Bit) wäre absoluter Luxus.
2. Warum 60 FPS ? genügen nicht 30 FPS ?
30 finde ich zumindest am Mac oder Windows-PC eher schrecklich, da ruckelt und zuckelt es leicht, alles fühlt sich zäh an.
Das fand ich am Atari ST anno 1987 toll: der Mauszeiger war immer „glatt“ und schnell und auch bei Floppy-Zugriffen oder unter Last zuckelte nichts. Im Gegensatz zu Mac, Amiga, PC.
-
.
-
Mit den 48 fps auf dem Medion-Monitor am Falken bin ich gut zufrieden - bloß mit den übrigen Parametern dort nicht; HiColor zB. geht mit BlowUp nur per ´Guckloch´. Aber vorläufig soll es ja nur um Ataris mit VME gehen.
-
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.
-
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...
-
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.
-
Setzt das ganze nicht zwingend USB 2.0 voraus? Der Atari kann ja nur USB 1.1
-
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.
-
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
(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:
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.
-
Gabs die Vampire nicht auch mit Grafikanschluss?
-
Jup die Vampire hat einen eingebauten SAGA Core mit HDMI Ausgang.
-
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!
-
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?
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.
-
Der Vampir ist hier OT - bitte anderswo diskutieren*. Hier geht es darum, ob eine GK mittels RPi möglich ist.
Sorry
-
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
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.
-
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?
-
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.
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.
Dem Grunde nach die in GEM eingebaute Bild-Komprimierung.
Wie kommst den denn jetzt darauf daß da irgendwas komprimiert ist???
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.
-
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).
-
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.
-
Ich finde es etwas befremdlich als Grafikkarte einen kompletten modernen Mini Rechner zu benutzen. Eine CosmosEx ist/wäre auch genauso nicht mein Fall.
-
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.
-
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?
-
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?
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.
-
^^-- Der RPi kann auf seinen eigenen Speicher sehr gut zugreifen.
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?
Ja und ich hatte Dir darauf geantwortet, daß deren Hintergrund nicht in den TT geschaufelt werden muß. Willst Du das jetzt nochmal wiederkäuen? Außerdem muß man dafür nicht den gesamten Screen sichern.
Ich habe in #38 nicht weniger im Sinn, als das gesamte VDI in das VD zu verschieben, auf ganz ähnliche Weise, wie die FloatingPoint-Arithmetik in eine FPU verschoben wird - bloß daß das Ergebnis nicht zurück in den TT geht, sondern an den Bildschirm.
-
^^-- Der RPi kann auf seinen eigenen Speicher sehr gut zugreifen.
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?
Ja und ich hatte Dir darauf geantwortet, daß deren Hintergrund nicht in den TT geschaufelt werden muß. Willst Du das jetzt nochmal wiederkäuen? Außerdem muß man dafür nicht den gesamten Screen sichern.
... und woher weiß die arme vro_cpyfm()-Routine (die in beiden Fällen das Kopieren übernimmt), daß Du im einen Fall die Pixeldaten wieder im ST haben willst, im anderen aber nicht?
-
^^-- Der RPi kann auf seinen eigenen Speicher sehr gut zugreifen.
Ja, und? Bei vro_cpyfm müssen trotzdem Daten in beide Richtungen geschaufelt werden.
Ja und ich hatte Dir darauf geantwortet, daß deren Hintergrund nicht in den TT geschaufelt werden muß.
Doch, müssen sie. Es werden dort die gleichen VDI Befehle ausgeführt die auch ein Benutzer-Programm aufrufen würde. Woher soll das VDI wissen, daß das nur für ein Menü war?
Außerdem muß man dafür nicht den gesamten Screen sichern.
Nein, das nicht, aber auch das sind nicht unerhebliche Datenmengen.
-
^^-- 640x400 Pixel schafft sogar meine CratzDots über VME in TrueColor (24 Bit) in beide Richtungen. Die typischen PixelPatches für GEM sind nochmal ´ne Größenordnung kleiner. Bei diesen Korinthen sollte nun wirklich kein Problem auftreten. Nur AnwenderPrge. wollen größere Bilder sichern - und in dem Moment sind sie nicht zeitkritisch, siehe Bem. oben.
... und woher weiß die arme vro_cpyfm()-Routine (die in beiden Fällen das Kopieren übernimmt), daß Du im einen Fall die Pixeldaten wieder im ST haben willst, im anderen aber nicht?
Muß sie meistens gar nicht wissen, RasterOps. könnten im BeePi ausgeführt werden. Der hat genug Power & RAM, um das gesamte RAM des TT zu cachen, das reicht auch locker für mehrere Screens.
Und in den wenigen anderen Fällen, in denen ein Teil des Caches in den TT zurückgeschrieben werden soll, ließe sich das sicher regeln (die Raster können ja über ihre Adressen identifiziert werden). Solche Details sollte man sich dann anschauen, wenn die HW-Frage aus #38 geklärt ist, und nicht hier mißbrauchen.
Ich weise nochmals darauf hin, daß im BeePi auf dem RPi ja schon fast alles wünschbare vorhanden ist: VDI, ScreenTreiber, notfalls sogar AES und mehr. Es fehlt eigtl. ´nur´ der VME-Bus, der das Maximum des vom TT-VME her möglichen übertragen kann - und bei der skizzierten Benutzung der VDI-Befehle nur selten muß - und ein paar kleinere Software-Teile (wobei, Thorsten, ´kleinere´ heißt: Kein neues VDI und kein neuer GK-Treiber).
PS: Wer nun argumentiert, dann könne man doch gleich den RPi als Emulator laufen lassen, der übersieht, daß solch ein Emulator (wie alle anderen auch) das Problem hätte, die vielen Schnittstellen eines Ataris bereitzustellen.
-
... und woher weiß die arme vro_cpyfm()-Routine (die in beiden Fällen das Kopieren übernimmt), daß Du im einen Fall die Pixeldaten wieder im ST haben willst, im anderen aber nicht?
Wenn in der MFDB-Struktur eine NULL als Adresse des Raster übergeben wird, dann geht VDI davon aus, dass der Bildschirm gemeint ist. Natürlich bleibt das Problem bestehen, dass ein AES den Buffer im RAM des Host anlegt und die Daten durch das VDI über den VME-Bus holen wollen würde.
Man müsste VDI also beibringen, Speicherbereiche selbst bereitzustellen, die dann über Handles angesprochen werden könnten ::)
http://toshyp.atari.org/en/00700d.html#MFDB (http://toshyp.atari.org/en/00700d.html#MFDB)
Note: If the component fd_addr contains a 0, the rest of the MFDB does not have to be filled out. The raster operations vrt_cpyfm and vro_cpyfm then automatically refer to the screen (or, in the case of a printer driver to the printer bitmap). The reserved words fd_r1, fd_r2 and fd_r3 should be set to 0 to cater for future extensions!
-
Wenn in der MFDB-Struktur eine NULL als Adresse des Raster übergeben wird, dann geht VDI davon aus, dass der Bildschirm gemeint ist.
Das ist zwar richtig, macht aber m.E. nicht den geringsten Unterschied.
-
Wenn in der MFDB-Struktur eine NULL als Adresse des Raster übergeben wird, dann geht VDI davon aus, dass der Bildschirm gemeint ist.
Das dürfte nicht das Problem sein, das war schon immer so. Auch wenn manche Programm die komplette Stuktur trotzdem ausfüllen, oder manchmal auch den Rückgabewert von Logbase() dort eintragen.
Natürlich bleibt das Problem bestehen, dass ein AES den Buffer im RAM des Host anlegt und die Daten durch das VDI über den VME-Bus holen wollen würde.
Man müsste VDI also beibringen, Speicherbereiche selbst bereitzustellen, die dann über Handles angesprochen werden könnten ::)
Auch über Handles dürfte nicht funktionieren. Abgesehen davon daß die Programme nicht wissen können daß das nur ein Handle ist, die Grafikdaten müssen nunmal direkt (im Speicher des ST) ansprechbar sein, da führt kein Weg dran vorbei. Es gibt einige Programme die benutzen das z.B. um das tatsächliche Pixelformat zu analysieren, wenn sie Color-Icons darstellen wolllen. Sich da auf das AES zu verlassen hilft auch nichts weil es im Grunde das gleiche macht.
-
Was im RAM des TT passiert, das soll eine GK behindern? Das glaubst Du doch wohl selber nicht. Was sollen diese Verwirrspiele, Thorsten?
Klar ist außerdem, daß aus KompatibilitätsGründen nicht das VDI im TT durch Handles erweitert werden kann - wohl aber wäre das lokal im BeePi möglich.
-------
Ich möchte den Fokus noch mal auf die Ü-Rate im VME-Bus lenken.
Meine CrazyDots kann zB. 1024x768x8@60; wie man leicht nachrechnet, bedeutet dies, daß über den VGA-Port 45MB/sec gehen. Eine Nova kann noch viel mehr. Es ist inzwischwen völlig klar, daß diese DatenMengen nicht auch über den VME-Bus gehen können. Das RAM dieser GKs wird also vom TT _wesentlich_ langsamer befüllt. Leider habe ich trotz einiger Suche keine Zahlen dafür gefunden. Oben in #12 hat @czietz dunkel geraunt "Im MegaSTE und TT deutlich weniger als 20MB/s". Würde mich mal interessieren, was CratzDots & Nova tatsächlich über den VME-Bus schaufeln... Wenn die Leistung der GPIO am RPi zu gering ist (lt. Chocco immerhin max. 5MB/s), wie @tuxie in #1 meint, und ich andererseits sehe, daß die Lightning_VME nicht einmal 1MB/s macht, dann paßt da irgendetwas nicht so recht zusammen...
Kurz, ich halte dafür, daß auch ohne den oben skizzierten Trick eines VDI-Terminals eine GK auf Basis des RPi möglich ist. Und wenn der RPi die Daten vom VME-Bus erst einmal übernommen hat, dann sollte es auch gelingen, sie an dessen (BeePi-) eigenen ScreenTreiber weiterzuleiten. Und die Leistung einer solchen GK sollte die der Nova deutlich übertreffen.
PS: Die Argumente in diesem Posting wurden vorgetragen, um den Einwand eines zu langsamen Transfers zum und vom RPi zu widerlegen. Es ist nicht gemeint, auf den Gedanken eines VDI-Terminals oder noch besser eines VDI-Coprozessors zu verzichten.
-
GPIO mit dem Pi scheitert - auch wenn's schnell genug wäre - meiner Ansicht nach bereits daran, daß nicht genügend Pins zur Verfügung stehen. Der Pi hat - wenn ich das richtig weiß - 40 GPIO Pins.
Der VME-Bus braucht _DS0, _DS1, _DTACK, _AS und WRITE für sein Busprotokoll, 16 Bit für Daten und - wenn man Full-HD unterstützen und 8 MByte adressieren will, mindestens 23 Adressleitungen.
Macht nach Adam Riese 44 Pins - reicht nicht. "Kürzen" könnte man, indem man entweder die Adressleitungen beschneidet (weniger Auflösung) oder die Daten multiplext (nochmal deutlich verringerte Performance).
Meiner Ansicht nach nicht interessant.
Deutlich vielversprechender erscheint mir, eins der vielen FPGA-Evalboards zu nehmen (die haben mehr als genug Pins um einen "vollwertigen" VME-Busanschluß zu realisieren, können oft schon HDMI, manche haben bereits GBit Ethernet on board und sind nicht besonders teuer) und auf der Basis eine Karte aufzubauen, die nicht schon von vornherein unnötige Einschränkungen hat.
-
Meiner Ansicht nach nicht interessant.
Deutlich vielversprechender erscheint mir, eins der vielen FPGA-Evalboards zu nehmen (die haben mehr als genug Pins um einen "vollwertigen" VME-Busanschluß zu realisieren, können oft schon HDMI, manche haben bereits GBit Ethernet on board und sind nicht besonders teuer) und auf der Basis eine Karte aufzubauen, die nicht schon von vornherein unnötige Einschränkungen hat.
Das dürfte tatsächlich der richtige Ansatz sein.
-
Das dürfte tatsächlich der richtige Ansatz sein.
Ich hab' so eins: https://www.arrow.de/products/deca/arrow-development-tools hier liegen, das m.E. alles (und mehr) hat, was man dafür braucht. Wahrscheinlich wäre es sogar möglich, auf der Karte zusätzlich einen m68k unterzubringen, der deutlich schneller wäre als der im TT...
Allerdings bin ich ein wenig erschrocken, wie die Dinger preislich angezogen haben. Vor einem Jahr habe ich (incl. Steuer und Zoll) etwa die Hälfte des jetzt aufgerufenen Preises bezahlt...
-
Richtig sinnvoll sollte man eine Lösung finden um auch den kompletten Bus des TT´s nutzen zu können, der VME BUS ist einfach kastriert und nur 16bit breit. Hier gibt es andere Ideen die man umsetzen kann, was eventuell auch Plug and Play kann. Einen video Core braucht man nicht mal schreiben den der existiert schon. Sei es SAGA, sei es Videl, vollkommen egal. Man könnte eine Platine entwerfen die in den Shifter Sockel gesteckt wird und dort den Shifter ersetzt. Macht aus heutiger Sicht auf jedenfall mehr sinn da der VME Bus viel zu langsam ist. Klar der ST-Ram ist auch nicht schnell ohne ende aber das Problem wird man am ende nur auf andere Weise lösen können. Größte Problem ist das es so viele verschiedene Board Revisionen gibt. Wenn alle Boards einen PGA Sockel hätten dann wäre es wohl weniger Problematisch weil dort dann CPU rein und ein anderes Board eingesteckt mit schnellerer CPU und Fastram was mit CPU Takt läuft, dort könnte die CPU direkt die Grafikkarte ansprechen, bei 32Mhz sind locker 30-40Mb/s drin (siehe Pak3 dort läuft der Fastram auch mit CPU Geschwindigkeit).
Die Frage ist aber am ende nicht WAS, sondern WER!!! Macht doch ein Projekt daraus und packt es an...
-
In diesem Zusammenhang fällt mir auf: wo ist 1ST1 ("man") geblieben?
-
Das wäre aber, @tuxie , ein viel größeres Ding.
Eben deshalb suche ich nach einer kleineren Lösung mittels RPi.
-------
Nun weiß ich aber immer noch nicht, wieviel MB/s eine Nova über VME schiebt.
-
Na dann mach mal, bin gespannt!
-
Aber vielleicht bescherst* Du uns ja zu Weihnachten einen Vampir im TT. Bin mal gespannt, wo der Platz nimmt und wo er anbeißt. Oder vielleicht wenigstens einen Lightning_2 mit 5MB/s ?
Die Idee einer GK mit RPi ist ja nun in der Welt. Wenn sie etwas taugt, dann wird sie ihren Weg finden - auch ohne mein weiteres zutun -, denn Ideen lassen sich bekanntlich nicht zurückrufen, wenn sie mal in der Welt sind. Manchmal bedaure ich, daß ich ´nur´ ein Softie bin.
In diesem Zusammenhang fällt mir auf: wo ist 1ST1 ("man") geblieben?
Der wartet seit zweiundeinhalb Jahren auf eine FPGA-Lösung (https://forum.atari-home.de/index.php/topic,12930.0.html) .
* Nein, ich glaube nicht mehr an den Weihnachtsmann.
Aber ich glaube unerschütterlich an tuxie. :D