ABBUC Magazin 084


IMPRESSUM
© 2002 Atari Bit Byter User Club e.V.
C/O Wolfgang Burger, Wieschenbeck 45
D-45699 Herten ???? +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 SIO2USB Interface
Seite 6 Test SIO2IDE Interface
Seite 9 Hardwarewettbewerb 2006
Seite 11 Softwarewettbewerb 2006
Seite 12 LOGO die unterschätzte Programmiersprache
Seite 16 Spieletest REAXION
Seite 18 TRS- Desktop
Seite 21 Atari XL/XE RAMdisk-Info (Version 3.5) Teil 4
Seite 26 Spieletest VENUS EXPRESS
Seite 28 XL/XE DOS „Top 10“
Seite 32 PD-Neuheiten

SIO2USB Interface

Beschreibung:
Das SIO2USB-Interface ist eine Hardware Erweiterung zum Anschluss an den ATARI 8-bit Rechner (400, 800, 600XL, 800XL, 130XE). Das Gerät simuliert eine ATARI 1050 Floppy und wird über den SIO-Bus angeschlossen. Dieser ermöglicht den einfachen Anschluss des Gerätes an jeden ATARI Rechner ohne zusätzliche Adapterplatinen, Öffnen des Rechners, Einbau von Hardware oder Anbringung von Gehäuseöffnungen am ATARI. Das SIO2USB-Interface simuliert ATARI 1050 Diskettenstationen und ist damit voll kompatibel zu jedem Betriebssystem oder Betriebssystemerweiterung. Es können wie gewohnt weiterhin alle anderen Peripheriegeräte zeitgleich an den SIOBus angeschlossen und genutzt werden. Ein handelsüblicher PC USB Memory-Stick dient als Speichermedium zum Ablegen der virtuellen ATARI Disketten. Dieser wird direkt an das SIO2USB- Interface angesteckt und enthält ein normales FAT16 Filesystem, in dem die ATARI 1050 Disketten als je ein PC-File (Image) abgelegt werden.

Die Verwendung eines weit verbreiteten und preisgünstigen PC Speichermediums mit Standard PC-Filesystem erlaubt eine einfache Handhabung, die Doppelnutzung an PC und ATARI sowie ein einfaches Backup der Daten. Das SIO2USB-Interface unterstützt das zeitgleiche emulieren von mehreren ATARI 1050 Diskettenstationen. Ein vierzeiliges LCD-Display im SIO2USB-Interface erlaubt es dem Benutzer jederzeit den Status der Diskettensimulation(en) zu erkennen und weitere Informationen abzurufen. Dies ist unter anderem der Dateiname der Diskettensimulation, die Zuordnung zur Diskettennummer (D1, D2) und der aktuelle Status (aktiv/inaktiv). Da viele ATARI Programme über mehr als eine Diskettenseite verfügen aber nicht mehrere Diskettenstationen unterstützen, hat das SIO2USB- Interface eingebaute Tasten die unter anderem auch das einfache Tauschen von vorher ausgewählten Diskettenimages erlauben und das Aktivieren oder Deaktivieren von simulierten Diskettenstationen.
Das Selektieren von Files zur Diskettensimulation kann wahlweise über
1. die Tasten und das Display des SIO2USB- Interface erfolgen oder
2. über ein Menüprogramm auf dem ATARI oder
3. direkt auf dem USB-Stick am PC erfolgen 

Das SIO2USB-Interface verfügt über eine eigene batteriegepufferte Echtzeituhr (RTC). Diese sorgt dafür, dass Änderungen auf dem USB-Stick mit dem richtigen Datum und Uhrzeit versehen werden. Das Datum und die Uhrzeit sind auch über den SIO-Bus vom ATARI abrufbar (z.B. für Sparta DOS). Die Spannungsversorgung des SIO2USBInterface und des angeschlossenen USB-Sticks erfolgt von ATARI Rechner über den SIO-Bus. Somit ist keine externe Spannungsversorgung notwendig. Den benötigten Strom hat jeder Standard- ATARI verfügbar. Optional können das SIO2USB-Interface und der USB-Stick auch über ein externes Netzteil versorgt werden, falls der ATARI-Rechner aufgrund eingebauter Erweiterungen nicht mehr in der Lage ist das SIO2USBInterface zu versorgen.

Die Firmware des SIO2USB-Interface besteht aus zwei Teilen: dem Bootcode und dem Applikationsteil. Der Bootcode ist fest im Gerät integriert und kann nicht vom Anwender verändert werden. Der Applikationsteil kann über den ATARI neu programmiert werden. Somit kann der Benutzer Softwareupdates – die z.B. via Internet verbreitet werden – selbst in das SIO2USB- Interface laden ohne das Gerät einschicken zu müssen oder spezielle Ladekabel zu verwenden. Der residente Bootcode stellt sicher, dass jederzeit ein neuer Applikationsteil geladen werden kann, selbst wenn beim Programmieren des Applikationsteils ein Fehler auftreten sollte (z.B. Stromausfall). Das SIO2USB-Interface erlaubt auch die Datenübertragung in Speedy 1050 Geschwindigkeit (ca. 57kbit/s) oder Standart 1050 Geschwindigkeit (ca. 19kbit/s). Es ist kompatibel zur Speedy 1050, jedoch werden nicht alle Funktionen der Speedy 1050 unterstützt.

Zusammenfassung:
Das SIO2USB-Interface bietet eine kompatible Lösung ohne Löten und Schrauben und ohne Inkompatibilitäten aufgrund geändertem Betriebssystem oder ähnlichen Eingriffen in den Standart. Die Daten werden auf einem einfach erhältlichen, preisgünstigen und handlichen PCSpeicher abgelegt. Der Speicher kann auch für den PC Einsatz weiterbenutzt werden und der Inhalt kann leicht und schnell gesichert werden (Backup).

Das Gerät benötigt keine eigene Spannungsversorgung und kann über die eingebauten Tasten und das Display oder über den ATARI Rechner gesteuert und programmiert werden. Mehrere Diskettenstationen werden gleichzeitig simuliert und die Highspeed Übertragung der Speedy 1050 wird unterstützt. Entwicklungsstand / Hilfsmittel: Die Entwicklung des SIO2USB-Interfaces wurde vor ca. 2 Jahren von Mitgliedern der ABBUC Regionalgruppe Frankfurt / Main (RAF) gestartet. An der Entwicklung beteiligt sind
* Thomas Grasel (Hardware und Firmware)
* Harry Reminder (ATARI Software)
* Carsten Strotmann (USB Software).

Die SIO2USB-Interface Hardware ist bereits serienreif aufgebaut und funktioniert stabil. Der Software-Bootcode ist fertig und das Programmieren des Applikationsteils via ATARI funktioniert ebenfalls bereits. Um die Programmierung eines USB-Treiber zu erleichtern, und von der SIO2USB Hardware unabhängig zu sein, wurde ein Inbetriebnahme- Board entwickelt, welches den Anschluss des verwendeten USB-Ch
ips an den Modulschacht eines ATARI-Rechners ermöglicht. Dieses Inbetriebnahme- Board ist mittlerweile als USBCartridge bekannt und für andere USBAnwendungen erhältlich.

Am USB-Treiber für USB Memory-Sticks wird von Carsten Strotmann noch gearbeitet. Um die SIO2USB-Hardware zu testen und die Firmware zu entwickeln wurde ein weiteres Inbetriebnahme-Board entwickelt. Dieses Board wird direkt an die CPU des SIO2USB-Interfaces angeschlossen und beinhaltet einen FLASH Speicher und weitere Ansteuerelektronik. Dort können zurzeit Daten anstatt auf dem USB-Stick abgelegt werden.

Erfolgreich konnten auf diesem FLASH bereits zwei Diskettenimages abgelegt und vom ATARI darauf zugegriffen werden. Zurzeit erfolgt die Implementierung des FAT16 Filesystems auf diesem FLASH. Zur Überprüfung der Datenübertragung zwischen ATARI und SIO2USB-Interface bzw. ATARI Diskettenstationen wurde ein weiteres Gerät entwickelt, der SIOSpy. Dieser erlaubt es die Datenübertragung auf dem SIOBus auf einem PC sichtbar zu machen und hat schon beim Auffinden einiger Fehler und undokumentierten Teilen des SIO-Protokolles geholfen. Thomas Grasel / Harry Reminder 09.08.2005 für den ABBUC Wettbewerb „beste Hardware in Entwicklung“ 2005


SIO2IDE

Für das anschließen von Festplatten an den Atari gibt es verschiedene Lösungen. Das Problem ist, dass die meisten nicht mehr hergestellt werden und somit nicht mehr erhältlich sind. Als Besitzer des MyIDE hätte ich zwar eine Lösung parat gehabt, aber meine Wünsche an so ein Interface sind schon recht genau. Das MyIDE als externe Lösung, belegt den Cartridge-Port. Wenn man aber z.B. den Atari Writer oder ein Turbo-Modul für Kassetten verwenden will und gleichzeitig auf Festplatte schreiben möchte, steht man im Regen. Die interne MyIDE Variante gefiel mir da besser. Hier muss man allerdings einige Drähte anlöten, wodurch es an den Atari gebunden ist. Auf Dauer war das für mich keine Lösung. Das KMK-Interface, ist an den XE gebunden und belegt zudem permanent den Cartridge/ECIAnschluss. Diese Lösung ist also auch nichts wenn man z.B. eine andere Erweiterung verwendet, die den PBI bereits belegt hat. Am besten gefiel mir jedoch eine Lösung die am SIO Bus angeschlossen werden kann.

Deshalb habe ich sofort zugeschlagen, als bei eBay das SIO2IDE 4.4 Interface mit CFUnterstützung angeboten wurde. Immerhin kann man auf der angeschlossenen Festplatte einfach die ATR-Files als Laufwerke ansprechen. Dabei kann ein ATR File bis zu 16MB groß sein. 55 US-Dollar pro Stück (47 Euro) kostete ein Interface. Der Versand erfolgte aus Frankreich. Damit sich die Versandkosten lohnten, habe ich dann auch gleich zwei Stück bestellt. Inklusive Versand habe ich dann 101 Euro bezahlt. Da ich per Paypal zahlte, war das Geld nach 3 Minuten dort gebucht. Schon sieben Tage nach der Auktion hielt ich die Interfaces in der Hand. Turbomäßig schnell !

USB-Anschluß
Genauso turbomäßig begannen dann auch die Problemchen. Das SIO2IDE hat eine Besonderheit: Es besitzt optional einen USB Anschluss! Das erlaubt es die Festplatte entweder am Atari oder am USB zu betreiben. Die gekaufte Variante enthielt aber weder USB Chip noch die USB Buchse. (Daher war es so günstig) Da ich mit dem Lötkolben umgehen kann, war das aber kein Problem. Nach langer Suche dann die Info: Die USB Chips werden nicht mehr hergestellt! Bei Reichelt und Conrad nicht mehr zu bekommen. Um es kurz zu machen: Bei Schuricht wurde ich fündig. Allerdings verkaufen die nur an Firmen. Nach zwei Wochen hatte ich die fehlenden Teile zusammen und das nächste Problem trat auf: Die USB Chips sind SMD Chips, also winzig klein. Mit einem normalen Lötkolben ist da nichts zu machen. Also musste noch Lötpaste gekauft werden (14 Euro), aber dann ging es los.

