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

GK mit RPi für TT ua.?

<< < (9/12) > >>

Gast160608:
^^-- Der RPi kann auf seinen eigenen Speicher sehr gut zugreifen.

--- Zitat von: Thorsten Otto am So 18.11.2018, 06:11:29 ---
--- Zitat von: ari.tao am So 18.11.2018, 05:01:46 ---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.
--- Ende Zitat ---
Ja und weiter oben hatte ich ein anderes Beispiel genannt, herunterklappende Menüs. Wilst du da auch jedesmal 7sec warten?
--- Ende Zitat ---
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:

--- Zitat von: ari.tao am So 18.11.2018, 06:32:59 ---^^-- Der RPi kann auf seinen eigenen Speicher sehr gut zugreifen.

--- Zitat von: Thorsten Otto am So 18.11.2018, 06:11:29 ---
--- Zitat von: ari.tao am So 18.11.2018, 05:01:46 ---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.
--- Ende Zitat ---
Ja und weiter oben hatte ich ein anderes Beispiel genannt, herunterklappende Menüs. Wilst du da auch jedesmal 7sec warten?
--- Ende Zitat ---
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.

--- Ende Zitat ---

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

--- Zitat von: ari.tao am So 18.11.2018, 06:32:59 ---^^-- Der RPi kann auf seinen eigenen Speicher sehr gut zugreifen.

--- Ende Zitat ---

Ja, und? Bei vro_cpyfm müssen trotzdem Daten in beide Richtungen geschaufelt werden.


--- Zitat ---Ja und ich hatte Dir darauf geantwortet, daß deren Hintergrund nicht in den TT geschaufelt werden muß.

--- Ende Zitat ---

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?


--- Zitat ---Außerdem muß man dafür nicht den gesamten Screen sichern.

--- Ende Zitat ---

Nein, das nicht, aber auch das sind nicht unerhebliche Datenmengen.

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

--- Zitat von: mfro am So 18.11.2018, 08:56:53 ---... 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?
--- Ende Zitat ---
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:

--- Zitat von: mfro am So 18.11.2018, 08:56:53 ---... 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?

--- Ende Zitat ---

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!

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete