Neues C64 OS: "C64 OS"

Quote from Snoopy

Ich würde mich bei einem OS für den C64 über die konsequente Einbindung einer Internetverbindung freuen.

Gerade gelesen, das scheint schon mal vielversprechend beim C64 OS:

User's Guide | Programmer's Guide | C64 OS

Quote

C64 software has not traditionally been written with ready access to always–on networking. C64 OS changes that expectation. Modem detection, configuration, memory management and numerous other features are provided for by the operating system, making it easy for an applications to use networked services, with very little development effort.

Quote from Retrofan

Ich bin gespannt, wie das Projekt weitergeht und ob das OS später auch von anderen Entwicklern als Basis verwendet wird.

Mich als Entwickler einer Software, die nun schon einige Jahre auf dem Buckel hat, aber immer noch seine Reize und Nützlichkeiten aufweist, würde in diesem Zusammenhang interessieren, ob Greg eine Möglichkeit eingebaut hat, sozusagen "seamless" auf eine solche Applikation wie GoDot, die das ganze Gerät beschlagnahmt, umschalten zu können (und wieder zurück). Das wäre ebenso für andere Anwendungssoftware wichtig. Mit den Ergebnissen müsste man dann sofort im C64OS weiterarbeiten können, vorzugsweise internetbezogen. Für Spiele gilt das eher nicht, denn dazu bräuchte es das C64OS erst gar nicht.

Arndt

Quote from Retrofan

Wenn Greg jetzt also z.B. einfache Nutzung von Speichererweiterungen [..] einbaut

Und das ist schon das erste Problem.

1.) Auch wenn sie immer so genannt werden, sind die Speichererweiterungen für den C64 keine "echten" Speichererweiterungen. Das würde nämlich voraussetzen, daß der Prozessor direkt auf den Speicherinhalt zugreifen kann (z. B. über Bankswitching). Tatsächilch handelt es sich sowohl bei der REU als auch bei der GeoRam und verwandter Hardware um externe Ram-basierte Datenträger ohne Dateisystem, bei denen eine Nutzung von vornherein niemals einfach sein kann.

2.) Was die REU anbelangt, so hat sie den Nachteil, daß bei der Datenübertragung mittels DMA IRQs gestört werden. Das kann z. B. dazu führen, daß in Abhängigkeit von Zeitpunkt der Übertragung und Datenmenge ein Splitscreen plötzlich an zu flackern fängt.

3.) Um externen Datenspeicher in einem OS zu nutzen, müssen folgende Bedingungen erfüllt sein:

a) Das Programm teilt dem OS zu Beginn mit, wieviel Speicher es auf dem Datenträger belegen möchte.

b) Das OS reserviert diesen Speicher und merkt sich intern die Anfangsadresse für diesen reservierten Speicherbereich.

c) Das Programm ruft im Folgenden zwei Routinen auf: i) Laden eines Speicherbereichs, ii) Speichern eines Speicherbereichs. Die Aufhebung der Reservierung sollte vom OS automatisch nach Beendigung des Programms vorgenommen werden.

d) Bei einem Aufruf z. B. der Laderoutine werden folgende Parameter übergeben: i) Zieladresse im Speicher (16 Bit), ii) Größe der Daten (16 Bit), iii) relativer Offset auf die Daten im externen Datenträger (mindestens 24 Bit). Da der 6502 nur 3 8 Bit-Register hat, lassen sich diese Werte nicht über die Register übergeben, sondern sie müßten z. B. zuerst in die Zeropage geschrieben werden.

Kurz gesagt: Einfach sieht anders aus.

Ich habe mir mal das Video angesehen. Dabei fielen mit folgende Dinge auf:

1.) Nur 20 kb (= $5000) für Programme frei.

Das ist sehr wenig. Ehrlich. Für eine rein textorientierte GUI ist das echt wenig. Bei einem normalen Speicheraufbau entspräche das dem Bereich von $800 bis $57ff. Bei längeren Programmen wäre man darauf angewiesen, diese in einzelne Module aufzuspalten, was eine Programmentwicklung erschwert. Außerdem führt es dazu, daß Module oder Daten häufig nachgeladen werden müssen.

2.) Das OS läuft nicht von einer üblichen C64-Originalhardware.

