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

Quote from Frenetic

Quote from M. J.

Das noch nicht veröffentlichte Sidekick20 kann auch einen VIC emulieren (oder ersetzen und den VC20 ohne betreiben), aber auf dem C64 müsste man einen Schritt weitergehen und gleich die CPU mitlaufen lassen. Fragt man sich, ob man nicht gleich BMC64 für das Sidekick kompiliert Dennoch: eine grafische Ausgabe über HDMI kann man immernoch programmieren mit Features nach Wunsch (man kann es ja bei 320x200 und 16 Farben belassen... oder einen VDC emulieren), aber ich habe es so verstanden, dass das nicht gewünscht ist

hdmi ist mehr als erwünscht 😉

Quote from Frenetic

Stephan Scheuer hat neben den REU u.a. Releases auch eine Toolchain für GeoRAM,

Besonders die Arbeiten von Stephan Scheuer zeigen sehr anschaulich, was man mit einem neuen Steckmodul erreichen könnte. Alle Programme, die er bislang gepatcht hat für 1581, GeoRam usw. lassen sich sehr leicht so umrüsten, daß sie auch unter dem neuen Modul laufen, jedoch ohne daß es dabei zu Problemen kommt in Hinblick auf IRQs oder Sprites. Eine Patch-Routine, die einen Sektor von dem Modul lädt, ist dabei sogar wesentlich kürzer (und schneller) als ein Schnellader oder die Verwendung eines Sektorladers über den Kernal. Mit anderen Worten: Die Originalspiele, bei denen Stephan Probleme hat, ausreichend freien Speicher für die Patchroutinen zu finden, dürften aufgrund der Kürze der Routine fürs Lesen vom Modul leicht zu patchen sein.

Damit dies möglich ist, habe ich formuliert, daß der externe Speicher nicht über ein Dateisystem verfügt, denn so stehen alle Daten direkt nacheinander im externen Speicher und können ohne großen Aufwand angesprochen werden, z. B. ohne sich durch eine Sektorlinkliste zu hangeln. Das schließt aber nicht aus, daß man einen zusammenhängenden Block des (mit mindestens 4 GB sehr großen) Speichers nicht auch dazu nutzen kann, ein ".dsk"-Diskettenimage abzulegen oder ein beliebiges anderes Dateisystem. Gerade weil der innere Aufbau des Speichers nicht festgelegt ist, können sich Programmierer dort in aller Ruhe austoben.

Quote from Frenetic

So wäre es ein Leichtes die IO-Bereiche mit mehr Registern zu belegen (und z.B. RAM und "Disk" parallel/im Wechsel zu betreiben, oder Teile eines IO-Bereichs für Register und RAM-Erweiterung zu nutzen).

Das klingt natürlich gut. So wäre es z. B. möglich, mittels eines Befehls "Gerät setzen" eine Auswahl zu ermöglichen zwischen SD-Kartenspeicher (als eine Art schneller Festplatte für den C64) und einem flüchtigen Ramspeicher ähnlich der GeoRam für temporäre Daten.

Da auch die anderen Möglichkeiten wie WLAN bereits umgesetzt worden sind, ist es somit keine Frage mehr, ob es technisch machbar ist, sondern ob sich jemand bereit erklärt, solch ein Modul zu bauen.

Quote from Snoopy

Für mich ist die "Schmerzgrenze" die, dass alles an "Berechnungen" usw. weiterhin nur vom C64 bewältigt wird. Ob ein Datenträger eine echte Diskette, eine SD-Karte oder ein Modem mit Netzzugang vom Server ist, ist mir persönlich völlig schnuppe. Wenn aber plötzlich Grafiken oder Sounds ausgespuckt werden, die ein echter C64 von sich aus nicht kann, oder ein Tempo hingelegt wird, das 100-1000 mal schneller als der C64 ist, dann wird für mich es "unecht". Das kann der C64 halt nun mal nicht und "soll" er auch weiterhin nicht "können können".

Im Prinzip stimme ich Dir zu, obgleich ich mir schon vorstellen könnte, einen C64 zu haben mit einer anderen, erweiterten Auflösung. Aaaaber, das wäre dann für mich eben auch kein Original-C64 mehr, sondern eher so wie der Apple//gs im Verhältnis zum Apple//e. Hier geht es mir aber darum, ein Modul zu haben für den Original-C64, wobei

a) der C64 an sich nicht verändert wird,

b) die genaue Hardware des Moduls nicht vorgeschrieben ist,

c) der C64 mit dem Modul per Befehl kommuniziert.

