atari-home.de - Foren

Allgemeines => Atari - Talk => Thema gestartet von: Chocco am Mi 27.06.2018, 22:18:51

Titel: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Chocco am Mi 27.06.2018, 22:18:51
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?


   

Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Arthur am Do 28.06.2018, 00:42:25

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?
 

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.
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag 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.
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: mfro am Mo 02.07.2018, 13:18:39
Was meint ihr?

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 ;)
 
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Chocco am Mi 04.07.2018, 20:26:23
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.

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 (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 :)
 
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Chocco am Mi 04.07.2018, 21:16:21

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

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

Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Arthur am Mi 04.07.2018, 21:40:18
Was? In zwei Jahren soll das bereits zufriedenstellend laufen? >:D
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: mfro am Mi 04.07.2018, 21:50:44
... 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...

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.
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Chocco am Mi 04.07.2018, 22:08:54
Was? In zwei Jahren soll das bereits zufriedenstellend laufen? >:D

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 :)
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Chocco am Mi 04.07.2018, 22:35:31
... 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...

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.

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.
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: gh-baden am Mi 04.07.2018, 23:31:58
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.

Bei GEM am PC störte mich nur der Speichermangel, ansonsten Zustimmung.

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.

Wu? Schon AMC-GDOS waren Längen besser als das originale Atari-GDOS. Und NVDI ist IMHO in einer ganz anderen Liga, sowohl was Umfang, Fehlerarmut und erst recht Geschwindigkeit angeht. Kein Atari ohne NVDI.

Ich kann deinen Ansatz mit "GEMwoandersdrauf" durchaus nachvollziehen. Und da es inzwischen einige Programme am Atari im Source gibt, sind die mit nicht allzu großem Aufwand auch zu portieren. GEMDOS und GEM auf MIPS, ARM oder RISC-V wäre schon ulkig :-)
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: tuxie am Do 05.07.2018, 00:22:38
Dieses Thema hat mich schon vor vielen Jahre beschäftigt nur habe ich zu der Zeit niemanden gefunden der halbwegs so gut Programmieren konnte um das TOS auf eine andere Platform zu bringen. Gibt da ja auch andere Ansätze wie zum Beispiel ToS ins OpenBIOS zu integrieren. Die Abwärtskompatibilität steht dabei eigentlich gar nicht so im Vordergrund sondern eher die Usability. und Benutzbarkeit der Anwendung.
Ich finde es echt cool was du da machst... 
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Chocco am Do 05.07.2018, 00:42:36

Wu? Schon AMC-GDOS waren Längen besser als das originale Atari-GDOS. Und NVDI ist IMHO in einer ganz anderen Liga, sowohl was Umfang, Fehlerarmut und erst recht Geschwindigkeit angeht. Kein Atari ohne NVDI.

Ich kann deinen Ansatz mit "GEMwoandersdrauf" durchaus nachvollziehen. Und da es inzwischen einige Programme am Atari im Source gibt, sind die mit nicht allzu großem Aufwand auch zu portieren. GEMDOS und GEM auf MIPS, ARM oder RISC-V wäre schon ulkig :-)

Ja, PC-GEM krankte damals tatsächlich an Speicherproblemen. Bei PC-GEM hatten wir uns mit der Overlay-Technik beholfen, d.h. es gab einen 64kByte Slot, in den verschiedene Module bei Bedarf nachgeladen werden konnten. Das Hauptprogramm lief immer während, wo hingegen sämtliche Dialoge zur Konfiguration der E/A-Module (Erfassung von Telemetriedaten) in diesen 64K-Slot geladen und bearbeitet werden konnten. Diese Technik unterstützte damals übrigens ganz hervorragend der C-Compiler von Microsoft – ganz ohne Windows ;) Unsere größten Anwendung hatte damals weit über ein MB und die Größenbeschränkung der RSC-Dateien auf 64kB erforderten einigen Klimmzüge, um sie der Gesamtanwendung zugänglich machen zu können. Hat aber Spass gemacht und als rein industrielles Produkt, wurde es tatsächlich weltweit vermarktet. Bis der Wettbewerb uns mit Windows dann doch den Rang ablief.

Nach der reinen Lehre seitens Digital Research (DR), sollte eine GEM-Anwendung für alle Systeme übersetzbar sein, so lange diese Anwendung nur Aufrufe über AES, GEMDOS und VDI verwendet.

Die verfügbaren 68k Emulatoren laufen super und ein TT/ST, wie auch immer, rennt in der Emulation unter Aranym schneller, als mein Milan auf einem echten 68040. Andererseits fühlen sich Emulationen auch immer ein wenig an, wie "Sex mit Gummi" :)

Nach meiner Ansicht, könnte man relativ schnell ein RPi-GEM erstellen. Basis wäre das verfügbare und ständig gepflegte Debian Linux und statt des wohl mächtigsten und schlimmsten Window Manager "X-Windows" täte man dafür lieber ein schlankes VDI/AES bauen – und natürlich ein GEMDOS API *rülps*.

Auf Basis dieser genialen und flinken Kombination HW-naher Komponenten setzt man anschließend einen User-Space in Form von Ruby-Objekten! Ähnlich SmallTalk und voller cooler Objekte, mit denen sich über die GPIO-Ports des RPi Bastelroboter oder 3D-Drucker steuern lassen – *kreisch*

Okay, das ist meine persönliche Version einer sehr coolen Maschine. Das GEM-VDI könnte im Prinzip auch einen 3D-Drucker befeuern, denn jede Druckseite wäre dann nur noch eine weitere Schicht auf dem 3D-Drucker. Das DR das Ende der 70ern schon ahnte, verblüfft mich tatsächlich ;)
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: MJaap am Do 05.07.2018, 21:20:40
pTOS ist ein echt interessantes Projekt, ich würde da nicht nach dem Sinn fragen. Es wäre natürlich faszinierend, später zu sehen, wie ein NetSurf, ScummVM oder ein Emulator auf dem Ding "rennt".

NVDI war eine feine Sache - ersetzte nicht nur das GDOS, sondern auch gleich "Bildschirm-Blitter" wie Turbo ST. Leider gibt es noch immer kein freies VDI mit Unterstützung für Vektorfonts (Experimente in der Richtung gab es vor vielen Jahren).

Ataris Software... ja, irgendwie tat sich da erschreckend wenig. Erst in den letzten Jahren wurde Atari aktiver, mit dem NewDesk, SpeedoGDOS, AtariWorks oder MiNT - und das waren zum Teil nicht mal Eigenentwicklungen.
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: 1ST1 am Do 05.07.2018, 23:33:48
Ich bin skeptisch, was die Portierung von EmuTOS bzw. MiNT auf andere Plattformen mit modernen CPUs angeht. Die Software unterstützung wird fehlen, und moderne Betriebssysteme mit modernen Anwendungen passen da eher besser drauf.
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Thorsten Otto am Fr 06.07.2018, 01:13:19
Leider gibt es noch immer kein freies VDI mit Unterstützung für Vektorfonts (Experimente in der Richtung gab es vor vielen Jahren).

Das ist so nicht ganz richtig. fVDI kann schon lange freetype als backend benutzen (wenn auch eine etwas ältere Version), und damit auch TrueType und Type1 Vektorfonts benutzen. Ob das auf einem "normalen" Atari allerdings schnell genug ist, ist eine andere Frage.
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Chocco am Di 31.07.2018, 19:22:35
Leider gibt es noch immer kein freies VDI mit Unterstützung für Vektorfonts (Experimente in der Richtung gab es vor vielen Jahren).

Das ist so nicht ganz richtig. fVDI kann schon lange freetype als backend benutzen (wenn auch eine etwas ältere Version), und damit auch TrueType und Type1 Vektorfonts benutzen. Ob das auf einem "normalen" Atari allerdings schnell genug ist, ist eine andere Frage.

Die "normale" Atari Hardware ist mit Antialiasing und Vektorfonts sicher überfordert. Selbst mein Milan mit NVDI baut Seiten mit Vektorschriften ziemlich zukelig auf. Ich habe Aranym auf dem Raspberry mit dem BeePi Package getestet  und war echt begeistert von der Geschwindigkeit mit fVDI https://sites.google.com/site/emaappsarch/news/beekeyandbeepibeta9areavailable (https://sites.google.com/site/emaappsarch/news/beekeyandbeepibeta9areavailable).

Meinen ersten Anlauf, einen VDI-Treiber auf Basis der alten DR-Sourcen zu bauen, habe ich erstmal gestoppt und die Implementation über openVG begonnen. Egal was aus pTOS wird, kann dies dann immer noch als Basis für etwas anderes verwenden.

Anbei noch ein Foto von meinem BeePi-Atari:

