ABBUC Magazin 045

 


IMPRESSUM

(c) 1996 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

 


Der Gastkommentar

von Wolfgang Ulke, Haltern – Mai 1996

Wolfgang nahm mich mit.

ABBUC – Computerclub Regionaltreffen! Erinnerungen an meine Computerclubzeit anfang der 80er Jahre wanderten mir durch den Kopf.

Roland holte uns vom Bahnhof ab und brachte uns ins Pfarrhaus, wo schon einige warteten. Kurz danach. trafen weitere Freaks ein. Es war die Sprache, die ich sofort erkannte, kurz und knapp, geht, geht nicht, hab ich probiert, läuft, läuft nicht, ist er dran, Zeitproblem, solltest Du mal das versuchen…… !

Ja, dann brachte Alfred Ordnung in die Diskussion. Jeder Freak stellte seine neuesten Erfahrungen und Errungenschaften vor. Zweieinhalb Stunden lief das ab, mir rauchte der Kopf, vieles ging mir ab. Was mir auffiel, kein Streitgespräch war das, sondern suchen nach Unterstützung, ein kramen im eigenen Erfahrungsschatz.

Uber Mittag kam ein Neuer, Ulrich mit Sohn, dazu.

Praktische Dinge führten einige nach dem Essen vor, wobei ich ob der Leistungsfähigkeit der Ataris als acht-bitter nur staunen konnte. Noch am frühen Nachmittag klang das Süddeutsche Regionaltreffen des ABBUC aus und alle verabredeten sich für den 28.10.96 in Herten.

ABBUC – scheint mir ist nicht nur ein über gebliebener Computerclub. Viele Anregungen nahm ich aus diesem Regionaltreffen mit.

Das Abbröckeln der privaten Hilfsbereitschaft ist besorgniserregend, weil in der täglichen EDV-Welt nur Kommerz zählt. Ihr vom ABBUC liefert ein Signal des Engagements, aber wie soll dies ohne „Nachhilfe“ von außen gelingen ? ABBUC goes to Internet ?

Vielen Dank für Eure Gastfreundschaft.

Wolfgang

Schreiersgrüner Messebericht

von Raimund Altmayer (member of R.A. M.)

Abfahrt: Freitag 22.03.96 ca.09.00 Uhr
Ankunft: Freitag, ca. 15.30 Uhr,
bedingt durch Tausende von Baustellen und unnötigen Staus auf den Autobahnen A4/A5.

Angekommen in Schreiersgrün habe ich mich zuerst mal auf die Suche nach meinem vorher reservierten Zimmer gemacht, Dabei wurde ich in eine Straße zitiert, die eigentlich gar keine Straße war, sondern ein aufgerissener Haufen Holperei. MEINE STOSSDÄMPFER! -NEIN! Das machte aber die nette Gastfreundschaft, die mir in meinem Domizil entgegengebracht wurde (zuerst mal Kaffee), wieder wett. Nach einem kurzen Palaver mit der Wirtin übergab diese mir den Schlüssel und ich machte mich auf die Suche nach dem vereinbarten Treffpunkt mit Markus Römer und HelmutWeidner. DieserTreffpunkt sollte laut Markus‘ Aussage in der Sportgaststätte Schreiersgrün stattfinden. Dort bin ich auch hingefahren, mußte aber feststellen, daß ich mich in der falschen Kneipe“ befand. In Schreiersgrün gibt es sogar zwei Gaststätten. In der zweiten Gaststätte teilte man mir mit, daß ich Markus und Helmut um ca. 5 min. verpaßt habe – STOEHN !!

Nach mehreren Anwahlversuchen hatte ich endlich Helmut an der Strippe, der mich zu sich nach Hause beordede. Nach dreimaligem Umfahren des Blockes gelang es mir schließlich, Helmuts Heim ausfindig zu machen, weiches 6 km von Schreiersgrün entfernt in Lengenfeld ist. Nach ausführlicher Begrüssungszeremonie (Originalton Markus: „Morgaeaen… – Originalton Raimund: „Wirsing…“) und einem stutzendem Helmut gab es dann endlich was zu essen. Nach dem Essen wollte Markus das TOP-Mag fertig stellen, was aber an endloser Laberei und fortschreitendem Biergenuß scheiterte. Man könne dies ja noch am Messemorgen erledigen.

Gegen 23.00 Uhr bin ich dann zurück in mein Quartier und hatte auch überhaupt keine Mühe einzuschlafen dank der anstrengenden Fahrt.

————– schnarch ————–­ Samstag, 23.03.1996 8.xx Uhr

Nach einem ausgedehnten Frühstück kam ich an der Messehalle an und mußte mit Erstaunen feststellen, daß Andreas Magenheimer (der AMC vertrat), Thorsten Schall (Jaguar und Lynx), Kemal Ezcan (KE-Soft), Markus Römer (Kaisersoft), Dietmar Rosenberger (der für die WAF gekommen war, allerdings ohne Stand, aber präsent) und Helmut Weidner (der das alles hervorragend organisiert hat) schon fleißig am ausladen und aufbauen waren. Um ca. 9.00 Uhr war derAufbau weitgehend abgeschlossen, aber noch kein Besucher in Sicht. Negatives Gemurmel wurde schon laut. Auf einmal, ich weiß auch nicht wie, waren total viele Leute da. Darunter auch die beiden ACEer, die die Messedemo gleich persönlich brachten, welche eine feine Sache geworden ist. Außerdem brachte die Post (einmal war sie pünktlich) noch einen Demopart von Heaven, der es vorher nicht mehr geschafft hatte. Nun ging der Kaufrausch los und die Leute ramschten wieder, wie es auf den Messen a
llgemein bekannt ist. Nachdem der Hunger an Software gestillt war, wurden die neuen Sachen ausgetestet. Neues gab es außer Spielen nichts.

Was gab’s überhaupt ?

KAISERSOFT hatte eine neue Kollektion Polenspiele vorzustellen, die auch zu kaufen oder zu bestellen waren. Natürlich konnten auch wieder T-Shirts bestellt und ABOs abgeschlossen werden.

KE-Soft hatte die übliche Palette aufbereitet und dazu noch neue Soft aus Amerika vorzustellen.

AMC hatte seinen neue Hardware-Produkte mitge­bracht (Powerpad und Stereoblaster-pro). Auch die AMC-Soft gab es zu erwerben.

JAGUAR & LYNX präsentierte einen Jaguar und einen Lynx mit den neusten Spielen. Es konnten auch Jaguar oder Lynx gekauft werden.

R.A.M. hatte nichts zu verkaufen, veranstaltete aber ei­ne Umfrage bzgl. der Eröffnung einer Bücherbibliothek. Außerdem bestand reges Interesse an der Übertragung von Daten vom XL auf den ST und umgekehrt.

Trotz der geringen Anzahl an Ausstellern, herrschte doch ein sehr reges Aufkommen an allen Ständen.

Irgendwann entdeckte ich zwischen den Besuchern zwei bekannte Gesichter aus den Niederlanden (Namen sind mir unbekannt oder ich habe sie vergessen).

Kurz darauf waren unsere niederländischen User auch bei mir am Stand und eine rege Diskussion entbrannte sich. Dabei ging es zum einen um den Umbau einer XF551 zu einem 3.5 Zoll-Laufwerk und zum anderen wie man Turbo-Basic an Sparta-DOS anpassen könnte. Leider hatten unsere NLer den weitesten Anreiseweg und brachen daher auch zeitig wieder auf (zum Bedauern aller).

Gegen 15.xx Uhr waren die Besucher so plötzlich verschwunden, wie sie erschienen waren. Kurze Zeit später begannen wir mit dem Abbau unserer Stände. Abschließend trafen sich Andreas Magenheimer, Dietmar Rosenberger, Thorsten Schall, Markus Römer, Helmut Weidner und ich uns in der unter dem Saal befindlichen Gaststätte, um bei Essen und Trinken das Nachwort zu halten.

Fazit:
Laut Aussagen von AMC, Kaisersoft und Jaguar hat sich die Messe auf jeden Fall gelohnt, was auch meine Meinung ist. Leider hatte ich nicht die Möglichkeit, Kemal zu fragen, da er so schnell aufgebrochen war. Durch die als Eintritt erhobene „Symbolische Mark` hatten wir bei Kassensturz einen Betrag von DM 73 ‚ – zu verbuchen. Man kann aber nicht sagen, daß genau 73 Besucher gezählt wurden, da manche Leute mehr als eine DM gegeben haben und einige durch das Gedränge sich an der Kasse vorbei mogeln konnten. Wir sind davon ausgegangen, daß zwischen 60 und 65 Besucher anwesend waren. Ein guter Auftakt!

Weiterhin ist zu loben., daß unsere Saalmiete weniger als DM 100,- betrug, worin Heiz- und Stromkosten enthalten waren. Vielleicht ein Anreiz an „westliche` Saal­vermieter.

Mit sehr großer Wahrscheinlichkeit wird es ein Schreiersgrün 1997 geben. Dies ist den Usern zu verdanken, die sich aus allen Teilen Ostdeutschlands auf den Weg machten, um in Schreiersgrün zusammenzufinden.

Ein ganz besonderer Dank geht an Helmut Weidner, der die Messe optimal organisiert hat, nicht zuletzt auch durch die hervorragende Werbung, die er gemacht hat. Alles in Allem kann man Schreiersgrün als gelungene Veranstaltung betrachten und sollte als Beispiel für die Zukunft dienen.

Gtx. Highlander Soft

 

Probleme mit der 80-Zeichen-Karte

Anfang des Jahres wurde vom ABBUC eine Aktion gestartet, bei der man als Mitglied sehr günstig eine XF551-Floppy oder eine XEP80-80-Zeichen-Karte erstehen konnte. Auch ich habe sofort eine XEP80 geordert und innerhalb kürzester Zeit erhalten. Natürlich sehr neugierig habe ich mich sofort ans Ausprobieren gemacht und die Karte wie im Handbuch beschrieben an meinen XL gestöpselt. Groß war die Enttäuschung, als auf meinem Grünmonitor (Commodore DM 602) nur Pixelmüll erschien.

Nach verzweifeltem Studium des Handbuchs und der mitgelieferten Hilfsdatei (XEP80.DOC) und weiteren Versuchen an einem Peacock AI-1 00 Monitor kam ich zu dem Schluß, daß die Karte defekt sein müsse. Also orderte ich bei Wolfgang eine weitere Karte, bei der es leider die gleichen Probleme gab. Damit war erwiesen, daß die Ursache wohl bei den Monitoren, und nicht bei der Karte lag.

Also begann ich noch mal alles auszuprobieren, was mir so einfiel. Dabei kam ich auf die Idee, die Monitore zu öffnen und nach weiteren Potis zum Einstellen des Monitorbildes zu suchen.

Ich schraubte und drehte an so ziemlich allem, was beweglich war und tatsächlich, irgendwann hatte ich lesbare Schrift auf dem Bildschirm, allerdings nur teilweise sichtbar.

Nach weiterem Justieren gelang es mir den gesamten 80-Zeichen Bildschirm auf den Monitor zu bringen.

Mein Tip an alle, die vielleicht ähnliche Probleme haben: Probiert sämtliche Potis aus, die ihr an und in eurem Monitor findet. Bei mir war es das Poti zur horizontalen Verschiebung, das für ein ordentliches Bild gesorgt hat. Aber Vorsicht beim Hantieren am geöffneten Monitor. An einigen Bauteilen kann Hochspannung anliegen. Es besteht leider auch die Möglichkeit, daß ihr keinen Poti findet der zu einem brauchbaren Ergebnis führt.

Dies ist mir bei meinen Peacock- Monitor passiert; der hatte überhaupt keine Regler. Dann ist guter Rat teuer und ein Betrieb der XEP80 an diesem Monitor wohl unmöglich.

Ich hoffe, daß nun einigen Userri, die ähnliche Probleme hatten, geholfen ist und wünsche allen fröhliches Hacken auf ihren XLs und XEs.

Euer Tobias Hang
(SLM-Software, ehemals HS-Computertechnik)

PS: Für die einen ist es Windows95 für die anderen ist es der längste Virus der Welt.

Cracking the Code
Teil 8

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

The Need For Pointers / Wozu Zeiger?

Rekapitulieren wir, worum es im letzten Artikel ging: Die beiden indexed-indirect Modes griffen auf die Daten per 2-Byte-Zeiger zu, die in der Page Null abgelegt waren. Die vorindizierte Methode benutzt das X-Register, indem der Wert im X-Register zur angegebenen Adresse hinzuaddiert wurde. So erhielt man die eigentliche Adresse für den Zeiger. Diese wurde dann indirekt benutzt, vergl. Abb. 1

Die post-indizierte Methode benutzt das Y-Register und wandte sich per Zeiger erst an die Basis-Adresse des Bereichs (area) und addierte dann den Wert aus dem Y-Register, um die endgültige Adresse zu erhalten. Das Schlüsselelement für die beiden Adressiermodes ist natürlich das Nutzen eines Zeigers, um an das Daten-Byte heranzukommen. Es ist wichtig, diese Vorgänge klar zu verstehen, da sie beim Programmieren sehr oft verwendet werden.

Der erste Grund, warum ein Zeiger benutzt werden kann, ist der, die Grenze zu überwinden, die der 6502 absolut indexed Modus vorgibt. Da die Index-Register nur 8 Bit lang sind, können von jeder fest vorgegebenen Basis-Adresse aus nur 256 Bytes angesprochen werden. Die Lösung ist, die Basisadresse als Page Null-Zeiger zu speichern und dann den indexed-indirect Modus zu verwenden. Der Witz an der Sache ist, daß man den Wert des Zeigers ändert, um auf jedes beliebige Byte zugreifen zu können. Dabei können wir entweder den pre-indexed oder den post- indexed Modus benutzen. Das folgende Beispiel zeigt die Anwendung des pre-indexed Modus zum Verschieben einer Wertetabelle.

LDX #0	;Keep zero ;index. LOOP LDA	(POINT1,X) ;Load a byte. STA (POINT2,X)	;Save it. INC POINT1	;Inc. low pointer. BNL SKIP1	;Skip if not zero. INC POINT1+1	;Else inc. high byte SKIP1 INC	POINT2 ;Same for second BNE SKIP2	;pointer. INC POINT2+1 SKIP2 / /	/	;Perform /	/	;some test. /	/ "branch to" LOOP	;Go back if ;more to copy

Wir gehen davon aus, daß POINT1 und POINT2 (ZEIGER1 und ZEIGER2) sich in Page Null befinden und so definiert sind, daß sie auf zwei Bereiche (Area) im Speicher bzw. zwei Tabellen zeigen. Das X-Register steht auf Null, ansonsten würden wir nicht jedesmal auf denselben Zeiger zugreifen. Bei jedem Schleifendurchgang werden die beiden Zwei-Byte-Zeiger um eins erhöht (incremented); dann wird eine Überprüfung durchgeführt gefolgt von einer Verzweigung zurück zum Anfang, falls weiterkopiert werden soll. Auf diese Weise ist es möglich, Blöcke beliebiger Größe im Speicher zu verschieben. Das Programm hätte in ähnlicher Version das Y-Register benützen können. Aber (wieso Aber?) der post-indexed Modus kann schnell und flexibler sein.

LDY #0	;Start with zero. LOOP	LDA (POINT1),Y ;Load byte. STA (POINT2),Y	;Save byte. INY	;Inc. Index. BNE SKIP1	;skip if not zero INC	POINT1+1	;Else inc. high bytes INC POINT2+2	;of pointers. SKIP1	/	/ /	/ /	/	;Perform /	/	;some test. /	/ "branch to" LOOP	;Go back if ;more to copy

Dieses Programm arbeitet um einiges schneller, denn es finden weniger Speicherzugriffe innerhalb der Schleife statt. Dieses Mal incrementieren wir das Y-Register, anstatt das Low-Byte des Registers zu erhöhen, um bis zu 256 Byte zu kopieren. Sobald das Y-Register wieder bei Null angekommen ist, erhöhen wir einfach die beiden High-Bytes des Zeigers und können so die nächsten 256 Bytes jeder Tabelle in Angriff nehmen.

Wie Ihr sicher längst erkannt habt, wird der post-indexed Modus viel öfter verwendet als das Gegenstück, der pre-indexed Modus, da man so eine Menge Zeit und Bytes im Programm spart: Eine nützliche Folge kann auch sein, daß das Y-Register mit einem neuen Index geladen, damit bearbeitet und danach der alte Index wieder restauriert werden kann, ohne daß man am Zeiger etwas verändern müßte.

Keeping Track / So-Wo-Samma?

Der zweite Grund, warum wir mit Zeigern arbeiten, selbst wenn wir nur 256 Byte oder weniger ansprechen wollen, ist der, daß die betreffenden Data-Tabelle sich möglicherweise nicht an einer festen Position im Speicher befinden. Man muß nur mal in Betracht ziehen, daß wir verschiedene Tabellen im Speicher erstellen wollen, jede von unbestimmter Größe. Man könnte jede Tabelle an einer festen Adresse beginnen und dann hoffen, daß nicht eine die nächste überlappt oder überschreibt. Aber selbst, wenn das nicht passieren würde, würde man völlig unnötig eine Menge Speicherplatz verschwenden. Eine Lösung dafür wäre, den Zeiger auf die erste Tabelle zu setzen, und zwar am Anfang des verfügbaren Speichers. Die nächste freie Adresse würde dann den Zeiger für die zweite Tabelle enthalten usw. Auf diese Weise würde der Speicher effizienter genutzt.

Ein ähnliches Problem haben wir, wenn eine Subroutine in der Lage sein muß, mit einer neben oder außerhalb des Programms „gerade mal aufgestellten“ Tabelle zu arbeiten. Das aufrufende Programm könnte ganz einfach den Zeiger dafür in die Tabelle für die Sub-Routinen-Zeiger ablegen und dann die Subroutine aufrufen. Zeiger werden vom Atari-OS vor allem aus einem Grund benutzt: Die Speichergröße im System könnte unterschiedlich sein. So beginnt z.B. der Bildschirmspeicher bei einem 16K-Computer (Atari 400) an einer anderen Stelle als bei einem 48K-Computer (Atari 800). Das hat zur Folge, daß ein Zeiger bereitgehalten werden muß, der auf diese Zeiger deuten muß. Danach ist es dem OS völlig schnuppe, wo sich der Bildschirmspeicher tatsächlich befindet. Es wird je.: derzeit korrekt Zugriff darauf haben. Ich möchte an dieser Stelle mal darauf hinweisen, daß es recht schlechte Programmierpraxis ist, davon auszugehen, daß manche Speicherbereiche festgelegt sind, wenn sie doch tatsächlich an ganz verschiedenen Stellen liegen können, (Ich habe Programme gesehen, die für 48K-Computer geschrieben waren; ließ man sie auf einem 16K-Computer laufen, blieb der Bildschirm leer, obwohl genug Speicher vorhanden gewesen wäre: Der Speicher für den Bildschirm war durch das Programm verschoben.)

Accessing The Screen / Wie zeig ich’s meinem Kinde?

Der Grund, warum ich mich dafür entschieden habe, mit dem Bildschirm zu beginnen, ist der, daß man daran recht effektiv demonstrieren kann, wie man im indexed-indirect Modus zugreift, wobei man die Ergebnisse sofort – Nein! Nicht auf der Hand! vorAugen hat;
und außerdem istes eine typische Situation aus der Praxis.

Das kurze Programm, mit dem ich Euch beim letzten Mal alleingelassen habe (Listing 4) zeigte alle zur Verfügung stehenden 256 Zeichen am oberen Rand eines Graphic-0 Screens (Screen= Bildschirm). Es tut dies, indem es den Zeiger des OS auf die Ausgangsadresse des Bildschirm-Speichers setzte ($56). Das Y-Register wurde benutzt, um bis zu 256 Stellen im Bildschirm- Speicher zu indizieren. Und an jede Stelle speicherte es den Index-Wert, indem der Wert aus Y in den Accumulator geladen wurde.

Das Screen Layout

Jeder der Standard Graphik- und Text-Mode weist eine feste Anzahl von waagrechten (horizontal) Bytes pro Zeile und eine senkrechte (vertikal)Anzahl von Zeilen auf. Im Zusammenhang mit all diesen Modes gibt es eine einfach „Landkarte“, die im Speicher vorhanden diese Bilddaten steuert. Das erste Byte dieses Speicherbereichs ist der obersten linken Ecke des Bildschirms zugeordnet, das nächste Byte der Stelle daneben und so weiter, bis die erste Zeile voll ist. Die folgenden Bytes gelten entsprechend für diese Zeile, bzw. die Zeile darunter, jeweils von link nach rechts. (Man kann das ein bißchen mit einen) Schachbrett vergleichen, oder meinetwegen mit dem Spiel „Schiffe versenken“. A.K.) Abb. 3 zeigt dies für einen Bildschirm mit 24 Zeilen von je 40 Bytes, wie ihn ein Graphics-0 – Screen bietet. Dabei geben die Nummern in den Kästchen die Bytes an.

Character & Bit Mapping / Buchstaben und Pixel

Die Atari-Hardware bietet zwei Darstellungsmöglichkeiten: Buchstaben (bzw. Zeichen) oder Bit Maps. (Das ist die Verteilung der einzelnen Bits auf dem Schirm nach Plan um z.B. ein Bild darstellen zu können. A.K.) Der Unterschsied besteht darin, wie die Bytes aus dem Speicher dargestellt werden: Beide haben den Effekt eine Gruppe von Bildelementen, als Pixel bezeichnet, auf dem Bildschirm farblich zu verändern. Ein Pixel ist die kleinste adressierbare Einheit eines Bildschirms (bzw. eines Displays).

In einem Zeichenmodus (Character mapped mode) wie etwa Graphics-0 bewirkt das Einlesen jedes Bytes aus dem Speicher das Setzen bzw. Verändern einer Pixel-Matrix, also eines kompletten Pixel-Satzes. (Ein solcher Satz von Pixeln, z.B. 8×8, sieht wieder ein „Schachbrett“ aus, das man als Matrix bezeichnet. Allerdings hat eine Matrix eigentlich keine schwarzen und weißen Felder. A.K.) Im Fall Graphics-0 handelt es sich um ein 8×8 Pixel großes Feld (enthält also 64 Pixel). Die exakte Anordnung der tc, Pixel je Buchstabe bzw. Zeichen ist im Character- Set festgelegt (dem Zeichensatz; bei Buchstaben spricht man von einem Font. Wer schon mal mit einem Zeichensatz 118 119 oder Font-Editor gearbeitet hat, kennt das zur Genüge, inklusive der lästigen Einschränkungen. Der Zeichensatz-Editor von Daisy-Dot 3 bietet eine 32×32 Matrix. Das hat aber mit diesem Thema nichts mehr zu tun. A.K.)

Im Bit Map Modus wird jedes Byte in eine Anzahl von Bitgruppen oder Felder aufgeteilt, die alle dieselbe Anzahl von Bits haben, also 8 mit je 1 Bit, vier mit je 2 Bits, zwei mit je 4 Bits und 1 mit einem kompletten Byte. Jede Gruppe von Bits legt den Status eines logischen Pixels auf dem Schirm fest. Ein logisches Pixel ist eine Gruppe von physikalischen Pixeln (also echten Bildschirmpixeln), die als eine feste Einheit behandelt werden. Da die physikalischen Pixel nur von der Hardware angesprochen werden können, bezeichnen wir hier jetzt verkürzt die logischen Pixel einfach als Pixel oder Punkte. (Noch mal schnell zum Verständnis: Wenn wir auf dem Schirm mit Text einen Punkt sehen, kann dieser tatsächlich aus vier Pixeln bestehen, damit man ihn überhaupt erkennen kann. Dieser Punkt ist ein logisches Pixet bestehend aus vier physikalischen Pixeln A.K.)

Die Unterscheidung ist nicht besonders wichtig, solange wir uns darüber klar sind, daß eine Gruppe von Bits in einem Byte den Zustand eines Bereichs auf dem Bildschirm kontrolliert. Z.B. bietet Graphics-8 40 Bytes pro Zeile und 192 Zeilen insgesamt. Jedes Byte ist in 8 Bits aufgeteilt, jedes Bit „schaltet“ ein Pixel entweder aus oder ein (bei einer Farbe!). Das macht 40×8=320 Pixel pro Zeile bei vertikal 192 Zeilen.

Using a Bit Mapped Screen / Arbeiten mit einem Bitmap-Screen

Listing 1 greift auf den Pixel-Screen (im Gegensatz zum Zeichen-Schirm. A.K.) über den OS- Zeiger $58 zu – Dies gilt für alle Modes! -um ein beliebig bewegbares Muster zu erzeugen.
CONSOL und RANDOM sind Labels, die erstellt wurden, um auf spezielle Stellen in der Hardware zuzugreifen. Alles, was wir im Augenblick davon wissen müssen, ist, daß wir durch das Auslesen von CONSOL den Zustand der START-, SELECT- und OPTION-Taste erhalten (also der sog. Konsoltasten! A.K.), durch Auslesen von RANDOM eine 8-Bit-Zufallszahl (random=zufällig, beliebig). SAVMSC ist der Name des Zeigers, der auf das erste Byte des Bildschirmspeichers deutet. PZERO und TEMP sind Variable, die vom Programm benutzt werden. Ihnen sind die Werte $CB bzw. $CD zugeordnet. Man hätte auch gleich feste Zuordnungen machen können, z.B. PZERO=$CB; stattdessen habe ich den Location Counter (Speicherstellen-Zähler) auf $CB gesetzt und das Label PZERO defininert (Zeile 140). *=- *+2 weist dem Locatiön Counter seinen Wertzu, nämlich immer*, plus 2 zurück an den Location Counter.Auf diese Weise wird er Location Counter immer je zwei vorwärtsbewegt. Dasselbe passiert mit TEMP, das den Wert $CD bekommt. Dieses Vorwärtsbewegen des Location Counter wird häufig als „define space“ (Leerzeichen, Leerraum definieren) bezeichnet, und manche Assembler bieten dafür eine spezielle Anweisung. Der Vorteil dieser Methode liegt darin, daß man sofort erkennen kann, wieviel Bytes für jeden Speicherbereich gedacht sind (in diesem Fall zwei), und daß man keine Extraberechnungen für den Wert jedes Labels anstellen muß.

0100	CONSOL	$D01F	;Read START/SELECT/OPTIÖN. 0110	RANDOM	$D20A	;Random number generator. 0120	SAVMSC	$58	;Screen pointer. 0130	$CB	;Start of variables. 0140	PZERO	*+2	;Pointer to screen. 0150	TEMP	*+2	;Temporary locations. 0160	=	$0600	;Start of program. 0170	PLA	;Clean up stack. 0180	START	LDA	SAVMSC	:Copy low byte 0190	STA	PZERO	;of pointer. 0200	LDA	SAVMSC+1	;Same with high. 0210	STA	PZER0+1	 0220	NEWY	LDA	RANDOM	;Get random number. 0230	CMP #192	;If 192 or more 0240	BCS	NEWY	; get another one. 0250	STA	TEMP	;Save as low byte of Y. 0260	LDA	#0	 0270	STA	TEMP+1	;Zero high byte. 0280	LDX	#3	;Count of 3. 0290	MULT8	ASL	TEMP	;Multiply by 2 ... 0300	ROL	TEMP+1	 0310	DEX	;Dec. count and branch 0320	BNE	MULT8	; to give 8 times TEMP 0030	LDA	PZERO	;Add low byte to PZERO 0340	CLC	 0350	ADC	TEMP	 0360	STA	PZERO	 0370	LDA	PZER0+1	;Add high byte. 0380	ADC	TEMP+1	 0390	STA	PZER0+1	 0400	ASL	TEMP	;Multiply TEMP 0410	ROL	TEMP+1	; by 4 0420	ASL	TEMP	; to give 32 times 0430	ROL	TEMP+1	; as total. 0440	LDA	PZERO	;Add to PZERO again.. 0450	CLC	 0460	ADC	TEMP	 0470	STA	PZERO	 0480	LDA	PZER0+1	;Add high byte 0490	ADC	TEMP+1	; to give 40*Y value. 0500	STA	PZER0+1	 0510	NEWX	LDA	RANDOM	;Another random
number 0520	AND	#$3F	;Zero top 2 bits. 0530	CMP	#40	;If 40 or more 0540	BCS	NEWX	; get another. 0550	TAY	;Save as Index into line. 0560	LDA	RANDOM	;Another random number. 0570	STA	(PZERO),Y	;Save an screen. 0580	LDA	CONSOL	:Test buttons. 0590	CMP	#7	All up? 0600	BEQ	START	;Yes - go again. 0610	RTS	;Else return to BASIC.

Und letztendlich kann der komplette Block in einen anderen Speicherbereich verschoben werden, indem man einfach den Ausgangswert ändert, bevor er dem Label zugewiesen wird. Das spart bei einer größeren Anzahl von Labels eine Menge Zeit!

