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

Zitat von Korodny

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

Hmmm... halte ich persönlich immer noch für viel zu wenig. Wenn ich das richtig verstanden habe, soll dieser wenige Speicher dann u. U. noch auf mehrere Programme aufgeteilt werden. Um unter diesen Bedingungen zu programmieren, bräuchte man unbedingt einen externen Ramspeicher und einen Programmaufbau, bei dem die zu bearbeitenden Daten ständig in einen Puffer geladen und von dort geschrieben werden. Da das aber ziemlich langsam ist, stellt sich schon die Frage, welche Art von Programmen für solch ein System angedacht sind.

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

Und nun wieder die Preisfrage: Wer braucht diesen ganzen Kram? Da sich sein System für Spiele nicht eignet (einerseits wegen des Speichermangels, andererseits wegen der vorgeschriebenen Zeichenausgabe) bleiben eigentlich nur Tools als anvisierte Programmgruppe übrig. Doch selbst da dürfte man schnell an die Grenzen kommen. Der Witz dabei ist, daß man unter diesem System ja nicht einmal einen Texteditor schreiben kann, denn ein solcher sollte eigentlich im Bitmap-Hires-Modus seine Texte anzeigen, um so entweder auf 80 Zeichen pro Zeile zu kommen oder ein Lowcost-WSYIWYG zu gestalten (Fettdruck direkt erkennbar). Auch ein Spreadsheet sollte man heutzutage eher als Grafik ausgeben denn als Text. Also ich hätte keinen Plan, was ich mit dem OS machen sollte...

Zitat von Korodny

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.

Das ist auch immer die Frage, was man beim C64 unter einem "OS" verstehen will. Die einen denken dabei an einen Filemanager, die anderen an eine GUI-Bibliothek, wieder andere an Treiber für 1541 und Maus und noch andere an Multitasking und Speicherverwaltung. Für mich persönlich gehören weder Filemanager noch GUI-Bibliothek zu einem OS. Ein Filemanager ist eine App, und die GUI-Bibliothek eine Standardbibliothek, die vom OS bereitgestellt werden kann, um Programmierern die Arbeit zu erleichtern und dem Anwender programmübergreifend eine vertraute Umgebung zu schaffen. Richtig OS sind eigentlich nur die Treiber sowie die Verwaltung von Ressourcen wie Speicher und CPU. Letzteres finde ich für den C64 einfach überdimensioniert. Dafür ist der 6502 nicht gemacht, und es macht meiner Ansicht nach auch keinen Sinn, so etwas wie Multitasking auf dem C64 zu implementieren, da es in der Praxis keinen nennenswerten Vorteil bietet, dafür aber jede Menge Nachteile mit sich bringt. Treiber hingegen können schon nützlich sein, doch auch da wäre es sinnvoll, wenn eine App selbst entscheiden könnte, welchen Treiber sie überhaupt braucht. So wäre es z. B. möglich den Maustreiber nur dann zu laden, wenn das Programm auch eine Maus benutzt.

Im Endeffekt ist die beste Lösung immer noch, daß das "OS" aus einer Sammlung von diversen Bibliotheken besteht, darunter die erwähnten Treiber als auch die GUI.

Zitat von Retrofan

Die Programme sollen sich bitte zur Laufzeit die benötigten Routinen aus dem OS holen und gut ist – dann sind alle auf dem gleichen Stand.

So in etwa, nur daß die Routinen halt in getrennten Dateien vorliegen, die einzeln geladen werden können, und nicht als ein großer monolithischer Block, der viel Speicherplatz verbraucht, egal welchen Teil man davon wirklich benötigt.

Für so eine Vorgehensweise wäre aber besser eine andere Hardware geeignet wie z. B. ein OS auf einem Steckmodul mit SD-Karte als Speicher.

Zitat von Retrofan

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.

Beim Vorschlag des neuen Steckmoduls wäre so ein Gamelauncher quasi mit eingebaut. Das wäre die universalste Lösung.

Zitat von Retrofan

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.