(http://beacit.de/downloads/aranym_piceed.jpg)
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Börr am Do 02.08.2018, 12:35:03
Was sieht man da?
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Arthur am Do 02.08.2018, 12:47:11
Was sieht man da?

Lies mal Antwort #16.
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Börr am Fr 03.08.2018, 09:49:48
Was sieht man da?

Lies mal Antwort #16.

Ein BeePi-Atari???
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Chocco am So 05.08.2018, 23:20:45
Was sieht man da?

Lies mal Antwort #16.

Ein BeePi-Atari???

Korrekt formuliert ist es natürlich nur ein Raspberry Pi 3B mit Aranym zur Emulation der Atari Hardware. Als OS verwendet das System EmuTOS zum booten. Anschließend startet MiNT mit diversen Erweiterungen und der Thing Desktop. Eine SD-Karte für den RPi oder eine ISO-Image für macOS, Linux oder Windows kann auf der Homepage des Projekts geladen werden.

Damit das Ganze möglichst gut auf den Schreibtisch passt, habe ich die Raspberry Hardware in ein Pi-Top Ceed https://pi-top.com/products/ceed (https://pi-top.com/products/ceed) Gehäuse gepackt. Da ich kein Freund umfangreicher Verkabelung bin, verwende ich eine Keyboard/Maus Kombination von Rapoo https://www.amazon.de/Rapoo-ultraschlanke-Edelstahl-Tastatur-deutsches/dp/B006Z57CUU/ref=sr_1_2?ie=UTF8&qid=1533503687&sr=8-2&keywords=rapoo+kabellose+tastatur+und+maus (https://www.amazon.de/Rapoo-ultraschlanke-Edelstahl-Tastatur-deutsches/dp/B006Z57CUU/ref=sr_1_2?ie=UTF8&qid=1533503687&sr=8-2&keywords=rapoo+kabellose+tastatur+und+maus)
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: 1ST1 am Mo 06.08.2018, 07:13:18
Naja, das ist dann nicht, das, was Ausgangs in diesem Thread vorgeschlagen wurde, nämlich, dass der RaPi statt Linux eine EmuTOS-Umsetzung direkt booten soll. Was du zeigst, ist einfach ein RaPi mit Linux und Emulator. Im Prinzip nix anderes was hier viele andere auch machen, auch wenn statt Linux z.B. Windows das Basis-OS für Hatari, Aranym, Steem, etc. ist.
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Arthur am Mo 06.08.2018, 07:35:03
Naja, das ist dann nicht, das, was Ausgangs in diesem Thread vorgeschlagen wurde, nämlich, dass der RaPi statt Linux eine EmuTOS-Umsetzung direkt booten soll. Was du zeigst, ist einfach ein RaPi mit Linux und Emulator. Im Prinzip nix anderes was hier viele andere auch machen, auch wenn statt Linux z.B. Windows das Basis-OS für Hatari, Aranym, Steem, etc. ist.

Er schrieb ja:

Meinen ersten Anlauf, einen VDI-Treiber auf Basis der alten DR-Sourcen zu bauen, habe ich erstmal gestoppt und die Implementation über openVG begonnen. Egal was aus pTOS wird, kann dies dann immer noch als Basis für etwas anderes verwenden.

Da gibt es eigentlich nichts zu kritisieren. Ausnahme ist du macht es. :D
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: 1ST1 am Mo 06.08.2018, 09:18:36
Ich kritisiere nicht, ich fasse nur zusammen, was da wirklich passiert, im Gegensatz zum eigentlichen Thread-Thema.
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Arthur am Mo 06.08.2018, 10:25:25
Ah, ok.
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Chocco am Mo 06.08.2018, 18:48:28
Naja, das ist dann nicht, das, was Ausgangs in diesem Thread vorgeschlagen wurde, nämlich, dass der RaPi statt Linux eine EmuTOS-Umsetzung direkt booten soll. Was du zeigst, ist einfach ein RaPi mit Linux und Emulator. Im Prinzip nix anderes was hier viele andere auch machen, auch wenn statt Linux z.B. Windows das Basis-OS für Hatari, Aranym, Steem, etc. ist.

Vielleicht habe ich mich nur mißverständlich ausgedrückt. Ich habe die Frage gestellt, ob es sinnvoll ist, ein >30 Jahre altes Single-Task-OS ((Emu)TOS) auf eine neue CPU-Architektur (ARM) zu portieren. Ein ARM-TOS wäre sicher rasend schnell, aber wenn man nativ damit arbeiten möchte, müssen alte 68k-Anwendungen sowieso neu für die ARM-Architektur kompiliert werden.

Daher habe ich die Frage gestellt, ob es nicht sinnvoller sei, das bestehende Linux als Unterbau zu nehmen - praktisch als gepimptes MiNT.

Darauf aufsetzend müssten dann nur noch die AES und das VDI auf die ARM-Architektur portiert werden. Inwieweit man über einen Wrapper eine Aufrufkompatibilität zur XBIOS, BIOS und GEMDOS beibehalten kann, müsste man sich natürlich noch genauer anschauen.

Neu kompiliert werden muss beim Wechsel der Architektur sowieso und wenn man diesen großen Schritt eh macht, dann doch gleich in eine zeitgemäße Linux-Umgebung, die zudem noch super supported wird.

Für ein privates Projekt hatte ich bereits damit begonnen, aus den original DR-Sourcen von GEM/3 das VDI auf den RPi unter Linux zu portieren. Ich hatte hierfür das Framebuffer Device verwendet. Da der RPi jedoch über eine sehr schicke HW-Beschleunigung verfügt, die sich über das Framebuffer Device nicht realisieren lässt, wird meine VDI-Umsetzung nun entsprechend auf eine HW-beschleunigte Variante geändert. Diese Variante ließe sich vielleicht auch auf einem pTOS verwenden, falls dieses pTOS Zugriff auf die HW-Beschleunigung des RPi bereitstellt.

Ja, auf dem Foto ist nur eine auf ARM basierte Emulation eines 68k TOS-Kompatiblen zu sehen. Ich finde dieses Setting jedoch extrem schick und aufgeräumt.
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: 1ST1 am Mo 06.08.2018, 19:30:56
Das ist mir soweit alles klar, die Idee war entweder Linux komplett durch ArMint (schöner Name, nicht?) zu ersetzen, oder das X-Window-System durch VDI (und einen GEMDOS zu POSIX-Wrapper). Kann man alles machen, gibt aber keine Software dafür, es sei denn  man hat die Quellcodes und lassen sich möglichst einfach dafür kompilieren. Ob das bei dem Softwareangebot für Linux ein Motivationsschub ist, hab ich ja noch nicht mal gefragt. Nur dabei ist bisher rausgekommen, Linux, X-Window-System, Emulator. Das ist was ganz anderes und nichts spektakuläres, wie Ausgangs in Aussicht gestellt wurde.
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Chocco am Mo 06.08.2018, 20:16:32
Nein, soweit ist Dir nicht alles klar und ausgangs wurde auch nichts Spektakuläres in Aussicht gestellt.

Macht aber nichts ;)
Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: Thorsten Otto am Di 07.08.2018, 06:32:57
Das ist mir soweit alles klar, die Idee war entweder Linux komplett durch ArMint (schöner Name, nicht?) zu ersetzen

Offensichtlich ist dir da doch nicht alles klar. Es war die Rede von EmuTOS, nicht MiNT.

Zitat
oder das X-Window-System durch VDI (und einen GEMDOS zu POSIX-Wrapper).

Und wo hast du das her? Da war nie die Rede von.

Zitat
gibt aber keine Software dafür

Was genau gibt es nicht? Sourcen für alles sind vorhanden, teilweise sogar von unterschiedlichen Quellen. Ist halt die Frage was man draus macht.

Titel: Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
Beitrag von: 1ST1 am Di 07.08.2018, 07:24:47
Das ist mir soweit alles klar, die Idee war entweder Linux komplett durch ArMint (schöner Name, nicht?) zu ersetzen

Offensichtlich ist dir da doch nicht alles klar. Es war die Rede von EmuTOS, nicht MiNT.
Überschrift ja, aber schau mal im Text.
Zitat
Zitat
oder das X-Window-System durch VDI (und einen GEMDOS zu POSIX-Wrapper).
Wer glaubt denn, dass rein VDI reicht, damit neukompilierte Atari-Programme unter Linux eine Datei öffnen können, eine Schnittstelle ansprechen kann, usw? Also muss es einen Wrapper geben, der die dazu nötigen Systemaufrufe, die nicht im VDI liegen, übersetzt.
Zitat
Und wo hast du das her? Da war nie die Rede von.

Zitat
gibt aber keine Software dafür

Was genau gibt es nicht? Sourcen für alles sind vorhanden, teilweise sogar von unterschiedlichen Quellen. Ist halt die Frage was man draus macht.
Na dann übersetzt doch mal Calamus, Wordplus, Papyrus, Tempus, Adimens, Signum, Cubase, Notator, ... dafür. Letztendlich wird auf so einem Ding weniger laufen als selbst auf der Firebee.