ABBUC Magazin 043

 


IMPRESSUM

(c) 1995 Atari Bit Byter User Club e.V. c/o Wolfgang Burger, Wieschenbeck 45

D­45699 Herten, Tel. +49 2366 39623 FAX +49 2366 39623

Email: 0236639623-0001@dtag.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

DAS TOR ZUR WELT

Oder: Warum soll man sich das Leben nicht schwer machen!

Der Atari 800 im Wohnzimmer und der PC im Schlafzimmer eine Konstellation, an der keiner von uns (meine liebe Frau und ich) etwas Erwähnenswertes fanden. Bis, ja bis ich mich in eine Abendschule einschrieb: Computer – Netzwerk – Administrator – Ausbildung. So fürchterlich der Kurstitel, so interessant und umfassend die Schulausbildung. Nach zwei Wochen Schulgang ein, Computer­Netzwerk muß her, Und sei es auch noch so klein. So ein bißchen Null-Modem-Verbindung reicht ja schon.

Wer wird also mit wem verbunden? Viele Möglichkeiten gibt es bei uns ja nicht:

  • Der CBM mit dem ATARI ST
  • Der ST mit dem anderen ST
  • Der ST mit dem PC
  • Der PC mit dem 800er

Der PC mit dem 800er – das wars!

Da gibt es doch ein Terminalprogramm das es praktisch für alle Computertypen gibt und untereinander kompatibel ist (das haben wir doch gelernt) so ein

Computer – Fossil aus der Urzeit:

KERMIT!!!

(wie lautet zur Prüfungsfrage KERMIT die richtige Antwort?):

KERMIT = Frosch aus der Muppetshow

KERMIT = Universelles, schnelles, asynchrones, zeichenorientiertes, portables Terminal-Programm zum Filetransfer

KERMIT = Altfranzösisches Wort, dessen Bedeutung ich vergessen habe.

(Bei der Prüfung wird natürlich nur die mittlere Antwort gewertet!)

Da gibt’s doch in einer PD Sammlung auch für den 800er einen KERMIT und im Atari Magazin war doch einmal eine Bauanleitung für ein RS232 Interface – ist doch keine sechs Jahre her. 😉 <– man merkt, der Netzwerkkurs wirkt, der Smily rutscht einem fast von selbst in die Tastatur.Das Atari Heft war bald gefunden, im Zuge des ABBUC Beitrittes (die Verbindung zu dieser Geschichte wäre zwar durchaus hübsch zwingend, ist aber nur zeitlich zufällig) gab es auch eine PD Liste. Und da war auch wirklich der KERMIT drinnen. Für mich war diese Möglichkeit einfach faszinierend. Einen 8-Bit Rechner mit einen 32-Bit Rechner mittels EINES Programmes, eben KERMIT zu verbinden.Der KERMIT für den Atari wurde 1984 geschrieben, meine PC Version stammt aus 1993 und grundsätzlich können die Programme miteinander. Also frisch ans Werk. Theo Schwacke kriegte eine PD Bestellung (aber wegen einer PD Diskette schreib ich doch nicht nach Deutschland, samt der Verrechnung und so, also wurde gleich einiges mehr bestellt). Joost Küp kriegte zur Vorsicht eine Bauplanbestellung, es könnten sich ja zu diesem Interface notwendige Änderungen ergeben haben – eine richtige Überlegung, wie es sich später zeigte – (aber wegen einer Bauplanbestellung schreib ich doch nicht nach Deutschland, samt der Verrechnung und so, also wurden gleich einige weitere Baupläne mitbestellt). Der Schilling rollte also schon etwas, bevor sich noch richtig was tat.

Diskette mit KERMIT war da, Bauplan war da (doch einige Änderungen gegenüber dem Heft – ich hab’s ja gewußt) – der Lötkolben kann angeheizt werden. Die Bauteile hatte ich mittlerweile besorgt. Etwas Kummer bereitete mir der Anschluß des Interface am Parallelbus. Mir graute vor einer mit ständigen Wackelkontakten behafteten Lösung und außerdem wollte ich einen Aufbau, der die Hauptplatine möglichst wenig mechanisch belastet.

In dem dicken Packen der von Joost Küp geordeden Bauplänen fand ich eine Kopie: „Erweiterungen am ATARI Parallelbus“ von Michael Pascher. Und da stand am Ende des Artikels, sozusagen als Post­skriptum: „Es passen z.B. APPLE Slot Stecker!“

Yeah!! Im Laufschritt zu meinem Elektronikhändler: „APPLE Slot Stecker, h’rnm…. tatsächlich, zwei habe ich noch!“ Alle zwei gekauft (wer weiß, was ich den 800er noch alles hinten anstecken werde). Obwohl -billig waren sie nicht. Aber sooo professionell!

Ein passendes Gehäuse hatte ich auch schon besorgt. Der Slot Stecker wurde daran so montiert, daß das Gehäuse nach dem Anstecken satt auf der Tischplatte aufsitzt und keine Platinenbelastung auf­treten kann. Eine mir wohlgefällige Lösung.

Über die Löterei bei dieser doch eher hardwareintensiven Lösung lange zu berichten wäre sicher fad. Aber: Letztendlich fand ich doch alle meine Fehler und es kam zu einer ersten Verbindung: ATARI ST mit dem 800er über Nullmodem. (ST deshalb, weil im Atari-Heft gleich ein diesbezügliches Programm abgedruckt war und bei mir der eine ST gleich neben dem 800er steht.) Hurra, die beiden verstehen sich (natürlich nicht absolut sofort, aber nach einigen Stunden hatte ich die Sache durchschaut und die richtigen Einstellungen vorgenommen.

Also, auf zum PC und eine Verbindung herstellen. (Nach Ausräumen des Bücherregals~ Verlegen der Nullmodernleitung in’s Schlafzimmer – ein Mauerloch gab’s schon- im Schlafzimmer möglichst getamte Verlegung zum PC, Einräumen aller Bücher, Beseitigung des Chaos im Schlafzimmer – alles in kaum 4 Stunden erledigt). Gut. KERMIT auf beiden Seiten „angeworfen“. Gut. Am PC (gelernt ist gelernt) alle Einstellungen getroffen. Gut. Am 800er nach einigen Mucken das Programm (mit dem speziellen Interface Treiber vom Atarl Magazin) installiert: Connect! Nix.

(Alle Einstellungen nochmals – mit leicht geröteten Wangen – kontrolliert) Connect! Nix. (Wie sagte Donald Duck in der unnachahmlichen Übersetzung von Frau Dr. Erika Fuchs: SEUFZ!!)

Na gut. Analysiert, studiert, verglichen, Theorien aufgestellt, verworfen. Gelesen: „Mein ATARI Computer“: Stichwort XIO: Für das 850er Interface (RS 232 Schnittstelle) gibt es die XIO Befehle mit den Nummern 32 – 40.

Peng! Das saß. Denn im Treiberprogramm des Atari Interface gibt es eine eigene Handlertabelle
, wobei die XIO Befehle 40 bis 42 definiert werden. Das heißt, das Interface ist NICHT zur 850er kompatibel. Deshalb läuft auch der KERMIT nicht. Denn der setzt auf dem 850er Treiberprogramm auf.

Ach du schöne…. !

Dann schreib ich eben den KERMIT auf dieses Interface um! Der KERMIT für den 800er ist ein compiliertes ACTION! Programm. Den Source? Sicher nicht leicht zu kriegen. Aber vom PC KERMIT habe ich den Source Code!

Den brauche ich ja nur umzusetzen. Da habe ich mich aber ganz schön übernommen. Den Code nachzuvollziehen ist die eine Sache, daraus Infos für eine Adaption herauszulesen, eine andere. Das ist mir um einige Nummern zu groß.

So ein schönes Interface, Und so vollständig. Das kann nicht nur XON/XOFF. Da gibts auch Hardwahandshake. Alles da. Nur kein ordentliches Programm dafür. Das ist also für’n Hugo!

(Kein Programm dafür: Ich habe mir das Programm „Terminal XE“, speziell für dieses Interface geschrieben, besorgt: „Für RS 232 Spezialisten:

Protokollspeicherungen, – Ausdruck, Nachrichtenvorfertigung etc. etc. Na gut, sämtliche Fleckputzmittel, die ich gekauft habe, hielten auch nicht das, was die dazugehörige euphorische Beschreibung versprach. Bei den Fleckputzmitteln konnte ich nicht einmal die Flasche weiterverwenden, bei diesem Programm aber wenigstens die Diskette!)

Naja, da schaute ich schön aus! Die üppige Hard­ware für diese Interface war nicht gerade billig gewesen. Also begann ich ein Terminalprogramm selbst zu schreiben. Meinen Traum von KERMIT konnte ich aber’austräumen.

Mittlerweile entdeckte ich aber BobTerm. Da vergaß ich ganz schnell KERMIT und alle Vorhaben damit. DAS ist ein Programm, Aber mit meinem Interface – nichts zu machen!

Als einer dem ATARI 800er Verfallener hatte ich auch bei Wolfgang Burger alte ABBUC Magazine nachbestellt, Und da gab es eine Kurzserie von Roland Bühler über die RS232 Schnittstelle. Und ein eigenes Interface vom ARGS, als Modul konzipiert. Angelehnt an das Atari Magazin Interface, aber mit radikal reduziertem Hardwareaufwand. Da ich bei meinem Interface alle teuren Bauteile gesockelt hatte, könnte ich sie bei diesem Modul auf das einfachste probeweise verwenden. Und vor allem, dieses Modul läuft mit BobTerm. (Dieses Programm hatte ich mittlerweile in mein Herz geschlossen!).

Auf gehts. Roland Bühler angeschrieben. Baupläne, Programme und Modulgehäuse bestellt. Und schnellstens gekriegt. (Dabei: EG hin uund her -„geringfügige Werte“ zwischen BRD und Osterreich finanziell abzuwickeln – offensichtlich profitieren nur die Banken davon (und die Post). Die betroffenen Leute werden nur Länge mal Breite zur Kasse gebeten. Und das nicht schwach! Ich schicke in Zukunft bei solchen relativ geringen Beträgen nur mehr Bargeld!)

 

So, auf ein Neues !

Die Pläne studiert, das Modulgehäuse beaugapfelt: Wie kriege ich die Kontaktfahnen, die eben ein Modul zum Anschluß braucht, auf meine vorgesehene Lochrasterplatine? Als Freizeit-Löter sind bei mir natürlich Dinge wie Platine ätzen etc. nicht drinnen.

Warum überhaupt Modul? Ich kann das ja genauso­gut für den Parallelbus bauen. Da habe ich ja meinen hübschen Apple-Slot-Stecker und mein passendes Gehäuse. Und überhaupt: am Parallelbus ist alles schön sauber hintereinander – ein Modul schaut immer oben raus und das RS232-Kabel geht dann so störend hinten oben weg.

Leicht gesagt. Der Parallelbus hat natürlich auch alle Anschlüsse (die +5V hole ich mir eh‘ wieder vom JoyPort 2) so wie das Modul. Sogar mehr. Nur den blöden „CCTL“ nicht!. (Was auch immer der „CCTL“ ist, aber als unbeleckter „Nachbauer“ brauche ich mich ja nicht darum kümmern. Obwohl ich es schon gerne wüßte … )

Also doch nix mit Parallelbus. Schade. Die Erweiterung da hinten wirkte so professionell und störungsfrei. Pech gehabt. Also doch Modul!

Wie kriege ich die Kontaktfahnen …. ??? Eine kurze, kreative Meditation und schon kramte ich bei den SEGA – Modulen von den Kindern. So eine Platine verwenden, zurechtschneiden und mittels Heißklebers auf die Lochrasterpiatine kleben. Die Verbin­dungen mittels angelöteter Drähte von den Kontakt­fahnen abnehmen. Müßte gehen. Die Module von Zuhause rührte ich natürlich nicht an, ich bin doch nicht wahnsinnig. Aber ein Videoverleih in der Nähe hatte einen Abverkauf von alten SEGA Modulen um ÖS 40,– (DM 6,–). Das mußte noch drinnen sein.

Gesagt, getan, ein solches Modul erstanden, zerlegt, die Dinger von der Platine ausgelötet, die Platine entsprechend zurechtgeschnitten und auf die vorbereitete Lochrasterplatine aufgeklebt. Der Rest war leicht.

Testen. Der Bildschirm zuckte beängstigend. Na klar, zwei Lötfehler gefunden. Nochmals. Gleiches Zucken. Verflixt. Mit dem Multimeter alles, aber auch alles durchgemessen. Der Aufbau ist o.K., die Verbindungen stimmen!???

Eine gewisse Ratlosigkeit machte sich bemerkbar. Ich bin ja doch nur wie schon gesagt ein Nachbauer und habe so gut wie keine elektronische Grundlagen, Aber eine ausgeprägte Hartnäckigkeit. Und die half. Die Batterie vom Ohmmeter war schon ganz schwach, da fand ich es: Die Kontaktfahnen sind natürlich beidseitig(oben und unten). Und die dritte Fahne war oben und unten durchkontaktiert! Von außen nicht sichtbar. Das war der Grund für die herrliche Bildschirmblitzerei! Die untere Fahne war eh‘ nicht notwendig, also wurde sie einmal probeweise abisoliert.

Test. Ein völlig normales Atari Einschaltbild zeigte sich. Hurra, zumindestens stört das Modul nicht. Also weiter ….

Kurz und gut, es lief dann alles wie am Schnürchen. Unter Turbo-Dos wird die RAM-Disk auf Dl: unbenannt, BobTerm automatisch in die RAM Disk geladen und von dort gestartet. Vorher kann ich noch mittels einer Batch-Datei vorbereitete Textfiles auch in die Ramdisk schaufeln. Und nach Beenden von Bobterm wird wieder mittels eines Batch-Jobs alle empfangenen CAP- und sonstige Files von der Ramdisk auf physische Disks verewigt. Ebenso die Konfigurations – Datei und die Datei zum Selbstwähler von BobTerm.

Das war aber bislang alles Nullmodem Verbindung mit dem PC. (Die Kilometeranzahl möchte ich aber nicht wissen, die ich in dieser Phase zwischen Magazin # 43, Schlaf- und Wohnzimmer hin und her gelaufen bin.). Aber mein ursprüngliches Ziel habe ich zumindestens teilweise erreicht. Die Verbindung 800er und PC. Mittels der von Roland mitgeschickten Hilfsprogrammen sind auch am PC ATASCII Texte kinderleicht auf ASCII umzusetzen.

Im Moment brüte ich noch über eine Lösung, den PC- Drucker direkt vom Atari ansprechen zu können und den PC als Druckerpuffer zu verwenden.

Denn der alte GPl00 am Atari hat von den sieben Nadeln nunmehr sechs in Betrieb und das Farbband ist auch nunmehr Band (ohne Farb-). Das Hin- und Herschleppen des PC – Druckers
(ein solider NEC­Brocken) ist auch mühsam und außerdem: wozu gibt es DFÜ?

Ich hoffe doch, da bald auf eine Lösung zu kommen. Doch dieses Problem wird im Moment nicht sehr aufmerksam verfolgt, denn: Bei einem Computerflohmarkt in Wien erstand ich ein Modern! Es sah fürchterlich. aus, hatte abgeschnittene Kabeln, keine Dokumentation dabei, aber dafür ein Postpickerl. (Also kann’s nicht irgendein Noname sein, da muß man doch die Doku auftreiben können – war meine Überlegung). Das nicht ansprechende äußere Erscheinungsbildes dieses Gerätes half mir, den Verkäufer von ÖS 500,– auf 250 ,- (DM 70,– auf 35,–) herunterzuhandeln. Nach leichter Restaurierung und Besorgung eines Manuals stellte sich dieses Ding als tadelloses V32bis Modern heraus, sogar mit professionellen Eigenschaften. Mein Problem war natürlich wieder das englische Manual. Aber man rauft sich durch.

Hurra! Modembetrieb auch möglich. Die ABBUC-Box wartet! Da gab es aber mit dem 800er zu Beginn starke Troubles. Mit dem PC und dem Terminalpro­gramm TELIX klappte es wunderbar. Aber SysOp Heiko Bomhorst bemühte sich redlich um mich und gab mir heiße Tips. Und wirklich: Das Problem lag nur bei der Modemeinstellung. Mit dem richtigen In­itialisierungs – String flutscht die Sache tadellos.

Zum ARGS Modul kann ich nur sagen: Es funktioniert tadellos und die paar Bauteile sind wirklich erschwinglich. Und wenn man in der BRD lebt: Joost Küp hat eine entsprechende Platine dafür entworfen (also keine Bastelaktionen wie bei mir), damit ist der Aufbau natürlich noch leichter.

Ja, und jetzt bin ich wirklich froh und zufrieden! Der 800er versteht sich mit dem PC und ‚ umgekehrt, der 800er kann mit dem Modern in die weite Welt (der PC natürlich auch). Ein Problem war nur noch das ständige Umstecken der Modemkabel: 800er zu PC auf COM2 mit Null­modembrücken, 800er direkt an’s Modern, PC von COM2 direkt an’s Modern (800er Kabel wieder runter) …

  • Also baute ich mir noch ein Gehäuse mit vier RS232 Stecker:
  • Ein fixes Kabel vom Modern zu diesem Kasterl
  • Dieser fixen Modemanschluß ist zu einem weiteren Stecker durchgeschleift:
  • Da kann wahlweise das Schniftstellenkabei zum PC oder zum 800er für eine Modemverbindung angesteckt werden.
  • Zwei weitere Stecker die mit der entsprechenden Nullmodembrücke verbunden sind. Damit kann der PC und der 800er „nullmodemmäßig“ verbunden werden.

Das hat den Vorteil: Das Modern bleibt ständig fix mit diesem Kasterl verbunden. Der COM2 Port vom PC wird nicht dauernd traktiert, da ein fixes Kabel angeschlossen ist, das entweder an der Nullmodembrücke zum 800er oder am durchgeschleiften Modemanschluß hängt. Das Atari Kabel wird ebenso entweder an die Nullmodembrücke oder an den Modemanschluß angesteckt. Damit gibt es nur ein ele­gantes Umstecken beim Kasterl, das bequem in Arbeitshöhe hinter dem Modern plaziert ist. Und das Malträtieren von direkten Schnittstellenanschlüssen sowohl am Modern als auch am PC entfällt.

Eine Lösung, die mir sehr gut gefällt und die sich bestens bewährt hat.

Ja, aber meine KERMIT Verbindung, die Grundidee, konnte ich doch nicht verwirklichen. Aber dafür ha­be ich bereits eine neue Idee, die ich als Vorführprojekt für das Herbstsemester in meiner Schule durchführen werde:

Von der Schule eine Modemverbindung zu unserem PC, auf dem ist eine Mini-Mailbox installiert. Über diese Mailbox läßt sich mit einem Front -Door Pro­gramm auf das Betriebssystem unseres PCs zugrei­fen. Damit kann ich ein anderes Terminalprogramm starten (hängt dann an COMI) und stelle damit in Remote- Betrieb eine (Nullmodem) Verbindung zum 800er her. Und für den brauche ich noch ein Programm, damit der 800er in dieser Verbindung aktiv reagieren kann. Damit man da in der Schule was Hübsches sieht.

(Halt etwas mehr als nur die Ausgabe des DIR der RAMdisk) Daran bastle ich bereits eifrig.

Abschließend: Sollte einer von Euch Ideen oder be­reits praktische Erfahrungen haben, den PC als Druckerpuffer für den 800er einzusetzen, wäre ich für Zuschriften sehr dankbar.

Meine Adresse ist: Dieter Lichtenegger :
Rollingergasse..6-8/1/36
A-1 120 Wien Osterreich
Fidonet: 2:31011.143
Internet: Dieter.Lichtenegger@bmv.ccc.or.at oder eine Mail in die ABBUC Box!

(Das ist aber für mich ein noch ungelöstes Problem: Von Wien zum Ortstarif in die ABBUC Box. Aber ein Brief ans Christkind )

Dieter Lichtenegger

 

Dietmar’s Spielecke

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

Zebuland von KE – Soft:

Hier sind die letzten Codewörter: 01.ZEBU 02.BLAP 03.ZOFF 04.BONG 05.BAFF 06.BING 07.HOPP 08.FLAM 09.PENG 10.BANG 11.PLOP 12.BEEP 13.MOEP 14.UGLE 15.ZIPF 16.MONK 17.TONN 18.ZATZ 19.BLOY 20.ARCH 21.HEPP 22.SUPP 23.JUPP 24.ZSCH 25.PCHH 26.YARG 27.SNAG 28.GNOZ 29.NAJA 30.HUTY 31.WEST 32.NORD 33.SUED 34.TOLL 35.MATT 36.DOAD 37.HAHA 38.LOGI 39.DEPP 40.SACK 41.XERO 42.FATZ 43.GULP 44.BAUF 45.ONNO 46.WAPP 47.LINK 48.DRAG 49.AETZ 50.HELP

LASER-MAZE von KE-Soft

Hier sind die weiteren 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

Die letzten Codewörter zu diesem Spiel gibt es in der kommenden Ausgabe.

MANIAC MINER
von: GENTRY TM SOFTWARE
EDITOR:
Sektor20 Byte 85 HEX von 06 in 09 = unendliche Leben

ZEPPELIN
von: SYNAPSE SOFTWARE
EDITOR:
Sektor 15 Byte 10 hex von 04 in 08 und
Sektor 18 Byte 81 hex von 04 in la = 26 Leben
oder:
Sektor 15 Byte 10 hex von 04 in 08 und
Sektor 18 Byte 81 hex von 04 in 63 = 99 Leben

PANIC EXPRESS
von: RET RAT SOFTWARE
EDITOR:
Sektor 31 Byte 90 hex von 16 in 1 E = 15 Leben
oder
Sektor 31 Byte 90 hex von 16 in 28 = 25 Leben
oder:
Sektor 31 Byte 90 hex von 16 in Oa = 35 Leben
Unendliche Zeit:
Sektor 31 Byte 114 hex von 19 in ff

ACTION BIKER
EDITOR:
Sektor 255 Byte 84 hex von 35 in 39 = 9 leben
oder:
Sektor 255 Byte 84 hex von 35 in 63 = 99 leben
oder:
Sektor 255 Byte 84 hex von 35 in ff = 255 Leben
 
CONGO BONGO
Von: SEG
A ENTERPRISE
EDITOR: Sektor 11 Byte 99 hex von 02 in 09 = 9 Leben für beide Player
oder:
Sektor 11 Byte 99 hex von 02 in 1 e = 30 Leben für beide Player
 
SHIT
Hier ein Tip von Robert Kern:
Codes zum Spiel:
LEVEL 10: BHURP
LEVEL 20: ZOEFA
LEVEL 30: HEURF
Das war es für heute. Ich habe alle Programme selbst ausprobiert.
 
* good byte * Dietmar

Cracking the code Teil 6

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

Doing The Multiplication / Wie multipliziert man? Der einfache Weg, zwei Zahlen miteinander zu multiplizieren, ist der, die eine der beiden so oft zu addieren, wie es die zweite Zahl angibt; z.B. 2 x 3 ist dasselbe wie 2 + 2 + 2, d.h. die 2 wurde 3x addiert. Das ist natürlich sehr umständlich, insbesondere bei großen Zahlen, weil dann jede Menge zu addieren ist. Es gibt bessere Methoden, aber der Einfachheit halber bleiben wir mal bei dieser. Mit unserer Methode müssen wir die Zahl, die multipliziert wird (Multiplikand; bitte merkt Euch diesen Ausdruck! Wir brauchen ihn in der Folge immer wieder. A.K.), so oft addieren, wie es der Multiplikator angibt. Im Beispiel 2 x 3 ist der Multiplikator die 3. Also addieren wir die 2 dreimal, um das Ergebnis 6 zu erhalten. Das ist natürlich exakt dasselbe wie 3 x 2. Hier ist der Multiplikand die 3, der Multiplikator die 2; d.h. eine Addition weniger als zuvor, nämlich nur: 3 + 3. Noch deutlicher wird dies beim Beispiel 1 x 255, bei dem man die Eins 255x addieren müßte, statt nur einmal die 255 zu nehmen. Unsere Methode, oder unser Algorithmus, für die Multiplikation funktioniert also so: Ist der Multiplikand größer als der Multiplikator, vertauschen wir die beiden. Wir setzen das Ergebnis auf Null und addieren dann den Multiplikand so oft wie der Multiplikator angibt.

Listing 6 zeigt das komplette Assembler-Programm (bzw. die Assembler Routine). Das Folgende beschreibt, wie man es amchen könnte, es in einen Assembler einzugeben und zum kompilieren. Hat man eine AssemblerCartridge, dann gibt man alles ein außer den beiden linken Spalten. Die Kommentare rechts, nach dem Strichpunkt, sind natürlich optional (d.h. man kann sie weglassen oder ändern, ohne daß das Programm dadurch beeinflußt würde). Hat man einen anderen Assembler, müßten ein paar Kleinigkeiten geändert werden. Das muß man dann bitte im Handbuch nachschlagen.

Tabelle 1 bietet ein paar Richtlinien für die Umwandlung zwischen den gebräuchlichsten Assemblern. Vor dem Assemblieren speichert man diesen Code als Source-File ab. (In Form eines Textfiles! Gewöhnlich gibt man diesem File den Extender .SRC, um klarzustellen, daß es sich um ein SouRCe- File handelt.)

		0100	;Multiplikation zweier 1-Byte Zah  		0110	;len durch wiederholte Addition. 00CB		0120	MLTPND	=	#CB	;Multiplicand. 00DA		0130	RESULT	212	;Result for BASIC. 0000		0140	$0600	;Start an Page 6. 0600	68	0150	PLA	;Discard number of data. 0601	68	0160	PLA	;Discard high byte. 0602	68	0170	PLA	;Get low byte. 0603	85CB	0180	STA	MLTPND	;Save as multiplicand. 0605	68	0190	PLA	;Discard high byte. 0606	68	0200	PLA	;Get low byte. 0607	AA	0210	TAX	;Save as multiplier. 0608	C5CB	0220	OMP	MLTPND	;Compare both. 060A	9005	0230	BCC	NOSWAP	;OK if MLTPLR < MLTPND. 060C	A5CB	0240	LDA	MLTPND	;Swap MLTPLR 060E	86CB	0250	STX	MLTPND	;for MLTPND 0610	AA	0260	TAX	;so that MLTPLR <MLTPND. 0611	A900	0270	NOSWAP LDA	#0	;Zero the result 0613	85D4	0280	STA	RESULT	;low 0615	85D5	0290	STA	RESULT+1	;and high. 0617	E000	0300	MLTPLY	CPX	#0	;lt MLTPLr = 0 then 0619	F00F	0310	BEQ	EXIT	;exit loop. 061B	18	0320	CLC	;ClearCarry 061C	A5D4	0330	LDA	RESULT	;Add in MLTPND 061E	65CB	0340	ADC	MLTPND	;to the result 0620	85D4	0350	STA	RESULT	; dnd Save back. 0622	9002	0360	SCC	NOCARY	;No carry so branch 0624	E6D5	0370	INC	RESULT+1	Else adjust high byte. 0626	CA	0380	NOCARY	DEX	;Decrement count 0627	AC1706 0390	JMP	MLTPLY	;and go back, 062A	60	1400	EXIT	RTS	;exit back to BASIC.  Listing 6

Anschließend läßt man das erstellte Programm (das im RAM!) assemblieren, so daß man ein Objektfile erhält (Häufig erkennbar am Extender .OBJ). Angenommen es traten keine Fehler auf, dann müßte das Objektfile so aussehen, wie die 2. Spalte in Listing 6 und müßte ab $600 – das ist die Page 6 -geladen werden, wie dies aus der ersten Spalte ersichtlich ist.

How lt Works / Wie funktioniert es?

Die Zuordnungen in Zeile 120 und 130 definieren zwei Labels: MLTPND enthält den Multiplikand und befindet sich in der Speicherstelle $CB; RESULT (=Ergebnis) zeigt auf die Speicherstelle 212, wo BASIC sich den Wert (also das per USR-Routine berechnete Ergebnis) abholt. Als nächstes wird der Location Counter (der Speicher-Zähler) so gesetzt, daß der erzeugte Maschinen Code ab $600 steht. (Vergl. Tabelle 1! *= bedeutet Location Counter setzen. A.K.) Der erste „PLA“- Befehl holt die Zahlen der BASIC-Parameter in den Accumulator. Allerdings werden sie nicht verwendet, ebensowenig wie das High-Byte. So haben wir nach dem dritten „PLA“-Befehl nur das Low-Byte im Accumulator, und es wird durch den darauffolgenden „STA“-Befehl als Multiplikand abgespeichert, und zwar in die Speicherstelle MLTPND, also $CB. Zwei weitere „PLA“-Befehle sorgen dafür, daß ebenfalls der niedrigere Teil des zweiten Parameters im Accumulator verbleibt; er wird per „TAX“-Befehl als Multiplikator im X-Register gespeichert.

Es wird immer nur der niedrigere Teil (Low Byte) des Parameters (das ist der eingegebene Wert. A.K.) gespeichert, so daß keiner der beiden Werte 255 überschreiten kann. Daher kann der Wert des Ergebnisses nicht größer als zwei Bytes sein. Das nämlich ist das Maximum, was wir an eine BASIC-Variable zurückgeben können. Jetzt prüfen wir, ob der Multiplikator kleiner ist als der Multiplikand, um die Anzahl der Additionen so niedrig wie möglich zu halten. Zu diesem Zeitpunkt befindet sich immer noch eine Kopie des Multiplikators im Accumulator. Mit Hilfe des Cornpare-Befehls subtrahieren wir den Multiplikanden vom Multiplikator, wobei nur das N-, das Z- und das C-Flag betroffen werden.

10 DIM HEX$(16) 20 LINE=10000:TRAP 100 30 READ HEX$,CHKSUM:SUM=0:J=0:START=1536 40 FORI=1 TO 15 STEP 2 50 D1=ASC(HEX$(1,1))-48:D2=ASC(HEX$(1+1,1+1))-48  60 NUM=P1-7"(D1>16))16+(D2-7*(D2>16))) 70 SUM=SUM+NUMPOKE START+J,NUM:J=J+1:NEXT I  80 IF SUM=CHKSUM THEN LINE=LINE+10:GOTO 30  90 PRINT "Checksum error an this line!"  95 LIST LINE:END 100 PRINT "Data in memory." 10000 DATA 68686885CB6868AA,1026  10010 DATA C5CB9005A5CB86CB,1254  10020 DATA AAA90085D485D5E0,1254  10030 DATA 00FOOF18A5D465C13,960  10040 DATA 85D4902E6D5CA4C,1212  10050 DATA 1706600000000000,125
Listing 7

Das Vertauschen der beiden Werte wollen wir natürlich überspringen, wenn der Wert im Accumulator kleiner ist als der Wert des Multiplikanden, wenn also das Ergebnis kleiner als Null war. In diesem Fall wurde das Carry (C-Fiag) gelöscht. Der folgende Befehl, „BBC“, würde dann bei NOSWAP (englisch für Nicht Vertauschen) die drei weiteren Befehle überspringen. Der Austausch der beiden Zahlen fände nicht statt. Schaut man sich den Maschinen-Code (in Spalte 2) an, so sieht man, daß der Assembler die Adresse von NOSWAP ($611) in 05 geändert hat, entsprechend dem Op- Code 90 (für die „BBC“-Instru
ktion), wieder so eine Sache, die der Assembler selbständig für uns erledigt.

Klappt dieses Verzweigen nicht (weil der Multiplikand kleiner ist), dann arbeitet das Programm die Zeilen 240 bis 260 ab und vertauscht die beiden Werte (Multiplikand und Multiplikator), der Accumulator wird mit dem Multiplikand geladen, und danach wird der Multiplikator, im X-Register, als Multiplikand gespeichert. Schließlich wird der Inhalt des Accumulators als neuer Multiplikator ins X- Register zurückgeschrieben. Egal welcher Weg bisher beschritten wurde, sobald die „LDA“-Instruktion bei NOSWAP erreicht ist, befindet sich der Multiplikator im X-Register und der Multiplikand in MLTPND, wobei der Wert im X-Register der kleinere der beiden ist. Bei NOSWAP wird der Accumulator mit Null geladen, und sein Inhalt in der Speicherstelle RESULT (212) abgespeichert. Da das Ergebnis zwei Bytes belegt, müssen wir an der nächsten Speicherstelle auch den Platz für das High-Byte erstmal auf Null stellen (sozusagen erstmal Klarschiff machen. A.K.). Das ist besser, als ein anderes Label zum definieren, das auf Speicherstelle 213 zeigen müßte. Man schreibt daher einfach RESULT+1, was hier genausoviel wie 212+1, also 213 bedeutet (die Speicherstelle, in die das High-Byte des Ergebnisses geschrieben wird).

Der Multiplikator befindet sich im X-Register, so daß er gleichzeitig als Zähler benutzt werden kann: Nach jeder durchgeführten Addition wird sein Wert um ein vermindert, so lange, bis er auf Null ist. (Das nennt man auf englisch „decrement“ – herunterzählen, also 7, 6, 5, 4, usw.; das Gegenstück ist „increment“ = aufwärtszählen, also 1, 2, 3, 4, usw. A.K.) Geprüft, ob dieser Zähler auf Null steht, wird in Zeile 300, wo das X Register mit 0 verglichen wird. Ist es dann so weit, führt uns die „Branch-if- EQual“-Instruktion („BEQ“, das bedeutet: Verzweigen, wenn die Werte gleich -sind. A.K.) zu EXIT, was uns zurück ins BASIC bringt. Diese Überprüfung wird übrigens als erstes im Programm durchgeführt für den Fall, daß der Multiplikator gleich Null wäre; dann wäre das Ergebnis natürlich auch gleich Null. Angenommen, der Multiplikator ist nicht gleich Null, dann löschen die Zeilen 320 – 350 das Carry und addieren den Multiplikand zum Low-Byte des Ergebnisses. Ist das Carry gelöscht, wird in NOCARY verzweigt. Ansonsten wird zum High-Byte des Ergebnisses eins dazugezählt (durch die Increment-Instruktion in Zeile 370).

Diese Methode, nachzusehen, ob das Carry gesetzt ist, und dann das High-Byte um eins zu erhöhen, ist genau dasselbe wie „Adding With Carry“ („ADC“) (Addieren und den Wert des Carry, Null, zum High-Byte dazuzählen. Auf jeden Fall würde das eine Laden- und Speichern-Instruktion erfordern. So sparen wir uns also zwei Bytes! Alles, was geschieht, ist, daß durch die Decrement-X-Instruktion vom Zähler Eins abgezogen wird und dann zurückgesprungen wird zur Vergleichs-Instruktion bei MLTPLY, von wo aus die Multiplikation dann fortgesetzt wird. Diese Schleife wird immer wieder durchlaufen, bis der Zähler im X-Register bei Null angekommen ist. Dann kehrt das Programm zurück ins BASIC. Das Ergebnis, festgehalten in RESULT und RESULT+1, wird in die BASIC-Variable ausgegeben.

DescriptionAtari
Assm/Edtr
Cartridge Synapse
Syn Assm
Disk OSS
Mac 65/Bug 65
Disk or Cartridge Atari
Macro Assm
DiskSet origin
(Location Counter)   .OR *= ORGValue of location
counter * * * .0Equate
(assignment) = .EQ = = or EQUDefine bytes/ cha-
racters in memory .BYTE .AT
.HS
AS .BYTE.
SBYTE.
DBYTE DB
DC- Define words in
memory .WORD .DA MORD DWSkip bytes. r…,.BS*= +DS

Running The Program .. und ab geht’s

Um das Programm zu starten, muß es in den Adressen (Speicherstellen) ab $600 (600 hex, Page 6) stehen. Habt Ihr dieses Programm assembliert, könnt Ihr das Objectfile in den Speicher laden. Für Diskettenbenutzer kein Problem: Vom DOS aus per Binary Load und zurück ins BASIC. Arbeitet Ihr mit der Assembler-Editor-Cartridge und Cassette, hütet euch vor einem ERROR! Anders als im Handbuch beschrieben kann man ein Objectfile nicht per CLOAD laden. Man braucht statt dessen eine kurze Routine. Damit wollen wir uns im nächsten Teil dieser Serie beschäftigen. Könnt Ihr Euer Objektfile nicht laden oder habt noch keinen Assembler, dann hilft Euch Ljsting 7: Ein BASIC- Programm, das die Hex-Daten liest und sie, nachdem sie für die Arbeit mit Pokes in Dezimalwerte konvertiert sind, in den Speicher lädt. Habt Ihr DATAfehler, wird ein „Prüfsummen-Error“ ausgegeben. In diesem Fall müßt Ihr Eure DATA überprüfen. Nachdem Ihr das Programm abgespeichert habt, gebt Ihr RUN ein, und der Maschinen-Code in den DATA wird in den Speicher ge-„poke“t. Nach einer kurzen Verzögerung wird die Nachricht „Data in memory“ ausgegeben. Testet nun, indem Ihr folgendes eingebt: ANSWER=USR (1536,10,24) dann ? (ein Fragezeichen). Als Antwort (ANSWER) bekommt Ihr das Ergebnis 240. Ihr könnt die beiden Parameter (10 und 24) ändern, jedoch nicht die 1536; das ist der Dezimalwert für die $600, die Stelle, ab der das Programm geladen werden soll.

Until Next time / Bis zum nächsten Mal

In der nächsten Folge will ich ein paar noch offene Fragen klären, darin eingeschlossen, eine verbesserte Multiplizier-Routine. Danach will ich mit ein paar neuen Programm und Sachen beginnen. Viel Spaß beim Experimentieren! Und wenn Ihr’s noch nicht getan habt, dann saust jetzt mal ganz schnell los und kauft Euch den Assembler, den Ihr Euch ganz fest versprochen hattet!

ATARI 130XE – Emulator PC Xformer, Version 3.0

von Jörg Gernreich

1. Hardwareanforderungen

Die PC Xformer 3.0 – Software ist ein 32-Bit-MS­DOS-Programm und ist lauffähig auf PC­Kompatiblen auf Basis der Prozessoren 386, 486 oder Pentium. Voraussetzung sind mindestens 512kB freier Hauptspeicher unter MS-DOS, MS­Windows (Version 3.0, 3.1, NT, 95) bzw., OS/2 2.1 oder OS2/Warp in Verbindung mit VGA- oder Super­VGA-Grafikkarte. Der PC Xformer 3.0 arbeitet nicht auf 8086 und 286er PC’s.

Joystick, Modern und Drucker werden unterstützt, sind für die Benutzung des PC Xformers jedoch nicht Bedingung. Eine Soundblaster kompatible Soundkarte kann ebenfalls wahlweise verwendet werden.

Der Emulator läuft auf einem 386er PC bei 33MHz Taktfrequenz mit ca. 100% der Geschwindigkeit eines Atari 130XE, auf schnelleren PC entsprechend schneller. Die nachfolgende Tabelle gibt die annähernde Geschwindigkeit der Ernulation in Bezug auf den Atari 13OXE an:

Rechner Geschw.
386SX/20 0,5 fach
386 DX/33 1,0 fach
486 DX/33 2,0 fach
486 DX2/66 4,0 fach
Pentium > 7 fach

2. Merk
male

Der PC Xformer 3.0 unterstützt folgende Funktionen des Atari 130XE:

  • 6502 CPU-Emulation
  • Atari 800, 800XL und 130XE Betriebssystem-ROM-Emulation
  • Speichererweiterungsemulation bis 256k13 Im 130XE-Modus
  • Alle ANTIC-Modi (Text und Grafik)
  • Alle GTIA-Grafikmodi mit GTIA-256­Farbenpalette
  • PM-Grafik mit Kollisionsüberwachung
  • Verarbeitung von Displaylist-Interrupts, IRQ und NMI
  • Lesen und Schreiben vonlauf virtuelle Laufwerke
  • Direktes Lesen von MS-DOS-Files und automati­sche Konvertierung auf die virtuellen Laufwerke
  • Umschaltung von Basic E/A mit Tastendruck
  • Joystick-Emulation bei Benutzung der Tastatur oder des PC-Joystick
  • Voll-Geschwindigkeits-Emulation auf dem 386/33 oder schneller
  • Langsam- und Schnell-Modus in der Emulation
  • Modem- und Druckerunterstützung
  • Atari POKEY (4-Kanal-) Soundunterstützung in Verbindung mit Soundkarte
  • Atari-Einbaulautsprecher wird durch PC­Lautsprecher unterstützt

3. Installation

Der PC Xformer kann zwar von der Diskette gestartet werden, jedoch ist die Installation auf der Festplatte empfehlenswert.

Um den PC Xformer zu installieren, legen Sie die Xformer-Diskette einfach in Laufwerk A und rufen Laufwerk A mit dem Kommando „A:“. Nun geben Sie „install“ ein und drücken [Enter]. Auf Ihrem Laufwerk C (Festplatte) wird jetzt ein neues Verzeichnis mit dem Namen XFORMER angelegt und die PC Xformer-Files dorthin kopiert.

 

4. Start des PC Xformers aus dem MS DOS

Ist der PC Xformer 3.0 einmal installiert, wechseln Sie um ihn zu starten ins Laufwerk C: geben ein „cd xformer“ (wechseln ins Verzeichnis XFORMER) und tippen anschließend „xformer“.

Das vertraute Atari-Basic-Prompt „READY“ wird nun als hellblauer Text mit hellblauem Blockcursor auf dem blauen Bildschirm erscheinen. Um ins MS-DOS zurück zu gelangen, drücken Sie [Strg]+[F5].

Wenn Sie das Xformer-Programm starten, sind gewöhnlich bereits verschiedene Files von virtuellen Disketten vorhanden. Virtuelle Disketten (Xformer­Disk-Files) verhalten sich wie Disketten im Atari­Floppylaufwerk. Der Atari unterstützt bis zu 8 externe Laufwerke und einige verbreitete DOS-Arten eine RAM-Disk als 9. Laufwerk. Hier einige Beispiele von Aufrufen für den Betrieb des PC Xformers mit virtuellen Disketten:

xformer dos25.xfd

lädt den Xformer mit der Bootdiskette DOS 2.5

xformer mydos45d.atr

desgleichen mit MYDOS 4.53

xformer dos25.xfd demosl.xfd

lädt den Xformer mit der Bootdiskette als Laufwerk #1 und die Demodiskette als Laufwerk #2

Es können bis zu 8 Disk-Filenamen als Aufrufparameter angegeben werden, dabei muß der erste immer eine bootfähige Diskette sein. Zu beachten ist, daß verschiedene DOS-Arten eine unterschiedliche Anzahl von Laufwerken verwalten!

Falls Sie dem Emulator für Laufwerk #1 eine nicht bootfähige Diskette (Diskfile ohne DOS, wie z.B. DEMOS1.XFD) i~ngeben, so antwortet der Atari­Emulator mit der Meldung, „BOOT ERROW und Sie müssen entweder abbrechen oder mit [Fll] in den Konfigurationsbildschirrn wechseln und die Zuord­nung für Laufwerk #1 ändern. Mit [Enter] gelangen Sie zum Xformer zurück.

Ist im Aufruf kein Diskfile angegeben oder für Laufwerk #1 der Name eines Nicht-Diskfiles, so bootet der Emulator wie ein Atari ohne angeschlossenes Laufwerk.

Für die Aktivierung der Zusatzgeräte oder weiterer Optionen sind in der Kommandozelle zusätzlich Schalter-Parameter einzufügen:

  • -Cl Modern an Fort COM1
  • -Ü2 Modern an Port COM2
  • -J aktiviert Joystick-Unterstützung
  • -S aktiviert Sound-Blaster-Unterstützung
  • -A automatischer Start
  • -N Basic ausgeschaltet
  • -8 bootet statt 130XE-Modus im Atari 800 Modus

 

Die Schalter-Parameter stehen vor dem ersten Disk­Filenamen, zum Beispiel:

xformer -a -i -s dos25.xfd

startet sofort, bootet mit DOS 2.5 und aktiviert Joystick und Soundkarte.

Denken Sie daran, daß die meisten ausführbaren Programme nicht mit installiertem Basic laufen könnnen! Bei einem Neuling wird es wohl häufiger vorkommen, daß die Basic-Abschaltung vergessen wird.

Wenn Sie sich mit dem Xformer im Atari-Basic befinden und mit einer virtuellen Diskette gebootet haben, können Sie mit dem Befehl „DOS“ in das Atari­Dos (DOS-Menü, MyDos-Menü, Sparta-Dos-Kommandozeile o.ä.) wechseln. Sie können auch den Atari-Emulator neu booten und durch das drük­ken von [Shftl+[FIO] das Atari-Basic ausschalten, Sie gelangen dann in das DOS-Menü oder die Kommandozeile.

Wenn der Atari bootet, prüft er die angeschlossenen Laufwerke und stellt sich auf das ein, welches als Laufwerk #1 geschaltet ist. Er beginnt von diesem die Bootsektoren der Diskette zu laden. Falls keine vorhanden sind, er scheint die „BOOT ERROR“­Fehlermeldung.

Der Atari versteht den Gerätecode „D:“ als Disketten­laufwerk. Sind mehrere vorhanden, ist es notwendig, sie zu unterscheiden. Der Atari-Handler benutzt eine Numerierung, wenn es mehr als ein Gerät der gleichen Art gibt. So ist Dl: das Laufwerk #l, D2: Laufwerk #2, D3: Laufwerk #3 usw…

Nach dem Gerätenamen „D:“ kommt der Filename. In DOS-Arten, welche Unterverzeichnisse unterstützen, kommt zwischen dem Gerätenamen und dem Filename der Pfad. Diese DOSse benutzen die Bezeichnung „D:“ kurzerhand für den gerade eingestellten (aktuellen) Pfad.

5. Das Xformer- Disketten-Konfigurationsmenü

Während der Arbeit mit dem Emulator gelangt man durch drücken von [F11] in das Disketten­Konfigurationsmenü. Dieses erlaubt das wechseln der virtuellen Disketten, die den Laufwerken Dl: bis D8: zugewiesen sind,

Tippen Sie einfach die Nummer des Laufwerks und anschließend den Namen des neuen Xformer­Diskfiles.

6. Geschwindigkeitsumschaltung

Der PC Xformer arbeitet mit zwei Geschwindigkeiten, dem Normal- und dem Schnell-Modus.

Im Normal-Modus arbeitet der Xformer 3.0 etwa mit der selben Geschwindigkeit wie ein Atari 130XE. Dieser Modus sollte
für die meisten Videospiele benutzt werden. Die PM-Grafik mit Kollisionsprüfung arbeitet im Normal-Modus zuverlässiger.

Im Schnell-Modus läuft der Xformer so schnell wie es Ihr PC zuläßt (siehe Pkt. 1). In der Voreinsteilung ist (anders als beim Xformer 2.0) der Normal-Modus festgelegt.

Um zwischen beiden Geschwindigkeiten umzuschalten, wird [Scroll Lock] bzw. [Rollen] auf der Tastatur gedrückt. Wenn die Scroll Lock (Rollen)-Anzeige leuchtet, befinden Sie sich im Normal-Modus, ist sie aus, im Schnell-Modus.

7. Tastaturwechsel

Der PC Xformer startet automatisch die amerikanische Tastatur. Dadurch ändert sich gegenüber der deutschen Tastatur die Belegung einiger Tasten. In der Anlage 1 wird die abweichende Tastenbelegung im einzelnen dargestellt.

Im Handbuch werden die Funktionstasten [Fl], [F2], [F3] und [F4] als die Funktionstasten des Atari 1200XL beschrieben. In der Voreinstellung sind sie als Cursortasten im 800XL- und 130XE-Modus belegt. [Strg]+[F3] schaltet den Tastenklick ein und aus. Im Atari 800-Modus haben sie keine Funktion, weil der Atari 800 keine Funktionstasten besitzt.

Die Tastenkombinationen z.B. [CTRL]+[1] und [CTRL]+[3] bewirken nichts. Um die äquivalenten Funktionen zu erhalten, sind folgende Tasten zu drücken:

Um den PC Xformer zu verlassen, ist [Shift]+[F5] zu drücken (nicht F5 allein, wie beim Xformer 2.0). Es gab Klagen von Anwendern, die beim Versuch F4 oder F6 zu drücken, die F5-Taste erwischten und gegen ihren Willen aus dem Xformer hinausgewoi­fen wurden. Dagegen ist das versehentliche betäti­gen von Shft+F5 wohl schwerer zu bewerkstelligen.

Die weiteren Funktionstasten sind wie folgt belegt:

 

Mit der Kombination [Shftl+[F10] wird neu gebootet und dabei der Basic-ROM aus- bzw. eingeschaltet.

[F1 l] ruft das Disketten-Konfigurationsmenü (aus jeder Programmsituation) auf. Dabei wird das aktuelle Programm eingefroren. Mit [Enter] gelangt man in den Xformer zurück und kann an der Stelle forffahren, an der man ihn verlassen hat.

[F12] schaltet die Betriebsart um, d.h. zwischen Atari 800, 800XL und 130XE.

[PgUp] und [PgDn] scrollt den PC-Bildschirm um jeweils ein Pixel nach oben oder nach unten.

8. Joystickemulation

Unabhängig von der Unterstützung des Joystickports wird der Ziffernblock bei der Einstellung Num­Lock aus als 8-Wege-Joystick geschaltet. Die 0 bildet hierbei den Feuerknopf.

Der Block der Pfeiltasten bildet einen 4-Wege­Joystick. Im normalen Basicmodus dienen die Pfeiltasten in Verbindung mit [Strg] analog dem Atari zur Cursorsteuerung.

9. Austausch von Files

Es gibt viele Programme, die die Lücke zwischen den Atari- und IBM-Systemen überbrücken können, wenn ein Austausch von Files erfolgen soll. Einige sind reine Softwareprodukte, andere erfordern eine spezielle Hardware, entweder für Atari oder IBM. Wieder andere benutzen vorhandene Fileformate für virtuelle Disketten, wie „ATR“ des Programms S102PC oder das „DCM“ des DiskCommunicator 3.2.

Für jene, die ausschließlich mit IBM arbeiten, sind folgende Programme am gebräuchlichsten:

SIOCOPY

Dieses Programm erlaubt den Anschluß eines Atari­Floppy Laufwerks an Ihren IBM-PC.

DCM2DSK

Dieses Programm läßt Sie virtuelle Atarl_ Diskettenfiles des DiskCommander 3.2 (DCM’s) ‚in das S102PC-Format (ATR) konvertieren, um sie mit S102PC und PC Xformer benutzen zu können. Virtuelle Disketten sind Files, die alle Daten einer Diskette enthalten, einschließlich der Files und ihrer Namen, die genau dort sind, wo man sie auch auf der Diskette finden kann, sowie die Systeminformationen (Bootda n, DOS-Files usw.).

S2PC

S2PC lädt MyDos-kompatible SIO2PC (ATR)-Files und läßt sie zwischen der virtuelle Disk und Ihrem IBM-Laufwerk hin und her kopieren.

ATRIMG

Die Anwendung ist dem S2PC sehr ähnlich. Jedoch benutzt das Programm ein Interface, das mit den Pfeiltasten bedient wird. Es läuft nicht auf allen PC’s.

Für die jenigen, die den Datenaustausch zwischen ihrem Atari und dem IBM-PC wünschen, oder noch alte Atarl-Disketten lesen möchten, sind folgende Programme verfügbar:

Util und SpartaRead

Diese Programme lassen Sie auf Atari-Disketten mit doppelter Schreibdichte zugreifen, die bereits mit einem DD-fähigen Atarilaufwerk formatiert wurden. Benötigt wird ein 5,25″-Laufwerk auf Ihrem PC. Andere Versionen, die von diesem Programm erschienen sind, haben andere Namen. Es wäre daher klug, eine Version zu wählen, die auf Ihr System zugeschnitten ist und auf das Atari-DOS, das Sie verwenden wollen.

MULE

Wie Util und SpartaRead liest dieses Programm handelsübliche Atari-Disketten von Atarii 1050 Laufwerken, die mit 1,5 facher Dichte (enhanced) formatiert und von PC-Laufwerken wesentlich schwerer zu lesen sind. Die Software wird sowohl für den Atari, als auch für den IBM benötigt.

SI02PC

Dieses Paket enthält ein Kabel für die Verbindung zwischen dem 13 poligem SIO-Port des Atari (Standard 1/0) und einem RS 232-Port des IBM (COM). Mit einem Fileserver-Programm auf dern IBM-PC lassen sich Daten vom Atari holen oder auf ihm sichern. Grundsätzlich kann der IBM-PC zwischen ein und vier Atari-Laufwerke bedienen.

SIOCOPY

Das ist das Gegenstück zum SIO2PC. Es enthält ein Kabel und ein Programm, das den Anschluß eines Atari-Diskettenlaufwerks an Ihrem PC und das Lesen von Files erlaubt, so als wäre der PC ein Atan.

Disk2XFD

Dieses Atariprogramm konvertiert eine Atari-Diskette in ein XFD-Format, das zur Benutzung durch den
Xformer geeignet ist. Es kann die virtuelle Diskette als File sichern oder per Modern direkt auf Ihren PC senden, der den X-Modem-Filetransfer benutzt.

Arbeiten mit dem Atari-Bus 3.Teil

Fortsetzung aus Magazin 39
von Roland Bühler

5. Eine ROM-Disk für den Atari (David/Peters)

Eine gute Anwendung für eine PIA ist die ROM-Disk der Firma Peters. Wer schon einmal die Platine gesehen hat, der wird zwei PIAs darauf entdecken. Die Aufbau ist nun folgendermaßen:

Ein Eprom (mit 64kByte Speicher) hat 16 Adreßleitungen (A0-A15). Die eine PIA übemimmt nun mit ihren insgesamt 16 Portleitungen die Erzeugung des 64kByte Adreßraumes des EPROMS. Die andere PIA übernimmt mit einem Port die Auswahl der ins­gesamt 8 EPROMS über die jeweilige Selectleitung des EPROMS (nicht nur PIAs auch EPROMS haben Selectleitungen!). Der letzte Port übemimmt den Datenaustausch zwischen dem eingeschalteten Eprom und dem Computer. Es wird also nicht eine Speicherbank eingeblendet, sondern lediglich über ein „Loch“ (s.o.) gelesen.

Die nötigen Routinen stehen in einem eigenen Betriebssystem im Bereich des früheren Selbsttests. Man kann anhand der Tabelle 5 nun auch die EPROMS „per Hand“ umschalten, indem man die Werte 1,2,4….128 in PORTA von PIA1 schreibt. Mit diesem Wissen kann man nun relativ leicht eine kleine Schwester der ROM-Disk mit nur einem Eprom bauen, die ohne Probleme mit dem neuen OS zusammenarbeitet.

Steueradressen der ROM-Disk

P1A1 ($D100+A2): (ersetzt durch LS138)
PORTA Epromauswahl $D104
PORTB Datenleitungen $D105
P1A2 ($D100+A3):
PORTA Epromadressen LSB $D108
PORTB$ Epromadressen MSB $D109

(Tabelle 5)

 

Bauteile:

  • PIA 68B21 oder 6520A
  • Eprom 27C512 (64kByte)
  • 74LS1 38 oder 74LS00
  • 7 Widerstände mit lOk (am besten Array)

Erklärungen zum Bauplan:

  • Die PIA erzeugt wieder den Adreßraum des EPROMS und der LS138 schaltet das Eprom ein, so daß die Daten an den Datenbus des Atari ge­langen.(Bei der hiesigen Version 2 übernimmt ein LS00 die Aufgabe des LS138)
  • Damit die Sache nun funktioniert, muß man na­türlich ein OS für die ROM-Disk und den Rumfi­legeneratoC für das Eprom bei der Firma Peters bestellen.
  • Es geht aber auch das ARGS-OS Version E (Stand 11/95), das eine Weiterentwicklung des alten ROM-Disk-OS ist, in dem zusätzliche Trei­ber für Uhr, Drucker und RS232 integriert sind und ein Fehler behoben ist.
  • Man muß für +5V am Paralleibus sorgen. Sie werden (wie beim 600XL) an Leiterbahn 47 des Busses angelötet (beim XL unbelegt).
  • Das Lese/Schreib-Signal am Atari-Bus ist etwas zum CIDU-Signal verschoben. Es ist besser, wenn man diese Leitung abtrennt und die Leiterbahn 46 direkt mit Pin 36 der CPU verbindet.
  • Pin 14 von U2 (=$D100) muß mit der Leiterbahn 33 des Parallelbusses verbunden werden. An sie kann man dann ICS1 der ROM-Disk-PIA anschließen.

6. LCD-Anzeige

Das Schema ist immer das Gleiche: Eine PIA wird zwischen Rechner und externes Bauteil geschaltet. Die PIA wird über eine Adreßleitung (A2-A7) und der CCTL-Leitung (oder andere) in den Adreßraum des
Rechners eingebunden. Man muß nur darauf achten, daß nicht Baugruppen mit der gleichen Adreßleitung und CCTL zusammen betrieben wer­den.

Bauteile:

  • PIA 68B21 oder 6520A
  • LCD-Anzeige LTN 211 (oder ähnliche)
  • Widerstand 4,7k – 3,3k

 

 

Bedienung und Bauplanerklärung:

  • Man muß sich überlegen, wo man die LCD ein­bauen will. Entweder kann man sie in den Rech­ner direkt einbauen, oder in das Gehäuse der ROM-Disk oder in die ARGS-Box. Falls man sie in den Rechner oder in die ROM-Disk einbaut, sollte man als Steueradresse $D100+A4 wählen. Ansonsten bietet sich CCTL und A4 an.Man kann natürlich auch mit einem zusätzlichen LS138 weiter auscodieren, wenn man viele Erweiterun­gen betreibt (s.u.).
  • PORTA der PIA übernimmt die Steuerfunktionen der LCD. Man programmiert sie auf Ausgabe und schreibt zu Beginn am besten „0“ hinein.
  • Steueradressen: PORTA $D510/54544 PACTL $D512/54546 (5 Leitungen bleiben unbenutzt. Sie werden evtl. für den Anschluß einer PC-Tastatur herangezogen)
  • PORTB übernimmt den Datentransfer.
  • Man programmiert sie auf Ausgabe.
  • 4 Steueradressen: PORTB $D511154545 PBCTL $D513/54547
  • Die LCD-Anzeige kann insgesamt 80 Zeichen, aufgeteilt in zwei Zeilen speichern. Das Display kann aber nur zwei Zeilen mit 1 . e 16 Zeichen dar­stellen. Es kann wie ein `Fenster` über die zwei Zeilen geschoben werden.
  • Der Widerstand am Anschluß 3 der LCI) stellt den Kontrast ein.
  • Um die LCD anzusprechen, muß man auf jeden Fall „Enabie“ (Anschluß) 6 auf „High“ schalten. Für die normale Bedienung kann man RIW (Anschluß 5) auf `Low` schalten (= Schreiben). Wenn man die LCD programmieren will, dann muß RS (Register Select, Anschluß 4) auf „Low“ geschaltet sein. Will man ein Zeichen senden, dann muß RS „High“-Pegel haben. Man schreibt also in PORTB den Wert für das Zeichen oder den Befehl, schreibt in PORTA den Steuerwert und schreibt dann gleich wieder „0“ hinein. Die möglichen Zeichen bzw. Befehle entnehme man aus der Bedienungsanleitung.
  • Zu Beginn muß man die LCD zuerst programmieren. Sie ist beim Einschalten in einem undefnier­ten Zustand.

Version 2

Leider wurde bei der ersten Version das Timing des Displays nicht berücksichtigt. Man mußte unter Ma­schinensprache bestimmte Wartezeiten einbauen, damit es zu keinen Fehlfunktionen kam. Deswegen wurde eine Warteschleife in das Programm einge­baut, die mit JSR WAIT aufgerufen wird (LCD2MINLCOMISCR, LCD2.COM/SRC). Diese kann man auch in die Programme für die Version 1 noch einbauen.

Außerdem wurde der ganze Aufbau vereinfacht. Man kann nun nicht mehr alle Funktionen des Dis­plays nutzen, aber zur reinen Ausgabe von ASCII­Zeichen reicht es und man hat einen ganzen Port noch frei, den man z.B. zum Anschluß einer PC­Tastatur nutzen kann. Diesen Plan werden wir im kommenden Magazin veröffentlichen.

HyperSpeed

Auf Drängen Wolfgangs hin, schreibe ich jetzt noch in letzter Minute diesen Zwischenbericht bzw. diese Kurzbeschreibung der aktuellen Version des CPU­Speeders. Wolfgang sagte mir zur JHV auch, daß es bezüglich meiner CPU- Erweiterung einige Anfragen gegeben hätte – man würde ja gar nichts mehr hören usw. Warum habt Ihr Euch denn nicht mal bei mir erkundigt?

So, aber nun zum eigentlichen Thema. Die Entwick­lung von HyperSpeed XL/XE (so nennt sich das Ba­by in Zukunft) hat doch etwas länger als geplant ge­dauert. Mit meiner Schätzung April/Mai 1995 (siehe ABBUC Mag #40) lag ich etwas daneben.

Aber ich denke das Teil ist dafür um so besser ge­worden. Wie einige von Euch auf der JHV sehen konnten, hat HyperSpeed schon relativ „fein“ ausgesehen. Dem ist aber leider noch nicht so. Momen­tan habe ich noch mit ein paar kleinen Problemen zu kämpfen, aber ich hoffe ich bekomme diese schnellstmöglich in den Griff.

Nun aber ein paar technische Details. HyperSpeed hat eigentlich nur noch wenig mit dem zu tun, was im ABBUC Mag #40 vorgestellt wurde. Das Grund­prinzip ist aber geblieben – d.h. schneller lokaler Bus. Ein völlig neuer Taktumschalter wurde entwik­kelt, da ich an dem alten doch erhebliche Mängel feststellen mußte. Ich arbeite aber derzeit schon an einer Version ohne Taktumschalter, aber dafür mit einem asynchronen Daten- Interface zum ATARI. Aber es hat noch einige andere interessante Neuerungen gegeben. An erster Stelle ist diesbezüglich zu erwähnen, daß die alte CPU **NICHT** aus dem ATARI entfernt werden muß. Es kommt noch besser: Die alte CPU bleibt sogar noch lauffähig. Durch diese Tatsache sind eigentlich sämtliche Kompatibilitätsproblerne aus dem Weg geräumt.

Konkret sieht das dann so aus, daß nach einem Reset die CPU ausgewählt wird, mit der der Resetvorgang fortgesetzt werden soll. Um noch eins daran zu setzen kann HyperSpeed auch DMA (Direct Memory Access) auf dem ATARI betreiben während die alte CPU läuft – lesend und schreibend. HyperSpeed läßt sich sozusagen auch als intelligenten DMA­Controller für den ATARI mißbrauchen.

Der Takt der 65C816 CPU von HyperSpeed beträgt jetzt auch 14MHz. WDC, der Hersteller der 65C816 arbeitet meines Wissens derzeit an einer 20MHz Version…

Zur on Board Speicherausstattung von HyperSpeed ist folgendes zu sagen: Für das Boot- ROM steht ein Sockel zur Verfügung. Dort können alle EPROMs in den Größen von 16KB bis 1MB eingesetzt werden. Für statische RAMs stehen zwei weitere Sockel zur Verfügung. Dort können jeweils SRAMs der Organisationen 64Kx8, 128Kx8, 256Kx8 oder 512Kx8 eingesetzt werden. Für beide RAMs kann jeweils ein halber oder ein ganzer Warteschritt eingelegt werden. Ohne Warteschritte wird rein rechnerisch ein RAM mit 12ns Zugriffszeit benötigt (bei 14MHz). Pro halben Warteschrift erhöht sich die benötigte Zugriffszeit um 35ns. Es besteht zwar die Möglichkeit, die theoretische Zugriffszeit bei 0 Warteschritien auf 15ns zu erhöhen – mit einer schnelleren Memory Management Unit. Das dumme ist nur, daß diese schnelle MMU ca. DM 40,- teuerer als die normale ist.

Für das Boot-ROM sind übrigens 0,5, 1.0, 1.5 und 2.0 Waitsteps einstellbar.

Für die Leute, die sich ihre individuelle Speicheraufteilung zusammenstellen möchten, hätte ich dann auch noch etwas zu bieten. Außer für den groben Teil der Taktverwaltung verwende ich auch als MMU sog. in system programable Large Scale Integration“-Bausteine der Firma Lattice oder kurz gesagt ispLSI. Ich bin momentan damit beschäftigt die Download Software für diese Serie für den XL/XE zu schreiben. Damit ist es dann möglich z.B. die MMU über einen Joystick Port neu zu programmieren, Die Standardversion wird auf 2x128KB RAM und 512KB ROM eingestellt sein.

Auf der JHV wurde ich des öfteren gefragt, ob auch alte Programme beschleunigt werden können. Hierzu gibt es einen Modus, in dem im Slow-Mode von HyperSpeed interne Operationen der CPU sozusagen ‚zwischendurch‘ ausgeführt werden. Diese Tatsache allein beschleunigt z.B. BASIC Programme um ca. 10%-20% (je nach Programm konnte ich sogar noch höhere Beschleunigungen messen). Diese Art von Beschleunigung hat allerdings nichts mit dem eigentlichen Konzept von HyperSpeed z
u tun. Um ein Programm richtig bemerkbar zu beschleunigen (z.B. um den Faktor 7) ist es erforderlich, daß der Code schnell abgearbeitet wird und HyperSpeed relativ selten auf den ATARI zugreifen muß. Diesbezüglich ist es möglich 16K-weise den ATARI für HyperSpeed ein- oder auszublenden. In der Praxis sieht das dann so aus, daß zum Beispiel von $000000-$003FFF neuer RAM und für den Rest ($004000-$OOFFFF) ATARI eingeblendet ist. Und genau an dieser Stelle beginnen die Inkompatibilitäten. Wird z.B. der VIDEO RAM nicht in den RAM des ATARI gelegt, dann war’s das schon. Denn der ANTIC hat auf HyperSpeed keinen Zugriff. Ähnliche Probleme gibt es beim handlen der RAMDisk und des RAMs unter dem ATARI OS bzw. BASIC. Für einige dieser Probleme habe ich schon realistische Lösungen gefunden. Es ist zwar auch möglich alles 100%ig Wasserdicht zu machen, Aber dazu müßte man einen noch größeren Aufwand betreiben bzw. den ATARI umbauen. Doch ich persönlich sehe darin keinen richtigen Sinn. Das ganze wird dann noch teuerer als es ohnehin schon ist.

Derzeit habe ich noch eine Option eingebaut, die es ermöglicht alte Erweiterungen (wie ROMDisk etc.) direkt auf dem neuen Bus, aber mit dem alten 1.77MHz Takt des ATARI zu betreiben. Das werde ich aber höchstwahrscheinlich weglassen, da ich schon kommen sehe, daß das kaum oder gar nicht genutzt wird.

Alte Erweiterungen können aber nach wie vor direkt am ATARI betrieben werden. Man muß sich halt nur eine Ad Busverteiler bauen…

Eine Prozessor Single Step Unterstützung ist auch mit integriert. So etwas ist interessant für Assembler­Debugging. Das habe ich aber momentan überhaupt noch nicht praktisch getestet, aber es müßte eigentlich funktionieren. Damit wird man dann im Gegensatz zum Bibo-Assembier auch Programme ins ROM verfolgen können. Dasganze wird nicht über Breakpoints gesteuert, sondem nachdem die Single-Step Sequenz ausgelöst wurde, wird nach einer bestimmten Anzahl von OpCode-fetchs ein ABORT an der 65C816 ausgelöst.

Noch ein paar Worte zum Board. Das Board an sich mißt momentan ca.14x15cm und wird beim XL hinten am Busadapter angesteckt. Für XE-Modelle benötigt man den zur JHV besagten XE-XL Adapter der Firma P. aus V. ;-). Leider läßt es sich nicht vermeiden, daß am ATARI noch ein paar zusätzliche Leitungen angelötet werden müssen. Dann wird ein zusätzliches 5V Netzteil benötigt – Die Möglichkeit die Versorgungsspannung etwa über den Busadapter vom ATARI zu beziehen habe ich von vornherein ausgeschlossen, da das unter Garantie ein Schuß nach hinten wäre. Der Power Connector ist kompatibel zu den üblichen wie bei Festplatten etc. Für zukünftige Erweiterungen gibt es zwei Slots zur Aufnahme von Steckkarten. Als zusätzliches Extra hatte ich eigentlich vor, einen ordentlichen Realtime Chip (DP8570AV) mit zu integrieren, aber daraus wird wahrscheinlich nichts – den gibt es momentan nirgends zu kaufen.

Der Preis von HyperSpeed wird sicher auch viele interessieren. Ich traue mir ja gar nicht so richtig Euch diesen hier vor die Nase zu setzen, aber wenn man mal einen Preis/Leistungsvergleich mit diversen anderen Sachen macht, dann ist HyperSpeed spottbillig. Ihr bezahlt wie gesagt eigentlich nur die Materialkosten, Die Entwicklungskosten wären sowieso unbezahlbar. Finanziell gesehen ist Hyper­Speed von vornherein ein Minusgeschäft für mich. Aber ich habe meinen Spaß an der Entwicklung (manchmal auch nicht 🙂 und ich bin um eine Unmenge an Erfahrungen reicher geworden, Eine Garantie, daß an HyperSpeed alles so läuft wie es soll, kann ich natürlich nicht bieten. Aber ich entwickle dieses Teil eigentlich für mich und von daher werde ich schon aus Prinzip versuchen jegliche Fehler auszuschließen. Schon das Layout an sich stellt nicht nur einfach eine Verbindung der benötigten Chips dar. Wie einigen Experten sicher bekannt ist, sind dort für ein zuverlässiges System einige Regeln zu beachten. So, nun will ich mal mit der Sprache herausrücken. Also ich habe einmal sämtliche Einzelteile außer RAMs, ROM und die Platine zusammengerechnet und bin auf ca. DM 214,- gekommen. Der Preis der Platine ist momentan noch ungeklärt.

Ich hoffe aber, daß er zwischen DM 30,- und DM 40,- liegen wird – das hängt auch mit von der Stückzahl ab. Bei den RAMs sind nach oben hin praktisch keine Grenzen gesetzt. Aber als Minimalvarlante kommen 128KB in Frage. Davon bekomme ich im Moment 128Kx8/70ns für DM 26,- und 128Kx8120ns für DM 50,-. Bei größeren Sachen wird’s schon etwas teuerer: 512Kx8/70ns für DM 310,-. Wer Händler kennt, die preiswertere Angebote haben, der kann sich ja mal bei mir melden. Ich bin z.B. schon geraurne Zeit auf der Suche nach 512Kx8115ns. Den Preis des ROMs kann man eigentlich vergessen (minimal werden 16KB benötigt). So, ich denke rechnen könnt Ihr selbst, so daß jetzt ein wenig Klarheit herrschen sollte.

Ich suche übrigens nach wie vor Leute, die Interesse haben ein bißchen was für HyperSpeed zu programmieren. Eines steht auf jeden Fall fest: Ich kann und will mich nicht auch noch um ein neues bzw. auf 16Bit optimiertes Betriebssystem kümmern. Im derzeitigen „Lieferumfang“ von HyperSpeed wird nämlich kein neues BS vorhanden sein. Lediglich einige Routinen zur HyperSpeed – Steuerung werde ich da mit einbauen. Ansonsten Wird das alte OS verwendet (evtl. auf neuem ROM auf dem lokalen Bus).

Das war eigentlich vorerst alles von meiner Seite. Wenn HyperSpeed fertig ist werde ich mich wieder mal meiden bzw. falls Ihr Interesse daran habt solltet Ihr Euch jetzt bei mir meiden. Eines möchte ich aber noch vorausschicken: HyperSpeed ist nichts für den „Otto – Normalverbraucher, sondem eher etwas für aktive Programrnierer, Bastler und Entwickler.

Tschüs, Mario

Digital Force Developments
Mario Trams An der Eiche 1
09577 Lichtenwalde Tel.:037206f71232
Email:mario.trams@informafik.tu-chemnitz.de

Demokurs Teil 2

 

Herzlich willkommen zum zweiten Teil des Demokurses. Zuerst möchte ich nur noch erwähnen, daß es immer bessere, schnellere oder einfachere Routinen gibt. Vielleicht drücke ich mich auch manchmal umständlich aus. Sollte dies der Fall sein, so teilt mir doch einfach Eure Meinung mit. Denn nur wenn man Feedback bekommt, kann man sich verbessern.

Ich hoffe, daß einige Bit Byter den Source-Code angeschaut haben und gemerkt haben, daß die Routine nur für die x-Koordinaten von 0-255 geeignet ist.

Eine Erweiterung auf 320 bzw. noch weiter, wenn man Overscan benutzt, ist kein Problem. Auf der Diskette befindet sich eine neue Version der Plotroutine, die auch bis 320 Pixel funktioniert. Sie stammt von Heiko Bornhorst für den Atmas II.

Eine Pixelroutine kann man immer gebrauchen, so zum Beispiel für:

  • Funktions-Plotter, wie in diversen Demos
  • Sternenscrolling, usw.

Jeder sollte einmal eine Plot-Routine geschrieben haben. Ich finde, man gewinnt dadurch ein Gefühl für die Grafikstufen des Antics und nimmt einem die „Angst“ vor Hires-Grafik.

Durch einige Bit Byter wurde mir mitgetei
lt, daß es schon Demo-Menüs auf dem XL gibt, sogar Game­Menüs. Dies wollte ich zur Vollständigkeit noch erwähnen (Unity Demo).

Urn was kümmern wir uns dieses Mal? Wie wäre es mit einem Big-Scroller??? O.k. ist ein wenig langweilig, aber wie bei allem lernt man auch dabei einiges über den XL. Es gibt viele Arten von sogennanten Scrollern. Ein Scroller bezeichnet eigentlich nur eine Laufschrift oder einen Bereich, der verschoben wird.

Einige werden schon welche programmiert haben, was ja dem Programmierer durch den Antic relativ einfach gemacht wird. Viele Bit Byter besitzen vielleicht einen der 16Bit-Rechner wie Atari ST(E) bzw. Amiga . Da ich u.a. einen STE besitze, habe ich mit Verwunderung vor Jahren schon festgestellt, daß der normale ST mit seinem Shifter (Grafikchip) nicht (!) sanft scrollen kann. Sicher in den ST-Demos wird sanft gescrollt und zwar u.a.mit dem sogenannten „Sync“-Scrolling. Der ST besitzt ein Register für die Anfangsadresse des Bildschirms, aber ohne (!) Low­Byte. Erst beim STE hat Atari dieses fehlende Byte eingeführt. Die Demogruppen haben durch einen ungewöhnlichen Trick (greetx to Delta force (Flick)) dieses Low-Byte simuliert. Um aber sanft zu scrollen, ist ein Low-Byte unbedingt erforderlich. Ich will nicht näher auf das „Sync“-Scrolling auf dem ST eingehen, ich möchte nur die Bit Byter darauf aufmerksam machen, der XL war 1979 schon technisch weiter als der ST, ja sogar der STE (zumindest was die Programmierung und Felxibilität seiner Videohardware betrifft). Gestattet mir noch eine kleine Bemerkungen zum STE. Bei ihm hat Atari endlich ein Softscrollregister, ein Linewid-Register und das fehlende Low-Byte-Register eingeführt, aber auch andere Verbesserungen im Soundbereich. Aber, er kennt immer noch nicht einen flexiblen Bildaufbau. Wozu auch, besitzt er doch nur zwei Farbauflösungen. Wie sagt schon ein Sprichwort, „der Amiga ist dem XL ähnlicher als der ST“. Stimmt, der gleiche Designer der XL-Videohardware hat u.a. beim Amiga mitgewirkt (man korrigiere mich falls dem nicht so ist …).

Vielleicht ist manchem ja der Begriff „Copperlist“ schon mal über den Weg gelaufen, auch ich habe mal kurz auf dem Amiga eine Copperlist ausprobiert und mußte feststellen, sie ähnelt doch in den grundlegenden Dingen der „Displaylist“ des XLs. Aus diesen Gründen werde ich nicht auf dem ST programmieren, da ich einfach den Antic gewohnt bin und ich damit machen kann was ich will.

Grundsätzlich unterscheidet man beim Scrolling

  • horizontale und vertikale Scroller
  • „Big“-Scroller, d.h. deren Zeichensatz ist größer als der 8×8 Font des XLs. Dabei handelt es sich auch nur um „normale“ Scroller, eben nur mit größeren Buchstaben.
  • „perspektivis.che“ Scroller, wie z.B. 3D-Scroller („Star Wars-ScrolleC) oder „Street Fighter 2­Scroller‘. Der 3D-Scroller aus dem Krieg der Sterne – Film („In einer fernen Galaxie…“) ist weltbekannt, eine Laufschrift läuft von unten nach oben, also vertikal, aber in den Bildschirm hinein, d.h. gekippt. Diesen Scroller habe ich erst in letzter Zeit auf dem XL gesehen, ich könnte mir vorstellen, daß er relativ schwer zu programmie­ren ist, da man ja im GC-Modus scrollen und die Zeichen auch noch je nach Höhe verzerren muß. Der Begriff SF2-Scroller kam erst seit dem gleichnamigen Nintendo-Modul auf, ich glaube die alte Bezeichnung ist eher „Landscape“­Scroller, Ein Teil des Bildschirms, z.B. ein großer Zeichensatz z.B. 32 Gr.8 Zeilen hoch, wird per­spektivisch horizontal gescrollt, d.h. die unterste Zeile amschnellsten, die höheren entsprechend langsamer abhängig von deren Entfernung zu der untersten Zeile. Man bekommt einen räumli­chen Eindruck. Ich glaube der Titel Nr. 30 war so programmiert, um diesen Scroller werden wir uns auch noch beschäftigen. „Landscape“ vielleicht deshalb, weil ungefähr so gescrollt wird, wie wenn man bei fahrenden Auto aus den seitlichen Fenstern schaut. Die Landschaft (Landscape) bewegt, d.h. scrollt ähnlich vorbei, Nahe Bäume bewegen sich schneller vorbei als entfernte, Berge stehen sogar.
  • PM-Scroller, werden meistens für vertikale Scroller eingesetzt. PM steht wie immer für „Player-Missle“, d.h. die XL-Sprites. PM eignen sich für vertikale Laufschriften deshalb, weil sie über den ganzen Bildschirm gelegt werden kön­nen und der lineare Speicheraufbau für Scrolling auch sehr geeignet ist, Ein wichtiger Vorteil ist, daß sie vom Hintergrund gänzlich unabhängig sind, man kann mit diesen Scrollern einigen Un­sinn anstellen. Als Nachteil habe ich aber emp­funden, daß sie nur 8×8 Fonts darstellen können. Man kann aber mehrere Player nebeneinander stellen und kann so größere Fonts darstellen. Wie gesagt, vertikale Scroller sind einfach dar­zustellen und zu programmieren, aber horizontale sind schon ein wenig schwieriger, da man quasi .’per Hand“ scrollen muß, d.h. man muß selber die Bits verschieben. Diese Art des Scrollings benötigt mehr Rechenzeit, da ja softwaremäßig gescrollt wird ohne jedliche HardwareunterstÜt­zung durch den Antic. Es ist schon ein wenig un­heimlich, daß beim XL alles (aber auch wirklich alles) irgendwie zu einem harmonischen Ganzen verschmilzt. Legt man alle Player+Missles mit der höchsten Breite nebeneinander, so verdecken sie genau den sichtbaren Bildschirm! Man hat dann quasi einen zweiten Bildschirm unabhängig vom Hintergrund. Was man alles damit anstellen kann…
  • „Sinus-Scroller“. Eine ganz normale Laufschrift, bei der jeder Buchstabe auf eine andere y­Position z.B. eine Sinuskurve, gesetzt wird. Nur im Grafik-Modus möglich.
  • „per Hand“-scrolling: Wie auf dem ST früher, muss man sich um-alles selber kümmern, d.h. die Bits durch den Speicher schieben, da ja der Antic nicht helfen soll. Kann sich jemand an das Visdom 1-Demo von Jac erinnern? Ich glaube der unterste Scroller war ein solcher Scroller, da Jac erwähnt, er wäre ein 8-Bit Scroller. Würde man per Antic scrollen, so könnte man nur um jeweils 2 Bit verschieben. Vorteil des per Hand­Scrolling ist, daß man das Hardwarescrolling des Antics noch zur Verfügung hat und nicht für das ‚.normale` Scrolling verbraten hat. Damit lassen sich einige nette Effekte darstellen…
  • „Rasterscroller“‚: Ich führe hier mal diesen Begriff ein, Vielleicht kennen einige die Spiele „Rainbowwalker“, ‚Trailblazer“ und natürlich „Dimension X‘. In diesen Spielen wird ein quasi 3d-Effekt erzeugt, indem man ein Schachbrett­muster erzeugt und sich ähnlich dem „Landscape“-Effekt perspektivisch richtig bewegt und zwar in den Schirm „hinein“. Dieser Effekt ist schwer zu beschreiben, den muß man eigentlich gesehen haben.

So genug der Theorie, steigen wir jetzt ein in das Scrolling auf dem XL. Ich werde kurz die einzelnen Arten abhandeln, wobei kleine Beispiele nicht zu kurz kommen:

Scrolling bezeichnet das Verschieben eines Bildes. Es gibt zwei Arten, die der XL uns zur Verfügung stellt:

  • Hardscrolling
  • Softscrolling

Zum Hardscrolling: Jeder kennt den LMS-Befehl des Antics. Dieser Befehl bewirkt, daß der Bildspeicherzähler (Bezeichnung aus „Atari intern“, Data Becker) des Antics mit der Anfangsadresse des Speichers geladen wird, den man darstellen möchte. Hört sich hochtrabend und kompliziert an, ist es aber nicht.

Folgende kurze Displaylist soll uns beim Verstehen helfen:

Dlist	.DB $70,$70,$70            ;3*8 Leezeilen         .DB $42                    ;der LMS-Befehl adr     .DW Zeile                  ;Unsere Scrollzelle         .DB $41                    ;JMP zurück nach Dlist         .DW Dlist Zeile   .at "Dies ist ein Scrolling-Demo..."

 

Der LMS-Befehl des Antic
s ist $40. Die 2 legt den Grafikmodus fest, nämlich Antic-Modus 2 entspricht Basic-Modus 0 (Graphics 0). Ein Verschieben könnte man jetzt so erreichen, daß man jeden VBI diese LMS-Adresse erhöht um eins:

VBI      inc LMS          jmp $e462

(siehe Beispiell.src auf der Disk) Wie jeder gleich erkennt geschieht das sehr schnell. Man kann aber nichd lancisamer scrollen, da man sonst ein Ruckeln feststellen kann. Die einzelnen Zeichen der Läufschrift hüpfen immer eine Position weiter. Hier das Programm (Beispie12.src) dazu:

loop     lda#2        ;warten auf 2 VBIs          sta 540      ;wird vom Xi jeden Vbi decrementiert loop1    Ida 540          bne loop1          jsr scroll           jmp loop  scroll   inc Ims          rts

Wie man sieht ist ein Ruckeln zu erkennen, was nicht schön ist. In einem Demo muß sich alles sanft und soft bewegen, zumindest die Scroller. Der Antic kann ja uns dabei helfen. Kann sich jemand an mein „Overlame~‘-Screen erinnern? Da wurde das Ruckeln als Gag eingesetzt, siehe auch Hard-Megademo-Eingangsscreen.

Wie man sieht ist ein Erhöhen der LMS-Adresse bei schnellem Scrolling angebracht, nicht aber bei kleinen Scrollschritten.

Hier hilft uns nun der Antic mit dem horiziontalen und vertikalen Softscrolling. Setzt man in den Anticanweisungen das entsprechende Bit, so verschiebt der Antic diese Zellen um die entsprechende Anzahl von Farbtakte. Die Anzahl um wieviel steht in den Registern Hscrol $d404 und Vscroi $d405. Es ist einzusehen, warum um Farbtakte ver­schoben wird und nicht um einzelne Bits. Man stelle sich eine Laufschrift in Gr. 12, d.h. im 4-Farb­Modus, vor. Zwei Bits repräsentieren ja eine Farbe bzw. einen Bildpunkt. Würde man nun um einzelne Bits scrollen, so würde der M die Farben falsch interpretieren und damit würde die Grafik falsch dargestellt werden. In Gr.0,2,3 macht dies kein Unterschied. Hier Wird „richtig‘ verschoben, in Gr.9 definieren 4 Bits einen Bildpunkt und würde beim Scrollen um einzelne Bits zu hässlichen Farbveränderungen kommen. Diese kleinen Anmerkungen sind nur für diejenigen unter uns, die ‚.per Hand“ scrollen möchten! (Siehe weiter unten) Wenn ich also von „Bits verschieben` spre­che, so meine ich eigentlich um Farbtakte bzw. Pixel! Der geneigte Programmierer muß eigentlich nur wissen, um wieviel Pixel man verschieben muß, damit man sanft scrollt.

Durch die Hardwareregister kann man maximal 16 Farbtakte verschieben!

Wie aber kann man dann größere Bereiche scrollen? Man muß das Hardscrolling mit dem Softscrolling kombinieren. Der Antic interpretiert nur die unteren 4 Bits der Register H- und Vscroll, d.h. der Wertebereich geht von 0 bis 15. Ab den Wert 16 ist man quasi, wieder am „Anfang“.

Hier ein kleines Beispiel für eine einzelne Scrollzeile in Gr.0. Die Scrollroutirie sollte immer (!) im Vertical-Blank (VB]) ausgeführt werden, da sonst ein häßliches Ruckeln und Flackern auftritt (Beispie14.src).

vbi       jsr scroll           jmp $e462 scroll    lda shscrl           beq 0          ;wenn 0, dann hardscroll           dec shscrl     ;jeden Vbi einen Farbtakt verschieben           lda shscrl     ;unser Schattenregister für Hscrol           sta Hscrol     ;ins Hardwareregister           rts .0        lda #3         ;Höchstwert für Hscrol           sta shscrl     ;wieder von Anfang ab Farbtakt 0           sta hscrol           clc           lda lms        ;nächster Buchstabe           adc #1         ;durch erhöhen der LMS Adresse           sta lms           lda lms+l           adc #0           sta lms+1           cmp /texten    ;Ende vom Text schon erreicht?           beq .1. .9        rts .1        lda lms           cmp #textend           brie .9           lda #text  ;wieder ab Anfang von Text scrollen           sta [ins           lda Itext           sta Ims+I           rts dlist     .hx 52 ;$40=LMS, $02=Gr.0, $10 mit Hscrol lms       .da text ;unser Text                    .hx 41                    .da dlist text               .at'Dies ist ein Demotext für das Abbuc Magazin...." textend .at"          "

Hier als Anmerkung zum horizontalen Softscrolling. Damit man sich merken kann, ob man das Hscroll-Register herunter oder hinaufzählen muß, soll eine kleine Eselsbrücke helfen:

Will man nach rechts scrolien, d.h, der Bildschirm bewegt sich nach links, dann muß man ja die LMS-Adresse INCrementieren, was zur Folge hat, daß man Hscroll DECrementieren muß!

Will man nach links scrollen, dann wird die LMS­Adresse DECrementiert, Hscroll muß dann analog zu oben INCrementiert werden!

Wie man sieht also immer genau entgegengesetzt. Diese kurze Einführung soll nur dazu dienen, das Grundprinzip zu verstehen. Erst wenn der Pro­grammierer das obige verstanden hat, kann man auch diese Hardwareunterstützung des Antics für andere Effekte einsetzen wie z.B. `Big-ScrolleC, „Sinus-Scroller“ u.a.

Der Zeichensatz des Xls ist mit seinem 8×8-Font doch etwas zu klein geraten. Man kann sich quasi helfen, indem man eine andere Grafikstufe wählt z.B. Gr. 1 oder 2 (Antic-Modus 6+7). Will man größere Zeichensätze darstellen, genügt es die ein­zelnen Buchstaben aus normalen 8×8-Zeichen zusammenzusetzen. Man könnte einzelne Fonts in einem Grafikprogramm zeichnen (z.B. 16113, 3212 Pixel-Fonts) und dann in einen Zeichensatz umwandeln, d.h. von Hires-Grafik zu Zeichensatzgrafik. Dafür gibt es schon einige Programme (natürlich auch von mir … )

Ein weiterer Weg ist es Print XI-Fonts (d.h. Signum­Fonts v. ST) zu verwenden. Man schreibt sich ein kleines Schpt, daß das Alphabet in eine Druckdatei ausgibt. Dieses Print-File wandelt man in eine 320×1 92-Gr.8-Grafik um. Dann lässt man wieder ein Umwandler „drüberlaufen“ und erhält einen neuen Zeichensatz. Mit einem Zeichensatz ist es nicht ge­tan. Jeder Buchstabe besteht jetzt aus mehreren umdefinierten Buchstaben des Xis.

Man nehme an, ein Buchstabe bestehe aus 44­Zeichen, d.h. 32×32 Pixel mono oder 16×32 farbig. Was benötige ich nun zum Scrollen?

Ich benötige einmal diesen neuen Zeichensatz und zusätzlich eine Tabelle mit den neuen Buchstaben. In dieser stehen die verwendeten XI-Zeichen pro Buchstabe also wie im angenommen pro Buchstabe 16 Zeichen! Es representiert nicht mehr ein Byte ei­nen Buchstaben auf dem Schirm.

Das Scrollprinzip ist immer gleich, nur mit einem Unterschied
. Ich darf erst einen Buchstaben aus der Laufschrift holen, wenn ich einen „Bildschirm“­Buchstaben gescrollt bin. In der alten Methode habe ich einen neuen Buchstaben geholt, wenn ich 4 oder 8 Pixe( gescrollt bin. Dies ist ja korrekt, da ein Zei­chen aus 8×8 Pixel bestand, also einem XI-Zeichen.

Zum Veranschaulichen ein kurzes Ablaufschema:

phase 0:

Zeichen aus dem Scroller holen, Adresse des ~Igroßen‘ Zeichen ermitteln (anhand einerTabelle) und in den Bildschirm kopieren.

phase 1:

Jetzt je nach verwendeten Grafikmodus 4 oder 7 Pixel sanft per Hscrol $d404 scrollen Die Lms-Adresse erhöhen. Dieses solange wiederholen bis man einen .’großen“ Buchstaben gescrollt ist. Bei z.B. 32×32 Pi­xelfont muß ich 4 mal die Lrns-Adresse erhöhen! Ist der Bigfont nur 16 Pixel breit, so könnte man auch das Hscrol-Register die „ganze“ Zeit verwenden und nachdem man 16 Pixel verschoben hat, die Lms­Adresse um 4 erhöhen!

phase 2:

Nun muß man den ScroIlbereich um die Breite eines «großen« Buchstabens verschieben durch einfaches Umkopieren des Bildschirmrarns. Erst jetzt kann man wieder bei Phase 0 beginnen und den nächsten Buchstaben aus der Laufschrift holen.

Die obige Routine muß folgendermaßen erweitert werden:
vbi      jsr scroll          imp $e462   scroll   Ida phase          bne softscroll          Idx count             ;Zähler im Scrolltext          Ida text,x            ;Buchstaben holen          tax                   ;Adresse des 'großen" Zeichens          lda fontl,x          sta vo          lda forith,x          sta v0 	 ida #scrram+44        ;Adresse im »unsicht­ 	 sta vl                ;baren' Bereich 	 lda Iscrram+44 	 sta vl+I 	 ldx #4                ;Anzahl der Zeilen 	 stx zaehler           ;für das Hardscrolling (Breite) kopieren dy #0 .0       Ida (v0),y          sta (vl),y          iny          Cpy #4          bcc.0          cic          lda vo          adc #4          sta vo          Ida v0+1          adc #0          sta vo+l          C1C          lda vl          adc #48          ;Offset für Zeilenlänge          sta vl          Ida vl+l          adc #0          sta vl+l          dex          brie kopieren          Ida #1          sta phase          Ida #4          sta shscrl          rts softscroll dec shscd      ;jeden Vbi ein Farbtakt ver-          Ida shscd        ;schieben, unser Schattenregister          sta Hscrol       ;für Hscroi ins Hardwareregister          beq 0            ;wenn 0, dann Hardscrolling          rts .0       lda #3           ;Höchstwert für Hscrol          sta shscrl       ;wieder von Anfang ab Farbtakt 0 dec zaehler               ;bis ein ganzes Zeichen gescrollt          beq A            ;wurde          inc Ims          ;das "Hardscrolling" für 4 Zeilen          inc Ims+3        ;da unser Buchstabe 4 Zeilen          inc Ims+6        ;(32 Pixei) hoch ist.          inc ims+9          rts .1       lda #Screen      ;LMS-Adr, wieder auf Anfang          sta Ims          ;setzen          lda /Screen 	 sta Ims+l 	 lda #0           ;neues Zeichen 	 sta phase 	 ldx #44          ;"per Hand" nach links scrollen .2       lda screen+4,x 	 sta screen,x 	 lda screen+4+48,x 	 sta screen+48,x 	 lda screen+4+96;x 	 sta screen+96,x 	 lda screen+4+144,x 	 sta screen+144,x 	 dex 	 bne .2 	 rts dlist    hx 52         ;$40=LMS, $02=Gr.0, $10 mit Hscrol lms      .da screen  ;unser Bildschirm-Rann          .hx 52          .da screen+48          .hx 52          .da screen+96          .hx 52          .da screeri+144          .hx 41          .da dlist text     .at "Dies ist ein Demotext für das Abbuc Magazin  textend  .at tabinit  ldx #0          lda #fontadr          sta v0          lda lfontadr          sat vo+I .0       lda v0          sta fontl,x          lda v0+1          sta fonth,x          cic          lda v0          adc #16        ;ein Buchstabe besteht aus 16          sta vo         ;Zeichen        &n
bsp; lda vo+l          adc #0          sta vo+l          inx          cpx #128          bcc.o          rts

Diese Routine sieht etwas anders aus als die, die auf der Magazin-Disk enthalten ist. Ich mußte eine ältere Routine (die aus dem Titel 37) nehmen, da Wolfgang mich auf der JHV etwas überrascht hat mit der Deadline des Artikels! Ich konnte diese noch nicht testen, das könntet Ihr als `Hausaufgabe“ machen und mir mitteilen, ob obige Routine funktioniert.

Kleine Anmerkungen zu der Routine, die sich auf der Magazindisk befindet:

Als Font wird ein Sprint XL-Font verwendet. Dieser Font hat einen Nachteil, die Zeichen sind nicht alle gleich breit, d.h. das „W“ ist breiter als das I usw. Diesem Umstand wird in dem Unterprogramm „Font1“ so begegnet, indem ich, bevor ich ein Zeichen in den Schirm kopiere, prüfe, ob es eines dieser Sonderzeichen ist. So werden nur die Bytes in den Bildschirm kopiert, die auch zu diesem gehören. Der „Softscroll“–Routine wird dann durch die Va­riable „Count 1′ mitgeteilt, nach wievielen Bytes das nächste Zeichen aus der Laufschrift an der Reihe ist. „Hard“ ist die Hardscroll-Routine und „Soft“ die entsprechende Softscroll.

Abschließend eine kleine Tabelle mit den Höchstwerten für das Hscroll-Register

Antic Modus Farbtakte pro Byte des Screen-Rasters
2 4
3 4
4 4
5 4
6 8
7 8
8 16
9 16
10 8
11 8
12 8
13 4
14 4
15 4

Der Höchstwert für das Hscroll-Register ist die Anzahl der Farbtakte-l. Die Beispiele auf der Magazin­Diskette sind als Ascii-Source abgelegt. Es könnten einige Anpassungen an die verschiedenen Assembler notwendig sein, so z.B. „lda #“ bedeutet, lade das Lowbyte, „lda /“ das Hibyte!

Ich hoffe, Euch nicht zu sehr verwirrt zu haben und verbleibe bis zum nächsten Mal
Karoli Nadj

Maximilianstr. 153
75172 Pforzheim
Abbuc-Box: Mail an Heaven
oder über das Internet Email an „lord@hp9001.rz.fh-pforzheim.de“

ABBUC Angebote

Restposten von der Jahreshauptversammlung:
Diskettenpack: 30 Disketten, 1 Reinigungsset 5,25″
2 Päckchen Böder Diskettenlabel und eine
100er Diskettenbox nur 26.50 DM inkl. Porto

 

immer lieferbar:

Plotterstifte für den 1020:
Schwarz – 1 Satz – 8,–DM inkl. Porto
Schwarz – 5 Sätze – 23,–DM inkl. Porto
Bunt – 1 Satz – 8,–DM inkl. Porto
Bunt – 5 Sätze – 23,–DM inkl. Porto

 

immer lieferbar

I/O-Kabel 1 Stück – 10,–DM inkl. Porto
I/O-Kabel 3 Stück – 20,–DM inkl. Porto
I/O-Kabel 5 Stück – 30,–DM inkl. Porto

immer lieferbar:

PC-XFormer
Die neueste verfügbare Version mit Update-garantie (siehe Sondermagazin #18) bei uns für: 30,–DM inkl. Porto erhältlich.

immer lieferbar

CD-ROM
mit ATARI-8-Bit Programmen fertig in XFD­Files gepackt um sie mit dem Xformer aufrufen zu können oder im ATR-Format, um sie direkt über das S102PC Interface auf dem Atari aufrufen zu können. Fast alle ATARI Hardware liegt in Bildern (PCX-Forrnat) vor. (siehe Beispiele auf dieser Seite) für Atari Bit Byter User Club-Mitglieder nur: 53,–DM inkl. Porto

Bitte beachtet auch die Atari Bit Byter User Club – Sonderaktion, die dem Sondermagazin # 18 beilag. Wir warten auf die Rücksendung Eurer Bestellscheine!

 

10er Tastatur

Armin Stürmer stellte auf der Jahreshauptversammlung des Atari Bit Byter User Club wieder einmal neue (!) Hardware für unseren geliebten kleinen Rechner vor.

Es handelt sich um einen Joystick mit integrierter Zehnertastatur.

Dieser robust gebaute Joystick hat an beiden Außenseiten je einen Feuerknopf und ist mit einem fle­xiblen Spiralkabel zum Anschluß an die Joystick­ports versehen.

Als Zugabe gibt es drei Disketten voll mit Program­men, die sich zur Nutzung des Joysticks eignen.

Der Preis für Mitglieder beträgt 24.80DM

Bestellungen bitte an:

Armin Stürmer Blücherstr. 17
65195 Wiesbaden
Tel.: 0611-406611

 

Das PD-Mag

Hallo lieber Bit-Byter,

schon öfters hatte ich mir vorgenommen hier im ABBUC-Magazin etwas über mein PD-Mag zu erzählen, doch bisher bin ich einfach nie dazu gekommen. Nun, inzwischen hat das PD-Mag auch so schon ei­nen recht hohen Bekanntschaftsgrad erreicht und kann sich mit über 100 Abonnenten auch schon recht gut sehen lassen.

Doch was genau ist das PD-Mag? Nun, dieses Magazin ist ursprünglich als ein Mag nur für die PD­Szene geplant gewesen und auch heute noch dreht sich fast alles um Public-Domain-Software und inter­essante Neuigkeiten. Doc
h auch andere Rubriken haben sich zu ständigen Einrichtungen gemausert und so setzt sich heute jedes PD-Mag aus einem bunten Mix interessanter Texte zusammen. Natürlich gibt es jedesmal eine Menge Softwaretests, aber auch Buch und Filmtests, einen Assemblerkurs, Tips und Tricks, diverse Wettbewerbe und vieles mehr. Besonders stolz bin ich auf die meistens sehr gut gefüllte Leserbriefecke, in der die Leser ohne Zwang und Zensur über ihre Erfahrungen und anderes plaudern können. Das Magazin bietet in jeder Aus­gabe über 100 Bildschirmseiten Texte, die von ei­nem technisch ausgereiften Menüprogramm aus geladen werden können. Doch die Texte sind nur ein 1 eil jeder Ausgabe. Seit 2 Jahren schon kommt das PD-Mag auf 21 Disketten heraus und ist somit das Umfangreichste Magazin seiner Art. Da der Textteil aber komplett auf eine Diskettenseite paßt, werden die restlichen 3 Diskettenseiten jedesmal mit dem besten gefüllt, was die PD- Szene zu bieten hat. Da wie gesagt viel Platz zur Verfügung steht, erschei­nen regelmäßig auch umfangreiche Programme wie etwas Adventures oder Megademos im PD-Mag. Bei der Software lege ich immer Wert darauf, das wirk­lich jeder etwas von diesem Mag hat. Deshalb findet man in jeder Ausgabe Spiele, Anwenderprogramme und Demos in reichlicher Zahl!

Wenn ich euch jetzt Neugierig gemacht habe, dann schickt mir einen an Euch Adressierten und mit DM 1.30 frankierten Din-A-5 Umschlag und 2 Leerdisket­ten zu. Ihr erhaltet dann innerhalb von ca. 2 Wochen die neueste Ausgabe des PD-Mag zum testen von mir zugeschickt. Warum ich so lange brauche? Nun, da ich von Beruf Schausteller bin komme ich nur et­wa alle 2-3 Wochen mal nach Hause um die Post abzuholen, aber auf eines ist in jedem Fall verlaß, ich beantworte jeden Brief der mich erreicht!

Ich danke jetzt schon für Euer Interesse und ein weiterer Dank geht an Wolfgang Burger dafür, das er diesen und diverse andere Texte von mir mit ins Magazin genommen hat.
Bis demnächst.
Sascha Röber

Sascha Röber, Bruch 101
D-49635 BadBergenz

 

Preisrätsel

 

A.B.B.U.C. PD-Neuheiten

458 T.E.A.C. Problem Solving Kit #2 ED/2S
Smokey and the Bandit: Textadventure Kaufe Fahrzeuge, Funkgeräte etc. und fange den Banditen. Atomkraftwerk: Textadventure Halte den Reaktor in Betrieb und vermeide den GAU. Magic Square: Das berühmte Verschiebespiel in der ATARI-Version. Missionar und Kannibalen: Kopfnuss wie kommt man über den Fluss, ohne gefressen zu werden. Derzeit nicht verfügbar!

0459 The Incredible Laboratory Kopierschutz SD/1S
Mixe im Chemielabor deine eigenen Monster. Hübsch anzuschauende Grafiken. Derzeit nicht verfügbar!

0460 Social Studies/ The Changing Earth ED/2S
Englisches Lernspiel mit Textprogrammen.

0461 Water, Waves And Wind ED/1S
Englisches Quiz über Atmosphäre und Hydroshäre.

0462 Space The New Frontier ED/1S
Englisches Quiz über unser Solarsystem und die Erforschung des Weltraums.

0463 BEST OF MATH, BEST OF LANGUAGE ED/2S
17 englische Lernspiele für Mathe und Englisch.

0464 BEST OF SCIENCE ED/1S
8 englische Ratespiele aus dem naturwissenschaftlichen Bereich.

 

PD- Bibliothek: Theo Schwacke Heinestr.- 17, 45699 HERTEN, Tel. 02366-34696

 

 

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