ABBUC Magazin 080


IMPRESSUM
© 2004 Atari Bit Byter User Club e.V.
C/O Wolfgang Burger, Wieschenbeck 45
D-45699 Herten Tel. +49 2366 39623
Mail wolfgang@abbuc.de
Eingetragen beim Amtsgericht Recklinghausen unter Nr.: VR 1421
Kreissparkasse Recklinghausen, Konto Nr.: 54 000 468
(BLZ 426 501 50)
Das Atari Bit Byter User Club Magazin erscheint ¼Jährlich. Jeweils
½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

Inhalt

Seite 3 Hardware mit Software Teil 4
Seite 3 ABBUC e.V. # 80 1. Quartal 2005
Seite 4 Spieletest mit USB Lenkrad
Seite 6 Regeln Softwarewettbewerb 2005
Seite 7 Regeln Hardwarewettbewerb 2005
Seite 10 ATARI 8 Bit Boot CD´s
Seite 12 A-Track
Seite 16 ATEAM
Seite 18 ATARI USB
Seite 19 Wie man einen USB-Treiber schreibt
Seite 22 Wie man ein Spiel für USB Geräte patcht
Seite 24 ABBUC: Projekt Engl
Seite 27 ATARI XL/XE RAMdisk Info
Seite 29 ATARI Historie
Seite 30 Dordrecht 2005
Seite 32 PD-Neuheiten

Hardware mit Software Support oder
Software mit Hardware-Support Teil 4

So, dies ist nun endlich der letzte Teil dieser Serie. Heute geht es um die Themen CX85 Support und Touch-Tablet/Maltafel Support. Los geht’s: 7) Welche Programme haben einen CX85 Modus ?
* Bombdown (Roemer of Uno)
* The Bookkeeper (Atari)
* Multi Mouse Management (PD)
* Ball Harbour (Zong 8/1992)
* The Big Quest (Zong 7/1992)
* Blob (Zong 2/1992)
* Bomber Jack (KE-Soft)
* Catch (Zong 6/1992)
* Code table (Zong 11+12/1993)
* CX85-Driver (Zong 7+8/1994)
* CX85-Keycodedriver (Zong 7+8/1995)
* Donald (von KE-Soft)
* Drag (von KE-Soft)
* Dragon Fire (Zong 1/1993)
* Gravitar (Zong 4/1992)
* Hungry Goblin (Zong 5/1992)
* Invaders (Zong 5+6/1993)
* Joshi (Zong 3+4/1993)
* Lasermaze (von KE-Soft)
* Lost in the Antarctic (Zong 2/1992)
* Mampfman (Zong 8/1992)
* Minipac (Zong 3/1992)
* Minipac 2 (Zong 6/1992)
* Money Raider (Zong 2/1992)
* Monster Tracking (Zong 9/1992)
* Numtris (Powersoft/Drachensoft)
* Oblitroid (von KE-Soft)
* PacMan (Zong 11/1992)
* Schlumpf/Smurf (Zong 5/1992)
* Slurp (Zong 3/1992)
* Techno Ninja (von KE-Soft)
* Transsylvania (Zong 3+4/1993)
* Viro-Mania (Zong 2/1993)
* Zador XL (von KE-Soft)
* Zador II (von KE-Soft); – …
und wohl noch viele weitere Games von KE-Soft, Powersoft, Power per Post und anderen…

8) Welche Programme haben einen Touch Tablet Modus?
* Atari Artist (cart, Atari) Grafik-Programm
* Pixel Artist Deluxe 1.3 (disk, PD) Grafik- Programm
* The Brundles (disk, KE-Soft) Lemmings clone
* Musorqua (disk, Analog Computing) educational program
* UPN calculator (disk, PD) Taschenrechner mit „umgekehrter poln. Notation“
* Multi-Mouse-Management (disk, PD) versch. Treiber für div. Eingabe-Geräte
* und weitere Programme (an die ich mich jetzt nicht erinnere)

Im Abbuc Magazin Nr. 78 erschien übrigens ein universelles Hardware-Testprogramm von Florian Dingler – damit kann man ja alle genannten Eingabe-Geräte mal auf deren Funktionsfähigkeit hin testen. Jetzt kann ich eigentlich nur noch hoffen, dass ihr mit den endlos langen Infos etwas anfangen konntet. Wenn nicht, dann eben nicht (ihr hättet ja auch was sagen können). Man kann halt nicht immer alle Atarianer zufrieden stellen.
Bis demnext,
Andreas Magenheimer

SPIELETEST

WGL Spieletest
Alte Software auf neuer Hardware Man nehme alte, bewährte Spieleklassiker, wie z. B. M.U.L.E. oder Pole Position und patche sie für neu erhältliche Hardware für unseren ATARI, wie z. B. das Multijoy-Interface oder die USB Cartridge. Dies war 2004 der neue Trend im Spielesektor. Herausgekommen ist neuer, alter Spielspaß. Pole Position mit USB-Lenkrad zu spielen war auf der JHV 2004 die Sensation. Die RAF baute einen Stand auf und demonstrierte mit dem gepatchten Pole Position eindrucksvoll ihre Entwicklung, die USB Cartridge. Fast die gesamte Zeit war der Stand von Spielwilligen und Neugierigen dicht umlagert. Es kam richtig Spielhallen- Atmosphäre auf.

Das Wiesbaden Gaming Lab ließ es sich natürlich nicht nehmen, diese Kombination auf ihrer Party am 30.10.04 ausführlich zu testen. Cartridge und Lenkrad stellte die RAF für den Test zur Verfügung. Die „normale“ Joystick-Version ist natürlich schon ein Klassiker und hat von uns im Test die Höchstpunktzahl bekommen (5 Sterne). Mit der Zeit stellte sie aber keine sehr große Herausforderung mehr dar. Das zeigte sich auch auf dem 6. Spieltag der ABBUC Bundesliga: nach relativ kurzer Zeit hatten mehrere Spieler die Höchstpunktzahl erreicht und alle anderen lagen nur kurz dahinter. Anders bei der gepatchten Lenkrad- Version: die ersten Versuche landeten am nächsten Schild, Auto oder sonstigen Hindernissen, auch nach mehreren Stunden des Testens kamen wir bei weitem nicht an die Highscores des Bundesligaspieltages ran (Lenkrad: 59450 Punkte von Mad Butscher; Joystick: 66500 Punkte von Dietrich).

Hauptproblem bei der Steuerung war die digitale Umsetzung des analogen Lenkrades. Das heißt, egal ob man das Lenkrad voll einschlägt oder nur ein bisschen antippt, beim Auto hat man immer denselben (Voll-)Einschlag. Alles in allem eine neue Herausforderung. Deshalb unsere WGL-Wertung:
Pole Position (mit Patch für USB-Lenkrad): * * *
* * (5 von 5 Sternen)

Spiel USB -Gerät Treiber
Trailblazer Logitech Rumblepad 2 USB Logitech Rumblepad Driver
Boulder Dash 1 Logitech Rumblepad 2 USB Logitech Rumblepad Driver
Robotron 2084 Logitech Rumblepad 2 USB Logitech Rumblepad Driver
Pole Position Thrustmaster Nascar Pro Digital 2 Steering Wheel;

Logitech WingMan Formula GP Steering Wheel

Wheel Driver

 

Logitech Wheel Driver

Den Pole Position Patch erstellte cas von der RAF. Inzwischen erstellte cas noch für andere Spieleklassiker Patches. Die bisher gepatchten Spiele zeigt die folgende Auflistung: Die neuesten Informationen über das USB Projekt findet ihr hier:
https://sourceforge.net/project/showfiles.php?group_id=111428
http://www.microusb.org/

Für das Multijoy-Interface von Raster/C.P.U. waren bisher erst relativ wenig Spiele entwickelt worden (siehe Test im ABBUC-Magazin Nr. 74). Auf einen Schlag hat Schmutzpuppe die Software- Bibliothek stark erweitert, indem er Patches von einigen Klassikern geschrieben hat.

Wer hat sich nicht schon mal geärgert, alte für den 800er entwickelte Spiele nicht mehr zu viert spielen zu können. Schuld sind die zwei bei der XL-Serie eingesparten Joystickports. Wer ein Multijoy-Interface hat, für den ist dieser Missstand jetzt endlich behoben. Das WGL hat ein Multijoy-Interface und besteht aus vier Personen. Die Patches sind also wie für uns gemacht. Was für eine Freude war es, M.U.L.E auf dem XL zu spielen. Es spielte sich exakt wie das Original, deshalb unsere WGL-Wertung:
M.U.L.E. (mit Patch für Multijoy): * * * * * (5 von
5 Sternen)
Die anderen gepatchten Spiele siehe unten:
Die Patches sind erhältlich auf der Homepage des WGL oder bei Starsoft Berlin:
http://wiesbadengaminglab.atari.org
http://www.ppsberlin.de

Bis zum nächsten Mal,
Euer Wiesbaden Gaming Lab

Spiel Beschreibung WGL-Wertung
Dandy Superspaß im Labyrinth, im Team kann man weit kommen * * * *
Asteroids Asteroiden-Massaker, gegen vier haben die Steine keine Chance. Wird schnell langweilig * * *
Basketball Hmmh…es kommt nicht so richtig Spielspaß auf * *
ATARI Tennis Im Hunsrück lieferten wir uns harte Matche * * * *

 

Regeln für den ABBUC Software Wettbewerb 2005

1) Allgemeine Regeln:
Der Abgabeschluss für den Software-Wettbewerb wurde auf den 31. August 2005 festgelegt. Folgende Preise werden vom ABBUC vergeben:
1. Platz: 500 Euro
2. Platz: 250 Euro
3. Platz: 125 Euro
4. Platz: 75 Euro
5. Platz: 50 Euro
Der ABBUC erhält für die angemeldeten Programme das Veröffentlichungsrecht für das Magazin bzw. Sondermagazin oder die Jahresgabe; das Copyright bleibt jedoch weiterhin beim Autor, der sein Programm nach dem Wettbewerb frei verwenden kann. Die Präsentation der Programme wird auf der Unconventional und im ABBUC Magazin stattfinden, die endgültige Entscheidung und Preisvergabe hingegen auf der ABBUC-JHV in Herten im Oktober. Der Autor muss bei beiden Veranstaltungen (Präsentation, Preisvergabe) nicht unbedingt anwesend sein, er erhält den Preis dann trotzdem zugesandt oder überwiesen, sofern dem ABBUC dafür die Postadresse und/oder Bankverbindung vorliegt…

2) Programm Typen und Größe:
Bei den Wettbewerbs-Programmen darf es sich um folgende Programmtypen handeln:
a) Spiel/e,
b) Anwendung/en (auch Tools, Utilities, etc.)
c) Betriebs-Systeme (DOS)
Nicht erlaubt sind jegliche Formen von Demos oder Intros, sowie Beta-, Vorab-, oder Pre-Versionen (die Programme müssen fertig gestellt sein). Bei der Kompatibilität ist zu beachten, dass die Programme mind. auf einem XL oder XE Rechner laufen müssen, d.h. auf einem Standard 64k oder 128k Atari XL/XE. Es darf zwar Zusatzhardware unterstützt werden, diese darf aber nicht die Voraussetzung zum Laden oder Laufen des Programms sein. Und ob man es nun glaubt oder nicht, das ABBUC Software Ressort (und auch alle ABBUC Mitglieder) wir
d (werden) einen „Qualitäts-“ und „Kompatibilitäts-“ Check aller angemeldeten Wettbewerbs-Programme durchführen…

3) Format und Sprachen:
Das Wettbewerbs-Programm kann auf 5,25″ Atari- Disk(s) oder als ATR-Image(s) eingereicht werden, es muss als 90k (SD) oder 130k (ED) Disk-Format bzw. ATR-Image vorliegen. Zu dem Programm muss eine kurze Anleitung vorliegen, diese kann entweder im Programm (intern) enthalten sein oder als Text- Datei (extern) dazugefügt werden. Wichtig ist hierbei, dass entweder Deutsch oder Englisch verwendet wird (und kurz erklärt wird wie das Programm zu laden ist), damit auch jeder das Programm bedienen kann. Es sind übrigens alle Atari 8Bit kompatiblen Programmiersprachen erlaubt, jedoch am Ende nur Kompilate, damit jeder das Programm laden kann. Ausnahmen sind lediglich Atari Basic und Turbo Basic XL – hier sind auch Sources bzw. Listings erlaubt, da diese Sprachen ja jeder Atarianer besitzt… Schickt euer Wettbewerbs-Programm nebst Anleitung als 5,25″ Atari-Diskette bitte an folgende Adresse:

Andreas Magenheimer,
Ernst Ludwig-Str. 84,
55232 Alzey
Deutschland
Alternativ schickt ein ATR-Image (ungepackt mit 92.176 Bytes bzw. 133.136 Bytes oder gepackt als *.ZIP) nebst Anleitung an folgende E-Mail Adresse: software@abbuc.de
Also dann, viel Spaß beim Programmieren – euer ABBUC Software Ressort.
(Charlie Chaplin / Andreas Magenheimer)

Regeln für den ABBUC Hardware Wettbewerb 2005

1.1 Wettbewerb
Um die Entwicklung neuer Hardware für die ATARI 8- Bit-Systeme zu fördern, schreibt der ABBUC e. V. einen Hardwarewettbewerb aus. Die Regeln und Bedingungen für die Teilnahme am Wettbewerb sind in den nachfolgenden Punkten festgelegt.

1.2 Auszeichnungen
Folgende Prämierungen werden auf der Jahreshauptversammlung 2005 erfolgen: Preis „beste Hardware 2005“ Sonderpreis „beste Hardware 2005 in Entwicklung“ (Vorserienmodell/Prototyp)

1.3 Teilnahmebedingungen
1.3.1 Qualitätscheck
Die zur Wettbewerbsteilnahme vorgesehene Hardware muss dem Ressortleiter Hardware für die zur Zulassung erforderlichen Vortests zur Verfügung gestellt werden. Bei den Tests werden die beschriebenen Eigenschaften der serienreif aufgebauten Hardware überprüft. Die Zusendung je eines betriebsbereiten Produktes hat nach Absprache an den Ressortleiter Hardware zu erfolgen. Nach Abschluss des Wettbewerbs/der JHV 2005 erfolgt die Rückgabe/Rücksendung an den Eigentümer.

1.3.2 Eigenschaften
Zum Wettbewerb zugelassen wird/werden ausschließlich Hardware/Erweiterungen für die Computerfamilie der ATARI 8-Bit-Reihe (600XL, 800XL, 65XE, 130XE). Zur Zulassung kommen Erweiterungen für die Computer selbst, wie auch eigenständige Peripheriegeräte. Modifikationen von bereits verfügbaren Entwicklungen sind von der Teilnahme ausgeschlossen. Weiterhin muss der Teilnehmer gewährleisten, dass spezielle Softwares (Betriebssysteme, Computersprache, Anwendungsprogramme) nicht zwingend zum Betrieb der eingereichten Hardware notwendig sind, es sein denn, die Software ist im Lieferumfang enthalten und frei von jeglichen Rechten Dritter. In Sonderfällen entscheidet der Ressortleiter Hardware in Zusammenarbeit mit dem 1.Vorsitzenden des Vereins über eine Zulassung.

1.4 Anmeldung/Zulassungsvoraussetzungen
* Vorlage eines funktionsfähigen Serienmodell bei der Teilnahme „beste Hardware 2005“ (siehe auch Punkt 1.5 Anmeldeschluss)
* Vorlage von aussagefähigen Unterlagen/ Beschreibungen bei der Teilnahme „beste Hardware 2005 in Entwicklung“
* Verständliche Beschreibung/Anleitung der Hardware in deutsch oder englisch
* Mindestens drei Fotos in digitaler Form (min. 1024*768dpi, 24Bit Farbe)
* Die eingereichte Hardware bzw. Software muss frei von Rechten Dritter sein. Einsendungen, bei denen eine Copyright-Verletzung nicht zweifelsfrei ausgeschlossen werden kann, nehmen NICHT am Wettbewerb teil.

Die zur Teilnahme zugelassenen Modelle werden den Vereinsmitgliedern mit Funktionsbeschreibung und Bild (ern) vorab im ABBUC Magazin vorgestellt.

1.5 Anmeldeschluss
Die zur Teilnahme „beste Hardware 2005“ vorgesehene Hardware muss bis spätestens 15.08.2005 beim Ressortleiter Hardware zur Prüfung eingegangen sein. Hardware, die nicht, bzw. verspätet zur Prüfung eingegangen ist, kann nicht am Wettbewerb 2005 teilnehmen.

1.6 Präsentation der am Wettbewerb teilnehmenden Hardware
Die Hardwareerweiterungen werden auf der Jahreshauptversammlung durch den Entwickler bzw. das Entwicklerteam oder deren Vertreter präsentiert.

1.7 Bekanntgabe der Gewinner
Die Gewinner werden durch Abstimmung der Vereinsmitglieder auf der Jahreshauptversammlung 2005 ermittelt. Die Abstimmung erfolgt per Abstimmungsbogen. Wahlweise kann die Abstimmung auch per Post erfolgen. Der Abstimmungsbogen wird jedem Clubmitglied mit dem vor der JHV 2005 erscheinenden Clubmagazin zugestellt. Einsendeschluss für die Postabstimmung ist der 20.10.2005

1.8 Preisgelder
Der Preis für die „beste Hardware 2005“ ist mit einem Preisgeld in Höhe von EUR 500,00 dotiert. Der Sonderpreis für die „beste Hardware 2005 in Entwicklung“ ist mit einem Preisgeld in Höhe von EUR 100,00 dotiert.

1.9 Schlussbestimmungen
Der Rechtsweg ist ausgeschlossen.

Ein Rechtsanspruch der Teilnehmer auf Durchführung des Wettbewerbs besteht nicht. Änderungen sowie Irrtümer vorbehalten. Wird in einer Kategorie kein Preis vergeben, fällt das Preisgeld an den ABBUC e.V. zurück.
Andreas Mischka
hardware@abbuc.de

 

Atari 8bit Boot CD’s

Währe es nicht toll, wenn man eine CD in ein CDROM Laufwerk schieben würde und nach dem Einschalten des Atari XL/XE, davon booten könnte? Nie wi
eder Disketten wechseln während man ein Spiel spielt. Mehr Speicherplatz als auf jeder Diskette. Das würde heißen, Platz für mehr Treiber, mehr Level, mehr Soundeffekte und mehr Bilder oder grafische Effekte. Viel mehr!! Das alles mit „Festplatten-Geschwindigkeit“ ! Dazu kommt noch, das CDROM’s nicht fragmentiert sind ( weil man CDROM’s und CDR’s nicht löschen kann, tritt keine Fragmentierung auf ). Außerdem haben alle CDROM Laufwerke einen Puffer, wie man diese auch aus den Happy und Speedy Erweiterungen kennt.

Wie man weiß, gibt es das sogar für den C64. Da blutet das Herz eines jeden XL/XE Besitzers. Dabei gibt es schon seit Jahren Festplatteninterfaces. Die besseren davon, wie zum Beispiel die BlackBox, machen aus einem 512 Byte Sektor, wie er schon seit Jahren auf Festplatten üblich ist, zwei 256 Byte Sektoren womit zum Beispiel MyDOS und BeWeDOS etwas anfangen können. Nun könnte man auf die Idee kommen, das ein SCSI Kommando eben ein SCSI Kommando ist. Das IDE Kommandos wahrscheinlich gleich aussehen und das es wahrscheinlich nur einen Befehl gibt, um Daten auszulesen. Es gibt drei davon, soweit ich weiß. ISO 9660 CD’s benutzen, wie einige vielleicht auch wissen, 2048 Byte Sektoren….

Es gibt in der Tat drei SCSI Befehle um einen Sektor auszulesen. Diese kann man für fast alle (SCSI/IDE) Geräte benutzen. Die READ Befehle für Festplatte und CDROM oder sogar DVDROM Laufwerk sind gleich. Bei UNIX, wo SCSI lange Zeit bevorzugt wurde, arbeitet man mittlerweile auch über IDE. In Fällen, bei denen man nur 512 Byte Sektoren benutzen will, kann man SCSI Laufwerke über einen Jumper auf 512 Byte Sektoren umschalten. ( gilt nicht für Brenner! ) Hmm, wenn das CDROM Laufwerk die gleichen Lesebefehle versteht wie eine Festplatte, die Sektorgröße die das CDROM Laufwerk erwartet, gleich groß ist wie die einer Festplatte, dann….

…dann braucht man nur noch eine CD die ausgelegt ist wie eine Festplatte. Auf so einer Festplatte sind nicht nur Benutzerdaten enthalten, sondern auch Daten, die das Festplatteninterface braucht. Darin steht zum Beispiel, wo die einzelnen Partitionen anfangen und von welcher Partition gebootet werden soll. Ohne diese Daten kann man auch von einer Festplatte nicht booten. Die Benutzerdaten können alles Mögliche enthalten, wie Spiele, Tools, Demos und was auch immer.

Dann würde aber das Problem entstehen, dass man für jede Partition auch die Bootsektoren erstellen muss, und die Directory und die VTOC. Man könnte zuerst eine Festplatte mit den Daten füllen, die man auf der CD haben will. Danach probieren, den Inhalt der Festplatte eins zu eins auf die CD zu kopieren. Das Problem ist, dass man eine ziemlich große Festplatte braucht, wenn man die CD auch bis zum Rand füllen will. Auf 8 cm CD’s passen 210 MB, auf 12 cm CD’s passt 650 oder 700 MB, auf DVD’s 4.7 GB und auf Dual Layer DVD’s sogar über 8 GB. Man muss aber dazu sagen, dass die BlackBox bei Single und Medium Density 128 Byte pro Sektor verschwendet. Es würde also bei Single oder Medium Density nur halb so viel Daten auf eine Platte passen, wie in Double Density.

Man müsste dann aber entweder ein Programm schreiben, welches es ermöglicht, die Daten auf den XL/XE zu kopieren. Der Kopiervorgang könnte dabei „etwas“ Zeit in Anspruch nehmen. Oder man probiert die beiden Geräte am PC oder MAC zu hängen und probiert es von dort. Dieses müsste einfacher sein. Es müsste einen Weg geben, mit dem man am PC Partitionsimages erstellen kann. Man könnte dann mehrere Images „zusammen kleben“ um so ein CD Image zu erstellen. Dieses zusammengestellte Image könnte man dann auf eine CD brennen. Ein Partitionsimage ist eigentlich nichts anderes als ein Diskettenimage und diese kann man am PC zusammenstellen. Man könnte da das ATR-Format nehmen. Jetzt muss man nur noch die 16 Byte am Anfang eines jeden ATR’s abschneiden, die ATR’s zusammen kleben und die Partitionsliste(n) zusammen stellen.

