OS Entwicklung -- "moderne" Konzepte auf dem C64?

    Hier im Forum habe ich jetzt schon diverse Threads zum Thema eines neuen OS für den C64 gesehen. Etwas erstaunt hat mich, dass dabei oft der Fokus auf dem UI liegt -- das sollte meiner Meinung nach eher ein späterer Schritt sein.


    Wie würde man heute ein OS planen und bauen? Man versucht, so modular wie möglich zu sein, mit einem möglichst kleinen Kernel -- eine Strategie, die beim C64 vermutlich nicht weit führen würde aufgrund der recht begrenzten Leistungsfähigkeit der Hardware. Trotzdem denke ich, dass man bei der Planung eines neuen OS mit dem beginnen sollte, das definitiv auch in den noch so winzigsten Kernel gehört:

    • Prozessverwaltung und Scheduler
    • Speicherverwaltung
    • IPC

    Ich gehe jetzt einfach mal davon aus, dass man heutigen Ansprüchen an ein OS, selbst wenn es auf einer so alten Kiste laufen soll, nicht mehr gerecht würde ohne preemptive multitasking. Das führt direkt auf das erste Problem, das ich mit der Plattform sehe: Wie stellt man mehreren Prozessen Stack zur Verfügung?


    Prinzipiell kann ich mir zwei Herangehensweisen vorstellen:

    • Man segmentiert den Hardwarestack, so dass jeder Prozess einen Teil davon bekommt. Das führt aber zu sehr kleinen Stacks (der gesamte Hardwarestack ist ja nur eine Page groß), und wenn der Stack eines Prozesses überläuft, zerstört er den eines anderen Prozesses.
    • Jeder Prozess bekommt seinen eigenen Stack irgendwo, der über den Hardwarestack kopiert wird, wenn zu diesem Prozess gewechselt wird. Hier wäre der Nachteil, dass das gewaltigen Overhead beim Kontextwechsel mit sich bringt ?(

    Fällt jemandem eine dritte Alternative ein?


    ---


    Außerdem wird man beim C64 von vorneherein eine grobe Speicheraufteilung planen müssen. Um später ein GUI zu ermöglichen ist es sicher ratsam, das RAM von D000 - FFFF für den VIC zu reservieren (Bitmap ab E000, "unter" dem I/O Bereich Farbspeicher und Sprites). Damit wäre es naheliegend, die grundlegendsten Kernel-Funktionen in C000 - D000 zu packen, was auch den Vorteil hat, dass ein Bootloader dort problemlos hinschreiben könnte. Der Kernel braucht sicher Verwaltungsinformationen (Seitentabellen, Prozesskontrollblöcke) -- vielleicht schafft man es, diese, sowie weiteren Treibercode, komplett oberhalb von A000 unterzubringen, dann wäre der Bereich von 1000 bis A000 nutzbar für Services und User-Prozesse (ein GUI könnte man vielleicht als solchen realisieren), aber das ist sicherlich Träumerei, da müsste man mal sehen wie weit man kommt.


    ---


    Ebenfalls muss man sich Gedanken über ein Binärformat für ausführbare Programme machen. Es sollte möglich sein, ein Programm an eine beliebige Stelle im freien Speicher zu laden, dazu braucht es dann aber Relokationstabellen.


    ---


    Meiner Meinung nach ist es absolut unmöglich, ein System zu entwerfen, bei dem nicht jeder beliebige User-Prozess die Maschine "übernehmen" kann ... oder einfach nur bei einem Bug das System zum Absturz bringt. Ich denke damit wird man von vorneherein leben müssen, da gibt die Hardware einfach nicht mehr her.


    So ein Projekt würde sicher Spaß machen, allerdings habe ich noch keine Vorstellung, ob es überhaupt realisierbar ist. Bin gespannt auf Meinungen/Gedanken/Anregungen...

    @zrs1, was waere denn dann eigentlich der Haupt-Nutzen dieses OS? Eigentlich doch im wesentlichen nur das Multitasking, oder? Ansonsten wuesste ich halt nicht, was das OS jetzt genau fuer einen Mehrwert haben soll. Vermutlich fangen deshalb so viele Konzepte mit der GUI an, weil das das einzige ist, wovon man als User noch irgendwie was mitbekommen wuerde, und was einem wirklich noch was bringen "koennte". Aber einfach nur Speicherverwaltung, Multitasking, usw, das sind alles Dinge, die man doch streng genommen beim C64 ueberhaupt nicht braucht. Oder will jemand River Raid spielen und dann ab und zu in einen Text-Editor wechseln, um seine Scores aufzuschreiben?

    Quote from ZeHa

    Ansonsten wuesste ich halt nicht, was das OS jetzt genau fuer einen Mehrwert haben soll.

    Der praktische Nutzen würde sich sicher in Grenzen halten. Aber welchen Nutzen hat ein fancy grafisches UI, bei dem dann doch nur ein Programm läuft? Ich denke es ist ohnehin klar, dass kein neues OS für den C64 sich jemals für Spiele eignen würde. Aber vielleicht ein Terminal (lokal, RS-232, Telnet, ...?), ein Editor, ein Rechner, ... natürlich auch alles "Spielzeug", aber wenn ich mir so manche Entwürfe ansehe, wie ein OS "aussehen" könnte, ergeben die für mich eher Sinn mit echtem Multitasking. Und ich bin eben der Meinung man fängt dann besser mit den Grundlagen an statt mit der Oberfläche.


    Sind ja soweit sowieso nur Hirngespinste, daher auch in dieser Rubrik gepostet ;)

    Quote from zrs1

    Der praktische Nutzen würde sich sicher in Grenzen halten. Aber welchen Nutzen hat ein fancy grafisches UI, bei dem dann doch nur ein Programm läuft? Ich denke es ist ohnehin klar, dass kein neues OS für den C64 sich jemals für Spiele eignen würde. Aber vielleicht ein Terminal (lokal, RS-232, Telnet, ...?), ein Editor, ein Rechner, ... natürlich auch alles "Spielzeug", aber wenn ich mir so manche Entwürfe ansehe, wie ein OS "aussehen" könnte, ergeben die für mich eher Sinn mit echtem Multitasking. Und ich bin eben der Meinung man fängt dann besser mit den Grundlagen an statt mit der Oberfläche.
    Sind ja soweit sowieso nur Hirngespinste, daher auch in dieser Rubrik gepostet ;)

    Hmm ja verstehe. Ich denke halt, solange es wirklich nur "Spielzeug" bzw. "Spielerei" ist, wird sowas vermutlich auch nie wirklich umgesetzt werden, weil der Aufwand einfach zu hoch ist. Ich glaube, es wird eher von der anderen Seite her entwickelt: Jemand hat einen bestimmten Anwendungsfall und baut dafuer ein Tool (z.B. ein Telnet-Tool), und wenn sich vielleicht mal mehrere solche Tools zusammenfinden, koennte man da vielleicht eine Art "OS" drumrumschrauben oder eine Art "Suite" draus machen. Aber einfach nur ein nacktes OS zu bauen, wofuer dann erst noch Software entstehen muss, ist vermutlich etwas, was nie wirklich passieren wird. Soweit meine Meinung zu dem Thema. Aber vermutlich soll dieser Thread natuerlich nicht dazu dienen, die Idee zu zerreden, daher bin ich nun besser still :schande:

    Quote from ogd

    Hast du dir schon mal diese Ansätze angeschaut? Was davon käme deinen Vorstellungen am nächsten?

    Auf den ersten Blick sind GeckOS und LUnix was das ganz grundlegende angeht ziemlich genau das, was ich mir vorstelle -- da muss ich mal tiefer reinlesen (in den Code), um zu sehen, wie da z.B. mit dem Thema Stack umgegangen wird. Definitiv interessanter Link!

    Quote from ogd

    Dafur existiert mit o65 auch schon ein weitgenutzter Defacto-Standard.

    Auch das ist eine interessante Info, da sollte man dann natürlich nicht das Rad neu erfinden! Ich werde auf jeden Fall bei Gelegenheit mal in den Source der existierenden Projekte schauen -- eventuell wäre das schon ein geeigneter Unterbau um ein GUI "draufzusetzen".

    Quote from zrs1

    Wie stellt man mehreren Prozessen Stack zur Verfügung?


    Prinzipiell kann ich mir zwei Herangehensweisen vorstellen:

    • Man segmentiert den Hardwarestack ...
    • Jeder Prozess bekommt seinen eigenen Stack irgendwo, der über den Hardwarestack kopiert wird ...

    Fällt jemandem eine dritte Alternative ein?


    Wäre denn der C 128 auch eine Option? Mit dessen MMU lässt sich ja der Stack (und die Zeropage) auf eine andere Speicherseite umkonfigurieren. Die Funktionsweise ist recht ausfühtlich im Commodore 128 Programmer's Reference Guide beschrieben (ab Seite 458 ff.).


    BTW:

    Quote from zrs1

    Meiner Meinung nach ist es absolut unmöglich, ein System zu entwerfen, bei dem nicht jeder beliebige User-Prozess die Maschine "übernehmen" kann ... oder einfach nur bei einem Bug das System zum Absturz bringt. Ich denke damit wird man von vorneherein leben müssen, da gibt die Hardware einfach nicht mehr her.


    Ja, wegen diesem fehlenden Speicherschutz ist für Linus Torvalds das AmigaOS auch kein richtiges Multitasking-Betriebssystem :)

    Quote from ogd

    Wäre denn der C 128 auch eine Option?

    Also für mich eher weniger ... vor allem weil ich keinen habe :D und natürlich auch weil insgesamt die Verbreitung sehr viel geringer ist. Klar, das klingt sehr interessant -- eine MMU ist das, was man beim Entwickeln eines OS eigentlich wirklich haben will. Nunja, der C64 hat eben keine, kann man dann auch als Herausforderung sehen, die Design und Entwicklung "interessanter" macht ;)


    Quote from ogd

    Ja, wegen diesem fehlenden Speicherschutz ist für Linus Torvalds das AmigaOS auch kein richtiges Multitasking-Betriebssystem :)

    Kann man so sehen, muss man aber nicht, wie bei vielen Aussagen dieses Herrn ;) Wobei er in seiner äußerst undiplomatischen Art schon auch einige Wahrheiten verkündet hat ... denke da an Subversion ;)

    Quote from ogd

    Wäre es nicht sinnvoller, diesen Faden in die Programmierecke zu verschieben, um auch andere technisch Interessierte anzusprechen? Da tummeln sich ja Themen mit viel weniger Gehalt und viel heisser Luft.

    Für mich ist das hier ebenfalls "heiße Luft" solange nicht wenigstens mal ein Komponentendiagramm und ein klein wenig µkernel-Code existiert (und ob ich das mal anpacke überlege ich noch *g*). Allerdings könnte es tatsächlich sein, dass in der Programmierecke mehr Gedanken und Anregungen zusammenkämen --- hmmm ;)

    Quote from echo

    Vielleicht sollte man nicht ein neues OS planen, sondern eher das http://www.symbos.de/ portieren.
    Ich persönlich finde das Symbos sehr interessant und es erfüllt alle oben genannten Anforderungen.


    Soweit ich weiss, ist Symbos sehr speicherhungrig und setzt schnelles Bankswitching voraus. Zudem ist es GUI-orientiert und in reinem Z 80 Assembler geschrieben. Also ohne grosse Änderungen wird eine Umsetzung auf einen Standard C 64 nicht möglich sein. Auch eine C 128-Portierung sieht Jörn eher skeptisch.

    Quote from zrs1

    Ich gehe jetzt einfach mal davon aus, dass man heutigen Ansprüchen an ein OS, selbst wenn es auf einer so alten Kiste laufen soll, nicht mehr gerecht würde ohne preemptive multitasking

    Bevor man das als gesetzt ansieht, sollte man doch hinterfragen, für was das genutzt werden soll. Ich hoffe doch nicht, für User-Tasks, oder doch? Ich glaube nicht, dass man auf einer so eingeschränkten Plattform, wie einem C64 mit 64KB RAM und 1 MHz Ressourcen verschwenden sollte für Techniken, die ein gleichzeitiges Ausführen (oder im Speicher halten) von mehreren Programmen ermöglichen. Natürlich müssen gewisse Dinge im Hintergrund quasi parallel abgearbeitet werden – (bei einem GUI z.B. der Mauszeiger oder vielleicht noch Desk Accessories) aber wirkliche Programme würde ich vom Multitasking ausschließen. Und ob man für Systemfunktionen wirklich präemptives Multitasking benötigt und sich nicht lieber mit einer Art kooperativem MT mit einem einfachen Scheduler begnügt, könnte man doch auch diskutieren, oder? Wenn ich mir überlege, dass selbst komplexere Betriebssysteme, wie Windows oder Mac OS erst ab der 2. Hälfte der 90er Jahre auf präemptives Multitasking umgestellt wurden, scheint es mir doch etwas zu hoch gegriffen, das als Mindestvoraussetzung zu definieren.


    Ich habe von Systemprogrammierung keine Ahnung, wollte das aber in die Diskussion einwerfen, um aus User-Sicht (die habe ich als GUI-Experte ja immer im Blick) zu berichten, dass ein Multitasking, wie man es heute von Desktop- und Server-Systemen kennt, für einen C64 nicht nötig ist. Wie man an manchen Smartphone-Systemen sehen kann, kommt man mit (aus User-Sicht) sehr sehr eingeschränktem Multitasking gut klar, wenn die Hardware einfach nicht mehr hergibt.


    Aber vielleicht reden wir auch aneinander vorbei, weil das parallele Ausführen von Userprogrammen gar nicht das Ziel der Überlegung war.


    Und jetzt ein Mockup:


    (keine Angst, nur ein Scherz)

    Hallo Retrofan, das ist ein interessanter Einwurf.


    Nein, wir reden nicht aneinander vorbei. Ich bin natürlich geprägt sowohl von meinem Erleben als auch von meinem Studium (in dem ich auch Betriebssysteme "vertieft" habe). Mir scheint es eine interessante Herausforderung zu sein, dem C64 in einem benutzbaren OS ein brauchbares preemptives Multitasking "beizubiegen". Aber vielleicht ist das unerreichbar. Und vielleicht ist das, wie du schön darlegst, aus User-Sicht gar nicht gewünscht, weil man zu viele Abstriche machen müsste. Ich lasse mir das mal durch den Kopf gehen!

    Ich habe mich ja auf dem "Mittwintermeeting" mit dem Entwickler von SymbOS (fuer den CPC) unterhalten, wie ich auch schon im entsprechenden Thread geschrieben habe. Das OS ist wirklich beeindruckend, orientiert sich relativ stark an Win95 von der GUI her, und kann Multitasking usw, also rein technisch gesehen ist das wirklich toll. Es gab z.B. dann auch ein Pacman, das er geschrieben hat, welches dann in einem Fenster laeuft, und das Spiel konnte er sogar zweimal starten und die Fenster halb uebereinander legen, und in beiden Fenstern laufen die Animationen einigermassen fluessig weiter usw., also schon irgendwie cool das alles. Aber ich habe ihm dann auch die Frage gestellt, wie es mit der Nutzung aussieht, und ich hoffe ich gebe es jetzt nicht falsch wieder, aber er meinte schon auch, dass das mehr so ne Experimentier-Plattform ist, die halt auf Treffen usw. gezeigt wird, und einige schreiben auch mal ein kleines Tool dafuer usw, aber so richtig produktiv setzt es dort leider auch keiner ein (und wenn dann vielleicht nur vereinzelt).


    Da wir hier in dem Thread ja auch die Grundsatzfrage hatten, ob das ueberhaupt einen Sinn hat usw, dachte ich, es waere sinnvoll, das hier mal zu erwaehnen. Natuerlich ist der Ansatz ein anderer als das was Retrofan auf seinen Mockups zeigt (Win95 vs. eher Smartphone-inspirierte GUI), von daher kann man daraus jetzt nicht unbedingt ableiten, dass es mit einem Retrofan-OS genau gleich ablaufen wuerde. Trotzdem denke ich, ist es nicht verkehrt, euch diese Information mitzuteilen. Vielleicht kann man in die Richtung SymbOS auch mal etwas weiter nachforschen, denn es ist nunmal ein existierendes Beispiel fuer das, was diesem Vorhaben hier noch am naechsten kommt.