Raspberry Pi im Amiga als ...

[mfro]

Dann mach' mal. Ich bin gespannt.

[Arthur]

Für ein Grafikinterface ist es nicht genug... Die A314 + Pi kann es ja auch nicht, falls ich nichts übersehen habe. Also ist CosmosEX von der Konzeption her mindesten gleich auf, oder?

[1ST1]

Wenns drum ginge, nur Bitmap-Grafik zu übertragen, 6,6 MB/s reicht bei 32 kB Videospeicher für knapp über 200 fps. Gebraucht werden aber nur 50, 60 oder 70 Hz, das heißt 25 bis 35% der zur Verfügung stehenden Bandbreite.

[mfro]

Wenns drum ginge, nur Bitmap-Grafik zu übertragen, 6,6 MB/s reicht bei 32 kB Videospeicher für knapp über 200 fps. Gebraucht werden aber nur 50, 60 oder 70 Hz, das heißt 25 bis 35% der zur Verfügung stehenden Bandbreite.

Aha. Du treibst den ganzen Aufwand nur, um den ST-Screen auf einen anderen Bildschirm zu übertragen?

[Arthur]

Einen TV bzw. Monitor per HDMI anschießen zu können würde mir auch gefallen.

[1ST1]

Einen TV bzw. Monitor per HDMI anschießen zu können würde mir auch gefallen.

Das würde halt nur gehen, wenn der Treiber aktiv ist, der den Shifter-Status (siehe oben) an den Rapi übermittelt. und solange keine andere Software den Videospeicher in die andere RAM-Bank verlegt. Bei Spielen die von Diskette booten, kann man das vergessen. Das ist der Nachteil an der Sache. Diese Variante nur als "Kompatiblitätsmodus", bis ein VDI Treiber startet, der den Rapi als Videobeschleuniger in höheren Auflösungen machen lässt. Was da für eine Bandbreite notwendig wäre. keine Ahnung. Wahrscheinlich müsste man dann mehr Intelligenz als nur das VDI (also auch das AES!) an den RaPi "auslagern". Dann würde der Rapi vom ST Befehle bekommen, zeichne da mal ein Fenster, eine Menüleiste, etc. mit folgendem Inhalt (Fonts, Bitmap, etc.)... Deswegen oben die Erwähnung von XDMCP, da läuft das ähnlich. Allerdings ist die Bandbreite, die XDMCP braucht (über Netzwerk mit einem Thinclient als Ausgabegerät hab ich das mal bei zeitgenössischen Auflösungen und komplexen CAD-Objekten gemessen) nicht zu verachten.

Vielleicht ist das nur ne Schnapsidee, aber wenn man von vorneherein so denken würde und gleich alles unterdrückt, würden wir heute noch auf Bäumen sitzen. Und es gibt Leute, die haben die Idee, aus einem Baumstamm zwei bis 4 Scheiben auszuschneiden, um sie drehbar an einem Brett zu befestigen, haben aber keine Säge. Und es gibt Leute, die haben eine Säge, erkennen aber den Sinn einer Kutsche nicht. C'est la vie. Ich verkrieche mich für den Rest des Abends in meiner Höhle und versuche mir mit zwei Feuersteinen ein Feuerchen zu machen, draußen ist es viel zu kalt für diese Jahreszeit, der April macht was er will, auf seine letzten Tage!

[Thorsten Otto]

Gebraucht werden aber nur 50, 60 oder 70 Hz, das heißt 25 bis 35% der zur Verfügung stehenden Bandbreite.

Und du willst jetzt ernsthaft den ganzen Aufwand betreiben, nur um dann doch wieder nur die (relativ mickrigen) ST-Auflösungen darstellen zu können?

Bei 640x480x256 Farben (was auch nicht wirklich viel ist) sind es dann schon 307k Bildspeicher. Rechne mal spasseshalber die mögliche Wiederholrate dafür aus.

[ari.tao]

Nun mach´ doch nicht schlapp, 1ST1, so kurz vor der Erfindung der Säge!

Wahrscheinlich müsste man dann mehr Intelligenz als nur das VDI (also auch das AES!) an den RaPi "auslagern". Dann würde der Rapi vom ST Befehle bekommen, zeichne da mal ein Fenster, eine Menüleiste, etc. mit folgendem Inhalt (Fonts, Bitmap, etc.)...

BeePi hat ja genug Intelligenz. Mal angenommen, man deligiert über entsprechende Trap-Manager im TOS sämtliche Grafik (VDI, AES, auch manche BIOS - und GemDos-Befehle) an den RasPi als eine Art graf. CoProzessor, der sie von BeePi verarbeiten läßt: Dann kann das Video-RAM im RasPi verbleiben, ein SharedMemory a la TrapDoor ist unnötig und ein Bus, über den das gehen muß, braucht keine extrem hohe Performance und es sind traumhafte graf. Auflösungen denkbar. Eine Schwierigkeit könnte sein, bei Speicher-Anforderungen zu entscheiden, welcher Speicher grafisch relevant ist, also im RasPi alloziert werden muß, und welcher im Atari.
Wenn aber sowieso BeePi läuft: Dann könnte man ja Programme gleich direkt darunter im RasPi ablaufen lassen - und dann umgekehrt diejenigen TOS-Befehle, die BeePi nicht kann, über einen Bus an den Atari schicken, den also als Peripherie-Gerät für den RasPi einsetzen, um die Atari-Spezifika zu erreichen (RomPort, Midi, DSP etc.pp.). Auch dafür braucht der Bus wohl keine allzu große Bandbreite. Aber vielleicht wäre dann ein SharedMemory a la TrapDoor doch nützlich.

[1ST1]

Im Gegensatz zu @Thorsten Otto hat @ari.tao verstanden, worauf ich letztendlich hinaus will. Zwei Grafik-Betriebsmodis: Kompatiblitätsmodus wo einfach das originale Shifter-Bild rausgeschoben wird, und als zweiter Betriebsmodus, wo der RaPi als eigenständige Grafikkarte agiert, die vom ST gesteuert wird. Also so ganz blöd habe ich mich nicht ausgedrückt, ari.tao hat es schon weiter oben verstanden. Der Vorteil wäre, dass man nicht 2 Monitore braucht (bis auf die Zeit, bis der Treiber geladen wurde).

[ari.tao]

Die Idee vom RasPi als GrafikKarte plus Treiber, die wurde in dem schon zitierten anderen Thread bereits erledigt: Sie provoziert immer den Einwand, den @tuxie in ## 18 & 35 vorgetragen hat. Die Idee vom RasPi als graf. CoProzessor geht weit darüber hinaus und ist imho noch nicht widerlegt. Die Idee vom Atari als PeripherieGerät am RasPi ist die logische Folge aus der Bastelei von @Chocco .

[mfro]

... Deswegen oben die Erwähnung von XDMCP, da läuft das ähnlich...

Vielleicht machst Du dich erst mal schlau, was XDMCP überhaupt ist, dann reden wir weiter. Was willst Du mit einem Login Service/Authentifizierungsmechanismus?

[Thorsten Otto]

Wenn aber sowieso BeePi läuft: Dann könnte man ja Programme gleich direkt darunter im RasPi ablaufen lassen

Dir ist schon klar daß RasPi kein m68000 ist auf dem man einfach mal so eben Programme laufen lassen kann? Dazu müsste man die emulieren. Dann kannst du auch gleich ARAnyM nehmen.

[Arthur]

Die Idee hätte ihren Reiz gehabt wenn es einfach machbar wäre. Allein ein Teil, das ein Bild über HDMI ausgibt hätte schon seine Berechtigung. Der Raspi kann ja vielseitig verwendet werden, siehe CosmosEX, aber als Grafikkarte fehlt eine kompatible Schnittstelle am Raspi. Da würde eine Implementierung als "SuperShifter" ähnlich dem SuperVidel im Falcon mehr Möglichkeiten bieten. Viel mehr als die ST-Auflösungen und HDMI wird wegen der 8MHz CPU aber nicht zu erwarten sein.

Aber mit etwas Glück läuft irgendwann eine Vampire im Atari und nicht nur als V4SA. Bis dato hab ich noch viel Zeit mich mit den Atari's, Emulatoren usw. zu beschäftigen.

[tuxie]

@insane hat mit dem Rasperberry Pi einen CPU ersatz für den C64 gebaut, dazu hat er mittels Bare Metal einen CPU Emulator geschrieben der die 6502 Emuliert. Daraufhin haben wir uns unterhalten was mit dem Pi im ST oder TT mögich wäre, aber wir sind immer wieder an den zu langsamen GPIO´s hängen geblieben. Deswegen wollen wir paar Tests per SPI machen und testen was möglich ist. Ich meine es gibt ja nicht nur das HDMI Interface sondern hat der Pi auch ein Netzwerkinterface und USB..  und man könnte den Pi als Co Prozessor verwenden um Decodierungen von ihm erledigen zu lassen. DSP ?

[mfro]

Die Idee hätte ihren Reiz gehabt wenn es einfach machbar wäre. Allein ein Teil, das ein Bild über HDMI ausgibt hätte schon seine Berechtigung...

Wenn Du das haben willst: im englischen Forum gibt es einen Thread, in dem der Shifter durch einen HDMI-fähigen "FPGA-Shifter" ersetzt wird. Das ist dann wenigstens "straightforward" und nicht von hinten durch die Brust ins Auge und dann dennoch in Knie geschossen.

[Lukas Frank]

Die Hardware ist schon fertig ->   https://www.exxoshost.co.uk/forum/viewtopic.php?f=29&t=330&hilit=hdmi

[ari.tao]

Wenn aber sowieso BeePi läuft: Dann könnte man ja Programme gleich direkt darunter im RasPi ablaufen lassen

Dir ist schon klar daß RasPi kein m68000 ist auf dem man einfach mal so eben Programme laufen lassen kann? Dazu müsste man die emulieren. Dann kannst du auch gleich ARAnyM nehmen.

Ich dachte, BeePi ist genau dieser Emulator?
Mal @Chocco fragen, was bei ihm unter BeePi so alles läuft.

[ari.tao]

Aber mit etwas Glück läuft irgendwann eine Vampire im Atari und nicht nur als V4SA.

Ich warte immer noch sehr gespannt auf Info, wo/wie der Vampir am Atari anbeißen soll.

[ari.tao]

@insane hat mit dem Rasperberry Pi einen CPU ersatz für den C64 gebaut, dazu hat er mittels Bare Metal einen CPU Emulator geschrieben der die 6502 Emuliert. Daraufhin haben wir uns unterhalten was mit dem Pi im ST oder TT mögich wäre, aber wir sind immer wieder an den zu langsamen GPIO´s hängen geblieben. Deswegen wollen wir paar Tests per SPI machen und testen was möglich ist. Ich meine es gibt ja nicht nur das HDMI Interface sondern hat der Pi auch ein Netzwerkinterface und USB..  und man könnte den Pi als Co Prozessor verwenden um Decodierungen von ihm erledigen zu lassen. DSP ?

(Einfärbung von mir)
Klingt für mich sehr plausibel & vielversprechend. Bin gespannt auf die Test-Ergebnisse!

[1ST1]

Vielleicht machst Du dich erst mal schlau, was XDMCP überhaupt ist, dann reden wir weiter. Was willst Du mit einem Login Service/Authentifizierungsmechanismus?

Mein Lieber, von dir hätte ich da mehr Sachkunde erwartet!

X Display Manager Control Protocol <<<----- Da steht nix von Login!

XDMCP ist ein (Remote-)Grafik-Protokoll. Es wird auf jedem System mit X-Window genutzt (z.B. Unix, Linux, gibts auch für unser MiNT), entweder intern, oder über Netzwerk. Das heißt, es ist das Protokoll zwischen dem X-Server und dem X-Client (Display Manager, spricht die Grafikhardware an). Der X-Client ist der Teil, der die Grafikhardware oder eine virtuellen Grafikkarte wie den xvnc/xrdp-Server anspricht. XDMCP kennt Grafikbefehle wie Linien zeichnen, Flächen füllen, Dialoge und Fenster darstellen/verschieben, usw. Es ist also ähnlich wie die Kombination wie VDI und AES, wobei das VDI eher dem X-Client, und AES mehr dem X-Server entspricht, aber ein direkter Vergleich ist eher schwierig, die Architekturen sind zu unterschiedlich, nur der Zweck ist am Ende der selbe: Darstellung einer grafischen Oberfläche auf nicht normierter Hardware, das heißt es gibt einen unabhängigen Teil und einen hardwareabhängigen Teil. Ein wesentlicher Unterschied zwischen XDMCP und VDI/AES ist, dass Server und Client bei XDMCP per Default über das UDP-Netzwerkprotokoll (auch innherhalb einer Maschine, auf einem Linux-System ist es ganz einfach, das im Netzwerk zu öffnen, so dass man von extern andocken kann, das geht indirekt aber sicher mit SSH-Tunnel oder auch direkt (und unsicher)) kommunizieren. Wenn man sowas als "Netzwerklösung" (z.B. ST zu RaPi) ("Netzwerklösung" in Klammern weil bei diesem Beispiel der Datenaustausch über Shared-Memory ablaufen würde) auf dem Atari umsetzen würde, müsste man für den Rechner, auf dem die Programme ausgeführt werden (in unserem Beispiel der ST), ein VDI und AES schreiben, was die Aufrufe über ein Protokoll an die zweite Instanz (in unserem beispiel der RaPi) schickt. Dort müsste eine VDI/AES-Instanz laufen, die dann die Darstellung auf der konkreten Hardware übernimmt.

Ein Login-Fenster ist nur ein Prozess, der über XDMCP dargestellt werden kann. Meistens ist dieser Login in den Desktop-Manager (gdm, kdm, etc.) integriert. Ich kann aber diesen problemlos umgehen und per XDMCP direkt einen Desktop oder einzelne Applikationen sehen, egal ob Remote oder lokal - das ist wie wenn man als normaler User aus einer Textkonsole an einem Linux/Unix-Rechner im entsprechenden Runlevel (ohne automatischen Start von X) "startx" eingibt - da kommt auch kein Login mehr.

https://de.wikipedia.org/wiki/XDMCP