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

[Chocco]

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

[1ST1]

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.

[Arthur]

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.

[1ST1]

Ich kritisiere nicht, ich fasse nur zusammen, was da wirklich passiert, im Gegensatz zum eigentlichen Thread-Thema.

[Arthur]

Ah, ok.

[Chocco]

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.

[1ST1]

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.

[Chocco]

Nein, soweit ist Dir nicht alles klar und ausgangs wurde auch nichts Spektakuläres in Aussicht gestellt.

Macht aber nichts

[Thorsten Otto]

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.

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.

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.

[1ST1]

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.

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.

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

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.