GK mit RPi für TT ua.?

[ari.tao]

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

[mfro]

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

[Thorsten Otto]

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

[ari.tao]

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

[Chocco]

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

[mfro]

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.

[Thorsten Otto]

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.

[ari.tao]

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.

[mfro]

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. 

[Gaga]

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.

[mfro]

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

[tuxie]

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

[Gaga]

In diesem Zusammenhang fällt mir auf: wo ist 1ST1 ("man") geblieben?

[ari.tao]

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.

[tuxie]

Na dann mach mal, bin gespannt!

[ari.tao]

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 .

* Nein, ich glaube nicht mehr an den Weihnachtsmann.
    Aber ich glaube unerschütterlich an tuxie.