★ APPLICATIONS ★ DISQUE ★ Neue Tips und Routinen zur vortex-Speichererweiterung ★ |
| RSX MINIBOS (CPC Magazin) | Applications Disque |
Im Handbuch der vortex-Speichererweiterung fehlt leider der Hinweis, daß OPENIN/OPENOUT-Dateien bei jedem Bankwechsel zerstört werden. Das gilt auch für indirekte Bankzugriffe mit den erweiterten PEEK- und POKE-Befeh-Ien. Diese an sich sinnvolle Sicherheitsmaßnahme verhindert aber auch die Verwendung von Daten aus anderen Bänken für OPENIN und OPENOUT. Falls dies aber für ein Programm notwendig ist, müssen die Daten vorher mit CLOSEIN bzw. CLOSEOUT gerettet werden. Günstiger ist ein Eingriff in die Cassettenvektoren (CAS OUT ABANDON und CAS IN ABANDON) mit POKE &BC7D, &C9: POKE &BC92, &C9. Die Dateien dürfen dann nach einem Bankwechsel auf keinen Fall angesprochen werden, da sie in der anderen Bank ja nicht existieren. Die Cassettenvektoren (uhd damit die Schutzfunktion) werden wiederhergestellt mit den Befehlen TAPE oder DISC, wenn ein Diskettenlaufwerk angeschlossen ist, ansonsten mit POKE &BC7D, &CF: POKE &BC92, &CF. Neue Einsatzbereiche für die Datenspeicherung mit der vortex-RAM-Erweiterung ergeben sich mit der MOVEBOS-Routine, die als Teil des XBOS-Progammes in der letzten Ausgabe des CPC Magazins abgedruckt war. MOVEBOS verschiebt beliebige Speicherbereiche, wobei automatisch der jeweils günstigste Weg von Bank zu Bank gesucht wird. Im ersten Teil dieser Reihe_wurden JnföfnTationen zu den Unterschieden zwischen I-RAM und X-RAM und den beiden Adressbereichenj 0 - &7FFF und &8000 - &FFFF gegeben. Daten können in der Regel nicht direkt übertragen werden, sondern müssen portionsweise über Zwischenpuffer im l-RAM (Bank 0) weitergegeben werden. Das vortex-BOS benutzt diese Technik für die relative RAM-Datei. MOVE-BOS arbeitet ähnlich, unterscheidet jedoch die verschiedenen vorkommenden Fälle. Zusätzlich werden schnellere Routinen für die Bankumschaltung verwendet. MOVEBOS benutzt die selben Puffer wie das vortex-BOS und zwar mit 128 Byte Länge ab &7F80 (Lowbuffer) und &90F7 (Highbuffer). Der Zeitaufwand für den Datentransport richtet sich danach, wieviele Puffer durchlaufen werden müssen. Ais Anhaltspunkt können die Screen-Befehle dienen, die ohne Puffer auskommen. Die Übertragung von 16 K kann 2 oder 3 mal solange brauchen, plus etwas Zeit für die Bankumschaltung. Das ist auch für Bildschirmwechsel schnell genug. Eine wichtige Anwendung ist deshalb die Speicherung von Bildschirminhalten ohne die Einschränkung mit VIDEO.ON. MOVEBOS wird über den Befehl CALL &93A0, quelle, ziel, laenge, quellbank, zielbank aufgerufen. Mit quelle, ziel und laenge müssen genaue Speicheradressen und die Länge des Bereiches angegeben werden. Für das Bildschirm-RAM ist die Adresse &C000 und die Länge &4000. Zum Speichern eignen sich in den Datenbänken die Adressen &8000 und &C000. So kann man in Bank 1 z. B. 2 Bilder unterbringen: CALL &93A0, &C000, &8000, &4000,0,1 und CALL &93A0, &C000, &C000, &4000, 0,1. Und so werden die Bilder wieder sichtbar: CALL &93A0, &8000, &C000, &4000,1,0 und CALL &93A0, &C000, &C000, &4000,1,0. Auch Programmbänke kann man für die Bildspeicherung benutzen, dürfen dann jedoch nicht mehr für Programme verwendet werden. Der Bereich 0 - &3F muß aber für das Betriebssystem bestehen bleiben und darf nicht überschrieben werden. Wenn der Bildschirm nicht gescrollt wurde (für Grafikanwendungen sowieso Voraussetzung), kann der Bildschirmspeicher etwas gekürzt werden (um 48 Bytes), so daß auch in die Programmbänke 2 Bilder passen: CALL &93A0, &C000, &40, &3FE0, 0, 1 und CALL &93A0, &C000, &4020, &3FE0, 0, 1, und zurück: CALL &93A0, &40, &C000, &3FE0,1,0 und CALL &93A0, &4020, &C000, &3FE0,1,0. In diesem Fall geht es genauso schnell wie mit den SCREEN-Befehlen. Es ist keine Frage, daß mit MOVEBOS Maschinenprogramme und Binärfiles in den Datenbänken gespeichert werden können; es müssen nur RAM-Adresse und Länge bekannt sein. Da mit dem Variablenpointer auch die Adressen von Basicvariablen ermittelt werden können, besteht die weitere Anwendungsmöglichkeit, Variableninhalte und sogar ganze Variablenfelder zu speichern. Zu beachten ist dabei, daß der Befehl, der den Variablenpointer verwendet, in derselben Bank stehen muß wie die Variable. Nehmen wir an, es sei ein Feld von Real-Variablen mit DIM a(100) definiert. @a(0) ist dann die Anfangsadresse des Feldes. Die Gesamtlänge ist dann bei 5 Bytes pro Realwert komplett 505 Bytes. Mit diesen Informationen können solche Felder ganz oder, wenn man sich die Adressen der jeweiligen Variablen ausgeben läßt, auch in Teilen abgespeichert werden. MOVEBOS überprüft nicht, ob die eingegebenen1 Werte sinnvoll sind. Mit ungünstigen Werten können Programmbereiche überschrieben werden, mit dem Effekt, daß der Rechner abstürzt. Das XBOS-Programm wurde für den CPC 464 entwik-kelt. Eine 664-Version scheitert vorläufig daran, daß es noch kein BOS-ROM für den 664 gibt. Aus den Funktionsteilen, die auch ohne vortex-BOS arbeiten, wurde ein MINI-BOS erstellt, das sich gleichermaßen für CPC 464 und 664 eignet. Es enthält REST3BOS und MOVEBOS. Das Zusatz-RAM kann damit für Daten, die Programmbänke eingeschränkt auch für Maschinenprogramme verwendet werden. MINIBOS erzeugt den Lowbuffer mit zugehöriger Routine selbst. Der Highbuffer ist in den Bereich hinter MINIBOS (&9580) verlegt. Die wichtigen Adressen für BANK STATE und SELECT liegen nun bei &930E/F, so daß MINIBOS in allen Details unabhänig geworden ist. MINIBOS liefert 2 RSX-Befehle: BMOVE, der CALL &93A0 ersetzt und die gleiche Funktion hat, und BCALLfür den Aufruf von Maschinenprogrammen: |BMOVE, quelle, ziel, laenge, quellbank, zielbank Dabei ist zu bedenken, daß für solche Programme die Restartvektoren (0 bis &3F) erst in die X-Bänke übertragen werden müssen (siehe letztes Heft). MINIBOS muß mit CALL &9300 initialisiert werden. Es besteht eine Absicherung gegen Mehrfachinitialisierungen. Falls der Lowbuffer zerstört wird, kann er mit CALL &9300 wiederherge stellt werden. Der Lowbuffer muß für die Ausführung von BMOVE unbedingt bestehen. MINIBOS kann an einer anderen Adresse als &9300 betrieben werden. Eine Anpassung geschieht in diesem Fall mit dem Basicladeprogramm. Dort kann in Zeile 10 ein anderes Highbyte für die Arbeitsadresse ab &80 aufwärts eingesetzt werden. Insbesondere der MOVEBOS-Teil stellt einen Kompromiß dar. Zwar ist jetzt jeder Zusatz-RAM-Bereich erreichbar, aber die Eingabe über die RAM-Adressen ist für viele Anwendungen zu unbequem. Es ist vorstellbar, auf den Grundroutinen eine Befehlserweiterung aufzubauen, die vergleichbar zu den SCREEN- und RAM-Datei-Befehlen etwas in der Art von DATA.IN und DATA.OUT, SAVE und LOAD enthält, um den Datentransport zu managen. Ein Problem dabei ist der notwendige Speicherplatz für solche Routinen, am deutlichsten bei XBOS zu sehen, das mit dem vortex-BOS um jedes Byte kämpft. Es ist ein erstaunlicher Umstand, wenn eine Speichererweiterung dazu führen kann, daß Speicherplatz knapp wird und unter Umständen nicht ausreicht. Das liegt daran, daß die RAM-Bereiche für Betriebssystem, Basic, Floppy und natürlich die Bank-Schalt-Software immer aktiv sein müssen, so daß dafür nur der Bereich ab &8000 im l-RAM in Frage kommt. Der einzige Ausweg für eine komfortablere BOS-Version besteht also darin, sie im ROM unterzubringen. Das bisherige vortex-ROM hat diese Möglichkeiten fast noch nicht genutzt. Es wird für die meisten BOS-Routinen nur als Speicher benutzt, zur Ausführung werden diese unverändert ins RAM übertragen, und man könnte sie ebensogut von Cassette laden. Wenn man die Routinen derart in's ROM bringt, daß sie dort auch ausgeführt werden, können zusätzliche Funktionen verwirklicht und im Bereich ab &8000 wieder der nötige Platz für andere Anwendungen geschaffen werden. Inzwischen hat vortex eine neue ROM-Version angekündigt. Man darf auf das neue BOS gespannt sein. Ein Grundproblem ist, daß niemals für alle Funktionen, bei denen RAM-Adressen aus verschiedensten (unkontrollierbaren) Anlässen angesprungen werden, eine Sicherheitsmaßnahme oder die richtige Bankselektion erreicht werden kann. In Basic betrifft dies Befehle wie ON ERROR, ON BREAK, EVERY, AFTER und z. B. den Variablenpointer. Im Maschinensprachebereich sind es die Unterbrechungsereignisse, aber (wer denkt schon daran) auch ungünstig verbogene Betriebssystemvektoren. Für Befehlserweiterungen hat das in XBOS enthaltene RSXBOS eine Lösung gezeigt. Für andere Probleme in Maschinensprache ist REST3BOS vermutlich ideal. Wir werden sehen, welche Lösungswege das neue vortex-BOS anbietet. Solange müssen wir uns noch mit dem alten BOS beschäftigen. Gerhard Knapienski, CPC Magazin
|
