Allgemeines > Atari - Talk

EMU-TOS native auf einem Raspberry Pi - macht das Sinn?

<< < (2/6) > >>

Chocco:

--- Zitat von: Arthur am Do 28.06.2018, 00:42:25 ---
--- Zitat von: Chocco am Mi 27.06.2018, 22:18:51 ---
Wenn ich mir ein Projekt ausdenken dürfte, dann würde ich nur VDI und AES nativ auf ARM portieren und als Basis das bereits vorhandene Linux nehmen. Das wäre dann ziemlich nah an der Kombi MINT+NVDI+XaAES.

Was meint ihr?
 

--- Ende Zitat ---
Denke da es ja das VDI das alle Umstände berücksichtigt nicht gibt und der Quellcode von NVDI auch kein open source ist... also sehr Zeitaufwändig ist. Da ist es einfacher für ein anderes Linux mal Steem, QEmu, Hatari neu zu kompilieren das auf dem pi dann schneller als dem TT läuft.

--- Ende Zitat ---

Vielleicht bin ich ja einfach nur durch PC-GEM "verseucht", aber mir geht es garnicht um die Nutzung alter Atari-Software, die man natürlich auf diversen Emulatoren perfekt zum Fliegen bringt. Mich hat das original GEM von Digital Research damals sofort verzaubert und da PCs doof und teuer waren, hatte ich mich damals halt für einen Atari 1040ST entschieden und war über einige Jahre glücklich in beiden GEM-Welten unterwegs.

Ich wiederhole mich vermutlich, aber Atari hat damals den Fehler gemacht, das Konzept von GEM/VDI zu kastrieren, nur um schnell eine Maschine auf den Markt bringen zu können. Diese Kastration führte dann zu Notlösungen, wie AMC-GDOS oder NVDI. Als seitens Atari irgendwann SpeedoGDOS nachgereicht wurde, war der Zug leider längst abgefahren.

Egal. Ein herkömmlicher VDI-Treiber für eine Grafikkarte umfasst bloß einige Kilobyte. Treiber für /dev/fb lassen sich relativ leicht implementieren. Das GDOS selbst macht nicht viel und ist schnell portiert. Das original AES ist ziemlich schmal und für ein Multitasking AES gibt es ebenfalls Vorlagen.

Werde mal weiter an meiner Software schrauben, die spätestens bei Erreichen der Rente fertig sein sollte  :)
Grüße

Arthur:
Was? In zwei Jahren soll das bereits zufriedenstellend laufen? >:D

mfro:

--- Zitat von: Chocco am Mi 04.07.2018, 21:16:21 ---... Diese Kastration führte dann zu Notlösungen, wie AMC-GDOS oder NVDI. Als seitens Atari irgendwann SpeedoGDOS nachgereicht wurde, war der Zug leider längst abgefahren...

--- Ende Zitat ---

Das würde ich übrigens im Nachgang eher als Glücksfall bewerten. NVDI hätte es wahrscheinlich in der Qualität nie gegeben, wenn Atari ein wenigstens halbwegs brauchbares GDOS abgeliefert hätte. Die bekannten Schwierigkeiten des originalen VDIs haben so wenigstens dazu geführt, dass eine recht gut dokumentierte Schnittstelle offen blieb, weil Atari selbst noch ein "Hintertürchen" brauchte.

Chocco:

--- Zitat von: Arthur am Mi 04.07.2018, 21:40:18 ---Was? In zwei Jahren soll das bereits zufriedenstellend laufen? >:D

--- Ende Zitat ---

Die Portierung der GEM/3 Sourcen (GDOS+Generic Screendriver auf 32bit ARGB) auf den RPi haben ca. 80h Stunden meiner Freizeit verbraucht. Wobei einige x86-Sourcenn noch nicht in C umgesetzt sind. Die Umsetzung der Algorithmen für die Polyline-Befehle, sowie Linienbreiten >1 Pixel sind etwas eklig und bei der Umsetzung des BitBlt begann ich dann auch etwas zu straucheln. Im Prinzip ist das 32-Bit Zielraster simpel, aber die Umrechnung Plane-basierter Quellraster mit Paletten benötigt doch einiges an Konzentration, die ich Abends nur schwer aufbringen kann. Von daher verspreche ich mir einige Unterstützung von der openVG Implementation im RPi :)

Chocco:

--- Zitat von: mfro am Mi 04.07.2018, 21:50:44 ---
--- Zitat von: Chocco am Mi 04.07.2018, 21:16:21 ---... Diese Kastration führte dann zu Notlösungen, wie AMC-GDOS oder NVDI. Als seitens Atari irgendwann SpeedoGDOS nachgereicht wurde, war der Zug leider längst abgefahren...

--- Ende Zitat ---

Das würde ich übrigens im Nachgang eher als Glücksfall bewerten. NVDI hätte es wahrscheinlich in der Qualität nie gegeben, wenn Atari ein wenigstens halbwegs brauchbares GDOS abgeliefert hätte. Die bekannten Schwierigkeiten des originalen VDIs haben so wenigstens dazu geführt, dass eine recht gut dokumentierte Schnittstelle offen blieb, weil Atari selbst noch ein "Hintertürchen" brauchte.

--- Ende Zitat ---

Das "Hintertürchen" ist doch genau das Problem. Für PC-GEM standen noch vor Erscheinen des Atari-ST generische Treiber für eine Vielzahl an Druckern und sonstige Ein-/Ausgabegeräte bereit. Dank des fehlenden GDOS im Atari GEM musste jedoch jede Anwendung wieder eigene Treiber mitbringen. Anfänglich war das kein Problem, weil gelebt damals jede Software eigene Treiber mitbringen musste - bis auf den Mac natürlich :) Spätestens mit Erscheinen von Windows 3 war der Drop dann endgültig gelutscht.

NVDI war und ist natürlich eine Perle und die Gebrüder Behnke haben einen wirklich tollen Job gemacht! Wäre toll, wenn die Brüder ihr NVDI als OpenSource freigeben würden :)

Für Atari USA war dieses europäische Gewese um den ST und später den TT völlig unverständlich. Alwin Stumpf hatte es in einem Interview so formuliert, dass der Stellenwert der TOS-Rechner in den USA als eher gering eingeschätzt wird, weshalb man sich auf die IBM-Kompatiblen Atari-Rechner fokussieren wird. Selbst dabei hat Atari USA dann leider auch wieder voll verkackt.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete