Allgemeines > Atari - Talk

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

(1/6) > >>

Chocco:
Hallo zusammen,
mit vollem Interesse habe ich heute einen Thread verfolgt, in dem die Portierung von EMU-TOS auf die ARM-Plattform aufgezeigt wurde. Als Basis hierfür dient aktuell ein Raspberry Pi.

Zunächst mal höchsten Respekt für dieses Vorhaben! Eine ELF Startmodul für ein Betriebsystem zu entwickeln, gehört in meinen Augen zu den hohen Weihen der Entwicklerkunst.

Da die Portierung auf nativen ARM-Code erfolgt, werden dort natürlich auch nur native Anwendungen ausgeführt werden können, d.h. 68k Software muss neu für die Zielplattform kompiliert werden. Das ist an sich nichts schlimmes und es gab sogar eine Zeit, in der Software eigentlich immer als Quelltext geliefert wurde, um sie dann auf dem Zielsystem zu bauen.

EMU-TOS ist ein super Projekt und ich verwende es selber gerne, um Emulatoren auf die Beine zu helfen.

Andererseits: Wenn schon eine Portierung, dann sollte man sich doch auf die Dinge konzentrieren, bei denen eine Portierung Sinn macht.

Ein Single-User TOS/GEMDOS als Basis ist in meinen Augen völlig obsolet und warum sollte man einen RPi, der über ein wunderbares Linux verfügt, mit einem solchen Anachronismus starten wollen? Das Teil besitzt immerhin 4 Kerne, 1GB RAM und taktet mit 1,2 GHz.

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?


   

Arthur:

--- 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... den in ein ST-Gehäuse und das Retrofeeling ist perfekt. Original Programme laufen ohne neue kompilierung... natürlich nicht so schnell wie bei deinem Vorschlag aber der Aufwand ist geringer...

Sonst würde ich an deiner Stelle mit dem entsprechendem know how zu einer Firebee greifen.

Börr:
What!!!?!?!?!?!?!?!?
Warum Linux als Unterbau, wenn man ein eigenes OS hat. Man könnte ja die anderen Kerne mit 68k Emulatoren für Abwärtskompatibilität nutzen.

mfro:

--- Zitat von: Chocco am Mi 27.06.2018, 22:18:51 ---Was meint ihr?

--- Ende Zitat ---

Wenn's Spaß macht - warum nicht?

In EmuTOS sind - grob geschätzt - etwa 5000 Zeilen m68k-Assemblercode drin, die man angreifen muss.

Den auf ARM zu portieren (es darf ja auch z.B. ein Zero sein, dann sind keine Kerne "übrig") erscheint mir persönlich einfacher, als VDI- und AES- (System-) Calls in ein (Linux-) Betriebssystem "einzuhäkeln", das strikte Prozesstrennung einhält und für jeden Prozess einen eigenen virtuellen Adressraum erzwingt. Ausserdem wäre das dann ja wohl kein TOS mehr...

Die Stellen, die man anpacken muss (abgesehen von direkten Hardwarezugriffen, die offensichtlich sein dürften) sind bereits (für die native ColdFire-Implementierung) ziemlich eindeutig identifiziert.

Nativer m68k-Code könnte mit dem von Vincent umgehäkelten m68k-Emulator Musashi ("68kemu" auf GitHub) ausgeführt werden. Der implementiert lediglich die CPU-Emulation und übergibt alle Systemcalls an das OS. Emulierte Programme können so von den schnelleren Betriebssystemroutinen profitieren.

Ob das ganze Unterfangen "sinnvoll" ist, ist eine andere Frage. Wie sinnvoll ist es überhaupt, sich (egal ob ARM, x86 oder m68k) mit so archaischem Zeugs zu beschäftigen? Die Antwort steht oben ;)
 

Chocco:

--- Zitat von: Börr am Mo 02.07.2018, 11:31:32 ---What!!!?!?!?!?!?!?!?
Warum Linux als Unterbau, wenn man ein eigenes OS hat. Man könnte ja die anderen Kerne mit 68k Emulatoren für Abwärtskompatibilität nutzen.

--- Ende Zitat ---

Das "eigene OS" besteht ja nun aus mehreren Teilen und wenn ich mir MINT ansehe, welches nach POSIX schon UNIX kompatibel ist, dann könnte man als Basis doch direkt ein Linux oder BSD-UNIX nehmen und den Hirnschmalz lieber ins VDI und AES stecken. Zudem war GEM von DR damals ja extra so entworfen worden, dass es auf verschiedenen Plattformen lauffähig sein sollte.

Ein Vorteil wäre dann, dass sich die Probleme bei der Treiberunterstützung der Basisdienste (Netzwerk, USB, Tastatur, Maus, usw) nahezu in Luft auflösen würden.

Zum Spass habe ich mir die GEM/3-Sourcen vor einigen Monaten mal geladen und und begonnen, einen GDOS VDI-Treiber auf Basis des Framebuffer Device für den RPi zu bauen. Der x86-Assembler des Original VDI ist ziemlich ekelig, aber dank EmuTOS hatte ich dort eine gute Informationsquelle.

Da der Framebuffer nicht mehr state of the art ist und der RPi eine HW-Beschleunigung bietet und zudem openVG unterstützt, baue ich meine Sourcen gerade auf diese Basis um https://de.wikipedia.org/wiki/OpenVG

Für das AES fällt mir bestimmt auch noch etwas ein...
Und das alles auch nur, weil es Spass macht :)
 

Navigation

[0] Themen-Index

[#] Nächste Seite