Wie er selber sagt, ist Grundvoraussetzung ein Datenträger, der über Unterverzeichnisse verfügt. Und natürlich auch groß genug ist für die ganzen OS-Dateien. Und der natürlich schnell genug ist, um die ganzen Dateien in vertretbarer Zeit nachzuladen. Es ist also nur sehr eingeschränkt ein OS für den C64, mehr ein OS für den C64+modernem Datenträger. Das erklärt dann auch, warum sowas nicht schon früher in den 80ern geschrieben wurde: Diese Datenträger gab es damals schlicht nicht.

3.) Er zeigt uns nicht, wie Bilder geladen werden beim eingeschalteten Splitscreen. Was man aber sieht, ist, wie das Mauszeiger-Sprite beim Laden kurz flackert. Anders als GEOS verfügt sein System wohl nicht über besondere Laderoutinen (wie z. B. einem Schnellader), der verhindern könnte, daß der IRQ abgeschaltet wird oder das Maussprite die Übertragung stört. Das wäre auch nicht zu erwarten, denn sein System fokussiert auf moderne Hardware (SD2IEC) und nicht auf Original-Hardware (1541). Für das SD2IEC gibt es aber keine Schnellader etc.

4.) Bei der ganzen Demo habe ich mich verzweifelt gefragt: Wofür? Er hat da also jetzt eine Text-GUI entworfen, die sehr viel Platz im Speicher kostet. Und er hat Programme geschrieben, mit der man diese GUI konfigurieren kann. Fein. Nur wird bisher nicht die Frage beantwortet, wofür diese GUI überhaupt gut sein soll. Welche Programme schweben ihm oder andere eigentlich vor? Bei dem Taschenrechner konnte man m. E. schon sehen, daß das GUI-Konzept nur bedingt tauglich ist. Für meinen Geschmack sah das Design mit den unterschiedlichen Farben nicht gerade ansprechend aus. Im Hires-Modus hätte man das sicherlich besser hinbekommen. Auch die Beschränkung der Zeichen auf reine ASCII-Zeichen ohne Umlaute usw. halte ich einfach für nicht mehr zeitgemäß. Ich frage mich daher, welche Programmierer a) überhaupt eine konkrete Vorstellung davon haben, was sie unter dieser GUI programmieren können, b) ob das starre Zeichenkonzept am Ende nicht einen zu engen Rahmen darstellt. Für mich persönlich sind diese Beschränkungen schon zu viel.

Quote from GoDot

ob Greg eine Möglichkeit eingebaut hat, sozusagen "seamless" auf eine solche Applikation wie GoDot, die das ganze Gerät beschlagnahmt, umschalten zu können (und wieder zurück)

Naja, der übliche Weg bei Launchern etc. ist ja, sich aus dem Speicher zu verabschieden und nachdem der C64 resettet wurde (andere Möglichkeiten des Beendens kennen die meisten C64-Programme ja nicht), wieder neu zu laden, vorzugsweise aus einem schnellen ROM- oder RAM-Speicher.

Vielleicht wäre ja eine Parameter-Übergabe denkbar, sodass man in einem bestimmten Speicherbereich Infos ablegt, den die (angepasste) Zielapplikation auslesen kann. Als Beispiel würde mir z.B. der Pfad eines Bildes einfallen (nachdem man z.B. ein Bild auf die App gezogen hat), das von der gestarteten App sofort geöffnet wird.

Quote from GoDot

Mit den Ergebnissen müsste man dann sofort im C64OS weiterarbeiten können, vorzugsweise internetbezogen.

Da könntest vielleicht noch etwas mehr erklären, was denn die Ergebnisse sein könnten und was mit denen passieren soll.

Quote from M. J.

Tatsächilch handelt es sich sowohl bei der REU als auch bei der GeoRam und verwandter Hardware um externe Ram-basierte Datenträger ohne Dateisystem, bei denen eine Nutzung von vornherein niemals einfach sein kann.

Ich meinte, dass das Betriebssystem den komplizierten Kram einmal übernehmen muss, damit darauf aufbauende Programme sich darum möglichst wenig kümmern müssen. Dass es für das OS nicht trivial sein wird, zumal es nicht nur eine Speicher-Lösung gibt, ist natürlich klar.

Quote from M. J.

1.) Nur 20 kb (= $5000) für Programme frei.

Das ist in der tat eher wenig, sogar weniger als bei GEOS. Ich hatte ja beim eigenen Ansatz gehofft, deutlich mehr freien Speicher zu haben. Allerdings auch mit Unterstützung irgendeiner Art von (vielleicht sogar mitgeliefertem) Zusatz-Speicher (ROM oder RAM)

Quote from M. J.

2.) Das OS läuft nicht von einer üblichen C64-Originalhardware.

Wie er selber sagt, ist Grundvoraussetzung ein Datenträger, der über Unterverzeichnisse verfügt. Und natürlich auch groß genug ist für die ganzen OS-Dateien.

Das stimmt. Ich denke, jeder neue Ansatz wird zwangsläufig auf irgend eine Art von moderner Zusatz-Hardware setzen – sonst hätte es die entsprechende Lösung wahrscheinlich auch schon damals™ gegeben. Ich finde das grundsätzlich nicht verwerflich, nur sollte man darauf achten, dass die Hardware nicht zu exotisch oder teuer ist, wenn man da einen gewissen Standard setzen will. Wer heutzutage den C64 für irgendwelche Anwendungen "nutzen" will, der wird wahrscheinlich keinen Vanilla-C64 mit 1541 haben (hoffe ich).

Quote from M. J.

3.) ... Anders als GEOS verfügt sein System wohl nicht über besondere Laderoutinen (wie z. B. einem Schnellader), der verhindern könnte, daß der IRQ abgeschaltet wird oder das Maussprite die Übertragung stört. Das wäre auch nicht zu erwarten, denn sein System fokussiert auf moderne Hardware (SD2IEC) und nicht auf Original-Hardware (1541). Für das SD2IEC gibt es aber keine Schnellader etc.

Er hat gesagt, dass er für Disk-Zugriffe Kernal-Routinen verwendet, selbst das BASIC-ROM nutzt er für bestimmte Sachen (Taschenrechner). Er empfiehlt daher Jiffy-DOS, um die Laderoutinen zu beschleunigen – das funktioniert übrigens auch sehr gut mit dem SD2IEC. Besser wäre es natürlich, selbst die Routinen zu patchen, um dem User schonmal eine Hürde (Jiffy-DOS-Erwerb) abzunehmen.

Quote from M. J.

4.) Bei der ganzen Demo habe ich mich verzweifelt gefragt: Wofür? Er hat da also jetzt eine Text-GUI entworfen, die sehr viel Platz im Speicher kostet. Und er hat Programme geschrieben, mit der man diese GUI konfigurieren kann. Fein. Nur wird bisher nicht die Frage beantwortet, wofür diese GUI überhaupt gut sein soll. Welche Programme schweben ihm oder andere eigentlich vor?

Ja, die Frage bleibt erstmal unbeantwortet. Und ich bin auch der Meinung, dass das OS zu diesem Zeitpunkt noch nicht sehr viel Sinn macht. Wenn er einen einfach zu nutzenden Internet-Zugang bieten kann, dann könnte das aber evtl. anders aussehen. Bis jetzt ist es eine hübsche (wenn auch aufwendige) Tech-Demo, wie viele andere OS- und GUI-Ansätze der Vergangenheit auch.

Quote from M. J.

Bei dem Taschenrechner konnte man m. E. schon sehen, daß das GUI-Konzept nur bedingt tauglich ist. Für meinen Geschmack sah das Design mit den unterschiedlichen Farben nicht gerade ansprechend aus. Im Hires-Modus hätte man das sicherlich besser hinbekommen. Auch die Beschränkung der Zeichen auf reine ASCII-Zeichen ohne Umlaute usw. halte ich einfach für nicht mehr zeitgemäß. Ich frage mich daher, welche Programmierer a) überhaupt eine konkrete Vorstellung davon haben, was sie unter dieser GUI programmieren können, b) ob das starre Zeichenkonzept am Ende nicht einen zu engen Rahmen darstellt. Für mich persönlich sind diese Beschränkungen schon zu viel.

Ich bin ja auch nach wie vor davon überzeugt, dass eine moderne Bitmap-Lösung (plus natürlich weitere Features, wie Online-Zugriff, ISO-Encoding und anderes) deutlich mehr Potential für zukünftige Anwendungen hätte. Aber so eine Lösung ist halt leider nicht in Sicht und so ist Gregs C64-OS der umfangreichste Ansatz, der sich zumindest in Entwicklung befindet. Der Spatz in der Hand, sozusagen ...

Erstmal baut sein OS auf JiffyDos aus. Das er somit für das SD2IEC keine Schnelladeroutine zur Verfügung hat, stimmt so schon mal nicht.

Denn wozu I/O-Routinen neu schreiben, wenn man alles bereits im OS hat.

Zweitens kennt man die RAM Config nicht. Wenn er die Original belassen hat und sein OS irgendwo zwischen $0800 und $a00 rum liegt,

würde das auch die 20 Kb Programmspeicher erklären, Viel größer als 18 Kb kann sein OS nämlich auch nicht sein.

Ich brauche für Maus,- und REU-Treiber, diversen Bildschirm- und I/O- Routinen grade mal etwa 4K. Die liegten bei mir zwischen $c000

und $d000.

Der Rest würde dann für Multitasking und die eigentliche GUI drauf gehen.

Quote from Retrofan

etwas mehr erklären, was denn die Ergebnisse sein könnten und was mit denen passieren soll.

GoDot macht Bilder. Die müssten dann via Internet verschickbar/ladbar sein, denn das kann GoDot nicht. Ich bräuchte für GoDot das C64OS als Internetzugang zum Austausch von Bildern (per FTP? Email?) Schön hin- und herkopieren auf der heimischen Anlage geht ja schon. Weiteren Nutzen kann ich im Moment nicht für mich erkennen.

Arndt

Quote from GoDot

Weiteren Nutzen kann ich im Moment nicht für mich erkennen.

Du hast ja auch schon ein eigenes UI und eigene Mausroutinen, REU-Unterstützung etc. Das wäre ja etwas, dass einem so ein OS abnehmen würde. Für dich könnte Gregs C64-OS wirklich nicht viel tun. Klar, es könnte auf dem Massenspeicher liegende Bilder (aus Godot oder jedem anderen Programm) vielleicht übers Internet zugänglich machen – aber dafür bräuchte es noch nicht einmal eine "Verbindung" zwischen dem OS und dem anderen Programm.

Ich kam nun auch mal dazu mir das Video auf Youtube komplett anzuschauen. Schön, dass man endlich mal bewegte Bilder sieht. Schon faszinierend wie gut das ganze jetzt schon läuft.

Was ich bisher auch gar nicht wusste, dass er ja anscheinend alles komplett auf dem C64 direkt programmiert, was ja heutzutage auch eher seltener der Fall ist.

Auf jeden Fall Hut ab !

Quote from Retrofan

Klar, es könnte auf dem Massenspeicher liegende Bilder (aus Godot oder jedem anderen Programm) vielleicht übers Internet zugänglich machen

Das gilt für alle gängigen Anwendungen. Da müsste Greg eine Schnittstelle zum Umschalten vorsehen, sonst wird sich keiner dafür interessieren, außer mit solchen Bekundungen:

Quote from Brotbox64

Auf jeden Fall Hut ab !

Was ich natürlich ebenso sehe.

Arndt

Quote from Retrofan

Ich meinte, dass das Betriebssystem den komplizierten Kram einmal übernehmen muss, damit darauf aufbauende Programme sich darum möglichst wenig kümmern müssen. Dass es für das OS nicht trivial sein wird, zumal es nicht nur eine Speicher-Lösung gibt, ist natürlich klar.

Völlig richtig. So hatte ich Dich auch verstanden. Ich wollte nur aufzeigen, daß auch die Verwendung des externen Ram-Speichergeräts nicht so leicht ist, wie man es sich vielleicht vorstellt. Im Gegensatz zu einer "echten" Speichererweiterung mit Bank-Switching kann man nicht eben mal ein paar Bytes holen und verarbeiten. Es ist weiterhin zwingend notwendig, Programme und Daten in kleine Häppchen aufzuteilen, die dann an bestimmten Stellen im Programm nachgeladen werden können, geradeso als ob man von Diskette laden würde, auch wenn der Vorgang schneller geht. Er ist aber immer noch so langsam, daß der Einsatz in zeitkritischer Software nicht zu empfehlen ist, zumal das Programm nicht von einer bestimmten minimalen Übertragungsrate ausgehen kann. Diese kann vielmehr extrem schwanken (z. B. zwischen REU und GeoRam). Anders gesaget: Die Annahme mit einem externen Datenträger wären die Speicherprobleme beim C64 gelöst, geht leider fehl. Gelöst ist damit noch gar nichts, man kann eher davon ausgehen, daß ein Programm, welches den externen Datenträger einsetzt, dies so tun wird wie z. B. die alten Infocom-Spiele: Man verwendet den Speicher als Diskettenersatz mit blockweisem Zugriff, indem die Daten vom eigentlichen Datenträger (1541, 1581 etc) auf den Datenträger kopiert und anschließend die Laderoutinen umgebogen werden.

Quote from Retrofan

Ich hatte ja beim eigenen Ansatz gehofft, deutlich mehr freien Speicher zu haben. Allerdings auch mit Unterstützung irgendeiner Art von (vielleicht sogar mitgeliefertem) Zusatz-Speicher (ROM oder RAM)

Das hatte ich auch gehofft. Hierfür müßte aber das OS komplett modular aufgebaut sein, so daß einzelne Routinen auf dem Ram-Datenträger zum schnellen Nachladen ausgelagert werden können. Bisher scheint es mir aber, als würden die Einzelteile, die es gibt, vom SD2IEC geladen werden. Entweder ist ein Treiber für Ram-Datenträger bisher noch nicht vorhanden, oder aber das System ist zu monolitisch (s. u.), daß man es nicht in Einzelteile aufspalten kann. Aber was nicht ist, kann ja noch kommen.

Quote from Retrofan

Ich finde das grundsätzlich nicht verwerflich, nur sollte man darauf achten, dass die Hardware nicht zu exotisch oder teuer ist, wenn man da einen gewissen Standard setzen will. Wer heutzutage den C64 für irgendwelche Anwendungen "nutzen" will, der wird wahrscheinlich keinen Vanilla-C64 mit 1541 haben (hoffe ich).

Denke ich auch, doch lauten die Hardware-Voraussetzungen jetzt schon: 1.) SD2IEC, 2.) Jiffy-Dos. Wenn dann noch ein Ram-Speicher hinzukommen sollte, müßte man eigentlich überlegen, ob solch ein "Standard" in der Hardware-Konfiguration wirklich sinnvoll ist. Da gäbe es - zumindest theoretisch - weitaus bessere Lösungen.

(Nebenbei: Ich habe tatsächlich einen C128 mit 1571 ohne Jiffy-Dos, ohne SD2IEC, ohne externen Speicher...)

Quote from Retrofan

Er hat gesagt, dass er für Disk-Zugriffe Kernal-Routinen verwendet, selbst das BASIC-ROM nutzt er für bestimmte Sachen (Taschenrechner).

Was mein Herz mit Grauen erfüllt. Kernal-Load hat viele Schwachpunkte (kein stabiler IRQ, keine Sprites, langsam auf Rechnern ohne Jiffy) und das Einblenden des Basic-Roms sowieso. Ich vermute mal, daß letzteres bei ihm möglich ist, da im Bereich $a000..$bfff ohnehin nur seine Routinen liegen und der Interrupt über das Kernal-Rom und den Vektor bei $314 abgewickelt wird. Das schränkt jedoch den Spielraum für irgendwelche Programme ein.

Quote from Retrofan

Ich bin ja auch nach wie vor davon überzeugt, dass eine moderne Bitmap-Lösung (plus natürlich weitere Features, wie Online-Zugriff, ISO-Encoding und anderes) deutlich mehr Potential für zukünftige Anwendungen hätte.

Sehe ich auch so. Und wenn schon moderne Hardware als Grundlage genommen wird, sollte man es richtig machen und dem C64 eine neue Hardware in Form eines Steckmoduls geben, die dann a) weder Jiffy noch SD2IEC voraussetzt, b) massiv Speicher anbietet, c) auch für Programme verwendet werden kann (Patch vorausgesetzt), die ursprünglich nicht dafür geschrieben wurden, weil d) es bei Verwendung nicht zu Problemen mit IRQs und Sprites kommen kann. Sowas hatten wir ja bereits skizziert, aber man kann getrost davon ausgehen, daß diese Hardware nicht realisiert wird.

Quote from Snoopy

Ich fände eine "Komplettlösung" ganz schön. Also sowohl das OS selbst als auch die notwendigen Erweiterungen (Speicher, WiFi, SD-Karten-Laufwerk, usw.) alles auf einem Modul, das ich dann nur noch in den C64 stecken muss. Und alles ohne weitere Konfigurationsorgien. Einfach einstecken und loslegen. DAS wäre für mich eine wirklich reizvolle Sache und dafür würde ich gerne - auch etwas mehr - Geld ausgeben.