Und genau das ist der springende Punkt: Alle Laufwerke bleiben wie sie sind, dafür können die Teile des OS (oder auch andere, beliebige Daten) geladen und gespeichert werden, ohne daß man hierfür auf Kernal-Routinen zurückgreifen müßte. Also keinen Konflikt mit Speicheraufbau, IRQ, Sprites usw. Gelingt es technisch, dem Modul noch ein Autobootrom beizufügen, lassen sich Desktop/Launcher/Filemanager direkt nach einem Reset starten, ohne daß man extra eine Diskette einlegen muß. Und da beim Laden nicht auf den seriellen Bus zugegriffen werden muß, werden die Daten, z. B. Spiele, auch noch schneller geladen als beim SD2IEC. Daher verstehe ich ehrlich gesagt auch nicht, wieso nicht schon längst jemand diese Hardware gebaut hat, zumal die Grundlage dafür in der Form des Sidekick64 bereits vorhanden ist.

Zitat von Retrofan

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

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

Der Link scheint bei mir nicht zu funktionieren und verweist nur auf den Anfang dieser Seite...

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

Was wäre zum jetzigen Zeitpunkt realistisch?

1.) Auf Basis des Sidekick64 läßt sich ein Modul erstellen, welches eine SD-Karte als großen Massenspeicher verwendet. Wie dabei die SD-Karte intern organisiert wird, ist zunächst zweitrangig. Soll heißen: Entweder a) der Massenspeicher entspricht 1:1 dem Aufbau der SD-Karte, oder b) der Massenspeicher wird auf einer FAT32-formatierten SD-Karte als Datei angelegt.

2.) Dieser Speicher läßt sich wie bei der GeoRam über ein Fenster bei $de00 lesen und schreiben, wobei das Schreiben im Vergleich zur GeoRam aber ein dauerhaftes Schreiben ist.

3.) Der C64 sieht nicht die interne Struktur der SD-Karte. Sollte der Speicher als Datei auf der SD-Karte organisiert sein, hat der C64 keinerlei Zugriff auf das Inhaltsverzeichnis oder andere Dateien auf der Karte, nur auf die Bytes innerhalb der Datei.

4.) Die Kommunikation mit dem Speicher läuft ähnlich ab wie bei der GeoRam. In Registern (im Bereich $dfxx) schreibt man einen Befehl sowie die Adresse des Blocks, den man lesen/schreiben will. Nach Schreiben des Befehls wird der neue Block angezeigt. Das geschieht am besten so, daß das Modul diesen Block in einen internen Cache lädt. Wurde dieser Cache vorher beschrieben, wird der Inhalt auf die SD-Karte kopiert. ==> Es gibt keine getrennten Befehle zum Lesen und Schreiben, sondern nur zum Setzen eines Blocks.

5.) Mit einem gesonderten Befehl läßt sich eine Basisadresse festlegen. Alle weiteren Adreßangaben sind relative Offsets auf diese Basisadresse. Damit läßt sich der Speicher in unabhängige Bereiche teilen.

6.) Der Speicher enthält kein Dateisystem in der Form der 1541 oder 1581. Man könnte theoretisch ein Dateisystem einrichten, sollte es aber nicht, da man dafür extra einen Dateisystemtreiber benötigt. Besser ist es, den Speicher einzuteilen nach dem TLV-Prinzip.

7.) Nach diesem Prinzip lassen sich alle möglichen Programme auf die SD-Karte schreiben und mittels eines Launchers schnell starten. Man kann aber auch Bibliotheken dort ablegen oder einen Filemanager oder einen Desktop oder...

8.) Günstig wäre ein zusätzliches Autobootrom, welches die Anfangssektoren nach einem Bootprogramm durchsucht und dieses startet. Alternativ könnte nach einem Reset der interne Fensterzeiger auf einen Bootblock zeigen, der bei $de00 eingeblendet wird und sich dann mittels SYS 56832 starten läßt.

Was also nicht direkt dabei wäre, wäre ein 1541 kompatibles Dateisystem. Es stünde aber jedem offen, ein solches in einem Block des SD-Kartenspeichers einzurichten und mit einem Dateisystemtreiber zum Laden von Programmen zu versehen. Wichtig dabei ist aber, daß dieser Dateisystemtreiber sich dann im C64 befindet und nicht Teil der Hardware ist (wie beim SD2IEC).

Günstig wäre es auch, wenn man WiFi zusätzlich in die Hardware aufnehmen könnte (mit Registern bei $dfxx). Aber zur technischen Umsetzung kann ich nichts sagen.

