★ APPLICATIONS ★ DIVERS ★ INPUT (CPC MAGAZIN) ★ |
| Input (CPC Magazin) | Applications Divers |
Nobody is perfect. Das gilt wohl auch für den CPC. Trotz all seiner guten Fähigkeiten, gibt es so manche Schwachstelle. So z. B. den ziemlich verunglückten VAL-Befehl, der auch bei Amstrads neuester Kreation, dem 6128 nicht verbessert wurde. Die eigentliche Aufgabe dieses Befehls besteht darin, den Inhalt oder Wert eines Strings mathematisch zu ermitteln. Im CPC-Basic gibt dieser Befehl jedoch nur den Wert der ersten Zahl eines Strings wieder. Das ist nicht nur ärgerlich, sondern vollkommen unsinnig, da sich dies auch mit LEFT$ oder MID$ erreichen läßt. Mit etwas Aufwand gibt es hier eine Lösung. Die folgende kleine Programmierroutine interpretiert und verarbeitet einen String als Funktionsgleichung mit DEF FN und fügt diese Funktion in eine Basiczeile ein. Hierzu machen wir zunächst einen kleinen Ausflug ins Innenleben des CPC. Die wichtigste Frage hierbei ist WIE und vor allem WO Basiczeilen im RAM abgelegt werden. Zunächst zur Frage WO: Wie Sie vielleicht wissen, liegt der Basicspeicher im Bereich &170-&AB7F, d.h., ab &170 stehen unsere Basic-Programme, dahinter Variablen und Arrays. Die Struktur einer Basiczeile im RAM sieht grundsätzlich folgendermaßen aus: Zeilenlänge (16-Bit) - Zeilennummer (16-Bit) - Zeileninhalt (8-Bit). Allgemein ist zu sagen, daß alle Zeichen einer Zeile als Codes in Form der sog. Tokens gespeichert werden. Hierbei wird zwischen Befehlswörtern (Input, Print etc.), Variablen und sonstigen Zeichen (Texte) unterschieden. Die Token für Textzeichen entsprechen dem ASCII-Code und können im Handbuch nachgeschlagen werden. Befehle dagegen werden nicht etwa als Buchstabenfolge, sondern als Zahl zwischen 128 und 255 codiert. Schon etwas komplizierter wird es bei Variablen oder Zahlen (je nach Typ Integer/Real). Doch nun zu unserem kleinen Programm. Zeile 10 dient als Platzhalter für die Funktionsgleichung. Sie muß als allererste Zeile im Programm stehen und genügend Platz für Funktionsgleichungen reservieren. In Zeile 30 - 90 wird der Funktionsterm als String (z$ und n$) eingegeben. Zeile 120 -160 ist der Kern der ganzen Sache. Die DATAs beinhalten die Token für den Vorspann (DEF FN etc.). Dann werden ab &174 die Zeichen des Funktionsterms als ASCII-Code ein-gepoked. An dieser Stelle taucht auch schon ein weiteres Problem auf. Der Computer interpretiert unseren Funktionsterm in der Form als reine Zeichenkette und nicht als mathematischen Ausdruck, da wie gesagt Variablen besonders codiert werden. Eine Umcodierung würde unser Programm jedoch nur unnötig verlängern. Diese Aufgabe überlassen wir dem Interpreter (Zeile 170), indem wir Zeile 10 editieren. Ab 500 können Sie dann Ihr Hauptprogramm weiterschreiben. In unserem Beispiel wird eine kleine Wertetabelle ausgegeben. In Zeile 560 wird der Anfangszustand in Zeile 10 wieder hergestellt. Diese Zeile sollte am Ende des Hauptprogramms stehen und vor einer Änderung der Funktion durchlaufen werden. Noch ein Hinweis: Wenn Sie mehrere Funktionsgleichungen nacheinander bearbeiten wollen, werden Sie feststellen, daß Zeile 10 nach jedem Durchgang etwas länger wird. Dies hängt ebenfalls mit der unterschiedlichen Codierung zusammen. Als Kontrolle, daß Zeile 10 nicht länger als 255 Zeichen wird, dienen die Zeilen 100 und 110. Auf diese Weise lassen sich selbstverständlich auch andere Dinge programmgesteuert in Zeilen einfügen. Das überlasse ich jedoch Ihrer eigenen Kreativität.
|