Sowas ähnliches haben Retrofan und ich bereits definiert, jedoch nicht als Laufwerk wie das SD2IEC, sondern als reiner nicht flüchtiger Datenspeicher auf einem Steckmodul und ohne 1541-kompatibles Dateisystem. Diese Hardware würde ein schnelleres Laden von Dateien/Spielen ermöglichen als das SD2IEC bei gleich großer Datenmenge (ebenfalls basierend auf einer SD-Karte), denn das SD2IEC benötigt eine Anbindung über den langsamen seriellen Bus, wohingegen beim Steckmodul ein Fenster von 256 Bytes ($de00..$deff) wie bei der GeoRam vorgesehen ist. Stattet man solch ein Modul noch mit einer Autostartmöglichkeit aus (Rom wird bei $8000 eingeblendet), lassen sich OS, Programm-Launcher, Filemanager... in nullkommanichts laden.

Quote from MC64

Erstmal baut sein OS auf JiffyDos aus. Das er somit für das SD2IEC keine Schnelladeroutine zur Verfügung hat, stimmt so schon mal nicht.

Das ist so nicht richtig. Die Aussage war, daß sein OS selbst keinen Schnellader beinhaltet. Wenn sein OS die Laderoutinen von Jiffy voraussetzt, halte ich das persönlich eher für einen Nachteil, denn nicht alle Rechner haben Jiffy.

Quote from MC64

Zweitens kennt man die RAM Config nicht. Wenn er die Original belassen hat und sein OS irgendwo zwischen $0800 und $a00 rum liegt,

würde das auch die 20 Kb Programmspeicher erklären, Viel größer als 18 Kb kann sein OS nämlich auch nicht sein.

Du kannst Dir die Ram-Konfiguration gerne selber in dem verlinkten Video ansehen bei 13:30. Die braunen Felder zeigen klar an, daß sein OS von $8000 bis $dfff reicht. Der Bereich von $e000..$ffff gilt als reserviert. Auch im Bereich zwischen $4000 und $5fff gibt es mehrere Bereiche, die als vom OS belegt angezeigt werden.

Quote from MC64

Ich brauche für Maus,- und REU-Treiber, diversen Bildschirm- und I/O- Routinen grade mal etwa 4K. Die liegten bei mir zwischen $c000

und $d000.

Das ist aber noch kein OS. Das ist nur eine Sammlung von irgendwelchen Treiberroutinen. Sowie ich das verstanden habe, kommen bei ihm noch Routinen hinzu für Speicherverwaltung und Multitasking. Dazu entsprechend Routinen, um Apps zu starten und zu beenden, dazu die Handhabung eines relokatiblen Dateiformats. Allein die Strings, die angeben, wo auf dem SD2IEC die OS-Daten zu finden sind, belegen schon jede Menge Speicher, sowie die Routinen (wahrscheinlich) zum Verbinden von Strings und dem Wechsel in Unterverzeichnisse usw. Kurz gesagt: Da kommt ein großer Haufen Kilobyte hinzu auch noch ganz ohne GUI.

Quote from MC64

Der Rest würde dann für Multitasking und die eigentliche GUI drauf gehen.

Problem bei seinem System ist aber, daß die GUI-Routinen ständig präsent sein müssen, weil sie von den Apps im laufenden Betrieb verwendet werden (Laufzeitbibliothek). Man kann sie also nicht einfach vom OS trennen. Außerdem gilt für den internen Aufbau des OS, daß er sie entweder getrennt programmiert hat z. B. mit Hilfe von Sprungtabellen. Dann wird wahrscheinlich Speicher am Ende des Blocks verschwendet. Oder der Code ist ein monolithischer Block, so daß man aus diesem Grunde keine Trennung vornehmen kann.

So oder so, dieser Code frißt jetzt schon so viel Speicherplatz, daß bei der Speicherbelegung nur noch unter $8000 ein wenig Speicher frei bleibt für das eigentliche Programm.

Quote from M. J.

Das ist so nicht richtig. Die Aussage war, daß sein OS selbst keinen Schnellader beinhaltet. Wenn sein OS die Laderoutinen von Jiffy voraussetzt, halte ich das persönlich eher für einen Nachteil, denn nicht alle Rechner haben Jiffy.

Eben, wieso sollte er sonst in dem Emulator ein Jiffy ROM verwenden. Ich würde da das Rad auch nicht 2 mal erfinden wollen.