Ebenso handelt es sich hierbei nicht um eine Speichererweiterung im Sinne einer GeoRam oder REU, da der Speicher nichtflüchtig ist und besser nicht andauernd neu geschrieben werden sollte. Ob sich zusätzlich zu dem SD-Kartenspeicher noch Ram-Speicher auf dem Modul unterbringen läßt, der dann wie die GeoRam angesteuert werden kann, weiß ich ebenfalls nicht. Ich glaube allerdings auch nicht, daß solch ein zusätzlicher Ramspeicher dringend notwendig ist. Bei einem OS kommt es viel mehr darauf an, feste Routinen oder Daten schnell nachzuladen, aber weniger Ramspeicher extern auszulagern.

WIe gesagt: Das Sidekick64 bietet heute schon an, die oben skizzierte Hardware zusammenzustellen. Daraus würden sich jede Menge neue Möglichkeiten für den C64 ergeben, ohne daß man die eigentliche Hardware verändert. Und wer auch immer sich darüber beschwert, daß das Steckmodul einen Prozessor hat, sollte sich besser auch keine 1541 zulegen.

Zitat von Retrofan

30 KB frei für Programme finde ich voll OK, wenn man zusätzlich Zugriff auf weiteren schnellen Speicher hat. Dann muss dort ja nur der Programmcode liegen und Daten könnten größtenteils außerhalb verwaltet werden. (Wie bei "unserem" angedachten Modul).

Kleiner Haken: Es gibt außerhalb der eingebauten 64kb des C64 keinen schnellen Speicher. Speicherzugriffe bei der REU oder dem GeoRam (oder auch "unserem" Modul) sind im Verhältnis zu einem Direktzugriff des Prozessors auf echtes Ram (und sei es über Bankswitching) bis zu 100 mal langsamer. Ursache dafür ist einerseits die langsame Übertragung der Daten (bei der GeoRam müssen alle Daten per Hand aus dem Fenster bei $de00 in den Speicher kopiert werden) als auch das zugrundeliegende Speichermanagement, da jede App quasi ihren eigenen Treiber für ein virtuelles Ram mitbringen muß, bei dem vor einem Zugriff erkannt werden muß, ob sich eine Adresse im Puffer befindet, und wenn nicht, der Puffer neu beladen bzw. der alte veränderte Inhalt vorher geschrieben wird. Das ist alles andere als einfach und im Ergebnis halt sehr langsam. Wichtger Punkt dabei: Daten lassen sich nicht außerhalb verwalten, sondern nur im C64, was ein vorgehendes Laden in den Puffer zwingend nötig macht.

Man stelle sich folgende einfache Aufgabe vor: In einem Texteditor soll an einer bestimmten Stelle eine neue Zeile eingefügt werden. Zu diesem Zweck muß der hintere Textanteil umkopiert werden, was bedeutet, daß man stückweise diesen Teil in den Speicher laden und dann an eine neue Position zurückschreiben muß. (Gleiches gilt natürlich auch fürs Zeilenlöschen.) Selbst mit dem DMA der REU ist dies immer noch ein aufwendiger Akt. Oder man will einfach nur den Text nach einem Wort durchsuchen. Auch dann gilt wieder, daß der Text in einzelne Häppchen zerlegt, geladen und durchsucht werden muß.

Schlimmer wird es noch, wenn man den Speicher nicht nur einfach linear ansprechen will wie bei einem riesigen Textblock, sondern sowas wie Zeigerstrukturen verwalten möchte oder structs. Dann muß man zunächst die Zeiger umwandeln in Offsets auf den externen Datenträger, dann kann man bestenfalls ab diesem Offset die Daten in den Speicher laden (REU) oder muß beim Kopieren schauen, ob die Daten in den nächsten Speicherausschnitt des Speicherfensters hineinragen, und dann noch eine Speicheranfrage stellen (GeoRam).

Wie gesagt: Schnell geht anders. Die erfolgreichste Methode, eine GeoRam einzusetzen, ist dann zumeist, sie wie eine Ramdisk zu verwalten, von der stets ganze Blöcke (= Sektoren) geladen oder geschrieben werden. Das setzt aber voraus, daß das Programm intern bereits so organisiert ist, daß es seine Daten blockweise verarbeitet (wie z. B. der Infocom-Interpreter).

So oder so benötigt man ein virtuelles Speichersystem, was die Komplexität einer App drastisch steigert. Im schlimmsten Fall geht ein Programmierer so vor, daß er keinen internen Cache verwendet, sondern für jeden Zugriff auf ein Element eine neue Übertragungsanfrage an das OS stellt. Doch dann geht die Geschwindigkeit völlig baden.