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
Thema: EMU-TOS native auf einem Raspberry Pi - macht das Sinn? (Gelesen 28451 mal)