GK mit RPi für TT ua.?

[ari.tao]

... BeePi ... Die volle Auflösung des 24" HP wird mit 1920x1200 Pixel bei 32 Bit Farbtiefe unterstützt.

Kann mir jmd. auf dieser Grundlage eine interne VME-GrafikKarte (für TT & MSTE) bauen? @faucon2001  @Chocco  @Lukas Frank  @tuxie  @alle ...

[tuxie]

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

[Lukas Frank]

Der Weg wäre vielleicht eine FPGA VME Grafikkarte der auf die Nova Treiber aufsetzt ...?

[tuxie]

Der Weg wäre ein Shifter ersatz !!

[Chocco]

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 

Grüße

[Lukas Frank]

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.

[joejoe]

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.

[Chocco]

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.

[Arthur]

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

[joejoe]

Der interessante Ansatz in meinem Beitrag liegt in der Erwähnung der CSI-2 Schnitte des RPI,
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?

[Chocco]

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

[Chocco]

Der interessante Ansatz in meinem Beitrag liegt in der Erwähnung der CSI-2 Schnitte des RPI,
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ß 

[czietz]

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.

[tuxie]

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!

[Chocco]

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.

[ari.tao]

^^-- 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?

[goetz @ 3rz]

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.

[goetz @ 3rz]

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.

[goetz @ 3rz]

.

[ari.tao]

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.