VLIR und Overlay-Module

Jedes größere GEOS-Programm ist in einer sog. VLIR-Struktur gespeichert. Ohne nun groß auf das Diskettenformat dieser Struktur einzugehen, dürfte der Sinn jedem GEOS-User bekannt sein:

Viele Programme sind so groß, daß sie nicht in einem Rutsch in den Speicher passen. Daher wird immer erst ein Hauptteil, der für die Steuerung und Abfrage benötigt wird, geladen und dann je nach Befehl des Nutzer ein Programmteil, der in der Regel mit "Modul" bezeichnet wird, nachgeladen, er enthält dann auch die nötigen Befehle.
Unter GeoCom ist Speicher knapp. Es stehen für Programm, Variablen und Konstanten nur 14 kByte Speicher zur Verfügung, wenn der Hintergrundspeicher ab $6000 als ein solcher genutzt werden soll. Zwar würde sich unser Programm, die Würfelsimulation, auch mit einem Schlag im Speicher holen lassen, doch soll hier einmal gezeigt werden, wie eine solche Aufteilung auf verschiedene Module möglich ist.

Dazu gibt es im wesentlichen drei Befehle: GLOBALEND, OVERLAYMOD und GOTOMOD. Sie haben im einzelnen folgende Aufgaben:
GLOBALEND ist eine Endemarke. Alles was vor diesem Befehl steht, ist ständig im Speicher. Wenn man sich nicht gerade irgendwelcher Tricks bedient, handelt es sich also um Menü-, Tastatur-, Bildschirmbereich- und andere Abfragen sowie das Aufrufen der notwendigen Ansprungmodule.
OVERLAYMOD kennzeichnet das Ende eines Moduls, daß bei Bedarf nachgeladen wird. Diese Ladetechnik nennt man Overlaytechnik, daher auch der Name dieses Befehls. Das letzte Modul eines Programms braucht diesen Befehl nicht zu enthalten, da OVERLAYMOD auch gleich einen Datensatz für den jeweils nächsten Programmblock auf der Diskette vorbereitet.
GOTOMOD schließlich ist ein Sprungbefehl zum Nachladen eines Overlaymoduls.

Die Verwendung der einzelnen Befehle werde ich weiter unten erläutern. Zuvor noch ein paar Besonderheiten:

1. Nach dem Start eines GeoCom-Programms mit VLIR-Struktur wird zunächst das Modul 0 geladen, dies ist das erste Modul nach dem residenten Hauptteil. Hier kann man also am besten alle Variablen initialisieren und den Bildschirm aufbauen, damit das Hauptprogramm davon entlastet wird. Dieses Modul braucht unbedingt einen Sprungbefehl GOTO zu einer Stelle in den globalen Teil.
2. Jedes GeoCom-Programm ist als VLIR-Datei gespeichert, auch wenn es nur eine, sequentielle Struktur aufweist. Ein Datensatz enthält dann das sequentielle Programm, ein zweiter die GeoCom-Grundroutinen.
3. Angenommen, es werden zwei Overlaymodule (0 und 1) verwendet. Der Compiler zeigt in der Statuszeile bei "Mod..:" nun aber "3" an. Das dritte Modul ist dabei das Hauptprogramm, der residente Teil. Auf der Diskette wiederum sind vier Datensätze, hinzu kommt noch die GeoCom-Routinenbibliothek. Also: Nicht verwirren lassen.

Doch nun zu unserem Statistikprogramm. Der globale Teil soll die Menüabfrage, die Tastaturroutine und die Hilfsmittelverwaltung enthalten. Bei der Menüabfrage sollen jedoch nur noch Sprungadressen zu den jeweiligen Nachlademodule stehen. Dies sieht im einzelnen so aus (Auslassungen sind durch (...) gekennzeichnet und bereits aus den anderen Teilen bekannt):

   (...)
   BYTEVAR schongewürfelt, pos, action
   (...)
   ROW 8 STRVAR16; tools
   (drei Zeilen entfallen)
   LABEL hauptprogramm, keyrout
   (eine Zeile entfällt)
   LABEL r_info, r_sim, r_load, r_save, r_print, r_end
   (...)
   @hauptprogramm
   (...)
   @r_info
   (...)
   @r_sim
   FIRSTMENU
   action=1
   GOTOMOD 1
   RETURN
   @r_load
   FIRSTMENU
   GOTOMOD 2
   RETURN
   @r_save
   FIRSTMENU
   GOTOMOD 3
   RETURN
   @r_print
   FIRSTMENU
   action=2
   GOTOMOD 1
   RETURN
   @r_end
   (...)
   @keyrout
   (...)
   @hilfsmittel
   (...)
   GLOBALEND

Modul 0 werden wir für die Programminitialisierung verwenden. Modul 1 enthält die Routinen zur Simulation und zum Drucken, Modul 2 wird zusammen mit Modul 3 erst in der nächsten Folge ergänzt werden, hier kommen die Diskettenbefehle hinein.
Die nachträgliche Umgestaltung erweist sich als wenig übersichtlich und wird in der Praxis auch nicht so gemacht. Man wird zunächst ein Konzept und eine Gliederung entwerfen, dann von Anfang an die Module entsprechend einrichten. Dies war jedoch im Rahmen des Workshops nicht möglich, da zunächst einmal einige Grundlagen behandelt werden sollten.

Wofür ist die neue Variable "action" da?
Sie soll eine Merkvariabale sein, welcher Befehl in Modul 1 denn ausgeführt werden soll, Simulation oder Druck. Natürlich könnte man auch für jede Routine ein eigenes Modul verwenden, nur wird sich weiter unten noch zeigen, warum dies so sinnvoller ist.

Der Hauptteil wäre damit abgeschlossen, wenden wir uns also dem Modul 0 - der Programminitialisierung - zu:
Hier muß zunächst die Variable "last" deklariert werden. Sie stand mal im Hauptteil, doch wird sie dort nicht mehr gebraucht. Dann wird das GEOS-Menü eingerichtet (dies sind die ersten vier Zeilen des Programmblocks) und noch ein paar Variablen initialisiert - also nichts neues, nur bekanntes in anderer Form:

   BYTEVAR last
   FCLASS "",5,8,tools
   last=backbyte
   POKE ((ADR m_geos)+1),(((9 - last)*14)+15)
   POKE ((ADR m_geos)+6),((9 - last)OR%10000000)
   (würfelzahl<0>)=0
   (...u.s.w. bis Index "5" ...)
   gesamtwert=0
   schongewürfelt=0
   GOTO hauptprogramm
   OVERLAYMOD

"GOTO hauptprogramm" springt in die Programmschleife, die alles steuert, und OVERLAYMOD beendet diesen Teil. Also folgt nun Modul 1:
Hier begegnen uns zunächst ein paar bekannte Variablen- und Labeldefinitionen, dann wird der "action"-Wert ausgewertet und es folgen die bekannten Routinen:

   BYTEVAR zähler, würfelwert, zufallszahl
   INTVAR AT $850a; random
   ROW 640 BYTEVAR datenpuffer
   ROW 1920 BYTEVAR treiberpuffer
   LABEL simulation, drucken, zahlenreihe_erzeugen,
         grafik_aufbauen, würfel_darstellen
   IF (action==1) THEN : GOTO simulation : ENDIF
   IF (action==2) THEN : GOTO drucken : ENDIF
   @simulation
   (... hier steht der Programmcode aus @r_sim nach dem
        Befehl FIRSTMENU, siehe GUP 38...)
   RETURN
   @drucken
   (... hier steht der Programmcode aus @r_print nach
        dem Befehl FIRSTMENU, siehe GUP 38...)
   RETURN
   @zahlenreihe_erzeugen
   (...)
   @grafik_aufbauen
   (...)
   @würfel_darstellen
   (...)
   OVERLAYMOD

Nun wird deutlich, warum die Simulation und das Drucken in ein Modul kommen: Beide brauchen die gleichen Grafikunterroutinen. Natürlich könnte man nun den Abschnitt @grafik_aufbauen auch zweimal implementieren, doch wäre dies Verschwendung von Diskettenspeicherplatz. Auch könnte sich dieses Label im Hauptprogramm befinden, nur ist es ratsam, jenes immer so kurz wie möglich zu gestalten.
Profis werden nicht für jeden Befehl im Hauptteil ein Label definieren, sondern die Ansprungadresse durch die Menüvariablen von GeoCom berechnen. Dies würde hier jedoch zu weit führen.

Eine kurze Vorbereitung für den nächsten Teil treffen wir noch, dann ist für diese Ausgabe alles fertig:

   Overlaymodul 2 -
       Laden von alten Daten
   RETURN
   OVERLAYMOD
   Overlaymodul 3 -
       Speichern von Datenreihen
   RETURN

Durch diese Befehlsfolge haben wir noch die Module 1 und 3 auf Diskette vorbereitet. So das war's erstmal. Viel Spaß beim Programmieren.
Übrigens: Die Workshop-Disk ist wieder aktualisiert.

Olaf Dzwiza