Nun zum Programm! Der Code startet bei $60. Als erstes muß das Byte, das vom BASIC übergeben worden ist, runter vom Stack. Damit der Inhalt von SAVMSC nicht verändert wird, wird der 2-Byte-Zeiger in die Labels PZERO und PZER0+1 kopiert. Nun wird eine Zufallszahl in den Accumulator geladen und mit der Anzahl der vorhanden Zeilen (des Bildschirms) verglichen. Ist die Zufallszahl größer oder gleich 192, wird ein neue Zahl gezogen. Sobald diese Schleife erfolgreich durchlaufen ist (die Suche nach einer Zufallszahl < 192), enthält A eine Zahl zwischen 0 und 191 (beide Endwerte eingeschlossen). Diese Y-Koordinate wird in TEMP abgespeichert und das High:Byte von TEMP (also TEMP+1) wird auf Null gesetzt. In 280 bis 500 wird dieser Y-Wert dann mit 40 multipliziert (40 ist die Anzahl der Bytes pro Zeile). Daraus ergibt sich der Ausgangspunkt, an dem die jeweilige Zeile beginnt. Dieser wiederum wird zu unserem Zeiger hinzuaddiert, der auf den Anfang des Bildschirmspeichers zeigt, nämlich PZERO.

Um die Routine schnell und handlich zu machen, mit der TEMP multipliziert wird, multiplizieren wir sie mit 8, addieren das Ergebnis zu PZERO und multiplizieren dann TEMP nochmal mit 4, was insgesamt 32x ergibt. Auch dies wird zu PZERO addiert. Somit ergeben die 8xTEMP plus die 32xTEMP schließlich die 40xTEMP, die zu PZERO hinzuaddiert werden mußten. Diese Multiplikationen werden alle an TEMP und TEMP+1 mit Hilfe von Shift- und RotateOperationen durchgeführt, wobei jedesmal mit 2 multipliziert wird.

Nun wird eine andere Zufallszahl geladen. Aber dieses Mal muß sie zwischen 0 und 39 liegen. Deshalb vergleichen wir sie mit 40 und holen uns dann ggf. eine andere Zahl, falls das Carry gesetzt ist. Um das Ganze zu beschleunigen, werden die beiden höchsten Bits der Zufallszahl mit Hilfe der Funktion AND und einer 00111111-Maske (bzw. $3F-Maske) auf Null gesetzt, so daß die größtmögliche Zahl 63 wäre. Somit erhöht sich die Chance, daß wir schnell eine geeignete Zahl bekommen erheblich (63%-Chance gegenüber 15% ohne diesen Trick!). Dieser Wert wird als Byte-Index für die ausgewählte Zeile benutzt und wird nun ins Y-Register verschoben, Und noch eine Zufallszahl wird gezogen, und das 8-Bit-Muster wird in das ausgewählte Bildschirm-Byte gespeichert (ausgewählt durch unsere bisherigen Rechenvorgänge: Zeile und Stelle; die Angaben dafür erhalten wir durch PZERO und den Inhalt des Y-Registers.). Durch Ändern des Bytes werden 8 Bit in diesem Bereich an- oder ausgeschaltet. Schließlich lädt das Programm den Wert von CONSOL, vergleicht ihn mit 7 (keine Taste gedrückt) und beginnt wieder von vorne. Ist eine Taste gedrückt, endet es und kehrt zurück ins BASIC.
Um das Programm laufen zu lassen, tippt Ihr entweder das BASIC-Programm ein (Listing 2) oder Ihr assembliert den Sourcecode von Listing 1 und ladet das (neu) entstandene Objectfile. Sobald das Programm von 1536 aufwärts geladen ist, kann man es durch Eingabe von „GR.24:X=USR(1536)“ aus dem BASIC heraus zum Laufen bringen. Falls der Bildschirm sich mit lauter Zufalls-Quatsch füllt, macht Euch keine Sorgen; das heißt nur, es funktioniert. Um das Programm zu stoppen drückt Ihr – Na was wohl? Ihr habt doch wohl kapiert, was läuft, oder? Richtig! – eine der drei Konsoltasten: START, SELECT oder OPTION.

QZ 10	D1M HEX$(16) CV 20	LINE=10000: TRAF' 100:J=0:START=1536 VA 30	READ HEX$,CHKSUM:SUM=0 AA 40	FOR 1=1 TO 15 STEP 2 ZG 50	D1=ASC(HEX$(1,1))-48:D2=ASC(HEX$(1+1,1+1))-48 KT 60	NUM=((D1-7*(D1>16))*16+(D2-7*(D2>16))) LW 70	SUM=SUM+NUM:POKE START+J,NUM:J=J+1: NEXT 1 LY 80	IF SUM=CHKSUM THEN LINE=LINE+10:GOTO 30 IN 90	? "Checksum error an this line:" VO 95	LIST LINE:END YS 100	PRINT "Data in memory." TB 10000 DATA 68A55885CBA55985,1080 KF  10010 DATA CCADOAD2C9COBOF9,1415 LK  10020 DATA 85CDA90085CEA203,1011 XV  10030 DATA 06CD26CECADOF9A5,1279 WF  10040 DATA CB1865CD85CBA5CC,1238 TG  10050 DATA 65CE85CCO6CD26CE,1099 RB  10060 DATA 06CD26CEA5CB1865,948 MN  10070 DATA CD85CBA5CC65CE85,1350 PO  10080 DATA CCADOAD2293FC928,942 DI  10090 DATA BOF7A8ADOAD291CB,1332 JG  10100 DATAAD1FDOC907FOAA60,1126

Listing 2.

BASIC-Loaders / BASIC-Ladeprogramme

Zum Abschluß haben wir diesmal fünf BASIC-Programme. Das letzte liest ein Binärfile von Disk oder Cassette ein. Diese fünf sind kurze Utilities, mit denen man DATA erzeugen kann und DATA einlesen kann, um sie in einem BASIC-Programm zu nutzen.

Listing 3 fragt, wohin es das File schreiben soll. Cassettenbenutzer geben also wieder C: ein, Diskettenbenutzer D: gefolgt vom Filenamen. Anschließend fragt es nach vier Dezimalzahlen. Angenommen wir haben assemblierten Code im Speicher, dann wird das Programm ein File erzeugen, das Zeilennummern und Statements enthält. Die DA-TA, die durch Start- und Endadresse definiert sind, werden anschließend in die DATA-Statements eingeordnet, und die Zeilennummern starten mit der eingegebenen Zahl und erhöhen sich um die eingegebene Größe (z.B. Zehnerschritte). Das Programm wird dann mitteilen, wieviele Bytes aus dem Speicher ausgelesen wurden. Das so neu entstandene File kann dann per ENTER-Befehl zu jedem BASIC- Programm dazugeladen werden, das dann wiederum diese DATA einlesen kann, wie das in Listing 4 geschieht. Achtung: Wenn man weiß, wieviel Bytes gelesen werden müssen, ist es einfacher eine FOR/NEXT-Schleife zu benutzen.

Die Listings 5 und 6 sind ähnlich wie 3 und 4. Listing 5 erstellt ein File von DATA-Statements, listet aber die DATA in Strings von Hex-Zeichen, die dann von einem Programm gelesen werden können, wie z.B. von Listing 6. Falls Ihr keinen Assembler habt, dann ist Listing 6 besonders nützlich, da man dann Hex-Zeichen wie folgt in die DATA-Zeilen schreiben kann:

10000 DATA A46OFF458296D51ABC579830.

Die 24 Zeichen stellen die 12 Hex-Zahlen dar, die in aufeinanderfolgende Speicherstellen plaziert werden sollen. Ihr könnt mehr oder weniger Zeichen pro Zeile schreiben; dies ist eben die Anzahl der Daten, die Listing 5 erstellt. Und zum Schluß noch Listing 7: Es erzeugt ein File, das eine String-Dimensionierung enthält und einige String-Zuordnungen. Werden Anführungs- oder RETURN-Zeichen gefunden, dann werden sie per CHR$-Funktion anders zugeordnet. Wenn Ihr mit dieser Methode arbeitet, müßt Ihr sicherstellen, daß das Programm, das in String MC$ startet, relozierbar ist (verschiebbar); es dürfen hier also keine Jump-bzw. Jump-to- Subroutine-Anweisungen enthalten sein, da das Programm sonst abstürzt. Um den Code in einem St-ring aufzurufen, benutzt Ihr die String-Adressier-Funktion:

X=USR(ADR(MC$))<
/pre> 

Ich hoffe, ich habe Euch genug kleine BASIC-Utilities geboten, und es sollte nicht zu schwierig sein, diese Routinen zu modifizieren, so daß sie an Eure Bedürfnisse angepaßt werden können. Beim nächsten Mal werden wir uns detailliert mit den Möglichkeiten der Hardware und des OS auseinandersetzen.

XQ 10 DIM FILE$(14) FW 20 ? "Please enter device/file name" CH 30 ? "for output..." AR 40 INPUT FILE$ LY 50 OPEN #1,8,0,F1LE$ GK 60 ? "Please enter start address..." ZM 70 INPUT ST YS 80 ? "Please enter end address..." RQ 90 INPUT EN GB 100 ? "Please enter starting line..." IC 110 INPUT LIN WM 120 ? "Please enter line increment..." DU. 130 INPUT INC ZB 140 CH=0 MH 150 FOR 1=ST TO EN DV 160 IF CH=0 THEN PRINT #1;LIN;" DATA" ; DP 170 IF CH=7 OR I=EN THEN PRINT #1;PEEK (I): GOTO 190 RJ 180 PRINT #1;PEEK(I);","; VC 190 CH=CH+1:IF CH=8 THEN CH=0:L1N=LIN+INC FS 200 NEXT I LA 210 CLOSE #1 GF 220 ? "Number of data = ";EN-ST+1 Listing 3.</pre> </div> <div align="left"> 
OU ID TRAP 40:LOC 1536 QH 20 READ NUM:POKE LOC,NUM DF 30 LOC=L0C+1:GOTO 20 YS 40 END Listing 4.

NZ 10 DIM F1LE$(14),HEX$(24),CONV$(16)  HL 20 CONV$="0123456789ABCDEF"  FX 30 ? "Please enter device/file name"  C1 40 ? "for output..." AS 50 INPUT FILE$ LZ 60 OPEN #1,8,0,FILE$ GL 70 ? "Please enter start address..." ZN 80 INPUT ST YT 90 ? "Please enter end address..." UJ 100 INPUT EN GD 110 ? "Please enter starting line..." IE 120 INPUT LIN WO 130 ? "Please enter line increment..." DW 140 INPUT INC JI 150 LN=EN-ST+1:LOC=ST GO 160 NUM=12:HEX$="" GE 170 IF NUM>LN THEN NUM=LN MA 180 FOR 1=1 TO 2*NUM STEP 2 IM 190 X=PEEK(LOC) YY 200 D1=INT(X/16):D2=X-D1*1 6 PH 210 HEX$(1,1)=CONV$(D1+1,D1+1): HEX$(1+1,1+1)=CONV$(D2+1,D2+1) HH 220 LOC=L0C+1 FY 230 NEXT! WP 240 PRINT #1;LIN;" DATA ";HEX$  RC 250 LIN=LIN+INC:LN=LN-12  MG 260 IF LOC<=EN THEN 160 GP 270 ? "Number of data = ";EN-ST+1  LO 280 CLOSE #1 Listing 5</pre> </div> <div align="left"> 
QK 10 DIM HEX$(24) DE 20 TRAP 100:LOC=1536 BS 30 READ HEX$ VK 40 FOR 1=1 TO LEN(HEX$) STEP 2 ZG 50 D1=ASC(HEX$(1,1))-48: D2=ASC(HEX$(1+1,1+1))-48 KT 60 NUM=((D1-7"(D1>16))16+(D2-7*(D2>16)))  VO 70 POKE LOC,NUM:LOC=LOC+1 IW 80 NEXT I SI  90 GOTO 30 NQ  100 END Listing 6

JK 10 DIM FILE$(14),CRS(50),QTS(50) FW 20 ? "Please enter device/file name" CH 30 ? "or output..." AR 40 INPUT FILE$ LY 50 OPEN #1,8,0,FILE$ GK 60 ? "Please enter start address..." ZM 70 INPUT ST YS 80 ? "Please enter end address..." RQ 90 INPUT EN GB 100 ? "Please enter starting line..." IC 110 INPUT LIN WM 120 ? "Please enter line increment..." DU 130 INPUT INC SS 140 LN=EN-ST+1 JH 150 PRINT #1;LIN;" DIM MC$(";LN;")" WR 160 PSS=1:PSE=50:FIN=0 LV 170 CR=0:QT=0:LIN=LIN+INC FJ 180 IF PSE>LN THEN PSE=LN:FIN=1 GZ 190 PRINT #1;LIN;" MC$(";PSS;",";PSE;")=";:PUT #1,34 AL 200 FOR I=PSS TO PSE DH 210 X=PEEK(ST+I-1) UN 220 IF X=34 THEN QT=QT+1:QTS(QT)=I:X=32  CK 230 IF X=155 THEN CR=CR+1:CRS(CR)=I:X=32  SB 240 PUT #1,X GC 250 NEXT 1 BZ 260 PUT #1,34:PUT #1,155 GS 270 IF QT THEN GOSUB 320 GF 280 IF CR THEN GOSUB 370 VU 290 IF NOT FIN THEN PSS=PSS+50: PSE=PSE+50:GOTO 170 KZ 300 CLOSE #1  NU 310 END ZA 320 X=34 HZ 330 FOR 1=1 TO QT ZA 340 P=QTS(I):GOSUB 420 GD 350 NEXT 1  ZL 360 RETURN  RN 370 X=155 YL 380 FOR 1=1 TO CR VA 390 P=CRS(1):GOSUB 420 FU 400 NEXT I  ZC 410 RETURN ZY 420 LIN=LIN+INC FD 430 PRINT #1;L1N;" MC$(";P;",";P;")=CHR$(":X:")"  ZI 440 RETURN Listing 7

Der ATARI XL/XE IDE-Controller

Nachdem in der letzten Abbuc-Ausgabe 44 unter den Regionalgruppennews einige unklare Informationen zu dem Atari XL IDE-Controller preisgegeben wurden, möchte ich nun doch einmal eine korrektere und umfassendere Beschreibung zu dem Controller-Projekt abgeben.

Zuerst einmal ermöglicht der Controller den Anschlußvon modernen IDE und EIDE Festplatten an den XL. Die Festplatten werden in Parlitionen eingeteilt (Partitionen sind Teilbereiche der Festplatte) und erscheinen dem User dann als XL-Laufwerke D0 ... D9, Die einzelnen Partitionen können bis zu 16MB groß sein und können beliebig auf die einzelnen Laufwerke verteilt werden. Die Festplatte kann in max 140 Parti­tionen zerteilt werden, was einer max Festplattenkapazität von 140*16MB=2240MB entspricht (dies ist jedoch nur ein theoretischer Wert, die XL-Programme und Dateien sind so klein, daß es schon recht schwer wird eine 16MB-Partition zu füllen. 2,2GB sind viel zu groß für den kleinen XL). Es kann von jeder beliebigen Partition gebootet werden.

Der Controller arbeitet mit nahezu allen Dos-Versionen zusammen (genauergesagt mit allen, die mit Hilfe der Atari SIO-Routinen auf die Diskettenlaufwerke zugreifen. Leider tut dies das beliebte Bibo-Dos nicht. Sonst laufen aber wirklich fast alle bekannten Dos­Versionen, wie z.B. Sparta-Dos 3.x, Bewe-Dos 1.x, Atari Dos 2.x, My-Dos 4.x ... ). Es lassen sich aber auch viele Boot-Disketten auf Festplatten-Partitionen kopieren, aber auch diese müssen mit den SIO-Routinen arbeiten.

Benutzer von anderen Festplattencontrollern (BB, MIO, Supra) kennen die oben genannten Ausführungen gut, diese Controller arbeiten (vielleicht mit kleinen Unterschieden) nach dem selben Prinzip und mit denselben Einschränkungen.

Der Controller ist ein richtiges ParalleIbusgerät, d.h. er ist im normalen Betrieb nicht im Speicher sichtbar und blendet weder ROM noch RAM noch Steuerregister ein (dies wurde in dem Regionalgruppenbericht vollkommen falsch dargestellt). Nur bei einem Festplattenzugriff wird der Controller kurz sichtbar und wickelt die an ihn gestellten Aufgaben ab, um dann wieder vollkommen zu verschwinden. Kollisionen mit anderen Geräten können nur dann stattfinden, wenn diese das Parallelbusregister auf $JD1FF blockieren (dies sollte aber keine professionelle Hardware tun, da ja sowohl Atari als auch die einschlägige Fachliteratur den ganzen $D1XX-Bereich als belegt ausweist). Die so oft gerühmte ARGS-Hardware stellt leider solche Mechanismen nicht zur Verfügung, sondern blockiert für alle anderen Geräte ganze Speicherbereiche, zum Teil leider auch $D1XX. Solche Geräte lassen sich natürlich nicht zusammen mit dem Controller betreiben (sie laufen aber auch nicht mit den anderen ParalleIbusgeräten zusammen, wie z.B. dem Black­board).

In dem Regionalgruppenbericht wurde ebenfalls die nicht realisierte Bus-Pufferung erwähnt. Mal ganz davon abgesehen, daß kaum eine Hardwareerweiterung für den XL eine solche enthält (auch nicht die normale ARGS-Hardware), sie ist bei einem Parallelbusgerät auch gar nicht so sinnvoll. Betreibt man den Controller nämlich als einziges Gerät am XL, dann lohnt sich eine solche Pufferung nicht, da der Controller den XL-Bus fast gar nicht belastet (der Controller arbeitet sogar mit den signalschwachen Mexico­CPUs zusammen). Wird der Controller jedoch zusammen mit anderen ParalleIbuserweiterungen betrieben, dann benötigt man sowieso noch eine Busplatine, auf der eine großzügige Pufferschaltung dann viel sinnvoller untergebracht ist.

Die gesamte Schaltung ist auf einer nahezu Europa­kartengroßen Platine untergebracht, die von einer großen Firma hergestellt worden ist. Die Platine wird über ein kleines Flachbandkabel an den Parallelbus des Atari XL angeschlossen. Diese Lösung haben wir aus zwei Gründen gewählt:

Einmal sollte die Platine einer Slotkarte (wie eine PC­Steckkarte) möglichst ähnlich sehen, damit man sie auch problemlos in eine Busplatine oder ähnliches stecken kann. Auf der anderen Seite sollte sie aber auch ohne eine solche Busplatine betrieben werden können, damit dem Otto-Normaluser nicht noch weitere Kosten entstehen. Um eine Flachbandkabelverbindung realisieren zu können, war es jedoch nötig, den XL-Bus auf der Platine einmal zu spiegeln.

Noch ein paar abschließende Worte zur Kompatibilität. Wir haben den Controller zusammen mit fast allen Typen von XL und XE Computern betrieben und es gab bei uns keinerlei Probleme. Die Testgeräte.

Atari 800XL und 600XL (einmal mit 1064 und einmal intern erweitert). Ein Atari 800XL mit Peters Ramdisk. Atari 800XE und 130XE (angeschlossen Über einen XE-Paralielbusadapter). Ein weiterer 130XE ebenfalls mit Peters Ramdisk. Alle XE-Geräte haben eine Mexico-CPU.

Weiterhin haben wir sehr viele Festplatten an dem Controller getestet, und es gab nur mit einem einzigen (und zudem uralten) Gerät Probleme. Da PC­Festplatten jedoch generell etwas problematisch sind (nicht jede IDE-Festplatte läuft an jedem PC-IDE-Controller) können wir hierzu nicht sehr viel sagen. Sollte also doch einmal eine Festplatte wider Erwarten nicht an dem Controller laufen, dann wäre es schön, wenn man uns benachrichtigen könnte. Die Testfestplatten:

Seagate 157A, Seagate 3144, WD 44MB, Conner CP300OA, Conner CP35lA, Conner CP330OA, Quan­tum Maverick 540AT, WD Caviar 2200.

Nach so vielen 'Fakten stellt sich jetzt vielleicht die Frage wann und wo man den Controller erwerben kann. Die Antwort auf diese Frage fällt mir zur Zeit nicht so leicht, da auf der einen Seite die Hardwareentwicklung längst beendet ist und auch die Controllerplatinen schon gefertigt sind. Auf der anderen Seite feilen wir jedoch noch an der Software zu dem Controller, die (leider) recht umfangreich ist. Da die Software jedoch schon ein fortgeschrittenes Beta-Stadium erreicht hat, hoffen wir spätestens im Frühsommer den Controiler ausliefern zu können. Bei allen, die schon länger mit uns in Kontakt stehen, und sich über die nun schon längere Wartezeit ärgern, möchten wir uns hiermit entschuldigen. Der Atari XL ist nur unser Hobby und nicht unser Beruf, Aus diesem Grund können wir auch nur einen beschränkten Teil unserer Zeit dem XL widmen.

Der Controller wird 120,-DM kosten und kann auch schon bestellt werden (dies ist vielleicht auch ganz sinnvoll, da schon ein beträchtlicher Teil der Auflage der Platinen vorbestellt ist).

Kontaktadresse:
Stefan Birmanns
Kollwitzstr.17
52134 Herzogenrath
Email: stefan-birmanns@ac.cybercity.de

XEP80 die Zweite

Das XE-Design ist wohl das Unwichtigste bei diesem Gerät, während man denAbmessungen doch mehr Gewicht schenken wird, Wohin damit? Die Maße entsprechen keinem mir bekannten ATARI-Gerät, so daß 'Türmchen bauen schon mal wegfällt; zumindest wenn man wie ich auf den beiden 1050ern auch noch den 1010-Recorder haben will. Naja, ein Platz wird sich schon finden, ich kann ja dafür das 1010-Netzteil mit verwenden, das die gleichen techn. Daten aufweist wie das der XEP. Das heißt, ich könnte, wenn der Stecker passen würde! Die Sicht auf die Gehäusefront brauche ich bei der Aufstellung nicht zu berücksichtigen, da die hier angebrachte grüne 'Power-LED' ihrem Namen nicht gerecht wird (bei Tageslicht kaum zu erkennen). DieAnschlüsse befinden sich alle an der Gehäuserückseite und machen einen guten, soliden Eindruck. Wenn hier auch noch das Verbindungskabel zum Joyport steckbar wäre, würde ich 'vorbildlich' sagen. Daß das mitgelieferte Videokabel nicht ohne Adapter zu benutzen ist, ist verzeihlich, daß aber der Ein/Aus-Schalter an die Rückseite des Gerätes verbannt wurde, gibt der XEP80 in puncto Bedienerfreundlichkeit eine glatte Sechs.

All das mag sich furchtbar negativ anhören, fällt aber, wenn erst ein Platz gefunden ist und die Anschlüsse hergestellt sind, kaum mehr ins Gewicht. Auch kann man mit ein wenig Bastelgeschick vieles an die eigenen Bedürfnisse anpassen.

"Wirklich nervend ist die Neueinstellung von Bildhöhe, horizontaler Bildlage und Helligkeit.», schreibt Erhard Pütz in Magazin 38 über seine Arbeit mit der XEP80. Auch das "...dauernde Umstöpsein des Videosteckers... " ist ihm unangenehm.

Diese Nachteile sollte mein Commodore 1802 Monitor ausgleichen. Der 1802 hat 3 getrennte Videoeingänge: Composite (FBAS) - Separate (Chrorna?Luma) - Monochrom (grün).

Das Umschalten erfolgt bequem mittels eines Schiebeschalters an der Frontseite. Weiterhin können Lautstärke, Farbe, Helligkeit und, was für die Arbeit mit der XEP80 wichtig ist, Vertikalfrequenz, Horizontalposition und Bildhöhe über Potis von vorne ohne Verrenkungen eingestellt werden.

Doch gerade der ansonsten sehr gute Monitor machte mir große Probleme. Es gelang mir einfach nicht, lesbaren Text darzustellen. Zeichen stellten sich am Bildschirm als verwaschene, grüne, von links unten nach rechts oben verlaufende Flecken dar. Bis ich dann aus Versehen einmal den Monitor aus und gleich darauf wieder einschaltete.

Plötzlich konnte ich links oben ein Y erkennen, welches das einzig Sichtbare des Basic-Prompts "READY" war. Also Bildschirm eingestellt und die Beispielprogramme ausprobiert. Das wirklich sehr gute Bild hat mich auf der Stelle alle Mißlichkeiten vergessen lassen und mir neuen Ansporn gegeben. Besonders die inverse Darstellung läßt einen die rein softwaremäßige 80 Zeichen-Darstellung wie z.B. von S.A.M. nur noch müde belächeln. Doch die Euphorie war nur von kurzer Dauer. Mein Monitor fiel immer wieder in die alte Darstellungsweise zurück und zwar sobald ein Kanal auf den Bildschirm geöffnet wurde (z.B. auch beim Sprung vom Basic ins DOS und umgekehrt). Hier half nur Monitor aus- und wieder einschalten. Mir war schnell klar, daß das mit der Umstellung von NTSC auf PAL zusammenhängen müsse, aber was ich konkret dagegen tun könne, konnten mir auch drei befragte'Fachleute' (Radio- u. TV Technikermeister!!!) nicht verraten. Alles was ich herausbrachte war, daß "...der Monitor die Zeile u
mschmeißt ................... und daß "uns die technische Ausrüstung fehlt ...... 'Computerfachleute' leugneten gar die Existenz von Computern mit weniger als 2MB Speicherkapazität, Soviel zum Fachhandel; ich bedaure nur die PC'Ier, die bei solchen Leuten ihre Ware kaufen müssen.

Da ich auch beim tragbaren TV meines Sohnes (über SCART) kein Bild bekam und ich fürchtete, mit ewigen Aus- und Ein-schalten meinen ansonsten hervorragenden Monitor zu ruinieren, entschloß ich mich, mir einen anderen Monitor (zu Testzwecken) zuzulegen. Fündig wurde ich im CF, wo mir ein sehr netter Commodore User seinen alten Monochrommonitor gegen Portoübernahme überließ. An dieser Stelle nochmals herzlichen Dank!

Der zugesandte Highscreen Grünmonitor mit 12 Zoll BS-Diagonale übertraf alle meine Erwartungen. Hier zeigt die XEP80 erst, wozu sie fähig ist. Das gestochen scharfe Schriftbild habe ich noch nirgends besser gesehen. Es braucht sich vor keinem PC zu verstecken. Ein Blick auf die vielen Einstellregler des Highscreen brachte mir endlich auch den so lange vermißten Geistesblitz: das Wort der Stunde war 'Horizontalfrequenz'. Diese ist bei meinem Commodore nicht von außen einstellbar, aber es müßte doch innen.... gedacht - geschraubt - geschaut - da ist es: ein Trimmpoti, neben dem 'H. HOLD' steht. Nach einigem Tüfteln war es so eingestellt, daß sowohl die 80 Zeichen der XEP als auch die normalen 40 Zeichen einwandfrei dargestellt werden. (VORSICHT!! Bei solchen Arbeiten besteht LEBENSGEFAHR, also unbedingt Trenntrafo verwenden oder besser noch zum Fachmann damit). (Wenn Ihr nur solche 'Fachleute' habt, wie ich sie getroffen habe, könnt ihr ihnen ja das 'Spezialwerkzeug' in Form eines Kreuzschraubendrehers mitbringen!)

Nun war ich also endlich soweit, daß ich die 80 Zeichenkarte mit meinem alten Monitor benutzen konnte, nur jetzt wollte ich nicht mehr. Wer gibt sich schon mit einem guten bis sehr guten Bild zufrieden (das man erst einstellen muß), wenn er daneben ein hervorragendes (auf Knopfdruck) haben kann. Nun zieren also zwei Monitore meinen überlasteten Computertisch. Doch nicht nur der Monitor bereitete mir hardwaretechnische Schwierigkeiten. Mein (nach ABBUC/Lojek) um 192 k aufgerüsteter 800XL nahm zwar jedesmal brav die Zusammenarbeit mit der XEP80 auf, verweigerte aber immer wieder nach etwa drei Minuten Arbeitspause (keine Taste gedrückt) die Weiterarbeit im 80-Zeichen-Modus. Meine Vermutung, dies liege an der Speichererweiterung, hat sich so nicht bestätigt: es liegt an den 41256er RAMs. Will heißen, sobald sich 4164 (original 64k) ,Bausteine im Rechner befinden, gibt es keine Probleme (unabhängig davon ob die Ansteuerungslogik angeschlossen ist oder nicht), erst wenn er mit 41256ern bestückt wird treten die Probleme auf.

Woran es liegt, daß der Rechner sonst klaglos seinen Dienst versieht, nur nicht in Verbindung mit der 80 Zeichenkarte ist mir bislang ein Rätsel geblieben. Vielleicht kann mich ja jemand aufklären?!

Die Erweiterung tut nun anstandslos Dienst in meinem älteren XL. Der Umbau (nichts gesockelt) hat zwar Zeit gekostet, mir allerdings auch die Wartezeit auf den Monitor verkürzt. So habe ich über den Umweg XEP auch noch einiges über Monitore gelernt und auch das Löten geht mir wieder besser von der Hand.

So richtig mit der XEP80 beschäftigen konnte ich mich natürlich erst jetzt, wo die rein hardwaremäßigen Probleme beseitigt waren. Hier erlitt ich die bisher größte Enttäuschung: die Bildschirmausgabe funktioniert nicht unter TURBO-DOS. DOS 2.5 und My-DOS (der RAM­Disk wegen) funktionieren, mit anderen habe ich mich noch nicht befaßt. Wolfgang Burger hat mir auf meine Anfrage eine Disk geschickt, auf der ein von Michael Pascher modifiziertes Treiberprogramm enthalten ist. Hierin ist ein Fehler im Originalprogramm behoben. Ich habe ziemlich lange gebraucht, um den Fehler zu finden, weil ich mich anfangs nicht mit der Nutzung der XEP als Druckerinterface befaßt habe, glaube aber ihn gefunden zu haben. So kann beim Originalfile nach einem <SHIFT RESET>, das ja einen Wechsel vom 80 zum 40 Zeichen-Modus bewirkt), der Drucker' nicht mehr angesprochen werden, was beim modifizierten Treiber sehr wohl möglich ist. Abhilfe schafft hier das softe' Umschalten z.B. von BASIC aus mit XIO 25,#1,12101"E:" (80 nach 40) und XIO 24,#1,12,0,"E:" (40 nach 80). Hier glaube ich allerdings auch einen klei­nen Bug im 'neuen'Treiber entdeckt zu haben. So kann man im Original (und lt. Anleitung) beim Umschalten von 40 nach 80 Zeichendarstellung durch Ändern von AUX1 von 12 in 44 (XIO 24,#1,44,0,"E:") das Löschen des 80 Zeichen-Screens verhindern. Dies funktioniert mit dem modifizierten Programm nicht.

Dafür ist die Diskette als Boot-Disk ausgelegt, d.h. es befindet sich ein Menü in den ersten Sektoren, das es erlaubt, zuerst den XEP80-Treiber und danach beliebige Bootdisketten ohne DOS zu laden. So kann man z.B. das Druckerinterface der XEP für SCREEN DUMP gebrauchen. Für DOS-Programme empfiehlt sich die Verwendung des Treiberprogramms als 'AUTORUN.SYS'. Wem dieses Geschreibsel vielleicht wirr und ungeordnet vorkommt, dem kann ich nur sagen, es ist ein genaues Abbild dessen, wie es momentan in meinem Kopf aussieht. Es war einfach ein bißchen viel, was da im Gefolge dieses kleinen grauen Kästchens auf mich eingestürmt ist und ein Ende ist (Gott sei Dank) nicht in Sicht. Gestern ist der MAC65 eingetroffen und auch das Modem für BOBTERM wird wohl nicht mehr lange auf sich warten lassen. Obwohl schon das Arbeiten im Basic-Editor mit der XEP80 ein Vergnügen ist, freue ich mich doch auch auf die Nutzung in 'richtigen' Programmen.

Für Interessierte: Lest doch mal die interessanten Beiträge von Erhard Pütz in #38 und #39 und den Testbericht von Wolfgang Burger in #16 nach! Und zum Schluß: ich bin an allen Infos, Programmen (selbstgeschrieben oder kommerziell), Erfahrungsaustausch zur XEP80 interessiert. Ich freue mich über jede Zuschrift!

MeineAdresse:
Günther Bartl
Furmannstr. 19
94315 Straubing

P.S.: Dies ist mein erstes aktives Wirken im ABBUC. Bisher war ich reiner Nutznießer. Deshalb möchte ich nicht versäumen, an dieser Stelle allen 'Aktiven' zu danken, die durch ihre Arbeit den ABBUC und damit den 8bit Atari unterstützen.

Ciao, Günther

Floppy 2000
Eine Nachbetrachtung

(von A. Magenheimer)

Wer, wie ich und Sascha Röber, eine Floppy 2000 ("FLOP 2000"!!!) sein Eigen nennt, der wird über kurz oder lang erkennen müssen, daß diese leider nicht das NONPLUSULTRA - Gerät für den Atari - User darstellt.

Das fängt zum einen damit an, daß diese Floppies von Klaus Peters "gebaut" wurden, dieser aber inzwischen mit A
tari so gut wie nix mehr am Hut hat - und auch von den ATARI-FREAX eigentlich nichts mehr wissen will. Mit Bauplänen wird es denn wohl auch in Zukunft für diese Floppies nichts werden, zwar versucht der ABBUC, diese irgendwie an Land zu ziehen, jedoch ist Herr Peters bisher zu einer herausgabe nicht bereit. Könnte ja sein, daß man urplötzlich beim ABBUC die Reparaturen für dieses Laufwerk übernimmt, und er selbst dann auf seinen Ersatzteilen sitzen bleibt.

Dabei muß sich Herr Peters doch eigentlich nicht wundern, wenn sich die User nach einer neuen und vor allem zuverlässigen Quelle umsehen, zumal er sich selbst ja überhaupt nicht rührt, und die Atari-User (auch mich!) meistens erstmals sechs Monate (!!!) auf Bestellungen oder Reparaturen warten läßt (wo bleiben denn mein 65XE und meine XF551, die ich Ihnen im Nov.95' zugeschickt habe??).

Nun ja, aber es läßt sich ja auch so ganz gut leben, schließlich gibt es noch andere ATARI-Händler und Clubs, auf die man sich im Gegensatz zu K.P. verlassen kann und denen man auch mit gutem Gewissen vertrauen kann.

Das Problem aber - Floppy 2000 -, bleibt bestehen, es sei denn, man macht es Wie ich, und tauscht diese Floppy gegen eine andere ATARI-Floppy und ein wenig Software ein. Nur muß man dazu erst einmal jemand finden, der blöd genug ist, sich darauf einzulassen.

Tatsache ist, mit der Floppy 2000 hat man eine 360KB, DS/DD-Floppy, die rein theoretisch über die Formate

a) Single (90kb),

b) Medium (1128k15),

c) Double (180kb) und

d) "Quad" (Double-Sided, Double-Density, 36Okb), verfügt.

Zusätzlich ist in diesem Laufwerk noch eine Speedy integriert. Hört sich ja alles geradezu grandios an, ist es aber leider nicht. Will man nämlich mehr als nur das übliche Single und Medium - Format verwenden, führt dies zu diversen Problemen.

Beim Versuch "Quad"-Density auszunutzen, wird man sehr schnell feststellen, daß die meisten Utilities hierzu für die XF551, der bis dato einzigen 360k-Floppy, geschrieben worden sind. Das die Floppy 2000 glücklicherweise nicht all die vielen Fehler von der XF551 (Formaterkennung, lndexlochabfrage, etc.), besitzt, mag einem ja noch freuen, denn man muß sich nicht einige Hardwarezusätze kaufen, um diese Fehler zu beseitigen.

Da in der Floppy 2000 aber nicht der gleiche Floppyspeeder, wie in der XF551, genutzt wird, läuft fast kein einziges 360k-Utility auf der F2000.

Die diversen, im PD-Bereich erhältlichen, "XF-UTILITIES", die einem die Quad/360k Ausnutzung ermöglichen, sind für die Floppy 2000 wertlos, denn sie laufen hiermit alle nicht. Einzig und allein einige DOSse (BIBO,TURBO,etc.), lassen sich halbwegs fehlerfrei verwenden (nur sind diese natürlich meist nicht ganz kompatibel zum DOS 2.5 Standard). DerTraum endlich kei­ne Disks mehr wenden zu müssen und die 5,25" DD­DISKS mitvoller Kapazitätauslasten zu können, wirdso wohl auch weiterhin ein Traum bleiben, denn eine spezielle "FLOPPY 2000 UTILITY-DISK" gibt es bis heute leider nicht. (Es wurde lediglich die BIBO-DOS Master­disk mitgeliefert ... )

Naja, zum Glück gibt es ja noch die Möglichkeit DOUBLE DENSITY zu nutzen, sowie die eingebaute Speedy. Utilities und DOSse gibt es hier tonnenweise. Die meisten davon verhalten sich auch DOS 2.5 kompatibel (3-stellige Sektorenanzeige, AUTORUN.SYS, 720s/707s free vor/nach dem formatieren, manche mit/ manche ohne RAMDISK.COM oder Ramdiskmöglichkeit, etc.).

Nach kürzester Zeit hatte ich hier 20 verschieden DOS­Arten und Dutzende,von Utilities zusammen, die mehr oder minder gut mit Double-Density (18Okb) zusam­menarbeiten. DasProblemdieKapazitätvon 18Oksinn­voll auszunutzen liegt denn auch nicht so sehr an der Floppy 2000, als vielmehr an der heutigen Atari-Soft­ware. Etliche Programmierer haben es sich nämlich er­laubt, ihre Spiele, Demos oder Utilities auf BOOTDISKS zu pressen, die man sofern sie nicht bereits für das Double - Format geschrieben wurden, natürlich nicht von Single oder Medium, auf Double umkopieren kann. Zwar gibt es einige Archivier - Programme für unseren kleinen Atari, diese archivieren jedoch die jeweiligen Programme meist so, daß sie anschließend nicht mehr

direkt ladbar sind (sie müssen erst entpackt werden, was nur selten automatisch geschieht, fast immer muß man erst einen Entpacker laden ... ). Im Klartext heißt das, das Bootdisketten im Single oder Medium-Format nicht auf Double kopiert werden können, der Versuch sie zu archivieren ist nicht nur umständlich, sondern auch sehr zeitintensiv, denn man muß sich stets eines Entpackers bedienen...

Aber, es gibt ja zum Glück auch Filedisketten, Files lassen sich ja mit einem geeigneten DOS (rein theoretisch) von S/M in Double umkopieren. Das Problem, das hierbei häufig entsteht, ist jenes, daß die Files anschließend nicht mehr laufen, da der Programmiererso nett war, diese Files (Spiele, Demos oder Anwendungen), so zu programmieren, daß sie grundsätzlich nur 128 Bytes per Sektor akzeptieren, egal welches DOS man auch benutzt.

Bei manchen Files ist es sogar noch extremer, denn diese akzeptieren grundsätzlich nur das Original ATARI DOS 2.5. Wehe dem, der sich wagt, ein anderes DOS zu verwenden (z.B. BIBO-DOS,TURBO-DOS,MY­DOS,BW-DOS, SPARTA-DOS, SMART-DOS, DOS­XE, etc.), das jeweilige File wird dann nicht mehr laufen...

Manche Files (Demos!) benötigen zum Laden auch ein sog. Game-Dos, da sie Teile des DOS-Bereiches ein­fach mit verwenden. Nur, erst mal ein Game-Dos finden, daß unter Double auch läuft, ich kenne da selbst nurdas SPEED INIT das zwar Double akzeptiert, unter dem bei mir jedoch nur sehr wenige Files laufen (das kann am Double-Format, dem Game-Dos - das stets eine Speedy initialisiert und daher zusätzlichen Speicher benötigt -, oder sonst was liegen).

Mit den Game-DOSsen "N-DOS-CONVERTER", von S.BAUCKE (aus Happy Computer), und "MICRO-DOS II/D INITIALIZER", von Stefan Dorndorf laufen bei mir hingegen alle Game-Dos kompatiblen Files einwandfrei, zu dumm nur, daß eben gerade diese Game-DOS­se kein Double vertragen...

Im Großen und Ganzen habe ich über 100 Filedisketten auf ihre Double-Density Eignung hin überprüft, das Ergebnis war geradezu niederschmetternd: noch nicht einmal 1/3 aller Files lief später fehlerlos. Woran es auch immer gelegen haben mag (DOS, GAME-DOS, SPEEDY, etc.), irgendwie keimt in mir der Verdacht, daß Double-Density wohl für unseren Atari nicht das richtige ist, obwohl die meisten über die entsprechende Hardware verfügen (TURBO, HAPPY, SPEEDY, XF551, F2000, etc.), wird dieses Format weder genutzt, noch in irgendeiner Weise unterstützt.

Wer es nicht glaubt, der schaue mal eben in den ABBUC-PD-Katalog oder in den HAPS-PD-Katalog, hier befinden sich von 500 bzw. 1000 PD's noch nicht einmal 10% im Double-Format. Und auch alle mir bekannten Disk-Mags erscheinen meines Wissens nur im absolut popeligen und fehlerbehafteten Medium Format. Dabei wurden doch die ganzen Floppy-Erweiterungen nicht nur wegen ihrer enormen Geschwindigkeit entwickelt und gebaut...

Sei es drum, Double scheint ein totes Format zu sein, daß dann eben auch für die F2000 Besitzer nur sehr schwer genutzt werden kann und das obwohl es ja noch viele andere Double fähige Laufwerke gibt.

Nun denn, wo sind wir denn nun ???

Wir haben festgestellt, daß Quad/360k kaum nutzbar ist, auch Double/180k nicht gerade leicht zu nutzen ist (und auch leider heute noch nicht zum Standard gehört), so bleibt uns also noch das Single und das Medium-Format und die in der F2000 eingebaute Speedy. Beschäftigen wir uns zunächst mit letzterem und schon können wir der Floppy den nächsten (AUS-)Schlag ver­setzen. Es ist nämlich leider so, daß die in der F2000 eingebaute Speedy leider nicht 100% kompatibel zur Speedy 1050 ist. Soll heißen, Speedy-DOSse und Game-DOSse lassen sich noch verwenden, spezielle Speedy-Programme aber, wie z.B. MS-COPY, ULTRA­COPY, HSS-COPY, BACKUP-COPY, DISK-MASTER, TURBO-1050-EMULATOR, etc., laufen auf dieserFlop­py aber nicht.

Die eingebaute ROM-Software (von der eigentlich nur der Sektorkopierer und der Slow-Mode brauchbar sind), benötigen nämlich genau 256 Bytes zuviel an Ramspeicherplatz. Was sind schon ein paar Bytes? Viel, wenn sie, wie hier eine Inkompatibilität bewirken.

Wie hieß es noch damals in dem schönen Werbetext, `...in der Floppy 2000 ist bereits eine Speedy integriert, Floppy 2000 Besitzer brauchen also nicht extra eine Speedy bestellen. Ja, schön und gut, haben wir ja dann auch nicht gemacht - aber wir haben natürlich alle möglichen Speedy-Programme bestellt, die dann zu unserem Erstaunen, auf dieser Floppy nicht lauffähig waren...

Selbstverständlich weiß Herr Peters schon seit längerer Zeit von diesem Dilemma - aber für einen Geschäftsmann ist so etwas ja nicht von Interesse, denn das bringt kaum Geld ein, kostet aber sehr viel Geld, den Fehler" zu beheben (man müßte ja das komplette Floppy-Betriebssystem, etc., neu coden lassen).

Schade drum, denn irgendwie werde ich den Verdacht nicht los, es ging bei der Floppy 2000 nur darum, möglichst viel Geld zu machen, aber nicht dem User eine gute Floppy für das (relativ) viele Geld (immerhin 400DM!) zu geben.

Man hätte ja auch den in der XF551 so verspotteten "BILLIGSPEEDER" einbauen können, und wäre somit kompatibel zur XF551 (ohne deren Fehler!) gewesen -aber man wollte halt unbedingt eine Speedy haben, anstatt nun aber dafür Sorge zu tragen, daß diese voll und ganz kompatibel zur 1050 Speedy ist, hat man nun nur noch eine PSEUDO oder Beinahe - Speedy geschaffen ("verdammt nah dran..." - aber doch daneben !!!).

Bleibt also noch die Nutzung vom veralteten SINGLE und Medium - Format.

Aller Dinge sind nun mal drei, so auch hier:

1.) Quad/36Ok geht nicht, da die F2000 nicht kompatibel und nicht so fehlerhaft wie die XF551 ist (kein ) XF551-Speeder),

2.) Double/18Ok geht auch nicht bzw. kaum, da
a) die softwaremäßigen Vorraussetzungen fehlen (s.o.) und
b) die hardwaremäßigen Gegebenheiten (Speedy) nicht kompatibel zu bereits vorhandenen Standards sind.

3.) Single und Medium geht auch nur in eingeschränkter Weise... Denn, man muß
a) bei kopiergeschützter Software stets die Speedy abschalten, (nur ein kleiner Umstand - aber auch das zählt hier !!) und
b) was noch sehr viel schlimmer ist: die Floppy ist auch ohne Speedy viel zu schnell !!!

Wer, wie ich, sehr viele Originale besitzt (es soll ja auch ehrliche User geben), der besitzt auch diverse Disks mit Kopierschutz (es sei denn, man hat diesen entfernt ... ). Nun denn, bei ca. 3/4 aller kopiergeschützten Disks muß man die Speeder (TURBO/HAPPY/SPEE­DY, etc.) abschalten, dies kann auf Dauer ganz schön nerven.

Bei der F2000 benötigt man ja nun nicht mehr die SPEEDY-SYSTEMDISK; um die Floppy "slow" zu schalten, man bootet mit offenem Laufwerk, wählt Punkt 4 (Floppy=SLOW) und bootet dann die ge­wünschte Original-Disk. In einigen Fällen wird aber auch das nichts nützen, denn die Floppy ist ja keine 1050 mit 287,5-288 UPM, sondern eine Industriefloppy (Marke: Mitsubishi), die normalerweise mit 300 UPM dreht.

Somit war die F2000 in der 'URVERSION' nicht bootfähig am ATARI - das gab damals bei PPP tausende Reklamationen und Rücksendungen-, was bewirkte, das bei K.P., aufgrund hunderter Proteste (und nicht etwa freiwillig!), die Floppy 2000, dann auf 290 UPM ge­trimmt wurde.

Mit diesen 290 UPM ist die Floppy nun trotz abgeschalteter Speedy immer noch schneller, als eine normale 1050 (wie haben die das bei der XF551 bloß hingekriegt, daß diese mit 288 UPM lief?) und somit einfach zu schnell.

Im Klartext heißt das, daß einige Originale auch bei abgeschalteter Speedy nicht, auf der F2000 laufen. Von diesen paar Originalen (meine Liste enthält nur 5 Stück - aber ich besitze ja auch nicht alles was es gibt !), könnte man durchaus noch absehen, denn diese fallen kaum ins Gewicht.

Was aber sehr wohl ins Gewicht fällt, ist, daß sich die Floppy auch nicht mit einigen kopierschutzlosen Disks verträgt (PD,SW,FW, etc.). Dies liegt ganz einfach am verwendeten Format. Eine normale 1050 erzeugtja bekanntlich Single und Medium-Format, nicht nur, daß ich Medium wegen des häufigen Datenmülls hasse, nein, bei Medium gibt es mit der F2000 auch irgendwie Probleme. Eine Industriefloppy kann mit diesem Format nichts anfangen, die F2000 kann mit diesem Format nur bedingt etwas anfangen.

Die Sache ist nämlich die, beim Medium Format werden nicht einfach nur 26 Sektoren pro Track geschrieben, auch die Geschwindigkeit ist eine andere. Und genau hier liegt auch wieder der Haken, bei allen möglichen Formaten läuft eine Atari-Floppy mit 288 UPM, eine F2000 mit 290 UPM. Noch ungenauerwird es beim Medium - Format, denn hier beträgt die von ATARI festgelegte Rate 270 UPM, bei der Floppy 2000 hingegen sehr viel mehr (die genaue Umdrehungszahl konnte ich leider nicht messen, da alle mir bekannten Drehzahltests nur mit Single liefen).

Eine F2000 ist nämlich niemals nicht in der Lage 270 UPM auch nur annähernd zu erreichen. Was ihr bei 288 UPM schon gewisse
(Ungenauigkeits-)Probleme bereitet, sieht bei 270 UPM (die bei Medium nun mal verwendet werden, um dieses scheußliche Format zu erzeugen, zu lesen und zu schreiben) noch sehr viel schlechter aus, die Floppy produziert haufenweise Datenmüll, was nicht nur allein auf das Medium-Format sondern eben auch auf die F2000 und ihre zu hohe Umdrehungszahl zurückzuführen ist.

Haufenweise Datenmüll, das heißt, daß die Floppy zunächst noch einwandfrei mit Medium läuft, solche Disks auch formatiert und beschreibt. Nur, will man sich' die Disks später mit einem Sektorkopierer vervielfältigen (weil man z.B. Herausgeber des PD-MAG oderdes TOP-MAG ist, oder weil man einfach nur ein paar Kopien anfertigen möchte ...), so erhält man häufig (nicht immer - aber oft!) sog. BAD SECTORS beim einlesen der Disk - und das obwohl diese keinen Kopierschutz enthält!!

Dies ist dann sozusagen typisch für das Medium-Format, denn ich habe solche Bad Sector Probleme bei Single oder Double noch nie gehabt (es sei denn, die Disks waren defekt).

Ein anderes, häufig bei Medium auftretendes Problem, besteht darin, daß die VTOC nicht richtig gelesen oder geschrieben wird. Das Medium-Format besitzt nämlich für die Sektoren, ab Sektor 721 bis Sektor 1010, eine zweite VTOC (Sektorbelegungstabelle). Diese befindet sich im Sektor 1024. Da nun aber Sektor 1011 bis 1040 vom DOS 2.5 aus nicht zugänglich sind, erhält man dazwischen einige Leersektoren. Das schadet eigentlich nichtweiter, fällt aber meist dann ins Gewicht, wenn auf der Disk nur 800-900 Sektoren belegt sind.

Man hat dann nämlich eine Menge Leersektoren, die bei etlichen (Speedy-Sektor-) Kopierprogrammen nicht geschrieben werden, das hat zur Folge, daß das Ko­pierprogramm vom letzten Datensektor zum VTOC­Sektor 1024 springt. Nur meist springt zwar das Pro­gramm, nicht aber der Schreib- und Lesekopf der Flop­py einwandfrei und mit voller highspeed über diverse Sektoren. Gerade hier kommt es dann auch zu Fehlern, denn eine zerstörte, nicht oder falsch geschriebene 2.VTOC hat meist Datenmüll zur Folge.

Die Sektoren 721-1010 können nicht mehr oder nur schwer gelesen werden oder aber Versuche, die Disk später weiter zu beschreiben, führt zu Datensalat, da nicht mehr klar ist, welche Sektoren nun genau belegt sind und welche nicht, Alles in allem ein typisches Speeder Problem, denn eine normale 1050 schreibt die 2.VTOC fast immer fehlerfrei und springt auch problemlos über einige Leersektoren, da die Daten stets direkt auf der Diskette und nicht erst im Trackbuffer abgelegt werden...

Man sollte, wenn möglich, also das Medium-Format meiden und speziell bei Highspeed-Laufwerken darauf achten, daß die VTOC richtig belegt und geschrieben wurde, ansonsten muß man sich später nicht wundern, wenn die Disk viel Müll enthält!!

Kurzum,vielleicht hatte ich ja eine besonders schlechte F2000 erhalten, dennoch bin ich der Meinung, eine derartige Floppy herzustellen, kostet sehr viel Zeit und auch sehr viel Geld plus Nerven...

Dem User aber

1) für viel Geld,

2) ein halbfertiges Produkt anzudrehen,

3) innerhalb kürzester Zeit alle weiteren (auch dringend notwendigen) Updates einzustellen und schließlich

4) alle Reparaturleistungen ewig in die Länge zu ziehen (bis zu 6 Monate) und auf Dauer wohl (so darf zu Recht vermutet werden) ganz einzustellen und

5) trotzdem keinerlei Pläne zum "DO-IT-YOURSELF" Reparaturshop (ABBUC) zur Verfügung zu stellen, dies ist schon eine bodenlose Frechheit und Unverschämtheit, die zum Himmel stinkt!!!!!

Sollte dennoch jemand Interesse an dieser Floppy haben, so kann ich ihm freudestrahlend mitteilen, die Herstellung und der Vertrieb wurden inzwischen eingestellt. Übrigens wer ähnlich gute Erfahrungen mit einem der Herren "P" gemacht hat, egal in weicher Weise, der kann mir ja schreiben.

Vielleicht können wir ja dann auch gemeinsa im ABBUC eine Interessengemein schaft für geschädigte (nicht im Hirn - im Geldbeutel !!), Atari User gründen. ATARI-USER wehrt euch, wenn ihr gelinkt werdet

So, mehr habe ich hierzu nicht zu mehr zu sagen

Andreas Magenheimer
Diehlgartenstr. 12
6759 Wachenheim/Zellertal

Dietmar's Spielecke

Hallo Leute , heute folgt der sechste teil meiner Spielecke. Ich wün­sche euch viel Spaß mit meinen Tips. Also los geht es:

DRAG von KE-SOFT

hier sind die letzten Codezahlen
00000, 47938, 94183, 52396,
26564, 71427, 65651, 38819,
83275,

BOMBER JACK von KE-SOFT

hier sind die ersten Codeworte

DISKSEITE: A
01.ANANNA
02.BIGIGI
03.CKANPA
04.DGAMAG
05.ESCHIN
06.FISCHT
07.GZAMMA
08.HLIBAT
09.ITHOTH
10.JTARRA
11.KGANNA
12.LNINIB
13.MZELIG
14.NBATTU
15.OGIRRA
die nächsten Codeworte gibt es in der kommenden Ausgabe.

THE FINAL FIGHT von: T Wittmeiyer

EDITOR
Sektor 39 Byte 61 von 03 IN 1A=26 Leben
Sektor 39 Byte 76 von 03 IN 1A=26 Leben
oder
Sektor 39 Byte 61 von 03 IN 63=99 Leben
Sektor 39 Byte 76 von 03 IN 63=99 Leben
oder
Sektor 39 Byte 61 von 03 IN FF=255Leben
Sektor 39 Byte 76 von 03 IN FF=255Leben

THE AARDWARK von: CHRIS OBERTH

EDITOR
Sektor 4 Byte 73 von 10 IN 35=35 Leben oder
Sektor 4 Byte 73 von 10 IN 99=99 Leben oder
Sektor 4 Byte 73 von 10 IN FF=255Leben

BCS Q UERST FOR TIERES von: CHUCK BENTON

EDITOR
Sektor 75 Byte 62 von 05 IN 10= 10 Leben oder
Sektor 75 Byte 62 von 05 IN 40=40 Leben oder
Sektor 75 Byte 62 von 05 IN 60=60 Leben oder
Sektor 75 Byte 62 von 05 IN 80=80 Leben

HIJAK Autor unbekannt

EDITOR
Sektor 196 Byte 61 von 06 IN 24=32 Leben oder
Sektor 196 Byte 61 von 06 IN 75=120 Leben oder
Sektor 196 Byte 61 von 06 IN AE=175 Leben oder
Sektor 196 Byte 61 von 06 IN FF=255 Leben

SNOKIE von:Y. LEMPEREAR

EDITOR
Sektor 77 Byte 54 von 03 IN 09=UNENDLICHE Leben

Das war es für heute. Ich habe alle Programme selbst ausprobiert.

* GOOD Byte * DIETMAR

WWW Page im Internet

Hallo Bit Byter!

Ich möchte in diesem Text ein wenig beschreiben, wie man zu einer eigenen WWW Seite im Internet kommt. Ich werde dabei von meinen Erfahrungen berichten. Aber schreiten wir doch zur Tat.

Punkt 1: Der Internetanschluss.
Ohne ihn geht bekanntlich nichts. Man braucht daher zuerst einen Provider. Der Provider ist derjenige, der den Anschluß ans Netz anbietet. Natürlich gibt es mittlerweile sehr vieleAnbieter. Hiersollte man sich haltsehrgenau überdie Kosten informieren. Nicht vergessen sollte man dabei die Telekom, die natürlich kräftig Geld verdient, wenn man keinen regionalen Anschluß findet. Wichtig bei der Auswahl des Providers: schnelle Leitungen und die Möglichkeit, eine kostenlose private Homepage erstellen zu können.

Wenn der Preis stimmt, ist es günstiger, einen regionalen Anbieter zu wählen. Möchte man wiederum möglichst un­abhängig vom Standortsein, empfiehlt sich dieAuswahl ei­nes Internationalen Provider, wie Compuserve oderAmerica Online. Aber auch T-Online in Deutschland oder Swiss Online in der Schweiz, die offiziellen TelekomAnbieter, sind gute Alternativen.

Glücklich ist, wer an einer Universität oder Hochschule ist. Die bieten normalerweise kostenlose Internetbenutzung an. Wer hier eine Homepage erstellen möchte, sollte sich einmal bei den Informatikdiensten informieren.

Das Wichtige noch einmal: möglichst kostengünstiger Anschluß und die Möglichkeit, eine WWW Homepage zu errichten sind die Grundvoraussetzungen für dieAuswahl eines Providers.

Punkt 2: die Hard & Software.
Momentan ist es leider nicht möglich, mit einem 8 BitAtari auf dem Internetzu surfen. Weran derUni ist, wird sowieso einen geeigneten Rechner zur Verfügung haben. Anson­sten sollte man sich einen PC oder MAC beschaffen. Es braucht keinen Pentium, ein 386 oder 486 PC reicht dafür allemal aus.Auch beim Mac reichen Modelle ab 68030 Pro­zessor aus. Noch zu beachten bei den PC: schaut nach, daß der UART Chip 16550 vorhanden ist und keinen 8xxx Chip, so das maximale Übertragungsgeschwindigkeit ge­währleistet ist.

Von dem Provider bekommt man dann normalerweise Software, die es erlaubt, ohne größere Probleme den Kon­takt via Modern zum Provider aufzunehmen und die nöti­gen Anmeideformalitäten ausführt. Weiterhin bekommt man dann noch Internet taugliche Software, mit der man Elektronische Briefe, Elektronische Bretter und natürlich WWW Seiten (ein sogenannter Browser) betrachten kann ' Es empfiehlt sich, einen Netscape Browser zu benutzen, da dieser de facto Standard ist.

Nun fehlt noch das geeignete Modern, Langsamer als 14400 bps sollte das 2odem nicht sein. 14400 ist M [n1­mum. Wer es sich leisten kann, sollte ein 28'800 Modern kaufen, um möglichst flott suden zu können. Keine Proble­me haben diejenige, die einen ISDN Anschluß haben. Hier sollte man sich im Fachhandel über geeignete Modems mit hoher Übertragungsrate informieren. Kein Modern brau­chen die glücklichen Studenten, da ihre PCs schon am Campusnetz angeschlossen sind.

Punkt 3: WWW Seite pianen und aufbauen

Nachdem man sein Setup angeschlossen hat und sich ein wenig mit dem Internet vertraut hat, kommt der Wunsch nach einer eigenen WWW Seite schnell mal auf. Zuerst sollte man sich Gedanken machen, was man überhaupt in den Seiten beschreiben möchte. WWW Seiten sind 1.a Informationsseiten, die mittels Verzweigungen auf andere Stichwörter, Bilder u.s.w. die Informationen möglichst benutzerfreundlich und schnell zur Verfügung stellen.

Als Beispiel nehmen wirjetzt einmal meine Seite. Ich habe mich um eine möglichst breite Atari Seite entschlossen. Wenn man meine Seite aufruft bekommt man zuerst einen Überblick über die Inhalte. Klickt man auf meinen Namen, bekommt man Informationen über meine Person. Die I n­halte sind mittels Stichwörter kurz beschrieben. Klickt man z.B. auf den Punkt Atari 8 Bit, gelangt man in die Atari 8 Bit Seite. Weitere Punkte sind bei mir Informationen über andere Atari Computer und Konsolen. Weiterhin gibt es noch eine Seite, die einige allgemeine Links zur Verfügung stellt. Allgemeine Links sind dabei Adressen, die auf andere WWW Pages im Internet zeigen.

Hat man einmal die Inhalte ausgewählt, muß man die Infor­mationen der Seiten bereitstellen. Eine WWW Seite wird mit Hilfe von HTML, eine Ad Programmiersprache, be­schrieben. Mit HTML kann man die Bilder plazieren, die Sthriftgröße wählen, die Sektoren im Text markieren, die Querverbindungen definieren u.s.w.

Es empfiehlt sich hier ein Buch über HTML zu kaufen und sich ein wenig damit vertraut zu machen. Aber auch im In­ternet selber findet man sehr viele Beschreibungen dar­über. Ich werde jetzt hier nichts über HTML sagen, da daß ganze nur einen Artikel ist und kein Buch.

Eine weitere und einfachere Möglichkeit ist, sich ein spe­zielles Programm zu kaufen, daß es ermöglicht, WWW Sei­ten mit der Maus zu erzeugen. Von diesen Programmen gibt es jeden Tag mehr. Für eine einfache Seite genügen
auch die einfachsten WWW Editoren. Es gibt sogar schon Text Editoren, die im HTML Format abspeichern können.

Wir wollen noch einmal kurz sehen, wie meine Atari 8 Bit Seite aufgebaut wurde. Zuerst gibt es Links zu anderen Atari 8 Bit Seiten im Internet. Danach folgt eine Vorstellung desABBUCs und der Link zuroffiziellenABBUC WWW Seite. Als Abschluß gibt es noch mehrere Farbfotos von Atari Hardware zu bestaunen.

Punkt 4: WWW Seite bekannt machen

Hat man einmal seine WWW Seite erstellt und sie Online geschaltet, muß man natürlich dafür sorgen, daß man die Seite bekannt macht, so das andere Internet Surfer einmal die eigene Seite besuchen.

Einerseits wirbt man ein wenig in den Atari 8 Bit Medien, an­dererseits pflegt man Kontakt mit mehreren Atari Freunde auf dem Netz. Das beste ist aber, möglichst viele Links auf die eigene Seite auf anderen WWW Seiten zu plazieren. Kontakt knüpfen ist dabei das wichtigste. Weiterhin kann man sich bei einem Suchdienst anmelden. Man wird so bald merken, daß einige Personen auf Besuch kommen.

Punkt 5: WWW Seite aktualisieren

Natürlich sollte man immer die eigene Seite aktualisieren. Wer will schon immer das gleiche ansehen. Man wird bald bemerken, daß man immer wieder neue Ideen hat, die man in seiner Seite einbauen möchte.

Ideen von anderen Seiten können auch übernommen werden, Es gibt immer wieder sehr findige Leute im Internet.

Punkt 6: Allgemeine Informationen

Natürlich könnte man jetzt noch sehrvieles schreiben, aber ich möchte in diesemArtikel nicht übertreiben. Ich kann im_ mer noch in einer anderenAusgabe wieder etwas über das Internet schreiben.

Ihr könnt mich aberjederzeit fragen, sei das via Email oder auf dem normalen Postweg. Adressen am Schluß des Textes.

Ich hoffe, daß ihr ein wenig Lust bekommen habt, auch einmal im Internet zu schnuppern. Möglichkeiten gibt es ja sehr viele. Vielleicht haben einige von euch auch Lust bekommen, eine eigene Seite zu kreieren. Als Startpunkt kann man meineSeite benutzen. Von dortaus könnt ihr auf andere Atari 8Bit Seiten und zur ABBUC Homepage gelangen.

Viel Spaß beim SURFEN! Sacha Hofer

Adresse:
S.Hofer, via ca di ferro 7, CH-6648 Minusio

Email: hofer@iamexwi.unibe.ch oder
101 762.3472@compuserve.com
Homepage Adresse: http://iamexwi.unibe.ch:80/studenten/hofer

Nachlese CeBit 96

und 1 . Waltroper Computertag

Liebe Bit Byter!
Auf dem CEBIT-Oldietreff war der ABBUC nur durch die Mitglieder des CCE vertreten, die auch im ABBUC Mitglied sind. Gerade im Computer-Club-Elmshorn gibt es ganz offen­sichtlich noch eine sehr starke 8-Bit-ATARI­Gruppe, über die ich demnächst einmal be­richten werde. Auf dem CEBIT-Oldietreff wur­den natürlich wieder jede Menge Erfahrun­gen ausgetauscht und Hardware herumge­reicht. Wer hat schon einmal einen Jupiter ACE in den Händen gehalten?? Ansonsten bot die CEBIT für uns im 8-Bit-Bereich wenig bis nix. Wir sind am Ball, auf der CEBIT-HO­ME evtl. wieder eine Oldieecke aufleben zu lassen. Verschiedene Leute kümmern sich bereits darum!

Weitaus erfolgreicher für den kleinen ATANI war der erste Waltroper Computertag, zu dem der CCE mit ei­ner großen Mannschaft angereist war. Gleich an zwei Ständen waren die kleinen ATARI's in voller Aktion zu bewundern. Ich hatte meinen ATARI-400 und einen 500XL dabei, auf dem die Programmiersprache LOGO vorgestelltwurde. Wie nichtanders zu erwarten, fanden die bunten Kröten großes Interesse des meist sehr fachkundigen Publikums. Die einfache Handhabung und Programmierbarkeit derATARI-Rechner begeister­te manchen Besucherebenso wie die Technik des ATARI-400.

Das zeitweise vorgeführte Spiel STAR-RAIDERS zeig­te den großen Unterschied zwischen Weltraumspielen derfrühen 809rJahre zum heutigen Stand in Grafik und Sound auf. Mir wurde aber von vielen bestätigt, daß es weitaus mehr auf Spielwitz ankommt, als auf tolle,Grafik mit bestem-Sound, aber unbeherrschbares oder langweiliges Spielgeschehen. Da ist wirklich nicht alles besser, was es heute gibt. Zu den ATARI­Geräten konnte ich den vielen Besuchern am Stand jede Menge Informationen geben, auch über den ABBUC, seine Größe und die Möglichkeiten im 8-Bit Bereich mitzumachen. Es war eine gelungene Veranstaltung in der Stadthalle in Waltrop.

Ich gehe davon aus, daß die kleinen ATARI's auch auf den im Herbst in Elmshorn stattfindenden Computerta­gen wieder dabei sind. Die Vorbereitungen dazu sind schon voll im Gange.

Grüße an alle ATARlaner von Willi

 

ABBUC Bücherbibliothek

In den vergangenen Monaten wurde viel über die Planung einer ABBUC­Bücherbibliothek geredet und geschrieben. Nun ist es soweit und wir lassen die Seiten auf Euch los, d.h. Ihr könnt ab sofort Bücher bei Highlander Soft ausleihen (genaue Adresse am Schluß des Berichtes). Zur Zeit sind 92 Bücher im Angbeot, davon 68 verschiedene, aber die Bibliothek wird ständig erweitert. Der Ankauf der Bücher hat einige finanzielle Opfer verlangt und daher erwarten wir von Euch auch eine angemessene Pflege der Bücher. Nicht alle Bücher sind in einem tadellosen Zustand (abgegriffen, Seiten lose etc.). Die losen Seiten werden aber so fern möglich wieder eingeklebt, so daß ihr keine Bücher bekommt, die aus Einzelteilen bestehen.

In jedem Buch befindet sich auf der letzten Innenseite eine Tasche mit der Ausleihkarte. Auf dieser Karte ist u.a. vermerkt wann das Buch zurück sein muß usw.. Der zweite Teil der Karte beinhaltet die Richtlinien, die nun mal gezwungenermaßen aufgestellt werden müssen.

Was zu den Richtlinien noch zu bemerken wäre ist, daß wir alle Leute, die die Bücher nicht zurückgeben oder die Bücher auf unsere Kosten zurückschicken, öffentlich im ABBUC (Magazin oderlund Diskette) anprangern werden. Dies sind sicherlich mittelalterliche Methoden, die wir aber gezwungen sind anzuwenden, da sonst keine andere rechtliche Handhabe vorhanden ist. Es liegt nur an Euch, ob solche >unappetitlichem Texte erscheinen werden. Wir appellieren an Eure Ehrlichkeit, bitten um Euer Verständnis und hoffen das die schwarze Liste erst garnicht zustande kommt.

Welche Bücher gibt es bei uns ?
Wir hatten auf der Messe in Schreiersgrün eine Umfrage gestartet und nach dieser Auswertung hat sich gezeigt, daß die User im allgemeinen nur an Literatur für unseren 8-Bitter interessiert sind (fast). Deshalb werden wir auch nur Bücher für ATARI XLIXE anbieten. Eine ausführliche Bücherliste werdet ihr ab sofort auf jeder ABBUC-Magazindiskette vorfinden, mit den jeweiligen Neuerungen.

Was kostet denn das ?

Nachdem bei der Post Erkundigungen eingezogen worden sind hat sich herausgestellt: Bücher verschicken ist nicht die billigste, Sache der Welt ! Büchersendungen müssen offen verschickt werden und gelten nur bis max. 1Kg als Büchersendung. Was schwerer ist wird als Päckchen/Paket verrechnet. Es sind also nur 2-3 Bücher auf einmal möglich, außer Ihr wollt doppelt bezahlen. Die Kosten betragen im einzelnen:

Standard 0,80 DM
Kompakt** 1,10 DM
Groß** 1,50 DM
Maxi** 2,50 DM

**bis auf weiteres sind bei Nichstandardsendungen in Rechteckforrn auch folgende Höchstmaße zulässig: L 600 mm, B 300 mm, H 150 mm oder L,B,H zusammen 900 mm, jedoch in keiner Ausdehnung länger als 600 mm. Für die Ausleihe der Bücher kommt wohl nur MAXI in Betracht. Mit diesen Tatsachen müssen wir uns abfinden.

Wie bekommt ihr die Bücher ?

Ganz einfach! Ihr füllt den Bestellschein aus und sendet ihn an Highlander Soft. Die Bezahlung hat im Voraus zu erfolgen. Gültige Zahlungsmittel sind Briefmarken, die einfach dem Bestellschein beigefügt werden und Barcash, sprich Überweisung auf mein Konto.

Beachtet bitte, das ihr den genauen Titel und/oder die genaue ISBN-Nr. bei Eurer Bestellung angebt! Zur Ausleihdauer möchte ich noch erkären, das in den 4 Wochen NICHT der Postweg mit eingerechnet wurde.

Ein Beispiel:
Geht ein Buch am 12.06.1996 mit der Post raus, so muß es nicht am 12.07.1996 sondern erst am 16/17.O7.1996 wieder bei mir ankommen.

Ok, soviel zum Thema Bücher ausleihen . In dieser Textbeilage findet Ihr'auch einen Zettel mit der Umfrage, die jeder beantworten sollte, damit wir uns besser auf Eure Wünsche einstellen können. Um rege Teilnahme. an der Umfrage wird gebeten.

Nun noch etwas in eigener Sache! Ich suche ein Bibliothekenprogramm für ATARI ST(E) - kein Bücherverwaltungsprogramm, denn mit so einem Programm schlage ich mich z.Zt. herum.

Demo Kurs Teil 4

Hallo Demo-Freax,
dies ist doch tatsächlich der 4. Teil des Kurses. Ich hoffe, daß ich einige User dazu bewegen konnte, auch etwas eigenes zu coden, mittlerweile sollte auch mein Dentro "Carpe Demo" erschienen sein...

Was gibt es aus meiner Sicht zu der XI-Demo-Szene zu sagen? Nun, erstens kommen immernoch alle Demos aus dem ehemaligen Ostblock, vor allem aus Polen ' Zweitens setzt sich der Trend durch, keine Mega-Demos mehr zu coden, sondern "nur Intros, Shortros, Dentros, ... d.h. File-Demos.

Diese Entwicklung war vorauszusehen, da man dies schon auf dem Amiga und PC beobachten konnte. Weiter geht der Trend klar in Richtung 3D-Effekte, sei es Zooming, Rotationen, Texture-Mapping, Gourand-Shading.... Gerade die Quasimodos zeigen, was in dieser Richtung möglich ist.

Ich finde es aber irgendwie schade, das "alte" Effekte und "neue" Effekte nicht miteinander kombiniert wer­den. Wag spricht denn dagegen, z.B. wieder DII's für Farbveränderungen zu nehmen?

Warum werden keine Player/Missles mehr verwendet? Gerade die sinnvolle Kombination aller (!) XL-Features kombiniert mit ausgeklügelten Algorithmen machen ein gut designtes Demo aus. Es kommt nicht darauf an, wieviele Fixe[ o.ä. ich in einem Vbi hinbekomme, son­denn, daß das Demo einfach gut aussieht... egal auf weichem technischen Stand die Routinen sind... Es nützt dem besten Demo nicht, wenn es zwar technisch hoch kompliziert ist, es aber unattraktiv aussieht.

Doch kommen wir zu einem weiteren Bereich des Scrollings, den nicht oft gesehenen Player-Missle­Scrollen

PM-Scrollersind einfach zu programmieren (zumindest die vertikalen ... ) und haben den Vorteil, daß sie gänzlich unabhängig vom Hintergrund sind und daß sie über die ganze Länge des Bildschirms gelegt werden können. Ein nicht zu unterschätzender Vorteil ist auch, daß sie linear im Speicher abgelegt werden und somit bestens mit dem 6502 per indirekter Adressierung bearbeitet werden können. Ein Nachteil ist aber, der GTIA zwackt dem Prozessor einiges an DMA-Zyklen ab, womit weniger für eigene Routindn übrig bleibt. Doch macht diese DMA-Stehlerei nicht unbedingt so viel aus, als daß man ein Auge darauf werfe
n sollte... zumindest wenn die Routine schnell genug ist. Merkt man, daß et­was nicht stimmt mit dem Effekt, so sollte man, wenn man PM nutzt, erstmal diese ausschalten und schauen, ob damit der ge­wünschte Effekt eintritt. Doch dies nur als Tip..

Wer schon genau weiß, daß er PMs einetzen will, sollte auf jeden Fall schon zu Beginn der Routinen, auch wenn noch nichts mit PMs dargestellt wird, diese ein­schalten, damit man eben nicht die böse Überraschung erlebt, daß die Taktzyklen nicht ausreichen. Einfach zu Beginn des Demos:

jsr pminit
...
pminit lda #0
Idx #0
sta p0,x
sta p2,x
inx
bne 0
Ida #46 oder 62
sta 559
Ida #3
sta 53277
Ida #pmbase
sta 54279
rts

Damit stellt man sicher, daß gerade die Dli- und Vbi­Routinen nicht "aus dem Takt kommen", wenn das Scrolling der PMs einsetzt...

Machen wir uns ans Werk... zuerst den `normalen" und leicht zu codenden vertikalen PM-Scroller:

Jeder weiß, daß beim XL sogenannte Player-Missles­Grafik gibt, das sind Objekte, die unabhängig vom Hintergrund bewegt werden können und eine Auflösung von 8x128 bzw. 8x256 Pixel haben (lassen wir die Missles weg und behandeln diese, als wären sie ein 5, Player ... ). Der Witz an der Sache ist, daß sie linear im Speicher abgelegt werden, d.h. jeder Player besteht aus 8 Pixel in der Breite, d.h. einem Byte. Im Speicher, folgen für die Bytes einfach linear hintereinander.

Jetzt sollten einigen Bitbytern schon ein Lämpchen aufgehen... Ein XL-Zeichen besteht aus 8 Bytes... und sind 8 Pixel breit... hmmm, diese passen also genau in einen Player und je nach vertikaler Auflösung des Players (128 oder 256 Scanlines) eben 16 bzw. 32 Buchstaben untereinander. Machen wir uns das Scrolling anhand eines Ablaufsche­mas (schon wieder919) klar:

phase 0: Zeichen aus dem Zeichensatz ganz unten in den Player reinkopieren .. phase auf 1

phase 1: Die Daten des Players immer um eine Zeile nach oben kopieren, 8 mal 8 Bytes ist ja ein Zeichen lang. Nachdem 8 mal der Pla yer verschoben wurde, phase auf 0 und neues Zeichen kopieren.

Klingt simpel... ist es auch... So sieht die Routine aus:

init isr pminit ;Player Missle Grafik einschalten+ Speicher löschen

jsr tabinit ;Tabellen initialisieren

.....

vbi jsr prnscroll

jmp $e462

pmscroll Ida phase ;an welcher Stelle stehen wir
bne pmscrolll;Zeichen schon kopiert,dann 8x nach oben verschieben
Ida #1 ;phase auf 1
sta phase
clc
Ida #text ;Adresse des Scroll-Textes
adc fontcounter;Nr. des Zeichens aus dem Scroll­Text
sta v0
Ida /text
adc fontcounter+l
sta v0+1
cmp /texte;Textende schon erreicht?
bne A ;nein, sonst von vorne
Ida v0
cmp #textend
brie A
lda #0
sta fontcounter
sta fontcounter+I
ldy #0 ;Atasci-Wert des Zeichens holen
Ida (v0),y
tax ;ins X-Register
Ida fontadrl,x;Adresse des Zeichens im Zeichensatz ermitteln
sta vo
Ida fontadrh,x
sta vo+I
pmcopy Idx #0
.0 Ida (v0),y ;Bytes aus dem Zeichensatz holen
stap0+120,x; ganz unten in den Player reinschreiben oder man nimmt einen Buffer..

inx
iny
cpy #8 ;8 Bytes...
bcc 0
sty vertikal;und gleich Zähler setzen für das Scrollen
rts
pmscrolll ldx#0; ganzen Player-Inhalt um eine Zeile nach oben
.0 lda p0+1,x;schieben
sta PO,X
inx
cpx#128 ;128Rasterzeilen(bei256entsprechend mehr..)
bcc.0 dec vertikal;so lange, bis 1 Char nach oben (8 Zeilen) beq .1 ;wenn 8x kopiert, dann phase auf 0
rts

.1 lda #0
sta phase
clc ;nächstes Zeichen aus dem Scroll-Text
Ida fontcounter
adc #I
sta fontcounter
Ida fontcounter+l
adc #0
sta fontcounter+I
rts
tabinit
Ida #font
sta v0
Ida /font
sta vO+I
ldx #0
.0  Ida v0
sta fontadrl,x
,Ida v0+1
sta fontadrh,x
clc
lda v0
adc #8
sta vo
lda v0+1
adc #0
sta vo+I
inx
cpx #128
bcc 0
rts

Dies ist eigentlich Standard... Man kann nun durch, Dlis ganz einfach die horizontale Position des Players z.B. anhand einer Sinus-Tabelle verändern... oder... ' Doch warum versuchen wir uns nicht an einem horizontalen PM-Scroller (Titel #44 Intro zum Intro... v. mir z. B.) Hier liegt die Sache aber etwas anders... Ein PM ist nur 8 Pixel breit... zu einem gescheiten horizontal- ' Scroller gehört, daß er schon Breiter ist als ein Zei­chen, da man ihn sonst nicht lesen kann.

Lösung: Man legt alle PMs nebeneinander und hat so­mit 40 Pixel zur verfügung, was ausreichend ist (4 Player+alle Missles macht 5 Player a 8 Pixel=40 Pi­xel.. ). Stellt man noch die 4-fache Breite der PM-Grafik ein, so schließt sich mal wieder der Kreis und die PMs (nicht Produkt-Manager.. 😉 ) bedecken genau den XL-Schirm. Wie läuft hier aber das Scrolling ab... mal wieder ein Ablaufplan:

phase 0: wie beim vertikalen Scroller wird das Zeichen in einen Buffer kopiert...

phase 1: horizontal worden 8x die Pixel verschoben und dann wieder v. phase 0

Jetzt ist es schon nicht mehr so einfach wie bei einem vertikalen PM-Scroller, da hier nichts mehr linear auf­gebaut ist... Wie gehen wir an die Sache heran...

Nochmal zum Veranschaulichen eine kleine Skizze:

<--- Bildschirmbreite --->
p0 p1 p2 p3 m
<--- Buffer --->

Wie beim normalen Scrolling per Antic muß man, um das Hereinpoppen der Zeichen zu verhindern, m it ei­nem Buffer arbeiten (s
.o. Skizze). Der Buffer ist 48 Bit breit... statt 40 Bits wie die Player...

Scrolling hat immer mit Bits verschieben zu tun, d.h. man kann bequem den 6502-Befehl dafür verwenden, nämlich ROL. Rol steht ja bekanntlich für "ROtate Leff, d.h. die Bits einer Speicherzelle werden nach 'links verschoben (was auch einer Multiplikation mit 2 entspricht ... ) mit dem Unterschied zu ASL ("Arithmetic Shift Leff), daß "herausfallende" Bits in das Carry-Bit wandern und beim nächsten Rol in Bit 0 wandern. Die Bits rotieren eben. Und genau diesen Umstand ma­chen wir uns zunutze.

Wie oben beschrieben arbeiten wir mit einem 5 Byte breiten Buffer, d.h. er kann genau 5 Zeichen aus dem Zeichensatz aufnehmen. Wir müssen nun rechts an­fangen die Bits zu verschieben und uns nach links "vorarbeiten", nicht von links nach rechts, da uns da­durch Bits verloren gehen!

Die Scroll-Routine sieht so aus: Softscroll

ldx #8 ;8 Bytes scrollen loop cic ;beim Scrollanfang Carry-Bit löschen, damit kein "Müll" reinscrollt

rol buffer+40,x ;ganz rechts anfangen

rol buffer+32,x ;und dann nach links weiter rol buffer+24,x rol buffer+16,x rol buffer+8,x

rol bufferx

dex

bne loop

Sieht wie ein ST-Scrolling-Demo aus... 😉 Nein, mal im ernst... die "rausfallenden" Bits werden automatisch in das nächste Byte übertragen und wir müssen uns nur um die richtige Abarbeitung des Buffers küm­mern. Warum arbeiten wir eigentlich mit einem Buf­fer??? Man könnte direkt die Pläyer-Daten verschie­ben. Dies ist noch einfach händlebar, wenn man ein­fach einen `normalen" horizontalen Scroller haben möchte. Ich habe auch zuerst direkt die Player-Daten verschoben.

Statt rol buffer+40,x heisst es eben röl p3,xPgefolgt voh rol p2,x usw...

Am Ende des Softscrollings muß man die Daten aus dem Buffer in die jeweiligen Player kopieren, wobei aber das äußerste Byte nicht kopiert wird, da dieses $nur gebraucht wird di~it die Ze~Ihen nichi reinploppen. Die Kopierroutine sieht folgendermaßen aus:

pmcopy Idy #Position,;wo im Player.. .
.0
Idx #0
.0 Ida bufferx
sta p0,y
Ida buffer+8,x
sta pl,y
Ida buffer-16,x
sta p2,y
Ida buffer+24,x
sta p3,y
Ida buffer+32,x
sta p4,y ;sind die 4 Missles...
iny inx cpx #8 ;8-Bytes
bcc.0 rts

Man kann auch die Laufschrift vergrößern, indem man statt nur einmal das Byte in den Player zu kopieren, dieses Byte mehrmals hintereinander schreibt:

Ida buffer;x
sta p0,y
sta p0+I,y
sta p0+2,y
sta p0+3,y
........
iny
iny
iny
iny ;4x iny statt einmal!

So, was aber wenn man die Laufschrift vertikal bewegen will? Dann müßte man ja jedesmal die Daten in eine andere Speicherzelle kopieren und dann der Softscroll-Routine sagen, wo sie die Bits verschieben muß. Dies ist in meinen Augen zu aufwendig und rech,fferfigt den Einsatz eines Buffers. Am Ende 49r Scrollroutine wird der 'Buffer' dann dorthin kopiert, wo er hinsoll... Man kann auch den Buffer beim Kopieren "stretchen", d.h. größer oder kleiner machen, drehen usw. Der Vbi sieht dann so aus:

vbi jsr pmscroll ;die eigentliche Scroll-Routine
jsr pmcopy ;die Routine, die den Buffer bearbeitet und dann in die Player kopiert
jmp $e46e

In dem Titei#44 hab ich anhand einer Tabelle (übrigens die gleiche Tabelle, die ich bei den fallenden Pixel verwendet habe .. ) den Buffer kopiert und schon war der hüpfende Scroller geboren. Die Routinen sind so schnell, daß sogar eine Feuer-Routine ablaufen kann...

Beachten sollte man nur noch, daß alle Player nebeneinander setzt in folgender Reihenfolge:

p0 pl p2 p3 m3 m2m mlm m0

Die Missles müssen spiegelverkehrt zu den Playern gesetzt werden, dies hat technische Gründe. Der XI stellt bei Zusammenfassung der Missles zu einem 5. Player den Speicherinhalt so dar, daß Missle 0 die Bits 7+6, Missle die Bits 5+4 usw... aufnimmt. Im Source sollte man dies in der PMinit-Routine erkennen.

Auf dem Magazin sollte der Source-Code zu dem In­tro zu dem Titel-Demo #44 sein. Er liegt im Bibo-Ass­Format vor, aber als Ascii-Source. Die, die einen Bibo­Ass haben, können den Source einfach per ENT-Be­fehl einiesen. Für andere Assembler muß man einfach die Zeilen-Nummern löschen (Atmas, Makro-Ass). In dem Source kann man sich die nötigen Routinen anschauen, wer will kann sich auch die Feuer-Routine, die ich im letzten Magazin erklärt habe, genauer be­trachten.

Bis zum nächsten Mal
Heaven

Internet Email: "nadkar@zeus,rz.fh-pforzheim.de"

Die alte Email-Adresse "lord@hp9001.rz.fh-pforz­heim,de" existiert nicht mehr!

Umfrage

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

0471 XEP80 DISKS ED/4S
Die XEP80 InfoDisk von Harald Gödel, überarbeitet von Günter Ba
rtl. Auf der ersten Disk findet Ihr über ein Menü aufrufbar unter anderem ein angepasstes TurboBASIC, ein Leser.BAS mit 80Zeichen Ausgabe, eine Demo und diverse Texte zum Thema XEP80. Auf der zweiten Disk befindet sich ein angepasstes BIBO-DOS mit der 80Zeichenausgabe sowie ein weiteres angepasstes TurboBASIC.

0472 TEXTPRO 5.2 ED/1S
Der vollkommen überarbeitete Nachfolger vom bekannten TEXTPRO 4.5, das bei uns vor längerer Zeit unter der Nr 277 erschienen ist. Wer uns die originale ABBUCPD-Disk und 1,30 DM Rückporto schickt, bekommt das Update gratis. Bitte die Disk der PDBibliothek zuschicken.

0473 PIXELART DELUXE 1.3 ED/1S
Ein Zeichenprgramm von Art Horan. Bedienbar über den Joystick. Zu Beginn wird ein umfangreicher Anleitungstext in Englisch geladen. Die einzelnen Kapitel werden mit dem Joystick oder Tastatur ausgewählt und dann geladen. Das Programm kann auch mit einem TouchTablett bedient werden.

0474 SUPER STUD POKER ED/1S
Das bekannte Kartenspiel in einer Variante von Walt Huber. Man kann zwischen drei bis fünf Mitspieler (die vom Rechner gesteuert werden) wählen. Es kann zwischen 7 verschiedenen Spielvarienten und den ChicagoRegeln gewählt werden. Die Karten werden in Windowtechnik ausgegeben.

0475 ATARI TOOLS ED/1S
Eine Disk mit nützlichen Tools, die vom Kopierprogramm über Zeichensatzfinder, Disassembler und AUTORUNSYSGenerator bis zum Packer reichen. Insgesamt 21 Programme.

0476 AMC INTERN #1 ED/2S
Der AMC stellt sich vor. Ihr findet viele Informationen über den AMC. Von der Preisliste (mit guten Restpostenangeboten) bis zum guten Hardwareangebot findet das Herz des Atarianers immer etwas. Als Zugabe findet man die Titelbilder der AMCProgramme.

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

 

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