Es wäre also möglich, anstelle des Sidekick64 auch einen FPGA zu nehmen oder ein Board mit einem 6502-Prozessor oder... Der konkrete Hardwareunterbau sollte für den C64 unsichtbar sein, was eine gute Voraussetzung dafür ist, das Modul als ein C64-Modul zu akzeptieren.

Quote from Frenetic

eine grafische Ausgabe über HDMI kann man immernoch programmieren mit Features nach Wunsch (man kann es ja bei 320x200 und 16 Farben belassen... oder einen VDC emulieren), aber ich habe es so verstanden, dass das nicht gewünscht ist.

Sicherlich ließe sich noch so manches ergänzen, wobei wahrscheinlich eine HDMI-Ausgabe der Originalgrafik des C64 bei vielen ganz oben auf der Liste stehen würde. Ob man dann auch noch die Grafikfähigkeiten des C64 aufbohrt, ist eine Sache, die jeder für sich entscheiden soll, die aber mit dem eigentlichen Ziel des Steckmoduls, einen großen, schnellen Datenspeicher anzubieten, nichts zu tun hat. Das schließt nicht aus, daß jemand solche Features für sich ergänzt, genauso wie auch mehr SIDs usw. Wichtig ist nur, daß der Sinn des Moduls unabhängig von all solchen Features erfüllt werden kann und hierfür eine Schnittstelle definiert wird ähnlich wie bei der GeoRam, die von einem Vanilla-C64 aus bedient werden kann.

Also noch mal kurz:

1.) Für ein neues Modul braucht man eine feste Definition der Schnittstelle, wie ein normaler C64 auf den Datenspeicher zugreifen kann.

2.) Außerdem bräuchte man eine Methode zur Erkennung, ob z. B. auch ein WLAN oder ein Ramspeicher mit eingebaut ist.

3.) WLAN und Ramspeicher bekommen ebenfalls eine feste Schnittstelle.

4.) Egal, was für Erweiterungen auf einem Modul X noch vorhanden sind, es gilt, daß ein Modul diesen Schnittstellen-Standard anbieten muß.

5.) Schön wäre es dann auch, wenn z. B. C64-Emulatoren diese Schnittstelle umsetzen würden so wie sie auch die GeoRam emulieren. In diesem Fall käme dann zu tragen, daß die Hardware an sich nicht vorgeschrieben ist. Ein Emulator könnte den Datenspeicher ähnlich wie eine Diskette einfach als Image-Datei realisieren.

Mal eine Frage in die Runde:

Gäbe es Interesse an solch einem Modul? Und wäre jemand in der Lage, ein Sidekick64 so zu gestalten bzw. einen Emulator so zu programmieren bzw. eine andere Hardware zu basteln?

Interesse besteht sehr .

Fähigkeiten das selbst umzusetzen, ist nicht vorhanden

Quote from M. J.

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.

Oh, ich bin völlig deiner Meinung dass das zu wenig freier Speicher ist. Deswegen meine Bewertung als "Tech-Demo": Ich finde solche Projekte sind immer vom falschen Ende her gedacht: "Kriege ich das alles auch auf einem C64 implementiert?" statt "Was brauchen Anwendungsentwickler/Anwender eigentlich auf einem C64?".

"Mehrere Programme" soll C64OS aber m.W. nicht können. Man kann lediglich wie bei GEOS oder STOS kleine Utilities (Taschenrechner) in irgendeinen Speicherblock laden - der dann aber vermutlich auch für andere Sachen mitbenutzt wird (als Cache o.ä.).

Quote from M. J.

Also ich hätte keinen Plan, was ich mit dem OS machen sollte...

Naja, wenn du dich für den Grafikmodus entschieden hast, ist sein textbasiertes OS natürlich für dich natürlich sinnlos - das ist dann aber nicht die Schuld des OS.

Quote from M. J.

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.

Laufwerkstreiber sollte man m.E. tunlichst vermeiden - die Nutzung der ROM-Routinen spart maximal viel Speicher und ist maximal kompatibel, außerdem lässt sie dem Nutzer die Wahl ob bzw. wie viel Geld und Aufwand er in die Beschleunigung welcher Laufwerke investieren will. Dann bleiben nicht mehr viele systemweite Treiber übrig - mir fallen nur Maustreiber und Echtzeituhr ein. Alles andere (RS-232, Drucker, Ethernet) würde ich als anwendungsspezifische Treiber bezeichnen. Die würde zwar auch das OS mit verwalten und konfigurieren, aber die sind eher ein "Afterthought": Nicht ständig geladen, werden in den Anwendungsspeicher geladen, Laden und ggfs. Initialisieen übernimmt die Anwendung - da brauche ich beim "OS"-Design nicht viel Rücksicht nehmen.

Wenn Kernel und DOS von den ROMs übernommen werden, bleibt natürlich nicht mehr viel klassisches "OS" übrig, aber ich glaube mit dieser sprachlichen Ungenauigkeit können wir leben.

Quote from M. J.

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.

Aber dann bist du ja wieder bei einer Speicherverwaltung angelangt, die wolltest du doch vermeiden?

Quote from M. J.

Gäbe es Interesse an solch einem Modul?

Ja, durchaus. Mittlerweile und mit Blick auf die Zukunft fast wichtigstes Feature für mich wäre die Möglichkeit, das C64-Videosignal per HDMI auszugeben. Röhrenmonitore in Stand setzen oder halten ist nichts für mich - auch wenn ich das C64-Bild an einer Röhre lieber mag. Auf der anderen Seite möchte ich bei einem solchen Modul aber auch die Möglichkeiten nicht mehr missen müssen, die z.B. 1541U bietet bzw. auch der quasi identische Feature-Anteil des TC64 (spezielle TC64-Features sind da erst mal außen vor).

Was dann weitere Möglichkeiten eines solchen Moduls anginge, wäre selbst mit dieser Art der Beschränkung:

Quote from Frenetic

Ich finde eine gute Grenze (das ist aber natürlich nur meine Meinung) ist: was man damals (tm) hätte technisch umsetzen können, auch wenn es sehr aufwändig/teuer gewesen wäre, ist noch OK.

