atari-home.de - Foren
Non-ATARI => Hardware => Thema gestartet von: 1ST1 am Sa 27.04.2019, 12:28:22
-
Raspberry Pi im Amiga als Speichererweiterung, Laufwerk, USB, Netzwerk, ...
Schaut mal hier, vielleicht lässt sich sowas ja auch im ST machen...?
---> https://github.com/niklasekstrom/a314
(Die Trapdoor-Schnittstelle im Amiga ist nahe am 68000er-Protokoll, also z.B. auch nahe am Mega-ST-Systembus.)
Da ließe sich doch bestimmt auch ein VDI dafür schreiben, immerhin hat der RaPi doch eine HDMI-Grafikkarte ...?
Ja, und jetzt kommen wieder die Einwände, wer soll das alles machen, usw...? ? ? ? :)
-
^^-- Na, _Du_ natürlich! ;D ;D
Die Trapdoor-Schnittstelle im Amiga ist nahe am 68000er-Protokoll, also z.B. auch nahe am Mega-ST-Systembus.
Gilt das auch für den VME-Bus im TT?
-
Eine weitere Idee den Pi mit einzuspannen. Auch schön das alles auf GitHub verfügbar ist. VME kannst du nachschauen welche Signale dort und am 68k übereinstimmen. Wenn eins fehlt pickt man sich das per Kabel vom MB.
-
VME ist auch nah am 68000 Bus Protokoll. Zorro (Amiga 2000/3000/4000) und NuBus (Apple Mac) übrigens auch, die beiden lezten fügen eine Art AutoConfig bzw. Plug&PLay-Mechanismus hinzu.
-
Die GPIo sind zu langsam um ihn sinnvoll zu nutzen. Die Thematik ist nicht neu, ein User hier aus dem Forum hat mit einem PI Zero eine cpu emulation für den C64 gebaut
-
Die GPIo sind zu langsam um ihn sinnvoll zu nutzen. Die Thematik ist nicht neu, ein User hier aus dem Forum hat mit einem PI Zero eine cpu emulation für den C64 gebaut
Und, C64 in Zeitlupe?
-
Das gibt's für den ST schon.
Heißt CosmosEx und unterstützt sogar DMA.
Wahrscheinlich nicht langsamer als die FPGA-Lösung des A314, die anscheinend per SPI (also seriell) mit dem Pi redet.
Jetzt muß 1ST1 nur noch eben schnell das VDI dafür schreiben.
-
Denk Denk Denk ???? C64 hat wieviel MHz und wieviele Bit ist der bus breit ?
8Bit vs 16bit ?
1,79Mhz vs 8Mhz ?
Rechne selbst hoch wie gross der Unterschied ist um Daten über den Bus zu schieben!
-
Das gibt's für den ST schon.
Heißt CosmosEx und unterstützt sogar DMA.
Wahrscheinlich nicht langsamer als die FPGA-Lösung des A314, die anscheinend per SPI (also seriell) mit dem Pi redet.
Jetzt muß 1ST1 nur noch eben schnell das VDI dafür schreiben.
Genau diese Reaktion habe ich von dir erwartet. Hab ich ja oben schon angedeutet, ohne Namen zu nennen. Natürlich gibts CosmosEx, ich finde aber die interne Anbindung dieser Lösung sehr interessant. Grafik über ACSI-DMA oder SCSI wird sicher nicht so flott sein, wie man sie am internen Systembus realisieren könnte.
-
Das gibt's für den ST schon.
Heißt CosmosEx und unterstützt sogar DMA.
Wahrscheinlich nicht langsamer als die FPGA-Lösung des A314, die anscheinend per SPI (also seriell) mit dem Pi redet.
Jetzt muß 1ST1 nur noch eben schnell das VDI dafür schreiben.
Genau diese Reaktion habe ich von dir erwartet. Hab ich ja oben schon angedeutet, ohne Namen zu nennen. Natürlich gibts CosmosEx, ich finde aber die interne Anbindung dieser Lösung sehr interessant. Grafik über ACSI-DMA oder SCSI wird sicher nicht so flott sein, wie man sie am internen Systembus realisieren könnte.
Du hast ja drum gebettelt.
Grafik über SPI wird sicher nicht so flott sein, wie Grafik über DMA...
-
Das gibt's für den ST schon.
Heißt CosmosEx und unterstützt sogar DMA.
Heißt das, der CosmosEx hat quasi einen ´integrierten´ MST-Bus?
-
-> http://joo.kie.sk/?page_id=384
Da ist kein Video ...
-
Jo, aber gemeint ist wohl, den ScreenSpeicher ´rüberzukopieren, entweder in der einen Richtung:
Atari-Screen -> RasPi-Screen -> HDMI
oder in der anderen Richtung:
Raspi-Screen -> Atari-Screen (als GK-Ersatz).
-
Wieso nicht dem Rapi die VDI-Befehle schicken und den machen lassen...?
-
^^-- Stimmt, BeePi hat ja schon ein VDI, darüber hatten wir ja schon einmal diskutiert:
https://forum.atari-home.de/index.php/topic,14793.0.html
Wäre damit das missing link gefunden? TrapDoor-Bus anstatt GPIOs?
Edit.: Nee, _soo_ natürlich nicht (wenn über SPI)!
-
-> http://joo.kie.sk/?page_id=384
Da ist kein Video ...
Da auch nicht:
https://github.com/niklasekstrom/a314
-
Wie geht denn das mit dem DMA am CosmosEx?
Der ACSI/SCSI-Port? Der müßte doch schnell & breit genug sein??
-
Mir ist da glatt ein Denkfehler unterlaufen, und keiner hat es gemerkt. Aber das macht die Sache mitunter noch faszinierender und eröffnet noch interessantere Möglichkeiten. Der Trapdoor-Steckplatz im Amiga 500 ist nämlich kein Prozessorbus, das wurde er er erst beim Amiga 1200, wo ja auch Turbokarten eingebaut werden können (u.a. die Blizzard-Karten, bald wahrscheinlich auch eine spezielle Version der Vampire), aber beim A500 ist der Trapdoor-Steckplatz in erster Linie ein Speicherbus für DRAM. Sorry für diese Verwechslung.
Genau das, ein Speicherinterface für DRAM, gibts auch im ST. Wenn man jetzt eine der beiden RAM-Bänke durch Logik und RaPi ersetzen könnte, würde man auf den RaPi vom ST aus mit RAM-Geschwindigkeit zugreifen können. Das Problem ist aber, von den 40 Pins des GPIO-Ports des RaPi sind nur 25 (#2 bis #27) direkt so nutzbar, 2 weitere (#0+#1) sind zwar auf der Hauptplatine vorhanden, aber reserviert und nicht auf dem Stecker. Eine RAM-Bank bräuchte aber 16 Datenbits, R/W, RAS+CAS und 10 Adressleitungen, das macht also 29 Leitungen, reicht also nicht.
Aber man schaue sich diese Platine für den Amiga nochmal genau an. Selbst meinem hochverhten Kritiker ist nicht aufgefallen, dass da zwischen dem Amiga-Trapdoor-Steckplatz und dem GPIO-Anschluss ein FPGA und ein RAM-Baustein sitzen... In der Beschreibung steht, dass dieser RAM zwischen dem Amiga und dem Rapi geshart ist, beide können darauf zugreifen. Der FPGA macht das wohl möglich.
Spinnen wir das mal weiter. Schließen wir das Ding mal gedanklich als Bank 2 an der ST-MMU und dem Datenbus (z.B. am Shifter) an, der FPGA macht dann die Übersetzung zwischen dem DRAM-Speicherbus des ST auf den (evtl. statischen) 2 MB RAM der Adapterplatine, und auch der Rapi kann über GPIO zugreifen. Der ST sieht da dann ganz normales RAM. Dazu muss dieses RAM nur schnell genug sein, so dass sich 68000, Shifter (!!!), ggf. Blitter und RaPi nicht in die Quere kommen. 68000, Blitter und Shifter kommen sich nicht in die Quere, dafür sorgt schon Glue.
Zugriff auf die vollen 2 MB einer ST-RAM-Bank wird aus RaPi-Sicht nicht möglich sein, dazu reichen die 25 GPIO-Pins nicht. Im Amiga-Trapdoor können je nach Amiga-Chipsatz (OCS im A500, ECS im A500+) 512 kB oder 1 MB angesprichen werden, und auf dieser Platine scheint der RaPi darauf komplett Zugriff zu haben, wie das genau gemacht wird, bekommt man bestimmt über die Dateien auf der Github-Seite raus. Aber 512 kB oder 1 MB am oberen Ende des ST-RAM-Adressraums, das von beiden Seiten nutzbar ist, das reicht eigentlich schon, damit beide Prozessoren miteinander Daten austauschen können.
Wenn ich die Basis-Adresse des ST-Shifters da rein lege, kann der Rapi den Videospeicher sehen, auslesen, und über HDMI raus schicken. Allerdings fehlt ihm dazu die Information, welcher Videomodus (Low/Med/High) und welche Werte die Farbregister gerade haben.
Da müsste auf ST-Seite ein Treiber her, der einen festgelegten Teil dieses Shared-Mem alloziert und dort solche Informationen aus dem VBL geraus ablegt, die der RaPi dann auswertet. In diesem Shared-Mem könnte dann der ST-Treiber weitere Bereiche allozieren, für weiteren Datenaustausch wie Platte, USB, Netzwerk, ... und einen neuen Videomodus, der nicht im ST-RAM liegt, sondern der ST übermittelt über das Shared-Mem direkt VDI-Befehle und notwendige Bitmaps in den RaPi, der die dann in seiner Auflösung rendert. Gewisse Handshake-Mechanismen müssten da auch im RAM abgebidet werden können, damit gewisse Sachen syncronisiert serden können. Bei all diesen Funktionen kann sogar ein evtl. vorhandener Blitter mithelfen, um die Daten zwischen ST-RAM und Rapi hin und her zu schaufeln.
Bootfähig ist eun darüber angebundenes Disk-Image, oder ein Translated Laufwerk (siehe CosmosEx Translated drive) allerdings nicht, es muss immer erst von einem anderen Laufwerk der Treiber geladen werden.
Aber ich weiß, mein lieber Freund wird mir jetzt gleich wieder Visionen vorwerfen. Dss ist sogar noch einfacher, als solche Visionen zu haben. Oder man denkt mal über die Idee nach und verwirft sie dann wieder. In diesem Sinne, gute Nacht!
-
Du hast da aber deinen plan ohne den viel zu langsamen gpios gemacht ;)
-
Im Amiga 500 scheints ja auch zu gehen. Der ist bei RAM-Zugriffen auf das Trapdoor-RAM allerdings noch langsammer, da das dort Chipmem ist, auch "Slow-RAM" genannt, und das bei nur 7,14 MHz. Den Rest, was Geschwindigkeit angeht, die Syncronisiation usw., dafür ist ja die Logik im FPGA da.
-
Das Problem ist aber, von den 40 Pins des GPIO-Ports des RaPi sind nur 25 (#2 bis #27) direkt so nutzbar, 2 weitere (#0+#1) sind zwar auf der Hauptplatine vorhanden, aber reserviert und nicht auf dem Stecker. Eine RAM-Bank bräuchte aber 16 Datenbits, R/W, RAS+CAS und 10 Adressleitungen, das macht also 29 Leitungen, reicht also nicht.
Das hatte uns mfro ja schon hier:
https://forum.atari-home.de/index.php/topic,14793.msg233938.html#msg233938
vorgerechnet. Ich sehe da keinen wesentlichen Unterschied, ob nun das Video-RAM jenseits der Schnittstelle im RasPi liegt oder diesseits im/am Atari: Solange das über GPIO gehen muß bleibt das Problem mit den Raster-Ops. dasselbe.
Die Frage wäre, ob DMA ("im Hintergrund") helfen kann.
-
Hast Du dir angeschaut, wie das FPGA mit dem Pi spricht? Ich wiederhole mich: mit SPI. Da ist kein schnelles Speicherinterface, und wenn Du noch so lange Texte schreibst.
SPI ist eine serielle Zweidrahtverbindung, die im Pi unter besten Bedingungen mit etwa 30 MHz getaktet werden kann.
Die Verbindung Pi <-> FPGA schafft also im besten Fall in etwa die Geschwindigkeit einer (langsamen) SD-Karte, in der Realität deutlich weniger. Da ist m.E. die CosmosEx-Anbindung per DMA die bessere Wahl, da verschenkt man wenigstens auf der ST-Seite keinen Hauptspeicher.
Als Video-Speicher ist das allerdings reichlich ungeeignet, zugegeben. Bei Floppy- und HD-Zugriffen würde das Bild stehenbleiben wie beim ZX80...
-
Wie geschrieben, auf der Amiga-Adapter-Platine, auf der der Rapi steckt, ist RAM drauf. Das dürfte ST/Amiga-seitig mit normaler Geschwindigkeit ansprechbar sein.
Und ich denke, selbst eine nach heutigem Maßstab langsame SD-Karte ist immer noch schneller, als ACSI. Hier habe ich ein Datenblatt gefunden, wo über SPI 200 Mb/s*** rüber gehen: https://www.corelis.com/blog/spi-bus-protocol/ Den Amiga-Leuten reicht das offensichtlich für Massenspeicher- und Netzwerkanbindung, dann sollte das auch am ST reichen, ob das für Echtzeitspiegelung von Grafik reicht, müsste man testen (32kB * 70/s).
*** Selbst wenn bei dieser Angabe Mb/s das Mb für Megabit und nicht für Megabyte steht, sind das immer noch 25 Megabyte pro Sekunde!
-
Wie geschrieben, auf der Amiga-Adapter-Platine, auf der der Rapi steckt, ist RAM drauf. Das dürfte ST/Amiga-seitig mit normaler Geschwindigkeit ansprechbar sein.
Und ich denke, selbst eine nach heutigem Maßstab langsame SD-Karte ist immer noch schneller, als ACSI. Hier habe ich ein Datenblatt gefunden, wo über SPI 200 Mb/s*** rüber gehen: https://www.corelis.com/blog/spi-bus-protocol/ Den Amiga-Leuten reicht das offensichtlich für Massenspeicher- und Netzwerkanbindung, dann sollte das auch am ST reichen, ob das für Echtzeitspiegelung von Grafik reicht, müsste man testen (32kB * 70/s).
*** Selbst wenn bei dieser Angabe Mb/s das Mb für Megabit und nicht für Megabyte steht, sind das immer noch 25 Megabyte pro Sekunde!
Googelst Du nur, oder liest Du auch, was da steht?
Klar gibt es auch SPI-Interfaces, die mit 60 MHz laufen (sogar welche mit > 100) und die mehrere SPI-Kanäle (wie eine SD-Karte im "True-SD"-Mode - die hat dann praktisch vier SPI-Kanäle) zusammenfassen können und die sind dann tatsächlich - zumindest gemessen am Hardware-Einsatz - ganz schön flott.
So ein Pi schafft nun mal stabil allerhöchstens 30 MHz, hat nur einen Kanal und der ist zu allem Überfluß auch nur halbduplex (kann also nur senden *oder* empfangen, aber nicht beides gleichzeitig).
Glaub's mir, ich hab' das schon probiert. Du darfst aber natürlich gern deine eigenen Erfahrungen sammeln.
-
Googelst du auch?
http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_SPI.html
Der Treiber unterstützt folgende Geschwindigkeiten:
cdiv speed cdiv speed
2 125.0 MHz 4 62.5 MHz
8 31.2 MHz 16 15.6 MHz
32 7.8 MHz 64 3.9 MHz
128 1953 kHz 256 976 kHz
512 488 kHz 1024 244 kHz
2048 122 kHz 4096 61 kHz
8192 30.5 kHz 16384 15.2 kHz
32768 7629 Hz
Ich lese da 125 MHz.
Ist auch offiziell dokumentiert: https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md
-
Ich lese da 125 MHz.
... und, hast Du's probiert? Hat's funktioniert?
-
Und du?
-
Und du?
Wenn Du meine Beiträge lesen und nicht nur anzweifeln würdest, wüsstest Du das längst.
Wenn Du in den Quellcode schauen würdest, den Du oben verlinkt hast, wüsstest Du auch, welche SPI-Frequenz das Amiga-Dingens benutzt (mehr als ich eigentlich dachte, anscheinend hat der Autor einen besseren Pi als ich).
-
Es ist offiziell dokumentiert und es stehen keine Einschränkungen dabei. Solange du deine Zweifel nicht belegen kannst, glaube ich dir auch nicht. Die 125 Mhz ohne Einschränkung dagegen habe ich schwarz auf weiß auf zwei Webseiten vor Augen. Außerdem, die Platine für den Amiga zeigt ja, dass es funktioniert. Warum soll etwas am Amiga funktionieren, und am ST nicht?
Ich ahne aber, was du mit deiner Null-Diskussion bezweckst. Neulich beim Thema Feldstärke von HD-Disketten auch.
-
Da ist m.E. die CosmosEx-Anbindung per DMA die bessere Wahl, da verschenkt man wenigstens auf der ST-Seite keinen Hauptspeicher.
Als Video-Speicher ist das allerdings reichlich ungeeignet, zugegeben. Bei Floppy- und HD-Zugriffen würde das Bild stehenbleiben wie beim ZX80...
Hmm, wäre das soo schlimm?
(Da ich nie einen ZX80 hatte, fehlt mir das Gefühl dafür).
-
Es ist offiziell dokumentiert und es stehen keine Einschränkungen dabei. Solange du deine Zweifel nicht belegen kannst, glaube ich dir auch nicht. Die 125 Mhz ohne Einschränkung dagegen habe ich schwarz auf weiß auf zwei Webseiten vor Augen. Außerdem, die Platine für den Amiga zeigt ja, dass es funktioniert. Warum soll etwas am Amiga funktionieren, und am ST nicht?
Ehrlich gesagt ist mir das ziemlich wurscht. Warum, glaubst Du, läuft das Amiga-Ding nicht mit 125 MHz, wenn 125 MHz möglich wären?
Ich ahne aber, was du mit deiner Null-Diskussion bezweckst. Neulich beim Thema Feldstärke von HD-Disketten auch.
Träumst Du oder bin ich vergesslich? Ich kann mich jedenfalls nicht erinnern, jemals was zur Feldstärke von HD-Disketten geschrieben zu haben.
-
Ich ahne aber, was du mit deiner Null-Diskussion bezweckst.
Klär´ uns mal auf bitte.
-
Träumst Du oder bin ich vergesslich? Ich kann mich jedenfalls nicht erinnern, jemals was zur Feldstärke von HD-Disketten geschrieben zu haben.
Sorry, da hast du sogar recht, hatte ich verwechselt. Das kam damals aus so einer überraschenden Ecke, dass ich vor ein paar Wochen völlig perplex war. Warum ich das jetzt mit dir in Verbindung bringe, dafür kann ich mich nur entschuldigen.
Trotzdem. Wenn die das am Amiga schaffen, übers RAM-Interface eine Platte zu emulieren, USB und Ethernet anzubinden, warum soll das nicht im ST funktionieren? Sahnehäubchen wäre halt noch eine Grafikausgabe über HDMI. Ob die Performance für Bitmap-Kopien reicht, müsste man halt mal testen. Vielleicht geht es aber ja, wenn man dem Rapi nur VDI-Befehle weiterleitet und der die ausführt? So ala XDMCP.
Und solange ich nirgends lesen kann, dass das mit den 125 Mhz nicht funktioniert, funktioniert das eben.
-
Aus dem oben verlinkten Amiga-Projekt:
It works fine at 66 MHz, but at 100 MHz the bits are delayed by one bit. I think this concludes this experiment, with the result that we cannot do 100 MHz SPI. [...] it is possible that there are "problems" with the RPi PCB as well
Ganz offensichtlich läuft es schon mit 100 MHz nicht mehr.
-
Ok, damit haben wir beide (mfro und ich) nicht recht, aber 66 Mhz sind auch noch mehr als 30 Mhz. Und es reicht ja im Amiga, dann sollte es das im ST auch tun, solange man Grafik erstmal nicht berücksichtigt.
-
Im Amiga 500 scheints ja auch zu gehen. Der ist bei RAM-Zugriffen auf das Trapdoor-RAM allerdings noch langsammer, da das dort Chipmem ist, auch "Slow-RAM" genannt, und das bei nur 7,14 MHz. Den Rest, was Geschwindigkeit angeht, die Syncronisiation usw., dafür ist ja die Logik im FPGA da.
Du musst auch mal schauen was damit gemacht wird!!! Dazu brauchst du keine Bandbreite
-
Platte, USB, Netzwerk. Überschlagsmäßig müsste über SPI bei 66 MHz rund 8 MByte/s machbar sein.
-
Ich Lese da nur was von Platte also HDD Ersatz. Der Rest ist doch erst in Planung und noch nichts umgesetzt. Oder habe ich da was überlesen?
-
Platte, USB, Netzwerk. Überschlagsmäßig müsste über SPI bei 66 MHz rund 8 MByte/s machbar sein.
Wunschtraum.
Auch wenn der vom Autor verwendete Pi offensichtlich eine höhere SPI-clock verträgt als mein "alter" (der trotz deiner Bemühungen immer noch nur 31 MHz schafft): SPI braucht mindestens einen Takt Setup und einen Hold. Du brauchst also zehn Clocks für ein Byte. Mehr als 6,6 MByte/s können da gar nicht rauskommen.
Was Du auch noch vergessen hast: selbst wenn man für das shared memory eine der beiden ST-RAM Bänke "opfert", wie willst Du sicherstellen, daß der Zugriff des FPGAs mit dem "verschränkten RAM-Zugriff" der ST-Chips und der CPU harmoniert? In der oberen werkelt (normalerweise) der Shifter (den Du nicht anhalten kannst), überall die ST Busmaster (CPU, DMA, Blitter).
M.E. kann da auch mit viel Aufwand nichts anderes rauskommen, als CosmosEx schon kann. Das benutzt den DMA-Chip und der ist diesbezüglich schon optimal integriert.
-
Welche Festplattenlösung für den ST schafft denn 6,6 MB/s?
Außerdem wird ja nicht die komplette Bank geopfert, sondern man reserviert einen Teil der 2 MB, z.B. 512 Bytes (oder ein kleines Vilefaches davon) für den Transfer von Sektoren, plus eine Datenstruktur, über die beide Systeme miteinander kommunizieren. Der Rest ist zur weiteren Verwendung des ST. Beim Amiga wäre es noch doofer, denn das Trapdoorinterface des A500 kann nur 512 kB (A500) oder 1 MB (A500+) adressieren, und beim Amiga ist wegen seiner Architektur und des Betriebssystems Speicher noch viel "wertvoller".
-
Dann mach' mal. Ich bin gespannt.
-
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?
-
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.
-
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?
-
Einen TV bzw. Monitor per HDMI anschießen zu können würde mir auch gefallen.
-
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!
-
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.
-
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.
-
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).
-
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 (https://forum.atari-home.de/index.php/topic,14723.msg233102.html#msg233102) von @Chocco .
-
... 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?
-
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.
-
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.
-
@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 ?
-
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.
-
Die Hardware ist schon fertig -> https://www.exxoshost.co.uk/forum/viewtopic.php?f=29&t=330&hilit=hdmi
-
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.
-
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.
-
@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!
-
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
-
... Das heißt, es ist das Protokoll zwischen dem X-Server und dem X-Client (Display Manager, spricht die Grafikhardware an)...
Blödsinn.
Was Du meinst, heißt "X Window System core protocol". Das verwendet z.B. die xlib (auf der so gut wie alle Grafikfunktionen von X aufbauen).
xdm sucht lediglich (per XDMCP) nach de[m|n] nächsten verfügbaren Server[n] (im Netz per Broadcast und/oder lokal) und erlaubt, sich darauf anzumelden. Hat also mit Grafik (für die es auch das X Window System Core Protocol nutzt) nicht die Bohne zu tun.
-
Mal @Chocco fragen, was bei ihm unter BeePi so alles läuft.
Irgendwie werd ich das Gefühl nicht los daß manch einer nicht so den richtigen Durchblick hat wovon er überhaupt spricht. BeePi ist genau das wovon ich gesprochen habe: ein RaspPi, auf dem debian und darauf aufgesetzt Aranym (oder auch Hatari) läuft.
-
Was Du meinst, heißt "X Window System core protocol".
Das wiederum ist eine Teilmenge dessen, was ich meine. den das Core-Protokoll alleine ist nicht netzwerkfähig, das wird es erst durch XDMCP.
-
So ein Protokoll ist noch für einen 8Mhz 68K Rechner viel zu viel ...
-
Was Du meinst, heißt "X Window System core protocol".
Das wiederum ist eine Teilmenge dessen, was ich meine. den das Core-Protokoll alleine ist nicht netzwerkfähig, das wird es erst durch XDMCP.
Du solltest dich bei Sachen, wo Du dich nicht auskennst, echt ein bißchen zurücknehmen. Das ist schon wieder Quatsch.
-
^^-- Nebelschwadenl im OT! Kommt wieder auf den Teppich!
=======
Irgendwie werd ich das Gefühl nicht los daß manch einer nicht so den richtigen Durchblick hat wovon er überhaupt spricht. BeePi ist genau das wovon ich gesprochen habe: ein RaspPi, auf dem debian und darauf aufgesetzt Aranym (oder auch Hatari) läuft.
Thorsten, lies bitte mal nach: Nicht Du warst es, sondern ich, der von BeePi schrieb: Siehe Zitat in #56. Ich sehe ja nur das Geschriebene, was Du in Deinen Bart gemurmelt/gesprochen hast, das weiß ich nicht.
-
Was Du meinst, heißt "X Window System core protocol".
Das wiederum ist eine Teilmenge dessen, was ich meine. den das Core-Protokoll alleine ist nicht netzwerkfähig, das wird es erst durch XDMCP.
Du solltest dich bei Sachen, wo Du dich nicht auskennst, echt ein bißchen zurücknehmen. Das ist schon wieder Quatsch.
Wieviele Linux basierte Terminalserver mit XDMCP unterstützenden Thinclients hast du denn schon aufgebaut? (Ich habe für so einen Thinclient schonmal ein Installationshandbuch geschrieben, unter Berücksichtigung der Eigenheiten diverser Linux-Distributionen und diversen Unix-Derrivaten - ein Exemplar dieser Thinclients habe ich auch noch, das ist jetzt auch schon Retro)
-
So ein Protokoll ist noch für einen 8Mhz 68K Rechner viel zu viel ...
Da hast du recht, XDMCP ist recht komplex, aber wenn du die VDI- und AES-Syscalls wie auch immer auf ein Remote-System schicken kannst, und dieses diese ausführt, sieht das anders aus. XDMCP diente nur als Vergleich, weil es genauso die Grafikbefehle weiterleitet. (Dazu im Gegensatz VNC, RDP ind ICA, welche die gerenderten Bitmaps weiterleiten)
Aber ari.tao hat schon recht, wir gehen immer weiter Offtopic. XDMCP war nur als Beispiel gedacht, wie ich das meine. Es ging mir nicht um dieses spezielle Protokoll, sondern um das Funktionsprinzip. Inzwischen scheint diese Message auch zu allen durchgedrungen zu sein. Daher werde ich auf weitere Grundlagen dazu nicht eingehen. Naja, wenn ich mein X-Terminal mal wieder zum Laufen gebracht habe (Netzteil kaputt), werde ich mal versuchen, ob man XDMCP unter dem X-Window Paket von MiNT freischalten kann, mal sehen ob der TT als Terminalserver taugt, wenns auch auf einem Singleusersystem nicht wirklich sinnvoll ist...
-
Das wiederum ist eine Teilmenge dessen, was ich meine. den das Core-Protokoll alleine ist nicht netzwerkfähig, das wird es erst durch XDMCP.
Vielleicht solltest Du mal das hier: https://www.x.org/docs/XProtocol/proto.pdf lesen, bevor Du das nächste Mal ein Handbuch schreibst.
-
Ihr habt die beiden Betriebsarten, die ich für die Rapi-Sache vorgeschlagen habe, verstanden. Das reicht. Das ganze wird eh nix, genau wie Vampire im ST könnt ihr nur zerreden. Wie gut, dass Vampire dann doch kommt.
-
To pi or not to pi, that is the question!
-
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.
Hab da vor ca. nem Jahr schon mal geguckt und gefällt mir eigentlich, aaaabbbbeeerrr. Sound über HDMI fehlt und die STE's werden nicht unterstützt. Es scheint aber auch noch nicht final zu sein, auch wenn man damit evtl. schon arbeiten könnte. Probleme mit Spielen bzw. Demos sind auch noch vorhanden. Hoffentlich hat Smonson noch Lust. Aber alle Achtung so weit zu kommen.
-
^^-- Nicht bloß die (M)STEs werden nicht unterstützt, sondern auch TT & Falcon nicht, also nur die kleinen STs. Schon deshalb ist das imho keine Rose.
Und die Erweiterung der Grafik-Auflösung (720x480x1p) ist auch nicht gerade üppig.
-
Und die Erweiterung der Grafik-Auflösung (720x480x1p) ist auch nicht gerade üppig.
Etwa die gleiche Auflösung bekommt man mit AutoSwitch-Overscan auch hin, man muss aber dem SM-124 nachjustieren, damit die äußeren Pixel nicht hinter dem Plastikrand des Monitorgehäuses verschwinden.
-
Das ist doch garnicht möglich alle Atari Rechner mit ein und der selben Erweiterung zu unterstützen. Und mehr als die System Auflösungen wird da nicht möglich sein. Ist ja keine Grafikkarte über die eh nichts an Spielen etc. läuft.
-
Aber darum ging doch die ganze Diskussion: Eine Erweiterung mittels RasPi zu schaffen, die für alle Ataris mit einem geeigneten Bus funzt (also alle).
-
^^-- Nicht bloß die (M)STEs werden nicht unterstützt, sondern auch TT & Falcon nicht, also nur die kleinen STs. Schon deshalb ist das imho keine Rose.
Und die Erweiterung der Grafik-Auflösung (720x480x1p) ist auch nicht gerade üppig.
VGA finde ich noch OK.
-
VGA wäre doch 640x480x8p, oder?
Das macht das Teil aber nicht! Noch nicht einmal 640x480x4p.
-
VGA wäre doch 640x480x8p, oder?
Das macht das Teil aber nicht! Noch nicht einmal 640x480x4p.
Verstehst du es extra falsch oder ist das jetzt ernst gemeint? Der Falcon und der TT können alle Auflösungen die sie beherschen über VGA an den Monitor geben... TT-High nur an ECL-Monitor oder mittels ECL-VGA-Adapter.
Nur wegen HDMI bzw. DVI erhöht sich ja nicht die Auflösung des ST an sich oder nur im Rahmen wie 1ST1 oben erklärte.
-
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.
Unter BeePi arbeitet Aranym als Kompilat für die ARM Architektur. Die Aranym-68K-Emulation arbeitet auf einem der vier Kerne des Raspi mit beachtlicher Geschwindigkeit. Im Prinzip läuft also jede Software, die auch unter x86 als Basis der Emulation von Aranym läuft.
Software, die unter Aranym-x86 nicht funktioniert, läuft demnach auch nicht unter BeePi.
-
To pi or not to pi, that is the question!
Die Frage ist doch, was tatsächlich das Ziel sein soll. Möchte man native 68K-Software auf nativer Hardware laufen lassen, dann ist die Vampire sicher eine sehr elegante Wahl. Möchte man 68K-Software in einer Emulation laufen lassen, dann ist die Wahl des Host-Systems relativ egal, weil inzwischen alle Systeme schnell genug sind. Da reicht dann eben auch ein 30€ RPi.
Weiterhin kann man über ein Hybrid-System nachdenken. Ähnlich XWindows, könnte man ein "Terminal-VDI" einsetzen, um Grafik-Ausgaben und User-IO an einen Bildschirm zu schicken, der nicht zwangsweise Bestandteil eines (Atari) GEM-Computers ein muss. Da über das VDI alle IO-Funktionen bereitgestellt werden, könnte man sowas sicher realisieren.
AES und VDI sind im regulären TOS eng verknüpft. Ein AES, welches mit einem Terminal-VDI funktioniert, müsste entsprechend vorbereitet sein. Sämtliche mir bekannten AES wären aktuell dazu nicht in der Lage. Die AES gehen aktuell immer davon aus, per open workstation das Handle einer (internen) Grafikeinheit zu erlangen, die einen direkten Zugriff auf den Grafikspeicher erlaubt. Bei einem Terminal-VDI funktioniert das nicht.
Die VDI-Raster-Funktionen erwarten, dass ein Raster im Arbeitsspeicher adressiert werden kann. Damit kann auch der Bildspeicher gemeint sein, der bei einem Termial-VDI natürlich nicht adressiert werden kann. Sauber arbeitende Programme, die als Quell-/Zielrasterfür den Bildschirm NULL angeben, könnten weiterhin funktioneren. Hier wäre nur die Anbindungsgeschwindigkeit zum Transport der Rasterdaten der begrenzende Faktor.
Einen RPi als Client für ein Termial-VDI zu verwenden hätte den Charme, dass er über eine GPU verfügt, die im Vergleich zu allem, was sonst für die Atari-Plattform verfügbar ist, rasant schnell ist.
Andererseits ist auch sicher, dass nur Software, die sauber nach VDI/AES Regularien entwickelt wurde, mit einer solchen Lösung klar kommt.
-
... AES und VDI sind im regulären TOS eng verknüpft. Ein AES, welches mit einem Terminal-VDI funktioniert, müsste entsprechend vorbereitet sein. Sämtliche mir bekannten AES wären aktuell dazu nicht in der Lage...
Prinzipiell ist das - bei ausreichend Platz und ausreichend Performance - ein lösbares Problem (bzw. ist schon - zumindest teilweise - gelöst). Dem AES ist das relativ egal, es greift immer auf das VDI zurück, um irgendwelche Bildschirm-Manipulationen durchzuführen.
Im CT60 TOS gibt es eine ähnliche Problematik: der Speicher auf der Beschleunigerkarte is um ein Vielfaches schneller als der Grafikspeicher auf der "Legacy-" (Falcon-) Seite. Der fVDI VDI-Treiber im CT60 TOS führt deswegen (optional) *zwei* Bildschirmspeicher mit. Jedes direkt geschriebene Pixel wird *zweimal* geschrieben: im eigentlichen Bildschirmspeicher *und* im Shadow-Speicher im schnellen RAM.
Komplexere (read-modify-write) Screen-Memory Operationen können dann im schnellen RAM vorbereitet und nur das Ergebnis *einmal* in den (langsamen) "echten" Bildschirmspeicher übertragen werden.
Damit spart man in vielen Fällen eine (langsame) Leseoperation. Anscheinend ist es für komplexere Operationen (z.B. das Invertieren eines Menüpunktes - "lesen"-"XOR"-"schreiben") in der Summe schneller, das im schnellen RAM zu tun und nur das Ergebnis in den "echten" Bildschirmspeicher zu schreiben. Die zusätzliche (schnelle) Schreiboperation kostet wohl weniger als die dadurch gesparte (langsame) Leseoperation.
Für einen ST wäre das allerdings ziemlicher Overkill und (wahrscheinlich) schnarchlangsam.
-
AES und VDI sind im regulären TOS eng verknüpft. Ein AES, welches mit einem Terminal-VDI funktioniert, müsste entsprechend vorbereitet sein.
Ganz so eng sind die nicht verküpft, zumindest nicht in TOS 2.x/TOS 3.x, und auch nicht in EmuTOS. Sonst wären ja auch andere VDI nicht so leicht in der Lage das zu ersetzen. Was dort verknüpft ist sind allerdings die BIOS-Funktionen die auf den Bildschirm ausgeben, die müssen dann auch entsprechend abgefangen werden. Ausserdem natürlich Line-A, das schon seit 1989 "deprecated" ist aber immer noch fleissig von einigen Programmen benutzt wird.
Die AES gehen aktuell immer davon aus, per open workstation das Handle einer (internen) Grafikeinheit zu erlangen, die einen direkten Zugriff auf den Grafikspeicher erlaubt.
s.o., das stimmt so nicht ganz. AES selber greift in keiner Weise direkt auf den Bildschirmspeicher zu oder macht da irgendwelche Annahmen, das geht alles über VDI-Funktionen.
-
...Jedes direkt geschriebene Pixel wird *zweimal* geschrieben: im eigentlichen Bildschirmspeicher *und* im Shadow-Speicher im schnellen RAM.
Komplexere (read-modify-write) Screen-Memory Operationen können dann im schnellen RAM vorbereitet und nur das Ergebnis *einmal* in den (langsamen) "echten" Bildschirmspeicher übertragen werden.
Verstehe ich das richtig, daß der CT60 ein eigener Video-Port fehlt? Das wäre ja mit dem RasPi anders (und mit dem Vampir (hoffentlich) auch).
-
Verstehe ich das richtig, daß der CT60 ein eigener Video-Port fehlt?
Die CT60 benutzt ohne Zusatzhardware das ganz normale Falcon-Videosystem.
Das wäre ja mit dem RasPi anders.
... und was würde das nutzen, wenn der Bus dahin ein Bummelzug ist?
-
@ari.tao: TT und Falcon würde ich bei der Betrachtung außen vor lassen, die haben VGA, was vielfach von noch halbwegs modernen TFTs unterstützt wird, und VGA-zu-HDMI-Konverter sind auch kein Hexenwerk, DVI-I frisst das per mechanischem Adapter direkt, und das Bild bei VGA bei nicht übertriebener Kabellänge ist gut. Für TT und Falcon gibts auch bereits genügend Grafik-, Netzwerkkarten und tlw, USB.
@mfro : Freut mich, dass es endlich Klick gemacht hat und , Danke @Chocco.
Ob aus der Idee was werden kann, ist eine andere Sache.
-
@mfro : Freut mich, dass es endlich Klick gemacht hat und , Danke
Klick?
Beim Falcon mit CT60 reden wir von der Differenz der Speicherbandbreiten zwischen mehreren hundert MB/s und wenigen MB/s, das "doppelt halten" von Videospeicher ist nicht schlimm, weil Platz genug da und die CPU schnell genug ist.
Das ist mit der Situation in einem ST und einem - noch so schnellen - Pi (mit immer noch langsamen GPIOs) m.E. nicht mal ansatzweise vergleichbar. Wenn der ST zweimal in seinen Videospeicher schreiben müsste, um ein Bild zu bekommen, würde in keiner mehr benutzen wollen. Tut mir leid, für mich ist das weiterhin eine Schnapsidee.
-
Wie geschrieben, es geht nicht um den Falcon.
-
Mal angenommen, es geht am ST: Warum sollte es dann an F30 & TT nicht gehen?
Bin mal gespannt, was bei tuxies Tests mit SPI herauskommt. Und wo der Vampir anbeißt.
=======
Kennt sich jemand mit der Einbindung von CoProcs aus?
-
Beim TT und Falcon wird sowas schlicht nicht gebraucht, weil es dafür alles gibt.
-
AES und VDI sind im regulären TOS eng verknüpft. Ein AES, welches mit einem Terminal-VDI funktioniert, müsste entsprechend vorbereitet sein.
Ganz so eng sind die nicht verküpft, zumindest nicht in TOS 2.x/TOS 3.x, und auch nicht in EmuTOS. Sonst wären ja auch andere VDI nicht so leicht in der Lage das zu ersetzen. Was dort verknüpft ist sind allerdings die BIOS-Funktionen die auf den Bildschirm ausgeben, die müssen dann auch entsprechend abgefangen werden. Ausserdem natürlich Line-A, das schon seit 1989 "deprecated" ist aber immer noch fleissig von einigen Programmen benutzt wird.
Stimmt, ich habe mich ungenau ausgedrückt. Ich hatte mir explizit nur XaAES angeschaut und dort wird während der Initialisierung ziemlich viel "ausprobiert" und "gehofft", welche workstation-ID denn nun zu nehmen sei. Beim TOS-AES wird wohl einfach das XBIOS befragt (?).
Die AES gehen aktuell immer davon aus, per open workstation das Handle einer (internen) Grafikeinheit zu erlangen, die einen direkten Zugriff auf den Grafikspeicher erlaubt.
s.o., das stimmt so nicht ganz. AES selber greift in keiner Weise direkt auf den Bildschirmspeicher zu oder macht da irgendwelche Annahmen, das geht alles über VDI-Funktionen.
Danke für die Aufklärung. Ich hatte überschlägig im TOS-AES eigene Blt-Funktionen gesehen und war davon ausgegangen, dass hier seitens Atari "optimiert" wurde. Wenn diese Funktionen jedoch selbst wieder das VDI aufrufen, dann ist ja alles in Butter.