Autor Thema: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?  (Gelesen 9185 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline Chocco

  • Benutzer
  • Beiträge: 225
  • May the force be with you
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?


   

Atari TT030 mit CrazyDots
Milan 060 (ATI Rage Pro)
Apple MBP

Offline Arthur

  • Benutzer
  • Beiträge: 10.302
  • Mein Atari erinnert mich an die gute alte Zeit..
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #1 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.

Offline Börr

  • Benutzer
  • Beiträge: 858
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #2 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.

Offline mfro

  • Benutzer
  • Beiträge: 1.637
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #3 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 ;)
 
« Letzte Änderung: Mo 02.07.2018, 13:23:00 von mfro »
And remember: Beethoven wrote his first symphony in C

Offline Chocco

  • Benutzer
  • Beiträge: 225
  • May the force be with you
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #4 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

Für das AES fällt mir bestimmt auch noch etwas ein...
Und das alles auch nur, weil es Spass macht :)
 
Atari TT030 mit CrazyDots
Milan 060 (ATI Rage Pro)
Apple MBP

Offline Chocco

  • Benutzer
  • Beiträge: 225
  • May the force be with you
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #5 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

Atari TT030 mit CrazyDots
Milan 060 (ATI Rage Pro)
Apple MBP

Offline Arthur

  • Benutzer
  • Beiträge: 10.302
  • Mein Atari erinnert mich an die gute alte Zeit..
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #6 am: Mi 04.07.2018, 21:40:18 »
Was? In zwei Jahren soll das bereits zufriedenstellend laufen? >:D

Offline mfro

  • Benutzer
  • Beiträge: 1.637
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #7 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.
And remember: Beethoven wrote his first symphony in C

Offline Chocco

  • Benutzer
  • Beiträge: 225
  • May the force be with you
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #8 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 :)
Atari TT030 mit CrazyDots
Milan 060 (ATI Rage Pro)
Apple MBP

Offline Chocco

  • Benutzer
  • Beiträge: 225
  • May the force be with you
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #9 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.
Atari TT030 mit CrazyDots
Milan 060 (ATI Rage Pro)
Apple MBP

Offline gh-baden

  • Benutzer
  • Beiträge: 1.967
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #10 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 :-)
Wider dem Signaturspam!

Offline tuxie

  • Benutzer
  • Beiträge: 6.830
  • Falcon! Milan! Schuetzt die Raubvoegel!
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #11 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... 
Tschau Ingo

Offline Chocco

  • Benutzer
  • Beiträge: 225
  • May the force be with you
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #12 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 ;)
Atari TT030 mit CrazyDots
Milan 060 (ATI Rage Pro)
Apple MBP

Offline MJaap

  • Benutzer
  • Beiträge: 1.558
  • ST-Computer
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #13 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.

Offline 1ST1

  • Benutzer
  • Beiträge: 8.661
  • Gesperrter User
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #14 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.
Ausgeloggter Mitleser, der hier NIE mehr aktiv wird. Am besten, meine Inhalte komplett löschen. Dabei berufe ich mich auf mein Urheberrecht, die DSGVO und auf die Rechte, die mir unter Impressunm&Datenschutz zugestanden werden. Tschö!

Online Thorsten Otto

  • Benutzer
  • Beiträge: 1.248
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #15 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.

Offline Chocco

  • Benutzer
  • Beiträge: 225
  • May the force be with you
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #16 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.

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:

Atari TT030 mit CrazyDots
Milan 060 (ATI Rage Pro)
Apple MBP

Offline Börr

  • Benutzer
  • Beiträge: 858
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #17 am: Do 02.08.2018, 12:35:03 »
Was sieht man da?

Offline Arthur

  • Benutzer
  • Beiträge: 10.302
  • Mein Atari erinnert mich an die gute alte Zeit..
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #18 am: Do 02.08.2018, 12:47:11 »
Was sieht man da?

Lies mal Antwort #16.

Offline Börr

  • Benutzer
  • Beiträge: 858
Re: EMU-TOS native auf einem Raspberry Pi - macht das Sinn?
« Antwort #19 am: Fr 03.08.2018, 09:49:48 »