Dazu bräuchte man einen Programmierer der sich mit PCs und ATR’s auskennt, wie zum Beispiel Matthias Reichl. Außerdem braucht man jemand, der sich die Mühe macht, die BlackBox Konfiguration und die Partitionsliste zu dekodieren, wie mich. Weil wir zwar beide nahe der Deutschen Grenze wohnen, aber er in Österreich und ich in den Niederlanden, braucht man auch noch das Internet, mit dem wir uns austauschen können und um dann das Programm, das die ATR’s in ein CD Image verwandelt, zu veröffentlichen. Dann hätte man auf der JHV Ende Oktober sein müssen, um zu sehen wie wunderbar oben Erwähntes funktioniert. Ich hatte zwei CDROM’s dabei. Die erste habe ich nur gebrannt um Matthias‘ Programm aus zu probieren. Es sind vielleicht 18 Partitionen darauf. Die zweite enthält 17 (in Worten: siebzehn) Partitionslisten. Jede mit bis zu 96 Partitionen. Sie enthalten insgesamt über 1300 (in Worten: eintausenddreihundert) Partitionen (ehemalige ATR’s). Alle ABBUC Magazine, inklusive Sondermagazine, alle AMC Disketten und alle die ABBUC PD Disketten die man von Atari starten kann, und trotzdem nur 330 MB der CD benutzt.

Matthias und ich sind davon überzeugt, dass man so auch eine (Dual Layer) DVD erstellen könnte, von der man dann auch booten könnte. Wie Matthias‘ Software genau funktioniert, findet ihr auf unseren Internetsites. Dort gibt es auch eine genauere Beschreibung wie AtariCD funktioniert.

Tschüss
Mathy van Nisselroy
Sites:
http://www.mathyvannisselroy.nl
http://www.horus.at/~hias/atari/

A-TRACK

A-TRACK – ein Wunder für den ATARI ?!
Hallo Bitbyter! Schon vor einiger Zeit bin ich im Internet über das Projekt A-TRACK von Terry Chamberlain gestolpert. Was das ist? Nun, es handelt sich um ein vollständig entwickeltes Hardware-Software-System für den ATARI XL/XE, das zur digitalen Steuerung von Modellbahnen dient. Überraschend daran ist eigentlich nur, dass es so lange gedauert hat – bis zum Jahr 2000 – bis endlich eine professionelle Lösung für diese Anwendung auf dem ATARI XL/XE zur Verfügung stand. Ältere Bitbyter erinnern sich sicher noch an die vielen nie vollständig umgesetzten Lösungsansätze zur analogen und/oder digitalen Steuerung von Robotern, Modellbahnen, etc. Einzig das leider nicht mehr erhältliche FischerTechnik-Interface von Martin Reitershan ermöglichte eine brauchbare Steuerung von Robotern, Plottern, etc.

In vielen lokalen ATARI-Computerclubs wurden Bastellösungen
entwickelt, die meist mit der Steuerung eines Roboterarms endeten, Lichtquellen schalteten und ich kenne auch eine passable Lichtorgelsteuerung. Selber habe ich zu meinen Anfangszeiten auf dem ATARI XL davon geträumt, meine Märklin Z damit steuern zu können. Aber über ein Relaisinterface ließ sich nur sehr begrenzt eine brauchbare Zugsteuerung realisieren. Immerhin konnten Licht, Weichen, Schranken etc. auf meiner Mini-Anlage damit ganz gut verwaltet werden. Aber nach einer Vergrößerung der Anlage war das nicht mehr sinnvoll möglich. Das Interface wurde weggegeben und die Anlage eingemottet. Inzwischen sind ja fast alle Modellbahntypen im digitalen Zeitalter angelangt und wow – es gibt eine digitale Steuerung für mittlere heimische Modellbahnanlagen für den ATARI XL/XE. Schade ist daran, dass der Entwickler sein System auf dem PC weiterentwickeln will. Da das ganze auch eine wirtschaftliche Komponente hat, sicherlich gut nachzuvollziehen. Doch vielleicht gibt es ja unter den Bitbytern interessierte Modellbahner, Programmierer und Hardwareentwickler, die sich dieser, wie ich meine, hervorragenden Lösung mal annehmen und sie für den ABBUC adaptieren. Dem Entwickler Terry Chamberlain aus Großbritannien habe ich schon mal eine E-Mail geschickt in der Hoffnung, dass der ATARI-Part dieser Entwicklung dem ABBUC zur Verfügung gestellt werden könnte.

Nachfolgend habe ich den Teil von Terrys Webseite (http://www.a-train-systems.co.uk/index.htm) als deutsche Übersetzung angehängt, der einen Überblick über das von ihm entwickelte A-TRACK-System gibt. Weitere Details und Infos finden sich, natürlich in Englisch, auf seiner Webseite. Falls genügend Interesse an einem entsprechenden deutschsprachigen Projekt besteht, stell ich gerne meine bescheidenen Kenntnisse dafür zu Verfügung. Gruß & GoodByte Walter Lojek A-TRACK Eine vollständige Systemumgebung für „Digital Command Control“ von Modelleisenbahnen vom ATARI XL/ XE aus.

Features
* Zentrale, computergestützte Steuerkonsole.
* Basisstation mit Unterstützung für multiple Stromversorgung.
* Bis zu 8 Handcontroller für die gleichzeitige Steuerung von 8 Lokomotiven oder anderen Anlagenteilen.
* Entspricht den NMRA DCC Standards.
* Ablaufliste für Steuersequenzen für bis zu 64 Lokomotiven.
* Speicherung aller Steuerparameter sowie der Programmierung für die Lokomotiven auf Diskette.

Überblick
A-TRACK (http://www.a-train-systems.co.uk/) ist ein Programm für die (betagten aber leistungsfähigen) ATARI XL/XE Computer zur digitalen Steuerung (DCC) von Modelleisenbahnen . A-TRACK unterstützt alle in den DCC Standards und den dazu empfohlenen Verwendungen (http:// www.dcc.info/standards_rps/index.html) festgelegten Funktionen, die von der National Model Railroad Association (http://www.nmra.org/) bis zum Jahr 2000 festgelegt wurden. Mit A-TRACK, einer Interfacebox (DCC Interface Unit oder DIU) vom Computer zur Anlage und einem Set von Handcontrollern, die in auf der Anlage verkabelte Buchsen gesteckt werden, lassen sich maximal 8 Lokomotiven gleichzeitig auf einem Schienenstrang betreiben. A-TRACK ermöglicht die vollständige Kontrolle einer Modellbahnanlage vom ATARI aus durch Einrichten einer Ablaufliste für den Fahrbetrieb, wobei Lokomotiven oder Streckenteile auf dafür ausgesuchte Handcontroller zugewiesen werden können. Zusätzlich lassen sich sogar alle Weichen oder Signale von einer Zentrale aus fernsteuern. A-TRACK bietet außerdem volle Programmierbarkeit der Decoder in den Lokomotiven einschließlich der Speicherung dieser Programmdetails für jede einzelne Lokomotive sowie des gesamten Betriebsablaufs auf Diskette, damit alles sicher gespeichert ist und bei Bedarf wieder verwendet werden kann.

DCC ermöglicht den gleichzeitigen Betrieb von einer fast beliebigen Anzahl von Modelllokomotiven auf einer komplexen Modellbahnanlage ohne den Einsatz der konventionellen Blockstrecken, bei dem ja z.B. eine einzelne Lokomotive auf einer nur ihr zugewiesenen Teilstrecke gesteuert werden kann. Die Geschwindigkeit und die Fahrtrichtung jeder einzelnen Lokomotive kann unabhängig festgelegt werden, ganz egal wo auf der Gleisanlage sie sich gerade befindet (Dieses Feature muss aber mit Vorsicht genutzt werden!). Die Steuerung mehrerer Lokomotiven oder Streckenabschnitte als eine zusammengefasste Einheit ist auch möglich, ebenso für Zubehör wie Beleuchtung, Signale, Weichen etc.

Die in den Lokomotiven verwendeten Decoder können auch zur Steuerung von statischen Anlagenteilen wie Signalen, Weichen, etc. eingesetzt werden. Nun ja, für diesen Zweck werden normalerweise spezielle Zubehör- Decoder mit schaltbaren Ausgängen eingesetzt, sofern das Zubehör (Drehscheibe, Kran, etc.) die Steuerung über einen Elektromotor benötigt. A-TRACK und die DIU entsprechen von ihrer Auslegung her voll den NMRA Standards und funktionieren mit allen handelsüblichen Decodern. Bisher wurde das System mit folgenden Marken erfolgreich getestet:

Digitrax (http://www.digitrax.com/)
Lenz (http://www.lenz.com/)
Model Rectifier (http://www.modelrec.com/products/
trainSound/prodigyDCC.asp)
North Coast Engineering (http://www.ncedcc.com/)
Wangrow SystemOne (Herstellung eingestellt)
ZTC Decoder (http://ztccontrols.com/)

Geschichte
In der Jan/Feb-Ausgabe 1996 des ATARI Classics Magazine stand ein dringender Hilferuf eines Enthusiasten aus Kalifornien, Decker McAllister, nach dem Entwurf eines Interfaces für ATARI 8-Bit Homecomputer, mit dem die Steuerung einer Modellbahnanlage per DCCSystem ermöglicht werden sollte. Weder er noch seine Freunde hatten die notwendigen Elektronik- oder Assemblerkenntnisse. Freudig habe ich meine freiwillige Hilfe angeboten und dann fast meine gesamte Freizeit der nächsten 4 Jahre für das Entwickeln von zuerst der Hardware (der leichtere Teil, da ich von Beruf Elektronikingenieur bin) und dann der Software eingesetzt. Da die Steuerung der Lokomotiven in Echtzeit ablaufen muss, kam die Verwendung von BASIC nicht in Frage. Die gesamte Software wurde in Assembler geschrieben. Das Quellcodelisting ist 15.000 Zeilen lang (ca. 200 Seiten). Ich glaube, dass es wohl eines der umfangreichsten Assemblerprogramme für den 8-Bit-ATARI sein muss (das 400/800- OS umfasst etwa 5.800 Zeilen). Zur einfachen Bedienung enthält die Software auch einen Maus-Handler.

Damit lassen sich Mäuse vom ATARI ST, Commodore, Amiga und dazu kompatible Mäuse ansprechen. PCMäuse (seriell oder PS/2) lassen sich nicht verwenden (Anmerkung des Übersetzers: es sei denn, sie wurden entsprechend modifiziert.). Weniger als 250 Zeilen Assemblercode waren erforderlich, um einen Allzweckmaushandler in das CIO-System des ATARI einzufügen. Nach so ziemlich 2 Jahren Arbeit (beträchtlich mehr als meine anfängliche Schätzung) konnte die erste Demoversion der Software kurz vor Weihnachten 1997 an Decker und seinen Freund Bob DeMoss nach Long Beach, Kalifornien, sowie zu Charles Cole vom Cochise & Western Model Railroad Club (http:// users.ssvecnet.com/cacole/cwmrrc_001.htm ) in Sierra Vista, Arizona (wurde durch Decker in das Projekt einbezogen) zum Ausprobieren geschickt werden. Sehr zu meiner Zufriedenheit lief es einwandfrei auf den NTSC-Versionen des ATARI. Da die Software eine Menge an zeitkritischen Routinen enthält, befürchtete ich, dass der Wechsel von 50 Hz PAL auf 60 Hz NTSC die Programmabläufe stören könnte.

Nun ja, es brauchte ein weiteres Jahr an Entwicklungsarbeit, um die Interfaceelektronik zu perfektionieren und sie mit den Softwareerfordernissen abzustimmen. Und schließlich musste ich ja noch die entsprechenden Anlagensets für meine geduldigen ‘Kunden’ in Kalifornien und Arizona bauen. Die erste Auslieferung erfolgte im Frühling 1999, gefolgt von persönlichen Besuchen zum endgültigen Einbau i
n die Anlagen und zum Ausbügeln der unvermeidlichen Kinderkrankheiten. Ein weiteres Jahr Entwicklungszeit war notwendig, bevor die finale Version des Handcontrollers (einsteckbar an verschiedenen Buchsen; zum Herumlaufen beim Betrieb) das A-TRACK-System komplettierte.

Dazu kamen die damit zusammenhängenden Softwareupgrades. Die endgültige Auslieferung erfolgte dann im März 2000. Die umfangreichste Installation des A-TRACK-Systems beim C&WMRRC befindet sich seitdem im Dauerbetrieb, wobei nur kleine (und schnell korrigierte) Störungen aufgetreten sind. Diese lange, erfolgreiche Betriebszeit machte aber deutlich, dass das Limit von maximal 64 Lokomotiven im A-TRACK-Programm eine nachteilige Begrenzung für den Betrieb von Clubanlagen darstellt, da nicht alle Lokomotiven der Clubmitglieder in das Programm mit einbezogen werden können. A-TRACK war nicht ohne weiteres auf eine längere Betriebsliste erweiterbar, weil das Programm den gesamten 64k-Speicher des ATARI bis auf ein paar hundert Byte belegt. Die Lösung bestand im Schreiben eines ergänzenden Programms, A-STILE (http://www.a-train-systems.co.uk/ projects.htm#_A-STILE_%E2%80%93_the), mit dem alle Clublokomotiven in einem einzigen File zusammengefasst werden können. Daraus lassen sich einzelne Betriebslisten mit maximal 64 Lokomotiven nach A-TRACK übertragen, um spezifische Betriebsabläufe durchzuführen. Weitere Details über A-STILE finden sich auf der Projektseite (http://www.a-trainsystems. co.uk/projects.htm). Leider verstarb Decker McAllister, der die erste erfolgreiche Einrichtung noch erlebt hatte, nach kurzer Krankheit Ende 1999.

Deckers grenzenloser Enthusiasmus ließ während der langwierigen Entwicklung des Projekts nie nach und sorgte dafür, dass das herauskam, was der Modelleisenbahner wollte, ohne dass er Computerexperte sein muss. A-TRACK ist seinem Andenken gewidmet. Danksagungen Die Entwicklung der Software für A-TRACK wäre wahrscheinlich unmöglich gewesen ohne das ausgezeichnete von Nick Kennedy entwickelte SIO2PC (http://www.tcainternet.com/wa5bdu/sio2pc.htm). Damit konnte ich meinen ATARI 800XL mit einem PC verbinden. Die momentane Verbindung läuft über ein RS232-Interface, das um einen Maxim MAX232 Chip herum gebaut wurde und den ATARI-SIO-Port mit einem beliebigen seriellen Port am PC verbindet. Das Interface ist relativ einfach herzustellen, wenn man der leicht verständlichen Dokumentation von Nick folgt.

Die SIO2PC-Software auf dem PC stellt den PC als eine Art ATARI ‚Superdiskdrive‘ bereit, der von jedem ATARIDOS ohne weitere Modifikation der ATARI-Hardware und ohne zusätzliche ATARI-Software genutzt werden kann (Anmerkung des Übersetzers: weitere Software für SIO2PC auch unter Windows, MAC OS und Linux verfügbar). ATARI-Files lassen sich auf der PCFestplatte speichern und bei Bedarf auf PC-Disketten (Anmerkung des Übersetzers: auch CDs, DVDs, Memostick, etc.), so dass die komplette ATARI-File- Bibliothek jederzeit direkt verfügbar ist.

Mit SpartaDOS (mein bevorzugtes DOS für den ATARI – Kommentar des Übersetzers: meins auch!!!) lassen sich auf dem PC ATARI-Superdisks mit 1 MB anlegen, was letztlich unerlässlich für das A-TRACK-Projekt war, da die Sourcefiles in etwa 500 KB groß waren und das Assembler-Listfile allein mehr als 650 KB beansprucht. Ich muss zugeben, das Files dieser Größe weit außerhalb der Kapazitäten eines jeden ATARI-Texteditors liegen, weshalb ich in der Tat einen PC für die Entwicklung des Assembler-Sourcecodes verwende. Diesen übertrage ich dann per RS232-Link über ein P:R:-Interface mit Hilfe von BobTerm auf der ATARISeite.

BobTerm von Bob Puff (http://www.nleaudio.com/ css/) (Anmerkung des Übersetzers: Jahresgabe 1989 des ABBUC) ist weitaus das beste Kommunikationsprogramm für den 8-Bit-ATARI und konvertiert die PCASCII- Zeichen CR/LF automatisch in ATARI-EOLZeichen. Mit ein bisschen Nachbearbeitung auf dem 800XL lässt sich das übertragene Sourcefile (liegt auf einer SIO2PC-Superdisk auf dem PC) dann von einer Assembler/Editor-Cartridge aufrufen und in das gewünschte Maschinencode-Objektfile sowie in das Listfile ausgeben. Die Ausgabe erfolgt ebenfalls auf eine weitere SIO2PC-Superdisk auf dem PC, da der 800XL diese langen Files weder in seinem 64 KB Speicher noch auf einem echten ATARI-Diskdrive ablegen kann (Anmerkung des Übersetzers: Natürlich gibt es Hardware für den ATARI XL/XE, die diese Speicherkapazitäten locker handhaben könnte, z.B. eine stinknormale Festplatte.).

Obwohl das alles sehr kompliziert klingt, ist es in der Praxis ziemlich einfach zu handhaben und gewissermaßen auch befriedigend, weil ein PC als ATARIPeripheriegerät verwendet wird. Zukünftige Weiterentwicklung Bedauerlicherweise wurden die ATARI 8-Bit- Maschinen schon vor langer Zeit technisch überholt durch den unerbittlichen Vormarsch der IBMkompatiblen PCs. Daher wird die weitere Entwicklung von A-TRACK nach Konvertierung auf der PCWindows- Plattform stattfinden. Der erste Ansatz wird sein, soviel wie möglich von der ursprünglichen ATRACK- Hardwar e einschließlich der DCC-Interface-Unit (DIU) und der Handcontroller beizubehalten, damit keine Umbauten der momentan damit betriebenen Modellbahnanlagen erforderlich werden. Um mir die Dinge so einfach wie irgend machbar zu gestalten, werde ich die Software in Visual BASIC schreiben und das Interface zwischen PC und DIU (und den Handcontrollern) per USB herstellen. Die Verwendung von USB erfordert auf dem zur Steuerung eingesetzten PC Windows 98 SE als Mindestvoraussetzung (Anmerkung des Übersetzers:

Win98 First Edition kann sehr wohl normale USB-Schnittstellen ansprechen und inzwischen kann das auch unser ATARI!!!) und bevorzugt Windows 2000 oder XP, was aber insgesamt keine allzu große Einschränkung in der aktuellen PC-orientierten Welt darstellen sollte.

Kommentar des Übersetzers: Natürlich ist es vor allem für große Anlagen wie z.B. den der Modellbahnclubs vorteilhaft, umfangreichere Hardwareressourcen wie z.B. die eines aktuellen PCs zur Verfügung zu haben. Für die heimische Modellbahnanlage sollte aber ein XL/XE völlig ausreichen.
Walter Lojek

ATEAM

A BBUC’s
T hrilling
E vents
A nd
M agazines

Hallo Abbucianer,
Wolfgang brauchte noch einen Artikel für das Magazin. Da ich aktuell eher mit Arbeiten gehen und Küche renovieren beschäftigt bin, kann ich leider keine aktuellen 8-Bit-Projekte vorweisen. So habe ich mal auf ein altes Projekt zugegriffen. Es gab mal eine Zeit, wo ich vermisst habe, dass so ein Diskeditor bestimmte Informationen über Sparta DOS Disketten gesammelt auf einen Blick anzeigt. So entstand irgendwann SDBOOT.TUR. Dabei handelt es sich um ein Turbo BASIC Programm, welches den Bootsektor einer Diskette ausliest, die Informationen auswertet und auf einer Bildschirmseite darstellt.

Dazu jetzt einige Erklärungen:
Zeile 100-220
Was für ein Glück, dass die meisten meiner kleinen Tools solch einen Header haben. Wie sonst sollte ich nach 10 Jahren noch wissen, was die Zeilen darunter bewirken? 🙂

Zeile 230-250
Als erstes Platz geschaffen für das Einlesen des Sektors. Da die Sektoren 1-3 immer mit 128 Byte übertragen werden, unabhängig davon, ob es sich um eine SD oder DD Diskette handelt, braucht man hier keine Stat
usabfragen, um die Dichte auszulesen. Dann wird festgestellt, ob das Turbo Basic Programm unter Sparta DOS läuft. Wenn ja, dann wird die SIO-Routine von Sparta DOS benutzt. Es ist natürlich nicht wirklich wichtig, ob der eine Sektor mit Highspeed eingelesen wird oder nicht. Aber wenn man die SIO von Sparta DOS benutzt, hat man auch Zugriff auf die eventuell geladene RAMDISK.

Zeile 260-300
Hier wird ein deutscher Zeichensatz geladen, wenn sich die genannte Datei an der bezeichneten Stelle befindet. Und wenn man das GOTO 300 in Zeile 240 entfernt …

Zeile 310-380
Der Bildschirm wird gelöscht. Es wird eine Eingabeaufforderung geschrieben und dann läuft das Programm solange in einer Schleife, bis man eine Ziffer von einschließlich 1 bis 9 eingibt. Erfolgte eine korrekte Eingabe, dann wird die eingegebene Nummer noch auf den Bildschirm ausgegeben und dann geht’s los: Sektor lesen, Info generieren und wieder zurück zur Eingabe.

Zeile 390-500
Sektor 1 wird in den String SEKTOR$ geladen.

Zeile 510-560
Eine Routine zur Ausgabe eines 8-Bit Wertes. Der INFO$ enthält am Anfang 2 Zeichen als Zeiger auf die Stelle in Sektor 1, wo die Daten zu finden sind. Beispiel: „17Das ist Text.“ Aus den beiden Zeichen 1 und 7 wird durch den VAL Befehl der Wert 17. Dann wird der Text um zwei Zeichen nach Links geschoben, womit die Zeichen 1 und 7 dann weg sind.

Zeile 570-640
Genauso wie PROC BYTE, nur eben für die Ausgabe einer 16-Bit Zahl.

Zeile 650-960
Der Bildschirmaufbau erfolgt. In Zeile 690 sollte es statt „IF T=1“ besser heißen: „IF T=1 OR T=0“. Leider setzten nicht alle Sparta DOS Versionen beziehungsweise die Diskettenformatierprogramme dieses Byte richtig. Es steht für die Anzahl der Tracks. Wenn eine Festplattenpartition oder eine RAMDisk formatiert wurden, betrachtet Sparta DOS das Medium einfach als die Summe seiner Sektoren und trägt für die Zahl der Tracks eine 1 ein, manchmal aber auch eine 0. Wenn es bei RAMDisks immer eine Null wäre und bei Festplattenpartitionen immer eine 1 könnte man dieses Byte verwenden, um zwischen den beiden zu unterscheiden. Ist aber nicht so.

So, wer möchte kann das Programm dazu verwenden, etwas über den Sparta DOS Bootsektor zu lernen. Eine gute Dokumentation zur Struktur des Dateisystemaufbaus ergibt sich aus der Summe der Handbücher zum „Sparta DOS Contstruction Kit“ und zu „Sparta DOS X“. Auf dem Magazin sollte nun zu finden sein:
* dieser Text
* das Listing abgedruckt, wenn Wolfgang das mit den Sonderzeichen des Atari hinbekommt
* das Programm SDBOOT.TUR
* der Zeichensatz GERMAN.FNT

Viel Spaß
Euer Erhard

Atari USB

Nun ist es soweit,
die Atari USB Cartridge kann bestellt werden. Die Cartridge wird in den USA von Steve Tucker gefertigt und kostet 25 Euro pro Stück. In der ABBUC Version gibt es ein kleines Handbuch (inkl. Anleitung, wie USB Geräte unter BASIC und Turbo Basic abgefragt werden können), eine Treiberdiskette sowie angepasste Spiele (PolePosition für Lenkräder und Boulder Dash für Joypad).

Die Diskette enthält Treiber für
* USB Maus
* USB Joystick (analog)
* USB Joypad (digital)
* USB Tastatur

Bevor Ihr Euch nun USB Geräte kauft, bitte auf http://www.strotmann.de/twiki/bin/view/Microusb/ ProjUSBCartAtariDevMatrix schauen, welche Geräte erfolgreich getestet wurden. Es werden noch nicht alle Joysticks, Joypads und Lenkräder von den Treibern unterstützt. Wer 100% sicher gehen will, der kann folgende USB Geräte direkt mitbestellen (mit der USB Cart getestet und mit Funktionsgarantie): WingMan Precision Gamepad USB (Logitech) 15.00 Euro Pilot Wheel Mouse Optical (Logitech) 20.00 Euro Attack 3 Joystick (analog) (Logitech) 25.00 Euro Wingman Formula GP (Lenkrad) (Logitech) 40.00 Euro Speed Link Ultra-Flat Metal Keyboard 50.00 Euro Speed Link USB Tastatur normal 15.00 Euro zzgl. Versandkosten 6 Euro (innerhalb Deutschland) Auslieferung der USB Cartridges und der USB Geräte nach Geldeingang). Weitere technische Informationen unter http://www.microusb.org/

Die Abrechnung dieser Sammelbestellung (wie auch schon frühere Bestellungen) geht direkt über den ABBUC.

Bestellungen bitte senden an:
usb-order@strotmann.de Ich sende Euch dann eine Bestellbestätigung und weitere Informationen. Bitte Geld erst _nach_ korrekter (prüfen) Bestellbestätigung überweisen.

Beste Grüße
Carsten Strotmann

Wie man einen USB-HDI Treiber schreibt

Das USB-Gerät
Ich habe heute ein neues „Logitech Rumblepad 2 USB“ gekauft. Weil es noch keinen Treiber für dieses Gerät für den ATARI gibt, werde ich es als Fallstudie benutzen, um zu zeigen, wie man einen USB-HID (HID = Human Interface Device) Treiber für dieses Gerät schreibt.

Das „Logitech Rumblepad 2 USB“ hat einen digitalen Joypad Controller, zwei analoge Joystick Controller (rechter Hebel und linker Hebel), 10 normale Knöpfe, einen Modus-Knopf und eine Modus-LED, und einen Knopf, der den Force Feedback Vibration Modus umschaltet (lange oder kurze Vibrationsdauer).

Schritt 1: Untersuchen der USB-Pakete Zuerst starte ich das USBTEST.COM Utility von der „USB End User Driver Disk“. Der USB Controller kann das Logitech Pad erreichen und gibt die Gerätebeschreibung (Device Descriptor) und die String- Beschreibung (String Descriptors) aus. OK, wir können das Gerät ansprechen, es antwortet. Gut. Danach starte ich die „USB HID Trace“-Funktion in USBTEST. Die „USB HID Trace“-Funktion gibt alle USB-Pakete aus, die das Gerät an den Controller (das USB Modul) sendet.

Wir sehen etwa folgendes, wenn wir das Gerät benutzen (ohne die Kommentare auf der rechten Seite):
80 80 80 FF 08 00 44 FD |
80 80 80 E0 08 00 44 FD | linker Hebel von „runter“ nach „normal“
80 80 80 95 18 00 44 FD | Knopf 1 gedrückt
80 80 80 7F 08 00 44 FD |

Hier habe ich den rechten Hebel von der Position „runter“ nach „Normal“ (in der Mitte) bewegt und den Knopf 1 einmal gedrückt.

Nach einigem Herumspielen mit dem Gerät (10 Minuten), kannte ich alle möglichen Pakete:
Byte 1: horizontale Bewegung linker Hebel ($00 = links, $80 = Mitte, $FF = rechts)
Byte 2: vertikale Bewegung linker Hebel ($00 = hoch, $80 = Mitte, $FF =
runter)
Byte 3: horizontale Bewegung rechter Hebel ($00 = links, $80 = Mitte, $FF = rechts)
Byte 4: vertikale Bewegung rechter Hebel ($00 = hoch, $80 = Mitte, $FF = runter)
Byte 5: Bit 0-3 digitales Joypad (siehe unten) 
Byte 5: Bit 4 – Knopf 1, Bit 5 – Knopf 2, Bit 6 – Knopf 3, Bit 7 – Knopf 8
Byte 6: Bit 0-5 – Knopf 5-10
Byte 7: Bit 2 – Vibrations Knopf, Bit 3 – Modus Knopf und LED
Byte 8: unbekannt

Das digitale Joypad hat für jede Richtung einen eigenen Wert:
hoch
0
7 | 1
links 6—8—2 rechts
5 | 3
4
Runter

Schritt 2: Der grundlegende Treiber 
Ich beginne mit einer neuen, frisch formatierten Diskette für jeden Treiber und installiere ein DOS und den BiboAssembler auf der Diskette. Weiterhin kommt der Basis HID Treiber (Base HID Driver) und der HID Geräte Quellcode (HID Device Template Sourcecode) mit auf die Diskette.

Jeder HID Treiber Quellcode (HID Driver Sourcecode) besteht aus zwei Teilen:
* dem Basis HID Treiber Teil
* dem geräteabhängigen Teil

Der Basis HID Treiber Teil behandelt die grundlegenden Aufgaben, die für alle USB HID Geräte gleich sind:
* Copyright Nachricht ausgeben
* Reset und Initialisierung des USB Controllers
* „slow speed device“ (langsames USB Gerät) erkennen
* „USB Address 1“ an das Gerät senden und EndPoint 0 setzen
* Konfiguration 1 im Gerät auswählen
* VBI initialisieren
Wir ändern den Basis Treiber, um unseren geräteab- hängigen Teil einzufügen:

——————————
DEVICE .IN „D:device.SRC“
——————————

Schritt 3: Der Geräte-Treiber
Der geräteabhängige Teil wird in den Basis Teil eingefügt.
Der geräteabhängige Teil hat drei Hauptfunktionen:
* Ausgabe von geräteabhängigen Nachrichten
* Kopieren der USB HID Register in die ATARI Schattenregister
* Simulieren von alten ATARI Controllern (Joystick, Paddle, Tastatur)

Wir müssen nur den geräteabhängigen Teil des Treibers ändern. Zuerst müssen wir entscheiden in welche Schattenregister wir die Daten der USB Funktionen (USB HID Register) speichern. Diese Register werden aus dem USB Controller Speicher in den ATARI Speicher kopiert. Die USB HID Register beginnen ab der USB Controller Speicherstelle $10. Ich habe festgelegt, dass die USB Register in den PADDLE Registern des ATARI (Schattenregister $270-$277) abgelegt werden. Den Speicher des USB Controllers anzusprechen ist leicht. Das X-Index Register wird mit dem Wert der gewünschten USB Speicherzelle (0-255 / $00-$FF) geladen und dann wird in die Unterroutine REGFETCH gesprungen. REGFETCH gibt den Wert des der gewünschten Speicherzelle im ACCU (A) Register zurück. Der Wert wird dann im entsprechenden ATARI Schattenregister gespeichert. Weil der Treiber im VBI läuft, werden alle vom ATARI OS in diese Register gesetzten Werte überschrieben.

POLLDEVICE
LDA #03
JSR PROCESS ; nächstes USB HID Paket abfragen
LDX #$10 ; lade USB Register $10
JSR REGFETCH
STA RPADLHH ; ablegen im Schattenregister
LDX #$11
JSR REGFETCH
STA RPADLHH
LDX #$12
JSR REGFETCH
STA RPADRHH
LDX #$13
JSR REGFETCH
STA RPADRHV
LDX #$14
JSR REGFETCH
PHA ; wert auf Stack speichern
AND #$0F ; löschen von Bit 4-7
STA RPADDJY ; ablegen im Schattenregister
PLA ; alten wert vom Stack holen
LSR ; obere 4 bit nach unten shiften
LSR ; Bit 4-7 -> 0-3
LSR
LSR
STA RPADBUT1 ; ablegen im Schattenregister
LDX #$15
JSR REGFETCH

USB

Register

Byte des

HID Paketes

Funktion

Atari Memory

Schattenregist.

original Label neues

USB Label

$10 1 linker Hebel horizontal $270 (624) PADDL0 RPADLHH
$11 2 linker Hebel vertikal $271 (625) PADDL1 RPADLHV
$12 3 rechter Hebel horizontal $272 (626) PADDL2 RPADRHH
$13 4 rechter Hebel vertikal $273 (627) PADDL3 RPADRHV
$14 5 Bit 0-4 Digitales Joypad $274 (628) PADDL4 RPADDJY
$14 5 Bit 5-7 Knopf 1-4 $275 (629) PADDL5 RPADBUT1
$15 6 Knopf 5-10 $276 (630) PADDL6 RPADBUT2
$16 7 Modus Knopf Status $277 (631) PADDL7 RPADMODE

STA RPADBUT2
LDX #$16
JSR REGFETCH
STA RPADMODE
RTS

Es folgt Programmcode, um die gerätespezifischen Nachrichten auszugeben. Diese Unterroutinen werden vom Basis Treiber Teil bei der Initialisierung aufgerufen:

PRINTDEVICE JSR PRINT JSR PRINT .AS "Logitech RumblePad 2 USB Driver" .HX 40 RTS PRINTVERSION JSR PRINT .AS "Version 1.0" .HX 40 RTS PRINTCOPY JSR PRINT .AS "(c) 20041213 C. Strotmann" .HX 40 RTS

Die Unterroutine USB2ATA emuliert alte ATARI Geräte (ATARI Joystick) aus den USB-Joypad Werten. In diesem Treiber betätigen alle USB-Geräteknöpfe den Feuerknopf des ersten ATARI Joysticks. Der linke USB Hebel emuliert den digitalen ATARI Joystick 1 (STICK (1) in BASIC) und der rechte USB-Hebel emuliert den digitalen Joystick 2 (STICK(2) in BASIC).

; SCHWELLENWERT (THRESHOLD) ANALOG->DIGITAL THLEFT .HX 60 THRIGHT .HX A0 THUP .HX 60 THDOWN .HX A0 USB2ATA LDA #$0F ; Standard setzen STA STICK0 ; ATARI Joystick STA STICK1 ; Wert $0F = 15 = keine Bewegung, LDA #1 ; Standard setzen STA STRIG0 ; ATARI Knopf STA STRIG1 ; Wert $1 = 1 = nicht gedrueckt ; LDA RPADBUT1 ; irgendein Knopf gedrueckt? ORA RPADBUT2 BEQ GETSTICK ; nein! LDA #0 ; ja, Knopf Wert speichern STA STRIG0 ; GETSTICK1 Joystick 1 bearbeiten (linker Hebel) LDA STICK0 LDX RPADLHH CPX THLEFT BCC .1 ; links CPX THRIGHT BCS .2 ; rechts BCC .10 EOR #$04 ; links BPL .3 .2 EOR #$08 ; rechts .3 STA STICK0 .10 LDX RPADLHV CPX THUP BCC .11 ; hoch CPX THDOWN BCS .12 ; runter BCC .20 .11 EOR #$01 ; hoch BNE .13 .12 EOR #$02 ; runter .13 STA STICK0 .20 GETSTICK2 ; Joystick 2 bearbeiten (rechter Hebel) LDA STICK1 LDX RPADRHH CPX THLEFT BCC .1 ; links CPX THRIGHT BCS .2 ; rechts BCC .10 EOR #$04 ; links BPL .3 .2 EOR #$08 ; rechts .3 STA STICK1 .10 LDX RPADRHV CPX THUP BCC .11 ; hoch CPX THDOWN BCS .12 ; runter BCC .20 .11 EOR #$01 ; hoch BNE .13 .12 EOR #$02 ; runter .13 STA STICK1 .20 RTS

Der vollständige geräteabhängige Teil des Quellcodes befindet sich auf dem Diskettenimage

Schritt 4: Kompilieren und Testen
Jetzt kompilieren wir den neuen Treiber und testen ihn mit einem kleinen Basic-Programm.
* Wir laden den Basis Treiber Teil in den BiboAssembler und kompilieren mit ASM zu einem Binärfile (COM File).
* Wir laden den Treiber vom DOS aus
* Wir gehen ins BASIC und testen den Treiber mit diesem kleinen BASIC Programm 

100 REM Kleines USB Testprogram fuer Logitech Rumble Pad 2 USB Driver 110 REM ----------------------------------------------------------- 120 IF STICK(0) < 15 THEN PRINT "linker Hebel bewegt, Joystick 1:", STICK(0) 130 IF STICK(1) < 15 THEN PRINT "rechter Hebel bewegt, Joystick 2:", STICK(1) 140 IF STRIG(0) < 1 THEN PRINT "Knopf gedrueckt:", STRIG(0) 150 GOTO 120

Wie man ein Spiel patcht …

… um es mit dem USB-Modul zu benutzten
Das Spiel
Für diese Dokumentation habe ich das Spiel „Trailblazer“ verwendet. Das Original-Trailblazer- Binärfile (Binary=ausführbare Programmdatei) ist auf einem Disketten-Image. 

Schritt 1: Die Binär-Datei des Spiel untersuchen 
Zuerst müssen wir wissen, wohin im Speicher das Spiel geladen wird, damit wir festlegen können, wohin wir den Treiber ablegen können. Ich habe Thorsten Karwoths Power Packer benutzt, den ich auch als Linker verwende. Der Power Packer zeigt folgende Informationen:
$6D06-$7BC7
Init: $6D06
$1D00-$5AE1
Start: $E474
Mit Hilfe eines residenten Speicher-Monitors (BiboMon oder QMEQ) nehme ich die Speicherstellen ab $9000 als sicher an, es scheint, als würde das Spiel diesen Bereich nicht nutzen.

Schritt 2: Wie es funktioniert
Der Patch funktioniert, indem er die Lade-Befehle der Joystick-Register (LDA joy_nr, LDX joy_nr, LDY joy_nr) in Sprünge in eine Subroutine zum USBTreiberprogramm umwandelt (JSR adr_routine). Normalerweise werden die Werte für Joystick 1 aus der Speicherstelle $0287 (Stick0) oder direkt aus $D300 (PORTA) gelesen. In den meisten Spielen finden sich daher Maschinensprachekommandos wie LDA $0278. Danach findet sich der Wert des Joysticks im ACCURegister (oder X- oder Y-Register bei LDX/LDY) der CPU. Wir ändern dieses Kommando in einen Sprung in eine Unterroutine, nämlich die des USB-Treibers.
* Lesen des USB-Gerätes
* Konvertieren der gelesenen Werte in ATARIJoystick- Werte
* Zurückkehren aus der Unterroutine mit dem Joystickwert im ACCU

Manchmal werden die Werte in den X- oder YRegistern gespeichert, aber das Prinzip ist das gleiche. Schritt 3: Durchsuchen des Spiel Binärfiles nach Joystick-Codes Jetzt durchsuchen wir das Binärfile des Spiels nach Kommandos, die die Joystick-Schattenregister abfragen. Man benötigt dazu einen Maschinensprache- Monitor. Ich benutze BiboMon oder QMEG. Wir suchen nach der Bytefolge $78 $02, die Teil eines Kommandos wie LDA $0278 oder LDX $0278 ist. Wir suchen nach $0278 (Stick0), $D300 (PORTA) und $284 (Strig0 für den Joystick-Knopf/Trigger).

Für Trailblazer finden wir:
$26A9 — LDA $0278
$26BF — LDX $0278
$26A3 — LDA $0284
$26B3 — LDX $0284

Wir müssen also vier Speicherzellen patchen. Für den Joystick und den Trigger erstellen wir kurze Unterroutinen, die
* die CPU-Register retten
* das USB_Gerät abfragen
* die Werte des Gerätes in ATARI-Werte umwandeln
* die Werte zurückgeben
* die Register wiederherstellen

LDASTICK
STX SAVE1
STY SAVE2
JSR POLLDEVICE
JSR USB2ATA
LDA STICK0
LDX SAVE1
LDY SAVE2
RTS

Dann patchen wir die Speicherstellen, die wir vorher gefunden haben, mit Sprüngen in diese Unterroutinen

PATCH
; let’s patch
.OR $26A9
JSR LDASTICK
;
.OR $26BF
JSR LDXSTICK
;
.OR $26A3
JSR LDASTRIG
;
.OR $
26B3
JSR LDXSTRIG

Am Ende der WAITDEVICE Unterroutine entfernen wir die VBI-Registration (wir brauchen keinen VBI in einem Spiel-Patch). Dafür rufen wir den Game entry point (Startadresse des Spiels) ($E474 für Trailblazer) auf.

WAITDEVICE
(…)
JMP $E474

Jetzt assemblieren wir unseren Treiber (siehe den beigefügten Quellcode). Der Treiber ist zu 90% identisch zu einem normalen USB-Treiber.

Schritt 4: Das Spiel und den Treiber zusammenfügen/“linken“
Wir müssen den neuen Treiber mit dem original Binärfile zusammenfügen/linken. Der neue Treiber wird an das Original angehängt. Das Binärfile wird nur im Speicher, aber nicht auf der Diskette gepatcht. Dafür brauchen wir den Linker. Ich habe dafür Power Packer benutzt (auf dem Disketten-Image beigefügt). Zuerst lade ich das original Binary „TRAIL.COM“. Dann lade ich den Treiber „TRAILUSB.COM“. Der RUN-Vektor von „TRAILUSB.COM“ überschreibt den RUN-Vektor des original Binarys. Danach können wir das neue, kombinierte Binärfile speichern (.COM). Schritt 5: Das Spiel testen Wir laden das Spiel und -hey!- es funktioniert! Jetzt können wir Trailblazer mit unserem „Logitech USBJoypad“ spielen.

Um einen Treiber für ein anderes Gerät zu schreiben (USBLenkrad oder USB-Joystick oder sogar USB-Keyboard) müssen wir POLLDEVICE und die USB2ATA-Unterroutinen im Treiber mit dem geräteabhängigen Codes ersetzen.
Viel Spaß!
Florian Dingler &
Carsten Strotmann

ABBUC: Projekt Engl

Mitwirkende: Wolfgang Burger, Matthias Reichl, Florian Dingler, Torsten Schall, Guus Assmann, Bernhard Pahl Zweck: In erster Linie geht es darum (Atari-)historische Dokumente von Bernhard Engl aufzubereiten und ins Web zu stellen. Außerdem sollen die „alten“ Geräte von B. Engl wieder neu belebt werden. Copyright: Alle aufgearbeiteten Zeichnungen und Texte von B. Engl müssen auf jeder Seite folgenden Text haben: „Copyright 198X Bernhard Engl – used by ABBUC with permission“

1050 Turbo / 1986 – 1988 / Bernhard Engl
Es sind bereits Drucker-Interface für die Turbo-2 fertig gestellt und weitere 35 Platinen bestückt. Guss Assmann ist jetzt mit im Team und stellt Rekorde auf: In wenigen Tagen hat er eine funktionierende Turbo gebaut. Dazu hat er einen Neuentwurf gemacht, bei dem der Gal unter dem Eprom plaziert ist. Dadurch wird die Platine kleiner als die originale Turbo. Turbo-Freezer XL 4 / 2004 / Matthias Reichl Matthias hat den größten Happen. Er entwickelt auf der Basis des Turbo-Freezer 3 einen neuen Freezer mit zeitgemäßen und gegenüber dem Original billigeren IC. Der Prototyp mit selbst gelötetem Adapter für IC funktioniert. Ein Aufbau mit Flash-ROM und CPLD M4A5-32/32 funktioniert ebenfalls. Es wurden etliche neue Funktionen implementiert. Genaueres dazu wenn alles fertig ist. Guus Assmann hat schon mal probeweise ein Layout in PS/PDF gemacht und eine erste Platine geätzt und aufgebaut.

Bis jetzt ist Freezer, Cart-Emulation, programmieren vom Flash und RAM und alle Cartridge Emulationen getestet. UND MIT ERFOLG !!! Die RAMdisk und auch die Version mit nur RAMdisk und Emulation, also ohne Freezer muss noch getestet werden. Wir hoffen, Euch im kommenden Magazin die Hardware zum Kauf (Selbstkostenpreis) anbieten zu können. Dazu wäre für die Kalkulation wichtig, wenn Ihr schon mal Euer vorab Interesse mitteilen würdet. Das kann per Postkarte an die Clubzentrale oder per Mail an mich (Wolfgang@abbuc.de) erfolgen. Nachfolgend ein paar Zeilen von Bernhard Engl: Ein großes Lob an alle Mitglieder des Nachbau – Teams !!! (und ein wenig Philosophie über das, was wir hier tun, sei auch erlaubt!)

Ihr habt einen bewundernswerten Einsatz gezeigt, um diese alten Produkte neu zu dokumentieren, mit heutigen Bauteilen nachzubauen und damit quasi „von den Toten“ aufzuwecken. Ihr habt mir damit (und ich hoffe, auch Euch selber) eine große Freude gemacht. Es sind vor allem diese kleinen magischen Momente im Leben, die uns aus dem Alltagsleben in höhere spirituelle Sphären erheben. Die schöpferische Freude, die man empfindet, wenn ein längeres Projekt gelungen ist und das „Geschöpf zum Leben erweckt“ ist, das ist eine der besten Freuden, die es gibt. Der Advokat des Teufels würde an dieser Stelle nun einwenden, dass es eine Verschwendung kostbarer Lebenszeit sei, sich derartig intensiv mit solch alten Konzepten zu beschäftigen, anstatt die Zeit zu nutzen, um etwas „ganz Neues“ und „Nützliches“ zu schaffen, das „besser in die heutige Zeit passt“.

Meine Meinung dazu ist, dass es die Mühe wert ist, und zwar gerade deswegen, weil es sich um „alte Konzepte“ handelt – alte Konzepte nämlich, die noch so einfach sind, dass man sie in endlicher Zeit VOLLSTÄNDIG BEGREIFEN kann, wenn man so will. In unserem Fall der Atari 8-bit Homecomputer heißt das, dass jeder sich so einen Atari greifen kann und solange an den einzelnen Bits spielen kann, bis das „ganze Ding“ VOLLSTÄNDIG BEGRIFFEN ist. Das ergibt auf dem Weg dazu bei jeder kleinen Entdeckung und jedem gelungenen Programmierexperiment viele kleine magische Glücksmomente. Diese Eigenschaft eines solchen Dings an sich, nämlich von einem einzelnen Menschen in endlicher Zeit vollständig BE-GREIF-BAR zu sein, diese Eigenschaft fehlt den heutigen Computern und auch vielen anderen Hi-Tech- Produkten leider ganz und gar. Auch diese können zwar Lerneffekte bieten, aber ein Ende ist nie in Sicht, das ganze Ding ist viel zu komplex, es handelt sich um das Ringen mit Mannjahrtausenden an dort hinein geflossener Entwicklungsarbeit. Auf die Dauer ermüdet das und frustriert nur noch, weil es kein Ende nimmt, und schlimmer noch, das, was man bestenfalls dabei lernen kann, besteht größtenteils bloß aus so genanntem „Metawissen“, das sich schon nach dem nächsten Softwareupdate als nutzlos (weil nicht mehr darauf anwendbar) herausstellen kann.

Den Dingen auf den Grund zu gehen, und sich solchermaßen spielerisch ein solides und dauerhaft gültiges Grundlagenwissen zu erschließen, das gelingt bei der heutigen Technologie kaum noch jemand. Vielleicht ist es gerade deswegen die Mühe wert, unsere alten Atari – Computer (und auch andere Errungenschaften der Technik) für die Nachwelt funktionsfähi
g (und damit BEGREIF- BAR) zu erhalten. Ein reines Museum mit in Vitrinen eingesperrten Exponaten kann das BEGREIF- EN leider nicht bieten!

Übrigens benutzte ich hier absichtlich das Wort „BEGREIFEN“ statt „VERSTEHEN“, denn „verstehen“ könnte man das alles auch mit einem Simulator, der auf einem aktuellen Computer läuft. Bloß, das wäre nicht wirklich „echt“, es fehlt das reale Anfassen, Sehen und Hören des untersuchten Dings, und wenn das fehlt, dann beschleicht das Unterbewusstsein irgendwie ein Gefühl, es sei alles eh bloß ein Trugbild, und der Lern- und Speicherprozess wird dadurch beeinträchtigt. Soweit ein kleiner Einblick in den philosophischen Hintergrund unseres Tun.

(*) Damit schließt sich auch der Kreis dazu, warum es wert ist, diese alten Produkte zu bewahren und aufzufrischen. Jemand – so wie dieses Team – muss es tun, und das WWW trägt es hinaus in die Welt…
ALSO – WEITER SO !!!
viele Grüße,
Bernhard

Atari XL/XE RAMdisk-Info (Version 3.2)

Dies ist eine lange Liste mit insgesamt vier Teilen, die alle wichtigen Infos bezüglich XL-RAMdisks (RAM unter dem OS-ROM!) und XE-kompatiblen RAMdisks (gesteuert via Port B – $D301) enthält. Die Infos stammen aber nicht alle von mir, sondern (insbesondere bei Teil 2) von versch. Atarianern, die unter anderem in den Credits erwähnt werden. Sollte es also Beschwerden über unvollständige oder gar falsche Infos geben, dann denkt bitte daran, dass ich diese Infos nur gesammelt habe, um sie euch (und anderen) zur Verfügung zu stellen. Man kann den Text natürlich auch im A8FAQ von Michael Current nachlesen (subjects 8.10, 8.11 und 8.12). Genug gelabert, los geht’s:


Teil 1: RAMdisks für 64k Atari-Computer: Will man auf einem 64k Atari eine RAMdisk einrichten oder simulieren, so kann man dazu das RAM unter dem OS-ROM benutzen. Eine solche RD wird im Allgemeinen als XL-RAMdisk bezeichnet. Sie ist recht praktisch, um kleine und kurze Programme oder auch das DUP (und/oder Mem.Sav) dort zu speichern, so dass sie blitzschnell (ohne Nachladen von Disk) zur Verfügung stehen. Es muss allerdings klar sein, dass mit der XLRAMdisk alle jene Programme nicht laufen, die ebenfalls das RAM unter dem OS benötigen. Hier eine kleine Auflistung der wichtigsten DOS-Versionen und wie man dort eine XL-RAMdisk installiert:

XL-RAMdisk unter Turbo-DOS XL/XE 2.x:
Man startet zuerst den Batch-Editor BATEDIT.COM. Dort richtet man ein SETUP.BAT ein. Der erste Befehl ist RUN: <CTRL+R>, in der nächsten Zeile dann SETXLRD.COM. Danach kommt XL-RAMDISK <CTRL+X>. In den folgenden beiden Zeilen dann DUP.SYS <CTRL+D> und evtl. MEM.SAV <CTRL+M>. Das war’s dann auch schon. Das ganze sieht dann auf dem Bildschirm so aus:

RUN:
SETXLRD.COM (oder der entsprechende Name für den XL-RD-Treiber)
XL-RAMdisk: (wichtig, denn ohne diesen Befehl klappt nix!)
DUP.SYS (nun steht DUP in der RD, kein Nachladen mehr!)
MEM.SAV (kann man auch weglassen, um Platz zu sparen)

Wichtig: Der XL-RD-Treiber darf hier NICHT RAMdisk.COM heißen. Mittels Batchfile-Verarbeitung (AUTORUN.SYS in Verbindung mit SETUP.BAT) lassen sich noch weitere Programme laden, anzeigen oder in die RD kopieren. Da das RAM unter dem OS-ROM nun für die RD belegt ist, lassen sich natürlich keine Programme mehr laden, die ebenfalls diesen Speicherplatz benötigen (TB-XL, CTB-Runtime und viele andere Programme). Aber dafür kann man ja eine extra DOS-Disk ohne XL-RD-Treiber erstellen…

XL-RAMdisk unter DOS 2.5 oder MyDOS 4.x:
Hierfür gibt es jeweils externe Treiber, man nennt den Treiber für DOS 2.5 in RAMdisk.COM um, und schon hat man eine XL-RAMdisk unter DOS 2.5 mit/ohne DUP.SYS bzw. Mem.Sav. Je nach verwendetem Treiber steht nun als D3: bis D8: eine kleine XLRAMdisk zur Verfügung. Viele dieser Treiber erlauben jedoch nur eine eingeschränkte Anzahl an Dateien, die von 1 bis 16 (und nur selten bis 64) variieren kann.

Unter MyDOS 4.5x muss der Treiber AUTORUN.SYS heißen, ab Version 4.53 oder höher darf er auch *.AR0 heißen. Für weitere Autorun-Programme unter MyDOS 4.5x kann man dann ja das Batchfile- Enhancement (von Thorsten Karwoth) benutzen; ab Version 4.53 oder höher sind bis zu 10 Autorun- Programme (*.AR0 bis *.AR9) möglich. Alle MyDOS 4.x Versionen können Programme automatisch in die RD kopieren, wenn man eine SubDIR: RAMdisk anlegt und dort alle Programme reinkopiert, die man später in der RD haben will…

XL-RAMdisk unter Bibo DOS 5.x und 6.x:
Unter diesem DOS ist kein extra RAMdisk-Treiber notwendig. Bei 64k Rechnern und auch bei größeren Maschinen wird automatisch eine RAMdisk erstellt (mittels Menüpunkt „H“ DOS/DUP konfigurieren ist dies einstellbar). Sollte die eingebaute RD nicht kompatibel zur Compyshop oder Megaram 1,2,3 sein (RDBlocks 26AE), so kann man sie mit einem externen Treiber (Config.COM oder so ähnlich) konfigurieren und so das DOS entsprechend anpassen. Dies ist z.B. bei Atari Magazin oder Newell, TOMS, Rambo, und anderen RAMdisks notwendig. Es wird außerdem stets das DUP.SYS in das RAM unter dem OSROM geladen, sofern es auf der Disk vorhanden ist.
Die einzige Möglichkeit dies zu verhindern und das RAM unter dem OS unbenutzt zu lassen besteht also darin, das DUP auf der Diskette zu löschen. Mit Menüpunkt „N“ (Startup Edit) lässt sich auch eine Art Batchfile-Verarbeitung einrichten… XL-RAMdisk unter Super-DOS 2.x – 5.x: Bei allen mir bekannten Versionen von Super-DOS existiert ein File namens AUX.SYS, hiermit kann das DOS konfiguriert und ggf. das RAM unter dem OS für das DUP.SYS genutzt werden. Bei Rechnern mit mehr als 64k wird automatisch eine RD eingerichtet (mit „5-8“ als Laufwerk D5: bis D8:), ob bei Rechnern mit nur 64k auch automatisch eine XL-RAMdisk eingerichtet wird, habe ich noch nicht ausprobiert – ich vermute aber mal das dies nicht der Fall ist und man stattdessen manuell das AUX.SYS File nutzen muss (ladbar via Menüpunkt M – Binary Load)…

XL-RAMdisk unter Bewe DOS:
Da Sparta-DOS bereits selber das RAM unter dem OS benutzt, ist hier keine XL-RAMdisk möglich. Anders bei Bewe-DOS, hier ist das RAM unter dem OS frei und kann mit dem Treiber XLRD.COM (oder so ähnlich) auch als XL-RAMdisk genutzt werden. Eine Batchfile- Verarbeitung kann hier mit Hilfe des selbst zu erstellenden (Text-) Files „Startup.BAT“ genutzt werden… XL-RAMdisk unter DOS II+D Version 4.x – 6.x: Da dieses DOS nur aus einem File (DOS.SYS) besteht, ist keinerlei Nachladen von DUP.SYS notwendig. Das DOS ist also immer sofort da, wenn man (in Basic) DOS eintippt. Eine XL oder XE RAMdisk ist mit entsprechenden POKE-Befehlen einstellbar. Leichter geht es aber dieses DOS mit dem separaten File „SETUP.COM“ (nur für die Versionen 6.1 und 6.4) entsprechend zu konfigurieren. Eine Batchfile-Verarbeitung kann über das JOB Kommando genutzt werden (JOB @FILEN
AME.BAT, wie üblich ein Text-File). Es darf darauf hingewiesen werden, dass dieses DOS im Medium/Enhanced Format nicht DOS 2.5 kompatibel ist, man sollte also nur Single und Double benutzen…

XL-RAMdisk unter Top-DOS, Top-DOS Plus und Top-DOS Professional:
Zugegeben, mir ist nur die Standard-Version Top- DOS 1.5 bekannt, die Plus und Professional Versionen kenne ich gar nicht (und selbst die Standard- Version von Top-DOS benutze ich so gut wie nie). Es gibt für Top-DOS externe Treiber für Axlon, Mosaic und 130XE-Erweiterungen. Daneben ist es auch noch möglich, Top-DOS so zu konfigurieren, dass es bei 64k und 128k Rechnern das RAM unter dem OS ROM als RAMdisk benutzt. Ja sogar der Speicherplatz von Atari Basic (immerhin 8k!) kann bei Bedarf als RAMdisk benutzt werden. Und als ob das alles nicht genug wäre, sind sogar mehrere Kombinationen möglich, also z.B. 130XE-RD plus RAM unter dem OS, 130XERD plus RAM unter dem OS plus Basic-RAM oder nur RAM unter dem OS als RD, RAM unter dem OS plus Basic RAM als RD, etc. Leider ist Top-DOS nicht ganz DOS 2 kompatibel, es benutzt nämlich nie sog. Sektor/ File-Links, wodurch beim Lesen mit DOS 2 oder 2.5 stets der beliebte Error 164 auftreten würde. Und beim Enhanced Format stellt Top-DOS nur max. 944 Sektoren zur Verfügung. Angeblich soll das Kompatibilitäts- Problem zu DOS 2 und DOS 2.5 mit Top- DOS Plus und Top-DOS Prof. behoben worden sein, mangels Besitz dieser Versionen konnte ich das aber nicht testen…

Das waren dann wohl so ziemlich die wichtigsten DOS-Arten. Eine Aufzählung von weiteren DOS-Versionen erscheint mir überflüssig.
Credits: Bernhard Pahl
(Hinweise zu Turbo-DOS), Andreas Magenheimer (all the rest).

ATARI Historie

Texte schreiben kann jeder. Aber jetzt gibt es die ATARI Historie auch als ansehnliche, bewegte und interaktive Grafik.

Der ABBUC bringt nun als erster die Historie von Atari als Animation ins Internet und stellt sie in den Kontext zu anderen Ereignissen.

Andreas Bertelmann hat auf unserer WEB Site eine hervorragende Umsetzung der ATARI Geschichte programmiert. Das Ergebnis seht Ihr nebenstehend in dem Screenshot.

Man bewegt den Mauszeiger über ein Ereignis um die Timeline zu stoppen. Bewegt man den Mauszeiger wieder weg, setzt sich die Timeline wieder in Bewegung. Klickt man auf ein Ereignis, erhält man Kontext abhängige Informationen. Mit den Buttons am oberen Rand kann die Geschwindigkeit verändert werden. In der Scroll-Leiste kann man auch ein anderes Jahr auswählen.

Es funktioniert mit Java Runtime Standard Edition ab Version 1.4 und einem Webbrowser z.B.
* Firefox ab 1.0
* Mozilla ab 1.8
* Internet Explorer ab 6.0
Also sofort auf http://www.abbuc.de ausprobieren! Andreas ist für weitere Ereignisse und entsprechende Links dankbar.

Dordrecht 2005

Nachdem R.I.K. schon Samstag bei mir eingetroffen war, haben wir uns Sonntag morgen auf den Weg nach Dordrecht gemacht. Nach einer wettermäßig sehr abwechslungsreichen Fahrt mit heftigem Regen, Sonnenschein, Schnee, Hagel & kräftigem Wind sind wir nach 2 1/2 Stunden ohne (!) uns zu verfahren angekommen. Bei unserer etwas späten 😉 Ankunft waren bereits alle Tische aufgebaut und zwischen den ca. 30 Besuchern und Ausstellern herrschte reges Treiben. Wir haben uns erst einmal von Mr. Atari´s (www.mratari. com) Frau mit einem Kaffee verwöhnen lassen. Mr. Atari hatte, wie üblich, jede Menge 2600, 5200, 7800, XL, Jag & Lynx-Software dabei. Und auch ein paar (leider unverkäufliche) Raritäten, so z.B. neben einen 400er & einem 800er einen Audio-Vizuliser, der schon anfangs der siebziger zur Musik visuelle Effekte auf einen NTSC-fähigen Fernseher zaubern konnte und eine unbestückte 1450XLD-Platine.

Von Sijmen erfuhr ich noch wie er die Videos (Tron, Star Wars, South Park) auf den XL umsetzt und konnte auch ein paar Videos live auf seinem XL laufen sehen. Er hat im Übrigen Steve Tucker die Erlaubnis gegeben das MyIDE-Interface nachzubauen und zu vertreiben. Viel 8- & 64-Bit-Software gab es auch an dem Stand von „Stichting atari / www.atarimuseum.nl“ (ehemals Stichting Pokey / ANG-Software). Unter anderem konnte man hier auch die originalen ATARI-Sticks als Funkversion (von ATARI selbst!) bewundern. Wie von Guus Assmann zu erfahren war steht die XL-Version des neuen Freezers kurz vor der Serienreife. Es gibt inzwischen drei Prototypen, die zur Zeit. auf verschiedenen Systemen getestet werden. Der eigentliche Freezer wurde um einige Funktionen erweitert, so gibt es jetzt im Debugger eine Suchroutine, sowie eine Block-Move- & Block-Fill-Funktion.

Er ist mit 32k RAM ausgestattet, lässt sich aber auch mit 128K oder 512K bestücken. Es steht ein gesockelter Steckplatz für ein 29F010 Flash (128K) oder 29F040 (512K) zur Verfügung. Der Freezer emuliert 8K / 16K ATARI-Cartridges sowie OSS-Cartridges, z.B. Basic XE/XE, Mac/Bug65 oder Action. Des Weiteren gibt es noch eine SDX-Emulation (Sparta Dos 4.19…. 4.22). Diese Emulationen sind aus dem Flash, aber auch aus dem RAM möglich.

Der Freezer bietet die Möglichkeit eine Floppy zu emulieren. Dafür müsste noch ein DOS angepasst werden. Dabei könnten Guus & Matthias evt. Hilfe brauchen! Zu guter Letzt ist der Freezer dank eingebauter Schnittstelle zum PC mit Hilfe eines entsprechenden Kabels „Updatebar“ Alle Infos (inklusive Source-Codes) werden auch im Internet veröffentlicht.

Eine ganze Weile haben wir an einem Jag/7800er-Stand verbracht und aus einer kompletten Jag-Spiel- Sammlung (laut dem Besitzer fehlt nur EIN Game, welches qualitativ so schlecht war, dass er es wieder verkaufen MUßTE;-) das eine oder andere (teils seltene) Game testen können. Wir sind dann im 2-Player-Modus von Raiden hängen geblieben…

Es gab einen Stand mit originalverpackten 7800- Konsolen, an dem ich meiner einsamen 7800er endlich ein passendes Netzteil spendieren konnte. Dazu gab´s dann direkt zwei Ersatzjoypads, eine Anleitung & eine Ersatzkonsole. 😉

Mein Tower-Toppler-Modul, welches von meiner Konsole bisher verschmäht wurde, läuft auf der neuen 7800er! 🙂 Einen meiner Freunde wird´s freuen – er bekommt endlich seine Konsole zurück, die jetzt schon ein paar Jahre bei mir wohnt! Ausserdem gab es noch ein paar Stände an denen man XL/Jaguar/ST Hard- & Software ansehen bzw. kaufen konnte, unter anderem bei Bo & Ernest Schreurs und einige weitere ATARIaner, die uns namentlich unbekannt sind.

Ziemlich pünktlich um 16:30 musste die Halle dann leider auch schon wieder geräumt werden. Alles in allem war es ein schöner Tag, den wir nächstes Jahr, wenn´s passt, gerne wiederholen werden.
R.I.K./& Sleepy / Kaisersoft

ABBUC e.V. PD-Neuheiten

0699 Serie Disk-Mag: COMPY-SHOP-MAGAZIN Juli 1989 2S/ED

Es ist schon erstaunlich, was alles so in den Archiven schlummert. Auf diesem CSM befinden sich Informationen in Ergänzung zu den im letzten Heft zum Clubmagazin veröffentlichten Kapitel 1 zu ATARI-Cartridges (Das Geheimnis der Module). Daneben eine Menge interessanter Informationen, Programme, Teste wie Programmieren in 6502 (Teil 12), Welt der Fraktale 4 von Peter Sabath, Videoverstärker für 600/800 XL, Peter Sabaths Disk Doktor, ZS-Editor für den 1029 und mehr. Besonders Fans der Fraktale kommen auf der Rückseite

0700 Serie Disk-Mag: COMPY-SHOP-MAGAZIN August 1989 2S/ED

Auch auf diesem CSM schlummern Schätze. Vor allem das Hypra-Soft-BASIC von Uwe Röder in Verbindung mit dem ROM-Simulator von Erwin Reuß ist ein Beweis dafür (wieder einmal), dass man als ATARIaner mit ein wenig Wissen und Eigeninitiative dem XL/XE immer wieder neues und noch mehr Leistung entlocken kann. Das HS-BASIC wurde um 40 Befehle erweitert! Der ROMSimulator ergänzt wiederum die Artikelreihe zu Cartridges im Clubmagazin. Daneben Teil 13 von Programmieren in 6502, Fraktale Teil 5, 10 Jahre ATARI und Demos, Katalog, etc.

0701 QUICKmagazin 3 & QUICKdemo 3 Joystick 2S/ED

Die Themen: Erweiterung und Verbesserung von Quick zur Version 2.0. Entprechende Anleitungen sind auf der Disk. Die neuen Befehle, Änderungen im Compiler, weitere Änderungen sowie generelle Infos zum Quick 2.0 System sind wirklich etwas für alle, die die Version 1.6 updaten wollen. Daneben Hinweise zu Rekursiven Programmieren, Der Display List Interrupt, DLIs in QUICK sowie passende Demos. Dazu auf der B-Seite weitere Demos:

0702 QUICKmagazin 4 & QUICKdemo 4 Joystick 2S/ED
Weiteres Futter für angehende Programmierer und solche die es werden wollen. Die langen Winterabende laden förmlich dazu ein und wer weiß, vielleicht finden sich dann interessante, neue Programme als Teilnehmer am Programmierwettbewerb 2004/2005. Auf geht’s an die Tasten! Die Themen: Die CHR-Library, Digital- Sounds, Türme von Hanoi, OS-Header, Runtime Update, Runtime Sprungtabelle und dazu Demos und weitere Demos auf der B-Seite. Dann QUICKt mal schön.

ABBUC e. V. – Public Domain Software-Bibliothek
c/o Walter Lojek – Willem de Zwijgerstraat 20 – NL-6021 HM Budel
PD@ABBUC.DE

Dieses ABBUC Magazin erschien ursprünglich als Papierbeilage. Aufbereitung für HTML: Andreas Bertelmann