Nachdem alles zusammen gebaut war, kam der erste Test am Atari: Erfolglos! Die USB-IDE Verbindung lief zwar problemlos, aber der Atari erkannte die Festplatte nicht. Und nun wird es für alle (technisch) interessant, die sich mit dem Interface beschäftigen wollen. IDE Geräte einrichten Man sollte die beigefügte Dokumentation fast wörtlich nehmen. Die Festplatte muss unter DOS partitioniert und formatiert werden. Bei der CFKarte darf die Formatierung unter Windows erfolgen (bei mir Windows 2000) In der Doku steht zwar etwas anderes, aber auf meine Aussage kann man sich verlassen. Ich habe es ausführlich getestet und X-mal partitioniert und formatiert. Auf jeden Fall sollte man entweder FAT16 oder FAT32 formatieren. Ob mit oder ohne LFN Option ist egal. Das Interface unterstützt auch lange Dateinamen. Um diese am Atari sehen zu können, muss man nur die Leertaste drücken.

CF-Karten
Getestet habe ich verschiedene CF-Karten: 256MB Hama, 512MB Sandisk, 1GB Transcent. Alle Karten liefen am CF2IDE das am SIO2IDE angeschlossen wird problemlos. Nur die Hama Karte musste ich zuerst unter DOS mit Fdisk einrichten.

Festplatten verwenden
Wer denkt er könne für das Interface eine uralte Festplatte verwende, sei vorgewarnt: Ich habe 5 verschiedene Platten mit 128 bis 256 MB getestet. Nur eine einzige funktionierte am Interface. Und die hatte dann nach 2 Tagen ein defektes Dateisystem. Die 3GB 2,5″ Platte hingegen läuft problemlos, ist schnell und leise. Alte Geräte vertragen sich nicht dauerhaft mit dem SIO2IDE Interface!

Zwei IDE Geräte anschließen
In der Anleitung steht, dass man ZWEI Festplatten (o.a.) gleichzeitig verwenden kann. Das wollte ich dann auch testen. Aber auch nach 2 weiteren Tagen war es mir nicht gelungen zwei IDE Platten zu betreiben. Die Master Platte war immer erreichbar. Aber die Slave Platte lies sich nie ansprechen. Auf dem Interface befindet sich ein Jumper, mit dem man Master und Slave tauschen kann. Das funktioniert tatsächlich und sogar während des Betriebes. Dann war eben der Master der Slave und der Slave, der zum Master wurde, ließ sich nicht ansprechen.

CD-Laufwerk verwenden
Angeblich soll man auch CD Laufwerke am SIO2IDE betreiben können. Man muss nur ein bestimmtes DOS Format auf der CD berücksichtigen. Aber leider verlief auch dieser Test negativ. Drei CD/DVD Laufwerke hatte ich zum Test. Zwar wurden die CDs erkannt und das Interface schaltete auf „Ready“, aber dennoch konnte ich nicht von CD booten.

Zweimal D1: am Atari
In jedem Verzeichnis in dem ATR-Files stehen, muss eine CFG-Datei stehen, in der die Laufwerkszuordnungen D1-D8 eingetragen werden die sich auf die ATRs im selben Verzeichnis beziehen. Das Interface bietet eine Notfall- Lösung. Im CFG-File des Hauptverzeichnis kann man zusätzlich ein Laufwerk D9 definieren. Dieses ist über alle Verzeichnisse als D1 ansprechbar. Dazu muss man nur auf dem Interface den Jumper HD1_ZW umstecken. Sollte man sich also versehentlich das Boot- ATR zerschossen haben, steckt man den Jumper um und bootet von D9 das dann als D1 angesprochen wird.

Die ATR-Files
…ein heikles Thema. Das SIO2IDE nimmt es sehr genau! Zu verwendende ATR müssen einen sauberen Header haben! Stimmt ein Byte nicht, wird
es vom Interface nicht erkannt. Während ich mit den ATR-Files hantierte musste ich feststellen, dass die Tools atariman und AtrUtil die Header nicht sauber schreiben! Statt dessen habe ich dann APE verwendet.

Das CFG-File
…ist eine reine Text-Datei in der die Zuordnung D1-Dx zu den Dateien vorgenommen wird. Die Dateinamen müssen in Großbuchstaben geschrieben sein. Dieser Hinweis ist nirgends zu finden sind! Weder in der Doku, noch auf der polnischen Homepage oder den amerikanischen Foren gab es Hinweise. Evtl. handelt es sich um einen Bug in der Version 4.4. Das bleibt noch zu klären.

Die USB-Verbindung
Auch sei die folgende Einschränkung nicht verschwiegen: Eine USB Verbindung ist extrem langsam. Erst dauert es unter Windows 2000 gut 2 Minuten bis das Interface erkannt wird (Windows 98: 5 Minuten) und dann braucht die Übertragung von 14 MB geschlagene 15 Minuten. Wenn man weniger als 50 ATRs kopieren will, ist das sicher nicht so relevant. Aber wenn man mehr zu übertragen hat, sollte man die Festplatte direkt am PC anschließen. (nicht über SIO2IDE)

Der Erfolg
Aber als dann alle diese Hürden erkannt und überwunden waren, lief es einwandfrei. Der Atari bootet mit Turbo-Highspeed. Die Ladegeräusche am Monitor verkommen da fast zu einem einzigen Pfeifton. Eine Diskette ist in wenigen Sekunden eingelesen. So wollte ich es haben! Nicht sehr schön gelöst ist, dass man zwar Verzeichnisse auf der Festplatte haben kann, dort aber in jedem Verzeichnis eine Datei Namens SIO2IDE.CFG vorhanden sein muss. Ansonsten wird beim Verzeichniswechsel der Fehler angezeigt: „Kein SIO2IDE Dir“. Die auf der Festplatte liegenden ATR-Files können im laufenden Betrieb gewechselt werden.

Fazit:
Ich stehe mit gemischten Gefühlen vor dem SIO2IDE. Das was funktioniert beeindruckt sehr. Insbesondere der Wechsel der Konfiguration im laufenden Betrieb und die extrem hohe Datenübertragung. Die Probleme zu Master/Slave und CD-Rom hoffe ich durch ein „Bios-Update“ aus dem Weg zu räumen, wenn es denn verfügbar ist. Aus diesem Grund habe ich mit Marek Mikolajewski Kontakt aufgenommen der das SIO2IDE Interface gebaut hat und weiter entwickelt. Bernd Herale ist ebenfalls mit im „Boot“ und wird wie ich die neue Firmware testen. Nach Informationen von Marek kann das helfen bisher nicht freigeschaltete oder nicht voll getestete Funktionen im SIO2IDE zu aktivieren und zu testen.

Es gibt nun also wieder eine weitere deutsch/ polnische Verbindung 😉 Hier aber noch etwas zu den Kosten (jeweils inkl. Versand):
* 2 SIO2DIE: 101 Euro
* 2 USB-B Buchse: 0,60 Euro
* 2 USB Chip 29,00 Euro
* 1 Lötpaste 13,80 Euro (passende Lötstation vorausgesetzt)

Auf der JHV 2005 wurde die Entwicklung des SIO2USB vorgestellt. Ich bin schon sehr gespannt darauf. Gerne hätte ich das SIO2USB sofort bestellt, aber etwas muss ich mich wohl noch gedulden, bis die Entwicklung abgeschlossen ist.
Andreas Bertelmann
(ABBUC Webmaster)

