RAM-Disk unter TriOS r48?

[quix]

Ich hab mir eben mal das Paket r48-27-11-2011 runter geladen und angeschaut. In der Datei "installation.txt" stehen Befehle für eine RAM-Disk. Wird sie im Externen RAM (2x512k) eingerichtet?

[drohne235]

Ich hab mir eben mal das Paket r48-27-11-2011 runter geladen und angeschaut. In der Datei "installation.txt" stehen Befehle für eine RAM-Disk. Wird sie im Externen RAM (2x512k) eingerichtet?

Genau, die Ramdisk liegt im eRAM und ist dynamisch verwaltet. Integriert habe ich sie voriges Jahr. Auch im IOS sind schon die entsprechenden Routinen für eigene Programme enthalten. Interessant: man kann bei der Ramdisk auch mit mehreren geöffneten Dateien arbeiten, da sie einen Filedeskriptor verwendet - Vorbereitung und Vorraussetzung für komplexere Anwenderprogramme.

Allerdings ist die Ramdisk noch nicht sehr gut getestet. Wenn etwas nicht stimmt, kann man mit dem Tool eram.bin debuggen.

[quix]

Gibt es denn schon einen Bereich des RAMs, der für bestimmte immer wieder kehrenden Werte festgelegt wurde? Sozusagen eine Zero-Page mit Systemvariablen? Im Bezug auf künftige Erweiterungen sollte über sowas gesprochen werden. Wo (in welchem Bereich) wird die RAM-Disk abgelegt?

[drohne235]

Systemvariablen werden von der obersten Adresse absteigend verwaltet, die Ramdisk von der Adresse 0 aufsteigend. Das ergibt folgendes einfaches Speichermodell:

0000h Ramdisk
(rbas) Heap
(sysvar) Systemvariablen

Verwendet ein Programm keine Ramdisk, kann in einfacher Form auf den freien Speicher (Heap) zwischen Ramdisk und den Systemvariablen zugegriffen werden. Man verwendet dabei die IOS-Routinen ios.ram_* einfach mit dem Parameter "usrmod". Dadurch entspricht die übergebene Adresse 0 der Adresse der ersten freien Speicherzelle nach der Ramdisk. Entsprechend gibt es auch noch einen Parameter "sysmod", bei welchem Adresse 0 auch der physischen Adresse 0 im eRAM entspricht. In diesem Systemmodus kann man auf die Systemvariablen und die internen Strukturen der Ramdisk zugreifen.

Die Ramdisk selbst wird als verkettet Liste verwaltet und es wird mit den IOS-Routinen ios.sd_* zugegriffen. Die Funktionen entsprechen im wesentlichen normalen Dateioperationen wie open, close, put, get usw.

Eine Regel gibt es aber bei diesem System: Man sollte sich in einem Programm entscheiden ob man Speicher im eRAM über die Ramdisk verwaltet, oder den freien Speicher zwischen Ramdisk und Variablen nutzt. Beide Verfahren zu mischen bringt Probleme, da eine Veränderung der Ramdisk auch den freien Speicher dahinter beeinflußt. Im Klartext nehmen die Routinen für die Ramdisk KEINE rücksicht auf den Speicher und die Daten dahinter - sie werden eventuell einfach überschrieben.

Aber das ist nicht so schlimm, denn die Nutzung ergibt folgende Regeln:

1. Werden die Daten auch noch nach dem Beenden des Programms benötigt, dann verwendet man die Ramdisk.

2. Sind die Daten nach Programmende vogelfrei, kann einfach der Heap verwendet werden.

Mischen sollte man das nicht.

In der IOS-Lib sind wie bei vielen Funktionen noch einige genauere Infos im Quelltext. Ist nicht der richtige Ort, kommt später mal in eine Doku. Ich kopiere das trotzdem mal hier rein:

Code: Alles auswählen

CON ''------------------------------------------------- eRAM/SPEICHERVERWALTUNG
{

Und so funktioniert es: Der Speicher (hier geht es nur um den eRAM!) ist in drei Teile gesplittet:

    1. Ramdisk
    2. Heap
    3. Systemvariablen

Wofür ist das jetzt gut?

Das unkomlizierte Speichermodell: Wenn man in seinem Programm unkompliziert Speicher braucht, der nicht resident
gehalten werden braucht, nutzt man einfach die Routinen ram_* um auf diesen zuzugreifen. Nach dem Beenden
des Programms ist dieser Speicher (Heap) aber dann vogelfrei. Für die Adressierung mit diesen Routinen gibt es
zwei Modis:

     1. sysmod - Hier entspricht die Adresse 0 auch der wirklichen physischen Adresse 0.
     2. usrmod - Hier entspricht die Adresse 0 dem Wert von "rbas" - ist also virtuell.

In einem normalen Programm wird man den usrmod verwenden und nur auf den freien Speicher (Heap) zwischen rbas
und rend zugreifen. Das klingt im ersten Moment kompliziert, ist aber ganz einfach: wenn es einfach sein soll,
arbeite ich im usrmod und bekomme von Adresse 0000..nnnn den Bereich zwischen Ramdisk und den Systemvariablen
(rbas..rend) zu "sehen". Möchte aber ein Systemprogramm zum Beispiel auf die Systemvariablen oder die Internas
der Ramdisk zugreifen, so ist der sysmod gefragt. In diesem Modus wird der eRAM direkt adressiert.

Die Ramdisk: Braucht die Anwendung aber residenten Speicher, so kann man sich einen Speicherblock als
Datei in der Ramdisk erzeugen und auf den Inhalt auch per direkter Adressierung mit rd_rdbyte/rd_wrbyte
zugreifen. In der Kommandozeile Regime ist es dann möglich, per xdir/xload und xsave auf diesen Speicher
bzw. Dateien zuzugreifen.

Ach ja: Mit der Ramdisk ist es auch möglich mehrere Dateien zu öffnen und zu verwenden - rd_open liefert dafür
eine Filenummer fnr, die man bei allen Operationen benutzen muss! :)

Wichtig ist es nur zu verstehen, dass der freie Speicher bei Verwendung der Ramdisk vogelfrei ist,
wenn die Anwendung beendet wird: Speichert ein Programm dort Daten und kehrt zur Kommandozeile zurück,
wird zum Beispiel durch laden oder speichern einer Datei in der Ramdisk die Variable "rbas" und
damit der freie Bereich in seiner Größe verändert ---> unsere Daten im freien Bereich befinden sich also nun
im usrmod an einer anderen Stelle oder sind überschrieben.


  memory-map:

  0000   -->    datei 1                                 'ab adresse 0 liegen die dateien der ramdisk als
                datei 2                                 'verkettete liste. das erste freie byte hinter der
                ...                                     'wird mit der variable "rbas" definiert.
                datei n

  rbas   -->    usermem start                           'zwischen rbas und rend liegt der freie ram.
                ...
  rend   -->    usermen ende

  sysvar -->    systemvariablen                         'ab dieser adresse befinden sich die systemvariablem im eram


  aufbau datei ramdisk:

  1  long       zeiger auf nächste datei                (oder 0 bei letzter datei)
  1  long       datenlänge
  12 byte       dateiname                               8+3-string
  nn byte       daten

  aufbau ftab:

  fnr                           dateinummer

  fnr 0         usermem
  fnr 1..7      dateien

  fix := fnr * FCNT             index in ftab

  ftab[fix+0]   startadresse daten
  ftab[fix+1]   endadresse daten
  ftab[fix+2]   position in datei
}

Edit: Als Einstieg kann man sich den Quelltext regime.spin oder eram.spin anschauen, dort sind ja schon einige Kommandos und Funktionen in Verwendung.