KC-News 3/1995

Diskussion zu ZAS

von Mario Leubner

Nachdem ich in den letzten KC-News meine neue Steuerschleife ZAS veröffentlicht habe, gab es Beschwerden über die Art und Weise, wie ich die Steuerschleife erweitert habe. Besonders Uwe Felgentreu hat Probleme mit seinen Programmen bekommen. Da es sich hier um Grundsatzentscheidungen handelt, will ich meinen Standpunkt dazu darlegen und zur Diskussion auffordern:

ZAS ist mit den Gedanken entstanden, allen KC-Usern ein allgemein nutzbares Paket an universell verwendbaren Routinen zur Verfügung zu stellen. Ich wollte mit ZAS auch anderen die Möglichkeiten erweiterter Zeichensätze, inverser Schrift, Fenstertechnik, Grafik und Farbe auf einfache Weise zugänglich machen.

Da ich der Meinung bin, daß nicht jeder über die erforderlichen Kenntnisse verfügt, solche "Treibersoftware" selbst zu schreiben, habe ich eine Form gewählt, die an das Konzept der Mühlhäuser Entwickler anknüpft und dazu kompatibel ist. Alle vorhandenen Programme sind weiterhin lauffähig und Erweiterungen sind jederzeit möglich. Warum sollen solche von vielen Programmen allgemein nutzbaren Funktionen nicht in einen "Gerätetreiber" wie ZAS laufen?

Jeder müßte sonst seine eigenen Routinen zusammenstellen und jedesmal neu in das Grundgerät übertragen. Dabei werden die Anwenderprogramme unnötig lang, was Diskettenkapazität, doppelten Programmieraufwand und zu kleinen TPA-Speicher bedeutet.

Die Methode, mit ZAS die Steuerschleife komplett zu ersetzen hat mehrere Gründe:

• Die Fülle an neuen Funktionen lies eine Einbindung nach dem Prinzip der Umbiegung von Sprungadressen nicht mehr zu. Ich hätte so viele Sprünge einbauen müssen, daß fast zwei Steuerschleifen im Grundgerät vorhanden wären, die alte und für alle ersetzten Funktionen eine ersetzte. Von der Verschwendung des ohnehin knappen Speichers im Grundgerät mal abgesehen - was wäre, wenn dann jemand den OTIR-Befehl von ESC-R "umbiegt" und mein ESC-R vorher abgefangen wurde? Ich bin der Meinung, dies ist nicht der richtige Weg!
  
  
• Wenn ich Funktionen in Programme einbinden will, von denen ich nicht genau weiß, ob es schon verschiedene Versionen gibt, kann ich nicht einfach irgendwo Sprünge einbauen! Wer garantiert mir, daß Mühlhausen nicht schon im Laufe der Zeit verschiedene EPROM's in die D004-Basis eigebaut hat? Mein D004 meldet sich bei JUMP FC FF mit Version 2.0, man kann also davon ausgehen, daß es mindestens schon mal eine Version 1.0 gegeben hat. Mit der kompletten Ersetzung bin ich auf der sicheren Seite. Ich gehe lediglich davon aus, daß die Funktionen zum Übertragen von Daten funktionieren.

Uwe Felgentreu schreibt "Der RAM von 400h bis 1100h ist TABU!", ich gehe noch einen Schritt weiter: von 400h bis 2000h hat kein Programm außer der Steuerschleife (mit ein paar Ausnahmen, siehe unten) etwas zu suchen! Dort läuft die Steuerschleife, egal welche! Schon weil keiner weiß, ob alle in Mühlhausen gebauten Floppys den selben EPROM haben, darf keine Modifikation der Steuerschleife vorgenommen werden.

Im oben genannten Bereich dürfen also weder Bytes umgepokt, noch Sprungadressen verändert werden! Wenn eine andere Steuerschleife benötigt wird, dann nur komplett ersetzen! Den Quelltext zu ZAS und dem entsprechenden Ladeprogramm gebe ich bei Interesse gern weiter, damit jeder, der sich dazu in der Lage fühlt, seine eigenen Treiber einbinden kann. Natürlich verlange ich, daß bestehende Funktionen erhalten bleiben, ansonsten bewegen wir uns wirklich "mit Lichtgeschwindigkeit auf einen inkompatiblen KC85 zu."

Nun zu den Ausnahmen, die eine Modifikation zulassen:

• Die Tastaturtabelle mit 3*64 Tastencodes. Auf der Adresse FFB4H (KTABAD) im Koppel-RAM steht die Adresse dieser Tabelle, genutzt z.B. von den Programmen COMPUMOD.COM und TYPEMOD.COM. Auch hierbei ist es erforderlich, zuerst die Lage der Tastaturtabelle zu ermitteln, ehe die neuen Codes übertragen werden dürfen! (wegen der verschiedenen Versionen)
  
  
• Die ESC-Tabelle mit 3*63 Bytes. Auf der Adresse FFB7H (ESCTAB) im Koppel-RAM steht die Adresse dieser Tabelle, die sich aus einem Byte für die Länge und einem Wort für die Adresse jeder Routine zusammensetzt. Mit den möglichen Funktionen ESC-41H bis ESC-7FH sind es genau 63 Einträge in dieser Tabelle. Wird eine spezielle Funktion gebraucht, kann einfach die eigene Routine in den RAM (z.B. RAM4) kopiert und in der ESC-Tabelle die Werte und die Parameteranzahl eingetragen werden und schon ist die Funktion eingebunden. Vorbildliche Programmierer tragen mindestens am Programmende die alten Werte wieder ein.

Tip! Aus der Adresse ESCTAB läßt sich übrigens auch das erste freie Byte der Steuerschleife ermitteln. Es ist zwar sehr riskant, da nirgends dokumentiert, aber die Steuerschleife (auch ZAS) endet mit der ESC-Tabelle. Addiert man also 189 Bytes zur Anfangsadresse der ESC-Tabelle, weiß man wie lang die Steuerschleife ist.

Uwe's Argumente zur Unverträglichkeit von ZAS mit anderen Programmen halten einer genaueren Betrachtung auch nicht Stand. So enthält ZAS 1.0 mit ESC-Y und ESC-Z genau die Funktionen, die er durch sein "Umpoken" von ESC-R erzeugt hat.

Die Idee zu ESC-Y und ESC-Z stammt übrigens aus Turbo-PASCAL-Routinen, die ich für Torsten Harder für "CyLogic" ZAS-tauglich gemacht habe. Und wo ist der Rest der WINDOW's-Bibliothek für Turbo-PASCAL? Wenn die Quellen mal veröffentlicht würden, wird sich sicher eine saubere Lösung im Zusammenspiel mit ZAS finden. Vielleicht gibt es sogar noch ein paar nützliche Erweiterungen von ZAS?

Mein Angebot lautet nach wie vor:

Her mit weiteren Ideen für ZAS. Der Speicher bis 2000H und der Funktionsumfang bis ESC-7fh kann ruhig ausgeschöpft werden. Und Versionsnummern für ZAS gibt es auch noch genügend! Wer unbedingt Wert auf eine Originalsteuerschleife legt, um bestimmte Aufgaben zu realisieren, der muß eben ohne ZAS arbeiten.

Ich zwinge ZAS niemandem auf! Auch habe ich mir schon überlegt, ob es sinnvoll wäre, eine Option "ZAS /OFF" beim Aufruf einzuführen, dann könnte auf einfache Weise zur Originalsteuerschleife zurückgekehrt werden.

Übrigens habe ich mit der angeblich hohen "Wahrscheinlichkeit, daß dann jemand genau diese Bytes umpoken will", bisher nur Programme von Uwe Felgentreu aufgespürt. Daß es auch anders geht, beweist sein sehr gutes Programm KCFORMAT.COM von der letzten KC-News-Diskette, das zwar für ein Formatierungsprogramm mit 26 KByte recht lang ist, dafür aber auch zwei Programme (das grafische und das mit der Kommandozeile) vereint. Ein Lob dem Programmierer!