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

Ja klar, habe mich leider vertippt.

Ich habe grade total fasziniert den Thread nachlegesen (danke für die inspirierende Diskussion!), und lade kurz einmal meinen Senf dazu hier ab:

1. Als man in den 60ern angefangen hat, mit (MultiUser)Timesharing-Systemen zu experimentieren, war das bittere Notwendigkeit, weil man als Alternative bloß das Abgeben von Kartenstapeln bei den Operatoren gehabt hat, und das Abholen der Ausgabe nächsten Tag oder so. Per Timesharing hat man mehreren Leuten gleichzeitig direkten Zugriff auf den Rechner geben können. Das ist der Hauptgrund für Multitasking, nicht, zwei Tetrisse übereinander unkontrolliert verlieren zu lassen.

2. Ebenso ist die Notwendigkeit da gewesen, überhaupt Rechnerleistung online und interaktiv zur Verfügung zu stellen. Hätten die Leute damals schon private Alternativen (gar mit heutigem Komfort) gehabt, hätte kein Mensch so eine System genutzt. Daher muss man von vorn herein davon ausgehen, dass User sowieso lange nicht das bekämen, was sie auf modernen Systemen selbstverständlich nachgeschmissen bekommen. Der C64 wäre von seinen Leistungsdaten in den 60er-Jahren mit den damals üblichen Minicomputern schön mitgeschwommen, und hätte, von der Performance her, auf einer Universität oder in einer kleinen Firma durchaus Verwendung gefunden. Was die damals aber sicher nicht gehabt haben: graphischen Komfort. Eine Teletype-Maschine mit Tastatur und Drucker war damals für das Empfinden der User noch luxuriöser (weil neuer) als heute eine Android-Touch-Screen.

3. Was die graphische Oberfläche betrifft, wäre die aus meiner Sicht einzig sinnvolle Variante die, den Textbildschirm so aufzubereiten (wie es früher TurboPascal-Versionen - allerdings auf PC - standardmässig getan haben). Damit braucht man ein Kilobyte für den Bildschirm, das ist verträglich. Wenn man wirklich HiRes braucht, kann man das ja arrangieren, aber man braucht es nicht als default-Lösung gleich beim Start zuklotzen.

4. Der einzige Grund, sowas auf dem C64 zu versuchen, ist die Lust an der Antiquität und die übersprudelnde Kreativität und Neugier: "Was wäre wenn? Ginge das?". Das ist der Hauptgrund für 99.9% aller Projekte hier. Wirklich brauchen tut diese Systeme de facto niemand mehr. Es ist Lustgewinn, sonst nichts. Daher wäre so ein Experiment sicher extrem interessant (für unsereins), aber ob es dann brauchbar ist und allgemein genutzt wird, darauf sollte man sich eher nicht versteifen. Freilich: Je näher man dem kommt, je mehr Leute es dann tatsächlich vielleicht benutzen, desto schöner ist das fürs Selbstbewusstsein, und das soll ja auch so sein.

5. Es ist nicht nur (bzw. nur marginal) Mangel an Speicher, der so eine Idee unpraktisch erscheinen lässt. Das erste UNIX hat auch nicht mehr als 64k zur Verfügung gehabt, auf der PDP-7 eher weniger (ich weiß nicht, wieviel wirklich, ich glaube es waren 32k, aber ich kann mich irren), die erste ernstzunehmende, auf der PDP-11, hat, glaube ich, 256 K gehabt, wenn es stimmt. Aber 64K wären schon OK. Allerdings ist der 6502 wirklich für Multitasking extrem übel. Nicht-verschiebbarer Stack, Addressierungsformen recht karg, Register noch kärger, und und und. Insofern denke ich, dass jedes Z80A-System da besser geeignet wäre, bei ähnlichem Speicherausbau.

6. Deshalb scheint es mir, dass so ein System auf einem 6502 bzw. 6510 nur dann wirklich Sinn hätte, wenn es auf einer möglichst schnellen virtuellen Maschine läuft, mit sehr kompaktem ZielCode. Eine möglichst kompakte Zielsprache könnte vielleicht FORTH ähnlich sehen (nur vom Code her, das muss ja nicht als Hochsprache verwendet werden), um die Programme möglichst klein zu halten, und mit einer VM könnte man auch die Addressräume voreinander schützen. Dann aber wird alles unweigerlich noch langsamer, als der geliebte Kübel jetzt schon ist. Ein Kompromiss könnte sein, beides zu verwenden: Für zeitkritische Teile des OS (oder eigener Programme) Assembler, für alles andere viel kompakteren virtuellen Code. Damit könnte man wohl mehr an Funktionalität unterbringen, als in Maschinensprache, die auf dem 6510 im Vergleich zum Gesamtspeicher schon sehr gierig ist.

7. Das mit dem Multitasking vs. Multiprogramming sehe ich nicht so kritisch. Was man ja auf jeden Fall braucht, ist die Möglichkeit, mehrere Programme in all ihren Zuständen im Speicher zu halten, und sie von aussen zu unterbrechen (z.B. wenn man eine GUI verwenden will). Man braucht das Memory-Management, man braucht den geordneten Prozess-Wechsel. Damit hat man schon die Dreiviertel-Miete, würde ich sagen. Ob dann noch ein Scheduler regelmässig Zeitscheiben zuweist, oder ob der "nur" auf die Anfragen des Users reagiert, ist von der Technik her dann schon nebensächlich. Da das nur mehr ein kleiner Schritt ist, könnte man das sogar live ein oder ausschalten, und vor allem als User ausschalten, wenn die Performance gar zu sehr sinkt.

Soweit meine Gedanken dazu. Es würde mich interessieren, ob irgendwer da schon weiter gearbeitet hat.

Zitat von Zirias/Excess

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

Mehr Infos zu GeckOS: https://www.lyonlabs.org/commodore/GeckOS/