ABBUC e.V. Wettbewerb
Hardware 2006

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 2006 erfolgen:
?? Preis „beste Hardware 2006“
?? Sonderpreis „beste Hardware 2006 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 2006 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, d ass spe z i e l l e So f twa r e s (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 2006“ (siehe auch Punkt 1.5 Anmeldeschluss)
* Vorlage von aussagefähigen Unterlagen/ Beschreibungen bei der Teilnahme „beste Hardware 2006 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 2006“ vorgesehene Hardware muss bis spätestens 15.08.2006 beim Ressortleiter Hardware zur Prüfung eingegangen sein. Hardware, die nicht, bzw. verspätet zur Prüfung eingegangen ist, kann nicht am Wettbewerb 2006 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 2006 ermittelt. Die Abstimmung erfolgt per Abstimmungsbogen. Wahlweise kann die Abstimmung auch per Post erfolgen. Der Abstimmungsbogen wird jedem Clubmitglied mit dem vor der JHV 2006 erscheinenden Clubmagazin zugestellt. Einsendeschluss für die Postabstimmung ist der 20.10.2006

1.8 Preisgelder
Der Preis für die „beste Hardware 2006“ ist mit einem Preisgeld in Höhe von EUR 500,00 dotiert. Der Sonderpreis für die „beste Hardware 2006 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.

Bitte Teilnahmeformular aus dem WEB laden und ausgefüllt und unterschrieben per Post oder Fax schicken.

AN: ABBUC e. V.
Ressort Hardware
c/o Andreas Mischka
Pfarrstr. 7
D-89165 Dietenheim
GERMANY

ABBUC e.V. Wettbewerb
Software 2006

1. Allgemeine Regeln:
Der Abgabeschluss für den Software-Wettbewerb wurde auf den 15. August 2006 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 Erstveröffentlichungsrecht für das Magazin bzw. den Software-Wettbewerb; 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.) und
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) wird (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. Zu den Programmen bzw. Kompilaten muss keinerlei Sourcecode beiliegen, das fertige bzw. lauffähige Programm ist schon ausreichend.

Also dann, viel Spaß beim Programmieren – euer ABBUC Software Ressort.
(Charlie Chaplin / Andreas Magenheimer)

LOGO

– die unterschätzte Programmiersprache Was kommt einen in den Sinn, wenn man an die Programmiersprache LOGO erinnert wird? Turtle Grafik und Schule. Logo ist vor allem durch die einfache Turtle (Schildkröten) Grafik bekannt geworden und wurde in der 80er Jahren im Schulunterricht eingesetzt, um Computergrundlagen und Programmierung zu vermitteln. LOGO eignet sich hierfür sehr gut, da die Sprache einfach zu erlernen und die Programmausführung interaktiv ist.

Anfänger haben sehr schnell Erfolgserlebnisse, wenn sie die Turtle Über den Bildschirm bewegen und die ersten Programme erstellen. Aber diese Eigenschaften haben dazu geführt, das LOGO oftmals in eine Schublade als „Spielzeug-Programmiersprache“ gesteckt wird (ein Beispiel für e ine echte „Spielzeug- Programmiersprache ist Atari-Pilot). „Eine Sprache die Kinder in der Grundschule lernen, das kann ja nichts für ernsthafte Programmieraufgaben sein“.

Falsch. Als Wally Feurzeig und Seymour Papert die Sprache LOGO in den 60er Jahren entwickelten, so nahmen sie sich eine der mächtigsten Programmiersprachen zum Vorbild: LISP. (LISP war damals nicht nur Vorbild für LOGO, sondern auch Grundlage: die ersten LOGO Versionen waren in LISP geschrieben). Man kann LOGO als eine gekonnte Verschmelzung der besten Seiten von BASIC und LISP sehen. Wie in BASIC gibt es Befehle (Commands), welche Effekte erzeugen, z. B. der PRINT Befehl, der Daten auf dem Bildschirm ausgibt, oder der TOOT Befehl zum Erzeugen von Tönen. Befehle ergeben immer einen Effekt, aber Befehle geben nie Ergebnisse zurück. Diese Art von Programmteilen wird für einen Programmstil benutzt, der imperative (befehlende) Programmierung genannt wird. (BASIC, wie auch ACTION!, Quick oder Pascal und C sind imperative Programmiersprachen). Wie in LISP gibt es in LOGO aber auch Funktionen (Operations), Programm-Module die ein oder mehrere Eingabewerte aufnehmen, diese Werte bearbeiten und ein Ergebnis zurückliefern. Diese Art von Programmierung nennt man funktionale Programmierung. Die imperative Programmierung ist vielen von BASIC oder PASCAL und C bekannt. Die funktionalen Programmiersprachen sind weniger bekannt, aber deshalb nicht weniger interessant. In der funktionalen Programmierung zerlegt man das Problem in viele kleine Einheiten, die Funktionen. Diese Funktionen werden dann ineinander verschachtelt, wobei immer die Rückgabewerte anderer Funktionen die Eingabewerte einer nachfolgenden Funktion werden. Hier ist ein Beispiel aus LOGO:

?PRINT FIRST BUTFIRST BUTFIRST BUTFIRST
„ABBUC“
U
?
Das Fragezeichen „?“ ist die Atari-LOGO Eingabeaufforderung.
Die Ausgabe der Befehlszeile ist das Zeichen „U“.
PRINT ist der einzige Befehl in dieser Befehlskette, er ist dafür zuständig das Ergebnis der Funktionen auszugeben (und das Ergebnis war der Buchstabe „U“).

Was ist nun genau hier passiert? Um Funktionsketten zu verstehen, müssen wir die Kette von rechts nach links Nachverfolgen: „ABBUC ist eine Zeichenkette (String) BUTFIRST ist eine Funktion, welche einen Eingabewert annimmt and von diesem Eingabewert alles bis auf das erste Element zurückgibt. FIRST ist eine Funktion, welche genau das Gegenteil bewirkt. Sie nimmt einen Eingabewert und liefert von diesem Eingabewert nur das erste Element zurück. Der ursprüngliche Eingabewert „ABBUC wird von jeder Funktion bearbeitet und das Ergebnis dann an die weiter links stehende Funktion weitergegeben. Die Zwischenergebnisse werden vom LOGO automatisch von Funktion zu Funktion übergeben, ohne das wir diese in Variablen zwischenspeichern müssen. Daher kommen wir bei funktionaler Programmierung in LOGO mit viel weniger Variablen als in BASIC oder anderen Sprachen aus.

Schritt für Schritt:
Ist LOGO nun eine imperative (wie BASIC) oder eine funktionale (wie LISP) Programmiersprache? Die Antwort: beides. LOGO hat die einfache Befehlsstruktur von BASIC und die mächtigen Funktionen und Listen von LISP. Das Beste aus beidem, und wir haben als Programmierer die freie Auswahl. Weitere bemerkenswerte Fähigkeiten von LOGO: LISTEN als
Datentypen. Listen sind eine sehr mächtige Möglichkeit, Daten zu speichern. Im Grunde verhalten sich Listen wie ARRAYS, nur mit dem Unterschied das der Programmierer beliebig Daten zu einer Liste hinzufügen kann. Listen können andere Listen enthalten und diese auch wiederum Listen. Dynamische Speicherplatzverwaltung: Der Speicherplatz in Logo wird dynamisch verwaltet ähnlich wie heutzutage in Java. 

Funktion Ergebniss Effekt
„ABBUC ABBUC keiner
BUTFIRST BBUC keiner
BUTFIRST BUC keiner
BUTFIRST UC keiner
FIRST U keiner
PRINT U wird ausgegeben

Der Programmierer muss sich nicht um das Anfordern und Freigeben von Speicher kümmern, LOGO übernimmt diese Aufgabe automatisch. Eigenschaftslisten (auch benannte Listen): in diesen Listen haben die gespeicherten Datenwerte einen Namen und können über diesen Namen angesprochen werden. Dies ist vergleichbar mit den assoziativen Arrays in Perl oder ähnlichen Sprachen wie Ruby oder Python. Dies ist eine Funktion, welche man in keiner anderen Programmiersprache auf dem Atari findet. Um Eingenschaftlisten nutzen zu können, müssen die Definitionen in der Datei „PPROP.LGO“ in das Atari Logo geladen werden (Befehl LOAD „D:PPROP.LGO) Beispiel eines Übersetzungsprogramms, wir erfassen die Vokabeln in einer Eigenschaftsliste:
pprop „buch „englisch „book
pprop „buch „französisch „livre
pprop „buch „spanisch „libro
pprop „buch „italienisch „libro
pprop „buch „deutsch „buch

Wir haben in der Liste „buch“ verschiedene Übersetzungen des Wortes Buch gespeichert.

Diese können wir nun mit Namen abrufen:
?print gprop „buch „spanisch
libro
?

Unser Beispielprogramm fragt den Benutzer, welche Vokabel er übersetzt haben möchte, und fragt dann in welche Sprache diese Vokabel übersetzt werden soll. Ist eine Übersetzung vorhanden, so wird diese ausgegeben, ansonsten wir eine Fehlermeldung an den Benutzer ausgegeben, dass diese Übersetzung nicht verfügbar ist. Das vollständige Übersetzungsprogramm befindet sich auf der Heftdiskette unter dem Namen „UEBERSET.LGO“ und kann mit LOAD „D:UEBERSET.LGO geladen werden. Das Programm startet automatisch. Das Übersetzungsprogramm zeigt auch, das in LOGO die Namen für Variablen, Listen und Eigenschaftslisten dynamisch im Programm bearbeitet werden können. In Basic und allen kompilierten Sprachen ist das nicht möglich. Zum Beispiel ist es in Basic nicht ohne Tricks möglich, den Benutzer zum Laufzeit des Programms nach dem Namen einer Variablen zu fragen und dann den Inhalt dieser Variablen anzuzeigen. 

In LOGO geht das so:
PRINT THING FIRST RL
RL – (Read Line), Einlesen des Namens der
Variablen
FIRST – wir möchten nur das erste Wort der eingelesenen Zeile
THING – wir möchten gerne den Inhalt des „Dings“ mit den eingegebenen Namen
PRINT – druckt dann den Inhalt aus 

Beispiel:
MAKE „VARIABLE „ABBUC PRINT THING
FIRST RL
Wenn nun der Name der Variable „VARIABLE“ eingegeben wird, ist die Ausgabe „ABBUC“.

Eng mit dieser Fähigkeit von LOGO verknüpft ist die Möglichkeit, Programme während der Ablaufzeit des Programms zu verändern und auszuführen. Programme in LOGO sind nichts weiter als in Listen gespeicherte LOGO Befehle. Wir können uns neue Listen mit Befehlen erstellen und diese mit dem Befehl RUN zur Ausführung bringen. Hier ist eine Routine mit der wir in LOGO interaktiv Funktionen und Befehle auf das Wort „ABBUC“ ausprobieren können:

TO AUSPROBIEREN
PRINT [BITTE GIB DEN BEFEHL ODER DIE
FUNKTION EIN]
MAKE „BEFEHL FIRST RL
PR [DAS ERGEBIS IST]
PR RUN SE :BEFEHL WORD „“ „ABBUC
END

Und noch eine ungewöhnliche Eigenschaft: die „Dämonen“. Die „Dämonen“ sind eine Spezialität des Atari LOGOS und nicht unbedingt auch in anderen LOGO Varianten zu finden. Die Dämonen eignen sich zu einer LOGO eigenen Interruptprogrammierung, sogar um ein wenig „Multitasking“ zu erzeugen. Jedem „Deamon“ wird ein Ereignis zugewiesen (Auf eine Player Missile Kollision zu achten, auf eine Joystickbewegung oder Joystick-Knopf, oder ein Timer) sowie eine Liste von Befehlen. Tritt das Ereignis auf, wird automatisch sofort die Liste der Befehle ausgeführt. Das heißt als Programmierer müssten wir nicht den Joystick abfragen, wir können diese Aufgabe einem „Dämonen“ übertragen, welcher im Hintergrund den Joystick überwacht und bei einer Joystickbewegung unsere Befehle ausführt.

Zum Ende des Artikels noch ein paar Worte darüber, was LOGO nicht ist. Mit LOGO können wir keine zeitkritische Systemprogrammierung durchführen, LOGO ist hierfür zu langsam. Die Geschwindigkeit von LOGO ist vergleichbar mit normalem Atari BASIC. Alle Aufgaben für die Atari BASIC schnell genug ist, sollten sich auch in LOGO gut lösen lassen. Des Weiteren ist der Speicherbereich von Atari LOGO auf 32 Kilobyte beschränkt (48 KB des Atari 800 minus 16 KB Modul). Hiervon ist noch der Speicher abzuziehen, der für das DOS benötigt wird. Bei größeren Programmen kann man schon mal an die Speichergrenzen gelangen und muss dann sein Programm „aufräumen“. Aber auch das kennt man von BASIC. Ich hoffe bei Euch ein wenig Interesse für Atari LOGO geweckt zu haben. In den kommenden Ausgaben des ABBUC Magazin gibt es einen kleinen Einführungskurs in LOGO. Wer nicht bis dahin warten kann, findet Informationen und Anleitungen rund um Atari LOGO auf den Webseiten der ABBUC Programmers Group.
Carsten Strotmann

 


REAXION
Spieletest

Reaxion von TMR / Cosine
Am 31.12.2005 erschien ein neues Spiel für den ATARI XL. Das ist erstmal keine so ungewöhnliche Nachricht. Auch wenn solche Nachrichten immer seltener werden und wir uns daher umso mehr freuen.

Ungewöhnlich ist jedoch, wer es herausgegeben hat. Es wurde von der englischen C-64-Demo- Group Cosine herausgegeben. Jason Kelk alias TMR /Cosine ist seit einiger Zeit jedoch regelmäßig mit Posts im AtariAge-Forum vertreten. Er setzt sich offensichtlich auch intensiv mit dem Atari auseinander. Das merkt man bei dem vorliegenden Spiel. Ihm ist eine vorzügliche Umsetzung des gleichnamigen C-64-Spieles gelungen. Das Original programmierte TMR bereits 1994 und veröffentlichte es in der Ausgabe 47 des Magazins „Commodore Format“. Ursprünglich hatte es 30 Level. 1995 setzte er es für Commodore Amiga um – jetzt mit 99 Leveln. Diese 99 Amiga-Level waren dann im Jahre 2001 die Vorlage für die Neuauflage des Spieles als Reaxion Extended auf dem C-64. 2005 kamen dann die Umsetzungen für Commodore Plus/4 und den Atari 800 XL, beide wieder mit dem ursprünglichen Namen Reaxion, jedoch mit den 99 Amiga- Leveln. In Arbeit sind zur Zeit Umsetzungen für Nintendo NES und Sinclair ZX Spectrum. Neu ist die Spielidee auf dem Atari aber dennoch nicht. 1996 erschien Neuroid von Sikor Soft mit identischem Spielprinzip. Reaxion ist jedoch schöner und farbenfroher.

Das Spielfeld besteht aus 8×7 Feldern, auf dem farbige Steine
erscheinen. Welche Farbe ein Stein hat, spielt keine Rolle, es hat rein optische Gründe. Ziel ist es, das Spielfeld in der vorgegebenen Zeit von 60 Sekunden von den Steinen zu befreien. Mit dem Joystick bewegt man einen Zeiger. Drückt man auf den Feuerknopf wird das Feld unter dem Zeiger und alle 8 angrenzenden Felder invertiert. Beim invertieren erscheinen auf freien Feldern neue Steine und Felder mit Steinen werden zu freien Feldern. Das ist ein einfaches Spielprinzip, welches einen aber durchaus fesseln kann. Ich bin bisher bis zum Level 9 vorgedrungen. Als störend empfinde ich, dass man immer wieder von vorne anfangen muss, wenn man sein einziges Leben verliert. Es gibt keine Codeabfrage um spezielle Level anzusteuern. Wird ziemlich nervig in höheren Leveln, sofern man keinen Turbo Freezer sein eigen nennen darf 😉

Die Titelmelodie und Ingame-Music sind nicht schlecht, lassen sich aber nicht abstellen. Das Spielbild ist interessant und farbenfroh gestaltet. Die Steuerung bereitet keinerlei Schwierigkeiten. Erwähnenswert ist noch die Hintergrundstory. Der Kontrollcomputer eines unterirdischen Kernkraftwerkes wurde von einem Computervirus infiziert und ist ausgefallen. Die 99 (!) nun instabilen Kernreaktoren sollen manuell heruntergefahren werden, indem die aktiven Brennstäbe deaktiviert werden. Eine Inaktivierung löst aber eine Kettenreaktion in der Umgebung aus, was wiederum eine Aktivierung der Brennstäbe bewirkt. Hahaha!
Spiel: Reaxion
Autor: Jason Kelk alias MR / Cosine
Levelanzahl: 99
Besonderheit: ist eine Umsetzung des gleichnamigen
C-64-Spieles vom selben Autor.
Erscheinungsdatum: 31.12.2005
Bezugsquelle: Freeware
http://www.cosine.org.uk/
Eine Diskette oder Kassette mit dem Spiel kann
für 2 Pfund bei Cronosoft bestellt werden.
http://cronosoft.white.prohosting.com/cronosoft/
reaxio.htm
WGL-Wertung:
(8 von 10 Punkten)
Euer Wiesbaden Gaming Lab
Gunnar Kanold alias Bunsen /WGL

TRS-Desk

Ein neuer Desktop für ATARI-Computer im Vergleich

Wer sich regelmäßig die News auf www.ataritoday.com oder das ATARI-8-Bit-Forum unter www.atariage.com durchliest, der wird es sicherlich schon bemerkt haben: es befindet sich eine neue Benutzeroberfläche für den kleinen ATARI-8-Bitter in der Entwicklung. TRS-Desk, so der Name des von der polnischen Crew „TRS“ vorbereiteten Projekts, ist eine Oberfläche, die in Turbo-BASIC geschrieben ist und in der Endversion als Kompilat abläuft. Was da auf die ATARI-User zukommt ist eine, wie mir scheint, gut durchdachte Benutzeroberfläche für SpartaDOS-User. Ob das ganze auch unter BeWe-DOS laufen wird? Warum nicht? Schließlich kommt das Setup komplett mit einer Hardwareerkennung daher und sollte auch seine Softwareumgebung erkennen. Auf dem Screenshot jedenfalls ist zu sehen, dass zumindest Sparta- DOS-X erkannt wurde und wohl die entsprechende Unterstützung geladen wird, ob in Form von Treibern oder in Form von Auslagerungsmethoden ist mir jedoch nicht bekannt. Wieso schreibe ich über TRS-Desk, wenn es doch noch nicht mal erschienen ist und ich doch sowieso eine eigene Oberfläche zu bieten habe? Das erfahrt ihr jetzt. Ich werde beide Oberflächen, TRS-Desk und BOSS-X, miteinander vergleichen. Um die Sache noch etwas abzurunden, nehme ich ATOS auch noch in die Runde mit auf:

(siehe nebenstehende Tabelle:)
TRS-Desk kann sich sehen lassen, bis auf ein paar obszöne Icons ist diese Oberfläche recht anschaulich und auch die Screenshots von der Installation und von Setupfenstern wirken professionell und durchdacht. Was mich persönlich stört, ist dieser 80- Zeichen-Font, der auf ATARI-XL-Geräten besonders schwer zu lesen ist, auf XE-Geräten ist der auch nur notgedrungen erträglich (eine subjektive Meinung). Vorteil ist dabei jedoch, dass Textlängen in Pixel schneller berechnet werden können, um so Menüs schneller aufbauen zu können. Die Nutzung der PMGrafik für absolut jedes Icon (vgl.: bei BOSS-X nur für gekennzeichnete Icons) finde ich übertrieben, aber da man sämtliche Farben an eigene Bedürfnisse anpassen kann, ist es

  TRS-Desk ATOS BOSS-X
Herkunft des Namens Gibt den Namen der Autoren-Crew wieder (u. a. Tristesse) das „A“ steht für ATARI, „T“ für Tom Hunt, „OS“ …klar BOSS: irgendein Wort, das mir 1992 grad eingefallen ist (noch vor dem Vorgänger des heutigen BOSS-X), X steht für das X in XL und in XE
Zielgruppe SpartaDOS-Anwender SpartaDOS-Anwender mit Festplatte (wg. schnellem I/O-Zugriff) ATARI-DOS-, MyDOS-Anwender mit RAM-Disk (geht auch anders, aber das tut jetzt nichts zur Sache 🙂
unterstützte Hardware SpartaDOS-X
RAM-Disk
R-Time8 Uhr
(lt. Hardwareerkennung auf dem Screenshot)
ATARI-ST-Maus
Amiga-Maus (!)
ATARI-ST Maus Joystick / ATARI-ST Maus
Aussehen Graphics 8, permanente PM-Graphik für Symbole und Menüs, Farben anpassbar, DLI für untere Menüleiste Graphics 8, PM-Graphik für Mauszeiger, clean schwarz-auf-weiss-Grafik Graphics 8, PM-Graphik für Mauszeiger, angepasste PM-Graphik an Symbole und Menüs, mehrfarbiger DLI für die Titelzeile, Farben anpassbar
Icons neu erstellte monochrome Icons (32×32 Pixel) neu erstellte monochrome Icons (32×32 Pixel) neu erstellte farbige Icons (24×24 Pixel)
Schriften 4×8 Pixel pro Zeichen = 80 Zeichen pro Zeile 4×8 Pixel pro Zeichen = 80 Zeichen pro Zeile Proportionalschrift mit bis zu 8×8 Pixel pro Zeichen ~ 60 Zeichen pro Zeile
Programmiersprache Turbo-BASIC
kompiliert zur Laufzeit
Maschinensprache
viel Objektorientiertes
Turbo-BASIC
läuft auch komplett unter Turbo-BASIC (kein Kompilat)

ein Leichtes, eine unauffälligere Farbe dafür zu wählen. Jedenfalls bin ich gespannt auf TRSDesk. Wenn es so ähnlich funktioniert wie BOSSX, also dass sämtliche Systemdateien beim Start (oder vielleicht sogar dynamisch während des Betriebes?) in die RAM-Disk geladen werden, werde ich dieses System am echten ATARI ausprobieren (vgl: ATOS, hier werden u. a. die „Layer“, also die von Menüs und Fenstern verdrängten Hintergründe auf die Diskette/Festplatte geschrieben, so dass das System z.B. auf SIO2PC- Datenträgern ziemlich langsam läuft und nur im Emulator getestet werden kann). Die Macher von TRS-Desk haben (leider 🙂 sogar an Bluescreens gedacht (vgl.: BOSS-X hat außer im Desktop für alle „unerwarteten“ Fehler eine grafische Fehlermeldung). Dies kann allerdings in bestimmten Szenarien von Vorteil sein: so stelle man sich vor, eine selbst eingebaute RAM-Disk hätte während des Betriebes eine kalte Lötstelle bekommen. Während BOSS-X für die grafische Fehlermeldung Daten aus der RAM-Disk versucht zu lesen und der Fehler immer wieder auftritt und eine endlose Fehlerschleife entsteht, so zeigt TRS-Desk diesen Fehler mit Mitteln an, die jedem ATARI zur Verfügung stehen (also der normale Zeichensatz aus dem ROM). Gut, BOSS-X‘ grafische Fehlermeldung verhält sich anders (wenn das Grafikfenster nicht mehr gezeichnet werden kann, dann springt BOSS-X in Gr.0 und zeigt einen Fehler als normalen Text an, dies ist dann aber der Fehler während des Zeichnens des Fensters auftrat, nicht der, der das Fehlerfenster erst hervorgerufen hat).

ATOS hängt sich übrigens bei unerwarteten Fehlern komplett auf, zumindest findet es nicht mehr zurück, nachdem der Fehler behoben wurde (ich habe dem Emulator während des Einlesens des Directorys das Diskimage weggenommen). Danach hat sich nur noch der Zeiger bewegt und sich auch typischerweise beim Klicken verfärbt, aber sonst – nix mehr. Die erste Version von TRS-Desk wird auf der FOREVER 2006 – Party als Freeware veröffentlicht. Die Quellen werden verfügbar sein, sobald das System stabil läuft, das wird etwa 2 Monate später sein (die Quellen der Alpha-Versionen bleiben also unter Verschluss). Die offizielle Homepage wird als Unterseite von www.atari8.info auftauchen (übersetzt aus dem entsprechenden Posting im Atari-Age-Forum). So, dass soll’s erstmal gewesen sein … sobald TRS-Desk da ist, werde ich mich wieder melden (man, bin ich neugierig!).
Mirko Sobe

ATARI XL/XE Ramdisk Info – Teil 4

Willkommen zum 4. und letzten Teil dieser Serie. Heute geht es um Programme die unbedingt eine RAMdisk benötigen – und ohne RAMdisk (oder Extra-RAM, Ram-Erweiterung, etc.) nicht laufen würden. Es wurde ja immer behauptet, dass es kaum Programme gäbe (außer Demos) für die man unbedingt mehr als 64k RAM haben müsste. Nun, diese lange Liste beweist, dass es durchaus doch Sinn macht eine RAM-Erweiterung zu haben – und sei es nur zum Kopieren von Files oder Sektoren/Disks. Los geht`s…:

Teil 4: Atari-Programme die Extra-RAM / RAMdisk benötigen:
a) „Tools“ that require more than 64k RAM:
128k Memory Testers
(quite many programs, 64k XRAM, block E),
130XE Bank/Mem.-Testers
(quite many programs, 64k XRAM, block E),
130XE Sectorcopiers
(quite many programs, 64k XRAM, block E),
130XE Utilities
(HAPS PD 0031, 64k XRAM, block E),
192k Memory Testers
(some PD programs, 128k XRAM, blocks AE),
256k Memory Testers
(Newell, ICD, etc., 192k XRAM, blocks ACE),
320k Mem. Testers 8ACE
Atari Mag., TOMS, etc., 256k XRAM, blocks
8ACE),
320k Mem. Testers 26AE
(Compyshop, etc., 256k XRAM, blocks 26AE),
576k Memory Testers
(Peterson, TOMS, etc., 512k XRAM, blocks
8ACE),
1088k Memory Testers
(Newell, TOMS, etc., 1MB XRAM, blocks
02468ACE),
4160k Memory Tester
(Newell, 4MB X R A M , b l o c k s
0123456789ABCDEF),
APC Archiver 1.x
(LBS/APC, 256k XRAM, 8ACE only!),
APC Packer 1.x
(LBS/APC, 256k XRAM, 8ACE only!),
A.W. P. Super Menu
(Ken Siders, min. 64k XRAM, block E),
A.W. P. XE Super Menu
(Ken Siders, min. 192k XRAM, blocks ACE),
Audio/Studio Master
(Mirage/ANG, 256k XRAM, 26AE only?),
Boot Majster
(Electron, 64k XRAM, block E),
Boss X [Vers. 10.x]
(M. Sobe, with any DOS min. 64k RAMdisk,
block E; with MyDOS 4.x it supports up to 1MB
RD, subdirs and up to 16MB HD part.),
Boss XE [Vers. 8.x]
(M. Sobe, with any DOS min. 64k RAMdisk,
block E; with Turbo-DOS or MyDOS 4.5x it
supports bigger RAMdisks, but no subdirs!),
CAD XE
(HAPS PD 0350, 64k XRAM, block E),
Diskettenverwaltung XE
(ABBUC PD 86, 64k XRAM, block E),
Draw XE
(ABBUC PD 387, 64k XRAM, block E),
Dream Vision
(ABBUC PD 480, 192k XRAM, blocks ACE?),
Fraktale & Colorprint
(P. Woetzel, 64k XRAM, block E),
Grafik Zeilen Editor
(HAPS PD 0296, 64k XRAM, block E),
Hires Dump
(ABBUC PD 113, 64k XRAM, block E),
Inertia 3.x
(MadTeam, min. 64k XRAM, block E; supports
up to 256k XRAM, AE/ACE/26AE/8ACE with
almost any DOS),
Inertia 4.x
(MadTeam, min. 64k XRAM, block E; supports
up to 1024k XRAM – all possible bank combina-
Seite 21 ABBUC e.V. # 84 1. Quartal 2006 Seite 22 ABBUC e.V. # 84 1. Quartal 2006
tions!),
Macro Assembler XE
(T. Karwoth, 64k XRAM, block E),
Macro Assembler XE+
(T. Karwoth, min. 64k XRAM, block E; supports
up to 1024k XRAM – all possible bank combinations!),
Masher XE
(???, min. 64k XRAM, block E; supports up to
256k XRAM: AE/ACE/8ACE),
Menu 130
(Les Howarth, 64k XRAM, block E),
Midi Mate III
(Hybrid Arts, 64k XRAM, block E),
Monitors, Debuggers, … (
HAPS PD 0109, 64k XRAM, block E),
Multi DOS 130
(Kuchera/Excellent, 64k XRAM, block E),
Multi DOS 320
(Kuchera/Excellent, 256k XRAM, 8ACE only!),
Multi Tasking OS
(???, min. 64k XRAM, block E),
MTOS 256
(Tom Hunt, 192k XRAM, blocks ACE),
MTOS XE (
Tom Hunt, 64k XRAM, block E),
Neo-Tracker 1.x
(Epi, min. 64k XRAM, block E; under MyDOS 4.5x
or Sparta DOS X cart. it supports up to 1MB
XRAM, all bank combinations!)
Newspaper Editor
(HAPS PD 0294, 64k XRAM, block E),
Protracker 1.5
(MadTeam, min. 64k XRAM, block E; supports up
to 256k XRAM: AE/ACE/8ACE/26AE),
Rechnen für Kinder
(ABBUC PD 85, 64k XRAM, block E),
Rund um die RAMdisk
(ABBUC PD 383, HAPS PD 1084, contains info
texts and pgms. for upgrading the 800 or XL/XE
and testing its XRAM up to 1 MB; the docs use
english language and provide detailed information
for Axlon compatible 800 XRAM and Newell/
Buchholz/Peterson compatible XL/XE XRAM),
Sample Art XE
(Mozart/WSL, min. 64k XRAM, block E; supports
up to 1024k XRAM, all bank combinations, alas
the program is faulty/buggy!),
Shrink XE
(P. Fitzsimmons, 64k XRAM, block E),
Snapshot
(???, 64k XRAM, block E),
Tape RAMdisk Drivers
(Pokey, SAG, etc., 64k XRAM, block E),
Text 130
(B. Russmann, 64k XRAM, block E),
Textpro „+“ [e.g. 4.54+]
(Ronnie Riche, 64k XRAM, block E),
Textpro 5.x
Ronnie Riche, 64k XRAM, block E),
The Code Cruncher 2.x
(Soused Teat, min. 64k XRAM, block E),
The Code Cruncher 3.x
(Soused Teat, min. 64k XRAM, block E),
The Cruncher 5.x
(MSL/Magnus, min. 64k XRAM, block E),
The Small Printery
(W. Lojek, min. 64k XRAM, block E; supports up
to 1024k XRAM, all bank combinations!),
The [Sparta DOS] Wedge
(Ed Bachmann, 64k XRAM, block E, sep. Antic!),
The Works
(Tom Hunt, min. 64k XRAM, block E),
Württemberger Disk
(ABBUC PD 361, HAPS PD 1050, 64k XRAM,
block E; mainly/only because side 2 contains
the XE version of Gizmo’s castle),
XL-2
(J.K. Picken, min. 64k XRAM, block E; under
MyDOS or Sparta DOS it supports up to 1024k
XRAM !),
Zeitungsredakteur
(ABBUC PD 121, 64k XRAM, block E);
b) „Games“ that require more
than 64k RAM:
Castle of Blackthorne
(T. Graef, 64k RD, block E),
Seite 22 ABBUC e.V. # 84 1. Quartal 2006
Seite 23 ABBUC e.V. # 84 1. Quartal 2006
Cavepack XE (
XE-version by K. Ezcan, 64k RD, block E),
Computer Baseball
(D. Blackwell, 64k XRAM, block E),
Der Neffe
(XE-version by ???, 64k XRAM, block E),
Gizmo’s Castle
(XE-version by M. Kugler, 64k XRAM, block E),
Kaiser II
(128k version by C. S., 64k XRAM, block E),
Kaiser II
(320k version by C. S., 256k XRAM, 26AE &
8ACE),
Minesweeper 1-4
(4 versions by J.R. Chicko, 64k XRAM, block E),
Mister X
(S. Soelbrandt, 64k RD, block E),
Oelbaron
(XE-version by ???, 64k RD, block E),
Space Harrier
(C. Hutt, 64k XRAM, block E),
Strategy Baseball
(HAPS PD 0302, 64k XRAM, block E),
Yie Ar Kung Fu
(???, 256k XRAM, blocks ??? – new version 1.2
now works on a real 320k Atari; alas it works only
with the manipulated DOS!),
Zargon XE
(ABBUC PD 611, HAPS PD 0485, 64k XRAM,
block E),

Please note, that hackers, crackers and pirates also made file versions of (most of) the XE / XEGS 64k and 128k carts available. Due to cart. bankswitching, a 64k XL/XE was enough for these super-carts; not so withthe file versions, they do (mostly) require more than 64k memory… Next, there are also „un-official“ (pirated, hacked, cracked, patched) cart. versions of former diskbased games, that require XRAM, which they originally did not (example: Conan, the multi-stage disk-version by Datasoft requires 64k RAM, whereas the single-stage version of the Sunmark multicart. req. 128k RAM). Since Sunmark will continue in producingA8 carts and other programable / flashable carts (like the Atarimax Flash cart. by Steven Tucker) are on the market today, it is quite likely, that more games will occur in the Atari scene with the same behaviour…

c) „Demos“ that require more than 64k RAM:
130XE Artshow (
HAPS PD 0013, 64k XRAM, block E),
130XE Autoshow
(HAPS PD 0637, ABBUC PD 191, 64k XRAM,
block E),
130XE Demo
(S.A.G., 64k XRAM, block E),
130XE Impossible Demo
(R. Haegemann, 64k XRAM, block E),
3D Scroll
(Jaskier/TQA, 64k XRAM, block E),
American Natives
(Fox-1, 192k RD, RAMdisk = DOS dependant),
Amiga Boink XE
(B. Armour, 64k XRAM, block E),
Animkom. meet B. V.
(Animkomials + B.V., 64k XRAM, block E),
(The) Asskicker
(Shadows, 64k XRAM, block E; hold Select!),
Back to Life 2
(Jaskier/TQA, 256k XRAM, auto-setup!),
Base 33
(AIDS, 256k XRAM, hold SHIFT for setup!),
Bill Pie Demo
(MadTeam, min. 64k XRAM, block E; supports
up to 256k XRAM: AE/8ACE with more frames),
BMW Animation
(Mirko Sobe, 64k XRAM, block E),
Brull
(Pin/Trs, 1MB XRAM for a sample demo !?!)
CES XE Demo
(full 580 sectors version by XANTH, 64k XRAM,
block E; includes the Swan-, Fuji-Boink- and
Robot-Demo all in one file!),
Cogito Demo
(AIDS, uses blocks 8C, thus 8ACE only!),
Critical Sounddemo
(Innovative, 64k XRAM, block E),
Seite 23 ABBUC e.V. # 84 1. Quartal 2006
Seite 24 ABBUC e.V. # 84 1. Quartal 2006
Danielle (Gr.9) Ani
(B. Kendrick, 64k XRAM, block E),
DoXEpin
(AIDS, 64k XRAM, block E),
Edelweiss Demo
(A.R.+C.S.S.+S.V.L., 256k XRAM, 26AE only!),
Ergo Bibamus
(Quasimodos, 64k XRAM, block E),
Extract Slideshow
(Replay/Bit Busters, 64k XRAM, block E),
Fat Bottomed Girls
(???, 64k XRAM, block E for a Queen sample),
Forever 1ktro
(New Generation, 64k XRAM, block E for a 1k
demo),
Forsaken Love
(New Generation, 256k XRAM, 26AE & 8ACE;
simplydelete „BANKS.DAT“, reboot and create a
new one for your kind of XRAM!),
Glasshead Demo
(A.R.+C.S.S., 256k XRAM, 26AE only!),
Halle 1994: The Wormhole
(Magic Arts, 256k XRAM, 26AE only!),
Hardware Demo
(A.R.+C.S.S., 256k XRAM, 26AE only!),
Igor Demo (Side A)
(MadTeam, 64k XRAM, block E – use 128k.BAT),
Igor Demo (Side B)
(MadTeam, 128k XRAM, blocks AE – use
192k.BAT),
Igor Demo (Side A+B)
(MadTeam, 256k XRAM, 8ACE only – use
320k.BAT),
Imperial Sounddemo
(Innovative, 256k XRAM, 26AE & 8ACE),
Impossible but Real
(MacGyver, 192k XRAM, auto-setup!),
Incredible
(Excellent, 64k XRAM, block E),
Inside Out
(Taquart, 64k XRAM, block E),
Isolation Demo
(M.E.C., 64k XRAM, block E),
Journey Demo
(Boot version by Polynomials, min. 64k XRAM,
block E; supports up to 256k XRAM: AE/8ACE),
Journey Demo
(File version by MadTeam, min. 64k XRAM,
block E; supports up to 192k XRAM: AE/ACE),
Journey into Sound
(DGS / D. Garaghty, 64k XRAM, block E),
Khai Et
(AIDS, 256k XRAM, 26AE & 8ACE, SHIFT for
Setup!),
Killer Whales Ani
(MadTeam, min. 64k XRAM, block E, supports
up to 256k XRAM: AE/8ACE with more frames!),
Landscape-XE Demo
(Karl Pelzer, 64k XRAM, block E),
Manga Ani
(MadTeam, min. 64k XRAM, block E),
Megablast Sounddemo
(DGS / D. Garaghty, 64k XRAM, block E),
MTV’s Danielle = Danielle (Gr.9) Ani,
Nascar Ani
(M. Sobe, 64k XRAM, block E),
Nonjm Demo
(Tight, 64k XRAM, block E),
Numen Demo
(Taquart, 256k XRAM, 26AE & 8ACE, autosetup!),
Ogluszacz Sounddemo
(AIDS, 64k XRAM, block E),
Owca Demo
(Animkomials, 64k XRAM, block E),
Owca 2 Demo
(Animkomials, 64k XRAM, block E),
Pacem in Terris
(Quasimodos, 256k XRAM, 26AE & 8ACE,
auto-setup),
Parrot XMAS Demo
(A. Ramos, 64k XRAM, block E),
Pedrokko Sounddemos
(a collection of 10 disks / 20 sides by Pedrokko,
the player program assumes a 64k RD, block
E),
Raving Vierpz
(Pentagram, 64k XRAM, block E),
Raytracing Ani/128k
(K. Pelzer, 64k XRAM, block E),
Raytracing 320k
(Elsni / S. Elsner, 256k XRAM, 8ACE only!),
Seite 24 ABBUC e.V. # 84 1. Quartal 2006
Seite 25 ABBUC e.V. # 84 1. Quartal 2006
Raytracing 1088k
(Solocoder of A.C.E., 1024k XRAM, works only on
K.P. 1MB Megaram III, 8 bootdisks, loading time
approx. 17 minutes !!),
Reditus Demo
(Zelax, 192k XRAM, 26AE & 8ACE, auto-setup),
Render Ani
(MadTeam, min. 64k XRAM, block E),
Revenge of Hacker
(Rasero Team, 128k XRAM, blocks AE),
Running Cow ASCII Ani
(MadTeam, 64k XRAM, block E),
Sheol Demo
(Bit Busters, 256k XRAM, 8ACE only!),
Shiny Bubbles
(XE version by B. Paul, 64k XRAM, block E),
Stash 98 Demo
(Rasero Team, 256k XRAM, 26AE & 8ACE via a
buggy setup: 1) for 8ACE XRAM press A in the
1st or 2nd menu, 2) for 26AE press B in the 1st
menu and C in the 2nd menu; don’t use the CS
auto-setup!),
Starwars Demo
(A.R.+C.S.S., 256k XRAM, 26AE only!),
The Wormhole
(Magic Arts, 256k XRAM, 26AE only!),
Timekeep(er)
(New Generation, 256k XRAM, 8ACE only! wait!),
Tit Demo
(Mad Team, 192k XRAM, auto-setup!),
Too Hard 2 Demo
(Animkomials, 64k XRAM, block E),
Too Hard 3 Demo
(Animkomials, 128k XRAM, blocks AE),
Too Hard 4 Demo
(Animkomials, 256k XRAM, autosetup!),
Total Dazed
(Tight, 64k XRAM, block E),
Trabant Demo
(A.R.+C.S.S., 256k XRAM, 26AE only!),
Trip 6
(Shadows, 64k XRAM, block E),
Turtles Demo
(Ultra Software, 64k XRAM, block E),
Ultra Demo
(Taquart, 64k XRAM, block E),
Ultra 2 Preview
(Taquart, 64k XRAM, block E, unfinished!),
Vengeance (
Excellent, 64k XRAM, block E),
Vent XE
(Exc.+Pentagram, 64k XRAM, block E),
WAF-Demo
(W.A.F., diskside B = 64k XRAM, block E),
Worms Demo
(Datri, 256k XRAM, 8ACE otherwise buggy!),
X-Demo
(MadTeam, 256k XRAM, 26AE),
X-Files Ani
(MadTeam, 64k XRAM, block E),
X-Files 2 (TV-Ani)
(MadTeam, 256k XRAM, 26AE & 8ACE),
Xyberscape XE
(XE version by Bill Le Masurier, 64k XRAM, E),
Zero Demo
(New Generation, 64k XRAM, block E);

Mein Dank für bereitgestellte Informationen geht an folgende Leute: Russ Gilbert, Bernhard Pahl, Ron Hamilton, Mathy van Nisselroy und Stephan Pollok. So, damit hätten wir diese Serie endlich beendet. Mal sehen, was mir so als nächstes einfällt.
Andreas Magenheimer.

 

Spieletest

Venus Express von Heaven /TQA
Der Hit des Jahres bei der Minigame Compo 2005 war Venus Express für den C64. Es setzte sich gegenüber 23 Mitbewerbern in der 1K-Kategorie durch. Die Jury zeigte sich begeistert: die meisten bewunderten, wie so ein relativ komplexes Spiel nur einen Kilobyte Speicher einnimmt. Es wurde von einigen bemerkt, dass sie z.B. die Explosion der Spielfigur vermissen. Aber was soll denn noch alles in 1K?? Der im Internet veröffentlichte Quelltext inspirierte Heaven dann, dieses nette kleine Spiel auch für den Atari verfügbar zu machen. Er war natürlich nicht mehr an die 1K-Grenze gebunden und konnte deshalb noch einige Extras ergänzen. Er fügte ein Titelbild ein, Musik während des Spiels und einen schönen Crash-Effekt, wenn man gegen die Höhlenwand fährt. Das Spiel gewinnt schon durch diese kleinen Zusätze, die Magie des Spieles geht meiner Meinung nach jedoch verloren. Die relativ kleinen Änderungen, die das Spielprinzip nicht verändern, lassen die Dateigröße von 1K auf 8K ansteigen.

Das Spielprinzip ist natürlich nicht neu: Fliege in eine Höhle, finde dort etwas in einer bestimmten Zeit und fliege wieder hinaus. In diesem Spiel sind es „capsules“, die man retten soll. Im ersten Level eine Kapsel, im zweiten Level zwei Kapseln, im dritten Level drei Kapseln, usw. Dafür hat man jeweils 70 Sekunden Zeit. Die Spielfigur zu steuern ist nicht ganz einfach. Man darf den Joystick nur ganz sachte betätigen, ansonsten flitzt man ziemlich schnell gegen die Wand. Dies macht das Spiel herausfordernder. Sehr verwirrend und störend finde ich dagegen die „Anti-Trägheit“. Steuert man erst nach rechts und kommt dann wieder in die Mittelstellung des Joysticks, ruckelt die Spielfigur einige Pixel nach links. Realistischer wäre ein weiterdriften nach rechts. Das wäre ein realistischer Trägheitseffekt. Beim steuern nach links mit anschließender Mittelstellung zeigt sich der gleiche Effekt.

Das Aufsammeln der Kapseln ist oft schwierig. Befindet man sich exakt über der Kapsel, lässt sie sich nicht aufsammeln. Man muss also leicht nach links oder rechts versetzt die Kapsel ansteuern. Man muss jedoch aufpassen: die Kapsel darf nicht berührt werden, denn dann ist eines der drei Leben dahin. Die Musik, die während des Titelbildes und während des Spieles ertönt, ist aus einem anderen C64-Spiel von Sack /Cosine konvertiert worden. Sie ist gut und passt auch gut zum Spiel. Die Grafik ist zweckmäßig. Gut gefallen mir die von Level zu Level wechselnden Farben der Höhlenwände, die schön gezeichnete Spielfigur und das butterweiche Scrolling. Der Spielstand wird übersichtlich am oberen Bildschirmrand dargestellt. Der Zeichensatz aus „Dropzone“ wird dazu benutzt. Nachdem einige Beta-Versionen bereits im AtariAge- Forum veröffentlicht wurden, erscheint die finale Version exklusiv im aktuellen ABBUC Magazin.

Venus Express ist ein nettes kleines Spiel, welches immer gut ist für ein „Spiel zwischendurch“. Spiel: Venus Express Autor: Karolj Nadj alias Heaven /Taquart Erscheinungsdatum: Finale Version: März 2006 Besonderheit: ist eine Umsetzung des gleichnamigen C-64- Spieles von Aleksi Eeben, Gewinner der Minime Compo 2005 Bezugsquelle: ABBUC Magazin Nr. 84 WGL-Wertung: (7 von 10 Punkten) Euer Wiesbaden Gaming Lab Gunnar Kanold alias Bunsen /WGL Interview mit dem Entwickler des Spieles „Venus Express“ Heaven /TQA Heaven /TQA programmierte das Spiel „Venus Express“. Die aktuelle Preview-Version erscheint exklusiv auf der Magazindiskette des vorliegenden ABBUC Magazins. Das Wiesbaden Gaming Lab (WGL) führte ein Gespräch mit ihm.

WGL: Hallo Heaven! Erstmal vielen Dank für den exklusiven Release des Spiels „Venus Express“ im ABBUC Magazin. Was hat dich dazu veranlasst, das Spiel zu schreiben?

Heaven /TQA: Also, … die ursprüngliche Idee kam mir, als ich Venus, das für die Minigame Compo 2005 auf dem C64 geschrieben wurde, gesehen habe und Aleksi den Sourcecode mit veröffentlich hat. Warum nicht ein „quick- and dirty- Versuch“ in einer Konvertierung? Und so passierte es auch…

WGL: Konntest du den Quellcode 1:1 übernehmen oder war die Portierung aufwändiger?

Heaven /TQA: Es war etwas aufwändiger wie zuallererst gedacht. Als erstes wurde der Levelgenerator angepasst. Venus besitzt einen cleveren Generator, welcher vor jeden Level die Höhle generiert anhand von Zufallszahlen, welche aber vorhersehbar sind. Dann wird einfach a la „Photoshop- Stempel“ die Höhle „gemalt“ und die Kapseln gesetzt.

WGL: Was ist das bemerkenswerteste des Spiels aus deiner Sicht?

Heaven /TQA: Um die Levels 1 zu 1 umzusetzen benötigte ich 512 Bytes aus dem ROM des C64. Ich musste also im C64-Emulator diese 512 Bytes auslesen, was auch einige Zeit gekostet hat. Aber mit Hilfe von TMR von der C64-Gruppe Cosine ging es dann. Das Interessante ist nun, dass diese 512 Byte C64 ROM Code im Spiel weiterhin enthalten sind.

WGL: Wo lagen die größten Schwierigkeiten?

Heaven /TQA: Ein Level von Venus belegt sage und schreibe 48KB RAM! Das war ein ganz schöner Schock. Nun war etwas Trickserei notwendig.

WGL: Was sind denn die entscheidenden Unterschiede in der Programmierung im Vergleich zum C64-Vorbild?

Heaven /TQA: Ich wollte Venus natürlich auf die Hardware anpassen, d.h. die „copy und paste-Methode“ des C64 nicht übernehmen, sondern richtig mit Atarispezifischen Methoden arbeiten, wie z.B. der veränderten Display List. Also wurde eine schöne Display List geschrieben und die Scrollengine angepasst, da diese komplett anders arbeitet als auf dem C64. Auch die Spriteengine musste komplett neu geschrieben werden, da sich das Handling auf beiden Maschinen völlig unterscheidet. Die Physikroutinen für das Steuern und Fliegen des Raumschiffes wurden wiederum 1:1 übernommen, daher ist das „feeling“ nahezu identisch zum Original.

WGL: Du sagtest, die Scrollengine arbeitet auf dem C64 völlig anders. Kannst du uns das mal erklären?

Heaven /TQA: Die Register auf dem C64 arbeiten komplett anders als auf dem Atari, nämlich gerade anders herum. Daher gab es anfangs Verwirrung. Stimmt mein Code nicht oder liegt es an der Hardware? Aber auch das Problem wurde gelöst. Ein weiterer entscheidender Unterschied ist, dass der C64 immer in „1-Pixel-Schritten“ scrollt, egal, ob er im Multicolour-Mode ist oder nicht. Der Atari dagegen scrollt in „colour clocks“, d.h. sichtbaren Pixeln. Im Multicolour- Mode scrollt er also in „2-Pixel-Schritten“. Aber Gott sei Dank konnte ich durch hinzufügen von einem Befehl die Scrollengine und die Physikengine zum Laufen bringen.

WGL: Es ist jetzt verständlich, dass sich die Dateigröße so aufgebläht hat.

Heaven /TQA: Ja, und als ich merkte, dass ich die 1KGrenze bei weitem nicht einhalten kann, konnte ich ja noch ein paar weitere Verschönerungen einfügen und so wurden Statusleisten, DLIs für die Farben, Textmitteilungen, Musik usw. untergebracht.

WGL: Vielen Dank für diese doch sehr aufschlussreichen und interessanten Einsichten in die Entwicklung eines Spieles und natürlich vielen Dank für dieses schöne Spiel!

XL/XE DOS Top 10

Hier eine kleine Übersicht der gängigsten, gebräuchlichsten oder beliebtesten („Top 10“) Atari XL/XE DOS Versionen, mit entsprechenden Anmerkungen und Hinweisen:

– Alle Angaben ohne Gewähr –

– DOS 2.0:
Hersteller war Atari (1980), das DOS besteht aus zwei Teilen, DOS.SYS + DUP.SYS; ein Programm mit dem Namen AUTORUN.SYS wird automatisch geladen (bei ML-Files einfach umbenennen, bei Basic-Files muss ein 1-2 Sektor langes Autorun-File erstellt werden, das dann das Basic Programm lädt); eine RAMdisk wird eigentlich nicht standardmäßig unterstützt, es gibt jedoch selbst gemachte Treiber, die als Autorun-File eine RAMdisk als D4: einrichten können; dieses DOS existiert als DOS 2.0s(ingle) und DOS 2.0d(ouble); DOS-Menü: Ja ! Das DUP.SYS hat die Menüpunkte AO (inkl. Mem.SAV); Formate: SD / 90k für DOS 2.0s und DD / 180k für DOS 2.0d; aber kein ED-Format; Sub-Directories: Nein! Harddisk-Partitionen: Nein! Aux.: /N /A max. Anzahl von Drives: 4 (als D1: bis D4:); Dir.-Einträge: max. 64 RAM unter dem OS: nicht genutzt, steht für Programme oder Treiber frei zur Verfügung; Speeder-Treiber: in der Original-Version keine vorhanden und daher separate / externe Treiber notwendig; es existieren aber DOS 2.0 Patches mit eingebauten Speedern (z.B. für Happy Laufwerke);

– DOS 2.5:
Hersteller war Atari (1984), das DOS besteht aus zwei Teilen, DOS.SYS + DUP.SYS; ein Programm mit dem Namen AUTORUN.SYS wird automatisch geladen (bei ML-Files einfach umbenennen, bei Basic-Files muss ein 1-2 Sektor langes Autorun-File erstellt werden, das dann das Basic Programm lädt); eine XE-RAMdisk wird standardmäßig via Treiber RAMDISK.COM unterstützt, neben dem Standard 64k RD-Treiber gibt es auch viele selbst gemachte Treiber bis 256k RD; bis heute das meistverbreitete Atari 800/XL/XE DOS; DOS-Menü: Ja ! Das DUP.SYS hat die Menüpunkte A-P (inkl. Mem.SAV und Format SD); Formate: SD / 90k (Option „P“) und ED / 130k (Option „I“); aber kein DD-Format; Sub-Directories: Nein! Harddisk-Partitionen: Nein! Aux.: /N /A max. Anzahl von Drives: 8 (als D1: bis D8:); Dir.-Einträge: max. 64 RAM unter dem OS: nicht genutzt, steht für Programme oder Treiber frei zur Verfügung; DOS 2.0 kompatibel: Single Density/SD: Ja ! , Double Density/DD: Nein ! Speeder-Treiber: keine eingebaut und daher externe Treiber notwendig;

– Bibo-DOS
Hersteller war Compyshop (1986-1988), das DOS besteht aus zwei Teilen BDOS.SYS und BDUP.SYS. Es existieren drei Varianten, nämlich 5.xN (normal Version, ohne Speeder), 5.xHS (mit Happy+Speedy Treiber) und 6.xRF (mit XF551 Treiber); ein Programm mit dem Namen AUTORUN.SYS wird automatisch geladen (bei ML-Files einfach umbenennen, bei Basic-Files entweder ein 1-2 Sektor langes Autorun- File erstellen oder das Mini-Batchfile -Option „N“- nutzen, um das Basic Programm zu laden); eine XERAMdisk wird standardmäßig via eingeb. Treiber (bzw. der DOS-Konfig., unter Menüpunkt „H“) bis zu 256k unterstützt. DOS-Menü: Ja ! Das BDUP.SYS hat die Menüpunkte A-N (und ein Mini-Batchfile); Formate: SD / 90k, ED / 130k, DD / 180k (alle Vers.), sowie QD / 360k (nur Vers. 6.x); Sub-Directories: Nein! Harddisk-Partitionen: Nein! Aux.: /N /A max. Anzahl von Drives: 8 (als D1: bis D8:); Dir.-Einträge: 64 (SD/ED/DD), 128 (QD); RAM unter dem OS: wird vom BDUP.SYS genutzt; bei Programmen oder Treibern, die das RAM unter dem OS benötigen muß also das BDUP.SYS auf Disk weggelassen werden; DOS 2.0 kompatibel: Single Density/SD: Ja ! , Double Density/DD: Ja ! DOS 2.5 kompatibel: Enhanced Density / ED: Ja! (ebenso zweite VTOC in Sektor 1024); Speeder-Treiber: Version 5.xN hat keine Speeder, Version 5.xHS hat Speeder für Happy und Speedy, Version 6.xRF hat Speeder für XF551 Laufwerke; Anmerkung: beim Format QD / 360k auch MyDOS kompatibel (ohne Sektor/Filelinks); die letzten offiziellen Versionen waren 5.4N, 5.4HS und 6.4RF (es existieren auch Patches)…

– Turbo-DOS XL/XE:
Hersteller war Reitershan Computertechnik (1986- 1992), das DOS besteht aus zwei Teilen, DOS.SYS und DUP.SYS; Es existieren vier Varianten, nämlich 2.xNT (normal oder turbo), 2.xHS (Happy und Speedy), 2.xXF (XF551) und 2.xEX (extended, Happy+Speedy+XF551); ein Programm m
it dem Namen AUTORUN.SYS wird automatisch geladen (bei ML-Files einfach umbenennen, bei Basic-Files entweder ein 1-2 Sektor langes Autorun-File erstellen oder das Batchfile Programm nutzen, um das Basic Programm zu laden); eine XERAMdisk wird standardmäßig bis zu 256k unterstützt (entweder via Batchfile Programm oder via RAMDISK. COM Treiber; die RD-Größe muss mittels ext. DOS-Konfig. eingestellt werden). DOS-Menü: Nein! Das DUP.SYS hat aber eine Befehlsübersicht (via HELP-Taste); Formate: 90k, 130k, 180k (alle Vers.), sowie 360k (nur Vers. XF und EX); Sub-Directories: Nein! Harddisk-Partitionen: Nein! Aux.: /N /A /D max. Anzahl von Drives: 8 (als D1: bis D8:); Dir.-Einträge: 64 (SD/ED/DD), 128 (QD); RAM unter dem OS: nicht genutzt, steht für Programme oder Treiber frei zur Verfügung; DOS 2.0 kompatibel: Single Density/SD: Ja ! , Double Density/DD: Ja ! DOS 2.5 kompatibel: Enhanced Density / ED: Ja! (ebenso zweite VTOC in Sektor 1024); Speeder-Treiber: Version 2.xNT hat keine Speeder, Version 2.xHS hat Speeder für Happy und Speedy, Version 2.xXF hat Speeder für XF551 Laufwerke und Version 2.xEX hat Speeder für Happy, Speedy und XF551 Laufwerke (daher auch versch. Memlo`s); Anmerkung: beim Format QD / 360k nicht MyDOS kompatibel (TurboDOS nutzt hier 4 Bytes als Sektor/ Filelinks); letzte offizielle Versionen waren 2.1NT,

2.1HS, 2.1XF und 2.1EX;
– My-DOS 4.5x:
Hersteller war Wordmark (1983-1988), das DOS besteht aus zwei Teilen DOS.SYS und DUP.SYS; ein Programm mit dem Namen AUTORUN.SYS (MyDOS 4.50 und 4.51) oder *.AR0 (MyDOS 4.53, 4.54, 4.55) wird automatisch geladen (bei ML-Files einfach umbenennen, bei Basic-Files muss ein 1-2 Sektor langes Autorun-File erstellt werden, das dann das Basic Programm lädt); eine XE-RAMdisk wird standardmäßig via interner DOS Konfiguration und via externem RD-Treiber unterstützt; es gibt mehrere RD-Treiber bis zu einer Größe von 1024k RD; es existiert auch ein Batchfile-Enhancement von T. Karwoth; DOS-Menü: Ja! Das DUP.SYS hat ein Menü von A-; Formate: alle möglichen und unmöglichen, u.a. Single, Enhanced, Double; single-sided und doublesided; 35 Tracks, 40 Tracks, 77 Tracks und 80 Tracks; auch High-Density…; Sub-Directories: Ja! Harddisk-Partitionen: Ja, bis 16MB! Aux.: /N /A /Q /X max. Anzahl von Drives: 9 (als D1: bis D9:); Dir.-Einträge: immer max. 64; RAM unter dem OS: nicht genutzt, steht für Programme oder Treiber frei zur Verfügung; DOS 2.0 kompatibel: Single Density/SD: Ja ! , Double Density/DD: Ja ! DOS 2.5 kompatibel: Enhanced Density / ED: Nein! (zweite VTOC in Sektor 359); Speeder-Treiber: keine eingebaut und daher separate / externe Treiber notwendig; Anmerkung: die letzte offizielle Version war 4.50 (1988), es existieren aber einige gute Patches, wie z.B. 4.51, 4.53, 4.54 und 4.55, die alle dokumentiert sind (bzw. waren); leider sind auch in der letzten Version noch zahlreiche (kleinere) Bugs vorhanden…;

– Bewe-DOS 1.x:
Hersteller bzw. Autor war Bewesoft (Jiri Bernasek), das DOS besteht nur aus einem File XBW13.DOS und ist Sparta-DOS kompatibel (und demzufolge DOS 2.x inkompatibel). Ein Programm kann via Batchfile- Verarbeitung (ein einfach selbst zu erstellendes Textfile mit dem Namen STARTUP.BAT) automatisch geladen werden. Eine XE-RAMdisk wird via Treiber RAMdisk.Com bis zu einer Größe von 1024k unterstützt (der Treiber muss aber entweder manuell oder via Batchfile geladen werden). Im ABBUC-Magazin released und upgedatet. DOS-Menü: Nein! Das DOS ist Kommando-orientiert! Es gibt keine eingebaute Befehlsübersicht, d.h. die Kommandos muß man kennen oder im Manual nachschlagen; Formate: 90k / SD, 130k / ED, 180k / DD, 360k / QD (= DSDD, 40 Tracks); Sub-Directories: Ja! Harddisk-Partitionen: Ja, bis 16MB! Aux.: /N /A max. Anzahl von Drives: 4 (als D1: bis D4:) + RD; Dir.-Einträge: max. 1024? ; RAM unter dem OS: nicht genutzt, steht für Programme oder Treiber frei zur Verfügung; DOS 2.0 kompatibel: SD = nein, DD = nein, da Sparta- Format kompatibel; DOS 2.5 kompatibel: ED = nein, da Sparta-Format kompatibel (via MENU.COM können SD/ED/DD Files aber ins Atari DOS 2.x oder ins Sparta-Format konvertiert werden) Speeder-Treiber: keine eingebaut, externe Speeder notwendig (für XF551 mitgeliefert); Anmerkung: die letzte offizielle Version war 1.30; obwohl das DOS nur bis max. 360k formatieren kann, so kann es dennoch alle Sparta-Formate bis 16MB lesen und (be-) schreiben; man kann es sogar von/auf einer 16MB Partition bootfähig machen; die Zeit und Datums- Funktion von Sparta wird voll unterstützt; das DOS ist außerhalb Europas relativ unbekannt;

– Sparta-DOS 3.2x
Hersteller war ursprünglich ICD, später hat FTE die Rechte davon erworben und sich dann leider „aus dem Staub gemacht“. Das DOS besteht aus einem File X32x.DOS und ist DOS 2.x inkompatibel. Atari-DOS 2.x Formate können aber intern gelesen und angezeigt werden. Ein Programm kann via Batchfile-Verarbeitung (ein einfach selbst zu erstellendes Textfile mit dem Namen STARTUP.BAT) automatisch geladen werden. Eine XE-RAMdisk wird via externem Treiber bis zu einer Größe von 1024k unterstützt (der Treiber muss aber entweder manuell oder via Batchfile geladen werden). Wurde u.a. im ABBUC-Magazin released und upgedatet. DOS-Menü: Nein! Das DOS ist Kommando-orientiert! Es gibt keine eingebaute Befehlsübersicht, d.h. die Kommandos muß man kennen oder im Manual nachschlagen; Formate: alle möglichen und unmöglichen Formate, Single, Enhanced und Double; single-sided und doublesided; 35 Tracks, 40 Tracks, 77 Tracks und 80 Tracks; High Density… Sub-Directories: Ja! Harddisk-Partitionen: Ja, bis 16MB! Aux.: /N /A max. Anzahl von Drives: 9 (als D1: bis D9:); Dir.-Einträge: max. 1024? ; RAM unter dem OS: wird vollständig genutzt, ergo lassen sich damit keine Programme (z.B. TB XL ) oder Treiber (z.B. XL-RD) laden, die ebenfalls diesen Speicherplatz verwenden… DOS 2.0 kompatibel: SD = nein, DD = nein, da eigenes „Sparta-Format“ DOS 2.5 kompatibel: ED = nein, da eigenes „Sparta- Format“ (via MENU.COM können SD/ED/DD Files aber ins Atari DOS 2.x oder ins Sparta-Format konvertiert werden) Speeder-Treiber: es ist ein ultraspeed Treiber vorhanden, der Happy, Speedy und US Doubler (und kompatible Laufwerke) unterstützt; für XF551 und Turbo sind keine Speeder eingeb.; Anmerkung: die letzte offizielle Version war 3.2g; Sparta-DOS bietet eine Datums- und Zeit- Funktion; für den Betrieb mit einer XF551 muss das DOS und/ oder der Formatter (XINIT.COM) gepatcht werden, da man sonst beim Booten immer die Nachricht „Error – no DOS!“ erhält. Dazu sind mehrere Patch- Programme erhältlich…

– Sparta DOS 3.3x:
Hersteller bzw. Autor war Stephen J. Carden, es existieren die Varianten 3.3a, 3.3b und 3.3c. Diese Versionen von Sparta-DOS wurden speziell für den Betrieb von Mailboxen mit dem Programm „BBSExpress- Pro“ hergestellt. Es gibt nach wie vor Diskussionen darüber, wer der offizielle Rechte-Inhaber von 3.3x ist. Das DOS besteht aus einem File X33x.DOS und ist zu Atari DOS 2.x inkompatibel; Atari-DOS 2.x Formate können aber intern gelesen und angezeigt werden. Ein Programm kann via Batchfile- Verarbeitung (ein einfach selbst zu erstellendes Textfile mit dem Namen STARTUP.BAT) automatisch geladen werden. Eine XE-RAMdisk wird via externem Treiber bis zu einer Größe von 1024k unterstützt (der Treiber muss aber entweder manuell oder via Batchfile geladen werden). DOS-Menü: Nein! Das DOS ist Kommando-orientiert! Es gibt keine eingebaute Befehlsübersicht, d.h. die Kommandos muss man kennen oder im Manual nachschlagen; Formate: alle möglichen und unmöglichen Formate, Single, Enhanced und Double; single-sided und double- sided; 35 Tracks, 40 Tracks, 77 Tracks und 80 Tracks; High Density… Sub-Directories: Ja! Harddisk-Partitionen: Ja, bis 16MB! Aux.: /N /A max. Anzahl von Drives: 9 (als D1: bis D9:); Dir.-Einträge: max. 1024? ; RAM unter dem OS: wird vollständig genutzt, ergo lassen sich damit keine Programme (z.B. TB XL ) oder Treiber (z.B. XL-RD) laden, die ebenfalls diesen Speicherplatz verwenden… DOS 2.0 kompatibel: SD =
nein, DD = nein, da eigenes „Sparta-Format“ DOS 2.5 kompatibel: ED = nein, da eigenes „Sparta- Format“ (via MENU.COM können SD/ED/DD Files aber ins Atari DOS 2.x oder ins Sparta-Format konvertiert werden) Speeder-Treiber: es ist ein ultraspeed Treiber vorhanden, der Happy, Speedy und US Doubler (und kompatible Laufwerke) unterstützt; für XF551 und Turbo existieren keine Speeder; Anmerkung: die letzte offizielle Version war 3.3c; Sparta-DOS bietet eine Datums- und Zeit- Funktion; für den Betrieb mit einer XF551 muss das DOS und/oder der Formatter (XINIT.COM) gepatcht werden, da man sonst beim Booten immer die Nachricht „Error – no DOS!“ erhält. Dazu sind mehrere Patch-Programme erhältlich. Leider laufen div. Sparta-DOS only Programme nur unter Sparta-DOS 3.2x, deshalb wurden für 3.3x sog. Versionsnummer-Faker geschrieben (Faker.Com und Setvers.Com)…

– Sparta DOS X-Cartridge (4.x):
Die Sparta-DOS X cartridge wurde von ICD hergestellt und später an FTE weiterverkauft. Da FTE heute nicht mehr aktiv ist, kann man SDX kaum noch erhalten. Es handelt sich bei SDX um eine sog. Super- oder Megacartridge, in der neben dem DOS auch noch zahlreiche Utilities vorhanden sind; das Modul ist abschaltbar, erlaubt das aufstecken weiterer Module (die dann ebenfalls abschaltbar werden) und kann Programme die das RAM unter dem OS benötigen via banked RAM (XRAM) problemlos starten. Das DOS ist weiterhin DOS 2.x inkompatibel, Atari-DOS 2.x Formate können aber intern gelesen und angezeigt werden. Ein Programm kann via Batchfile-Verarbeitung (ein einfach selbst zu erstellendes Textfile mit dem Namen STARTUP.BAT) automatisch geladen werden. Eine XE-RAMdisk wird via externem Treiber bis zu einer Größe von 1024k? unterstützt (der Treiber muss aber entweder manuell oder via Batchfile geladen werden). DOS-Menü: Nein! Das DOS ist Kommando-orientiert! Es gibt keine eingebaute Befehlsübersicht, d.h. die Kommandos muss man kennen oder im Manual nachschlagen; Formate: alle möglichen und unmöglichen Formate, Single, Enhanced und Double; single-sided und double- sided; 35 Tracks, 40 Tracks, 77 Tracks und 80 Tracks; High Density… Sub-Directories: Ja! Harddisk-Partitionen: Ja, bis 16MB! Aux.: /N /A max. Anzahl von Drives: 9 (als D1: bis D9:); Dir.-Einträge: max. 1024? ; RAM unter dem OS: ??? Programme die diesen Speicherplatz benötigen können via banked RAM (XRAM, also 128k RAM minimum) problemlos geladen werden; DOS 2.0 kompatibel: SD = nein, DD = nein, da eigenes „Sparta-Format“ DOS 2.5 kompatibel: ED = nein, da eigenes „Sparta- Format“ (via MENU.COM können SD/ED/DD Files aber ins Atari DOS 2.x oder ins Sparta-Format konvertiert werden) Speeder-Treiber: es ist ein ultraspeed Treiber vorhanden, der Happy, Speedy und US Doubler (und kompatible Laufwerke) unterstützt;
Anmerkung: Die letzte offizielle SDX Version war 4.22; Sparta-DOS bietet eine Datums- und Zeit- Funktion; der lästige XF551-Bug ist hier nicht vorhanden. Leider laufen div. Sparta-DOS only Programme nur unter Sparta-DOS 3.2x, deshalb kann man für Version 4.x sog. Versionsnummer-Faker benutzen (Faker.Com und Setvers.Com)… Da ich einige DOS Versionen gar nicht kenne oder besitze, sind in dieser Liste bestimmt noch Fehler vorhanden. Für etwaige Korrekturen oder Hinweise wäre ich dankbar… (A.M.)

– Alle Angaben ohne Gewähr –
(Andreas Magenheimer)

ABBUC e.V. PD-Neuheiten

Hallo Bitbyter!
Diesmal nicht ganz so viele PD-Disks wie gewohnt. Beruf und Familie brauchen im Moment fast meine gesamte Zeit. Daneben aus gegebenem Anlass noch ein paar Anmerkungen: Bitte denkt daran, dass es ein zeitintensives Hobby ist. Daher bitte ich euch, einfach den Regeln für die Bestellung aus der PD-Liste zu folgen, andernfalls funktioniert es nicht gut. Bestellung bei mir, den von mir mitgeteilten Betrag auf das Clubkonto überweisen. Sobald Wolfgang aus der Clubzentrale mitgeteilt hat, dass das Geld eingegangen ist, stelle ich die Sendung zusammen und verschicke sie an euch. Da die Zentrale in Deutschland ist und ich den Niederlanden wohne, dauern andere Formen der Bestellung einfach länger, z.B. weil ich von Wolfgang erst eine Adresse erfragen muss, etc. Und solltet ihr PDs haben, die noch nicht in der Bibliothek erfasst sind, bitte ich euch, mir darüber eine Info zukommen zu lassen. Die Bibliothek ist nicht mein Baby sondern von Bitbytern für Bitbyter gemacht. Und nun zu den neuen Aufnahmen in die Bibliothek:

0721 Serie Disk-Mag: AMC-Soft 3-1986 BASIC ED/2S
Eine bunte Mischung zum ATARI, der auch ein wenig die damals aktuelle ST-Szene mit einbezieht. Infos zu vielen Spielen, Hardware für den XL, Modifikation des DOS 2.5 für den 64K-XL (RAMDisk), Bilder, Lesermeinungen. Spiel des Magazins: PQR I. Nachlesen und nachempfinden der guten alten Homecomputer-Zeit wäre ohne den AMC kaum vollständig.

0722 Serie Disk-Mag: QUICKmagazin 8 & 9 Joystick 2S/ED
Quick-Listings analysieren und auf dem ATARI 1029 drucken; Directory abfragen; Logische Verknüpfungen anhand von Beispielen; Bilder-Show selber programmieren; schnelle Grafik mit eigenen Routinen; Fraktale Kondensation am Beispiel Kristallwachstum; Algorithmus Grafik; Tastaturprogrammierung. Diese Routinen zeigen auf, was mit Hilfe von QUICK auf dem 8-Bit-ATARI möglich ist.

0723 TopDOS 1.5 (Standard) SD/1S
Mit der Professionalisierung von Anwendungen auf dem ATARI 800 und später dem 800XL wurden in den 80ern auch erstklassige Disk Operating Systems entwickelt. Die ATARI-DOS waren dagegen eher simpel. Seit 2005 ist TopDOS, von dem es drei verschiedene Versionen gibt, als Public Domain freigegeben. Hier also die Standard-Version für den Standardanwender mit ATARI plus Floppy. Mit auf Disk ein Hilfe-System in Englisch, das dem Anwender auf die Sprünge hilft.

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