ABBUC Magazin 062


IMPRESSUM

© 2000 Atari Bit Byter User Club e.V.
C/O Wolfgang Burger, Wieschenbeck 45
D-45699 Herten Tel +49 2366 396323
Mail Wburger@cityweb.de

Das Atari Bit Byter User Club Magazin erscheint vierteljährlich. Jeweils halbjä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

Inhalt

Inhalt:
Seite 3 Atariada 2000 in Prostejov
Seite 9 3,5″ Diskettenlaufwerk an XF 551
Seite 11 ATARI Messe in Neuss
Seite 13 Das ATARI Forschungslabor Teil 2
Seite 14 Disks am Ende?
Seite 16 Parallelbusinterface Teil 3
Seite 21 RAF zieht um
Seite 21 WAP auf dem Atari?
Seite 22 Wie funktioniert ein Emulator ?
Seite 29 Heißer ATARI Herbst
Seite 32 Die PD-Ecke

Atariada 2000 in Prostejov
Written by Jiri Bernasek – BEWESOFT

Meine Vorbereitungen für das Atariada- Treffen haben dieses Jahr sehr lange gedauert. Es begann alles bei der vergangenen Atariada vor einem Jahr, als ich versuchte, (zusammen mit Olda Rezler), ein Spielturnier mit „Maze of AGDAgon“ zu organisieren. Dies ist ein ziemlich altes Shareware- Spiel aus den USA, das mit bis zu 8 Atari-8-Bit Computern zusammenarbeitet. Meine Hardware funktionierte perfekt, aber die Software crashte sehr oft – so oft, dass wir nie zu einem wirklichen „Game Over“ kamen. Ich entschied, dass es auf der nächsten Atariada ein besseres Netzwerk- Spiel geben sollte. Während der nächsten Monate redete ich unglücklicherweise davon und schrieb darüber in Briefen, so dass ich keine Wahl mehr hatte: Ich musste dieses Spiel schreiben.

Im Januar 2000 machte ich den ersten Schritt: Ich kaufte mir einen zweiten Computer. (Ich fand eine Anzeige in einer Zeitung – es würde recht schwierig werden, mit nur einem Rechner ein Netzwerk-Spiel zu debuggen…) Unglücklicherweise war dieser 800XE „Made in China“ und so war das TVBild recht schlecht. Ich schrieb einen Monat nicht an dem Spiel und baute ein Upgrade für einen besseren Videoausgang. Wenigstens konnte ich auf der Atariada noch etwas anderes zeigen, zusätzlich zum schon fertigen „BTC“ Als das Upgrade fertig war, erhielt ich eine Lieferung mit 3 Ausgaben des polnischen Magazins „Syzygy“ – und zwei weitere Wochen waren verloren. (Es braucht seine Zeit, den Inhalt von 6 doppelseitigen Disks, zumeist in DD, zu lesen, alles in polnisch geschrieben und selbst einige Artikel zu schreiben… (Ich spreche tschechisch, nicht polnisch!))

So begann die Arbeit an meinem Spiel schließlich Ende Februar. Zu dieser Zeit klingelte mein Telefon – und Zdenek Burian (der Organisator) erzählte mir die schockierende Neuigkeit: nämlich dass die Atariada nicht am letzten Samstag im April sein würde (wie sonst immer) – sie würde dieses Jahr am ERSTEN Samstag im April sein! Da es ziemlich schwierig berechnen war, wie lange ich brauchen würde, das Spiele zu Ende zu schreiben, musste ich mit voller Geschwindigkeit daran arbeiten: Jeden Tag bis 23:00 Uhr. Ich malte Bilder mit der STMaus – das ging ganz gut. Ich schrieb Zeichensätze und Spielregeln – das ging nicht so gut. Ich schrieb die Routinen fürs Spiel – und wurde dabei fast verrückt. (Warum waren die grünen Männchen so dumm, wenn da mehr als 2 KB Code davor waren?) Ich schrieb dann noch die Routinen für die Kommunikation über den seriellen Bus. Ich hatte genug von dieser Arbeit. Ich schrieb die Menus und Texte und wusste eigentlich gar nicht mehr, warum ich das tat. Ich testete das ganze Spiel – und dies war ein großes Problem: Wie testet man ein Spiel für 8 Computer, wenn nur 3 Systeme verfügbar waren (einer gehört Olda), mit nur 2 Monito- ren und nur einem Spieler (das war ich)? Ich habe eine Woche lang ziemlich viel telefoniert bis Olda zu mir nach Hause kam (meine Familie spielt keine Computerspiele) und als er da war, sagte er: „Ich habe nur eine halbe Stunde Zeit und wir müssen noch über die Einzelheiten unserer Fahrt reden. Gib mir Dein Spiel auf Disk mit und ich schaue es mir später zu Hause an.“ Zu dieser Zeit war auch die Musik schon fertig (geschrieben an drei Abenden, zusammen mit dem Code, weil sie auf zwei Kanälen spielen muss).

Nun, irgendwie schaffte ich es, das Spiel rechtzeitig fertig zu bekommen. Es waren sogar noch ein paar Tage übrig, um Disketten davon zu machen (damit auf der Atariada nicht soviel Zeit fürs Kopieren drauf geht), die ganze Hardware einzupacken und einige Probleme mit der SynFile Datenbank zu beheben. Der Ausdruck meiner Software- Liste dauerte zwei Tage und ergab einen 2 cm hohen Papierstapel. Nicht zu vergessen das Druckerfarbband. Und alles nur, weil SynFile an einer bestimmten Stelle des Index-Files einen Datenbankeintrag wie verrückt in einer Endlosschleife druckt. Die Neuindexierung dauert ungefähr 2 Stunden. Dieses verrückte Programm hat auch noch einen Eintrag für das ABBUC Magazin 60 an viele verschiedene Stellen in der Datenbank verteilt und die alphabetische Ordnung total ignoriert.

Samstag, 8. April. Der Wecker ging um 03:34 Uhr – ekelhaft. Ok, aufstehen (das hat recht lange gedauert), rein ins Auto (ein 16 Jahre alter Skoda 120 – wir haben niemanden gesehen, der zu dem Treffen mit einem besseren Auto kam) und zu Olda’s Wohnung fahren. Um 5:15 Uhr sind wir dort losgefahren, die 276 Km lange Fahrt war ohne Probleme und so kamen wir um 9:15 Uhr im uns wohlbekannten Raum des Restaurants „Hana“ in Prostejov an.

Der Raum war alles andere als leer und es kamen immer noch viele andere Leute an. Ich sah mit Freude, dass Dank Zdenek die meisten 8-Bit Systeme auf einigen Tischen nahe der Tür beieinander standen – meine Netzwerkhardware ist längenmäßig natürlich begrenzt. Im vergangenen Jahr waren wir gezwungen, eine Verbindung quer durch den ganzen Raum zu machen. Einige Systeme konnten wir mangels Kabel nicht mal erreichen. 23 Meter scheinen vielleicht genug zu sein, aber es sind immer 3 Meter von einem Computer zum nächsten. Nur das letzte Stück Kabel hatten wir dieses Jahr durch ein 5 Meter langes Stück ersetzt. Das alte Kabel war so dick gewesen, dass es kleinere Teile von den Tischen geworfen hatte, wie eine Feder 🙂

Wir packten unsere beiden Systeme aus, eine ziemlich große 8-Bit Konfiguration. Im Auto hatten wir zwei Monitore, einige Diskettenboxen und einen großen Wäschekorb voller Hardware. Wir haben den Hauptmonitor auf einen Karton gestellt, so dass die Leute ihn von weiter weg sehen konnten. Obendrauf, zwischen die beiden Antennen (es war ja eigentlich ein Fernseher), stellten wir eine Tafel mit unseren Namen, „BeweSoft“ und „Prager Atari Club“ und eine kurze Beschreibung unseres Angebotes. Ich denke, dass alle Besucher eines solchen Treffens das gleiche tun sollten. Soweit ich mich erinnern kann, habe ich keinen anderen Tisch mit einem so gut sichtbaren Identifika
tor in diesem Raum gesehen. Bei den tschechischen Atariada Treffen sind wir immer in Eile, besonders weil einige Leute nur wenige Stunden bleiben und so ist es schwierig zu erkennen, wer der Besitzer eines bestimmten Computers ist und welchen interessanten Dinge es gibt.

Wir begannen sofort, alle 8-Bit Computer in dem Raum mit meiner Netzwerk-Hardware zu verbinden. Es gab zu dem Zeitpunkt nur 7 Systeme und eines davon war sogar sehr eigenartig installiert. Wir überredeten noch jemanden, seinen zweiten XE, den er eigentlich verkaufen wollte, auszupacken und stellten noch einen alten Fernseher auf, der uns vom Organisator zur Verfügung gestellt wurde, sowie einige Kabel und Joysticks aus unserem Korb. Wir hatten einige Reserveteile mitgenommen, weil wir nicht sicher waren, dass jeder ein SIO Kabel und einen Joystick für unser Netzwerk haben würde. Wir hatten Kassettenlaufwerke erwartet, aber die meisten hatten ST-XL Links mit und keine Floppies. Glücklicherweise lief das Spiel ohne gravierende Probleme. Wir entdeckten lediglich einige recht kleine Bugs:

Bei einer großen Anzahl von Spielern gibt es nicht genug Objekte zum Einsammeln und es ist sehr schwierig, andere Spieler mit Bomben zu zerstören. Bei wenigen Spielern sind die größte Gefahr die verrückten grünen Männchen, aber deren Anzahl verringert sich bei mehr Spielern und der interlaced Grafikmodus flackert auf den meisten Monitoren stärker als auf meinem Fernseher. Außerdem versuchten einige nach Spielbeginn, Textnachrichten zu schicken oder sich wieder einzuloggen, aber das Mastersystem unterstützt dies zu dem Zeitpunkt nicht mehr und so wurden zweimal Computer vom Spiel getrennt. Aber alle anderen Spieler spielten problemlos. Am späten Nachmittag „testeten“ wir sogar den Fall, dass ein Spieler einfach ausschaltete, alle Kabel trennte und die Atariada verließ – selbst dies beeinflusste nicht das Spiel. Aber das war viel später. Oh, vielleicht vergaß ich zu sagen, wie das Spiel heißt: Multi Dash.

Es sollte nun schon in der XL/XE Szene verfügbar sein, zusammen mit der Beschreibung der Hardware. (Anm. der Redaktion: Natürlich, erinnert Euch das an das letzte Sondermagazin des ABBUC) Auf der Atariada verteilte ich 14 Kopien an Leute, die eine DD Diskette dabei hatten und weitere Kopien gehen später auf die Post. Ich kann es kaum erwarten, das Spiel noch etwas zu verändern. Wenn man mit mehreren Computern spielt, sollten sich besser zuerst alle Systeme einloggen, dann die Textnachrichten verschicken und danach erst das Spiel starten. Und man sollte zusammenarbeiten, um andere Spieler zu zerstören, zum Beispiel in dem man mehrere Bomben um einen platziert, der in einer Ecke steht? An diesem Morgen spielten wir mein Spiel zwei mal. Das erste Mal war nur zum Training, aber die zweite Runde war ein Wettkampf um einen Preis. Aber die Beschreibung der zwei Runden ist nicht exakt. Nach dem Training wechselten einige Joysticks die Hände. Ich glaube, nicht mal der Gewinner des Wettbewerbs spielte in der Trainingsrunde mit. Um die Attraktivität des Spiels zu erhöhen, bot ich einen Preis für den Gewinner. Um die Wahrheit zu sagen, es war lediglich eine alte, nicht mehr gebrauchte Hardware aus meiner Sammlung, aber auf der anderen Seite konnte man aus einigen Dingen auswählen. Es hat recht lange gedauert, bis der rechte Preis gefunden war. Zdenek, der Organisator, hatte ein recht großes Problem, den Tisch zu bekommen, den wir für diesen Zweck „gestohlen“ hatten. Es gab noch eine Gruppe, die auf diesen Tisch warteten – sie waren gerade erst gekommen. Der gewählte Preis war das „Action!“ Modul, ohne Gehäuse, lediglich die Platine mit den Chips, bedeckt mit Diskettenlabels. Aber später am Nachmittag änderte der Gewinner seine Meinung und nahm das Spiel „KABOOM!“.

Zum Schluss trennten wir das Netzwerk wieder, aber die Jungs, die an dem zusätzlichen System (das, was eigentlich zu verkaufen und sogar schon von jemandem gekauft worden war, was aber nichts ausmachte) spielten, hatten eine interessante Idee: Zwei Computer den ganzen Tag lang zu verbinden. Vielleicht wollten sie bloß ein wenig länger spielen, aber ich fand die Idee richtig gut. Und so verbanden wir „deren“ System mit einem 800XE auf meinem Tisch, den ich im Moment nicht benutzte, so dass das Spiel den ganzen Tag präsentiert wurde – neben der Tafel auf meinem Fernseher, mit zwei sehr begeisterten Spielern.

Für den Rest des Tages redete, erklärte und antwortete ich endlos, usw. Die Funktion meiner Hardware Erweiterung im XE zeigte ich wahrscheinlich 10 mal. Ich musste mir meinen eigenen 800 XE von den beiden begeisterten Spielern ausleihen, weil die Erweiterung eingebaut war. Das einzige, wozu ich fast keine Zeit zu fand, war selbst im Raum umherzugehen und an anderen Tischen zu schauen. Ich habe eine unfertige, neue Ausgabe des FLOP Magazins gesehen, einige interessante Dinge gab es auch auf dem Tisch von David Spilka und seinen Freunden gleich neben meinem Tisch und ich dachte, ich würde später mal vorbeischauen – was für ein großer Fehler. Sie verließen die Party schon vorher. Am Nachmittag bauten wir das Netzwerk noch einmal auf, so dass auch die Neuankömmlinge es sehen konnten. Unglücklicherweise mussten wir feststellen, dass alle seit dem Morgen Angekommenen schon wieder gegangen waren, so dass es nur die selben 7 Computer wie am Morgen waren.

Zum Schluss fanden wir noch einen XE weit weg im ST-Bereich in diesem Raum (das ist das Ergebnis von Verbindungen zwischen verschiedenen Plattformen…) und Olda überredete den Eigentümer erfolgreich, sein System eine Zeit lang in die XL/XE Ecke zu stellen. Und so spielten wir eine Zeit lang mit den vollen 8 Systemen. Unglücklicherweise wurde der eine XE recht bald wieder abgeholt, weil der Besitzer die Party wieder verließ (wie ich schon vorher kurz erwähnte). Das Spielen mit 8 Rechnern war sehr wichtig für mich, da es die letzte Phase des Softwaretests war. Ich maß die Verhältnisse zwischen Spielgeschwindigkeit und Anzahl der verbundenen Systeme direkt hier auf der Atariada, indem ich einige versteckte Programmroutinen benutzte. Versucht doch mal, die geheime 3-Tasten Kombination zu finden ;-). Das Ergebnis mit 8 Rechnern war im Durchschnitt 15.4, maximal 24 Frames pro Durchlauf, das sind ungefähr 78%, mindestens jedoch 50% der Standardspielgeschwindigkeit. Akzeptabel.

Der Abend nahte und die Zahl der Leute in diesem Raum begann abzunehmen. Kurz nach 18:00 Uhr wollten wir eigentlich zusammenpacken und fahren, aber es ergab sich eine neue Situation. Einige Leute kamen aus einer vorher nicht sichtbaren Ecke, wollten meine Neuigkeiten sehen und redeten mit uns. Ich weiß nichts genaues, aber ich glaube, dass all diese Leute den ganzen Tag an ihren eigenen Tischen gestanden hatten, so wie ich, oder sie hatten irgendwo im ST-Bereich gesessen. Egal, die Idee einzupacken war schnell abgehakt und mein erweiterter XE wurde weitere 3 mal gezeigt.

Während der Diskussionen ergaben sich weitere interessante Dinge. Zum Beispiel Radek Sterba war ziemlich verblüfft, als ich ihm sein eigenes Programm auf einem der neuesten ABBUC Magazine zeigte. Seine Programme werden dort seit einiger Zeit veröffentlicht, aber er wusste nichts davon! (Anm. der Redaktion: Das ist mittlerweile geregelt. Radek Sterba (diesmal richtig geschrieben) ist nun ein vollwertiger Bit Byter) Ich zeigte auch ein Bild im RIP Format auf meinem TV-Bildschirm (Visage 2.4, FIGHT.RIP) und es gab eine unerwartete Reaktion (ganz zu schweigen von den Problemen, wenn man eine Datei von einer Syzygy Diskette mit BiboDos übertragen will). Einige Leute wunderten sich, wie es möglich ist, das Olda’s 800 XL das Bild zeigen konnte – ohne jede Peripherie. Und sie wunderten sich noch mehr als wir erklärten, dass in diesem 800 XL eine 120 MB Festplatte eingebaut war. Aber die meisten Leute waren allein durch das Bild geschockt. Mein Fernseher flackerte besonders wenig im Interlaced Modus und hinzu kam, das nur wenig Helligkeit an diesem dunklen Abend eingestellt war und so sah das Bild wie ein F
arbdruck auf einem Magazin aus. Es war lustig, die Reaktion der ST User anzusehen, die ihre verpackte Hardware zur Tür, die in der Nähe unseres Tisches war, trugen. Einer von ihnen schaute auf unseren Monitor und sein Kiefer sackte vor Verwunderung nach unten. Das Bild wurde ungefähr eine Viertelstunde lang gezeigt, wobei einige Leute Drumherum standen, Fotos machten und ich glaube, sogar eine Videokamera war dabei.

Und außerdem wurde der Tisch sorgfältig untersucht, weil einige dachten, dass es einen versteckten PC oder ST irgendwo geben müsse. In den letzten Minuten kopierten ich das einzige Programm, das ich auf der diesjährigen Atariada bekam: Radek Sterba’s < 1KB Intro „80 Rechtecke“, ziemlich gut für diese Programmgröße. Am Ende trug Zdenek selbst unsere verpackte Hardware zum Auto, es war 21:15 Uhr und wir waren wahrscheinlich die letzten Leute im Raum. Zdenek war sehr entschieden, ich glaube, der Restaurant-Raum war nur bis 21:00 Uhr gemietet.

Nach einer kurzen Erfrischung machten wir uns gegen 21:30 Uhr auf den Weg zurück nach Prag. Aber das ist noch nicht das Ende der interessanten Dinge. Im vergangenen Jahr hatten einige Jungs Probleme mit ihrem fast neuen Auto. Dieses Jahr hatten wir das Pech. Eine halbe Stunde später, etwa 30 Km hinter Prostejov und immer noch 230 Km vor Prag, verabschiedete sich bei einer Geschwindigkeit von 90 Km/h das rechte Hinterrad vom Auto. Der Wagen war plötzlich irgendwie niedrig und laut und so wurde die diesjährige Atariada mit einem Feuerwerk in Form von Funken hinter dem Heck des Wagens, das direkt über die Straßenoberfläche schliff, beendet – es war fast heller Tag auf der leeren Autobahn in der Nacht. Nachdem wir endlich auf der rechten Straßenseite angehalten hatten, überholte uns das Rad auf der rechten Seite (Ihr wisst, das ist nämlich illegal :-)), zog einen schwarzen Abschiedsgummistreifen auf die rechte Wagenseite und verschwand im Dunkel der Nacht. Nach einer halben Sekunde war aus außer Reichweite der Scheinwerfer und wie Olda meinte, würde es die Straße verlassen und die Reise nach Brno und Prag als eigenständiges Fahrzeug machen – sogar mit einer Ladung: Das verhasste Rad hatte die Bremstrommel mitgenommen. Aber ich weiß nicht, wie weit es schließlich reiste. Da waren ca. 2 Km gerade Straße vor uns. Egal, wir haben das Rad nie wieder gesehen, obwohl Olda mit einer Taschenlampe neben der Straße etwa 0.5 Km abgesucht hat. Er suchte eigentlich die nächste gelbe Tafel mit dem Kilometermaß, damit wir unsere exakte Position dem Abschleppunternehmen mit Olda’s Handy durchgeben konnten. Aber das war später. Vorher schaute ich mir den Ort an, wo das Rad eigentlich hingehörte.

Das war anfangs nicht einfach, weil es ziemlich dunkel war. Olda war mit der Taschenlampe und dem Warndreieck die Straße zurück gegangen und ich hatte keine Lampe. Die Lampe war irgendwo zwischen dem Werkzeug im Motorraum und es war nicht einfach, sie ohne Lampe herauszuholen. Sogar der Mond war hinter einigen Wolken versteckt. Als Olda mit der Lampe zurückkam, war es viel einfacher. Und so entdeckte ich, dass die Radnabe durch Materialermüdung gebrochen war und es gab demnach nichts, was wir hätten tun können. Wir hatten zwar so einiges an Werkzeug und Ersatzteilen mit, aber das war einfach zu viel.

Und so wurde eine halbe Stunde später unser Auto voller Atari-Hardware auf einen noch älteren Abschleppwaten aus Brno gehoben und der Weg nach Prag ging weiter (4 Leute auf 3 Sitzen im Abschleppwagen). Den ersten Teil des Weges fuhren wir langsam, mit allen möglichen Lampen in alle Richtungen geleuchtet, aber ohne Erfolg. Das Rad war verloren. Zumindest war es nicht auf der Straße. Wir hatten etwas Angst wegen der schnell vorbeifahrenden Autos. So kamen wir schließlich um 3:30 Uhr in Prag an und unser Weg hat nicht nur länger gedauert, er war auch viel teurer. 9544,- Kc, das sind über 250$, aber hier in der Tschechei bekommen wir weniger Lohn als Arbeiter in den U.S. Zum Glück hatte ich eine Kreditkarte in meiner Tasche. Wenn ich die Reparaturkosten dazurechne, wäre es billiger gewesen, ein anderes, gleichaltriges Auto zu kaufen… Aber wir mussten das Auto schließlich schnell von der Autobahn runterkriegen, alle Läden waren in der Nacht am Wochenende geschlossen und ganz nebenbei, würdet ihr einen Haufen Atari Hardware in einem alten Auto am anderen Ende Eures Landes zurücklassen?

Und so war die „Schräglage“ des Autos vor unserem Haus das sichtbarste Souvenir der diesjährigen Atariada 😉 Wir sehen uns nächstes Jahr in Prostejov! (Ich bin wieder dabei, mit einer neuen Radnabe.)

Jiri Bernasek


Hallo Jiri,
es hat viele Stunden gedauert, diesen 16 KB
langen Bericht zu übersetzten. Da Wolfgang
sowieso immer alles in Deutsch haben will –
könntest Du nicht direkt in Deutsch schreiben?
:-))))
Gruß, Erhard

Hi Jiri,
it took many hours to translate your 16 KB
report. Facing the fact, that Wolfgang always
wants things in German – what about writing
your future reports in German? :-))
Best regards, Erhard

3.5″ Diskettenlaufwerk an XF 551

Es gibt 2 Möglichkeiten ein 3,5″ Diskettenlaufwerk, ohne großen Aufwand, an den Atari XL / XE anzuschließen. Habe es aber nur mit der XF 551 getestet, mit der 1050 müsste es aber genauso gehen, weil kein Umbau in der Elektronik notwendig ist. Es gehen aber nur Original Formatierungen ( S, M, D, XF) !!Kein HD!! Bauteile: 1x Amiga 500 Floppy intern oder extern (DD 720kb) 1 x 3,5″ Floppy Flachbandkabel ( nicht länger als 20 cm !!! da sonst Datenfehler auftreten!!! )

1x 2pol Umschalter 125V / 1A
Möglichkeit 1: Einzelbetrieb
Möglichkeit 2: Dualbetrieb mit Umschalter
Möglichkeit 3: Dualbetrieb mit automatischer Diskettenerkennung (wie AMIGA) und automatischer Floppyumschaltung.

Ist leider noch nicht verfügbar, baue und teste noch. Dieser Umbau wird aber nur mit der XF 551 funktionieren. Umbau: Der Umbau ist ganz einfach, es kann jeder machen, der ein bissel Ahnung mit dem Umgang von Lötkolben hat. So nu genug geschwafelt, los geht’s: Als aller erstes vorsichtig das Floppylauwerk auseinander bauen und die Platine ausbauen. Nun suchen wir die aufgelötete Floppy- Stiftleiste. Wenn wir die Platine umdrehen und uns die Leiterseite betrachten sehen wir 34 Kontakte. Die werden wir benötigen. Bei einer Reihe sehen wir, das 17 Kontakte miteinander verbunden sind. Dies sind Pin 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23, 25, 27, 29, 31, 33. Dies ist die Masse. Hier werden wir nur den Pin 1 anlöten. Denn dies ist bei jedem Floppylaufwerk gleich.

Nun werden wir das Flachbandkabel, das Ihr euch besogt habt bearbeiten. Wenn wir uns das Kabel anschauen haben wir auf beiden Seiten ein 3,5“ Diskettenlaufwerksstecker dran. Einen schneiden wir einfach ab, und den anderen lassen wir so wie er ist. Auf der abgeschnittenen Seite isolieren wir das Kabel vorsichtig ab und verlöten jede Ader. Wir benötigen aber nur jeden 2. Pin vom Flachbandkabel.

Rot = Pin 1
Dann wird in der Reihenfolge
weitergezählt,
2, 3, 4, 5, 6…. usw.
wir benötigen Pin:
1, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34
Pin 1= Masse
Pin 2 – 34 Datenleitungen
Pin 2 und Pin 34 sind auf
der Platinen Rückseite aufgedruckt.

Nun haben wir die Pins abisoliert und verlötet. Jetzt folgt die schwierigste Arbeit, nun müssen alle Pins angelötet wer- den. Bitte keinen Pin vertauschen, dies bekommt Euerer Floppy und Atari schlecht. Lieber 10 mal prüfen ob es richtig ist. Es sollte aber keine Probleme geben mit dem Vertauschen, da wir ja nur jeden 2. Pin haben. Ausnahme Pin 1 aber der ist ja rot. ACHTUNG, Bitte prüft, das Ihr nicht zwei Pins zusammengelötet habt. Dies ist sehr schlecht für Euern Diskettencontroller. Nun müsst Ihr nur noch das Netz anschließen. Entweder Ihr lötet euch die +5V und GND (Masse) direkt an das Amiga Laufwerk oder ihr lötet einen andern Stecker dran.

Anschluss Netzstecker 3.5″ Floppy:

+5V | GND | unbelegt
In der XF551 Floppy ist es auf der Leiterplatte aufgedruckt. Nun noch zur Umschaltung. Wie vorhin schon gesagt, ist es möglich beide Laufwerke zu betreiben. Aber nur das 3.5″ oder das 5.25″ Laufwerk. Hierzu brauchen wir nun den 2-Pol Umschalter.

Ansicht von unten:

1 = +5V zur 5.25″ Floppy
2 = GND zur 5.25″ Floppy
3 = Zuleitung +5V von der XF 551 Platine
4 = Zuleitung GND von der XF 551 Platine
5 = +5V zum 3.5″ Floppy
6 = GND zum 3.5″ Floppy

Achtung Umschalter stimmen nicht immer mit der Polzahl überein. Ich verwende folgende Umschalter: Conrad Elektronik
Miniatur Kippschalter 2-pol Ein/Ein
Bestellnummer: 70 05 41 – 11
Preis: 3.75 DM

Ihr könnt aber auch den billigen nehmen: Conrad Elektronik
Miniatur Kippschalter 2-pol Ein/Ein
Bestellnummer: 70 13 51 – 11
Preis: 1,20 DM

Beide sind im Katalog auf Seite 1011 zu finden. Den Schalter könnt Ihr euch in die XF551 einbauen. So das war es eigentlich schon. Ach so, als Hinweis, falls aus versehen mal ein Floppy nicht gehen sollte, einfach den Umschalter noch mal hin und her schalten, dann geht es. Wenn noch irgendetwas unklar sein sollte, oder ich etwas vergessen habe, dann wendet euch einfach an mich.

Anschrift:
Thomas Kops
Windmühlenstraße 29
D-06231 Bad Dürrenberg
Tel.: 03462 / 211965
Funk: 0177 / 5124757
E-Mail: tk0471ger@gmx.de oder
xx_DJ_xx@gmx.at Chat: www.edencity.de
ich bin da der RaveBoy

Rechtlicher Hinweis
Diese Bauanleitung ist frei von dritten Personen. Die Urheberrechte liegen einzig und alleine bei Herrn Thomas Kops und Herrn Matthias Chronszcz Jedoch erteilen wir jeder Person die Genehmigung diese Bauanleitung egal in welcher Art auch immer zu Vervielfältigen oder weiterzugeben, solange dies KOSTENLOS geschieht. Für kommerzielle Anwendung bedarf es einer zusätzlichen schriftlichen Genehmigung. Alleine dem ABBUC (ATARI BIT BYTER USER CLUB e.V.), in Vertretung von Wolfgang Burger, Wieschenbeck 45, 4352 Herten, ist es genehmigt, diese Bauanleitung kommerziell anzuwenden oder egal in welcher Art auch immer zu verändern.
Mit freundlichen Grüßen
Thomas Kops

Atari/Amiga Messe in Neuss

Am 10. 06 und 11. 06. 2000 war es mal wieder soweit; die alljährlich stattfindende Messein Neuss stand an. Diesmal war es allerdings etwas anders, als sonst. Die Atari- User mussten sich die Messe mit den Amiga- Usern teilen. Da eine Atari-Messe allein wohl nicht genügend Einnahmen; sprich Profit gebracht hätte, schloss man sich mit dem unter Usern ungeliebten Brüderchen zusammen. Da man bei der Amiga-Messe wohl genau so dachte, kam es nun zur ersten gemeinsamen Messe in Neuss. Da ich von Freitag auf Samstag bei meinem Schwager in Monheim übernachtete, fuhr ich so gegen 9 Uhr los; Richtung Neuss. Ohne größere Umwege erreichte ich die Messe, schon gegen 9. 15 Uhr und musste feststellen, dass es erst um 10 Uhr losgeht. Da hatte ich mich wohl etwas im Zeitplan vertan. Es warteten bereits viele User aus beiden Lagern und die Stimmung war auch recht gut. Besonders lustig fand ich die Maskierung einiger Amiga-User. Daran erkannte man die wirklich fanatischen Fans, die ihren Compi wohl auch mit ins Bett nehmen und die Frau oder Freundin auf dem Sofa schlafen lassen. Von Amiga-Mützen mit Amiga- Bällen darauf bis zu selbstgeschneiderten Amiga-Anzügen war alles vertreten. Die Atari-User schienen nicht ganz so verrückt. Mal erblickte ich hier ein T-Shirt, mal da eine Schirmmütze oder einen Pin am Hemd.

Aber das war’s auch schon. Pünktlich auf die Hundertstelsekunde öffnete man dann auch und die Leute strömten in die Halle. Sehr positiv, dass das Gedrängel ausblieb; jeder wartete geduldig in der langen Schlange. Ich hatte mir schon zum Glück direkt bei der Ankunft eine Eintrittskarte besorgt, was mir das Stehen in der Schlange ersparte. Direkt am Eingang hatte sich die Firma Seidel postiert. Hier gab es noch ein paar Spielchen für den ST. Für die 8 Bitter hatte man nur noch ein Spiel da; dieses allerdings in großen Mengen. Hierbei handelte es sich um „Basil, the great Mouse Detectiv“ Ansonsten hatte sich der Seidel auf Soundsysteme spezialisiert. Atari und Amiga-User konnten hier ein paar Aktivboxen für ihren Compi ergattern, oder auch eine komplette Anlage zu recht fairen Preisen. Neben Seidel machte sich die Firma Jüst breit. Nach einem Jahr Abstinenz war man wieder da. Es gab hier einige Atari VCS Module, ein paar Spielchen für unseren XL(aber leider nichts, was ich noch nicht hatte), Lynx Module, sowie einiges für den Atari ST und Amiga. Merkwürdigerweise gab es auch Spiele für Colecovision, MAC und PC. Dann traf man auf den Atari Club aus Köln. Dieser befasst sich aber mit ST, Portfolio, Falcon und Milan. Also für mich nicht so interessant. Dann gab es noch einen privaten Aussteller oder Club. Hier konnte man Atari- Magazine kaufen. Leider nur komplette Jahrgänge und keine einzelnen Ausgaben.

Auch gab es hier noch ein paar XC 12 Programmrecorder. Aber wer hat noch keinen? Dann war auch noch der Atari-Portfolio-Club präsent. Hier gab es das Clubmagazin, sowie diverse CDs und Disketten zu kaufen. Auch konnte man hier gebrauchte POFOs kaufen. Dann gab es auch noch, wie jede Jahr den Stand von der Firma Gross, die und mit Spielen für Lynx und Jaguar beglückte. Dieses Jahr gab es sogar einige günstige Schnäppchen zu erstehen. Auch gab es zum Teil die neuen Jaguar und Lynx- Module aus Amiland. Diese waren natürlich etwas teurer. Aber mancher Sammler griff auch hier zu, vor allem weil es ja nicht allzu viel Neues für Jaguar und Lynx mehr gibt. Als nächstes war da die Firma Peter Denk, die gebrauchte STs, POFOs, Monitore, sowie einiges an Spielen für den ST anbot. Dann war da auch noch Bastian Moritz mit seinem Classic Atari-Magazin. Hier konnte man das Classic Atari abonnieren, sowie einiges an Software erstehen. Auch konnte man hier Druckerpatronen und ähnliches erwerben. Der Atari ST Club war natürlich auch da und hatte einiges an PD Software dabei. Auch konnte man hier Mitglied werden und das neueste Magazin erwerben.

Dann war da noch der Falke-Verlag, mit seinen Magazinen für Atari und Amiga. Hier gab es auch noch Literatur zu erstehen. Dann nicht zu vergessen die Firma MUCS aus Hannover. Hier konnte man deren gesamte Produktpalette erstehen. Von Software für ST und Falcon bis zu Hardware war fast alles vorhanden. ST und Falcon-User wurden hier garantiert fündig. Dann wurde auch noch der Milan großartig präsentiert, was für mich aber nicht
so interessant war. Und last but not least, der wohl interessanteste Stand für uns 8 Bitter. Best Electronics aus Kalifornien, war wie immer mit von der Partie. Und der gute Brad Koda, hatte natürlich einiges im Gepäck. Denn ich hatte vorab jede Menge Module bei ihm bestellt. Darunter auch einige für Andreas Magenheimer und ein paar Freunde von mir. Auf diese Art spart man Steuern, sowie Porto und Verpackung.

Neben unseren Sachen, hatte Brad auch noch viele Collector-Items dabei. Aufkleber, Pins, Atari-Banner und vieles mehr. Auch Jaguar und Lynx-Module hatte er dabei; teilweise recht günstig. Natürlich durften auch die berühmten Atari-Tassen nicht fehlen. Diese fanden äußerst reißenden Absatz und waren schnell vergriffen. Brad hatte auch für manch anderen User, teilweise skurrile Sachen dabei. Da war doch glatt jemand; der hatte für fast 300 Mark ne Tüte voll Papier geordert. Unter anderem mit Atari-Papp-Schnellheftern, ne Original Lochkarte eines ehemaligen Atari-Angestellten, sowie einige Geschäftsschreiben. Tja daran erkennt man den ultimativen Sammler. Auch mancher Amiga-User fand so einiges bei Best, denn die Best-Lightgun und der Best- Trackball funktionieren ja auch auf dem Amiga. Das war’s dann eigentlich für die Atarianer Im großen und ganzen war die Messe recht ordentlich besucht; wie es sonntags aussah, weiß ich nicht. Natürlich waren auch noch viele Amiga-Stände vorhanden, die teilweise auch für ST-User interessante Dinge, wie Software und Joysticks anboten. Ich traf auch einige Bekannte, wie Andreas Magenheimer, Andreas Volpini, Simon Shouten (nebst umwerfend gutaussehender Gemahlin) und ich musste feststellen, dass es auch viele User gibt, die sowohl Atari, als auch den Amiga nutzen. Die sogenannte gutgepflegte Feindschaft kann wohl nicht ganz so groß sein.

The Gambler (Walter Lauer)

Das ATARI Forschungslabor Teil 2

Bennis Experimente „Salz und Eis“

Im Winter streuen wir auf dem Gehweg vor unserem Haus Salz, wenn sich dort über Nacht Eis gebildet hat. Das Eis schmilzt dann und niemand kann mehr ausrutschen. Was passiert da bloß, wenn Salz auf das Eis kommt?

Was wir dazu brauchen:
– Atari Labor aufbauen und einschalten.
– Ein Päckchen Tafelsalz.
– Krümeleis.
– Zwei kleine Trinkgläser, gleich groß.
– Zwei kleine Schälchen.
– Zwei Teelöffel.
– Ein Styroporbecher.
– Eine große Keksdose oder Schale.

Wie wir das machen:
1. Wir nehmen etwa 20 Eiswürfel und zerschlagen sie zu Krümeleis. Eiswürfel dazu in ein Küchentuch einwickeln und fest auf den Fußboden schlagen.
2. Nun füllen wir in beide Trinkgläser Krü meleis, bis die Gläser etwa halb voll sind.
3. Wir stellen die Gläser in die Schüssel.
4. In ein Glas geben wir jetzt einen Teelöffel Salz hinein.
5. Nun rühren wir beide Gläser mit dem Löffel für zwei bis drei Minuten um. Das Eis schmilzt.
6. Nach fünf Minuten ist schon einiges von dem Eis geschmolzen. In welchem der zwei Gläser ist mehr Wasser zu sehen?
7. Wir schütten aus beiden Gläsern vorsichtig das Wasser in die beiden kleinen Schälchen. In welchem Schälchen ist mehr Wasser?

Kannst du nun verstehen, warum bei Eisglätte Salz gestreut wird? Was ich noch dazu wissen will: Wird das Eis durch Wärme geschmolzen? Oder ist da ein anderer Trick? Also, Atari – Labor her und mit dem Temperaturfühler nachprüfen, welche Temperatur Krümeleis und Salz haben. Huh, ist das kalt!!! Also ist hier doch ein Trick dabei! Ob wir mit dem Atari Labor auch das Wetter beobachten können ? Na klar! Als erstes Projekt messen wir die Innentemperatur im Wohnzimmer und vergleichen die Ergebnisse mit der Einstellung der Heizung. Die längste Zeit im Programm ist 24 Stunden. Wir haben immer um 10 Uhr das Labor gestartet. Ergebnis dieses einfachen Versuches ist: Die Absenkung der Heizung über Nacht ist kaum wirksam. Mein Papa hat mir erklärt, dass die Isolierung des Hauses so gut ist. Dadurch hält es die Wärme auch bei abgeschalteter Heizung ziemlich lange. Sobald wir einen zweiten Fühler haben, werden wir auch die Temperatur auf der Terrasse messen. Und dann können wir die Temperaturen innen und außen vergleichen. Anmerkung Das ATARI Lab Starter Kit und das ATARI Lab Light Module sind z.B. unter folgender Internetadresse zu bekommen
http://toronto.planeteer.com/~rsmith/hardware.htm

Benni Lojek

Disks am Ende ?!

by Erhard Pütz
Hallo liebe Atari 8-Bit Freunde. Vor einigen Wochen habe ich angefangen, meine Disketten als Images auf den PC zu kopieren. Dabei habe ich festgestellt, dass einige meiner ältesten Disketten stellenweise nicht mehr richtig gelesen werden konnten. Uuups. Dabei war das doch eine qualitativ hochwertige Marke?! Und jetzt ist die magnetische Aufzeichnung nicht mehr gut genug, um gelesen werden zu können? Dann hab ich mal nachgerechnet und festgestellt, dass die Disketten teilweise älter als 15 Jahre sind. Also ist wohl spätestens jetzt der richtige Zeitpunkt, die Disketten zu archivieren, bevor sie gar nicht mehr gelesen werden können.

Atari Filemanagement (AFM)

 

Programm von Burkhard Rau

Als guten Floppyemulator auf dem PC kann ich SIO2PC empfehlen. Das arbeitet unter MS-DOS auch mit einer nicht nur Standard SIO Geschwindigkeit, sondern funktioniert in WarpSpeed ($10). Damit dauert das kopieren dann auch nicht endlos lange. Als Kopierprogramm benutze ich den Sektorkopierer „Sectorcopy 1.5“ von der Speedy 1050 Systemdiskette. Und weil ich gerne doppelt sicher gehe, habe ich mir noch ein kleines Turbo-BASIC Programm geschrieben, dass eine Quelldiskette mit einem Image vergleicht (fehlerlose Kopie).
(File: compare.tur findet Ihr auf der Magazindiskette))

So, sind jetzt die Diskettenimages zwar auf dem PC, aber so furchtbar übersichtlich ist das ja nun noch nicht. Man kann den Images jetzt zwar schöne lange Dateinamen verpassen, aber was ist denn nun in dem Image drin? Nun, im Magazin 60 wurde der XFD Monitor vorgestellt, ein PC-Programm, welches auf dem Bildschirm nach Anklicken des Images sofort den Inhalt der „Diskette“ anzeigt. Das ist ausgesprochen nützlich, muss man die „Diskette“ doch nicht erst mit dem Atari laden.

An dieser Stelle möchte ich ein weiteres Programm ins Spiel bringen. Es vereint die Funktionen von SIO2PC und dem XFD Monitor. Schaut euch doch mal erst den Bildschirm an:

AFM erkennt selbstständig, ob es sich um eine Atari-DOS, MyDOS oder Sparta-DOS formatierte Diskette handelt. AFM kann 8 Floppylaufwerke emulieren. AFM kann direkt Dateien aus der „Atari-Diskette“ auf den PC exportieren oder eine Datei vom PC auf das Image importieren. AFM kann den vollständigen Diskinhalt als HEX-Dump anzeigen. Die Images der Disketten im linken Fenster können noch in frei wählbare Kategorien (z.B. Spiele, DOS, Doku usw.) unterteilt werden.

Nun, wie aktiviere ich ein Diskimage als Floppy? Ganz einfach per „Drag ’n‘ Drop“
. Man klickt mit der linken Maustaste auf das Image in der linken Fensterhälfte, hält die Maustaste gedrückt und zieht auf eine der 8 symbolischen Disketten. Dort lässt man los und schon ist die Datei zugeordnet. Genial, woll? (Bedankt euch bei Burkhard !) Jetzt muss diese Floppy noch eingeschaltet werden, also einfach einmal die Diskette anklicken. Man kann auch alle Floppies auf einmal aus – oder einschalten, dazu klickt man einfach auf den pinkfarbenen Punkt links von den Floppies.

Nun, warum benutze ich denn SIO2PC statt AFM? AFM kann bislang nur die einfache SIO-Geschwindigkeit und das ist mir für Massenkopieraktionen denn doch zu langsam. Außerdem hat AFM noch einige wenige Fehler. Aber Burkhard arbeitet daran, je nachdem, wie er Zeit hat. Davon hat er, wie wir alle, leider nicht sehr viel – aber es geht voran.

Bezugsquellen:
SIO2PC, aktuelle Version 4.21i
http://www.cswnet.com/~nkennedy/
AFM
http://www.hcrburk.de/

Das Parallel-Bus-Interface Teil 3

Liebe Atari-User!
Herzlich willkommen zu dem dritten und letzten Teil der Artikelserie über das Parallel- Bus-Interface (PBI). In den letzten beiden Artikeln wurde besprochen, welche Signale mit welchen Wirkungen an dem hinteren Bus der XL-Geräte anliegen und wie eine externe Hardware prinzipiell aussehen muss, damit ein angeschlossenes Gerät automatisch vom Betriebssystem des Atari erkannt wird. Wie schon erwähnt, spielt dabei das Signal Math-Pack-Disable (MPD\) eine entscheidende Rolle, da es dafür verantwortlich ist, das interne Mathematik-ROM von $D800 – $DFFF auszuschalten und ein geeignetes ROM einzublenden, wenn das PBI-Gerät über NEUPORT ($D1FF) eingeschaltet wurde. Schauen wir uns nun an, welche Datenstruktur in diesem Speicher stehen muss, damit es zu einer automatischen Erkennung kommt: (siehe Tabelle 1) In den ersten drei Feldern kann man Informationen über die Checksumme und Version des eingeblendeten ROMs ablegen, jedoch werden diese Informationen, genauso wie der Geräte-Typ als auch der Geräte- Name, nicht vom Betriebssystem (OS) geprüft. Der Benutzer kann hier also Daten ablegen wie er möchte.

Korrekt gefüllt sein müssen jedoch alle anderen Felder, da es sonst sehr schnell zu einem Absturz des Systems kommen würde.

$D800: *ROM Checksumme LOW-Byte $D80F: CLOSE-Vektor LOW-Byte -1 $D801: *ROM Checksumme HIGH-Byte $D810: CLOSE-Vektor HIGH-Byte $D802: *ROM Versions-Nummer $D811: GETBYTE-Vektor LOW-Byte -1 $D803: ID-Nummer 1 ($80) $D812: GETBYTE-Vektor HIGH-Byte $D804: *Geräte-Typ $D813: PUTBYTE-Vektor LOW-Byte -1 $D805: JMP ($4C) $D814: PUTBYTE-Vektor HIGH-Byte $D806: I/O - Vektor LOW-Byte $D815: STATUS-Vektor LOW-Byte -1 $D807: I/O - Vektor HIGH-Byte $D816: STATUS-Vektor High-Byte $D808: JMP (4C) $D817: SPECIAL-Vektor LOW-Byte -1 $D809: Interrupt-Vektor LOW-Byte $D818: SPECIAL-Vektor HIGH-Byte $D80A: Interrupt-Vektor HIGH-Byte $D819: JMP ($4C) $D80B: ID-Nummer 2 ($91) $D81A: INIT-Vektor LOW-Byte $D80C: *Geräte-Name (ASCII) $D81B: INIT-Vektor HIGH-Byte $D80D: OPEN-Vektor LOW-Byte -1 $D81C: *unbenutzt $D80E: OPEN-Vektor HIGH-Byte Tabelle 1 : ROM-Vektor Tabelle ($D800- $D81C), mit * gekennzeichnete Felder müssen nicht gefüllt sein     DUMMY ORG $D800 PBITAB DFB $CA,$FE,0 Checksum + ROM-Version DFB $80 ID-Nummer 1 DFB 0 Geräte-Nummer JMP SIOVEC SIO I/O-Vektor JMP IRQVEC IRQ IRQ-Vektor DFB $91 ID-Nummer 2 DEVNAME DFB 'Z Geräte-Name ASCII DFW OPEN-1 HATABS-Eintrag DFW CLOSE-1 DFW GET-1 DFW PUT-1 DFW CLOSE-1 DFW SPECIAL-1 JMP INIT DFB 0 Tabelle 2 : Beispiel PBI-Datenstruktur

Nach einem Reset schaltet das OS jedes (möglicherweise vorhandene) PBI-Gerät über NEUPORT nacheinander an und prüft, ob an den Stellen $D808 und $D80B die Werte $80 und $91 stehen. Falls dies der Fall ist (im Mathe-ROM stehen an diesen Stellen natürlich andere Werte), führt das OS einen Unterprogrammsprung nach $D819 durch, der bei korrekt gefüllten ROM über einen Sprung-Befehl auf die Initialisierungsroutine des PBI-Geräts führt. In diese Initialisierungsroutine können dann z.B. Register initialisiert und der Treiber beim OS angemeldet werden. Schauen wir uns einmal eine PBI-Datenstruktur und ein Stück der INIT-Routine an, die hier exemplarisch angeführt ist: (Tabelle 2)   NEWDEV EQU $E486 Routine zum Eintragen von Treibern in HATABS GENDEV EQU $E48F generische Treiber-Routine für PBI-Geräte DEVMASK EQU $247 dem OS bekannte PBI-Geräte NDEVREQ EQU $248 momentan aktiviertes PBI-Gerät PDIMSK EQU $249 Geräte, die IRQ auslösen dürfen HATABS EQU $31A Tabelle mit Treiber-Informationen CHIDZ EQU $20 Index auf Treiber in Tabelle HATABS * ORG $irgendwo * SIOVEC CLC IRQVEC RTS * * ALS PBI-DEVICE EINMELDEN UND TREIBER REGISTRIEREN * INIT LDA DEVMASK alle momentan registrierten Geräte laden ORA NDEVREQ aktuelles Gerät hinzu’odern’ STA DEVMASK und abspeichern LDA PDIMSK alle Geräte, die IRQ auslösen dürfen laden ORA NDEVREQ aktuelles Gerät hinzu’odern’ STA DEVMASK und abspeichern LDX DEVNAME LDA #GENDEV:H LDY #GENDEV:L JSR NEWDEV STA HATABS+1,x TYA STA HATABS,x ... ... hier können noch geräte-spezifische ... Initialisierungen vorgenommen werden ... RTS OPEN JSR HANDLER ... ... SEC RTS CLOSE JSR HANDLER LDY #1 SEC RTS GET JSR HANDLER ... ... SEC RTS PUT ... ... SPECIAL ... ... HANDLER TAY LDX CHIDZ Index in HATBS laden LDA HATABS,X Treiber-Name lesen CMP DEVNAME mit eigenem Namen vergleichen BEQ HANDLER1 ja wir sind’s ==> PLA falls nicht das richte Gerät, PLA Rücksprungadresse vom Stack holen und mit CLC gelöschtem Carry zurückspringen HANDLER1 TYA

Tabelle 3: Beispiel-Code zur Initialisierung eines PBI-Geräts Da das OS die entsprechenden ID-Nummern findet, führt es einen Unterprogrammsprung nach $D819 aus, der über einen JMP-Befehl auf die Routine INIT geleitet wird. Dort wird zuerst das Byte DEVMASK gelesen, welches alle schon beim OS angemeldeten PBI-Geräte enthält (für jedes Gerät ein Bit). Zu diesem Inhalt odern wir das Bit unseres PBI-Geräts aus NDEVREQ dazu und speichern das Ergebnis wieder nach DEVMASK. Dadurch „weiß“ nun das OS, daß es ein neues PBI-Gerät gibt. Ähnlich dem Byte DEVMASK gibt es auch noch ein Byte namens PDIMSK, in dem alle PBI-Geräte registriert werden, die einen IRQ auslösen können. Welche hardwareseitigen Vorraussetzungen dafür nötig sind, haben wir im letzten Artikel erfahren. Als nächstes lesen wir aus dem ROM den ASCII-Code unter dem unser Gerät, genauer: dessen Treibers, vom OS ansprechbar sein soll. Dies kann im Prinzip jeder beliebige Buchstabe sein, jedoch sollte man nicht willkürlich schon exist ierende Geräte, wie z.B. D: (Diskettenlaufwerk) oder E: (Editor) überschreiben, ohne genau zu wissen, was man da tut. In unserem Beispiel würden wir einen Treiber unter dem Namen “Z” registrieren und zwar durch die OS-Routine NEWDEV.

Dieser Übergeben wir im X-Register den Namen des Treibers und im Y-Register und Akkumulator die Adresse des Treibers. Hier möchten wir den generischen Treiber GENDEV registrieren, der im OS speziell zur Einbindung von Treibern für PBI-Geräte zur Verfügung steht. Die Routine NEWDEV liefert folgende Return-Codes: – Negativ-Bit gesetzt: Die Tabelle der Treiber (HATABS) ist voll, der Eintrag konnte nicht vorgenommen werden. – Carry-Bit gelöscht: Der Eintrag wurde erfolgreich in der Tabelle vorgenommen. – Carry-Bit gesetzt: Den Eintrag gibt es schon, X zeigt auf die Adresse innerhalb der Tabelle HATABS, wo der Eintrag schon existiert.

Im Beispiel kümmern wir uns nicht um die Return-Codes sondern schreiben immer in die Tabelle HATABS unseren Treiber, egal ob es schon einen Treiber unter diesem Namen gab. Daß die Tabelle voll sein könnte, ist so unwahrscheinli
ch, so daß dieser Fall ignoriert wird. Danach könnte noch die Hardware das Geräts initialisiert werden und per RTS springt man aus der INIT-Routine zurück.

Wir haben nun unter einem bestimmten Geräte-Namen (Buchstabe) einen generischen Treiber für PBI-Geräte registriert und dem OS über DEVMASK mitgeteilt, dass es unser Gerät überhaupt gibt. Wie geht dieser generische Treiber vor, wenn er angesprochen wird? Nehmen wir einmal an, ein Basic-Programm würde ein OPEN #2,4,0,“Z:“ ausführen, das ja heißt, auf Kanal 2 soll das Gerät „Z:“ zum Lesen geöffnet werden. Über die Tabelle HATABS findet das OS heraus, dass der generische Treiber für PBI-Geräte zu verwenden ist. Dieser tut nichts weiter als in einer Schleife alle registrierten PBI-Geräte nacheinander einzuschalten und dann über den OPENVekor des PBI-Roms in die entsprechende OPEN-Routine zu verzweigen. Diese Routine muß dann erst einmal prüfen, ob das eingeschaltete Gerät überhaupt für diesen Treiber-Buchstaben das richtige Gerät ist. Dies kann über die IOCB-Speicherstelle $20 (CHIDZ) geschehen, die einen Index auf den Eintrag in der Tabelle HATABS enthält. So kann über LDX CHIDZ und LDA HATABS, X herausgefunden werden, welcher Treiber zu bedienen ist. Wenn das Gerät diesen Treiber nicht bedienen kann, muss es das Carry-Flag löschen und per RTS zurückspringen, damit der generische Handler das nächste Gerät befragen kann. Hat der generische Treiber das richtige Gerät erwischt, so wird die entsprechende Funktion ausgeführt und mir gesetztem Carry-Bit zum generischen Treiber zurückgesprungen.

Anhand des gesetzten Carry-Bits stellt der generische Treiber fest, daß kein weiteres Gerät einzuschalten ist und gibt die Kontrolle an des OS zurück. Die einzelnen Funktionen OPEN, CLOSE, GETBYTE, PUTBYTE, STATUS, SPECIAL, müssen für jeden Treiber, der in HATABS eingetragen ist, entsprechend implementiert werden. Dabei werden Return-Codes wie bei allen Treibern, die über das IOCB angesteuert werden, über das Y-Register zurückgegeben. Alle Werte kleiner $80, insbesondere 1, gelten als erfolgreiche Ausführung, die Werte größer oder gleich $80 werden als Fehler behandelt. Alle Details entsprechen exakt der Treiberprogrammierung für IOCB und werden daher hier nicht näher bespro chen, da fast keine Besonderheiten für das PBI-Interface zu beachten sind. Einzige Ausnahme ist, daß das CIRTIC-Flag vom generischen Treiber gesetzt wird und daher nicht alle OS-Funktionen aktiviert sind, solange man es nicht selbst im Treiber wieder löscht.

Als letztes möchte ich noch die Funktion des SIO-Interfaces und die Interrupt-Fähigkeit besprechen. Kommen wir zum SIOInterface: Ab dem Zeitpunkt an dem in das Register DEVMASK das Bit des entsprechenden PBI-Geräts eingetragen wird, versucht das Betriebssystem bei Ein-/ Ausgaben, die über das SIO laufen, zuerst das PBI-Gerät zu aktivieren und von ihm die Anforderung bearbeiten zu lassen. Daher müssen wir auch hier dafür sorgen, dass das Carry-Bit beim Sprung durch den IOVektor an $D805 und SIOVEC gelöscht wird, da sonst angenommen wird, das Gerät habe das SIO-Kommando erfolgreich bedient. Auf diese Weise könnte man z.B. relativ einfach den P: – Treiber über eine eigene Hardware umleiten und müsste nur die wenigen SIO-Kommandos für den Drucker implementieren und nicht einen kompletten IOCB-Handler wie es in unserem Beispiel angedeutet wurde. Welche SIOKommandos (oder auch IOCB-Kommandos) es gibt, entnehmt Ihr bitte einem Fachbuch. Nun noch ein paar Bemerkungen zum Auslösen von Interrupts durch das PBI-Gerät.

Falls an das Bit des Geräts sowohl in DEVMASK als such in PDIMSK gesetzt hat, schaltet des OS vom Auftreten eines IRQs nacheinander alle in PDIMSK registrierten Geräte ein und liest die Adresse NEUPORT ein. Ist das zugehörige BIT aus NEUPORT gleich eins, dann wird in die Interrupt- Routine des PBI-Geräts verzweigt. Hier kann man dann alles tun und lassen um den Interrupt zu bedienen, zurückgesprungen wird mit RTS. In unserem Beispiel wird zwar der Gerät als interruptfähig registriert, jedoch verzweigt das OS über den Interrupt- Vektor an $D808 direkt auf ein RTS. Wir tun also nicht viel, könnten es aber. Zu bemerken ist noch, dass man ohne eine hardwareseitige Vorbereitung niemals das Bit in PDIMSK setzten sollte, da das Lesen von NEUPORT dann in der Regel $FF ergibt und das OS annimmt, das PBI-Gerät hätte den Interrupt ausgelöst, mit allen Konsequenzen (z. B. würden keine Tastendrücke mehr durchgereicht etc.).

So, nach den drei Artikeln über das PBI, sollten Hard- und Software begeisterte in der Lage sein, sehr kompatible Erweiterungen für den Atari zu basteln. Der Vorteil dieser zugegebenermaßen nicht ganz einfachen Materie ist, dass keine besonderen Speicherstellen belegt werden oder die Treiber von normalen Programmen nicht aufrufbar wären.

Ich wünsche Euch viel Spaß beim Ersinnen der (un-)möglichsten Hardware und würde mich Freuen, wenn es zu Diskussionen über diese Thematik kommen würde. Ich selbst habe ein Interface implementiert, das es ermöglicht, PC-Karten (8-Bit) vom Atari aus anzusteuern, wobei die Treiber und Hardware eben über diese Technik angebunden wurde und damit nach dem Plug & Play – Prinzip funktionieren.

Viele Grüße, Euer
Roland Scholz
Kölner Str. 119
53879 Euskirchen
roland_scholz@web.de

Die RAF zieht um

Ab sofort hat die ABBUC-Regionalgruppe Frankfurt / Main eine neue Homepageadresse, Email-Adresse sowie Email-Adressen für ihre Mitglieder. Auch die Telefon- und Faxnummer hat sich geändert. Die alten Nummern bzw. Adressen werden noch bis Ende Oktober 2000 aktiv bleiben, Ihr solltet aber möglichst nur noch die neuen benutzen.

RAF-allgemein: neue Homepage-Adresse:
http://www.abbuc-raf.de

Fragen zur Homepage:
webmaster@abbuc-raf.de

Bestellungen per Email:
order@abbuc-raf.de

Telefon (möglichst Fax oder Email verwenden):
069 / 95733508
Faxnummer: 069 / 95733507

Postanschrift: Thomas Grasel
Dillenburgerstraße 61
60439 Frankfurt / Main

RAF-Mitglieder:
Thomas Grasel email: tgrasel@abbuc-raf.de
Tel.: 069 / 95733508
Marc Mortara emai: keine
Tel.: 069 / 761294
Harry Reminder email:
hreminder@abbuc-raf.de
Tel.: 069 / 585303
Carsten Strotmann email:
cstrotmann@abbuc-raf.de
Tel.: 069 / 94419790

WAP auf dem Atari XL ?!?

Nun, von WAP hat ja wohl schon jeder etwas gehört. Das ist die furchtbar langsame, teure und grafisch simple Möglichkeit für Handys ins Internet zu gelangen bzw. spezielle Internet-Dienste abzurufen. Doch Hand aufs Herz: WAP hat eine Datenübertragung von 9600 Baud – das kann unser kleiner Atari locker !! Und grafisch bietet WAP simple LCD Grafiken, die unser Atari bestimmt auch beherrscht (er hat mehr Zeilen, höhe- re Au
flösung, etc.).

Nur: Wie funktoniert WAP ?!? Einmal davon ausgehend, das WAP nicht geheim und copyright-geschützt ist (bzw. Lizenzen wi e be i Showview nötig sind) , welche Hardwar e- Erweiterungen benötigt unser Atari 8 Bitter um WAP fähig zu werden ?? Welche Software müsste dafür gecodet werden ?? Also, wenn es über Funk liefe, wäre es kein Problem, siehe ABBUC Magazin 60 „Der Atari als Fernbedienung“. Nur glaube ich nicht so recht, dass WAP via Funk übertragen wird, dann könnten wir in den Atari ja auch ein Radio (bzw. einen Radio- Empfänger) einbauen. Wer mehr Ahnung oder Erfahrung mit WAP hat, der übermittle seine Kenntnisse bitte an die Clubzentrale.

Andreas Magenheimer

Wie funktioniert ein Emulator?

Ich bin ein Arcade-Fan. Ende der 80er Jahre haben sich mehrere Spielhallen von meinen Markstücken ernährt, aber Anfang der 90er kam diese Form der Unterhaltung aus der Mode. Ich ging mit meinem BAFöG sparsam um und zwangsläufig mussten einige Spielhallen schließen.

Sei einigen Jahren gibt es Computer, die so schnell sind, dass sie ältere Computer ‚emulieren‘ können. Und es gibt Programmierer, die haben nichts anderes zu tun, als sich die alten Schaltpläne und Chip- Unterlagen der Arcade-Kisten zu besorgen und damit in jahrelanger Arbeit Emulatoren zu Entwickeln.

Seit dem MAME-Projekt (Multiple Arcade Machine Emulator) sind Emulatoren in aller Munde. Mit einem Mal kann man sich alle alten Spielhallen-Hits ins Wohnzimmer holen. Im frei verfügbaren MAME-Sourcecode ist so ziemlich jeder alte Prozessor und Peripherie- Chip bereits enthalten, und so hat die Emulator-Welle hat auch vor unserem Atari nicht halt gemacht.

Ich bin erst vor kurzem nach vorübergehender Abstinenz (seit 1991) dem Club wieder beigetreten. In Ermangelung jeglicher Atari- Hardware muss ich mein Magazin mit einem Emulator lesen. Da stellt sich für mich als Programmierer die Frage: wie funktionieren diese Dinger eigentlich? Ein Elektroniker wird bei Emulation an ein ‚Spice‘-Verfahren denken, bei dem das Verhalten der Transistoren, Kondensatoren, Widerstände etc. nachgebildet wird. Oder an ein Programm, in dem Logik-Gatter miteinander verschaltet werden, um daraus die Funktionen komplexerer Chips zu bilden. Vermutlich könnten solche Verfahren zum Erfolg führen, wenn man wüsste, wie die Transistoren oder Gatter z.B. in einem Prozessor verschaltet sind. Aber solche Infos findet man weder in einem Schaltplan noch den Unterlagen der Chip-Hersteller. Außerdem benötigt man bei solchen Verfahren sicher die 10000fache Rechenleistung der ursprünglichen Geräte. Ein Pentium hat aber nur die ca. 500-2000fache Rechenleistung eines Atari 800XL.

Netterweise stellen Emulator-Programmierer den Sourcecode ihrer Programme zur Verfügung, so auch für den Atari800Win. (http:// www.cris.com/~Twist/atari800win) Ich habe mir den Code Stück für Stück vorgenommen und die Funktionen auf ein absolutes Minimum reduziert damit der Code leichter lesbar wird. Nachdem 60% des Codes entfallen sind, lag vor mir immer noch ein funktionierender Emu für den 800XL. Aus dem Sourcecode habe ich eine Menge gelernt. Vielleicht interessiert es außer mir noch jemanden, wie ein Emulator funktioniert? Eigentlich ist ein Emulator ein perfektes Handbuch für jeden Chip. Alle Funktionen kann man dort finden, besser als in den Unterlagen der Chip-Hersteller. Vieles versteht man in den Emulator-Sourcen eher als im Handbuch. Jede Funktionseinheit wie Prozessor, Speicher, Grafikchip etc. wird einzeln Emuliert, natürlich in der Programmiersprache C. Der Speicher Beginnen wir mit der einfachsten aller Chips, dem RAM. Ein Atari 800XL hat normalerweise ganze 64 kB RAM.

Für das RAM verwenden wir ein Byte-Array: unsigned char memory[64*1024];  Schon ist der Speicher (fast) fertig. Nun kopieren wir das BASIC-ROM und das OSROM in den Speicher. (Die ROMs sind an anderer Stelle im Code eingebaut):

memset(memory, 0, sizeof(memory)); memcpy(&memory[0xa000], Rom_AtariBas, sizeof(Rom_AtariBas)); memcpy(&memory[0xc000], Rom_AtariXL_OS, sizeof (Rom_AtariXL_OS));  Wenn z.B. der Prozessor aus dem Speicher lesen oder etwas hinein schreiben will, müsste eigentlich eine 'Zuweisung' genügen: ProzessorRegisterA = memory[adresse]; bzw.   memory[adresse] = ProzessorRegisterA;  Aber was passiert, wenn der Prozessor in den Rom-Bereich schreibt? Oder auf eine Adresse schreibt, mit der ein Chip wie PIA, ANTIC oder GTIA angesprochen werden sollte?   Bei jedem Speicherzugriff muss also geprüft werden, was bei diesem Zugriff passiert.  Das geht am einfachsten so: enum { /* ein Datentyp für die drei Möglichkeiten einer Speicheradresse: RAM, ROM oder Hardware   */ RAM, ROM, HARDWARE } memory_attrib[64*1024]; /* für jede Adresse ein Attribut für RAM/ROM/HARDWARE */ Klar, damit sind weitere 64 kB RAM des PC verbraucht. Aber wer wird denn an der falschen Stelle sparen..... Weiter mit dem Initialisieren dieses Arrays: SetAttrib(0x0000, 0x9fff, RAM); /* Fülle diesen Adressbereich mit dem Attribut 'RAM' */ SetAttrib(0xa000, 0xffff, ROM); /* Der Bereich für BASIC- und OS-ROM hat das Attribut 'ROM' */ SetAttrib(0xd000, 0xd7ff, HARDWARE); /* Mit diesen Adressen werden andere Chips angesprochen */ Auf den Speicher wird anstatt mit Zuweisungen nur mit den Funktionen GetByte() und PutByte() zugegriffen: unsigned char GetByte(addr) /* lesen von einer Adresse */ { switch (memory_attrib[addr]){ case RAM: return memory[addr]; case ROM: return memory[addr]; / * lesen aus dem ROM ist selbstverständlich erlaubt */ case HARDWARE: return Read_From_Hardware(addr); /* wird später erklärt */ } } void PutByte(addr, byte) /* schreiben auf eine Adresse */ { switch (memory_attrib[addr]){ case RAM: memory[addr] = byte; break; case ROM: break; /* nichts tun, zugriffignorieren */ case HARDWARE: Write_ To_Hardware(addr, byte); break;/* wird später erklärt */ } }

Damit ist der Speicher im Prinzip schon fertig und die ROM-Chips sind gleichzeitig schon emuliert. Natürlich fehlen noch Möglichkeiten, mit der PIA (Port B) einen Teil des ROMs auszublenden oder das Selbsttest- ROM zu spiegeln. Aber so genau werde ich nicht ins Detail gehen. Wenden wir uns dem bekanntesten Chip zu: dem Prozessor 6502. Der Prozessor Was wohl jeder über den 6502 weiß: er hat einige Register. Dazu legt man sich ein paar Variablen an. In C nimmt man dazu einen ’struct‘, das ist eine ‚Variabelen- Zusammenfassung‘. (Ist eigentlich auch nichts anderes als eine Reihe von Variablen):

struct{
UBYTE rA; /* Accumulator A */
UBYTE rY; /* Index Register Y */
UBYTE rX; /* Index Register X */
UBYTE rS; /* Stack Pointer S */
UWORD rPC; /* Program Counter PC */
struct /* Processor Status Register P */
{ /* dies ist ein bitfeld für die statusflags */
int fC : 1; /* Carry, 1=true */
int fZ : 1; /* Zero, 1=result */
int fI : 1; /* IRQB disable, 1=disable */
int fD : 1; /* Decimal mode, 1=true*/
int fB : 1; /* BRK command,1=BRK, 0=IRQB */
int fG : 1; /* constant, always 1 */
int fV : 1; /* Overflow, 1=true */
int fN : 1; /* Negative, 1=true */
};
}cpu; /* unsere Variable heisst nun ‚cpu‘ */
Die erste Funktion, die der Prozessor ausführt, ist der Reset. Und was macht ein Reset genau? Das hier:
void CPU_Reset(void){
memset(cpu, 0, sizeof(cpu)); /* alle register auf 0 setzen */
cpu.fG = 1; /* dieses flag-bit ist immer 1 */
cpu.rS = 0xff; /* der stack-pointer zeigt auf den stack-anfang */
cpu.rPC = (GetByte(0xfffd) << 8) |
GetByte(0xfffc) ; /* Die OS-Startadresse wird aus ROM gelesen */
}

Jetzt soll der Prozessor einen Befehl lesen und ausführen. Also muss ein Befehlsbyte aus dem RAM/ROM gelesen und der Opcode ausgewertet werden:

void CPU_Step(void)
{ UBYTE instruction;
instruction = GetByte(cpu.rPC); /* Befehlsbyte aus der Adresse lesen, auf die der Programm-Counter zeigt */
cpu.rPC++; /* PC um 1 erhöhen, PC zeigt jetzt auf den nächsten Befehl */
switch(instruction){ /* jetzt müssen alle 256 möglichen Befehle einzeln bearbeitet werden */
case 0x00: Process_Instruction_00();
break; /* Die Bearbeitung der Befehle wird später gezeigt … */
case 0x01: Process_Instruction_01();
break;
case 0x02: Process_Instruction_02();
break;
/* ich schreibe hier natürlich nicht alles einzeln hin. Denkt euch die restlichen 251 Befehle einfach dazu. */
case 0xFE:Process_Instruction_FE();
break;
case 0xFF:Process_Instruction_FF();
break;
}

Was noch fehlt, sind die 256 Funktionen ‚Process_Instruction_00()‘ bis ‚Process_Instruction_ FF()‘, in denen die Befehle wirklich bearbeitet werden. Ist halt etwas Fleißarbeit für die nächsten 10 freien Wochenenden. Die ersten Befehle, die beim Booten des OS bearbeitet werden, zeige ich hier als Beispiel. Der erste Befehl, der im OS-ROM steht, heisst SEI, d.h. Set-Interrupt-Flag:

void Process_Instruction_0x78(void){
cpu.fI = 1; /* Interrupt-Flag auf 1 setzen */
}

O.K., das war trivial. Der nächste Befehl ist ‚LDX #ab‘, d.h. Lade das X-Register mit dem nächsten Byte im Code. Dieser Befehlt tut – wie die meisten Befehle – noch mehr: er ändert einige Flags.

void Process_Instruction_0xA2(void)
{
cpu.rX = GetByte( cpu.rPC); /* Nächstes ‚Befehlsbyte‘ in das X-Register Schreiben */
cpu.rPC++; /* PC um 1 erhöhen, PC zeigt jetzt auf den nächsten Befehl */
cpu.fZ = (cpu.rX == 0) ? 1 : 0; /* wenn X-Register 0 ist, Zero-Flag auf 1 setzen, sonst auf 0 setzen */
cpu.fN = (cpu.rX & 0x80) ? 1 : 0; /* wenn X-Reg. Negativ ist (oberstes bit ist 1), Negativ-Flag auf 1 setzen */
}

Weiter geht’s mit ‚DEY‘, d.h. Y-Register um eins verringern:

void Process_Instruction_0x88(void){
cpu.rY–; /* Y-Register um eins verringern. */
cpu.fZ = (cpu.rY == 0) ? 1 : 0; /* wenn Y-Register 0 ist, Zero-Flag auf 1 setzen, sonst auf 0 setzen */
cpu.fN = (cpu.rY & 0x80) ? 1 : 0; /* wenn Y-Reg. Negativ ist (oberstes bit ist 1), Negativ-Flag auf 1 setzen */
}

Jetzt wird’s interessant: ‚BNE‘ (Branch if Not Equal), d.h springe an eine andere Codestelle, wenn das Z-Flag gesetzt ist.

void Process_Instruction_0xD0(void){
if(cpu.fZ == 1){ /* wenn Zero- Flag gesetzt ist */
cpu.rPC += GetByte(cpu.rPC); /* Addiere das nächste ‚Befehlsbyte‘ zum PC */
}
cpu.rPC++; /* Ein Byte weiter springen, weil dieser Befehl zwei Byte lang ist (instruction-byte + offset) */
}
Noch ein Opcode-Beispiel: ‚PHP‘, d.h. ‚Push
Flags auf Stack‘.
void Process_Instruction_0x08(void){
UBYTE Flags;
UWORD StackAdresse;
Flags = cpu.fC + (cpu.fZ << 1) +
(cpu.fI << 2) + (cpu.fD << 3) + (cpu.fB << 4)
+
(cpu.fG << 5) + (cpu.fV << 6) + (cpu.fN << 7);
StackAdresse = 0x0100 + cpu.rS;
cpu.rS–; /* Stack-Pointer dekrementieren */
PutByte(StackAdresse, Flags);
}

Das sollte als Beispiel für Opcodes genügen. Assembler-Programmierer wissen jetzt schon, wie jeder einzelne Befehl Emuliert wird. Wen es interessiert, der kann im Sourcecode nachsehen.

In den Datenblättern des Prozessors gibt es Tabellen, die jeden einzelnen Prozessorbefehl im Detail erklären. Zu jedem Befehl steht dort, mit welcher Adressierung (Zeropage, Immediate, Indirekt / Indiziert etc.) die Operanden gelesen werden, welche Flags beeinflusst und welche Rechenschritte durchgeführt werden etc. Um die 256 Befehle zu emulieren, muss praktisch nur das Datenblatt umgesetzt werden. Aber im Datenblatt gibt es leere Felder. Das sind ‚illegale‘ Opcodes, bei denen der Prozessor- Hersteller nicht verrät, was der Prozessor bei diesem Befehl tut. Aber irgendwas tut der Prozessor garantiert bei jedem Befehl. Um Herauszufinden, was bei diesen Opcodes wirklich geschieht, muss man das auf einem echten Atari ausprobieren. Bei einigen dieser Befehle bleibt der Prozessor sofort stehen, ein Scherzbold hat das mal als ‚CIM‘-Befehl bezeichnet, (d.h. Crash Immediately, stürze sofort ab). Andere Befehle tun merkwürdiges, z.B. ‚SKW‘ (Skip Word, überspringe zwei Byte), ‚ASO‘ (ASL and ORA, erst Arithmetic-Shift-Left, dann Ver-odern mit dem Accu). Etwa 100 Befehle muss man auf diese Art ermitteln. Dabei steht noch nicht einmal fest, ob wirklich jede 6502-CPU identisch arbeitet. Es ist aber möglich, dass der eine oder andere Atari- Programmierer diese Befehle benutzt hat. (Vermutlich jedoch nicht den ‚CIM‘-Befehl )

Deshalb muss das Prozessor-Verhalten auch für diese Befehle korrekt nachgebildet werden. Bisher haben wir die Bausteine, die synchron mit jedem Prozessortakt ihre Arbeit machen, ignoriert. Auf einem Multitasking- System wie Windows könnte man versuchen, jeden Chip in einer eigenen Task zu emulieren, damit alle Chips quasi gleichzeitig arbeiten. Aber dann laufen die Chips nicht mehr genau so synchron wie in einem echten 800XL. Was tun? Eigentlich müsste man mit jedem Quartz-Takt jede einzelne Chip-Emulation auch einen Takt arbeiten lassen. Aber wie viele Töne macht ein POKEY mit einem Quartz-Takt? Wie viel Teile eines Befehls arbeitet eine 6502 ab? Auf diese Weise wird man das Problem nicht lösen können. Man muss etwas von der ‚exakten‘ Emulation abweichen. Der Bildschirmaufbau findet in konstanten Abständen statt. Auf einem PAL-System wird alle 20 ms (50Hz) ein neues Bild erzeugt. (Auf einem NTSC-Gerät ist die Taktierung etwas anders) Würden die Programme ein exaktes Takt-Raster voraussetzen, könnten manche Programme nur auf NTSC oder nur auf PAL-Geräten arbeiten. Es genügt tatsächlich für fast alle Programme, den Bildschirmtakt als Maßstab zugrunde zu legen.

In 20 ms arbeitet unsere 6502 1,77MHz/50 = 35400 Takte. Um zu kontrollieren, wie viele Takte die CPU abarbeitet, muss man natürlich wissen, wie viele Takte jeder Befehl benötigt. Dazu legt man ein Array an, das zu jedem Opcode die Anzahl der Arbeitstakte enthält, die der Prozessor zur Abarbeitung benötigt:

const int cycles[256] =
{/* 0 1 2 3 4 5 6 7 8 9 A B C D E F */
7, 6, 2, 8, 3, 3, 5, 5, 3, 2, 2, 2, 4, 4, 6, 6,
/* 0x */
2, 5, 2, 8, 4, 4, 6, 6, 2, 4, 2, 7, 4, 4, 7, 7,
/* 1x */

und so weiter…
};
Die Bearbeitung des Programms erfordert also diesen Aufruf:

void Go_CPU(int nCycles){
while (nCycles > 0){ /* solange noch Prozessor-Cyclen auszuführen sind …*/
UBYTE instruction;
instruction = GetByte(cpu.rPC); /* Nächsten auszuführenden Befehl lesen */
nCycles -= cycles[ instruction]; /* Für diesen Befehl werden cycles[instruction] Takte benötigt */
CPU_Step(); /* führe diesen einzelnen Befehl aus */
}
}
Die Grafikprozessor-Emulation ruft nach jedem Bildschirmaufbau die CPU auf:

Go_CPU(35400); /* Führe 35400 Prozessortakte aus */

Soviel zur Emulation des Prozessors. Peripheriechips Der Prozessor greift hin und wieder in den Speicherbereich der anderen Chips. Bei einem Speicherzugriff wird dazu die Funktion Read_From_Hardware(addr) bzw. Write_ To_Hardware(addr, byte) aufgerufen, siehe Funktion GetByte() und PutByte().

UBYTE Read_From_Hardware(UWORD
addr){
switch (addr & 0xff00) { /* nur oberes Byte auswerten */
case 0xd000: return GTIA_GetByte
(addr);
case 0xd200: return POKEY_GetByte
(addr
);
case 0xd300: return PIA_GetByte
(addr);
case 0xd400: return ANTIC_GetByte
(addr);
}
return 0xff; /* Keine Hardware und kein RAM an dieser Adresse vorhanden */
}

Die Funktion Write_To_Hardware() sieht sinngemäß gleich aus, es gibt lediglich den zweiten Parameter ‚byte‘. Wie man sieht, wird nur das obere Adresse- Byte ausgewertet. Zur Vereinfachung der Hardware werden im Atari nicht alle Adressleitungen vollständig dekodiert. Jeder Chip wird dadurch mit einem Adressbereich von 256 Byte angesprochen, obwohl z.B. die PIA nur ganze 4 Byte des Adressbereichs benötigt. Unter der Adresse 0xd300 wird das gleiche PIA-Register angesprochen wie unter der Adresse 0xd304 oder 0xd3f8. Eigentlich könnte man mit 256 Adressen 64 PIA-Chips ansprechen. Der GTIA benötigt 0x20 Bytes Adressraum, mit 256 Bytes könnte man 8 Chips ansprechen. Erinnert sich jemand an die Bauanleitung, um mehrere GTIAs in einem Atari einzubauen? Dort wurden weitere Adressleitungen dekodiert, um den zweiten GTIA anzusprechen. Fahren wir mit dem einfachsten der Chips fort.

Die PIA
Die PIA hat sechs Register, die natürlich als Variablen emuliert werden:
UBYTE PACTL; /* Port A Control-Register */
UBYTE PBCTL; /* Port B Control-Register */
UBYTE PORTA; /* Port A */
UBYTE PORTB; /* Port B */
UBYTE PORTA_mask = 0x00; /* In/Output Einstellung für Port A */

/* default: alles als Input eingestellt */
UBYTE PORTB_mask = 0x00; /* In/Output Einstellung für Port A */

Die Register PACTL und PBCTL sind direkt les- und schreibbar. Wenn in einem Control- Register das Bit 0x04 auf 0 gesetzt ist, wirkt ein Zugriff auf eine Port-Adresse nicht auf den Port selbst, sondern auf das zugehörige Mask-Register. So lassen sich auch die Mask-Register lesen und schreiben, mit denen In/Outputrichtung der Ports eingestellt werden. Die vorhin angesprochene Funktion PIA_GetByte() sieht vereinfacht so aus:

UBYTE PIA_GetByte(UWORD addr){
switch (addr & 0x0003u) {/* nur die unteren zwei Bits der Adresse betrachten */
/* PORTA */ case 0: return (!(PACTL &
0x04)) ? PORTA_mask : Joystick_Read();
/* PORTB */ case 1: return (!(PBCTL &
0x04)) ? PORTB_mask : (PORTB &
PORTB_mask);
/* PACTL */ case 2: return PACTL;
/* PBCTL */ case 3: return PBCTL;
}
}

Und die Funktion PIA_PutByte(), ebenfalls etwas vereinfacht:

void PIA_PutByte(UWORD addr, UBYTE
byte){
switch(addr & 0x0003u){ /* nur die unteren zwei Bits der Adresse betrachten */
case 0: (!(PACTL & 0x04)) ?
PORTA_mask = byte : Joystick_Write();
break;
case 1: (!(PBCTL & 0x04)) ?
PORTB_mask = byte : PORTB_handler (byte); break;
case 2: PACTL = byte; break;
case 3: PBCTL = byte; break;
}
}


Hinter Port A verbergen sich die Joystick- Anschlüsse. Der PC hat keine digitalen Joysticks, aber in der Funktion Joystick_Read() kann man z.B. die analogen PC-Joysticks auslesen und einen Wert zurückliefern, der den Atari-Joysticks entspricht. Vielleicht baut sich ja jemand eine Hardware, an die man echte Atari-Joysticks oder andere Hardware anschließt. In diesem Fall macht auch die Funktion Joystick_ Write() einen Sinn, denn am echten Atari kann man über die Joystickports nicht nur die Joyst ickst e l lung lesen, sondern auch Signale ausgeben und damit z.B. Relais schalten. Andernfalls bleibt die Funktion Joystick_Write() einfach leer. Port B ist stets als Output eingestellt und wirkt auf den Speicher. Man kann damit z.B. das Selbsttest-ROM oder das BASIC-ROM abschalten. Diese Sachen verbergen sich hinter der Funktion PORTB_handler(). Und was passiert, wenn ein Programm Port B als Input konfiguriert? Wie verhalten sich dann die ROMs? Eigentlich müsste man das am echten Atari ausprobieren, aber was soll dabei schon sinnvolles Rauskommen? (Zugegeben, ganz richtig ist das alles nicht. Aber es geht ja nur ums Prinzip.) … und so weiter

Wichtige Teile fehlen noch: Grafik, Sound, Tastatur, Serial I/O. Aber ich will ja nur das Prinzip der Emulatoren erläutern. Vielleicht schreibt jemand von euch etwas über die Emulation eines anderen Chips?

Ach ja: wenn der ‚kastrierte‘ Code jemanden interessiert, bitte kurze Mail an:
‚Robert.T-Online@post.com‘.

HEISSER Atari-Herbst

Das Sommerloch und die Urlaubszeit sind vorbei. Die schädlichen Einflüsse der Sonnenstrahlen auf alte Monitore schwinden rasch und es ist Zeit, die Staubschutzhülle vom XL herunterzunehmen. Tief Luft holen, Zentralschalter auf EIN und – uuuiiiihhh! Der Lüfter des Minitowers meldet sich als Erster, danach Festplatte, kleine Floppy, große Floppies. Jetzt ist das 850 dran und danach der XL. Ein Pfeifen, der RS-Treiber ist geladen. Jetzt von der Festplatte booten und der Monitor meldet sich mit dem vertrauten Einschaltbild, die Hochspannung knistert und meine Finger wissen immer noch blind den Weg zu den Funktionen in Mini Office II. Ja, das ist noch Computergefühl: Jedes Gerät kann akustisch auf einwandfreie Funktion überwacht werden und keine Bluescreens erscheinen – toll! Es bewegt sich wieder etwas in ATARIDeutschland.

– Unconventional 2000 vom 1.-3. September in Lengenfeld,
– Jahreshauptversammlung am 28. Oktober in Herten und
– Elmshorner Computertage mit dem ABBUC-Stand am 4. und 5. November,
das sind die großen Veranstaltungen. Und im Dezember könnte mancher Bit Byter Kindern oder Enkeln ein nettes Weihnachtspräsent „Clubmitgliedschaft plus XL“ auf den Gabentisch legen. Dazu regionale Treffs, die im Magazin und auf der Web-Seite veröffentlicht werden. Von Bit Bytern für Bit Byter – ABBUC, der Userclub zu Mitmachen! Nach wie vor sind wir der Mitgliederstärkste ATARI 8-Bit Club weltweit. Das muss man sich ab und an mal auf der Zunge zergehen lassen: Weltweit!!!

1. Pflege der ATARI-Geschichte in Deutschland!
Damit sich das nicht ändert, suchen wir Bit Byter für folgende Projekte: Das Sondermagazin #27 bietet ein interessantes Essay zur Geschichte von ATARI. Wer sich schon mal mit dem Erschließen von Quellen zu diesem Thema befasst hat, weiß, wie schwer verlässliche Informationen zu bekommen sind. Das Internet bietet auch hier eine fast nicht mehr zu überschauende Anzahl an privaten und gewerblichen Webseiten, die den XL und seine Verwandten zum Thema haben. Eine Webseite, die m.E. besonders aus dieser Vielfalt hervorragt, ist THE ATARI HISTORICAL SOCIETY (AHS) unter http://www.atari-history.com). Die AHS bietet eine umfassende Dokumentation zur Geschichte der Firma ATARI und hat starkes Interesse an der „Europäischen Kapitel“ dieser Erfolgsstory. Bisher sind dazu nur Quellen aus Großbritannien (GB) eingear- beitet worden. Curt Vendel (USA) und Karl Morris (GB) sind die Initiatoren dieser tollen Webseite. Derzeit sind 5 Autoren und 77 ehemalige ATARI-Mitarbeiter als freie Autoren an diesem Projekt beteiligt. Gesucht werden nun ABBUC-Mitglieder, die bereit wären, ein wenig zur europäischen (also deutschen, belgischen, niederländischen, tschechischen, polnischen usw.) Geschichte von ATARI beizutragen. Besonders gefragt sind hier natürlich ehemalige Mitarbeiter von ATARI Deutschland, Benelux etc., die bereit wären, Dokumente, Fotos und anderes
Material aus ihrem privaten Fundus bereitzustellen. Wer bereit zur Mitarbeit ist, Kontakte zu ehemaligen Mitarbeitern oder Zugang zu anderen Quellen hat, kann sich für den ABBUC an diesem Projekt beteiligen. Geplant ist ein entsprechendes Link über die AHS auf unsere Homepage. Also interessierte ATARI-Freaks, bittet meldet euch in der Clubzentrale!

2. Softwaremuseum
Trotz Flohmärkten, Webseiten und privaten Kontakten wird es immer schwieriger, Softwaretitel im Original mit Anleitung und Verpackung zu bekommen. Mancher ehemals große Softwareanbieter existiert nicht mehr, andere wurden als Marke aufgekauft oder die Produktionsabteilung für 8-Bit-Computer wurde schlicht eingestampft. Natürlich ist fast jedes für 400/800 oder XL/XE produzierte Programm irgendwann als Kopie oder als File in Umlauf gekommen und auch heute noch über entsprechende Quellen zu bekommen. Doch schöner und interessanter sind natürlich Originale. Gesucht werden für dieses Projekt Bit Byter, die bereit sind, mit Herstellern und Vertreibern der alten Software Kontakte zu knüpfen und ein komplettes Original sowie eventuell die Rechte zum Vertrieb als Public Domain oder Shareware zu bekommen und damit und mit Spenden von Bit Bytern eine Sammlung auf die Beine zu stellen. Auf diese Weise wäre es möglich, eine für alle Bit Byter umfassende Softwarebibliothek aufzubauen. Andernfalls verschwinden immer mehr tolle Programme in den Nebeln der Zeit. Wer hat z.B. Kontakt zu dem Programmierer von StarTexter, einem der besten 8-Bit- Textprogramme? Die Rechte an dem Programmpaket sind nach Auskunft vom Sybex- Verlag an den Autor zurückgegangen. Es wäre toll, dieses Programm an neuere Anforderungen auf dem XL anpassen und weiter vertreiben zu können.

Oder die Austro-Programme oder – oder –

3. Jahreshauptversammlung des ABBUC in Herten
Interessierte Bit Byter – bitte meldet euch in der Clubzentrale! Für den 28. Oktober werden gesucht: Aussteller, Verkäufer von Hard- und Software, Vorträge über ATARI-Themen, Programmierer für Live-Projekte und was immer ihr sonst selbst zeigen, tauschen oder verkau wollt. Bitte meldet euch in der Clubzentrale an, wenn ihr einen Stand benötigt.

4. ECT – Elmshorner Computertage
Der ABBUC wird mit einem Stand im Bereich des Computermuseums vertreten sein. Gezeigt werden Hard- und Softwareklassiker, Infomaterial und einige Schmankerl. Für den 4. und 5. November werden noch Helfer, Aussteller und interessierte Bit Byter gesucht. Bitte meldet euch in der Clubzentrale. Alle Bit Byter im Norden Deutschlands sollten sich an diesem Wochenende mal zu einem Ausflug nach Elmshorn aufraffen. Es lohnt sich!

5. Digitale Bibliothek
Bereits seit 3 Jahren bin ich dabei, Literatur zum Bereich ATARI 8-Bit zu digitalisieren. Im Gegensatz zu ähnlichen Projekten im Internet wandle ich Handbücher und Bedienungsanleitungen sowie Bücher per OCR in Texte um, dagegen werden Magazine und Zeitschriften sowie Kataloge und Werbebroschüren komplett, also mit allen Anzeigen, eingehefteten Infos, Bildern, Grafiken und Photos mit 600 dpi gescant und gespeichert. Aufgrund dieser hohen Datenmenge dauert es immer eine gewisse Zeit, bis neue Ergebnisse vorliegen. Da es genug Quellen dieser Art aus dem englischen Sprachraum im Internet gibt, habe ich den Schwerpunkt auf die deutsche Literatur gelegt. Damit die digitale Bibliothek vor allem im Bereich der Magazine und Zeitschriften vergrößert werden kann, bitte ich um leihweise Überlassung von möglichst gut erhaltenen Exemplaren folgender Quellen:
Homecomputer
Happy Computer
Computer Kontakt
P.M. Computerheft
ANALOG
ANTIC
ATARImagazin
Page 6
New ATARI User


6. Public Domain Sammlung
Jede andere Quelle wie z.B. CHIP ist ebenfalls interessant, sofern sie Beiträge zu den kleinen ATARIs enthält. Natürlich ist Hilfe jeder Art immer willkommen. Auf der JHV im Oktober werden einige Ergebnisse zu sehen sein. Wer z.B. das Handbuch zum 850 Interface braucht, kann es sich von meiner Homepage http://home.t-online.de/home/wgbl2/ MyATARI.html herunterladen. Andere werden bald folgen. Keine Sammlung ist so umfangreich, dass man nicht noch neue Programme hinzufügen könnte! Also, schickt mir alles, was in den Bereich PD und von Rechten Dritter frei ist in irgendeiner Form.

 

ABBUC e.V. PD-Neuheiten

581 COMPY-SHOP ATARI-KATALOG #1 ED/2S
Die allererste Diskausgabe des bekannten Compy-Shop-Katalogs von Peter Bee & Co aus 1988. Vorgestellt werden Speedy 1050, Mini-Speedy, CS-Speichererweiterungen, BIBO-Assembler, BIBO-DOS, das Compy-Shop-Magazin, Kyan PASCAL 2.02, Kyan PASCAL Tooldisks, CS-Druckerinterface, BIBOBurner, Schreibschutzschalter für 1050, Hypra-Disk-Editor für DD, CS-Editor, XL-Art, MS-Formatter, Test über deutsche Textverarbeitungen, Test XF 551, Test XE Game System, umfassende Preisliste der damals lieferbaren Artikel für den XL/XE sowie einige interne Informationen. Als Programme enthält es Hypra-Disk-Editor und CS-Editor. Eine qualitativ auch heute hervorragende Produktion.

582 COMPY-SHOP-MAGAZIN #1 ED/2S
Die allererste Ausgabe des bekannten CSM von Februar 1988. Neben allerlei internen Geschichten Infos zur Entstehung des CSM. Des weiteren Artikel zu ‚Sterben der kleinen ATARIs’ (1988!!!), Inside BIBO-DOS 1, Schreibschutzschalter 1050, Vorstellung des ABBUC !!!, Versionen der Speedy, XF 551, Turbomodul 1050, Spieltests, CS-Preisliste. Der CS-Editor ist wie immer dabei.

583 COMPY-SHOP-MAGAZIN #2 ED/2S
Lasst euch nicht vom Nummernsalat der ersten Ausgaben verwirren. Dies ist CSM #2, Ausgabe 3/88 vom April 1988. Ja, manchmal ging es im ATARI-Land kunterbunt wie in Bullerbü zu. Artikel: Hobbytronic 1988, Tipps zur 1050, Satire zum Umgang mit Druckern, Tipps zu Hacker, CS-Editor-Update, Spieletests, Datenkompression, EPROMs, PASCAL Programmieren 1, Inside BIBO-DOS 2, Speedy 1050, Leserbriefe mit Antwortspiel und die aktualisierte Preisliste.

584 COMPY-SHOP-MAGAZIN #3 ED/2S
Dieser Zahlen-Hickhack. Ist aber auch egal – dies ist #3 vom April 1988. Die wesentliche Neuerungen dieser Ausgabe sind die erstklassige Druckroutine und das Einbinden von Farbgrafiken in die Textteile. Alles kann auf dem Drucker ausgegeben werden! Artikel: Internes, CeBIT 88, Inside BIBO-DOS 3, Tipps zu StarTexter, Umgang mit Farben, Anwendung Hypra-Disk-Editor, Formate der XF 551, Hardware-Reset für XL/XE, Zahlensysteme für Computer, XIO-Befehl 1, PASCAL Programmieren 2, Hard- und Softwareteste, Preisliste. Dazu als Programm der Hypra-Disk-Editor und einige BASIC-Demos, darunter 2 Updates für den StarTexter.

585 COMPY-SHOP-MAGAZIN #4 ED/2S
Ausgabe vom Mai 1988. Neu ist die Anpassung des Druckertreibers für IBM-kompatible Drucker. Artikel: Archimedes und sein RISC-Prozessor, Mini-Speedy, Inside BIBO-DOS 4, Tipps zum Umgang mit DOS, Vorstellung des ACT Bremen, Flohmarktecke, XIO-Befehl 2, PASCAL Programmieren 3, Display List 1, Grafikstufen des XL/XE, Softwareteste, Preisliste und Demos in BASIC u.a. zur Display List.

< p class="MsoNormal" align="left">ABBUC e. V. – Public Domain Software-Bibliothek
c/o Walter Lojek – Esinger Steinweg 98c – 25436 Uetersen

 

Umsetzung des Print-Magazins zu Text/HTML
Scannen, Layout, HTML Andreas Bertelmann
Rohdaten als PDF, Grafik Wolfgang Burger