★ APPLICATIONS ★ DISQUE ★ RSX XBOS (CPC MAGAZIN) ★ |
| RSX XBOS (CPC Magazin) | Applications Disque |
Im zweiten Teil unserer Tips für die vortex-Speichererweite-rung geht es um XBOS mit den drei Funktionsteilen RSXBOS, REST3BOS und MOVEBOS. Zunächst eine Bemerkung in eigener Sache. Die Verwaltung von bis zu 512 K RAM zusätzlich durch einen Prozessor, der nur für 64 K ausgelegt ist, bedeutet eine Herausforderung an die Programmentwickler. Die neue Technik muß erst einmal kennengelernt werden. Dabei soll diese Reihe helfen. Die Hinweise setzen zum großen Teil Kenntnisse in Maschinensprache und im CPC-Betriebssystem voraus, es gibt aber auch Hilfsprogramme und Tips, die unmittelbar angewendet werden können. Im ersten Teil (Heft 4/86, Seite 81) wurden verschiedene Einschränkungen im Basic-und Maschinensprachebereich genannt und Abhilfeprogramme versprochen. Ein Teil davon liegt inzwischen vor. Unabhängig von der RAM-Erweiterung einsetzbar sind: SYMB-AFT (zur Veränderung der SYMBOL-Tabelle nach einem MEMORY-Befehl, Heft 4/86, Seite 84) und ROM-Sieb (Heft 4/86, Seite 80). Mit ROM-Sieb kann das Erweite-rungs-ROM ausgeblendet werden, so daß Programme, die nach dem Einbau der RAM-Erweiterung nicht mehr funktionieren, wieder lauffähig sind. Wer bereits die neue ROM-Version mit dem Befehl DISBOS hat, braucht ROM-Sieb für diesen Zweck nicht mehr. XBOS mit drei Funktionsteilen Eine umfassende Ergänzung des vortex-BOS ist das hier vorgestellte XBOS. Es besteht aus den 3 Funktionsteilen RSXBOS, REST3BOS und MOVEBOS. Wer XBOS anwendet, kann allerdings für RAMOPEN nur noch Werte bis 304 (statt 1048) eingeben. RSXBOS erledigt seine Aufgabe im Hintergrund (Laden, Initialisieren und Vergessen). Das einzige Problem besteht darin, geeignete RSX-Programme zu finden bzw. anzupassen. REST3BOS erledigt die Schwerarbeit für eigene Maschinenspracheanwendungen. Wer die Zusatzbänke benutzen will, braucht nun nicht mehr die in den technischen Informationen von vortex angegebene Methode mit dem alternativen Registersatz, sondern kann auf den einfacheren RESTART 3 zurückgreifen. MOVEBOS erschließt neue Einsatzmöglichkeiten für die Datenbänke, die aber erst im nächsten Teil beschrieben werden. Aus dem ersten Teil war noch die Frage der Übergabe von Variablenadressen mit dem erweiterten CALL-Befehl offen geblieben. Dazu gibt es keinen direkten Weg. Der erweiterte CALL löst (im Gegensatz zu den erweiterten PEEK und POKE) den Transport der COMMON-Variabien aus. Diese stehen aber mit Sicherheit in der neuen Bank an einer anderen RAM-Adresse, so daß die ursprünglichen vom Variablenpointer ermittelten Werte wertlos geworden sind. Da es auch keine Möglichkeit gibt festzustellen, ob es sich um Variablenadressen oder direkte Eingabewerte handelt, ist keine Korrektur möglich. Es hilft nur eine indirekte Methode. Der CALL-Befehl muß in derselben Bank stehen, wie die auszuführende Routine. Dann kann er mit dem erweiterten GOSUB aufgerufen werden, und die Variablen werden mit COMMON übergeben, wobei der Variablenpointer in der Zielbank diesmal gültige Adressen ermittelt. Diese Angaben gelten ebenso für RSX-Befehle. Daß RSX-Programme nicht ohne wéiteres zusammen mit BOS (der Bank-Software) eingesetzt werden können, wurde ja bereits berichtet. Es muß entweder ein noch freier RAM-Bereich obérhalb &8000 gefunden werden (das SYMB-AFT-Programm hilft, den Bereich der SYMBOL-Tabelle auszunutzen), oder das nachfolgend beschriebene RSXBOS wird verwendet. Das Betriebssystem des CPC verwaltet Befehiserweiterungen in der Reihenfolge ihrer Initialisierung (beginnend beim Einschalten mit allen Hin-tergrund-ROMs) in einer Kette. Die Adresse eines Daten-blocks der Befehlserweiterung (Befehlsnamen und Sprungadressen) wird in einem 4-Byte-Feld (das von der RSX definiert werden muß) eingetragen. Die jeweils ersten beiden Bytes bilden dabei einen Zeiger auf das nächste RSX-Feld. Der Startwert der Kette steht bei &B1A6 (CPC 664 : &B8D3). Der Befehlsname wird erfreulicherweise (sonst wäre RSXBOS nicht möglich) bei &B196 mit maximal 16 Bytes (CPC 664 : &B8C3) zwischengespeichert. Bei der Suche nach einem Erweiterungsbefehl wird nun die gesamte RSX-Kette bis zu den ROMs abgeklappert. Sollen die Befehlsroutinen in unterschiedlichen Bänken stehen, muß in der richtigen Reihenfolge parallel dazu der jeweils richtige Bankzustand hergestellt werden. RSXBOS erledigt das über eine Tabelle, in der zu jeder RSX die zugehörige Bank eingetragen wird. XBOS muß unmittelbar nach dem BOS-Befehl geladen und mit CALL &9227 initialisiert werden. Das bewirkt neben einer Manipulation der RESTART 3 Routine eine Umleitung der Firmwareeinsprünge ROM WALK, INIT BACK, LOG EXT und FIND COMMAND auf RSXBOS. Die ROM-Routi-nen wurden der Vollständigkeit halber dazugenömmen. SASEM-Fans wissen, daß eine nachträgliche Neuinitialisierung von ROMs möglich ist. Zwar ist es nicht ratsam, den Fioppy-RAM-Bereich in eine X-Bank zu verlegen, aber es mag andere ROMs geben, für die es mal sinnvoll sein kann. RSXBOS übernimmt zum Teil Aufgaben, die sonst vom Betriebssystem-ROM erledigt werden, wobei dann die Tabelleneinträge und die Bankselektion vorgenommen wird. Zusätzlich besteht auch ein Sprung in die ursprünglichen Routinefortsetzungen im Betriebssystem-ROM, so daß RSXBOS nur auf dem 464 läuft und eine 664-Version umfangreiche Anpassungen erfordert. Eine Frage ist auch noch das Zusammenspiel mit dem vortex-BOS, denn es kann auch davon unterschiedliche Versionen geben, die sich eventuell nicht mit XBOS vertragen. Bis zu 49 RSX-Programme Verwendet wird der Speicherbereich &9227 bis &950E. Die einzige Kommunikation mit BOS geschieht über die Adressen &8ECE (BANK STATE, 0 für l-RAM und &20fürX-RAM) und &8ECF (BANK SELECT, 0 bis maximal 8). Die eigene Tabelle wird von &9259 (immer 0) abwärts angelegt. Je nach Anzahl der RSX-Programme wird dann die RSXBOS-Initialisierungsroutine überschrieben, die jedoch qeqen Mehrfachinitialisierungen abgesichert ist. Bis zu 49 RSX-Programme können mit RSXBOS verwaltet werden. Die gerade erreichte Tabeilenadresse wird bei &925E eingetragen, bei &925C wird der Tabellenlaufwert bei der Abarbeitung der RSX-Kette vermerkt. An &925B steht dann noch die ursprüngliche Bank, von der aus der RSX-Befehl aufgerufen wird und bei &925A die Bank, in welcher der Erweiterungsbefehl gefunden wurde. Vom Basic-ROM (oder wenn FIND COMMAND von einem Maschinenspracheprogramm aufgerufen wird von dort aus) wird dann nicht direkt in die RSX-Routine gesprungen, sondern in eine Routine ab &92E6, die für die Befehlsausführung die betreffende Bank einschaltet und danach in die ursprüngliche Bank zurückspringt. COMMON-Variablen werden dabei nicht übertragen, da diese ja auch nicht direkt verwertet werden könnten. Weiter vorne im Text wurde dazu schon eine Methode mit GOSUB beschrieben. Die Bankumschaltung von RSXBOS beschränkt sich auf das Wesentliche. Auch das braucht eine gewisse Zeit. Damit die Abarbeitung der RSX-Kette möglichst nicht zuviel davon verbraucht (am Ende der Kette stehen Floppy-Befehle wie DIR, ERA und REN), sollten RSX-Programme sich nach Möglichkeit auf eine einzige Bank beschränken. Für diese Anwendung eignen sich nur RSX-Programme, die sowieso unterhalb &8000 arbeiten oder die verschiebbar sind, andere Programme müssen entsprechend umgeschrieben werden. Neben den RSX betreibt das Betriebssystem des CPC noch weitere Ketten für Unterbrechungsroutinen. Je "Ereignis” muß ein 9 oder 13 Byte langer Block angelegt werden, der neben Kettenzeiger und Routinenadresse auch Daten über Priorität, Häufigkeit und Zulässigkeit enthält. Eine Buchführung über die jeweils richtige Bank ist bei dem komplexen Ablauf nicht mehr möglich. Wer FRAME FLY, TICKER und FAST TICKER anwenden möchte, kann das bei genügender Maschinenspracheerfahrung mit XBOS doch noch tun. Hauptsache dabei ist, daß der 9/13 Byteblock oberhalb &8000 untergebracht wird. Für die Routine selbst muß eine Banknummer fest ausgewählt und bei der Initialisierung angegeben werden (über die ROM-Auswahl-adresse). Zu bedenken ist, daß die Bankauswahl Zeit braucht, was bei den Interruptereignissen die Funktion beeinträchtigen kann bzw. bei der Auslegung der Routine berücksichtigt werden muß. RSXBOS hat eine eigene Routine für die Bankumschaltung. Das ist einmal ein Unterprogramm bei &9370 (Einsprungbedingung: Banknummer im a-Register; Aussprungbedingung: vorheriger BANK STATE und SELECT im alternativen hl-Register, neuer BANK STATE und SELECT bei &8ECE/F, alles andere unverändert. Interruptvektor wird nach &9365 verbogen, aufrufende Routine muß oberhalb &8000 stehen, damit ein Rücksprung möglich ist). Zum anderen wird dazu die RESTART 3 Routine des CPC verändert, so daß damit von Maschinenprogrammen aus über RESTART 3 mit passendem Selektionsbyte Unterprogramme in einer anderen Bank aufgerufen werden. Dabei sind mehrfach geschachtelte Aufrufe möglich und dürfen auch von unterhalb &8000 aus erfolgen. Für das Selektionsbyte wurde Banknummer plus "Bit 5 gesetzt” gewählt, also &20 bis &28. Da das SASEM-Programm (unter dem ursprünglichen Namen SESAM im CPC Magazin 12/85 abgedruckt, Anwendungen und Ergänzungen in den nachfolgenden Heften) auch über den RESTART 3 geht, kann es diese Erweiterungen ebenfalls benutzen. Der Härtetest geht so: SASEM nach Bank 4 laden und nach Bank 2 umschalten. Dann mit XCALL über den Wert &23 für romnummer eine Routine in Bank 3 aufrufen - kein Problem! Damit sich der Befehl XPEEK ebenso anwenden läßt, muß SASEM geringfügig modifiziert werden. Um den liegenden Bankwechsel zu überstehen, muß die Verschieberoutine selbst nämlich oberhalb &8000 stehen. Das Betriebssystem hat die gleiche (3 Byte lange) Routine an der Adresse &BAA9 (CPC 464). Das veränderte SASEM erzeugt man nun mit: POKE ladeadresse +&16.0: POKE ladeadresse +&64.&A9 : POKE ladeadresse +&65.&BA. Beim CPC 664 ist die entsprechende Adresse &BAA4. Der RESTART 3 Teil von XBOS kann auch für sich verwendet werden. Es handelt sich um den Bereich &9300 bis 937E (Datazeilen 200-240). REST3BOS kann sogar ganz ohne vortex-BOS eingesetzt werden. In diesem Fall erfolgt die Initialisierung mit CALL &9300. Die Anwendung erfolgt dann in Maschinensprache über den RESTART 3 oder in Basic mit Hilfe von SASEM. Mit entsprechenden Maschinensprachekenntnissen kann REST3BOS auch verschoben werden, muß jedoch oberhalb &8000 bleiben. Wenn das vortex-BOS nicht zugeschaltet ist, muß dafür gesorgt werden, daß die Adressen für BANK STATE und SELECT (8ECE/F) am Anfang null enthalten und nicht durch andere Programme überschrieben werden können. Am besten verlegt man diese Adressen dann an einen sicheren (nicht ganz so einsamen) Platz. Eine weitere. Adressenänderung ist für die CPC 664 Besitzer notwendig. Die RESTART 3 Routine ist da um 8 Byte verschoben, so daß die Anzapfung an die Adresse &B9DA gelegt werden muß statt an &B9D2. Für den Interrupt Entry &B939 muß &B941 eingesetzt werden. (Die 664/6128 Anpassung für SASEM steht im CPC Magazin 1/86). Für die ersten Versuche und Anwendungen mit den X-RAM-Bänken ohne vortex-BOS reicht REST3BOS und SASEM (oberhalb &8000). Mit XPEEK können die Bänke mit Programmen (nur Maschinensprache) und Daten geladen werden (Quelladresse oberhalb &8000) und mit XCALL kann man dann die Routine in der jeweiligen Bank aufrufen. Es ist zu bedenken, daß ohne vortex-BOS die X-Bänke zunächst leer sind. Die RESTART-Sprünge, die z. B. zur Ausführung der Firmwareroutinen notwendig sind, existieren noch nicht. REST3BOS erzeugt lediglich den unmittelbar notwendigen Interruptvektor. Es ist daher zu empfehlen, zuerst die RESTART-Vektoren in alle Bänke zu übertragen, z.B. mit: IXPEEK,0,0,&8000,&40 : FOR i=1 to maxbank: |XPEEK,&8000,i+&20,0,&40: NEXT. Um Mißverständnisse zu vermeiden: Die vorstehend genannten Möglichkeiten, nämlich X-Bänke auszuwählen, Daten zu verschieben und Das nächste Mal: MOVEBOS Routinen aufzurufen, gelten ausschließlich für die sogenannten Programmbänke (also unterhalb &8000). Aus gutem Grund muß das Programm, das dies bewerkstelligt, oberhalb &8000 stehen (siehe erster Teil). REST3BOS führt oberhalb &8000 ins l-RAM. Daß es sinnvoll ist, dort Routinen anzuspringen, für die unterhalb &8000 eine bestimmte Bank vorgewählt ist, haben wir schon an der Verschieberoutine &BAA9 gesehen. Nächstes Mal wird MOVEBOS erklärt. Damit ist der Zugriff auf die Datenbänke (oberhalb &8000) möglich. Wer will, kann schon mal vorsichtig den Befehl CALL &93A0, quelle, ziel, laenge, quellbank, zielbank ausprobieren. Gerhard Knapienski , CPC Magazin
|