eine Menge möglich, wenn eins sich mal vergegenwärtigt, was es alles damals™ schon gab und möglich war. Ob 80 Zeichen (Steckmodul oder Nutzung des VDC im C64-Modus eines C128), Stereo-SID (SID Symphony), anderer Soundchip (Sound Expander: Yamaha YM3526 OPL), andere oder auch schnellere CPU (2 MHz-Hack aus der 64'er, CP/M-Modul und diverse "Turbokarten"), höhere Auflösung und mehr Farben (BTX-Modul), Festplatte(n) oder mehrere C64 umschaltbar in einem...

Quote from M. J.

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.

OK, "schnell" ist natürlich relativ. Wenn etwas deutlich schneller als die 1541 ist, ist es natürlich noch nicht unbedingt auf dem Level von internem RAM. Es gibt ja auch weiterhin zwei Möglichkeiten, möglichst viel Speicher für Dokumente zur Verfügung zu stellen: Entweder baut man das OS und die Apps möglichst modular, sodass nur gerade benötigter Code im RAM liegt und schafft dadurch möglichst viel freies RAM für Daten oder aber man verwaltet Dokumente auf dem externen Flash-Speicher (auch wenn das deutlich langsamer sein sollte als im RAM). Auch Kombinationen davon wären sinnvoll. Wenn möglich, würde ich immer den ersten Weg favorisieren.

Aber warum immer die kleinen Speicherschnipsel wie bei der GeoRAM verwenden, warum nicht 8 oder 16 K am Stück, wie es das EasyFlash einblendet? Macht das nicht viel mehr Sinn?

Und was ich noch zu Bedenken geben will: Sollte man ein neues OS für den C64 konzipieren, dann ist viel freier Speicher heutzutage weniger wichtig als noch zu Zeiten von GEOS. Denn bis auf vielleicht (Plain-) Texte wird kaum jemand umfangreiche Dokumente auf dem C64 erstellen/öffnen. Es geht heutzutage eher um Kommunikation und um "Streaming" von Daten. Beispiel Browser: Ein externer Web-Proxy würde immer nur so viele Daten zum C64 schicken, wie dieser im Speicher halten könnte – der Rest würde erst übertragen, wenn man am Ende des vorherigen Pakets angekommen wäre. Bei eigenen Texten könnte/müsste man selbst darauf achten, dass man eine z.b. 24/32KB-Grenze nicht überschreitet. Auch SID-Tunes würde man z.B. Titel für Titel in den Speicher holen. Und bei Chat/Messaging, Online-Gaming etc. ist auch der freie Speicher nicht der limitierende Faktor.

Quote from Korodny

Ich finde solche Projekte sind immer vom falschen Ende her gedacht: "Kriege ich das alles auch auf einem C64 implementiert?" statt "Was brauchen Anwendungsentwickler/Anwender eigentlich auf einem C64?".

Genau deinen Ansatz haben wir bei unserem damaligen GUI/OS-Thread umgesetzt. Es ging genau darum: Was will jemand (natürlich ein C64-Fan) heutzutage noch mit der Kiste tun (was er bisher nicht oder nur schlecht tun kann)? Was braucht er – Und was ist dafür nötig? So kamen wir letztlich zu den Spezifikationen.

Du hast aber recht, dass die meisten Projekte dieser Art das nicht so machen sondern einfach danach gehen, was der Entwickler gerne programmieren möchte – ungeachtet eines Bedarfs. Kann man ja auch so machen – ist schließlich nur Hobby. Nur wird das in den seltensten Fällen zu einem "Produkt" führen, das irgendwer außer dem Programmierer nutzen möchte.

Quote from Korodny

Naja, wenn du dich für den Grafikmodus entschieden hast, ist sein textbasiertes OS natürlich für dich natürlich sinnlos

Richtig, nur hat er sich ja nicht aus reinem Spaß für den Grafikmodus "entschieden", sondern weil bestimmte Anforderungen im Text-Mode nur unzureichend umzusetzen sind, z.B. ISO-Encoding (wegen zu wenig freien Chars), Mehr-als-40-Zeichen-Darstellung, Text-Stile (fett, kursiv ...) usw.

Ein weiteres Problem beim Charmode ist auch einfach, dass es dort (neues OS hin oder her) kaum neue (also vorher schlecht umsetzbare) Anwendungen geben wird – der ist sozusagen ausgereizt – und neue Apps sähen kaum anders aus als Bestands-Apps (und das bezieht sich auch auf die Funktionalität). Der Bitmap-Mode (PC-kompatibles Encoding, bis zu 80-Zeichen, Text-Stile, Text/Grafik-Kombination, ansprechende Formular-Vorgaben, Icon-orientiertes GUI, freiere Farbnutzung ...) bringt neue Möglichkeiten und damit vielleicht auch neue Ideen und Apps, die vorher nur sehr mühsam zu entwickeln waren. Aus Anwendungs-App-Sicht ist es fast so, als würde man eine Grafikkarte in den Rechner stecken (nur eben per Software).

Auch bei modernen Betriebssystemen bringen neue GUIs frischen Wind in die Betriebssysteme, siehe gerade auch wieder beim letztjährigen macOS 11, dem kommenden Windows 11 oder Android Material You. Das ist nicht zu unterschätzen.

Quote from Retrofan

Aber warum immer die kleinen Speicherschnipsel wie bei der GeoRAM verwenden, warum nicht 8 oder 16 K am Stück, wie es das EasyFlash einblendet? Macht das nicht viel mehr Sinn?

Weil man dafür ein wenig mehr Kontrollogik braucht. Früher hatte man sich das gespart und kam mit den paar Bye klar die man mit wenigen Mitteln an dem Port so ausdekodieren konnte.

Und ja, der zur verfügung stehende Speicher ist ein deutliches Limit. Man kann mangels eigener MMU nicht einfach mehr davon hinein stopfen sonder muss immer mit so einer "xxxRAM" Lösung leben die eben jede Software explizit nutzen können muss. Alle weiteren "Streaming" Überlegungen dazu machen den C64 dann zu einem Terminal.

Geht das Bankschalten nicht, um mehr RAM (64KB Bänke) zu adressieren?

Quote from Sheltem

Weil man dafür ein wenig mehr Kontrollogik braucht. Früher hatte man sich das gespart und kam mit den paar Bye klar die man mit wenigen Mitteln an dem Port so ausdekodieren konnte.

OK – aber früher ist früher. Wenn man also jetzt etwas neues bauen würde, warum sollte man es anders machen als beim EasyFlash – nur halt auch beschreibbar?

Quote from Sheltem

Alle weiteren "Streaming" Überlegungen dazu machen den C64 dann zu einem Terminal.

Das sehe ich nicht so. Macht YouTube deinen Rechner zu einem Terminal?

Es geht doch nur (falls du den angesprochenen Proxy meinst) darum, etwas in Häppchen zu liefern, das sonst für den C64-Speicher zu groß sein könnte (natürlich neben anderen Dingen, wie Entschlüsselung). Sobald die Daten kommen, muss sie der C64 trotzdem interpretieren/verarbeiten/rendern – nur halt nicht alle auf einmal.

Das ist aber z.Z. nebensächlich – ich wollte nur darauf hinaus, dass die Anforderungen an an neues OS für den C64 andere wären als in den 80ern (in denen GEOS entstand), weil man viele IT-Geräte nicht mehr in erster Linie zum ERZEUGEN von Dokumenten nutzt, sondern zum Kommunizieren und Konsumieren von Inhalten. Und dafür braucht es weniger Speicher als wenn man z.B. DTP machen möchte, bei dem man ein großes monolithisches Dokument im RAM halten muss.

Ich weiß nicht genau, wie GEOS die REU genutzt hat aber oft liest man, dass man ohne REU GEOS quasi vergessen konnte und es nur Spielerei war. Konnte man mit der REU wirklich große Dokumente verarbeiten, die über den freien C64-Speicher hinaus gingen? Oder ging das alleine schon über das andersartige Dateisystem? Und bräuchte man so eine Lösung noch?

Quote from Retrofan

Konnte man mit der REU wirklich große Dokumente verarbeiten, die über den freien C64-Speicher hinaus gingen?

Nein. Konnte man nicht. Eine GEOS App konnte immer nur 24kb? haben...so wie im C128 auch. In der REU konnte aber das System hinterlegt werden so das man nicht immer auf der relativ langsamen DIskette herummachen musste. Wie funktionierte das? Der Controller auf der REU kannte ein paar Befehle zum kopieren und verschieben von Speicherblöcken. DH, Software musste diese explizit nutzen. https://www.retro-programming.…o-know/reu-programmierung

Quote from Sheltem

Nein. Konnte man nicht. Eine GEOS App konnte immer nur 24kb?

Das war natürlich schade, wenn man eine REU mit viel Speicher hatte.

Aber was ist mit dem EasyFlash und seine einblendbaren 8/16K-Blöcke – wäre das nicht eine Technik, die man erweitern könnte für beschreibbaren Flash-Speicher?

Quote from Retrofan

Aber was ist mit dem EasyFlash und seine einblendbaren 8/16K-Blöcke – wäre das nicht eine Technik, die man erweitern könnte für beschreibbaren Flash-Speicher?

Dann hast du quasi eine REU.

Quote from Korodny

"Mehrere Programme" soll C64OS aber m.W. nicht können. Man kann lediglich wie bei GEOS oder STOS kleine Utilities (Taschenrechner) in irgendeinen Speicherblock laden - der dann aber vermutlich auch für andere Sachen mitbenutzt wird (als Cache o.ä.).

Finde ich persönlich zu einschränkend. Jedes Mal, wenn man eine andere Utility haben möchte, muß dafür extra ein Menü der OS-Oberfläche aufgerufen werden. Außerdem setzt die gleichzeitige Verwendung z. B. des Taschenrechners voraus, daß es eine gemeinsame Anzeige im Zeichensatzmodus gibt.

Quote from Korodny

Naja, wenn du dich für den Grafikmodus entschieden hast, ist sein textbasiertes OS natürlich für dich natürlich sinnlos - das ist dann aber nicht die Schuld des OS.

DIe Frage ist, ob es für einen reinen Textmodus überhaupt genügend Anwendungen gibt. Typische Spiele (bis auf harmlose Vertreter wie Minesweeper und Superhirn) fallen da schon komplett heraus., und viele Anwendungen würden m. M. n, von einem Hiresmodus erheblich profitieren. Von daher sehe ich überhaupt keinen Einsatzzweck für solch eine zeichenbasierte Oberfläche. Natürlich ist das nicht die Schuld des OS, aber ich befürchte halt, daß es nicht nur mir so ergeht, sondern daß das Grundkonzept an der Praxis völlig vorbei entwickelt ist. Besser wäre es, jedem Programm die freie Wahl der Darstellung zu überlassen und dem Programmierer verschiedene Bibliotheken für GUIs (Zeichensatz, Hiresbitmap usw.) zur Verfügung zu stellen. Doch bei diesem Projekt hat man den Eindruck, als wäre die Zeichensatzdarstellung eng mit dem anderen OS-Code verzahnt, so daß eine Trennung gar nicht richtig möglich ist.

Meine persönliche Ansicht ist ohnehin, daß der Fensteransatz heutzutage nicht mehr aktuell ist. Soll heißen: Fenster sind auf dem C64 eher überflüssig. Als einzigen Einsatz könnte ich mir vorstellen, daß z. B. eine Dateiauswahl in einem Bildschirmbereich eingeblendet wird, der automatisch vom System gesichert und später restauriert wird. Verschiebbar braucht diese Anzeige dabei gar nicht zu sein. Ansonsten ergeben "richtige" Fenster nur dann einen Sinn, wenn man einen Rechner im Multitaskingmodus betreibt und mehrere Programmausgaben gleichzeitig betrachten will. Das aber setzt in der Regel eine hohe Bildschirmauflösung, d. h. Platz für die Fenster, voraus. Der C64 ist dafür mit seinen 320 Pixeln eher ungeeignet. Es gibt ohnehin schon zu wenig Platz auf dem Bildschirm. Dann sollten Programme diesen wenigen Platz auch vollständig und nach eigenem Belieben nutzen können.

Quote from Korodny

Laufwerkstreiber sollte man m.E. tunlichst vermeiden

Sehe ich nicht so. Auf Systemen ohne Jiffy (ja, die gibt es) sind Laufwerkzugriffe ohne Schnellader einfach nur quälend langsam. Daher sollte man sowas weiterhin optional halten. Aber genau das ist ja der Punkt bei diesem neuen OS: Es ist von vornherein gar nicht konzipiert für einen normalen C64, sondern für einen bereits mit moderner Hardware stark aufgerüsteten C64, nur daß diese Aufrüstung m. M. n. in die falsche Richtung geht.

Quote from Korodny

Wenn Kernel und DOS von den ROMs übernommen werden, bleibt natürlich nicht mehr viel klassisches "OS" übrig, aber ich glaube mit dieser sprachlichen Ungenauigkeit können wir leben.

Kann man, wenn sich alle einig darüber sind, was genau mit "OS" dann noch gemeint ist, aber mein Eindruck ist immer wieder, daß dies nicht der Fall ist.

Quote from Korodny

Aber dann bist du ja wieder bei einer Speicherverwaltung angelangt, die wolltest du doch vermeiden?

Nur für Programme, aber nicht für das OS selbst. Das OS sollte aus Bibliotheken bestehen, die optional hinzugeladen werden können, damit der Speicher nicht mit ungebrauchten Teilen zugemüllt wird. Die Speicherverwaltung einer Anwendung hingegen sollte allein nach dem Stapelprinzip organisiert sein, d. h. ein gibt einen Stapel im Speicher für lokale Daten, der jeweils herab- und wieder heraufgesetzt und ähnlich benutzt werden kann wie ein Stapel in modernen Hochsprachen. Wenn z. B. ein Dateiauswahlfenster am Bildschirm erscheinen soll, werden die Bildschirmdaten des Auschnittsbereichs auf diesen Stapel gerettet. Zusätzlich können Zeichensätze in den Stapel geladen werden, und auch das Inhaltsverzeichnis wird dort abgelegt. Nach Beenden wird der Stapel zurückgesetzt, und der Speicher steht damit anderen Routinen zur Verfügung. Dies ist die einfachste und auch effektivste Methode, um Speicher zu verwalten. Nun wäre es natürlich schön, wenn man auch Programmbibliotheken oder Module wie die Dateiauswahl in den Stapel laden könnte, doch das setzt relokatiblen Code voraus, wozu der 6502 nicht wirklich gemacht ist. Der Aufwand dafür ist sehr hoch, sowohl bei der Programmerzeugung als auch in der praktischen Anwendung, so daß es in dieser Hinsicht einfacher ist, einen festen Bereich im Speicher für zusätzlichen Code zu reservieren. Das System muß sich (anhand eines Ministapels) dafür merken, welches Programmodul vorher in diesem Speicherbereich abgelegt war und dieses nach Beendigung des zuletzt geladenen Moduls restaurieren, d. h. erneut laden.

Quote from Retrofan

Entweder baut man das OS und die Apps möglichst modular, sodass nur gerade benötigter Code im RAM liegt und schafft dadurch möglichst viel freies RAM für Daten oder aber man verwaltet Dokumente auf dem externen Flash-Speicher (auch wenn das deutlich langsamer sein sollte als im RAM).

Ich würde sagen, daß der erste Weg der einzig beschreitbare ist. Wie gesagt: Externer Ram-Speicher ist für den Prozessor kein Ram. sondern ein Datenträger. Auch wenn der sektorweise Zugriff darauf schneller ist als bei der 1541 (, was nicht gerade ein Problem darstellt), ist die Handhabung genauso umständlich. Sie erfordert die Einführung einer Abstraktionsschicht "virtueller Speicher", was in der Anwendung kompliziert und langsam ist. Als Ablage für aktiv zu bearbeitende Daten ist dieses externe Ram daher nicht geeignet. Hinzukommt natürlich auch, daß man Flashspeicher nicht andauernd neu beschreiben kann. Auch wenn nur ein Byte geändert wird, bedeutet dies, das auf der SD-Karte gleich der ganze 512 Bytes große Sektor neu geschrieben werden muß. Aus diesem Grunde sollte man bei einem neuen Steckmodul dringend trennen zwischen Massendatenspeicher (SD-Karte) und externem Ram (tatsächlichem Ram auf dem Modul) und die SD-Karte wirklich nur dann beschreiben, wenn man große Datenmengen dauerhaft speichern möchte.

Quote from Retrofan

Aber warum immer die kleinen Speicherschnipsel wie bei der GeoRAM verwenden, warum nicht 8 oder 16 K am Stück, wie es das EasyFlash einblendet? Macht das nicht viel mehr Sinn?

Nein, nicht wirklich. Damit vergrößert man zwar das Fenster, doch wirkt sich dies nicht aus auf die Speichervirtualisierung. Da der 6502 mittels der Indexregister nicht mehr als 256 Bytes in einem Rutsch kopieren kann, nutzt einem das größere Fenster auch nicht viel. Es gilt weiterhin, daß die Daten zur Bearbeitung von der REU/Easyflash in den Speicher kopiert werden müssen. Dies ist bei den meisten Spielen der EasyFlash auch der Fall: Das Spiel wird zu Beginn von der Easyflash in den Speicher des C64 entpackt. Diejenigen Programme, die während des Spiels Daten aus der EasyFlash nachladen, sind dafür speziell angepaßt worden. In diesen Fällen reicht es aus, über das Fenster die Daten einzublenden, um sie dann gezielt direkt anzuwählen. Bei einem OS ist dies aber nicht der Fall. Hier läuft die Verarbeitung über allgemeine Routinen, die davon ausgehen, daß die Daten nicht direkt im Fenster manipuliert werden, sondern im Speicher des C64, denn ein Programm weiß ja nicht, ob der C64 jetzt eine REU hat oder ein GeoRam oder... Genau diese Hardware soll ja vor ihm verborgen bleiben. Das ist so ähnlich wie früher beim PC mit seinem erweiterten Speicher (> 1 MB). Dafür gab es auch mehrere Verfahren. Die einen verfügten über eine Hardware, die ähnlich der REU in der Lage war, einen Ausschnitt des Speichers im Adreßraum einzublenden, bei den anderen mußten die Daten vom Prozessor in einen Puffer kopiert werden, der dann dem Programm zur Verfügung gestellt wurde. Die Idee war, daß die Programme nicht wissen mußten, welche Hardware konkret vorlag, sondern lediglich dem OS mitteilen mußten, welchen Speicherbereich sie haben wollten. Da der 80(2)86 ein 16 Bit-Prozessor ist (mit segmentierter Adressierung), war der Datenpuffer 64 kb groß. Beim 6502 sind es dann halt 256 Bytes.

Soweit ich mich erinnere (Bitte um Korrektur, wenn ich hier falsch liege), setzt der Einsatz der REU voraus, daß nicht nur der externe Speicher eingeblendet wird (z. B. bei $a000..$bfff), sondern gleichzeitig auch das Kernal-Rom. Dies ist hinderlich, da man so den direkten IRQ-Vektor bei $fffe/$ffff nicht verwenden kann (oder man muß halt den IRQ solange sperren). Außerdem kann man nicht gleichzeitig lesend auf das kostbare Ram unter $e000..$ffff zugreifen. Allein schon aus diesem Grunde würde ein OS die REU handhaben wie ein Diskettenlaufwerk: IRQs werden kurzzeitig blockiert, die REU-Daten werden eingeblendet und in einen zusätzlichen Puffer kopiert, danach wird wieder auf Ram umgeschaltet und die IRQs werden reaktiviert. Das Programm kann dann die Daten in dem Puffer bearbeiten.

Nebenbei: Um ein neues Steckmodul kompatibel zu halten zu vielen, vielen Programmen, die mittels Schnellader nachladen, sollte man die Daten allein über das Fenster bei $de00 laden und schreiben, da hierbei das Kernal-Rom nicht aktiviert werden muß. Vielmehr können dann wie bei einem echten Schnellader die Daten problemlos vom Ram unter dem Kernal (oder Basic) gelesen und geschrieben werden, während gleichzeitig der IRQ intakt bleibt. Das ist wirklich die sauberste Lösung, um alle Spiele kompatibel zu beschleuigen und dabei auf einem Massendatenträger abzulegen.

Quote from Retrofan

Sollte man ein neues OS für den C64 konzipieren, dann ist viel freier Speicher heutzutage weniger wichtig als noch zu Zeiten von GEOS.

Das ist richtig, aber 64 kb sind nun wirklich nicht viel, wenn man z. B. Hires-Bitmap verwenden möchte mit diversen Zeichensätzen usw. Da ist der Speicher schneller voll als einem lieb ist.

Quote from Sheltem

Dann hast du quasi eine REU.

Jein, denn die klassische REU blendet doch nur 256 Byte ein. 16 KB sind schon was deutlich anderes.

Quote from M. J.

Diejenigen Programme, die während des Spiels Daten aus der EasyFlash nachladen, sind dafür speziell angepaßt worden. In diesen Fällen reicht es aus, über das Fenster die Daten einzublenden, um sie dann gezielt direkt anzuwählen. Bei einem OS ist dies aber nicht der Fall. Hier läuft die Verarbeitung über allgemeine Routinen, die davon ausgehen, daß die Daten nicht direkt im Fenster manipuliert werden, sondern im Speicher des C64, denn ein Programm weiß ja nicht, ob der C64 jetzt eine REU hat oder ein GeoRam oder... Genau diese Hardware soll ja vor ihm verborgen bleiben.

Wenn wir von der Idee ausgehen, dass das OS mit einem noch zu konzipierendem Speichermodul zusammen ausgeliefert wird, dann WEISS das OS, was für eine Speichererweiterung vorhanden ist. Und letztlich weiß es auch das Programm, wenn es zu diesem OS (und damit zu dem Modul) kompatibel ist.

Quote from M. J.

64 kb sind nun wirklich nicht viel, wenn man z. B. Hires-Bitmap verwenden möchte mit diversen Zeichensätzen usw. Da ist der Speicher schneller voll als einem lieb ist.

Ich hatte ja mal vor Jahren diese OS-Speicheraufteilung (bei Nutzung eines EasyFlashs) skizziert und da bleibt meines Erachtens ein Menge RAM übrig. Auf jeden Fall mehr als bei GEOS, zumindest wenn man den Teil des permanent im Speicher nötigen OS klein genug halten kann. Und wenn ich mir jetzt vorstelle, dass der einblendbare 16KB-Speicherbereich RAM statt ROM wäre – dann erschiene mir das Konzept ideal. Ich wüsste nicht, warum man das gegen eine REU-Lösung eintauschen sollte.

Das einzig ungelöste Problem wäre, wie man Daten zurückschreiben könnte, denn wenn man in den eingeblendeten EF-Speicherbereich schreiben will, schreibt man in das RAM darunter, oder?

Quote from M. J.

Um ein neues Steckmodul kompatibel zu halten zu vielen, vielen Programmen, die mittels Schnellader nachladen, sollte man die Daten allein über das Fenster bei $de00 laden und schreiben, da hierbei das Kernal-Rom nicht aktiviert werden muß.

Meines Erachtens wäre es gar nicht nötig, zu irgendwas kompatibel zu sein. Meinetwegen könnte sich das OS und das ganze Modul komplett ausklinken, wenn ein "klassisches" C64-Programm geladen wird. Warum soll man irgendwelchen Alt-Programmen etwas zur Verfügung stellen? Meiner Meinung nach reicht es vollkommen, wenn neue angepasste Bitmap-Programme von der Speichererweiterung profitieren.

Aber wenn man das anders sieht, dann könnte sich das Modul im Notfall wie ein normales EasyFlash verhalten – dafür wurden schon sehr viele Programme angepasst und die wären out-of-the-box kompatibel.

Quote from Retrofan

die klassische REU blendet doch nur 256 Byte ein

Eine REU blendet *nichts* ein (nur ihre Steuerregister ab $df00). Ansonsten legt der Programmierer fest, was/wie viel von wo wohin soll.

Arndt

Quote from GoDot

Eine REU blendet *nichts* ein (nur ihre Steuerregister ab $df00). Ansonsten legt der Programmierer fest, was/wie viel von wo wohin soll.

Ach so, dann hatte ich das falsch verstanden. Ja, dann ist eine REU ja sogar noch flexibler als ein EF – und mir genau so lieb. Nur kann das Sidekick (als mögliche Entwicklungshardware) leider keine REU emulieren – ist wohl mit dem DMA zu komplex bzw. zu timingkritisch. Da ginge nur Geo/Neo-RAM.

Quote from Retrofan

Ach so, dann hatte ich das falsch verstanden. Ja, dann ist eine REU ja sogar noch flexibler als ein EF – und mir genau so lieb. Nur kann das Sidekick (als mögliche Entwicklungshardware) leider keine REU emulieren – ist wohl mit dem DMA zu komplex bzw. zu timingkritisch. Da ginge nur Geo/Neo-RAM.

DMA ist schlichtweg nicht vorgesehen. Das Sidekick könnte aber die Funktionalität mit dynamischem Speedcode emulieren (Transfer ~150kb pro Sekunde oder etwas mehr), das Programmieren sähe nur leicht anders aus. Einblenden wie bei NeoRAM ist aber natürlich immer noch die schnellste Möglichkeit, wenn es mit der Fenstergröße passt.

Die REU ist mit Abstand die am einfachsten zu handhabende Speichererweiterung - die macht DMA, d.h. ein Controller auf der REU kopiert beliebige Speicherbereiche vom C64-RAM in die REU oder umgekehrt - ich meine es ging sogar SWAP, also RAM-Inhalte tauschen. Und das alles (fast) ohne CPU-Belastung.