★ APPLICATIONS ★ DIVERS ★ Arbeiten mit dem 2. Speicher beim CPC 6128 ★ |
| Bankswap (Computer Schau) | Applications Divers |
Der neue Schneider CPC 6128 wird von Haus aus mit einem Speicher von 128 KByte ausgerüstet. Dieser Speicher ist mit „normalen” Basic-Befehlen nicht zu erreichen. Schneider liefert deshalb das Programm „BANKMAN” mit. Mit dessen Hilfe können dem Bechner fünf BSX-Befehle mitgeteilt werden; dann stehen dem Anwender auch die zusätzlichen 64 KByte zur Verfügung. „BANKMAN“ eignet sich hervorragend zum Arbeiten mit verschiedenen Bildschirmen. Vier Bildschirme können in den zweiten 64 KByte untergebracht werden. „SCREEN-COPY“ und „SCREENSWAP“ ermöglichen schnelles und komfortables Arbeiten unter BASIC. Auch über die anderen RSX-Befehle ist schon genügend geschrieben worden. „BANKREAD“ und „BANKWRITE“ erlauben die Speicherung von Stringvariablen in dem Zusatzspeicher; mit „BANKFIND“ ist sogar eine Suche mit Wildcards vorgesehen. Also, warum sich noch weiter mit den BANK-Operationen auseinandersetzen, wo doch dank „BANKMAN“ alles wunderbar funktioniert? Etwas anderes: Haben Sie schon einmal probiert, den zweiten Speicher komplett zu löschen? Programm 1 soll das für uns machen. Die Aktion läuft relativ schnell, aber leider fehlt noch 1 Byte. Also erhöhen wir „1“ auf 256. Dies wiederum nimmt uns das BASIC übel, denn Stringvariablen dürfen nur maximal 255 Bytes lang sein. Deshalb soll „1“ 128 und „n“ 512 sein; nun werden in 512 Durchgängen die gesamten 65 536 Bytes gelöscht. Aber, haben Sie schon einmal auf die Zeit geachtet? 4,53 Sekunden! Das kann ja noch nicht das Gelbe vom Ei sein. Grund genug, sich doch etwas mit dem Zusatzspeicher und seiner Ansteuerung zu beschäftigen. Um der Theorie auch etwas Würze zu geben, schreiben wir ein Programm, das den Zusatzspeicher ganz löscht und nicht soviel Zeit dafür benötigt. „BANKCLEAR“ heißt es, denn genau das soll es auch nachher machen. Für diejenigen, denen Maschinensprache im Moment noch nicht soviel sagt, haben wir auch einen BASIC-Lader als Programm 2 in diesen Artikel mit aufgenommen. Dieser BASIC-Lader erlaubt, in gewissen Grenzen, „BANKCLEAR“ an verschiedene Startadressen im Speicher anzusiedeln; unerlaubte Adressen werden von ihm ignoriert. Warum sind bestimmte Speicherbereiche für die Ansiedlung von „BANKCLEAR“ nicht erlaubt? Die Antwort wird schon im Handbuch mit einem kurzen Satz gestreift: „Beachten Sie, daß jeder Block aus den zweiten 64 KByte an derselben Adresse abgelegt wird.“ Der Bereich liegt zwischen &4000 und &7FFF. Wird der zweite Speicher angesprochen, so wird im „Hauptspeicher“ ohne Rücksicht auf irgendwelche vorhandenen Daten der Bereich ausgeblendet; stattdessen finden wir an dieser Stelle nun einen Block aus dem zweiten Speicher. Ein Block ist 16 KByte lang, folglich besteht der Zusatzspeicher aus vier Blöcken. Die einzelnen Blöcke haben eine Kennung von 4 bis 7. Diese Kennung muß dem Rechner mitgeteilt werden; so weiß er, welcher Block gerade „up to date“ ist. , ,CALL BANK* ‘ ermöglicht diese Mitteilung, wobei BANK für die Adresse &BD5B steht. Hier wird eine Routine im ROM aufgerufen, die die Bankwahl durch einen „OUT (c),c“-Befehl vornimmt. Die Blockkennung muß sich dabei im Register „A“ befinden. Will man also eine Bank aus dem Zusatzspeicher benutzen, so wird die Kennung nach „A“ geladen und „CALL BANK“ aufgerufen. Der Speicherbereich &4000 bis &7FFF wird nun durch den angewählten Block ersetzt und kann beschrieben werden. Würde unser Programm „BANKCLEAR“ in diesem Bereich liegen, so würde es sich beim ersten „CALL BANK“ selbst ausblenden; ein Absturz des Rechners wäre unvermeidlich. Was macht nun unser kleines Programm? Register „A“ wird mit der ersten Bankkennung geladen; danach wird der erste Block geladen und gelöscht. „A“ wird erhöht und der zweite Block wird gelöscht. Als Zähler fungiert übrigens das Register „C“. Wird in „C“ der Wert 8 erreicht, dann ist es höchste Zeit, das Programm zu verlassen. Zuvor wird der Hauptspeicher aber wieder in seinen Originalzustand versetzt. Dazu bekommt das Register „A“ den Wert 0; ein letztesmal wird „CALL BANK“ aufgerufen. Der Hauptspeicher ist wieder komplett, der Zweitspeicher gelöscht, und das Maschinenprogramm zu Ende. Haben Sie noch Interesse an einem zweiten Programm, das die Bankbefehle erweitert? Dann sollten Sie weiter lesen. Stellen Sie sich vor, Sie haben einen Speicherbereich, den Sie in den Zweitspeicher übertragen möchten. Natürlich können Sie dies mit Hilfe des „BANKMAN“ tun. Wie, das zeigt Programm 3. Übergeben an „BANKWRITE“ wird nun nicht mehr eine Variable, sondern eine Adresse; es ist also nicht nötig, den Speicherinhalt erst einer Variablen „aufzuhalsen“. Umgekehrt funktioniert es bei „BANKREAD“ natürlich genauso; die Daten aus dem zweiten Speicher werden direkt an die Adresse im Hauptspeicher geladen. Interessanter wird es bei einem „BANKSWAP“-Befehl. Hierbei wird ein Speicherbereich mit einem anderen Speicher vertauscht. Im Programm 4 wird gezeigt, wie beim „BANKMAN“ so etwas realisiert werden kann. Getauscht werden sollen, der Einfachheit halber, zwei 16-KByte-Bereiche. Die Bereichsgrenzen sind frei wählbar. Leider können wir den eingebauten „SCREENSWAP“-Befehl nicht benutzen; wir müßten jedesmal die Daten in den Bildschirmspeicher laden und anschließend wieder zurückholen. Das ist nicht nur sehr zeitaufwendig, sondern es sieht auch merkwürdig aus. Unter Maschinensprache geht der Vorgang wieder erheblich schneller. Das Programm benötigt zu allererst zwei Zwischenspeicher. Aus dem zuvor gelesenen wissen wir, daß diese Speicher oberhalb von &7FFF liegen müssen; daher werden Sie an das Ende des Programms gehängt. „BANKSWAP“ kann also wiederum nur im Bereich über &7FFF abgelegt werden; der BASIC-Lader berücksichtigt das. Das Programm gliedert sich grob in drei Teile. Teil 1 beginnt bei BANKSW. Hier wird kontrolliert, ob die angewählte Bank überhaupt zulässig ist. Dabei steht eine „0“ für die Bank im Hauptspeicher; „1“ bis „4“ bezeichnen die Banken im Zusatzspeicher. Das Subprogramm bei BANKS1 berechnet die korrekten Kennungen. Bei BANKS2 beginnt dann der eigentliche SWAP-Vorgang. Zuerst wird ein Speicherteilbereich im ZWSP1 gesichert. Dann wird der Hauptspeicher ausgeblendet; die Daten aus dem Zusatzspeicher werden nach ZWSP geladen (entspricht „BANKREAD“). Anschließend wird der Inhalt von ZWSP1 an die entsprechende Adresse im Zusatzspecher gesandt („BANKWRITE“). Der Hauptspeicher wird min eingeblendet; der Inhalt von ZWSP kommt an seinen Platz. Dieser Vorgang wiederholt sich bei unserem Beispiel 64mal; danach sind zwei 16-KByte-Blöcke ausgetauscht. Teil 3 beginnt bei BANKS0. Bisher wurde nur die Bank aus dem Hauptspeicher, z. B. Bank 3, wieder an ihren Platz im Zusatzspeicher geschickt. Jetzt soll aber auch eine neue Bank, z. B. Bank 4, in den Arbeitsspeicher geladen werden. Diese neue Bank muß bei dem Aufruf von „BANKSWAP“ mit übergeben werden. Der Vorgang beginnt von neuem: Der Arbeitsspeicher (Bank 0) wird in den Zusatzspeicher geladen; Bank 4 nimmt den Platz von Bank 0 ein. Worin liegt der Vorteil bei dem doppelten Bankgeschiebe? Schneller ginge es, wenn man den 16-KByte-Block im Hauptspeicher als reinen Arbeitsspeicher betrachten würde. Dann bräuchten die Bänke aus dem Zusatzspeicher nur dorthin geladen zu werden; einfache Blockladebefehle des Z80 würden genügen. Leider stehen dem Anwender dann aber nur 64 KByte zur Verfügung; mit unserem „BANKSWAP“ liegen wir aber bei 80 KByte. Grund genug, wie ich meine, dieses etwas aufwendigere Verfahren zu benutzen. „BANKSWAP“ wird mit einem CALL-Befehl aufgerufen. Dabei muß zu Beginn die Adresse von Bank 0 im Hauptspeicher angegeben werden. Mit „CALL &9F00, 0, &3000“ wird der Beginn von Bank 0 auf &3000 festgelegt; Bank 0 umfaßt also in diesem Beispiel den Speicherbereich &5000 bis &6FFF, gleichzeitig finden wir auch unser „BANKCLEAR“ wieder; es wird ausgeführt, wenn zwei Parameter an das Programm übergeben werden. So wird der gesamte Zusatzspeicher gelöscht. „CALL &9F00,2“: hiermit wird in den Arbeitsspeicher die Bank 2 geladen. Die bisherige Bank 0 wird unter der Adresse von Bank 2 gespeichert. Ein nochmaliger Aufruf von Bank 2 würde außer Zeitverlust nichts ändern. Programm 5 enthält den BASIC-Lader für BANK SWAP. Das korrekte Programm wird automatisch gesichert und dann aufgerufen. Denken Sie daran, daß BANKSWAP zuerst die Bereichsgrenzen des Speichers mitgeteilt werden müssen. Dabei wird immer der gesamte Speicher gelöscht. In Programm 5 wird diese Bedingung vor dem ersten Aufruf von BANKSWAP erfüllt. Natürlich können Sie auch diesen Befehl wieder als RSX-Befehl in Ihre Programme einbinden. Das Assemblerlisting kann Ihnen da behilflich sein.
|