Deswegen kann man davon ausgehen das er Jiffy voraussetzt. Zumindest zum Dateien kopieren.

Quote from M. J.

Du kannst Dir die Ram-Konfiguration gerne selber in dem verlinkten Video ansehen bei 13:30. Die braunen Felder zeigen klar an, daß sein OS von $8000 bis $dfff reicht. Der Bereich von $e000..$ffff gilt als reserviert. Auch im Bereich zwischen $4000 und $5fff gibt es mehrere Bereiche, die als vom OS belegt angezeigt werden.

Das hab ich dann wohl übersehen.

Quote from M. J.

Das ist aber noch kein OS. Das ist nur eine Sammlung von irgendwelchen Treiberroutinen

Richtig, aber richtig zusammen gesetzt eben schon. Ich wollte auch nicht damit sagen das man für so ein OS mit 4K auskommt.

Strings und Variablen, schlucken da ja auch noch einiges.

Aber die Routinen sind ja das wesentliche. Ich kann mir halt nicht vorstellen das man soviel RAM braucht für das was er da zeigt.

Quote from M. J.

1.) Nur 20 kb (= $5000) für Programme frei.

Das ist sehr wenig. Ehrlich. Für eine rein textorientierte GUI ist das echt wenig.

20 KB nach Laden des Launchers. Ich glaube 30 KB sind für Anwendungen frei.

Wenn man sich Greg's Videos ansieht, ist klar dass da nicht viel Speicher übrig bleiben kann: Er hat nicht nur einen Fenstermanager implementiert, sondern auch ein echtes UI-Toolkit - inklusive Layout-Boxen und komplexer Listviews (beide in Echtzeit in der Größe veränderbar), Tabs, Drop-Down-Menüs, Scrollbars usw. Das System verwaltet einen Text- und einen Grafikbildschirm und kann an beliebiger Y-Position zwischen beiden umschalten usw. usf.

Das ist mehr eine Tech-Demo (natürlich eine recht eindrucksvolle) als sonst irgendwas. Ich sehe auch gerade zum ersten Mal, dass er das OS verkaufen will, damit schränkt er die Verbreitung des Systems sowieso von Anfang an massiv ein...

Quote from M. J.

2.) Das OS läuft nicht von einer üblichen C64-Originalhardware.

Wie er selber sagt, ist Grundvoraussetzung ein Datenträger, der über Unterverzeichnisse verfügt. Und natürlich auch groß genug ist für die ganzen OS-Dateien. Und der natürlich schnell genug ist, um die ganzen Dateien in vertretbarer Zeit nachzuladen. Es ist also nur sehr eingeschränkt ein OS für den C64, mehr ein OS für den C64+modernem Datenträger. Das erklärt dann auch, warum sowas nicht schon früher in den 80ern geschrieben wurde: Diese Datenträger gab es damals schlicht nicht.

Sicher, aber wenn ich nur Original-Commodore-Laufwerke habe, brauche ich ja kein *OS*, sondern maximal ein einfaches UI-Toolkit? Als 'OS' taugen Action Replay o.ä. für 15x1-Besitzer deutlich mehr als alles andere.

Quote from Korodny

Wenn man sich Greg's Videos ansieht, ist klar dass da nicht viel Speicher übrig bleiben kann: Er hat nicht nur einen Fenstermanager implementiert, sondern auch ein echtes UI-Toolkit - inklusive Layout-Boxen und komplexer Listviews (beide in Echtzeit in der Größe veränderbar), Tabs, Drop-Down-Menüs, Scrollbars usw. Das System verwaltet einen Text- und einen Grafikbildschirm und kann an beliebiger Y-Position zwischen beiden umschalten usw. usf.

Beim C64 muss man aufpassen, dass man als Entwickler nicht zu viel will (wobei "zu wenig" auch Risiken birgt). GEOS hatte den ganzen von dir genannten "Kram" z.B. nicht – allerdings sahen auch fast alle GEOS-Apps, die nicht von Berkeley Softworks kamen, so aus. Es gab halt kein richtiges GUI-Toolkit (wie die damalige Macintosh Toolbox) außerhalb von ein paar zentralen Grafik-Basics (und auch keine UIGs). Ich denke, man sollte das dynamisch anlegen, sodass nur die UI-Sachen im Speicher gehalten werden müssen, die von einer App verwendet werden. 95% der C64-OS-Apps werden z.B. keine Bitmap-Darstellung benötigen – dann sollten auch weder die nötigen Routinen noch der Grafikbildschirm Speicher verschwenden.

Quote from Korodny

Ich sehe auch gerade zum ersten Mal, dass er das OS verkaufen will, damit schränkt er die Verbreitung des Systems sowieso von Anfang an massiv ein...

Ich hatte den kommerziellen Ansatz aufgrund von Indizien ja auch schon vermutet. Hast du da noch mehr Infos?

Quote from Korodny

Sicher, aber wenn ich nur Original-Commodore-Laufwerke habe, brauche ich ja kein *OS*

Das ist allerdings richtig. Wer nur die C64-Basisausstattung (C64, 1541, Bildschirm, Joystick) hat und nur Games zocken (und Demos angucken) will, der braucht keinerlei zusätzliches OS – allenfalls einen Game-Launcher. Also entweder setzt man die Hardware-Anforderungen höher an (moderne Massenspeicher-Lösung?, Maus?, Speichererweiterung? LAN? ...) oder aber man liefert gleich einen unverzichtbaren Teil davon mit.

Ich finde es ja, wie M. J., zunehmend attraktiv, einem neuen OS eine maßgeschneiderte Hardware-Erweiterung (in Form eines updatefähigen Moduls) zur Seite zu stellen. Bei Gregs Lösung sehe ich z.B. das Problem, dass er sehr oft auf den angeschlossenen Massenspeicher zugreifen will, z.B. um einen Status festzuhalten. Allerdings ist bei vielen Usern nur ein einziger Massenspeicher vorhanden – d.h. ein Medienwechsel (SD-Card) im Betrieb könnte im Zweifelsfall die System-Stabilität stören. Würde man aber den nötigen Zusatz-Speicher für ein OS (in welcher Form auch immer) mitliefern, könnte man mit den schon vorhandenen Laufwerken machen, was immer man möchte. Zudem gibt es auf dem C64 keine einfachere Lösung, um ein OS zu "installieren" als ein Modul in den dafür vorgesehenen Schacht zu stecken – auf jeden Fall deutlich simpler als eine anfängliche GEOS/MP3-Installation.

Quote from Retrofan

Quote from Korodny

Ich sehe auch gerade zum ersten Mal, dass er das OS verkaufen will, damit schränkt er die Verbreitung des Systems sowieso von Anfang an massiv ein...

Ich hatte den kommerziellen Ansatz aufgrund von Indizien ja auch schon vermutet. Hast du da noch mehr Infos?

Das schreibt er auf seiner Homepage:

Quote from http://www.c64os.com/c64os/

Purchase your copy of C64 OS

C64 OS is currently in beta testing. When it's ready you can purchase a copy right here.

Check back to this page for updates on the version 1.0 commercial release.

Quote from DeepL-Übersetzung ins Deutsche

Kaufen Sie Ihr Exemplar von C64 OS

C64 OS befindet sich derzeit im Betatest. Wenn es fertig ist, können Sie eine Kopie hier kaufen.

Schauen Sie auf dieser Seite immer wieder vorbei, wenn es Neuigkeiten zur kommerziellen Version 1.0 gibt.

Quote from Snoopy

Das schreibt er auf seiner Homepage:

Danke. Das hatte ich wohl übersehen. Naja, die Verbreitung wird sich stark danach richten, wie teuer das OS wird. Für 'nen 10er würden es viele einfach mal so mitnehmen, bei 50$ sähe es dagegen wohl schon deutlich anders aus.

Allerdings sehe ich bei einem kommerziellen Software-Vertrieb, egal zu welchem Preis, eher schwarz, was 3rd-Party-Apps angeht.

Quote from Retrofan

Allerdings sehe ich bei einem kommerziellen Software-Vertrieb, egal zu welchem Preis, eher schwarz, was 3rd-Party-Apps angeht.

Konkret bei diesem OS kann ich es nicht einschätzen.

Allgemein hängt es wohl davon ab, welchen Mehrwert das OS bietet. Zum Einen für die Benutzer und zum anderen für die Entwickler. Ein OS, nur um "das OS zu haben", wird sich eher schlecht verkaufen lassen.

Ich habe mal die Idee mit dem Modul inkl. OS in den Bereich Hardware ausgegliedert:

Modul (Flash-Speicher, WiFi ...) und passendes grafisches OS