ABBUC Magazin 044

 

Impressum

1996 Atari Bit Byter User Club e.V. c/o Wolfgang Burger, Wieschenbeck 45 D-45699 Herten, ( +49 2366 39623 FAX +49 2366 39623) eMail: 0236639623-1@t-online.de

Das Atari Bit Byter User Club Magazin. erscheint 1/4 jährlich. Jeweils 1/2 jährlich erscheint das Atari Bit Byter User Club Sondermagazin

Eingesandte Artikel müssen frei von Rechten Dritter sein. Mit der Zusendung gibt der Autor seine Zustimmung zur Veröffentlichung. Veröffentlichungen, auch Auszugsweise nur mit schriftlicher Genehmigung


 

 

 

Oldie Treff
CeBit 1996

Atari – Sinclair – Sharp MZ – Commodore – Schneider – Texas Instruments und alle noch aktiven 8-Bit User

Liebe Freunde und User der 8-Bit Computer!
In der Zeit vom 14. bis 20. März findet in Hannover wieder die CEBIT statt. Wir wollen den Oldietreff zur ständigen Einrichtung werden lassen und laden wieder recht herzlich alle Freunde der 8-Bit Szene zum „Oldie High Noon“ am Samstag, 16.3.96 12.00 Uhr und am Sonntag, 17.3.96, 12.00 ein.

Treffpunkt ist oben auf der Empore der Halle 2. Das ist die Nordseite in Hallenmitte am Übergang zur Halle 1. Dort ist erfahrungsgemäß immer reichlich Platz für einen kleinen Plausch. Wer im letzten Jahre dabei war, weiß ohnehin schon bescheid. Also, wer an einem dieser beiden Tage auf der CEBIT ist, ist herzlich eingeladen, sich zwanglos mit Freunden der 8-Bit Szene zu treffen. Es ist sicher wieder eine gute Gelegenheit, sich persönlich kennenzulernen, Erfahrungen auszutauschen, kleine Hardwareneuigkeiten (oder Oldies) mitzubringen oder ganz einfach nur um „Flagge zu zeigen…“.

Es sind noch viele User im 8-Bit Bereich aktiv, daß so ein Treffen bestimmt wieder eine tolle Sache wird. Diese Einladung geht an alle, mir bekannte Clubs und ich bitte darum, den Termin weiter bekannt zu machen. Ich weiß von einigen, die beim letzten Mal auch gerne dabei gewesen wären. Der ganz harte Kern mit dem ABBUC und dem ZX-Team wird bestimmt wieder mit mehreren Usern dabei sein. Da ich nicht weiß, ob ich selbst kommen kann, habe ich mich für Samstag eingeplant. Ich bitte alle darum, später selbst in den verschiedenen Clubs über das Treffen zu berichten. Es geht im Prinzip einfach nur darum, daß wir nicht einfach von der Bildfläche verschwinden. Auch andere Veranstaltungen und Messen sollten in diesem Jahr für ähnliche Treffs genutzt werden. Also auf geht’s zum OLDIE-HIGH-NOON auf des CEBIT96 in Hannover.

Euer Willi (Mannertz)

Die Lösung

Cracking the code – Teil 7

von Keith Mayhew
für den ABBUC ins Deutsche übersetzt von Alfons Klüpfel

Die letzten Male sahen wir, wie uns der Assembler viele eintönige Arbeiten abnahm, davon noch die einfachsten: das Nachschlagen der Op-Codes. Stattdessen können wir die Mnemonics verwenden. Und wir sahen, wie wir bei Labels Werte einsetzen können, wie z.B. die Speicherstelle einer Variablen oder die Adresse einer Instruktion im Programm. Auch müssen wir uns nicht damit herumschlagen, daß 2-Byte-Adressen in umgekehrter Reihenfolge (Low/High-Byte) abgelegt werden, und daß Verzweigungen von einer relativen Stelle ausgehen können. Der Assembler erledigt das alles für uns, und zwar fehlerlos.

Dies sollte uns jedoch nicht um die Feinheiten vergessen lassen, wie Instruktionen im Speicher abgelegt werden, und ihre Auswirkungen auf die Speicherstellen und die Register, wenn sie dann ausgeführt werden. Diese Sachen zu verstehen wird sich spätestens dann als von unschätzbarem Wert herausstellen, wenn man Programme entwickelt, hauptsächlich deshalb, weil man dem trauen kann, was man tut. Aber es vermittelt auch eine gründliche Einsicht, was das Programm tut, wenn es läuft. Das hilft vor allem dann, wenn man den Programmcode zu entbuggen versucht, ganz besonders, wenn man dies auf der Maschinensprache-Ebene tun muß und mit den Op-Codes und den Operandenbytes konfrontiert wird.

Wir haben schon alle Maschinensprache-Instruktionen in früheren Kapiteln abgehandelt. Ihr solltet daher jetzt in der Lage sein, jedes beliebige Programm zu schreiben, und Ihr könnt dazu sogar einen Assembler benutzen. Na gut, das ist nicht alles:denn obwohl wir jede Instruktion kennengelernt haben, und wie man sie in Assemblerform schreibt, sind wir noch nicht damit fertig, wie man Datas im Speicher adressiert. Ohne diese grundlegenden Adressierungsmodes, die auch eines der Indexregister miteinbeziehen, kann eigentlich kein Programm geschrieben werden. Aber macht Euch keine Sorgen, wir werden diese Modes später ansehen, und wenn sie erst mal verstanden sind, braucht Ihr nur noch ein bißchen Erfahrung damit. Natürlich bekommt man die nur durch Übung, dafür gibt’s keinen Ersatz. Aber Ihr werdet sehen, daß es Euch hilft, das geeignete Set von Instruktionen auszuwählen, um eine bestimmte Aufgabe zu bearbeiten. Es ist die Fähigkeit, das ideale Set von Instrumenten auszuwählen, das Euer Programm effizienter macht, d.h. es läuft schneller, ist kleiner oder braucht weniger Speicher für seine Datas: es ist sehr schwierig für diese Gesichtspunkte ein Optimum zu finden, und in bestimmten Fällen ist der eine Gesichtspunkt wichtiger als der andere (oder die anderen zwei!) Ihr braucht Euch nicht zu tief damit beschäftigen, Euer Programm zu optimieren. Die Tatsache, daß es funktioniert, wird im allgemeinen für Euch wichtiger sein!

A Case Of Efficiency / Eine Frage der Effizienz

Auch wenn Ihr beim ersten Mal vielleicht feststellt, daß ein Programm funktioniert, so werdet Ihr auch feststellen, daß es groß und langsam ist (fett und behäbig. A.K.) und daßes zu einem Alptraum werden kann, wenn man versucht herauszufinden, wie das Programm denn eigentlich arbeitet. Oft ist Durchsichtigkeit in einem Programm die wichtigste Eigenschaft. Sie erreicht man durch sorgfältige Planung, egal ob auf Papier oder nur im Kopf. Bei einem klar geschriebenen Programm braucht man weniger Kommentare, um durch den Sourcecode durchzufinden, w
enn man es ändern oder debuggen will. Denkt immer daran: Wenn man ein Programm nicht sauber aufgebaut hat, endet man schließlich leicht in einem solchen Chaos, daß ein Debuggen nahezu unmöglich wird. Wenn sich ein Programm während des Schreibens in eine solche Richtung bewegt, dann lohnt es sich im allgemeinen, ganz von vorn anzufangen, bevor man überhaupt keinen Boden mehr unter den Füßen hat. Das Schreiben klarer und eindeutiger Programme kommt erst mit der Übung, und Ihr werdet Eure „eigene Handschrift“ dabei entwickeln, wie bei jeder anderen Programmiersprache. Das ist auch der Grund, warum es so furchtbar schwer ist, umfangreiche Assembler-Listings anderer Autoren zu verstehen. Vielleicht schreiben die aber auch nur „voll chaotische Programme“!

Das Schreiben sog. effizienter Programme kann man grob in zwei Abschnitte aufteilen: Erstens wählt man einen guten Algorithmus (eine gute Methode. A.K.). Das ist wichtig, weil dadurch der Weg festgelegt, wie das Programm grundsätzlich strukturiert wird. Und gleich wichtig für viele Programme ist zweitens, wie Ihr die im Programm benutzten Datas strukturiert. Diese beiden Entscheidungen sind grundlegend und müssen getroffen werden, bevor man mit dem Schreiben des Programms beginnt. Wollt Ihr „unterwegs“ Euren grundlegenden Algorithmus oder eine Datenstruktur ändern, dann bedeutet das im allgemeinen eine Riesen-Umschreiberei von Teilen Eures Programmes. Die Wahl dieser Kriterien hängt natürlich von derArchitektur bzw. dem internen Layout des Prozessors ab: denn es ist ja wohl ziemlich witzlos, einen hübsch einfachen Algorithmus zu wählen, wenn er dann nur unter schlimmsten Verrenkungen auf dem 6502 läuft.

Ganz klar: Der grundlegende Algorithmus und die Strukturierung Eurer Datas legt die Obergrenze dessen fest, wie gut Euer Programm arbeitet (Effizienz!). Es gibt dabei ein zweites Gebiet, auf dem Ihr Euer Programm schneller und kleiner machen bzw. einen geeigneten Kompromiß zwischen diesen beiden Eigenschaften schließen könnt: die Auswahl der Instruktion. In manchen Fällen bedeutet das, daß man ganz schön tricksen muß. Aber letzten Endes heißt es nur zu verstehen, wie Instruktionen ausgeführt werden, und sich der Vorteile bestimmter „Marotten“ des 6502 zu bedienen. Nun, es gibt nicht viele im 6502 und die meisten sind unübersehbar.

Ich war bisher absichtlich etwas vage: denn es ist eine Frage des persönlichen Geschmacks und der Erfahrung, wie man schließlich beim Coden vorgeht. Und man geht vielleicht an zwei verschiedene Programme auch ganz verschieden heran. Ich will hier jetzt nur ein paar Faustregeln aufzählen, die Ihr bei Euren Programmen anwenden könnt.

Follow The Rules / Schön an die Regel n halten!

Der 6502 hat eine einfache interne Architektur. Sie besteht nur aus ein paar Instruktionen und Regeln. Die Tatsache, daß der 6502 nur wenige Instruktionen aufweist, kann tatsächlich als Segen angesehen werden (Vergl. der RISC-Prozessor! A.K.). Man muß sich hier keinen Wust von komplexen Instruktionen merken und glücklicherweise gibt es keine klaffenden Lücken, die einen ernsthaft behindern würden. Wir werden später sehen, daßdie echte Stärke des 6502 in den AdressierModes liegt. Obwohl der 6502 wegen seiner Einfachheit leicht programmierbar ist, liegen seine wesentlichen Beschränkungen in der Tatsache, daß nur drei Mehrzweckregister zu unserer Verfügung stehen. Und es gibt ein paar Unregelmäßigkeiten in der Weise, wie sie in verschiedenen Adressier-Modes kombiniert werden können (vergl. Tabellen in Teil 4!). Tatsächlich können alle benötigten allgemeinen Operationen nur auf dem Accumulator durchgeführt werden. Das bedeutet im allgemeinen, daß ein Wert in den Accumulator geladen, dort bearbeitet und dann abgespeichert werden muß, bevor der nächste Arbeitsgang (die nächste Operation) ausgeführt werden kann. Ihr werdet herausfinden, daß das X- und das Y-Register gewöhnlich nur für die „indexed“-Adressier-Modes verwendet werden. Sind sie jedoch frei, so kann man dort vorübergehend (temporär) Werte ablegen. Oder sie können einfach als Zählregister benutzt werden (was häufig der Fall ist). Der Schlüssel zu diesem Problem: Je weniger auf den (RAM) Speicher zugegriffen wird, desto schneller ist das Programm. Folglich heißt es, die Register so weit wie irgend möglich einzusetzen. Ein paar Operationen können direkt in den Speicherstellen durchgeführt werden, ohne daß der Wert erst in ein Register geladen werden müßte; und zwar handelt es sich um die Increment-, Decrement-, Shift- und Rotate-Operationen (d.h. aufwärts- bzw. abwärtszählen, verschieben und verdrehen. A.K.)

.

Besondere Aufmerksamkeit sollte man dem Loop-Vorgang (Schleife)schenken: damit kann man eine Gruppe von Informationen mehrfach ausführen lassen. Wenn man hier viele kurze Zeiteinsparungen erreichen kann, addieren sie sich im LoopVorgang in deutlichem Umfang und machen so die Schleife deutlich schneller. Es wird nur selten vorkommen, daßman in einer Schleife Speicherzugriffe vermeiden kann. Eine Möglichkeit, Zeit einzusparen, ist es, die Speicherstellen der Zero-Page zu benützen. Das spart ein oder zwei Zyklen bei jedem Zugriff. (Zu diesem Thema kann man in jedem beliebigen Buch über den 6502 nachschlagen, wenn man wissen will, wie viele Zyklen pro Instruktion und Adressier-Mode benutzt werden.) Ihr werdet möglicherweise selbst erkennen, daß Zero-Page- Speicherstellen recht wertvoll sind, besonders im Zusammenhang mit BASIC-Programmen. Man muß sie also sorgfältig auswählen ihr Einsatz jedoch hilft, ein Programm schneller oder kleiner zu machen.Zum Schluß will ich noch ein paar allgemein bekannte Tricks erwähnen. Sie machen lediglich effizienteren Gebrauch der zur Verfügung stehenden Instruktionen. Schaut Euch das folgende an.

