Hardware > Hardware (Classic 16-/32-Bit)

GK mit RPi für TT ua.?

<< < (10/12) > >>

mfro:

--- Zitat von: Chocco am Mo 19.11.2018, 20:45:48 ---Wenn in der MFDB-Struktur eine NULL als Adresse des Raster übergeben wird, dann geht VDI davon aus, dass der Bildschirm gemeint ist.

--- Ende Zitat ---

Das ist zwar richtig, macht aber m.E. nicht den geringsten Unterschied.

Thorsten Otto:

--- Zitat von: Chocco am Mo 19.11.2018, 20:45:48 ---Wenn in der MFDB-Struktur eine NULL als Adresse des Raster übergeben wird, dann geht VDI davon aus, dass der Bildschirm gemeint ist.
--- Ende Zitat ---

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.


--- Zitat --- 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  ::)
--- Ende Zitat ---

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.

Gast160608:
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:

--- Zitat von: mfro am Di 20.11.2018, 09:31:28 ---
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.

--- Ende Zitat ---

Das dürfte tatsächlich der richtige Ansatz sein.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete