Zwei Dumme, ein Gedanke.
Primär hatte ich nicht vor, eine Ramdisk für TriOS zu schreiben, sondern ich wollte eine Speicherverwaltung für Spin-Programme, welche unterTriOS laufen und es war mehr mit Blick auf die Verwaltung von Daten gedacht, da die Spinprogramme im hRAM laufen. Aber die Idee ist ähnlich deiner Vorstellung - die Speicherverwaltung als Minidateisystem.
Mein Plan für die Sache im TriOS sah in etwa so aus: Ein TriOS-Programm, wie zum Beispiel ein Editor, kann sich im eRAM Speicher anfordern, indem es in der Ramdisk eine Datei mit passender Größe erzeugt. Auf diesen Speicher kann dann wie bei einer Datei sequentiell per rd_get/put/seek zugegriffen werden, oder direkt per Adresse, wobei in diesem Modus die Adresse $0 dem ersten Byte des Speicherblocks entspricht. Wenn der Editor verlassen wird, kann wahlweise die Speicherdatei erhalten bleiben. In der Kommandozeile kann man die Dateien/Speicherblöcke über das xdir-Kommando anzeigen und mit xload/xsave/xdel rudimentär verwalten. Dabei kann jede Speicherdatei über ihren 8+3-Dateinamen angesprochen werden. Startet man ein anderes Programm, zum Beispiel einen Compiler, so kann dieser die Daten in den Dateien/Speicherblöcken weiter verarbeiten. Startet man wieder den Editor, geht es weiter mit der Textbearbeitung usw. Ach ja: Bei dem Speicherdateisystem verwende ich auch Filedeskriptoren und es können mehrere Dateien geöffnet werden.
Die Ramdisk ist dabei als verkettete Liste von der niedrigsten Adresse aufsteigend realisiert. Von der obersten verfügbaren Speicheradresse absteigend habe ich die Systemvariablen von TriOS angeordnet. Der freie Bereich zwischen Ramdisk und Systemvariablen kann auch von Programmen genutzt werden, ist aber nicht resident und wird eventuell überschrieben, sobald sich etwas in der Ramdisk tut. Diesen Bereich habe ich für einen einfachen und unkomplizierten Zugriff vorgesehen, der nicht so kompliziert wie der Zugriff auf die Ramdisk dafür aber "vogelfrei" ist.
Was man mit diesem Modell nicht direkt machen kann, ist eine feste Zuweisung eines Speicherblocks zu einer physischen Adresse. Da braucht es dann ein anderes Modell. Im Prinzip ist diese Geschichte mit der Ramdisk auch mehr ein Versuch von mir eine verwendbare Speichervarwaltung zu realisieren. Ich bin halt nicht der große Softwarespezialist, das sind auf dem Gebiet vielmehr meine ersten Schritte...
In PASM als MMU ist das eine ganz andere Sache als in Spin. Der momentane Satus ist je nur von TriOS aus gedacht und alle Zugriffsroutinen für den eRAM sind in Spin realisiert, also auch entsprechend langsam. Kann sein das die Idee mit der Kombination von Ramdisk und Speicherverwaltung als verkettete Liste Murks ist, dann muss eine bessere Variante her.
Die Aufteilung von Funktionen auf die physischen RAM-Bänke fand ich aus folgendem Grund dennoch sehr interessant: Um Hardware zu sparen, findet ja die Adressdekodierung des obersten Adressbits im Hive per Software statt, indem direkt die Signale /RAM1 & /RAM2 programmiert werden. Wenn man für jede Funktion (TriOS/XMM) eine RAM-Bank verwendet, so kann man sich diesen Aufwand in den Zugriffsroutinen zur Ansteuerung des RAMs sowohl im TriOS als auch in den anderen Systemen sparen - es wird einfacher und schneller bei jedem Speicherzugriff und man könnte TriOS und andere Systeme mit eigenem Speicherzugriff sauber trennen, ohne die Speicherverwaltung von TriOS komplett umzubauen. Nachteil ist dann die Begrenzung auf 1/2Meg Speicher.
Eine andere Variante wäre ja, den Regnatix-Code von TriOS komplett zu beenden, wie ich das schon oben geschrieben hatte. Dann hätte man nur noch den TriOS-Code in Administra und Bella laufen und die Schnittstelle zum eigenen System wäre dann der Bus.
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford
