Projekte in GfA-Basic


 

Als ich mir zum ersten Mal das Handbuch von GfA-Basic 2.x durchlas, hatte ich schon die ersten Ideen. Am meisten imponierten mir die Möglichkeiten, mit Zeichenketten zu jonglieren (MID$ rulez ;-)). Deshalb war mein erstes Projekt auch gleich eines, in welchem die Manipulation von Zeichenketten im Vordergrund stand:

Hangman

Ein Nachmittag genügte für das Grundgerüst: Eingaben von der Tastatur mit dem gewählten Wort zu vergleichen und die Buchstaben an die richtige(n) Stelle(n) in einer Reihe von Strichen einzusetzen. Wie ich jeweils Zeit dazu hatte, folgten das Einlesen der Wörter aus einer Datei mit Zufallsauswahl einer voreinstellbaren Anzahl von Wörtern, ein Titelbild, ein Regeltext und – als Krönung des ganzen – eine eigene, wenn auch auflösungsabhängige, grafische Oberfläche, bei der mir die Umstellung auf GfA-Basic 3.0 erheblich geholfen hat.

Nach 1989 habe ich an dem Projekt jedoch nicht mehr weiter gearbeitet. So fehlen bis heute die geplante Umstellung von einer sequentiellen auf eine indexsequentielle Wortdatei sowie die Beseitigung eines Fehlers, der nur sporadisch auftritt, dafür aber die Kiste zum Stehen bringt. Es scheint auch nur in der compilierten Version aufzutreten: Der Atari behauptet dann plötzlich, das Programm würde versuchen, auf einen negativen Feldindex zuzugreifen (TOS 1.04 und 3.06).


 

Was macht man, wenn die Wortsuchspiele in den einschlägigen Rätselheften zu leicht lösbar sind? Na, ganz einfach: Selber produzieren. Aus der Verbindung von mehrdimensionalen Arrays mit den Stringmanipulationen entstand

Wortsuch

Trotz der recht komplizierten Anordnung von mehreren Begriffen kreuz und quer in einer Matrix habe ich das Projekt nicht auf Papier vorgeplant, sondern gleich drauflosgetippt. Das Hauptproblem ist bei diesen Wortsuchgittern, daß sich die Wörter im Gitter sozusagen „begegnen“ können und sogar sollen, wobei die Buchstaben an den Knotenpunkten natürlich gleich sein müssen. Die Begriffe sind dabei von oben nach unten, von links nach rechts und jeweils umgekehrt sowie in alle Richtungen schräg zu verteilen!

Das Programm erlaubt die freie Vorgabe der Gittergröße, der Anzahl der darin zu versteckenden Begriffe und die Eingabe der Begriffe selbst (aus einer Datei oder von der Tastatur). Dann wird in einem zweidimensionalen Array das Gitter aufgebaut, indem zunächst die vorgegebenen Begriffe darin plaziert und dann zufällig ausgewählte Buchstaben drum herum eingetragen werden. Bei der Plazierung der Begriffe arbeite ich ebenfalls mit einer Zufallsauswahl der Koordinaten für den ersten Buchstaben im Gitter und für die Richtung; dann erst wird geprüft, ob der Begriff von der Länge her und in Bezug auf bereits vorhandene Begriffe ins Gitter paßt. Zugegeben, das ist ein ziemliches Brute-Force-Verfahren, aber wenn das Verhältnis Gittergröße zu Wortanzahl vernünftig gewählt wird, dann klappt es eigentlich immer. – Das Ergebnis kann dann abgespeichert und ausgedruckt werden (reiner Textdruck, damit ist kein besonderer Druckertreiber notwendig).


 

Ich hatte mir mehrfach Programme zum Drucken von Einlegern für Musik-Cassetten von anderen AutorInnen angesehen. Nahezu alle liefen darauf hinaus, daß der Einleger auf dem Bildschirm gezeichnet und dann per Hardcopy gedruckt wurde. Dabei paßt aber nicht viel auf so ein Label drauf, und die Qualität ist nicht gerade berauschend, da die (kleineren) Atari-Bildschirmschriften auf Druckern immer noch relativ groß herauskommen und trotzdem nicht gut lesbar sind. Abhilfe schaffte ich, nachdem ich einen HP-LJ II mit dem PostScript-Modul von Pacific Page gekauft hatte, mit

Cassette

Zunächst schrieb ich den Grundaufbau, also die Positionierung sämtlicher Linien und Texte, direkt in PostScript. Dann kam das eigentliche GfA-Basic-Programm sozusagen außen herum, das die Eingabe der Daten, das Umsetzen von Sonderzeichen, das Speichern fertiger Labels in .ps und schließlich den Ausdruck besorgte. Da das PS-Modul von Pacific Page nicht wirklich kompatibel zum PS-Standard ist und das Handbuch damals fehlte, konnte ich jedoch einige Dinge nicht verwirklichen. So habe ich es damals nicht geschafft, dem Teil korrekte Umlaute zu entlocken, und mußte die Umlaute im Programm auflösen.


 

Eine ganz spezielle Anwendung schrieb ich, als ich meinen 260ST an meine Freundin Kathi verschenkte. Sie wurde mit dem Down-Syndrom geboren und ist, obwohl nur einige Monate jünger als ich, intellektuell auf dem Stand eines etwa 4jährigen Kindes. Trotzdem hatte sie mit Begeisterung, wenn auch mit erheblich größerem Zeitaufwand als ein „normales“ Kind, lesen gelernt. Nun sollte das Schreiben dazukommen. Aber sie begriff nicht, was ich von ihr wollte, als ich sie aufforderte, Buchstaben zu malen. Also mußte ich ihr die Buchstaben irgendwie zeigen – eine Tastatur ist dafür doch optimal, oder? Also programmierte ich

Schreibe

Um die Buchstaben schön groß auf dem Bildschirm darstellen zu können, las ich sie aus einem Signum!-Font ein. Das Format war bekannt, und es existierte ein fertiges Programm, um die Buchstaben aus der Fontdatei in einzelne Bilddateien umzuwandeln. Ich wählte eine Datei aus der Fontserie „Schön“, eine besonders gut ausgearbeitete und sehr gut lesbare serifenlose Schrift.

Zunächst ließ ich die Buchstaben in alphabetischer Reihenfolge auf dem Bildschirm erscheinen, und Kathi mußte die entsprechende Taste finden und drücken. Danach erschienen Wörter, ähnlich wie im Hangman, jedoch Buchstabe für Buchstabe zu lösen. Als Hilfe erschien wieder der gerade gewünschte Buchstabe in groß. Die Begriffe, Satzteile und Sätze wählte ich zuerst aus ihrem Lesebuch, sodaß sie anfangs mit bekannten Wörtern üben konnte. Später fügte ich weitere Begriffe und insbesondere ihren Namen dazu und baute das Programm entsprechend ihren Fortschritten aus.

Zu beachten war, daß der 260ST zu dieser Zeit wieder nur noch 512 kB RAM hatte, weil die Speichererweiterung ja nicht mehr einsatzbereit war. Auch mußten Programm, Buchstaben und Begriffslisten auf eine Diskette mit 360 kB passen, denn nur ein solches Laufwerk stand zur Verfügung.


 

Was zunächst als Service im Lokalteil der Seerose gedacht war, entwickelte sich bald zum größeren Projekt: Das Termine-Netz. Ich lagerte die Hierarchie aus der Seerose-Hierarchie aus und erlaubte, diese neue Termin-Hierarchie frei durch die Mailboxen zu routen. Weil ich bald die Übersicht über die vielen Veranstaltungstermine verlor, baute ich eine passende Datenbankstruktur in Phoenix (relationale Datenbanksoftware) auf. Nur: Die Reports, die Phoenix schrieb, waren völlig unformatiert, und außerdem mußten sie ja auch einen ZConnect-Header bekommen, damit sie in die Mailbox eingespielt werden können. Mein letztes großes Projekt in GfA-Basic wurde damit der

TPoster (TerminPoster)

Er besteht eigentlich aus zwei Teilen: Der erste besorgt die Umformatierung der Phoenix-Reportdatei incl. Erstellung der ZConnect-Header, und der zweite Teil ist ein Janus-Mailer, um die Artikel direkt in die Mailbox zu pollen, ohne meine Pointsoftware zu bemühen, also incl. Ansteuerung des Modems.

In der Datenbank kommen viele Angaben immer wieder vor, zum Beispiel die Öffnungszeiten von Museen oder Vorverkaufskassen, die Adressen von Veranstaltungsorten etc. In so einem Fall legte ich in Phoenix eine Untertabelle an und holte mir die Daten per Popup-Menü in die Haupttabelle. Allerdings machten mir mehrzeilige Einträge dabei erhebliche Probleme. Also habe ich in solchen Fällen zusätzlich mit Kürzeln gearbeitet: Ein Prozentzeichen leitet in einigen Feldern ein Kürzel ein. Erst der TerminPoster setzt die Kürzel anhand einer Datei in den vollen Text um. Das reduziert die Größe der Datenbank sowie den Schreibaufwand erheblich, und Änderungen an den Daten werden nur in der Kürzeldatei eingetragen und sind sofort verfügbar.

Besondere Knackpunkte bei der Erstellung der ZConnect-Header waren das EDA: (Erstellungsdatum), die MID: (Message-Id), die ja für mindestens zwei Jahre, besser für „immer“ eindeutig sein muß, und – bei wiederholt geposteten Terminen – ein ERSETZT: (Supersedes). Beim Erstellungsdatum holte ich mir jeweils das aktuelle Systemdatum und baute es in ein ZConnect-konformes Erstellungsdatum um. Dabei achtete ich auf Sommer- bzw. Winterzeit und Tageswechsel und berechnete Datum und Zeit entsprechend dieser Differenzen. – Das Ergebnis benutzte ich dafür auch gleich in der Message-Id, fügte ihr jedoch zusätzlich eine Zahl aus einem Datenbankfeld hinzu, die aussagte, wie oft dieser Termin schon verschickt worden war. Denn regelmäßig wiederkehrende Termine wie die Trainingszeiten von Sportvereinen oder Termine, die lang vor dem Event bekannt waren, habe ich etwa in monatlichen Abständen repostet. – Wenn die Reposting-Zahl größer 0 war, habe ich außerdem den Ersetzt:-Header erstellt. Das Datum des letzten (Re-)Postings wurde aus der Datenbank mitgeliefert, und so habe ich den Ersetzt:-Header aus dem letzten Datum plus Reposting-Anzahl minus 1 rekonstruiert.

Die Ansteuerung des Modems war dann der nächste Schritt: Auf jeden Befehl hin muß die Antwort abgewartet und ausgewertet werden, und auf die Antworten vom Modem muß das Programm richtig reagieren. Mit einer vorliegenden Hayes-Tabelle ist das nicht wirklich schwer, aber eine Menge Schreibarbeit.

Wenn die Verbindung zwischen den Modems steht, müssen schließlich der Login und die Datenübertragung geregelt werden. Ich ließ den TerminPoster nach dem Janus2+-Verfahren pollen, und zwar auf meinen eigenen Pointeintrag in der Seerose. Dabei durfte die Box natürlich keine Daten an den TerminPoster übertragen, die eigentlich für meinen Point bestimmt waren. Daher meldete der TerminPoster seinen Poll mit „Janus2H“ statt mit „Janus“ an (das H steht für „hold your mail“).

Den TerminPoster habe ich von 1996 bis 1998 entwickelt.


Naja, und im Frühjahr 2001 habe ich mal wieder den Interpreter von GfA-Basic bemüht, um eine riesige exportierte Adimens-Datenbank für den Import in Phoenix vorzubereiten. Aber das rechne ich nicht als Projekt.