LDA NUM1
CLC
ADC NUM2
STA NUM1
LDA NUM1+1
ADC NUM2+2
STA NUM1+1

Das ist der übliche Weg, zwei 2-Byte-Zahlen zu addieren, wie sie ein Computer in jeder Hochsprache für „NUM1 + NUM2“ generieren würde. Dabei ist „NUM1“ das Low-Byte und NUM1+1 das High-Byte der erstenZahl, entsprechend bei „NUM2“ für die 2. Zahl. Beim letzten Mal haben wir jedoch folgendes gesehen: Ist die zweite Zahl eine 1-Byte-Zahl, d.h. „NUM2+1“ ist gleich Null, dann bleibt „NUM1+1“ entweder unverändert oder wird um Eins erhöht, je nach Status des Carry. Daher können die letzten drei Instruktionen ersetzt werden durch:

BBC NOINC ;Increment falls
INC NUM1+1 ;Carry gesetzt
NOINC

Das ist weniger beschwerlich als die erste Methode und braucht weniger Speicherplatz für den Code. Auch für die Subtraktion gibt es eine ähnliche Optimierung: Wollt Ihr die 2-Byte-Zahl nur um eines erhöhen, könnte man so vorgehen:

INC NUM1 ; Low-By te ändern
BNE NOINC ;High-Byte ändern INC NUM1+1 ;falls Low-Byte=0
NOINC

Beachtet, daß in diesem Beispiel die „INC“-Instruktion das Carry-Flag nicht verändert, und daß wir deshalb die Entscheidung, wann das High-Byte verändert wird, mit einer anderen Methode treffen müssen, die nicht vom Carry abhängt. Das High-Byte muß immer dann erhöht werden, wenn das LowByte von FF nach 00 „gerutscht“ ist. Das High-Byte wird also geändert, wenn das Low-Byte gleich Null ist, daher die „BNE“-Instruktion. Der entsprechende Code für das Abwärtszählen ist ein wenig anders, weil wir jedesmal prüfen müssen, ob das Low-Byte von 00 nach FF gewechselt ist. In diesem Fall wissen wir, daß das High-Byte ebenfalls heruntergezählt wird, wenn das Low-Byte vor dem Herunterzählen gleich Null war. Der Code sieht also so aus:

LDA NUM1 ;Low-Byte prüfen
BNE SKIP ;High-Byte herunterzählen DEC NUM1+1 ; falls Low=0
SKIP DEC NUM1 ;jetzt Low-Byte bearbeiten

In diesem Fall muß der LOAD-Vorgang durchgeführt werden, um ggf. das Z-Flag zu setzen, je nach Wert von NUM1: stattdessen
hätte man natürlich auch das X-oder das Y-Register benutzen können. Diese paar Beispiele zeigen, wie Ihr besser programmieren könnt, als Ihr es bis zu diesem Kapitel vermutlich gemacht habt. Und diese Art der Optimierung kann ein Computer normalerweise nicht schaffen, da er auf jeden Fall 2-Byte-Zahlen bearbeiten können muß.

Eine andere Gelegenheit, bei der Ihr ähnliche Tricks anwenden könnt, ist das Initialisieren von Speicherwerten. Wenn Ihr z.B. ein paar Speicherstellen auf „01“ setzen wollt, andere auf „00“ und wieder andere auf „FF“, könntet Ihr so vorgehen:

LDX #1 ;Initialwert 1
STX LOC1 ;Save
STX LOC2 ;Save
DEX ;Auf 0 runterzählen
STX LOC3 ;Save
STX LOC4 ;Save
DEX ;auf FF runterzählen
STX L005 ;Save
STX LOC6 ;Save

Daraus könnt Ihr erkennen, daß der Gebrauch des Index-Register praktischer ist, als über den Accumulator zu gehen: denn die Index-Register können durch eine einzige Instruktion um eins herauf- oder heruntergezählt werden. Abgesehen von der ziemlich offensichtlichen Tatsache, daß das Mehrfachspeichern desselben Wertes in einem Zug durchgeführt werden sollte (um das jeweils neuerliche Laden des Registers zu vermeiden), besteht der praktische Nutzen darin, daß man durch Herunterzählen von Null „FF“ und umgekehrt von „FF“ aus Null erhält. Man beachte, daß“FF“ das Zweierkomplement von „-1“ (bei einer 8-Bit-Zahl!) ist. Daher ist es sinnvoll, Null herunterzuzählen (Decremenl, um „-1“ zu erhalten, bzw. heraufzuzählen (Incremend), um von „-1“ nach Null zu kommen.

An einer anderen Stelle spart man oft viel ein: Man vergleicht den Wert des Counters (Zählelmit seinem Endwert, also anstatt so vorzugehen:

LDX #0 ;Start bei Null
LOOP ;Die Schleife selbst
INX ;Der Increment-ZählvorCPX #$5B ;gang auf Grenzwerte hin
;überprüfen zurück, falls .
;nicht gleich wird gewöhnlich
BNE LOOP
dies benutzt:
LDX #$5B :bei Maximum starten LOOP
:Die Schleife selbst
DEX :Zählerwert runterzählen
BNE :zurück, falls nicht gleich Null
Der Abgleich mit Null ist am Ende der 2. Loop-Version nicht nötig, weil die Decrement-Instruktion das Z-Flag passend setzt.

Man kann jede Menge weitere Beispiele dieser Art finden, aber es würde den Rahmen dieserArtikelserie sprengen. Aufjeden Fall hoffe ich, daß Euch diese Beispiele genug Anregung gegeben haben, andere Programmteile ähnlich zu optimieren. Als letztes will ich anmerken, daß Ihr immer den Stack benutzen könnt, um Werte vorübergehend abzulegen:dazu dienen die „PHA“- und die „PLA“- Instruktion, mit denen man den Accumulator laden kann. Aber vergeßt nicht, daß Ihr immer dieselbe Anzahl Bytes verschieben müßt – ansonsten geratet Ihr in ernsthafte Schwierigkeiten. (es sei denn, Ihr habt damit ein paar raffinierte Sachen vor). Es ist aus diesem Grund „PHA“ und „PLA“ nicht allzuweit voneinander einzusetzen: denn allzuleicht vergißt man, welcher Wert denn „damals“ auf dem Stack abgelegt worden war. Es gibt abgesehen davon noch zwei andere Instruktionen, die selten benutzt werden, „PHP“ und „PLP“, die eine Verschiebung (Push and Pull = wegschieben und herholen) am Prozessor-Status-Flag bewirken: „PHP“ könnte man z.B. einsetzen, nachdem man eine Zahl vom Accumulator abgezogen hat. Man speichert so die Einstellung aller Status-Flags: Man könnte dann mit dem Wert im Accumulator weiterarbeiten und später mit „PLP“ den Status von der Subtraktion zurückbekommen. Ab da könnte man ggf. verzweigen, je nach Status eines Flags, z.B. des Carry. Eine Lösung eines solchen Problems, ohne daß man diese Instruktionen benutzt, könnte ganz schön chaotisch werden.

Eine andere Möglichkeit, die „Push and Pull“ Operation zu nutzen, ist, „PHP“ gefolgt von „PLA“ einzusetzen, um den Zustand des Status-Flags in den Accumulator zu laden und dort zu überprüfen, worauf man dann mit „PLA“ und „PLP“ diesen Status nach Bedarf neu einstellen kann.

Improving The Multiplication / Multiplikation V 2.0

Wenn Ihr Euch erinnert: Die Routine im letzten Teil dieser Serie berechnete das Produkt zweier 8- Bit-Zahlen:durch wiederholte Addition erhielt man ein 16-Bit Ergebnis. Nur um zu zeigen, wie man Programme verbessern kann: Ein aufmerksamer Leser wies ganz richtig darauf hin, daßes nicht sehr sinnvoll sei, den Inhalt des Accumulator bei jedem Schleifendurchgang zu laden und abzuspeichern. Die Verbesserung besteht darin, die Lade- und Speicher-Instruktion komplett aus der Schleife herauszunehmen. Wenn dann die Schleife abgearbeitet ist, würde der Accumulator den Lower-Teil (die kleineren 8-Bit) des Ergebnisses enthalten, der dann zurück in das Label RESULT geschrieben würde, und zwar an der Stelle, die mit EXIT be- zeichnet ist. Mit „RTS“ geht’s in BASIC weiter. Egal! Der Algorithmus, per wiederholter Addition zu multiplizieren, ist hoffnungslos ganz besonders, wenn, man damit mal 16-Bit Zahlen bearbeiten will.

Entsprechend den großen Zahlen ergäbe sich eine Riesenmenge an Wiederholungen! Einen besseren Algorithmus kann man finden, wenn man mal nachdenkt, wie wir selbst denn normalerweise zwei Dezimalzahlen „von Hand“ multiplizieren. Wir nehmen den Multiplikand als ein Ganzes und multiplizieren ihn mit jeder einzelnen Stelle unseres Multiplikators. Das Ergebnis bekommen wir, indem wir die Teilergebnisse addieren.

225 Multiplikand
342 Multiplikator
450
9000 Teil-Produkt
67500
76950 Endergebnis (Summe der Teile)

Das erste Teilprodukt lautet 2 x 225 = 450. Das zweite, 4 x 225 = 900, wird allerdings um eine Stelle nach links verschoben, also mit 10 multipliziert, so daß man letztendlich 9000 erhält. Das dritte wird nach demselben Muster errechnet und dann um zwei Stellen verschoben. Machen wir dasselbe mit Binärzahlen, vereinfacht das alles. Jede Stelle des Multiplikators ist entweder 1 oder 0. Multiplizieren wir mit 0, bekommen wir als Ergebnis 0. Multiplizieren wir mit 1, ist das Ergebnis gleich dem Multiplikand. Jedes Teilprodukt ist also immer entweder Null oder der Multiplikand selber. Aber anstatt einfach eine Kopie des Multiplikand hinzuschreiben und sie dann um eine bzw. mehrere Stellen nach links zu verschieben, können wir einfach bei jedem Schleifendurchgang den Multiplikand Schritt für Schritt nach links verschieben. Listing 1 zeigt, wie man so etwas codet.

Das Programm startet, indem es die Werte von Multiplikand und Multiplikator vom Stack holt und sie in MLTPND und MLTPLR abspeichert. Dann wird der Accumulator mit Null geladen, um das High- Byte des Multiplikators zu initialisieren, die Speicherstelle „CC“ und beide Teile des Ergebnisses. Das X-Register wird mit 8 geladen – dies ist die Anzahl der Bits im Multiplikator und daher die Anzahl der Schleifendurchgänge. Die Hauptschleife startet bei MULT und verschiebt den Multiplikator nach rechts, so daß das unwichtigste Bit (das kleinste, ganz rechts!) ins Carry verschoben wird. (Schlagt doch mal Eure Op-Codes in den ersten Artikeln dieser Serie nach! „LSR“! Kap. 4! A.K.) Ist das Carry 0, so unterlassen wir, den Multiplikator zu addieren. Dazu dient die „BCC“-Instruktion („Branch if Carry Clear‘), die zum Befehl SKIP (überspringen) führt. Steht an dieser Stelle eine 1, dann findet eine 16-Bit-Addition statt, bestehend aus dem Wert des Zwischenergebnisses und dem Multiplikator. Bevor die nächste Schleife durchlaufen wird, verschieben wir den 2-Byte-Multiplikator um ein Bit nach links. Dazu dienen die „ASL“- und „ROL“-Instruktionen, die bewirken, daß das Carry vom einen Byte ins andere wandert, und eine Null in das unwichtigste Bit (das kleinste, ganz rechts)des Low- Byte verschoben wird. Somit wird der Multiplikator komplett mit 2 multipliziert. Der Bit-Zähler im X-Register wird dann decrementiert (eins heruntergezählt) und die Schleife fortgesetzt, falls die Berechnung noch nicht abgeschlossen ist. Bei jedem Durchgang wir der Multiplikator Schritt für Schritt nach rechts verschoben, so daß jedes Bit bei der Berechnung berücksichtigt wird.

Ebenso wird der Multiplikator nac
h links verschoben. Dies bewirkt eine Multiplikation mit 2. (Zur Erinnerung: Wir rechnen hier im 2er-System, d.h. eine Multiplikation mit 2 entspricht hier einer Multiplikation mit 10 im Zehnersystem! A.K)

Anders als die Methode der wiederholten Addition finden hier nur acht Schleifendurchgänge statt, ganz egal, wie groß die beiden Zahlen sind, die multipliziert werden. Diese Zeitersparnis ist wesentlich, wenn man sich vorstellt, daß man 16-BitZahlen multiplizieren will: Bei der Additionsmethode müßten über 60 Durchgänge gemacht werden: bei dieser dagegen nur 16! So, nun haben wir also einen effizenteren Weg, zwei Zahlen miteinander zu multipli- zieren. Aber auch der kann noch verbessert werden. Benennen wir den Multipli kator mit dem Buchstaben A und den Multiplikator mit B, das Ergebnis lautet dann A x B. Nun schreiben wir B in binärer Form nieder, wobei jedes Bit von B eine Unterbezeichnung bekommt, nämlich von b0 (das kleinste Bit, ganz rechts) bis b7 (das größte, ganz links). Wir bekommen folgendes: B = b7 x 128 +b6 x 64+b5 x 32 +b4x 16 + b3 x 8 + b2 x 4 + b1 x 2 + b0. Hat B beispielsweise den Wert 5, so wären die Bits b2 und b0 Eins und die restlichen Null. Diese Zahl können wir nun so schreiben: B = b0 +2(b1 + 2(b2 + 2(b3 + 2(b4 + 2(b5 + 2(b6 + 2 x b7)))))). Der Algorithmus, mit dem man den Wert B feststellt, funktioniert so: Nimm Bit 7und multipliziere es mit 2, addiere Bit 6 dazu und multipliziere das Ergebnis mit 2, addiere Bit 5 dazu und multipliziere … Dies geht so weiter, bis wir endlich Bit 0 addiert haben, so daß wir dann den Wert der Binärzahl B hätten. Aber wir wollten doch den Wert A x B! Nun, wir gehen genauso vor, multiplizieren aber jedesmal zusätzlich mit A. Am Ende haben wir dann vor jedem „b“ ein „A“ stehen.

Der Algorithmus verläuft nun so: Addiere Bit 7 mal A zum Ergebnis und multipliziere es mit 2 usw. bis Bit 0 mal A dazuaddiert ist. Natürlich ergibt die Multiplikation mit A immer nur eine Null oderA selbst. So geht es also bei jedem von B nur darum: Soll man A addieren oder nicht? Listing 2 zeigt, wie dieser Algorithmus eingebaut werden kann. Beachtet,
daß das Listing nicht komplett ist, es fehlt die Deklaration der drei Labels MLTPND, MLTPLR und RESULT, sowie der Startpunkt, der die Werte aus dem BASIC in die beiden Variablen holt wie in Listing 1.

Diese Routine benützt den Accumulator, um den Low-Teil des Ergebnisses zu halten und setzt ihn und das High-Byte des Ergebnisses beim Start auf Null. Schauen wir uns die (Haupt-) Schleife an, sehen wir, daßzuerst das Ergebnis mit 2 multipliziert wird. Dann wird das nächste Bit des Multiplikator geprüft und ggf. der Multiplikator zum Ergebnis dazugezählt. Das ist dasselbe, wie im vorhergehenden Algorithmus, außer, daß der Eingangswert des Ergebnisses mit 2 multipliziert wird, was natürlich Null ergibt (denn wir haben ja noch kein Ergebnis! A.K.)Diese Extra-Multiplikation erspart uns aber Instruktionen und ist demzufolge nützlich! Listing 3 zeigt noch einen weiteren Weg für dieselbe Multiplikation auf, der womöglich noch effizienter ist. (Es ist der letzte, das verspreche ich!). Dieser Algorithmus kann vom vorhergehenden ganz ähnlich abgeleitet werden. Ich werde ihn aber nicht in vollem Umfang beschreiben. Hier wird die Multiplikation vollzogen, indem der Multiplikator zum High-Byte des Ergebnisses addiert wird. Dann wird dieses Ergebnis durch zwei geteilt. (Dazu benutzen wir „ROR“.) Man beachte, daß zwei Rotationen vorgenommen werden, und nicht erst eine Verschiebung (Shift) und dann eine Rotation, weil auch jedes Carry von der vorausgehenden Addition mit hinuntergenommen wird.

230 LDA #0 :zero result low (held in A) 0240 STA RESULT+1 :and high.
0250 LDX #8 :load X with bit count.
0260 MULT ASL A :multiply result by 2 0270 ROL RESULT+1 :and high byte.
0280 ASL MLTPLR :Get next MSB bit in carry 0290 BCC SKIP :Skip if zero.
0300 CLC :eise add
0310 ADC MLTPND :multiplicand.
0320 BCC SKIP :skip if no carry to high. 0330 INC RESULT+1 :Else add one to high. 0340 SKIP DEX :Decrement bit count. 0350 BNE MULT :Loop back if more to do. 0360 STA RESULT :Save low byte of result. 0370 RTS :Finished.
Listing 2

0230 LDA #0 ero high byte (in A)
0240 STA RESULT :and low, byte of result.
0250 LDX #8 :Load bit count.
0260 MULT LSR MLTPLR :Get next bit of multiplier 0270 BCC SKIP :Skip if zero. 0280 CLC :eise add
0290 ADC MLTPND :multiplicand 0300 SKiP ROR A :divide result by 2 0310 ROR RESULT :and low byte 0320 DEX :Decrement bit count 0330 BNE MULT :and loop if more.
0340 STA RESULT+1 :Save high byte of result. 0350 RTS :and say bye-bye!
Listing 3

Genug jetzt mit Multiplikations-Routinen! Es gibt entsprechende Routinen für die Division – aber die sind nicht schlimmer. Ich werde Euch daher nicht auch noch damit langweilen. Ich hoffe, daß es Euch nach diesen vier Beispielen möglich ist, Euch selbst eigene Wege für eigene Programme auszudenken, oder anderer Leute Programme neu zu schreiben. Jetzt werden wir uns erst mal die noch fehlenden Adressier-Modes ansehen. Accessing Datas / Wie komm‘ ich an Nachbars Daten ran? Bisher konnten wir nur absolute, also feste Adressen im Computerspeicher ansprechen, um an Datas ranzu kommen. („absolut“ wäre vergleichbar: „Wieschenbeck 45 in Herten“. Diese Adresse gibt’s nur einmal. Das Gegenstück wäre „relativ“, etwa: „das 5. Haus, rechts in der zweiten Seitenstraße links.“ Das Ergebnis einer Suche nach dieser zweiten Adreßangabe könnte sehr unterschiedlich ausfallen, je nachdem, aus welcher Richtung man in die Straße hineinfahren würde. A.K) Das ist so lange ganz nett, solange wir nicht mehr wollen, als den Computer ein paar Multiplikationen lösen zu lassen. Wollen wir aber wirklich ein bißchen mehr machen, brauchen wir sowas ähnliches wie den ARRAY-Befehl in BASIC. Wollten wir beispielsweise eine Zahl in 256 aufeinanderfolgenden Speicherstellen ablegen, so müßten wir 256 Speicher-Instruktionen benutzen.

Wir brauchen eine Methode, anhand derer der Prozessor für jede einzelne Speicher-Instruktion eine andere Adresse erkennt. Eine primitive Methode dafür ist, das betreffende Operandenbyte des Speicher-Op-Codes im Programm zu beeinflussen. Das bezeichnet man als eine „Modifikation“, da wir den betreffenden Teil des Programmcodes modifizieren. Dies kann unter bestimmten, sehr seltenen Umständen sehr nützlich sein, aber Ihr solltet diese Methode im allgemeinen meiden wie der Teufel das Weihwasser! Die Schwierigkeit dabei ist nämlich, daß Ihr aller Wahrscheinlichkeit nach ein höllisches Durcheinander bekommt:denn der Wert, den Ihr beim ersten Durchgang als Operand abspeichert, wird beim nächsten bereits verändert sein (außer, Ihr setzt ihn jedes einzelne Mal wieder zurück). Und was noch schlimmer ist, der Code könnte nie zu einer festen Speicherstelle geschoben werden, geschweige denn in einem ROM festgehalten werden, da er dort nicht mehr geändert werden könnte. Diese Methode würde also nicht funktionieren. Welcheanderen bietet uns der 6502 dann, auf Datas zuzugreifen?

Indexing / Das Indizieren

Um auf eine Datentabelle zuzugreifen, die an einer festen Stelle im Speicher liegt, muß man der Ausgangsadresse der Tabelle einen Offset hinzufügen. Diese Adressiermethode bezeichnet man als Index-Methode. Sie benutzt – nicht überraschend -eines der Index-Register. DerAssembler akzeptiert folgendes, um diesen Adressiermodus anzuzeigen: STA TABLE,X :indizieren mit dem X-Register STA TABLE,Y :indizieren mit dem Y-Register Die Instruktion wird ganz normal geschrieben, enthält aber nach dem Operand ein Komma und einen IndexRegister-Namen. Hat also beispielsweise TABLE den Wert $4310, dann lautet der Maschinencode: 9D 10 43. Man beachte, daß keine Zusatzinformationen gespeichert werden, außer der absoluten Adresse $43 10. Der einzige Unterschied ist, daß der Op-Code 9D anstatt 8D lautet (was bedeuten würde: Absoluter Zugriff). Auch der Op-Code 9D bedeutet, daßder Inhalt des Accumulator abgespeichert wird, weist aber den 6502 an, ein
Index-Register für den Datenzugriff zu benützen. Achtung! Für die Arbeit mit dem Y-Register wird ein anderer Op-Code benützt, der lautet dann 99 (Vergl. OpCode-Tabelle!)

Schau’n wir mal, was passiert, wenn einer dieser neuen Op-Codes ausgeführt würde: Erstmal werden die Operanden aus dem Speicher geholt, in unserem Fall $10 gefolgt von $43, so daßsie eine 16-Bit-Adresse bilden. Nun, anstatt diese Adresse so zu benutzen, wie sie ist – sie wäre ja im Moment nur eine ganz ordinäre absolute Adresse – fügen wir erst den Inhalt des von uns ausgewählten Index- Registers an, um die endgültigeAdresse zu bekommen. Sie brauchen wir für den Datenzugriff. Achtung! Das Index-Register bleibt unverändert! Ihr könnt Euch diese Instruktion so geschrieben vorstellen:

STA TABLE+X

Allerdings wird diese Darstellung vom Assembler nicht benutzt, um das Index-Adressieren anzuzeigen, da er dann davon ausginge, daß Ihr einen festen (konstanten) Ausdruck schreiben würdet, in dem X einen Labelnamen darstellt. Also müßt Ihr Euch daran gewöhnen, das Komma in der Instruktion entweder als „indiziert“ (indexed) oder als „plus“ zu lesen. Das folgende Stückchen Programmcode demonstriert den Gebrauch des index-Adressierens anhand der Aufgabe, die Zahl $5B in 256 aufeinanderfolgende Speicherstellen zu schreiben, von denen die erste die $4310 ist:

LDA #$5B :Daten, die gespeichert werden sollen LDX #0 :Index laden
LOOP
STA $4310,X :speichern mit Index benutzen
INX :Index höherzählen (increment) BNE LOOP :wiederholen bis Auftrag erledigt

Bevor LOOP eingegeben wird, würde der Accumulator mit den Daten geladen, die abgespeichert werden sollen, und das X-Register mit dem Ausgangs-Index Null. Beim ersten Speichervorgang wird die neue Adresse errechnet: $4310 ergibt sich aus dem gegebenen Wertplus Null (da im X-Register ja Null steht!). Es wird also der Wert $5B in die Speicherstelle $4310 geschrieben. Danach wird der Wert von X um eins höhergezählt (incremented) und eine Verzweigung rückwärts zum Speichervorgang durchgeführt. Hier ergibt sich jetzt die neue Speicherstelle $4311, weil im X-Register mittlerweile eine Eins steht. Der Wert $5B wird also (beim nächsten Durchgang) in $4311 gespeichert. Diese Schleife wird so oft durchlaufen, bis der Wert im X-Register wieder Null ist. Schließlich werden alle Speicherstellen von $4310 bis $440F den Wert $5B enthalten. Natürlich hätte man für diesen Vorgang genausogut das Y-Register benutzen können.

Nun haben wir eine Möglichkeit, auf eine Tabelle zuzugreifen. Wir können ein kleines Programm schreiben, um eine Tabelle von einer Adresse in eine andere zu verschieben.

LDX #0 :Index auf Null
COPY LDA TABLEI,X :Daten aus Tabelle 1 STA TABLE2,X :in 2. Tabelle verschieben
INX :Index höherzählen (increment)
BNE COPY :Rest der Tabelle ebenso kopieren

Angenommen TABLE1 und TABLE2 sind gültige Labels, die die Adressen der beiden Tabellen enthalten, dann liest das Programm der Reihe nach jedes Byte der 1. Tabelle und legt ihn in der 2. Tabelle ab, wobei derAccumulator für die Übertragung benutzt wird. Es könnten auch weniger als 256 Bytes verschoben werden, wenn wir X vor der Verzweigung mit einem Grenzwert verglichen, oder indem wir den Grenzwert gleich ins X-Register laden würden und bei jedem Schleifendurchgang eins herunterzählen würden (decrement).

Die wesentlichen Grenzen für die 6502-Index-Methode bestehen darin, daß X-und Y-Register 8-Bit- Register sind. Daher können unsere Tabellen 256 nicht überschreiten. Ein anderes Problem, mit dem wir fast ständig konfrontiert sind, ist folgendes: Die Inhalte der Tabellen, auf die wir zugreifen wollen, bewegen sich ständig im Speicher umher. Wir werden gleich sehen, wie die restlichen Adressier- Modes dieses Problem lösen.

0100 :Vom BASIC aufrufen 0110: mit X=USR(1536), 0120 „`= $0600
0130 PLA 0140 LDY #0
0150 LOOP TYA
0160 STA ($58) ,Y
0170 INY
0180 BNE LOOP
0190 RTS
Listing 4

XQ 10 DIM FILE$(14)
DA 20 CH=1:? „Please enter device:file name AQ 30 INPUT FILE$
MC 40 GOSUB 10000
YT 50 END
RU 10000 OPEN #CH,4,0,FILE$:TRAP 10160 JY 10010 GET #CH,X:GET #CH,Y
WJ 10020 IF X<>255 OR Y<>255 THEN 10170 QU 10030 GET #CH,SL:GET #CH,EH
NQ 10040 ST=SL+256*SH
VA 10050 GET #CH,EL:GET #CH,EH
TU 10060 EN=EL+256*EH
BA 10070 10CB=832+CH*16:LN=EN-ST+1 LR 10080 LH=INT(LN/256):LL=LN-LH*256 JO 10090 POKE IOCB+2,7
MC 10100 POKE 10CB+4,SLPOKEIOCB+5,SH FN 10110 POKE 10CB+8,LL:POKE 10CB+9,LH JE 10120 X=USR(ADR(„hhh*LVd“),Ch*16) QX 10130 GET #CH,SL:GET #CH,EH
YW 10140 IF SL=255 AND SH=255 THEN 10130 YL

10150 GOTO 10040
WA 10160 CLOSE #CH:RETURN
TW 10170 ? „File does not have binary header.“:RETURN
Listing 5

Indirecting / Indirektes Adressieren

Der indirekte Adressier-Modus des 6502 ermöglicht uns, auf Daten mit Hilfe eines Zeigers (pointer) im Speicher zuzugreifen. Wenn z.B. die Stellen $600 und $601 die Werte $10 bzw. $43 enthalten, dann sagt man, daß$600 und $601 indirekt auf die Stelle $4310 deuten (zeigen). Diese beiden Speicherstellen enthalten also die Adresse, auf die wir zugreifen wollen. Der 6502 hat eine eine Instruktion, die das indirekte Adressieren selbständig beherrscht. Es handelt sich um die JMP- Instruktion, und sie wird so benutzt:

JMP($600)

Angenommen, daß $CB und $CC immer noch auf die Speicherstelle $4310 deuten, dann wird diese Instruktion dorthin springen und versuchen, den Code in $4310 auszuführen. Wiederum gilt: Es wird keine Extra-Information zusammen mit der Jump-Instruktion abgespeichert: stattdessen wird ein anderer Op-Code benutzt, um anzuzeigen, daßdie betreffende Adresse indirekt angegangen wird. Achtung: Es wird nur der erste Teil des Zeigers eingegeben, das zweite Byte wird immer aus der darauffolgenden Speicherstelle genommen. Mixing Indirecting With Indexing / Das Vermischen beider Methoden: indirektes und indiziertes Adressieren

Alle anderen Instruktionen, die diese Methoden des indirekten Adressierens benutzen können, wie „LDA“ und „STA“, können dies nicht aus sich selbst heraus: folgende Anweisung wäre also in Assembler illegal:

LDA($600)

Stattdessen beschränkt uns der 6502 auf die Page Null für die Zeigeradresse und zwingt uns, das Index-Adressieren zu benutzen, eine Kombination der beiden aufgeführten Modes. Im folgenden sehen wir, wie wir diese neuen Modes in Assembler schreiben. Achtung! In diesem Fall kann das X-Reg ister nicht durch das Y-Register ersetzt werden.

LDA($CB,X)

Dieser Modus wird als pre-indexed (vor-indiziert) bezeichnet, da zuerst der Inhalt des X-Register zurAdresse $CB addiert wird, damit man die endgültige Adresse erhält (die steht immer in der Page Null), von der der Zeiger genommen wird. Enthält X also $10, dann addiert der 6502 dies zu $CB und geht zur errechneten $DB: er nimmt dann die Inhalte von $DB und $DC als Zeiger, der auf die endgültige Stelle deutet, die sich dann an jeder beliebigen Stelle im Speicher befinden kann. Diese Methode wird jedoch selten benutzt, weil sie nur den Zugriff per Zeiger auf eine einzige Stelle erlaubt. Wollten wir dann auf die nächste Adresse zugreifen, müßten wir erst zwei Byte zum Zeiger hinzuzählen (increment!).

Der letzte Modus wird als post-indexed (im nachhinein indiziert) bezeichnet und kann nur das Y- Register benutzen. Geschrieben wird er so:

LDA($CB),Y

Dieser post-indexed Modus holt den Inhalt einer Page-Null-Stelle und benutzt ihn indirekt. Sobald der Wert entnommen ist, wird das Y-Register zur Adresse addiert, so daß man die endgültige Adresse erhält. Wenn z.B. $CB den Wert $10 enthält, $CC den Wert $43 und Y den Wert $20, dann erhalten wir die Adresse $4310 plus $20 aus dem Y-Register: das ergibt $4330.

Durch diese indirekt-indizierende Methode bekommen wir eine ganze Reihe von Zeigern, die in der Page Null bereitgehalten werden, und die man dann benutzen kann, um auf Tabellen im Speiche
r zuzugreifen, indiziert durch das Y-Register. Allerdings sind wir immer noch auf 256 Byte pro Tabelle beschränkt, es sei denn wir würden den Wert des Zeigers verändern. Wie man mit diesen Modes arbeitet, untersuchen wir im nächsten Kapitel. Jetzt schaut erst mal nach, was in Listing 4 passiert.

Listing 5 ist ein BASIC-Programm, das uns erlaubt, jedes Objectfile (erstellt und komprimiert mit einem Assembler) zu laden. In erster Linie ist es jedoch für die Arbeit mit Cassetten gedacht. Es lädt nämlich Objectfiles, die mit derAssembler-Cartridge erstellt sind. Für die Arbeit mit Cassetten tippt man nach dem Prompt (=die Eingabe-Aufforderung) nur „C:“. Wer mit Disk arbeitet, tippt „D:“ gefolgt vom jeweiligen Filenamen. (Die Gänsefüßchen werden nicht mitgetippt!) Allerdings werden Disk-User das Laden vom DOS aus als praktischer empfinden, außer Ihr wollt diese BASIC-Routine in eines Eurer Programme übernehmen.

Achtet darauf, daß in Zeile 1020 das „*“(das Stemchen)und das „d“ in Inverse-Video (also invertiert, d.h. Ataritaste vorher drücken!) geschrieben werden müssen. Sie sind ein Teil des Maschinencodes, der das Laden des Files im Vergleich zu einem BASIC GET-Befehl in einer Schleife erheblich beschleunigt. So, jetzt habt Ihr erst mal Gelegenheit, Euren Assembler wieder rauszuholen und zu experimentieren.

Textverarbeitung und 1,44 MB

Im Clubmagazin Nr. 40 suchte ein Bit Byter Informationen über Textverarbeitungen auf dem 8-Bit-ATARI, mit denen der User das ‚HDI‘ voll nutzen kann. Hierbei ging es insbesondere um die maximale Kapazität der Disks von 1,44 Megabyte. Wünschenswert war ihm darüber hinaus die Benutzung von Unterverzeichnissen, den Sub-Directories, die Sparta-DOS, MyDOS und BEWEDOS sowie einige andere DOS-Varianten zur Verfügung stellen.
Immerhin erreichten mich als ABBUC-Helfer in Sachen Textverarbeitungen in den letzten 3 Jahren 2 schriftliche und 1 telefonische Anfrage aus dem Club. Ein Zeichen dafür, daß die Bit Byter zusammen mit ihrer Maschine und der darauf installierten Software gereift sind und Probleme nicht mehr entstehen.

Textverarbeitungen gibt’s für den kleinen ATARI in Hülle und Fülle. Die meisten stammen natürlich aus dem englisch sprechenden Ausland und bringen das Problem mit sich, keine deutschen Sonderzeichen auf dem Bildschirm darstellen zu können. In so einem Fall arbeitet der erfahrene Bit Byter mit Control-Code -Sequenzen, die er sich für den jeweils angeschlossenen Drucker, meist auf FX-80-Standard, selber von Hand optimiert hat. Manch einer arbeitet aus Vereinfachung auch mit einem kompletten ATARI-System. Das kann z.B. aus dem Rechner 800XL, einer Floppy 1050, einem Drucker 1027 oder 1029 und dem guten, alten ‚ATARI Schreiber‘ als Textverarbeitung bestehen. Ein klassi- sches System des Jahres 1984. Ältere User haben vielleicht ein auf dem ATARI 800 und der Floppy 810 basierendes System, jüngere dagegen bauen auf dem 130XE und der XF551 auf. Allen gemeinsam ist das Problem der verflucht kurzen Textfiles. Den größten mir bekannten Textspeicher stellt die Cartridge-Version des ‚ATARI Schreiber mit ca. 28K bereit. Eine Ausnahme bilden Textverarbeitungen, die mit ‚SpartaDOS X‘ betrieben werden können. Hier sind ca. 31K Textspeicher verfügbar. Längere Texte wie z.B. die deutschen Handbücher zu ‚SpartaDOS 3.x‘, ‚ACTION!‘, ‚Mini Office II‘ oder ‚TurboBASIC‘ erzwingen eine Aufteilung in mehrere Textfiles. In etwa lassen sich in den meisten Programmen höchstens 10 Seiten Text im Speicher halten, wobei dann allerdings eine eventuell vorhandene Druckvorschau-Funktion schon nicht mehr erreichbar ist. Die braucht nämlich auch so ca. 4 Kilobyte freien Speicher.

Also muß der User nun die hoffentlich vorhandene Link-Funktion aktivieren und … Das Einhalten der Seitenformatierung, Header, Footer, Nummerierung, Fußnotenverwaltung etc. sollen ja durchgängig bleiben… Und funktioniert das auch im Preview?

Fragen über Fragen. Ein Blick in das Handbuch hilft hier manchmal weiter. Hier wird jetzt hoffentlich deutlich, daß es wirklich eine große Hilfe ist, wenn alle zu einem Text gehörende Files in einem Unterverzeichnis zusammen abgelegt werden können. Beim Einsatz der Textverarbeitung von ‚Mini Office II‘ habe ich für das ACTION!-Handbuch z.B. 4 Diskseiten zu je 128K gebraucht. Zum Preview und zur Bearbeitung bzw. für den Druck hatte ich mir diese Masse an Textfiles dann in die RAM-Disk geschoben und zusätzlich auf zwei 1050er verteilt.

Bei ‚Austro.Text‘ ist nicht einmal das möglich, da meines Wissens bisher kein RAMDISK-Treiber für das AustroDOS existiert. Und schon wird man langsam zum Disk-Jockey… Zum Glück gibt’s ja das ‚HDI‘! Bei mir laufen von Anfang an zwei 1,44MB-TEAC-Drives an diesem wirklich tollen Hardware teil. Was liegt also näher, als auf einem Laufwerk das Programm und auf dem anderen die Textfiles, schön geordnet in eigene Unterverzeichnisse, abzulegen.

Da für ein derartiges Hardwareteil auch ein professionelles DOS erforderlich ist, kommt hier nur noch SpartaDOS in Betracht. Anfänglich arbeitete ich mit MyDOS, das aber doch viele Probleme aufwirft. Es hat nie den RAMDISK-Treiber fehlerfrei dabei, den man gerade braucht. Außerdem benötigt es für viele Texter einfach zuviel Speicher. Die Verzeichniskennung per Doppelpunkt akzeptieren manche Programme nicht usw. Als dann ‚SpartaDOS X‘ herauskam, waren damit zumindest für mich fast alle Probleme beseitigt. Folgende Vorgehensweise hat sich im Laufe der Zeit bei mir eingespielt:

– Formatieren der 1,44MB-Disk mit SpartaDOS
– Anlegen des gewünschten Unterverzeichnisses, z.B. ACTION
– Starten der Textverarbeitung per Batch-Datei – Arbeiten und Speichern.
Speichem bzw. laden!., von Textfiles ist leider nicht so bequem. Da fast alle Programme auf den ATARI-Standard DOS 2.0/2.5 zugeschnitten sind, bekommt man kein Auswahlmenü angezeigt, in dem man ein Unterverzeichnis Anwählen kann. Eine Ausnahme stellt hier ‚Turboword 80+‘ für die XEP80 dar. Oft kommt dann noch die Beschränkung auf maximal ‚8.3‘ Stellen bei der Eingabe des Filenamens hinzu. Aber mit kurzen Namen bei den Unterverzeichnissen und Platzhaltern kann man dann doch einigermaßen arbeiten. Verzeichnisfreaks, die über mehrere Grenzen springen wollen, tun sich da schwer. Zwar akzeptieren viele Programme e Eingabe von ‚>‘ und ‚<‚ als Pfadangabe für Sparta-DOS, springen aber nicht in die CIO ein, wie sich das für ein sauber programmiertes Stück Anwendersoftware gehört, sondern pfuschen irgendwo in die SIO hinein und greifen direkt auf Laufwerk Nr. 1 zu. Eine besondere Gemeinheit ist dann noch der Verzicht auf Sektoren mit 256 Bytes wie z.B. bei ‚Mini Office II‘. Schon hagelt es Fehler und das Programm verabschiedet sich…

Nein, nein! Halt, noch nicht den PC einschalten!!! Auch hier gibt es Hilfe. Unter den klassi
schen Textverarbeitungen lassen sich der ‚ATARI Schreiber, der ‚ATARI Writer ‚Turboword 80+‘, ‚XLEnt 1st Wordprocessor und ‚TextPro‘ ganz gut für die Benutzung des ‚HDI‘ und ‚SpartaDOS X‘ anpassen. Man muß halt nur wissen, in welchem Unterverzeichnis der gesuchte Text gespeichert ist. Ein weitere Betrachtung soll den Print-Prozessoren gelten. Als ‚Daisy Dot‘ vor ca. 9 Jahren erstmalig erschien, war das ein revolutionäres Programm. Durch Nutzung der Grafikfähigkeiten eines 7-, 8- oder 9-Nadeldruckers ließen sich Texte und bald auch eingebundene Grafiken mit maximaler Auflösung drucken.

Die vorläufige Spitze dieser Entwicklung stellen ‚Daisy Dot III‘ und vor allem ‚Sprint XL‘, die Jahresgabe 91/92 des ABBUC e.V., dar. Zur Generierung von Printfiles für diese Programme lassen sich nicht nur Te
xtverarbeitungen sondern auch sogenannte Editoren einsetzen. Aus dem PD-Bereich bekannt ist sicher der ‚Compy Shop-Editor‘, der auch auf dem ‚HDI‘ mit Unterverzeichnissen arbeiten kann. Ich persönlich benutze dazu am liebsten den Editor aus der ACTION!-Cartridge, der reinen ATASCI I-Code erzeugt und keine Transformationen mehr durchlaufen muß. ‚Sprint XL‘ und der hervorragende ‚E24-Editor‘ dazu stammen von Martin Fähnrich, laufen sehr gut auf dem ‚HDI‘ und erlauben qualitativ die besten Ausdrucke auf dem ATARI-8-Bit System. Vor allem die Verwendung von Grafiken der Formate PIC, PI3 und ART machen hier die Spitzenstellung aus.

Genial wäre es natürlich, wenn unter dem Motto ‚Back to the Roots!‘ mal ein Profi der Programmierkunst ein DTP-Programm für den XL/XE mit mindestens 256K ZRAM entwickeln würde. Kohle läßt sich damit sicher nicht in großem Stile machen. Aber die Genugtuung, auf einem bald 20 Jahre altem Rechnerkonzept so etwas realisiert zu haben, sollte doch mehr reizen, als das Basteln an einer Demo!

Ein sehr guter Ansatz dazu war mal das ‚DESKTOP ATARI‘ von HBSF-Soft aus Berlin, das 1989 auf den Markt kam. Schade, daß keine Weiterentwicklung stattfand. Nachdem jetzt der ‚Ist XLENT Wordprocessor‘ in der Version 2.1 als Jahresgabe 1995 desABBUC jedem Bit Byter zuging, schlage ich vor, einen Workshop dazu im Magazin und eventuell auch in der Club-Mailbox einzurichten. Standardisierte Briefköpfe, Layouts für Zeitungen, Magazine, Broschüren sowie Druckerkonfigurationen fürjeden Zweck und jedes Modell sollten ein weites und interessantes Arbeitsfeld darstellen. Standardmäßig hängen an meinen XL entweder ein guter alter 1027 oder ein nicht ganz so alter Citizen 120 D. Mit etwas Geduld kriege ich auch noch den HP500 dazu, mit dem XL zu harmonieren. Also, schreibt mir eure Tricks, Tips und Fragen.

In diesem Sinne und Good Byte
Walter Lojek
Dömitzer Straße 9
29456 Hitzacker

Poesie & Lyrik

Im Nachfolgenden 3 Gedichte von Falko Hamann

Danke XE
Es ist ziemlich spät, als ich zum Fenster rausschaue. 4 Stunden von irgendwann und ich spreche mit meinem XE wie mit einem guten Freund. Du und ich wir, haben schon viele Situationen gemeistert. Und ohne dich Wäre ich manchmal wahrscheinlich auf den Bauch gefallen. Danke XE, auf dich war immer Verlaß. Du hast es immer geschluckt wenn ich dich geprügelt habe. Trotzdem wir haben uns immer gut vorstanden. Es war als wenn du gewußt hättest, daß mich die Termine drücken. Du hast mich nie hängen lassen. Viele Jahre lang brav geackert. Nie ne große Panne, mal nen Absturz OK. Aber sonst…
Danke XE, auf dich war immer Verlaß.

Und jetzt kurz vor Mitternacht kommt’s einfach über mich, es war unser letztes gemeinsames Spiel. Ich muß mich von dir trennen, meine Eltern wollen wir nen PC kaufen. Ich bin mal gespannt was das für’n Ofen ist. Ich trenne mich nicht gern von dir. Das kannst du mir glauben. Vielleicht ist der Typ bei dem du demnächst stehst ja ganz OK. Gleich werd ich dich zum letzten mal abschalten. Goodbye, mach’s gut alter Kumpel.
Danke XE, auf dich war immer Verlaß.

Ich bin ein gefangener…
Ich bin ein gefangener der Computer Games, das zocken läßt mich nicht mehr los.
Ich bin ein gefangener der Computer Garnes, spiel viel zu oft und viel zu lang.
Ich bin ein gefangener der Computer Garnes, ja ich bin mit den Garnes zu oft allein.
Ich bin ein gefangener der Computer Garnes, doch ich kann ohne sie nicht mehr sein.
Viele Jahre spiele ich schon und habe den Computer oft verflucht. Trotzdem bin ich dabei glücklich, hab nie was andres gesucht. Geh ich dann auf die Reise von der man nicht wiederkehrt, ja dann bitt ich meine Freunde meißelt mir in meinen Stein.
Ich bin ein gefangener der Computer Garnes, das zocken läßt mich nicht mehr los.
Ich bin ein gefangener der Computer Garnes, spiel viel zu oft und viel zu lang.
Ich bin ein gefangener der Computer Garnes, ja ich bin mit den Garnes zu oft allein. Ich bin ein gefangener der Computer Garnes, doch ich kann ohne sie nicht mehr sein.

Wir sind die User
Sie lieben den Compi, ne große Festplatte, die langen Stunden bei nem guten Spiel. Sie chatten vom Nordkap bis Beirut mit brennenden Augen im Monitorlicht. Der Compi läuft stolz bei Nebel und Regen manch Mädchen wartet vergebens auf sie. Sie bringen die Daten bei glühender Leitung, landauf und landab bis hinunter ans Meer. Wir sind die User, halten zusammen mit Herz und Verstand. Wo Compis laufen da ist unsre Heimat, wir legen den Joystick niemals aus der Hand. Die User sind einfache ehrliche Leute, wo immer sie hinkommen da kennt man sich aus. Sie kommen aus Bayern und Schwaben aus Schleswig und Friesland und sie gluten vor Sehnsucht sind sie weg von zuhaus.
Die Welt braucht die Helden unzähliger Spiele, sie wissen in Technik immer gut bescheid, Und wo sie sich treffen da redet und grüßt man, für sie gibt’s immer was zu tun.
Wir sind die User, halten zusammen mit Herz und Verstand, wo Compis laufen da ist unsre Heimat, ‚ wir legen den Joystick niemals aus der Hand.

Arbeiten mit dem Atari Bus – Teil 4

6. Interface für PC-Karten

Nun wagen wir uns mit der PIA an ein größeres Projekt, das wegen der großen Menge von billiger Hardware sehr attraktiv sein dürfte: Eine Interface für PC-Karten. Das Interface ist keine vollständige Emulation des PC-Busses. Dies wäre zuviel Aufwand. Es werden jedoch die gebräuchlichsten Leitungen abgefragt bzw. erzeugt. Man kann deswegen ohne Probleme eine Hercules-Karte ansteuern. Kaum eine Karte braucht alle Leitungen des Busses. Ein MFM-Controller, Floppy-Controller etc. müßten ebenfalls ansteuerbar sein. Steueradressen: (stattCCTL istauch $D100 möglich)

PIA1
(CCTL+A5):
PC-Bus Atari-Adressen
PORTB D0-D7 $D521/

54561

PORTA A16-A19 $D520 /

54560

CA2 /MEMW $D522/

54562

CB2 /MEMR $D523/

54563^

PIA2
(CCTL+A6)
PORTA AO-A7 $D540/

54592

PORTB A8-A15 $D541/

54593

CA2 /10W $D542/

54594

CB2 /10R $0543/

54595

(Tabelle 7)

Bedienung:
Vor allem: Reset am PC-Bus auslösen. Man programmiert PA4 auf Ausgabe und setzt ihn kurz auf „high“ und dann wieder auf „loW. Wenn man die Karte bedient, müssen bei der Initialisierung alle CA2/CB2-Leitungen „High“-Pegel haben. Man geht dann so vor: LSB in PORTA von PIA2 schreiben MSB in PORTB von PIA2 schreiben Segmentadresse (0-15) in PORTA von PIA1 schreiben (damit kann man nun 1 MByte ansteuern) Schreiben:

PORTB von PIA1 auf Ausgabe programmieren Daten in PORTB von PIA1 schreiben CA2 von PIA1 (/MEMW) oder PIA2 (110W) auf „Low“ schalten „und dann wieder auf „High“-Pegel zurückschalten “ Lesen: PORTB von PIA1 auf Eingabe programmieren CB2 von PIA1 (/MEMR) oder PIA2 (/10R) auf „Low“ schalten PORTB von PIA1 lesen CB2 von PIA1 oder PIA2 wieder auf „High“-Pegel schalten

Spieleecke

Hallo Leute
Heute der fünfte Teil meiner Spielecke. Ich wünsche Euch viel Erfolg und Spaß mit meinen Tips. Also los geht es:

LASER -MAZE VON KE-Sort Hier sind die letzten Codewörter:
01. LASER 02. HYPER 03. SPACE
04. DIGIT 05. TUNED 06. ATARI
07. MARIO 08. TECNO 09. SOGON
10. BASIL 11. LEVEL 12. NODUL
13. HOOCH 14. HONEY 15. ELEGY
16. DEATH 17. CACAO 18. CABAL
19. BIGOT 20. AGAIN 21. HAITI
22. INDIA 23. JESUS 24. KOREA
25. CHINA 26. BUSHU 27. MONTY
28. NANCY 29. CAMEL 30. SARAH
31. WALES 32. TINES 33. WHIZZ
34. TITAN 35. SYNTH 36. STORM
37. SHAVE 38. SHARK 39. ROUTE
40. PIECE 41. PINCH 42. OSCAR
43. OTTER 44. MAJOR 45. LOVER
46. LUCID 47. KNAVE 48. LABEL
49. INPUT 50. SUPER

DRAG vom KE-Son
Hier sind die erste fünf CODEZAHLEN
00000, 47938, 94183, 52396, 26564
die letzten vier Codezahlen gibt es in der kommenden Ausgabe.

DONKEY KONG VON: Nintendo
Editor:
Sektor:21 Byte 108 von 02 in 05=Leben

JAMES BOND VON: PARKER BROTHERS
Editor:
Sektor:42 Byte 25 von 05 in 06=ue Leben für beide Spieler

SUBMISSION VON PETER
Editor:
Sektor:88 Byte 39 von 13 in 16=6 Leben Sektor:88 Byte 39 von 13 in 26=22 Leben
Sektor:88 Byte 39 von 13 in 36=40 Leben Sektor:88 Byte 39 von 13 in 99=137 Leben

CANYON CLIMBER VON: TOM FERRIS
Editor:
Sektor:8 Byte 108 VON 03 in 1E=30 Leben Sektor:8 Byte 108 von 03 in 3C=60 Leben Sektor:8 Byte 108 von 03 in 63=99 Leben Sektor:8 Byte 108 von 03 in FF=255 Leben
Das war es für heute. Ich habe alle Programme selbst ausprobiert.

* GOOD Byte *
DIETMAR

BERICHTIGUNG MEM-LAND VON KE-SOFT
Heinrich Lorenz aus Dörfles-Esbach schickte uns folgende Korrekturen der Codeworte zu Zebu-Land zu:
NICHT Sondern:
04. BONG BONK
17. TONN TOON
20. ARCH ARGH
45. ONNO ONKO

PC-XFormer

In letzter Zeit hat man viel über den PC XFormer, einen ATARI 130 XE Emulator lesen können. Damit konnte man (fast) alle Programme unseres geliebten 8-Bitters auf dem PC wie gewohnt benutzen. Bis auf den Nachteil, daß es nicht gerade leicht ist, die ATARI-Software von der 5,25″ Diskette auf den PC zu bringen, zumal auch noch alles in XFD-Dateien, die ein virtuelles Laufwerk darstellen, umgewandelt werden mußte. Das bedeutet, erstmal die Files einzeln irgendwie auf den PC zu kopieren (meistens mit SIO2PC, Turbo – Unk oder über die ATARI & PC Diskette (ABBUC PC-Bibliothek #346)).

Für den ST XFormer, also den gleichen Emulator für die ATARI ST Serien, gab es bereits 1988 ein Kabel, so daß man ein ganz normales ATARI-Laufwerk (1050 o.a.) an den ST anschließen konnte. BRANCH Always Software, die Produzenten des PC Xformer, haben dieses Kabel jetzt für den PC entwickelt. Das XFormer-Kabel schließt man am einen Ende an ein ATARI-8-Bit Laufwerk (wie zum Beispiel 810, 1050, XF551 oder auch Rana, Indus GT, letztere sind mir zwar nicht bekannt, anscheinend aber in Amerika verbreitet).

Das andere Ende des Kabels wird an den Druckerport des PCs gesteckt. Eine speziell angepaßte Version des PC XFormers erlaubt den direkten Zugriff auf das so an den PC an-geschlos-sene ATA-RI-Lauf-werk. Somit kann man über den Emulator direkt auf die ATARI-Disketten zugreifen.

Da die Disketten nicht mehr emuliert werden, stehen einem alle Programme auf Diskette zur Verfügung. Auch ein Kopierschutz kann damit hardwaremäßig keine Probleme mehr machen, da die Originaldiskette im Originallaufwerk getestet wird (einziges Problem kann noch die Zeitmessung sein, die unter dem Emulator möglicherweise verfälscht ist). Auch der Datenaustausch mit echtem ATARI-Computern ist problemlos möglich, da man ja auf originale ATARI-Laufwerke zugreift.

Ich denke, daß dieses Kabel die Verbindung zwischen dem Emulator auf dem PC und dem ATARI dadurch erleichtert wird. Trotzdem sind mir zwei Kritikpunkte eingefallen, die ich nicht unerwähnt lass
en möchte:

1. Das Kabel ist NICHT kompatibel mit dem SIO2PCKabel. BRAsoft erklärte dies damit, daß das SIO2PCKabel nicht für den Anschluß einer ATARI-Floppy gedacht ist. Schade, weil doch beide Kabel die gleichen Steckverbindungen benutzten.
2. Das angesprochene Laufwerk kann nicht vom PC DOS angesprochen werden, sondern „nur“ aus dem PC XFormer.

BRAsoft hat auch nicht vor, einen Treiber zu schreiben, um das ATARI-Laufwerk über das XFormer-Kabel in das PC-Dateisystem einzubinden. Aber vielleicht findet sich ein Bit Byter ja dazu bereit, einen entsprechenden Treiber dafür zu schreiben. Zugegeben, das ist sicherlich nicht leicht, da die Diskettenformate verschieden sind, aber träumen wird ja wohl erlaubt sein….
Fazit: Auch wenn ich mir gewünscht hätte, die gleiche Funktionalität mit dem SIO2PC-kabel erreichen zu können (aber BRAsoft kann ja nichts dafür, daß man beim SIO2PC nicht an Floppyanbindung gedacht hat), denke ich doch, daß das Kabel eine gute Investition für diejenigen unter Euch ist, die sowohl einen PC als auch einen ATARI 8-Bitter (zumindest ein Laufwerk) zu Hause stehen haben.

Der ABBUC plant bei entsprechendem Interesse, eine Sammelbestellung für dieses Kabel zu tätigen. Weitere Informationen bitte dem INFO-Text auf der Magazindiskette entnehmen.
Thomas Rosanski

Anmerkung: Da das Kabel erst im Februar auf der ATARI Computer Show in Houston, Texas erhältlich sein wird, stammen alle Informationen vom Hersteller BRAsoft. Nachzulesen im Internet unter http://www.halcyon.comibrasoft/xformerhtml#CABLE

Demo Kurs 3

Hallo im neuen Jahr zum dritten Teil des Demo-Kurses

Es haben sich im Eifer des Gefechts einige Fehler in den abgedruckten Source-Code eingeschlichen. Versierte Programmierer haben den Fehler sicher gefunden: Unterprogramm Scroll: Nachdem das Hibyte der Scanline aus der Tabelle „fonth“ geholt wurde, muß dieses natürlich auch in das Hibyte von v0 geschrieben werden. Es muß also „sta v0+1“ heißen statt „sta v0“.

Das Thema Scrolling ist ja noch nicht abgeschlossen, wenn man beim XL überhaupt von Abschließen sprechen kann. Jeder auch noch so gute Effekt läßt sich noch nach Jahren verbessern oder optimieren. Im letzten Teil haben wir uns ein wenig mit den „Standard-Features“ der XL-Hardware bez. Softscrolling beschäftigt. Diesmal werde ich noch kurz auf das vertikale Scrolling eingehen. Im Prinzip ist dies genauso zu bewerkstelligen wie das horizontale Scrolling:

}-1.721.01CGIMOIN.N.9:

Man verändert die LMS-Adresse der Displaylist entsprechend der Zeilenlänge und scrollt dementsprechend nach oben oder nach unten.

Beispiel:
unten cic
Ida Ims
adc #48;bei Zeilenlänge von 48 Bytes,d.h. Overscan sta Ims
Ida Ims+1 adc #0
sta Ims+1 rts

Der Schirm „bewegt“ sich jetzt nach oben, d.h. wir scrollen nach unten. Ich weiß, mit den Bezeichnungen für Oben und Unten kann man durcheinanderkommen. Einigen wir uns auf folgende Definition. Ich spreche von „nach oben“, wenn von der LMS-Adresse Werte subtrahiert werden, und entsprechend „nach unten“,wenn Werte dazu addiert werden.

oben sec
Ida Ims
sbc #48 sta Ims
Ida Ims+1 sbc #0
sta Ims+1 rts
dlist dfb $70,$70,$70,$42
Ims dfw screen
dfb $41
dfw dlist
screen asc $dies ist ein kleiner test für das vertikale scrolling$

Wie schon aus dem zweiten Teil des Kurses bekannt, geschieht das Scrollen auf diese Art sehr schnell. Verlangsamt man das Hochzählen der LMS-Adresse, so ruckelt das Scrolling doch arg. Wie schon beim horizontalen Softscrolling ermöglicht der Antic ein sanftes Scrolling durch das Vscroll-Register $d405. Analog zum Hscroll-Register $d404 werden die Zeilen, bei denen das 5-Bit in der Display-List gesetzt ist, um die Anzahl der in dem Vscroll-Register stehenden Rasterzeilen nach oben verschoben. Die letzte Zeile, die so verschoben wird, ist die Zeile, bei der das Vscroll-Bit nicht mehr gesetzt ist! Vergißt man dieses Bit zu löschen, so „hüpften“ alle nachfolgenden Zeilen in das Bild hinein, was doch sehr stört… Schauen wir uns das ganze doch etwas näher an:

Beispiel-Displaylist:
dlist dfb $70,$70,$70,$42 ;gibt den Titel aus dfw titel
dfb $70,$52 ;horizontale Laufschrift
I ms1 dfw scrolltext
dfb $70,$62;vertikale Laufschrift
Ims2 dfw scrolitext2
dfb $22,$22,$22,$22,$22,$22,$22,$02
;9 Zeilen Gr.0
dfb $70,$46
;noch eine Gr.1 Zeile am Schluß
dfw bordertext
dfb $41
dfw dlist
titel asc $Kleines Demobeispiel aus dem Kurs 3$ vbi jsr vscroll
jmp $e462
vscroll

Soviel zum vertikalen Scrolling. Doch gestattet mir einen kleine Anmerkung zu Vscroll. Wie bekannt ist, kann der Antic nur 4kbyte Ramspeicher am Stück verwalten durch einen LMS-Befehl. Gerade beim vertikalen Scrolling ist es wichtig, darauf zu achten, daß diese Grenze nicht überschritten wird. Im obigen Beispiel wird durch die Displaylist 9 Zeilen dargestellt. Es wird aber nur zu Beginn dieser 9 Zeilen der Bildspeicherzähler durch den Lms-Befehl geladen. Die nachfolgenden 02 sagen dem Antic nur, welche Grafikstufe er darstellen soll. Die LMS-Adresse wird automatisch durch den Antic ermittelt. Jetzt bekommen wir aber ein Problem, wenn wir einen größeren Block als 4096 Zeichen scrollen möchten.

Nehmen wir an, wir befinden uns am Ende eines solchen 4k-Blockes und diese Adresse steht in der LMSAdresse der Displaylist. Die nachfolgenden 8 Gr. 2 Zeilen werden nun aber falsch dargestellt, da der Antic zwar korrekt die Offsets für die Zeilenlänge dazu addiert (32,40,48 Bytes), nur eben bis zu 4k. Wird die Grenze überschritten, so werden die oberen Bits nicht berücksichtigt und es wird der falsche Datenblock angezeigt. Ein ähnliches Problem existiert sowohl bei Zeichensätzen (können nur an einer 256-Byte Grenze beginnen) oder bei Player/Missle Grafik (nur an 4k-Grenzen).

Die Register Hscroll und Vscroll sind auch bestens geeignet zur pixelgenauen Positionierung einer Grafik o.ä.. Man denke nur an den ersten Teil des Demo-Kurses, an das Verfahren zur Ermittlung der Pixel-Position im Ramspeicher. Man kann im Prinzip genauso beim Scrolling vorgehen.

Angenommen wir haben eine Hires Grafik im Speicher, die wir anhand einer Positionstabelle (das kann ein Kreis o.ä. sein) sanft über den Screen scrollen möchten. Jetzt kann man im Prinzip genauso vorgehen wie bei der Pixel-Routine. Man ermittelt durch Division der x-Koordinate durch 4 bzw. 8 (je nach Grafik-Modus) den Byte-Wert, der in die LMS-Adressen der Displaylist geschrieben werden muß. Ermittelt man nun genau wie beim Plot-Befehl die Pixel Nummer, so kann man direkt in das Register Hscroll (analog Vsroll, wobei Vscroll bei Hires-Grafik keinen Sinn macht…) den Wert schreiben, da ja mit dem Register genau pixelweise die Scanline verschoben werden kann. Statt einen Wert in das Bildschirmram zu schreiben wiebeim Plotten, wird der Wert in Hscroll geschrieben. Nähere Angaben können bei mir angefordert werden.

Im Moment möchte ich auch nicht weiter auf das Scrolling eingehen. Im vierten Teil werden wir uns um sogenannte Player-Missle-Scroller kümmern. Dabei müssen wir auch das „per Hand“-Scrollen behandeln. Aus Aktualitätsgründen möchte ich die Entstehungsgeschichte der meiner Titel-Demo für das Abbuc-Mag 44 erzählen: Ich plane seit einigen Monaten ein Megademo. Einige Bitbyter haben auf der JHV ein Preview gesehen (Gerenderte Grafik, 256 Farben, hüpfender PM-Scroller,…). In dem Eingangsscreen habe ich anhand einer Pascal-Routine mich an „Plasma-Clouds“ in 256 Farben versucht. Leider war bzw.
ist meine Routine doch etwas zu langsam. Sie schafft nur 20×40 Pixel in einer einigermaßen erträglichen Geschwindigkeit. Nach einigen Tagen nach der JHV kam mir die Idee mal wieder ein Titel-Programm zu schreiben. Ich habe mir überlegt, warum nicht die Plasma-Routine nehmen und sie auf den „VGA“-Modus des XLs zu modifizieren.

„VGA“-Modus? Naja, unter einem VGA-Modus verstehe ich eigentlich nur einen Grafik-Schirm (welche Auflösung auch immer…) bei dem die Farbe des Pixels anhand eines Bytes gesetzt wird. Die alte Routine arbeitete in Gr.9 mit einen Haufen Dli’s, um die gerenderte Grafik darzustellen.

Wie wir wissen, ist es möglich mit dem XL mehr als 16 Farben gleichzeitig darzustellen. Folgende GTIA-Modi sollten bekannt sein, nämlich 9+11. In GTIA 9 habe ich16 Helligkeitsstufen und in GTIA 11 16 verschiedene Farben, aber nur eine Helligkeit. Hmmm. Durch einen simplen Display-List-Interrupt schalte ich zwischen diesen beiden Modi des GTIA um. Im PM-Prioritätenregister werden nicht alle Bits für das Festlegen der Prioritäten gebraucht, so daß die Bits 7+6+5 eine besonderen Bedeutung bekommen haben. Diese Bits wählen die GTIA-Modi an. Um nicht Interlace mit dem „flackernden“ Nachteil benutzen zu müssen, dachte ich mir, verwende doch dieses Verfahren:

1. Dli- wird auf 16 Farben-Darstellung umgeschaltet.
2. Dli- nun auf 16 Helligkeiten umschalten.
3. Dli- auf 16 Farben
4. Dli- auf 16 Helligkeiten
usw.

Wechselt man dieses Verfahren auf das ganze Bild an, so kann der XL nun 256 Farben quasi gleichzeitig darstellen, denn das menschliche Auge verschmilzt diese zwei Rasterzeilen zu einer und wir wir merken nur bei genauem Hinsehen, daß hier jede Rasterzeile umgeschaltet wird. Das Programm Apacview benutzt u.a. dieses Verfahren.

So, daß dies natürlich für Gr.9-Files bzw. APC-Files (Apacview), angewendet werden kann, ist klar. Ich überlegte mir, wie ich den das lästige Pixel-Umrechnen auf 256 Farben aus der alten Plasma-Routine durch Verwendung von Gr.0 umgehen könnte. Warum nicht einen Text-Modus nehmen, der nicht so rechenzeitaktiv ist, wie die Hiresstufen? Schon damit würde die Routine schneller werden… Auch würde das lästige Umrechnen entfallen, weiter sind die Pixel symetrisch, was auch nicht schlecht aussieht… Das obige Verfahren läßt sich auch auf Gr.0 anwenden… nur mit folgenden Unterschieden:

-Ich kann nur 128 Farben darstellen (statt 256), da ich in Gr.0 128 verschiedene Zeichen umdefinieren kann.
-ein „Pixel“ besteht jetzt aus einem XL-Zeichen.

Es ist nun egal, welchen Farbwert ich in das Bildschirm-RAM reinschreibe, es erscheint mit dem neuen Zeichensatz das richtige Pixel. Die Auflösung beträgt nun sage und schreibe 40×20 Pixel. Meine Routine verwendet eh nur 20×20 Pixel. Gesagt getan, die Routine wurde an einen 40×20 Gr.0+ Screen angepaßt. Sie war zu meiner Verwunderung so schnell, daß ich wieder einen „Bremser“ hab einbauen müssen, damit sie nicht zu schnell läuft… Auch dachte ich, daß die Auflösung dann doch zu grob sei, aber urteilt selber. Ich finde, sie ist nicht zu grob. Nur lief sie in der linken Hälfte des Screens. Mir viel nichts ein, was ich auf der anderen Seite aus „Symetriegründen“ einbauen könnte.

Auf der CD-ROM v. den „Schreurs“ fand ich ein XFD-File, daß einen langen Wunsch von mir erfüllte, nämlich einen Hires-Font-Wandler, der „intelligenter“ ist, als mein Turbo-Basic-Derivat. Auch muß ich nicht erwähnen, daß er wegen Assembler um einiges schneller ist, um „Warp“-Längen. Mit diesem Logo-Wandler habe ich ein sehr schönes Koala-Hires Bild in 6 verschiedene Zeichensätze umgewandelt. Der Vorteil ist ganz klar. Eine Hiresgrafik umgepackt benötigt 7680 Bytes, 6 Zeichensätze+Bildschirmram weniger.

Umgepackt ergibt sich schon ein Unterschied, gepackt aber erst recht! Von den eingesparten Taktzyklen nicht zu sprechen. Außerdem ist es nicht so einfach das Bild zu „rippen“… Weiter konnte ich einen „Pac-Man“-Effekt einbauen. Die Grafik wird für ein paar Sekunden angezeigt und wird dann zeilenweise bidirektional gelöscht. Durch Verwendung eines Text-Bildschirms kein Problem, einfach LDA #0, STA (v0),y… Aber nur eine Grafik darzustellen, war mir dann doch etwas zu wenig. Naja, man könnte ja wie schon von mir gewohnt, einen „Player“-Text über die Grafik legen. Dazu schrieb ich mir ein Turbo-Basic-Programm, daß einen normalen ASCII – Text in eine Player-Missle-Grafik umwandelte. Dazu werden im Speicher zwei 4-Bit-breite Zeichensätze aufgebaut, die jeweils 4-Bits verschoben sind. In einen 8-Bit-Player passen ja zwei 4-Bit-Zeichen. So jetzt hatte ich also schon meine Titel-Page zum neuen Abbuc-Mag… War aber immer noch dürftig. Eine Grafik+Plasma-Clouds in Gr.0+.
Man könnte den PM-Text jeden Vbi zeilenweise von unten nach oben aufbauen. Gesagt getan, sah nett aus. Warum den PM-Text nicht per Line-Interrupt die berühmten Regenbogenfarben des XLs geben? Ich wollte aber nicht einfach alle Farben durchlaufen lassen, sondern alle sollten die gleiche Helligkeit haben. Dies ist auch kein Problem:

loop Ida vcount ;Nr. der Rasterzeile
sta wsync;auf Rasterstrahl warten
dc
and #$f0 ; Helligkeit ausmaskieren _ ora #8 ;nur mit Helligkeit 8
sta pmcol0 sta pmcol 1 sta pmcol2 sta pmcol3
Ida 541 ;bis paar Sekunden vorbei
;sind
bne loop

So, nach dem Einblenden und den Regenbogenfarben, sollte die PM-Grafik wieder gelöscht werden, da ich deren Speicherbereich für Tabellen benötige. Das Löschen sollte von oben nach unten geschehen, wie beim Aufbauen der PM-Grafik. Wären die Grafik gelöscht wurde, sollte das „Hires“-Bild zeilenweise gelöscht werden. Schließlich sollte man auch auf das Finetuning achten und dazu zählt einfach auch das Überblenden. Einfaches Umschalten finde ich ziemlich ruckartig und unsauber. Die Grafik wurde dann vom Bildschirm „gefressen“. Hmm. Jetzt stand ich vor dem Problem, einen lehren orangefarbenen Screen vor mir zu haben. Naja, umgeblendet wird durch eine einfache Technik. Man zählt die Hintergrundfarbe bis zur höchsten Helligkeit hoch und schaltet dann den Bildschirm ab. Jetzt kann man sich um die Initialisierung von Tabellen, Display-Lists, Player-Missles-Grafik, usw. kümmern, ohne Angst haben zu müssen, „man“ sieht was auf dem Schirm. Hat Man alles initialisiert, so zählt man die neue Hintergrundfarbe mit der höchsten Helligkeit zu der Helligkeit herunter, die man haben will. Natürlich jeden Vbi. So da stand ich nun, hatte mein „Hires“-Bild, die PM-Grafik und die Plasma-Routine in Gr.O+.

Übergeblendet wurde auch schon. Hmm, ich hatte noch nie einen sogenannten „Texter“
geschrieben, d.h. einen einfache Text-Routine. Mit einem einfachen Gr.O-Font wollte ich das nicht coden. Da ich noch zu der Zeit nur sehr wenige brauchbare Bigfonts hatte, kam mir der Beispielfont auf dem Logo-Wandler sehr recht. Der Texter war sehr schnell geschrieben, er macht nichts anderes, als einen Text langsam buchstabenweise aufzubauen. Hmm. Als Hintergrund habe ich nur einen rosa Bildschirm gewählt. Da ein Texter nur sehr geringe Rasterzeit beansprucht, dachte ich, warum nicht noch einen einfachen Sternenscroller einbauen? Dies ist einer der ältesten Effekte auf dem XI, da er einfach zu coden ist: Jede Rasterzeile wird eine andere x-Position aus einer Tabelle geholt und die horizontale Position des Players entsprechend gesetzt per Dli. Hier die Routine dazu:

tabinit Idx #191 ;192 verschiedene Sterne
.0 Ida 53770 ;Pseudozufallszahl ;holen (0-255)
sta postab,x
dex
bpl .0
rts
vbi jsr beweg
beweg Idx #191
.0 inc postab,x ;nach rechts bewegen
dex bpl .0
rts
dli pha txa
pha
Idx#191 ;192 Rasterzeilen
Ida #1 ;Sterne „einschalten“
sta grafp0 ;ins „Dma“-Register des ; Player 0
;durch verwenden des ;grafp0-Registers wird ein ;ganzer Bit-Streifen erzeugt ;ohne die Dma des Antics…
0 Ida postab,x ;Position des Sterns holen
sta wsync ;auf Rasterstrahl warten und ;mit sich mit ihm syncro;nisieren sta hposp0
dex
bpl .0
pla
tax
pla
rti

So, wenn der Text fertig aufgebaut wurde, wollte ich auf den Plasma umblenden… Da stand ich nun ich armer Tor… mit meinem Plasma in 20×20 Pixel… Was nun, eigentlich wollte ich einen „interaktiven“ Plasma – Effekt, d.h. die Parameter sollten vom Betrachter zu verändern sein, doch dieses Vorhaben lies ich fallen. Ich wollte mich auf meine Klausuren konzentrieren. Daß ich aber mehr an dem Titel programmierte als zu lernen, muß ich nicht erwähnen, oder? 😉 Der Plasma wurde so modifiziert, daß der XL die Parameter selber nach einige Sekunden ändert, um der Monotonie vorzubeugen.

So, unter dem Plasma war noch Platz, da ich grundsätzlich Overscan benutze, d.h. mehr als 24 Zeilen. In diesem Fall ging ich bei allem an die Grenze des Machbaren auf dem Xl. Der Antic ist immer nahe dran, das Monitorbild zu rollen, d.h. per Dlist stelle ich nahezu 256 Rasterzeilen dar (außer bei dem Athleten…). So ich habe also mindestens 31 Gr.O Zeilen Platz… abzüglich des Plasmas blieben noch 7 Zeilen zu füllen. Warum nicht mit einer Status-Zeile? Aber dazu mußte ich per Dli wieder auf Gr.O+ auf Gr.O umschalten, da kann man leicht mit den DIfs durcheinander kommen. Die Titel-Zeilen waren schnell in die Displaylist eingefügt… Warum nicht darunter einen vertikalen Scroller einbauen? Ich hatte bis jetzt in 5 Jahren nur einen vertikalen Scroller programmiert, also ran an die Bulletten. Wer vertikale Scroller programmiert, kennt das Problem des Reinhüpfens der letzten Zeile des Scrollbereichs… Also, immer daran denken! Das Scrollbit wieder Löschen in der letzten zu scrollenden Zeile! Voilla, kein Problem und kein Hüpfen mehr. Es wurde noch ein Dli eingefügt, der die Font-Farbe auf kontinuierlich auf schwarz ändert…. So „faden“ die Zeilen auf Schwarz. So, was blieb noch? Die leere Fläche neben dem Plasma… Auf dem ersten Mega-Mag fand ich eine geniale Musik, die ich mir „ausgeborgt“ habe… Wer auch immer diese geschrieben hat: the music in mega-mag one is superb! So jetzt hatte ich eine Musik, Plasma, Titel-Grafik, PMText, Texter, Vscroller, und ein leeres Feld neben dem Plasma, das förmlich danach schrie, gefüllt zu werden.

Beim Betrachten einiger Amigademos viel mir immer der Feuer-Effekt auf, der auch bei den XI-Demos „Joyride“ v. Hard und „Endless Dream“ von Zelax verwendet wurde… also konnte er so rechenzeitintensiv nicht sein… Er mußte etwas mit dem Antialiasing zu tun haben…

Nach diversen erfolglosen Studieren von Malprogrammen auf dem Amiga und STE fand ich zwar einige Programme, die Antialiasing („Unschärfen…“) unterstützen, aber damit kam ich immer noch nicht auf das Prinzip. Nur soviel war mir bekannt, man muß die Farben der Pixel verknüpfen und eine Zeile nach oben schieben. Doch wie. Einige Versuche in Turbo-Basic brachten zwar nette Effekte, die dem Feuer ähnlich sahen, doch es stellte sich heraus, das der angewandte Algorithmus gänzlich falsch war. Naja, kurzer Rede, kurzer Sinn. Nach einigen Stunden im IRC hab ich dann den entscheidenden Denkanstoß von TIN (Inter, Atari Falcon) bekommen. Man stelle sich folgendes vor: Die Zahlen bedeuten eine Pixel-Matrix und ihre Farbwerte. Man geht nun eine Grafik entlang und zählt die Farbwerte der Position umgebende Pixel zusammen und berechnet den Durchschnitt.

Diesen neuen Farbwert schreibt man die alte Position. Im obigen Beispiel würde die Formel dafür lauten: (1+2+3+4)/42. Doch auch diese Vorgehensweise bringt zwar einen netten Effekt, doch nicht den, den ich gewünscht habe. Beim Stöbern im Xf2ftp.oulu.fi Server fand ich einen Feuereffekt in PASCAL geschrieben. Dieser berechnete die Farbe so:

* (aktuelle Position Pos) 123

Die Formel blieb die gleiche: (1+2+3+4)/42. Dabei entsteht schon ein sehr schöner Feuereffekt. Nur sollte man, um ein Antialising zu verhindern, von der Farbe c4 einen Wert abziehen. Hier nochmals die allgemeine Schreibweise für einen Gr.O+ Schirm:

for y=1 to 24
for x=1 to 40
c=(peek(screen+x-1 +(y+1)*40)+peek(screen+x+ (y+1)*40+peek(x+2+(y+1)“40+peek(screen +x +(y+2)“40))
if c>0 then c=c-1 ; um Antialising zu verhindern poke screen+x+y*40,c
next x
next y

So, daß ist das ganze Geheimnis. Es gibt aber zig Varianten, welche Pixel ich in meine Berechnung einfließen lasse. Deswegen unterscheiden sich die Effekte in den Demos von Zelax und Hard. Weiter benutzen Zelax einen Gr.O+Screen, d.h. mit 16 Farben und einer Auflösung von 40×20 Pixel, Hard dagegen benutzen 80×80 Pixel. Man kann die Feuerroutine direkt „über“ den normalen Gr.O+ Schirm laufen lassen. Angenommen die Adresse (pos) steht im Zeiger VO. Dann kann man direkt über das Y-Register auf die einzelnen Pixel zugreifen. In Assembler sieht dann das so aus

Idy #39 ;Position links unter der aktuellen ;Position
Ida (v0),y ;Farbwert 1
Idy #40 adc
(v0),y iny ;Farbwert 2
adc (v0),y
Idy #120 ;Farbwert 3
adc (v0),y
beq .0 ;Farbwert 4
sec ; schon schwarz?
sbc #1
;c:=c-1 um antialiasing zu verhin;dem…
.0 Isr ;c=c/4
Isr
Idy #0 ;wieder in Buffer schreiben (oder ;direkt auf den Schirm…)
sta (v0),y nächstes Pixel…

So eine kleine Feuerroutine habe ich als Intro zum Intro geschrieben, die ziemlich geschwindigkeitsoptimiert ist! Vergleicht sie mal mit der von Zelax!

Den Geschwindigkeitszuwachs erreicht man
a) durch Reduzierung der abzuarbeitenden Zeilen (Zeilen, die auf jeden Fall schwarz bleiben, brauche ich auch nicht abarbeiten…) und
b) keine Synchronisation mit dem Vbi.

Die Routine ist eh schon sehr rechenzeitintensiv, als daß sie in den Vbi passen würde. Diese Feuerroutine hab ich sehr lange optimiert. Interessanter Weise entwickle ich ungeahnte Kreativströme in der Klausurzeit 😉 Eine frühere Version der gleichen Routine wird für das Auffüllen des leeren Fensters im Titel-Programm verwendet. Diese läuft sehr viel langsamer ab, da wenig Prozessorzeit zur Verfügung steht und sie nicht sehr auf Geschwindigkeit optimiert wurde.Weiter wurde schon eine Routine für den Grafik-Modus Gr.9+ entwickelt. Doch was ist Gr.9+?

Gr.9+ ist eigentlich ein „Custom“-Grafik-Modus, d.h. ein selbst definierter lm Grund ist dieser Modus ein Gr. 9 Schirm mit symetrischen Pixel, d.h. 1 Pixel ist 4 Bits Breit und 4 Bits „lang“. Zwar ist die Auflösung in die Y-Richtung etwas gröber als Gr.9 (50 statt 200 Scanlines), dafür sind die Pixel symetrisch, was bei einigen Effekten doch besser aussieht. Ich nenn diesen Modus auch „VGA“-Modus, da man fast einen Byte-pro-Pixel Modus hat (nibble-pro-Pixel).

So damit wäre eigentlich das Titelprogramm fertig… Gelinkt und gepackt wurde es mit dem Superpacker von BEWESOFT. Sample wurde vom ST abgespielt und auf dem XL gesampelt und nach dem Intro zum Titel abgespielt („Please wait…“). Dieses Mal gibt es leider keine Beispiel-Sourcen, da die sich wahrscheinlich eh keiner ansieht… wenn doch, so schreibt mit ne mail (e-mail oder snail-mail)…

So fertig ist ein Titeldemo für das Abbuc-Magazin (und fertig sind meine Nerven). Ich kann nur sagen, es hat immensen Spaß gemacht das Teil zu coden, aber dafür hat es mich einige Zehntel in meiner Diplomnote gekostet… (;-) naja, was soll’s)
Heaven c/ o Kaue Ate citaximilianme 753
7 577 2 d’Atzheint
email cbitetnetdotAlzp9001.tz.fA-fetzlteimde

PS: Kennt sich jemand mit dem Atari 7800 aus? Kann mir jemand sagen, ob man Eproms für das Teil selber kostengünstig herstellen kann. Mich würde das Teil wegen der leistungsfähigeren Grafik (als der XL…) zum Demo-Coden reizen. Mir würde ein Modul langen, daß ich immer wieder selber programmieren kann.

Atari XL/XE Messe in Hanau

Es ist wieder soweit! Am 12.5.1996 von 10:00 bis 1
6:00 Uhr findet wieder die alljährliche Atari 8-Bit Messe in Hanau statt! In der Gaststätte der Jahnhalle in 63450 Hanau finden sich User, Sammler und Freaks ein, um beim regen Treiben und Handeln rund um den Atari XL/XE dabei zu sein.

Alles, was in der Szene Rang und Namen hat, wird sich an diesem Tage als Aussteller mit den aktuellen Neuheiten und Sonderangeboten präsentieren.

Wie auch im letzten Jahr gibt es an jedem Stand ein Preisausschreiben, bei dem Preise direkt auf der Messe gewonnen werden können – für Besucher also jede Menge Möglichkeit, einiges mit nach Hause zu nehmen, gekauft oder gewonnen.

Natürlich wird KE-SOFT wieder eine besondere Überraschung für alle Besucher -diesmal aus dem Bereich der Spielhallenspiele – bereithalten.

Für das leibliche Wohl sorgt wie immer der Wirt der Jahngaststätte mit Pizza, Salat und anderen Speisen zu günstigen Preisen. Kurzum: Ein Tag, den Sie sich auf jeden Fall freihalten sollten, denn ein Besuch der Messe lohnt sich immer!
Weitere Informationen erhalten Sie unter Telefon 06181-20739.

Legalize

Vorwort:
Nachdem ich in der Vergangenheit über drei Jahre vergeblich mit dem Verlag Markt&Technik über Rechte an dem TurboBasic verhandelt hatte, habe ich es aus Frust aufgegeben, mich weiter mit dieser Angelegenheit zu belasten. Nicht so der Bit Byter Raimund Altmayer! Ich möchte mich an dieser Stelle für sein tolles Engagement bedanken.

Hier nun der Bericht von Raimund Altmayer (Member of R.A.M.)
Hallo Bit-Byter
Nachdem es in letzter Zeit ziemlich viel Unklarheiten in Bezug auf Turbo-Basic-XL gab, hab ich mir gedacht, daß es Zeit wird, diese Unklarheiten zu beseitigen. Diese Unklarheiten äußerten sich wie folgt:

1. Es erschienen merkwürdige Bootdisketten, die sich bei näherem Betrachten als gepatchtes Turbo-Basic entpuppten.
2. Viele Leute wissen nicht wie es mit den Rechten an Turbo-Basic aussieht.

Ich habe mich mit der Firma MCS (Micro-ComputerService) in Mainz in Verbindung gesetzt und eine längere Telefonrechnung produziert. Mit einem Ergebnis, das zumindest mich zufriedengestellt hat. Was ist jetzt herausgekommen ?

Rechtliches:
Die Rechte an Turbo-Basic-XL hat nach wie vor der Verlag Markt & Technik, obwohl es den nicht mehr gibt. Die Vertriebsrechte hat der MCS (MicroComputer-Service) Theden inne. Nach Übereinkunft mit Herrn The-den ist es mir gestattet Turbo-Basic-XL in einer speziell gepatchten Form (und nur in dieser) zum Selbstkostenpreis <siehe unten> weiterzugegeben.
Sollten andere Versionen außer dem original Turbo-Basic-XL und der gepatchten Version des ABBUC auftauchen so sind das RAUBKOPIEN !

Anm. der Redaktion:
Natürlich gilt das nicht für die selbst abgetippte Version aus dem Happy Compter Sonderheft

Das Handbuch:
Auf Wunsch kann eine gekürzte Anleitung bei mir bezogen werden. Dafür muß ich aber 0.15 DM pro Kopie in Rechnung stellen.Die Gesamtsumme beläuft sich auf 3,–DM inkl. Porto. Das ausführliche Handbuch ist in der Clubzentrale des ABBUC erhältlich.

Nach Übereinkunft mit Wolfgang Burger findet ihr das Turbo-Basic-XL auf der Rückseite der beiliegenden Magazindiskette. Somit entfallen zusätzliche Kosten. Sollte jemand unter Euch sein, der gerne das TurboBasic auf einer fertigen bootbaren Diskette mit einem schönen farbigen Label haben möchte, so kann er/sie sich direkt an mich wenden. Bitte die ABBUC-Mitgliedsnummer mit angeben.

Der Bezugskostenpreiss:
Der Preis setzt sich zusammen aus:
Diskette (0,50 DM),
Versandkosten (1,30 DM bei Warensendung oder 3,00 DM in Versandtasche) und eventuell die Mehrkosten für anfallende Kopien.

Adressen:
MCS (Micro-Computer-Service) Theden
Weichselstrasse 64
D-55131 Mainz
Tel.: 06131 – 995463

Highlander Soft
Raimund Altmayer
Brunostrasse 80
D-54329 Konz
Tel.: 06501 – 3678
E-Mail: 065014024@btxgate.de FidoNet: 2:2452/333.19@fidonet.org

ABBUC goes Internet

Liebe Bit Byter.
Dank der Hilfe von Stefan Lausberg geht das Zeitalter des Internet nicht spurlos am ABBUC vorbei. Wir sind dabei das ABBUC-Online aufzubauen. Mehr darüber im kommenden Magazin. Hier seht Ihr schon mal ein „Preview“ von ABBUC-Online! Wer einen Zugang zum Internet hat, kann das Ganze schon mal ausprobieren. Bitte wählt die Seite

http://wwwcip.rus.uni-stuttgart.de/~ inf11492/abbuc/

an. Demnächst sollen dort auch Vorabinfos vom neuesten Magazin zu finden sein.
Viel Spaß beim „Surfen“

Dies wird die offizielle ABBUC Homepage! In naher Zeit könnt ihr hier alle wichtigen News über den ABBUC e.V. lesen! Folgende Dinge. sind geplant:

ABBUC Infos & News
Magazin Online
Wichtige Adressen
ABBUC PD Liste
Regionalguppen des ABBUC
ATARI 8-bit Online Chat
Und hier könnt ihr noch eine Mail an die Clubzentrale schicken

Kaisersoft und Helmut präsentieren:

Atari 8bit Messe in Schreiersgrün (bei Chemnitz)

An alle XL-Händler, Clubs, Usergruppen und interessierten User!

Am Samstag, den 23.03.1996, findet in Schreiersgrün eine ATARI-8-Bit-Only-Messe statt. Sie soll allen Usern die Möglichkeit bieten, sich über Neuheiten zu informieren und Produkte direkt vor Ort zu testen. Natürlich soll auch der Informationsaustausch nicht zu kurz kommen.

Eine Standgebühr für Aussteller wird nicht erhoben, eine „Spende“ zum Schluß ist erwünscht (die Höhe liegt im eigenen Ermessen). Der Eintritt für Aussteller wie für Besucher beträgt die berühmte „symbolische Mark“.

Alle Händler werden gebeten, in unserem, in eigenem sowie im Interesse der Atari-Szene, Werbung für diese Messe zu machen, für ausstellende Händler ist sie sozusagen die „Standgebühr“.

Für das leibliche Wohl ist durch eine Gaststätte unter der Halle gesorgt. Wer also bei der Messe einen Stand ausrichten möchte, sollte sich möglichst schnell bei der angegebenen Adresse melden, damit wir einen Überblick bekommen, wieviele Aussteller wir erwarten dürfen. Werbung, Dekorationen, Kabel jeglicher Art sowie Mehrfachstecker sollen möglichst selbst mitgebracht werden, da wir nicht genügend Material für mehrere Stände aufbringen können.

Die Messe findet am Samstag, 23. 03.1996 statt (Ort: Siehe beigelegte Karte), Für Händler ist die Halle ab 8 Uhr offen, für Besucher ab 10 Uhr. Aussteller können auch noch im Verlauf des Tages kommen, mit d
em Platz wird man sich im Notfall arrangieren können. Ende der Veranstaltung ist voraussichtlich gegen 18:°° Uhr, ein anschließendes „gemütliches Beisammensein“ findet je nach Interesse statt.

Genauere Infos gibt es täglich von 17:“ – 21:“ Uhr (donnerstags ab 18:15) und sonntags von 12:“ – 21:“ Uhr unter der angegebenen Telefonnummer. Wenn ich nicht da bin und auch meine Eltern / mein Bruder nicht Bescheid wissen, hinterlaßt bitte eure Telefon-/Faxnummen ich rufe dann zurück.

Ich hoffe, daß ich möglichst viele von euch in Schreiersgrün begrüßen kann und verbleibe mit atarianischen Grüßen, Markus Römer

 

 

Dieses ABBUC Magazin erschien ursprünglich als Papierbeilage. Scan, OCR, Digitalisierung und Aufbereitung: Andreas Bertelmann