ABBUC Magazin 059

 

Impressum
© 1999 Atari Bit Byter User Club e.V.
C/O Wolfgang Burger, Wieschenbeck 45
D-45699 Herten Tel. +49 2366 396323
Mail Wburger@cityweb.de
Das Atari Bit Byter User Club Magazin erscheint
¼ 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.


Inhalt:
Seite 3 Erlebnisberichte Teil 6
Seite 5 Cracking The Code Teil 15
Seite 16 Die gebräuchlichsten Dateitypen auf dem ATARI
Seite 19 Erlebnisberichte Teil 7
Seite 25 Die Jahreshauptversammlung 1999
Seite 29 Schreiersgrün 2000
Seite 30 Die 1 MB Speichererweiterung
Seite 32 Neues von der ABBUC-PD

 

Erlebnisberichte Teil 6

Der Grund, wie ich zu Computern kam, mag heute sehr wahrscheinlich für ungewollte Heiterkeit sorgen, denn eigentlich wollte ich unbedingt mal eine elektrische Schreibmaschine haben. Das hängt mit meiner Leidenschaft für das Schreiben und Publizieren zusammen, weshalb ich mir schon damals noch als Schüler so ein praktisches Gerät wünschte. Leider waren meine finanziellen Mittel für eine Anschaffung zu begrenzt, und es war auch nicht zu erwarten, dass ich jemals eine geschenkt bekommen würde, denn ich stand der felsenfesten Meinung gegenüber, für eine elektrische Schreibmaschine brauche man ja immer Strom und das wäre äußerst hinderlich. Zwar hatten zwei meiner Freunde, die dazu noch im selben Ort wohnten wie ich, zu der Zeit schon ihre ATARI XL´s und versuchten mich immer zu überreden, mir doch auch einen anzuschaffen. Aber das wollte ich nicht, erstens wollte ich ja nur eine kleine Schreiberleichterung haben und dann kosteten sie damals (es war so um das Jahr 1984/85 herum) noch für heutige Verhältnisse unglaubliche 500 DM.

Das war mir einfach zu teuer, so musste ich also weiterhin mit einer mechanischen Schreibmaschine vorlieb nehmen und auf bessere Zeiten hoffen. Diese kamen dann auch später. Es war im Jahre 1987, ich kam in die Ausbildung zum Industriekaufmann und mein Bankkonto erfreute sich eines größeren Zuflusses, so dass nun auch größere Anschaffungen in den Bereich des Möglichen gerieten. Da meine Freunde nicht müde geworden waren mir zu erzählen, wie toll man doch mit einem Computer schreiben könnte und die Preise inzwischen stark gesunken waren, kaufte ich mir auch dann endlich einen 800 XE mit einem Laufwerk 1050, was zusammen etwa 400 DM kostete.

Da stand sie nun vor mir, diese Wunderkiste, und als erstes schrieb ich einen schönen Text darauf und wollte ihn abspeichern, aber es klappte nicht. Nachdem ich meinen Freund angerufen hatte, musste er mir erst mal erklären, dass man mit dem Befehl SAVE nicht den Bildschirminhalt, sondern ein Basic- Programm abspeichert. Durch seine Beschreibungen neugierig geworden, begann ich mich dann auch mit dieser Sprache zu beschäftigen, und die Freude über erste Erfolge war natürlich groß. Noch größere Freude brachte mir allerdings kurze Zeit später ein Textverarbeitungsprogramm, mit dem ich meiner Schreiblust endlich ungehemmten Lauf lassen konnte und tatsächlich feststellte, dass das Schreiben mit dem Computer gegenüber der Schreibmaschine wirklich sehr viele Vorteile hat. Allein, es fehlte mir noch ein Drucker, um die getippten Ergebnisse auch auf Papier bringen zu können.

Also schaffte ich mir einen EPSON LX-800 an, ein 9-Nadel-Drucker, für den man im Jahre 1987 noch, so unglaublich das heute auch erscheinen mag, fast 600 DM hinblättern musste. Billiger war hingegen der Kauf einer besonderen PDDiskette, die noch im alten ATARImagazin erschien und auf die ich lange gewartet hatte, denn darauf war das Programm Der digitale Redakteur, womit ein einfaches Desktop Publishing möglich wurde. Jetzt konnte ich mit dem System richtig schön loslegen. Leider bewies das Laufwerk 1050 bald, dass es zu den anfälligsten Hardwarebestandteilen gehört, die ATARI je gebaut hat, denn nach weniger als einem Jahr fiel es zum ersten Mal aus. Erst war nur ein Kondensator locker gewesen, dann aber riss der Treibriemen, also musste es eingeschickt werden, und meine Computeraktivitäten fielen etwas zurück. Zudem erschien es mir eine Ewigkeit zu sein, bis das Laufwerk zurückkam.

Um nicht noch mal durch so einen Vorfall von wichtigen Projekten abgehalten zu werden, legte ich mir eine zweite 1050 zu und zeigte meinen Freunden voller Stolz, wie gut und schnell man doch von einem Laufwerk auf das andere kopieren konnte. Tja, dann fing diese Sache mit Klaus Peters an. Von ihm ließ ich mir eine 320k- Erweiterung in meinen 800 XE einbauen. Und der Geier weiß, was dieser Mann noch mit dem Gerät angestellt hat, jedenfalls zeigten sich danach das ein oder andere Mal gewisse Macken, bis eines Tages der Bildschirm völlig schwarz blieb. Ich schickte ihn also an die Firma Peters ein, bekam ihn zurück, schloss ihn an – und er funktionierte nicht. Herr Peters hatte allerdings schon seine Nachnahme kassiert. Nun denn, ich schickte ihn also noch mal ein, und als er wiederkam, funktionierte er dann zum Glück (erst später bekam ich bei einem zweiten Vorfall dieser Art zufällig mit, dass sich durch den Transport mit der Post lediglich ein paar Kontakte gelöst hatten, was allerdings hätte vermieden werden können, wenn Herr Peters eine ordentliche Paketpolsterung verwendet hätte).

Da mir dieser unnötige Ausfall auch auf den Geist ging, beschloss ich, mir noch einen Ersatzcomputer zulegen, und so dauerte es nicht lange, bis sich ein 130 XE bei mir dazugesellte. Natürlich blieb es nicht nur dabei, so kamen im Laufe der Zeit durch eine Kleinanzeige eine Maltafel hinzu, Paddels und zuletzt durch einen Wettbewerbgewinn auch noch ein Datenrekorder. Noch heute werden 800 und 130 XE oft genutzt – wer WASEO kennt, weiß warum :)!

Thorsten Helbing waseo@atari-computer.de

Cracking the code Teil 15

Von Keith Mayhew

Für den ABBUC ins Deutsche übersetzt von Alfons Klüpfel Anmerkung: Wir bitten die schlechte Qualität der Listings, Tabellen und Abbildungen zu entschuldigen. Sie liegen uns nur in genauso – schlechter Qualität vor (Fax bzw. schlechte Kopie). Wir beginnen unsere Tour durchs Operating System (OS) mit dem CIO, der zentralen Ein- und Ausgabe (Central Input and Output). Der CIO bietet die Möglichkeit, Daten von und zu folgenden Geräten zu lesen und zu schreiben: Keyboard (Tastatur), Diskettenstation, Kassette und Bildschirm.

Überblick

Bevor wir uns in den Tiefen des OS verlieren, ist es sinnvoll erst mal einen Einblick in die Struktur des OS und der Möglichkeiten zu gewinnen, die es uns bietet. Das CIO steht ganz oben auf einer Rangliste von Routinen, die Aus- und Eingabe am Computer unterstützen. Es gibt je einen Treiber (bzw. Treibersoftware, A.K.) für jedes Gerät (mit dem der Prozessor zusammenarbeitet. A.K.). Diese Treiber liegen entweder ständig vor (permanent) oder sie werden nach Bedarf nachgeladen, wie beispielsweise Treiber für RS232-Ports. Zur Unterstützung von Geräten, die über den seriellen Port angeschlossen sind wie etwa die Diskettenstation, bietet der Serielle Einund Ausgabetreiber (der SIO oder Serielle In- und Output) eine hochwertige Verbindung. (Und wenn man eine Zeit lang mit anderen Computern wie dem ST, einem Apple oder gar einer DOSe gearbeitet hat und kommt dann wieder an seinen geliebten XL mit einer Speedy-1050, dann ist man angenehm enttäuscht, wie schnell die Datenübertragung doch mit diesen quicklebendigen Dinos vor sich ging/geht. Zumindest hört es sich so an. A.K.) Die Teile des OS, die nicht direkt etwas mit Ein- und Ausgabe zu tun haben, sind deutlich in der Minderzahl. Es sind die Interrupt- Routinen und der sogenannte Monitor, der beim Hochfahren des Systems und bei einem Reset aktiv wird, um das System zu initialisieren und um ggf. die Regie an eine Software weiterzugeben wie etwa BASIC. Das Fließkomma-Paket (FPP = Floating Point Package) arbeitet völlig selbstständig, obwohl es Teil des OS ist; man stellt sich das am besten als einen Satz an Utility- Routinen vor, mit deren Hilfe man mit Kommazahlen arbeiten kann. Das OS belegt die 8 Kbyte von E000 bis FFFF in allen Systemen. Dabei wird für den Systemzeichensatz das erste Kbyte von E000 bis E3FF benutzt. Das FPP liegt im Anschluss an das OS im 2K-Bereich von D800 bis DFFF. Die XL- und die XE-Computer belegen außerdem (aus ihrem ROM) Speicherplatz im 4K-Bereich von C000 bis CFFF, wo sie einen weiteren Zeichensatz von CC00 bis CFFF zur Verfügung stellen. Der Extra- ROM-Platz wird für den Selbsttest und andere, unwichtigere Zusätze genutzt.

Der RAM-Speicher

Wie euch zweifelsohne bewusst ist, ist die Page 0 des Speichers von 00 bis FF ein bedeutender Bereich des Speichers für jedes Programm, das den 6502 benutzt: Sie bietet höhere Geschwindigkeit, das Programm kann kleiner sein, und am deutlichsten zu erkennen: die Fähigkeit des indirekten Adressierens d. h. man kann ein Paar Speicherzellen als Zeiger benutzen. Das OS setzt die erste 128 Bytes für seine eigenen Zwecke ein und lässt die andere Hälfte von 80 bis FF frei für Anwendungen. Allerdings wenn die FPP (Fließkommafunktion) eingesetzt wird, nutzt sie den Bereich von D4 bis FF selbst, so dass nur 80 bis D3 zur Verfügung stehen. Setzt man keine FPPRoutinen ein, stehen sie natürlich alle ( von 80 bis FF) zur freien Verfügung. Wird mit einer Sprache wie BASIC gearbeitet, benötigt diese weiteren Speicherplatz auf der Page 0: Das Standard Atari BASIC belegt 80 bis CA und D2 bis D3. Dies lässt für ein Anwenderprogramm den Zugriff auf den Bereich von CB bis D1 übrig, weil BASIC selbst FPP einsetzt. Es bleiben also gerade mal sieben Bytes für einen sicheren Zugriff. Ein Programm in der Art eines Spiels, das sowieso nicht aufs OS zugreift, kann den gesamten Speicher nach Belieben einsetzen. Mit anderen Programmen dagegen muss man sehr vorsichtig sein, sonst ergeben sich unerwartete (und unerwünschte, A.K.) Resultate. Page 1 ist immer für den Stack reserviert; dies ist durch das Design des 6502 vorgegeben. Falls man plant eine größere Datenmenge auf den Stack zu legen, sollte man vorher prüfen, ob der Stack nicht nicht überläuft (was bewirkt, dass sich dort alles verschiebt), oder man erstellt einen eigenen, privaten Stack, indem man einen Page 0-Zeiger benutzt. Der Speicherbereich von Page 2 bis Page 6 gilt als reserviert, Programme sollten also erst ab Page 7 aufwärts geladen werden. Der Bereich von 200 bis 47F wird vom OS benutzt, so dass 480 bis 6FF frei benutzbar sind. Naja, nicht ganz: FPP reserviert sich 57E bis 5FF. Somit ist die Page 6 die einzige im unteren Speicherbereich völlig unbenutzte Seite (Page).

Die OS Vektoren

Das Atari OS machte ausgiebigen Gebrauch von Vektoren um auf seine Ressourcen zuzugreifen. Unter Vektor versteht man einen Zeiger, der auf eine Routine deutet, die ausgeführt werden soll. Bedient man sich dieser Methode, heißt das, dass nur die Vektoren auf festen Speicherplätzen gehalten werden müssen, während die jeweils benötigten Routinen beliebig verteilt sein können. Dies bewirkt, dass Programme auch untere anderen Versionen des OS laufen. Die Zeiger im RAM sind besonders nützlich, da sie auf eigene Routinen „umgebogen“ werden können, so dass diese die Funktionen des OS ausweiten oder ändern können.

Zentrale Ein- und Ausgabe-Utilities

Das CIO ist der nützlichste Teil des Atari I/ O-Systems überhaupt; denn es bietet ein umfassendes, geräte-unabhängiges Interface zu jedem beliebigen I/O-Gerät. Das bedeutet, dass man um auf ein Gerät zuzugreifen nicht allzuviel Details über dieses Gerät wissen muss. (Ganz anders ist das beim C64, wo man erst für jedes Gerät und jeden Zugriff einen speziellen Kanal öffnen muss – so dass man letzteren bald voll hat. A.K.)

Ja, der CIO-Zugriff ist im Wesentlichen ähnlich wie BASIC-Befehle gestaltet: OPEN, CLOSE, INPUT; PRINT; GET und PUT. Alles, was BASIC in diesem Zusammenhang erledigt, ist das Umwandeln dieser Befehl in Aufrufe ans CIO. CIO-Aufrufe Alle CIO-Aufrufe erfolgen durch einen Vektor in E456. Die Anweisung an dieser Ad- resse ist eine Sprunganweisung (Jump) zum tatsächlichen CIO-Eingabe-Punkt (CIO entry point). Die Datenstrukturen, die benutzt werden um zwischen dem CIO und dem Anwenderprogramm Daten auszutauschen, werden I/O-Kontrollblocks genannt (IOCB). Es gibt acht IOCBs mit einer Länge von 16 Byte, jeder beginnt bei 340 und reicht bis 3BF.



Jeder dieser IOCBs enthält Kommunikations – Informationen über einen „Kanal“ (channel). Jeder dieser Kanäle ist entweder offen oder geschlossen. Ist er offen, läuft darüber entweder eine Eingabe, eine Ausgabe oder beides zu jeweils einem einzigen Gerät. Wird einer der Kanäle geschlossen, werden alle noch zur Übertragung anstehenden Daten weitergeleitet, der Kanal geschlossen und er steht dann für spätere Zwecke zur Verfügung. Wichtig! Jeder Kanal kann jedem Gerät zugewiesen werden. Es besteht keinerlei Unterschied zwischen den acht Kanälen. Tabelle 1 zeigt die Zuordnung der Bytes innerhalb des IOCB und ihre Beschreibung. Dies sind die wichtigsten: Was das CIO als Nächstes für den passenden Kanal ausführen soll, wird in ICCMD wei tergel e i tet , Tabelle 2 listet die zur Verfügung stehenden Befehle auf. ICSTA ist der Status des letzten CIOBefehls, der bezüglich des Kanals ausgeführt worden ist. Tabelle 3 listet die Statuswerte auf. Auf den Anwender- Puffer, der dazu dient, die Bytes zwischenzuspeichern, die übertragen werden sol len, wird von ICBAL und ICBAH aus gezeigt, seine Größe steht in ICBLL und ICBAH. ICAX1 bis ICAX6 enthalten geräteabhängige Informationen. Die Auflistung in Tabelle 2 und 3 sind die Standardwerte, die in allen Systemen vorhanden sind und enthalten die Disk- Operationen, die von allen DOS-Versionen unterstützt werden. Neue Gerätetreiber fügen evtl. neue Befehle und neue ERRORCodes zu den vorhandenen hinzu. Dazu muss man ggf. im jeweiligen Handbuch nachschlagen. Um einen CIO-Befehl auszuführen geht man so vor: 1. Man gibt alle nötigen Bytes in einen IOCB. 2. Man lädt das X-Register mit dem Index dieses IOCB von der Adresse 340 HEX ($340). Dies entspricht dem 16-fachen der gewünschten Kanalnummer (0-7). 3. Man springt zur Sub-Routine in E456 HEX ($E456). 4. Falls nötig prüft man das Y-Register, das eine Kopie des Statuscodes des IOCB enthält um zu überprüfen, ob evtl. ein ERROR aufgetreten ist. Achtung: Bei allen ERRORs ist Bit 7 gesetzt, d. h. sie sind negativ; eine BMIAnweisung stellt dies also fest, sobald der ERROR beim CIO ankommt.

Grundsätzliche CIO-Befehle
Die ersten sieben Befehle in Tabelle 2 sind die gebräuchlichsten CIO-Funktionen, die von fast allen Geräten unterstützt werden. Hier eine Beschreibung: OPEN (Öffnen) Der IOCB-OPEN-Befehl (03) muss ausgeführt werden, bevor weitere CIO-Befehle durch ein bestimmtes IOCB ausgeführt werden können. Die Puffer-Adresse (ICBAL und ICBAH) muss auf einen ASCII-String deuten, der durch ein End-of-Line-Zeichen (EOL) (dezimal 155) abgeschlossen ist. (EOL ist auch das Zeichen, das durch Drücken der RETURN-Taste eingegeben wird.) Der ASCII-String beginnt mit einem Anfangsbuchstaben, der festlegt, um welches Gerät es sich handelt. Darauf kann eine Ziffer folgen, falls mehrere gleiche Geräte möglich sind, also beispielsweise zwei Diskettenstationen (D1 und D2). Es folgt ein Doppelpunkt (:) und ggf. ein Filename (falls dieses Gerät Files bearbeitet, etwa eine Diskettenstation). Dies funktioniert tatsächlich genauso wie mit den Filenamen in BASIC. Dies sind die Standard-Geräte-Bezeichnungen:
E: Editor
S: Screen
K: Keyboard
C: Cassette
P: Printer
D: Disk Drive (nicht fest im OS)
R: RS232 (nicht fest im OS)

Es ist festzustellen, dass die letzten beiden Geräte (D: und R:) nicht fest im OS bzw. im Computer vorliegen. Sie müssen beim Hochfahren des Computers extra hinzugeladen werden (Diskette mit DOS!, A.K.), falls sie benötigt werden. Es ist auch wichtig zu erkennen, dass der Editor manchmal durch das OS geöffnet wird, damit Mitteilungen gezeigt werden können oder um den Bildschirm für eine andere Anwendung vor zubereiten. IOCB Nummer 0 wird vom OS immer für eine derartige Funktion reserviert und sollte daher am besten nicht für ein anderes Gerät als „E:“ geöffnet oder geschlossen werden.

ICAX1 und ICAX2 werden benutzt um (geräteabhängig) Informationen zu transportieren, wie das entsprechende Gerät zu öffnen ist. Diese beiden Adressen entsprechen den beiden Zahlen, die im BASIC OPEN- Befehl spezifiziert werden. Gewöhnlich steht in ICAX2 eine Null und in ICAX1 eine 4 für Nur-Lesen, eine 8 für Nur-Schreiben und eine 12 für Lesen-und-Schreiben. ICAX3 bis ICAX6 werden nur für sehr wenige Geräte benötigt und können daher in den meisten Fällen vernachlässigt werden.

CLOSE (Schließen)

Der IOCB-CLOSE-Befehl (OC) wird für einen IOCB verwendet, der irgendwann vorher geöffnet wurde und nun nicht länger benötigt wird. Es werden keine weiteren Informationen angegeben (nicht einmal ein Filename). Ein CLOSE-Befehl sichert auch die Übertragung der noch verbleibenden Daten an das entsprechende Gerät. GET & PUT CHAACTERS (Zeichen holen bzw. setzen) Der GET CHARACTERS Befehl (07) (Hole Zeichen) liest eine Anzahl von Bytes, die durch die Puffergröße begrenzt wird (ICBLL und ICBLH). Der PUT CHARACTERS Befehl (OB) schreibt entsprechend viele Bytes vom Puffer zum Gerät. Für jeden der beiden Befehle kann als Puffergröße Null angegeben werden. In diesem Fall wird das Zeichen in bzw. aus dem Accumulator des 6502 gelesen. Alle IOCBWerte bleiben unverändert wie vor dem Aufruf, außer dass ein GET CHARACTERS Befehl die Anzahl der tatsächlich gelesenen Bytes in die Speicherzelle schreibt, in der die Puffergröße festgehalten wird. Sind weniger Bytes gelesen worden, liegt dies daran, dass ein EOF (end-of-file) aufgetreten ist.

GET & PUT A RECORD

Diese beiden Befehle sind ähnlich wie die beiden vorherigen, sie sind jedoch nützlich, wenn man nicht genau weiß, wie viele Zeichen man denn lesen bzw. schreiben will. Der GET RECORD Befehl (05) liest so viele Zeichen in den ausgewählten Puffer, bis ein EOL-Zeichen kommt und in den Puffer geschrieben ist. Man muss allerdings immer noch eine Puffergröße vorgeben und schließlich die tatsächliche Größe in ICBLL und ICBLH festhalten. Ist der Puffer schon voll, bevor ein EOL gefunden ist, dann liest das CIO die restlichen Zeichen und gibt einen ERROR aus: Unvollständiger Eingang der Daten (truncated code). Der PUT RECORD Befehl (09) schreibt alle Zeichen des ausgewählten Puffers bis (und einschließlich!) zum ersten EOL-Zeichen zu dem ausgewählten Gerät. Enthält der Puffer kein EOL dann fügt das CIO dies automatisch an.

STATUS

Alle CIO-Aufrufe schreiben unmittelbar nach dem Aufruf einen Status-Code in das YRegister. Dies kann man überprüfen, wenn man wissen will, ob ein Fehler aufgetreten ist. Zusätzlich wird dieser Wert im Status- Byte des IOCB für spätere Bezugnahme festgehalten. Der Status-Befehl (0D) kann weitere Informationen übertragen, was jedoch geräteabhängig ist. Es unterstützen jedoch nicht alle OS-implementierten Handler diese Funktion und geben einfach ein „Kein Fehler“ an das Y-Register. Ein Beispiel-Programm Listing 1 ist die Assembler-Routine, die den Anwender auffordert, ein Eingabeund ein Ausgabegerät plus Filenamen anzugeben. Es kopiert dann vom einen (Ausgabe-) zum anderen (Eingabe-) Gerät bis ein EOF erreicht ist. Dies funktioniert genauso wie die Kopierfunktion des DOS. Es ist jedoch nützlich um zu verdeutlichen, wie das CIO arbeitet. Somit kann man dies in eigenen Programmen nützen. Listing 2 ist wieder das BASIC-Programm, das dazu dient das Assemblerprogramm einzulesen. Gestartet wird letzteres durch Eingabe von X=USR(24576) Das Programm enthält verschiedene Routinen, die die Verbindung zu den CIORoutinen herstellen. Jede geht davon aus, dass bestimmte IOCB Parameter gesetzt sind und dass das X-Register den IOCBIndex enthält, d. h. die Kanalnummer des IOCB mal 16.

OPEN“ öffnet einen IOCB
, schließt ihn jedoch zuvor, um sicher zu stellen, dass er frei ist. Es wird angenommen, dass die Pufferadresse für einen bestimmten Filenamen festgelegt ist und dass die Hilfsbytes entsprechend gesetzt sind. „READLN“ liest vorhandene Daten in den ausgewählten Puffer, „WRITELN“ schreibt Daten aus dem ausgewählten Puffer. Die Pufferlänge ist immer auf FFFF festgelegt, da die Daten einen EOL enthalten sollen. „GETBYTE“ liest ein einzelnes Zeichen in den Accumulator. Dazu muss kein IOCBParamter gesetzt werden. „PUTBYTE“ schreibt ein einzelnes Zeichen aus dem Accumulator. Auch dazu muss kein IOCBParamter gesetzt werden. „GETCHRS“ liest eine festgelegte Anzahl an Zeichen in einen ausgewählten Puffer, „PUTCHRS“ schreibt die festgelegte Anzahl an Zeichen aus einem ausgewählten Puffer. „CLOSE“ schließt den IOCB. Auch dazu muss kein IOCB-Parameter gesetzt werden. Das Programm startet mit dem WiederÖffnen des Editors, da er nicht garantieren kann, dass dieser immer geöffnet ist. Es schreibt dann eine Titel-Botschaft auf den Schirm und fordert auf, einen Filenamen einzugeben. Es folgt ein Aufruf für „INPUT“, das eine via Keyboard eingegebene Textzeile liest (Befehl „READLN“), die durch ein EOL; also RETURN abgeschlossen wird.

Es wird nun ein Test durchgeführt um festzustellen, ob eine ERROR-Meldung ausgegeben werden muss. Das könnte dann nötig werden, wenn der Anwender die BREAK-Taste gedrückt hätte, denn dies verursacht einen CIO-ERROR. Der eingegebene Filename wird dann im Nur-Lesen- Status geöffnet und derselbe Vorgang wird für das Zielfile entsprechend wiederholt. Sind die beiden Files erfolgreich geöffnet, wird das File mittels der Routine „CPYFILE“ kopiert. Sie versucht einen Puffer mit Daten des ersten Files zu füllen. Sie checkt dann den Status-Code. Findet sie keinen ERROR oder liegt ein EOF vor, dann kopiert sie die Puffergröße, in der festgehalten ist, wie viele Zeichen bereits gelesen sind, in den anderen IOCB und schreibt dann die Daten in das neue File. Nach einem Schreibvorgang wird nochmals überprüft, ob der vorherige Lesevorgang bereits alle gewünschten Daten übertragen hat (d. h. einen EOF enthalten hat). Ist dies nicht der Fall, springt die Routine zurück um mit dem Lesen der restlichen Daten fortzufahren. Ansonsten wird das Kommando an den Anwender zurückgegeben (d. h. die anfängliche Eingabe-Aufforderung steht wieder auf dem Schirm). Jeder „ERROR“-Aufruf erfolgt über „CIOERR“, wodurch sofort versucht wird, beide Files (Ein- und Ausgabefile) zu schließen. Das Programm wird dann gestoppt und das Kommando an den Anwender zurückgegeben (s. o.). „CIOERR“ ist ein recht nützliches Stückchen Code, das eine ERROR- Mitteilung und dazu den ERRORCode dezimal ausgibt. Den ERROR-Code dezimal auszugeben ist gar nicht so einfach, wie es auf den ersten Blick aussehen mag: Die nächstliegende Methode wäre, durch Vielfache von 10 zu teilen und den Rest stehen zu lassen. Dies ist jedoch eine ziemlich grausliche Methode und ziemlich langsam dazu, sobald es sich um größere Zahlen handelt.

Die verwendete Lösung ist dagegen recht elegant: Es schaltet den Dezimal-Modus per „SED“ ein und verschiebt dann die zu konvertierende Zahl Bit für Bit nach links. Bei jedem Verschiebevorgang wird dabei das Ergebnis verdoppelt (d .h. das Ergebnis wird einmal zu sich selbst hinzugezählt), das erste Byte wird um Eins erhöht, falls durch die Verschiebe-Operation das Carry- Flag gesetzt war. Am Ende dieser Schleife wird der Dezimal-Modus wieder abgeschaltet und das Ergebnis enthält den Binärcode in dezimaler Form (BCD) als die gewünschte Zahl. Ein einfache Print-Routine gibt dann jede Ziffer auf dem Schirm aus. Außerdem wird noch eine Prüfung durchgeführt, um unnötige Nullen am Anfang der Zahl zu unterdrücken. (Undemokratisch, sieht aber hübscher aus! A.K.) Es wäre sehr leicht, diese Dezimalumwandlung zu modifizieren, um damit auch größere Zahlen umwandeln zu können, um sie somit auch in anderen Programmen nützen zu können, z. B. zur Ausgabe von Speicheradressen. Das ERROR-Handling in diesem Beispiel ist dagegen eher primitiv: Es beendet einfach das Programm. Normalerweise fängt ein Programm auftretende Fehler recht effektiv ab und man kann danach problemlos weiterarbeiten. So kann der Anwender z. B. nach einem Schreibfehler gebeten werden , seine Diskettenstation bzw. seine Diskette zu überprüfen, so dass ein weiterer Versuch unternommen werden kann, die gewählte Aktion durchzuführen.

Beim nächsten Mal
Somit ist die Erläuterung unseres CIOProgramms abgeschlossen, das euch helfen soll eure eigenen Routinen zu schreiben, um grundsätzlich Ein- und Ausgaben zu bewerkstelligen. Beim nächsten Mal werden wir sehen, wie das CIO Gerätetreiber benutzt, um auf die entsprechenden Geräte Daten auszugeben bzw. von dort zu holen, und welche Möglichkeiten dies bietet.

STANDARDS
DIE GEBRÄUCHLICHSTEN DATEITYPEN AUF
DEM ATARI

In der folgenden Tabelle findet Ihr alle gängigen Dateitypen, die man auf dem ATARI finden kann. Ihr findet Informationen über die Dateinamenerweiterung, die Sektorenzahl
(Dateigröße), die Art und den Type einer Datei und eine Kurzbeschreibung. Die Sektorenzahl kann mit verbindlichen Zahlen oder auch geschätzten Werten angegeben sein.

Extender Sektoren Typ Art Beschreibung

PIC

<62

Bild

komprimiert

Koalapainter-Bild häufig benutztes Bildformat

PIC
MIC

62

Bild

Bitmap

Micropainter-Bild Standardformat, wird am häufigsten benutzt, das schnell geladen (praktisch ein Speicherspiegel)

256
PAINT?.PIC

62

Bild

Bitmap

Bild in 256 Farben die ersten 3840 Bytes enthalten die Farb-, die letzten die Helligkeitsinformation Durch geschickte DLI-Programmierung wird das Bild so dargestellt, dass immer eine Farb- und eine Helligkeitszeile angezeigt werden. Das PAL-Fernsehsystem stellt die Farbinformation einer Zeile immer zweizeilig dar, so dass die nächste Helligkeitszeile nicht schwarz/weiß, sondern auch in Farbe dargestellt wird. (die Interpretation, das menschliche Auge würde die Farben vermischen, ist falsch, denn die Farbzeile würde im Auge von der Helligkeitszeile verschluckt werden. Würde der ATARI als Ausgangssignal ein SECAM-Fernsehbild liefern, würde man tatsächlich nur ein schwarz/Weiß-Bild sehen. Mit einem ATARI-Emulator auf einem VGA-Monitor funktionieren diese Bilder ja schließlich auch nicht).

LUM
COL

je 32

Bild

Bitmap

wie 256, jedoch wird die Farbinformation in der COL-, die Helligkeitsinformation in der LUM-Datei gespeichert

 

Extender Sektoren Typ Art Beschreibung
PIC` >62 Bild Bitmap Bild mit 128 Farben dabei stehen vier Farben pro Zeile(anstatt für das ganze Bild) zur Verfügung
RGB
R
G
B
? (RGB)
62 (R,G,B)
Bild (-teile) Komprimiert (RGB)
Bitmap
JVIEW-Bilder
KPN
GR8
GR9
weit weniger als 62 Bild Vektor speichersparende Vektorbilder zugeschnitten auf Gr.15, Gr.8 und Gr.9
ATV sehr große Datei Video komprimiert ATARI-Video-Datei
VI7 216 Video Bitmap Video7x7 7 Bilder in Gr.7
TXT
ASC
sehr unterschiedlich Text unformatiert das gebräuchlichste Textformat auf dem ATARI. Texte können an jede beliebige Zeilenlänge angepasst werden
PRG ab 70 aufwärts Programm Turbo-BASIC dieses Programm ist nur unter dem System MTBS lauffähig
BOS ab 90 aufwärts Programm Turbo-BASIC dieses Programm ist nur unter der graphischen Benutzeroberfläche BOSS lauffähig
TUR
TRB
TB
TBS
sehr unterschiedlich Programm Turbo-BASIC BASIC-Programm nutzt die Sonderbefehle von Turbo-BASIC
BAS sehr unterschiedlich Programm BASIC dieses Programm ist unter dem eingebauten ATARI-BASIC und unter Turbo-BASIC lauffähig
LST sehr unterschiedlich Programm (-teil) BASIC ein als ATASCII-Text abgespeichertes Programmlisting wird häufig zum entfernen von unnützend Variablen (etwa aus einer vorherigen Beta-Version) oder zum verknüpfen zweier verschiedener Programme genutzt
TL
TBL
sehr unterschiedlich Programm (-teil) Turbo-BASIC wie LST, jedoch in Turbo-BASIC
GND um die 30-90 Programmteil Grundgerüst Grundgerüst einer Serie von Programmen, die z.B. alle die gleiche Optik haben sollen
DIS 10 Text Hyperlink ATARI-Network-Seite
bietet Hyperlinkfunktion
DBK je nach Datensätze Text Datenbank MS-Software-Datenbank-Datei

 

Extender Sektoren Typ Art Beschreibung
DAT sehr unterschiedlich Daten allgemein Diese unterliegt eigentlich keinem Standard. Sie wird verwendet, um irgendetwas zu speichern, seien es Bilder, Texte oder beides in einer Datei, alles ist erlaubt und alles wird gemacht. Da diese Endung auf diese Weise genutzt wird, sollten eigentliche Datenbankenprogramme sie nicht benutzen.
OBJ
DLL
1 bis 2 Programmteile Maschinensprache kleine ML-Dateien, die Routinen (Programmteile) beinhalten, die so in BASIC nicht realisierbar währen
EXE
COM
ca. 50-300, je nach Programm Programme Maschinensprache komplette ML-Programme, die nicht unter BASIC (sondern direkt auf Prozessorebene vom Computer) ausgeführt werden
SMP ca. 260 für 10 Sekunden Sound digitalisiert digitalisierte Geräusche
Um diese Dateien abzuspielen, braucht man die gesamte Prozessorleistung
AUM
MD8
MD4
MD2
ca. 100-260 Sound Musik Musikstücke, die digitalisierte Geräusche enthalten
KEM um die 23 Sound Musik Fast wie AUM, nur werden die Geräusche vom Soundchip, dem Pokey, selbst erzeugt. Wie der Sound dabei zu klingen hat, kann man dabei selbst bestimmen. KE’s Musikeditor bietet dafür viele Möglichkeiten.
GIF sehr unterschiedlich Bild CompuServe-Bitmap ein Austauschbildformat wird auf vielen Rechnerplattformen genutzt, auch auf dem ATARI
INI
INF
GAM
selten mehr als 1 Konfiguration   Einstellungen bestimmter Zustände eines Programms oder einer Diskette, die auch nach dem Ausschalten erhalten bleiben sollen dabei werden in GAM-Dateien meißt Spielstände gespeichert
Von Mirko Sobe   http://www.geocities.com/mssoft_2000/standard/index.html

 

Erlebnisberichte Teil 7

Warum „Im Land des Schreckens“ erst 1997 erschien oder: wie der A T A R I mein Leben veränderte…

Es gibt Dinge im Leben, die lassen sich in Kategorien zusammenfassen, z.B.

Kategorie 1:
Es gibt Dinge im Leben, die sollte man nicht erwähnen, z. B. (uuuups… – genau DAS meinte ich ! J )

Kategorie 2:
Es gibt ebenfalls Dinge im Leben, über die sollte man hinwegsehen, z.B. Programmfehler/Bugs, die auch der beste Programmierer (Namen zu nennen fällt unter die Kategorie 1 J ) mal übersehen kann – auch wenn sein Programm noch so gut und noch so durchdacht ist (schon wieder Kategorie 1)…

Kategorie 3:
Es gibt weiterhin Dinge im Leben, bei denen sollte man(n) nicht wegsehen, z.B. (Nein Raimund! NICHT was DU jetzt denkst… – siehe Kategorie 1…) z.B. so etwas wie Spaß! (Raimund – sitz!)

Kategorie 4:
Es gibt aber auch Dinge im Leben, daran kommt man einfach nicht vorbei – und davon möchte ich nach diesem (kurzen) Vorspann (kurz) erzählen…

… z.B. – wie ich über einen VC-20 (denkt an Kategorie 2 !!!) – dem SPASS am Neuen (Kategorie 3) zum A – und jetzt muss man sich das erst mal auf der Zunge zergehen lassen (wahre Gaumenfreude) … zum AAAAAA (kennt Jemand Bimmel und Bommel mit ihrem Buchstabenalphabet aus der Harald Schmidt-Show? – okay – Kategorie 1…) aber genauso könnte man dieses A… jetzt aussprechen… (Okay Raimund – das ginge auch anders – aber genug davon…) – um es kurz zu fassen: wie ich zum AAAAAATAAAAARI oder kürzer ATARI kam…

Es begab sich zu einer Zeit, wo Schüler wie ich ihre Hausaufgaben halbherzig und meistens in der Pause vor Schulstunde fertigten (Kategorie 2 …?) – da kam ich nach Hause und meine Aufgabe bestand darin, zu Lesen, mit Freunden die Gegend unsicher zu machen, etc.

Bis zu dem Zeitpunkt, als ich eine ATARI-2600 Videoconsole unterm Weihnachtsbaum mit PAC-MAN erhielt…
(Das war noch die mit brauner Holzblende…)
Lange gespielt – bis sie eines Tages abrauchte… (irgendwie gab es keinen Ersatz…)
Also stand ich ohne da …
Bis – tja bis jener Tag kam – als einer meiner (älteren) Brüder einen Brotkasten mitbrachte, der den Namen VC-20 von der Firma Commodore (Kategorie 1 1/2…) trug…
Sofort davon fasziniert, dass dieses Teil TASTEN hatte, LERNFÄHIG sein sollte – und sogar zum Spielen gebraucht werden konnte – war ich begeistert (Mal abgesehen davon, dass mein Bruder mich nur bei guter Laune an das Teil lies – oder wenn er zu faul war, es wegzuräumen… Nun Platzmangel und so…)
Also – lernte ich darauf die erste Tastatur kennen. Und die ersten BASIC-Befehle und das Eingeben von LISTINGS…
Dann kam die Wende… – mein Bruder kaufte sich (FREU HEUT NOCH DRÜBER) einen echten ATARI 800 XL! – Und nach bereits kurzer Zeit lernte ich NOCH MEHR LISTINGS abzutippen! (Kennt jemand Aquanaut von Kemal Ezcan? – Ich hab das Ding mit sämtlichen Levels eingetippt! – und mein Bruder meinte: gib mal ein LIST „D:AQUANAUT.BAS“, weil er dachte, so das Programm aufgeLISTet zu bekommen!!! – Ich habe ihm nie verziehen… J – oder CAMBODIA! Zahlenkolonnen habe ich Tagelang getippt…)
Aber was noch wichtiger war: ich lernte die sagenhafte Welt der (Abenteuer-)Spiele kennen…
Angefangen bei ATLANTIS über die guten amerikanischen Scott Adams Adventures… (Ich weiß heute selbst nicht mehr, wie es mir gelang, VOODO-Castle – das TEXT-Adventure ohne Hilfe selbst zu lösen!!! – Na ja – ich war zwar immer noch faul – aber meinem Englisch hat es sehr geholfen…)
Und damals war gerade die Zeit, als die Computer in der Schule eingeführt wurden.
Das nannte sich noch ITG (Keine Ahnung wofür das steht/stand – vielleicht für InformaTiG…? oh – Kat. 1…)
Ganz nebenbei besuchte ich die Informatik AG – damals lernte ich den Umgang auf Apple IIe (Kat. 1 1/2) – mit Basic und etwas Pascal (das war sooooo langweilig, Pascal, meine ich…).

Na ja, in Mathematik war ich auch kein Genie (angeblich setzt das LOGIK voraus…). Interessanter Weise gibt es dazu eine schöne Anekdote aus den 80ern…
Für die Lehrer war klar: Wer in Mathematik gut ist, ist dies im Umgang mit Computern auch – weil das ja die LOGIK ist…
Es stellte sich aber heraus – nach dem TEST in ITG – dass gerade die 1st class Schüler (Mathefetischisten – den Ausdruck kannte ich damals noch gar nicht…) die Looser waren – irgendwo hatte die LOGIK doch versagt – der Preis war: Der Mathe-Lehrer (nicht gut auf mich zu spreche
n – empfahl er doch meiner Mutter, mir den Computer zu verbieten – was diese aber verneinte – ich werde das nie vergessen) lies die Note aus ITG NICHT in die Mathe-Note mit einfließen, denn das hätte die LOGISCHEN Mathe-Noten der 1st class Matheknechte ziemlich UN-Logisch dreinschauen lassen… – na ja, ich geb´s zu: Meine 1 in ITG hätte meinen Matheschnitt von 4 auch etwas beeinflusst (wenn auch in die andere Richtung…)

Na ja – seit diesem Tag oder besser: seit den ersten Computer-Stunden hatte ich denen aus Kategorie 1 (Matheknechte..) gezeigt, was ne Harke is. – Und bevor jetzt Jemand fragt, was das mit dem ATARI zu tun hat:
ALLES ! – OHNE den ATARI wäre dieses POSITIVE Kindheitserlebnis nie eingetreten (Möge das einen kindischen Klang haben – dem Psychologen gibt das die Lebensberechtigung seines Tuns…)
UND – es kommt besser: Auch in Mathematik-Naturwissenschaft (Warum ich dieses Wahl-Pflicht-Fach gewählt habe weiß die andere Hälfte meines Gehirns: das Unterbewusstsein – ich weiß es nicht…)
Kam mir mein Computer-Wissen zugute: mit einem Notenschnitt von 3,6 (besser als in Mathe!) wäre ich der Einzige der Klasse gewesen, der ne 4 bekommen hätte…
ABER: Der Lehrer war niemand anders als unser bester ITG/Computer-Lehrer, der mir ne Chance gab:
Sollte ich doch sein Wasser-Füllstands-Programm auf dem Apple IIe verbessern – tja: gesagt getan, etwas beschleunigt das Ganze und ne schöne Grafik-Anekdote beigefügt… (Das würde jetzt den Rahmen unnötig strapazieren – war aber sehr lustig…) und schon hatte ich die 3 im Zeugnis…
So war der ATARI also das SPRUNGBRETT für das Verständnis mit Computern. Und obige wahren Begebenheiten mögen das nur bestätigen…
In den 80ern fing ich dann an, selbst zu programmieren… Sammelte vor allem Pokes (Mein absoluter Liebling: POKE 65,0!!! – Leute tut jedem USER einen Gefallen und stellt das Ladegeräusch leise… J )
Mein ERSTES ATARI-Buch (Geldmittel für einen 6.Klässler waren sehr beschränkt) war „ADVENTURES… und wie man sie …“ von Jörg Walkowiak (Kategorie 4!) – für schlappe 39,95DM – für mich oder besser meine Mutter ein kleines Vermögen! (Da weder Weihnachten, Geburtstag oder sonst was war…)
Ich lieb(t)e dieses Buch – wenn auch mit VIELEN Fehlern gespickt (Kategorie 2…) – vermittelte es mir doch die Grundlagen der ADV-Programmierung.

In der 2ten Hälfte der 80er gab es in der damaligen Zeitschrift „Happy-Computer“ einen Hunderttausendmark-Wettbewerb… für SPIELE-Programmierer…
Zwei meiner Klassenkameraden und ich wollten teilnehmen – ich das Programm und die Beiden die Sounds/Musik und die Bilder (ich lieferte die Maltafel mit Modul ARTIST von meinem Bruder…).
Inspiriert von ATLANTIS, LAPIS PHILOSOPHORUM, Mask of the sun, Serpents Star… wollten wir das Ultimative Adventure mit Super-Grafik, -Sound und -Parser entwickeln… aber :
Nun, die Sommerferien kamen – ich programmierte… – versuchte die DL zu ändern und TEXT/GRAFIK umschaltbar zu machen – die Sommerferien gingen. Stolz präsentierte ich mein komplettes ADV-Gerüst, das darauf wartete, die Handlungen von den 2 Kameraden einverleibt zu bekommen (wollten sie auch liefern…) – aber es kam anders: sie hatten außer ein paar Bildern NICHTS … und so gewannen wir keinen Hunderttausendmarkpreis… – und ich war „stinkesauer“… (Nicht wegen des Geldes – mehr wegen der nicht gehaltenen Versprechen.)
Aber: ich lernte ne Menge dabei…
Der ATARI bekam den „ERSTEN KONTAKT“ – mit Wasser… – und die Tasten streikten…
Mein Bruder startete diverse Lötversuche – und mehr schlecht als recht ging´s ab und an…
Gegen Ende der Schulzeit wusste ich: Computer – damit will ich mal arbeiten. Und der Beruf des „Datenverarbeitungs-Kaufmanns“ schien ideal: der Nachteil: er wurde (NOCH) nicht in meiner Umgebung ausgebildet geschweige denn wusste Jemand was davon… (Außer der Berufsberater… J )

Also beschloss ich, weiter Schule zu machen: Im Bereich Datenverarbeitung…
1988 kam der nächste LOGIK-Schock… – wollte ich doch die Höhere Berufsfachschule im (NEUEN!) Schwerpunkt DATENVERARBEITUNG belegen… – doch war Voraussetzung: NA? !
MATHE < 4 !!! (nicht <= 4 – und ich looste …)
Diese Regel wurde übrigens ein Jahr später abgeschafft – als sich das GEGENTEIL zeigte, dass nämlich die Mathe-Knechte die schlechteren Informatiker waren… (Das wusste ich schon länger… J )

Also nahm ich den Schwerpunkt „Rechnungswesen“ (Buchführung & Co…) – und freute mich über EDV als Teil im 2. Schuljahr des Fachs „Organisationslehre“!
Ich lernte DOS und PC´s und meine erste Anwendung: Textverarbeitung kennen…

Der ATARI ruhte immer mehr – dennoch las ich weiterhin das ATARI-Magazin…
Er streikte öfters wegen der defekten Tastatur…
Die Disketten staubten – ab und an kramte ich sie raus (BOULDERDASH kostete mich Nächte!!!)
Und ich verbesserte immer wieder mein Adv.programm. Ich war -abgetan von 2-Wort-Parsern, die Dich ständig mit „I don´t understand/Ich verstehe nicht“ zur Weißglut trieben oder Unlogik a la „Hacke Seil“ in ATLANTIS, was tatsächlich das Loch in die Mauer bringt… oder Toden wie „Deine Lebensuhr ist abgelaufen“ a la ATLANTIS… – nichts gegen das Spiel – ich hab´s gern gespielt!!! – geradezu besessen vom Gedanken, der (fast) perfekten Welt im Abenteuer, welches ganze Sätze versteht (VORBILD: LAPIS PHILOSOPHORUM – Der Stein der Weisen!!! Ich löste es bis auf eines: Das Ausgießen des Abdrucks beim Schmied fiel mir ums … nicht ein !!! – Ratet mal wem das einfiel: richtig, den 2 Mitstreitern des 100Tausendmarkpreises… – das ärgert mich heute noch…)

Ab und an und immer wieder – feilte ich an Einzelheiten. Ich optimierte das Programmgerüst – verkürzte das Programm immer mehr…

Das ATARI Magazin wurde eingestellt… – Aber „undercover“ weiterhin vertrieben…
Ich lernte „Steuerfachgehilfe…“ oder neuerdings „Steuerfachangestellter“ – ne Menge über PC´s und Modems und Windows…
… aber vergaß nie meinen ATARI…

Nach der Lehre hatte ich meinen Studienplatz! (INFORMATIK!) – UND: Die Bundeswehr wollte mich auch mal kennen lernen … (Trotz meiner Bittbriefe… und dem Zitat des Grundgesetztes: „KANN“ gezogen werden…)

Also 1.10.1992 ab zum Bund – und siehe da: T. Schall hatte es auch erwischt! (Ihn hatte ich 1990 an der Schule kennen gelernt – über einen gemeinsamen Bekannten: ACHTUNG: JETZT kommt ne Kategorie 1- BEICHTE!!!
Torsten war damals absoluter C-64-Spieler-Fetischist… J – Er wurde bekehrt: mit ihm bestellte ich ein Paket eines ATARI-Users – er erhielt eine Floppy 2000 und sonstiges und ich einen ATARI!!! – den ich so dringend brauchte!)

Beim Bund lernten wir Andreas Magenheimer kennen. (Da gibt´s diverse Geschichten – aber für eines muss ich mich noch entschuldigen: Damals waren die Heizungsrohre freigelegt, weil die Heizungen getauscht wurden. Und der (arme) Andreas saß als UvD im Kämmerchen – wir (gelangweilt?) sprühten DEO-SPRAY durch die Rohre und räucherten ihn geradezu aus… (Na ja – er war sauer – hatte wohl nen schlechten Tag…) – Untern vorm Gebäude schimpfte er wie ein Rohr-Spatz… Und darauf ließen wir die Puppen tanzen – besser gesagt fliegen: aus dem Fenster nach unten… – Gerüchten zufolge war sie zuletzt bei Torsten gesehen, wo sie zum trocknen hing… (Kategorie 3 2 1 … J )

Na ja – es (ver)ging auch – und Torsten infizierte mit seiner ATARI-Euphorie (damals machte er ST-Geschäfte mit Feldwebeln…) Andreas aufs Neue (der den ja schon lange vorher hatte… – den ATAR-Virus, meine ich…).

Nun – im Zeitraum 93 – 97 entwickelten Andreas und Torsten parallel ihre ATARI-Mentalität zu dem, was sie heute sind.

Ich traf Torsten wieder beim Studium an der FH Worms. Nein, ich studiere nicht Informatik – sondern, wen wundert´s Steuerrecht… – aber:
Im Jahre 1997 überkam mich die Erkenntnis, wenn
ich jetzt nicht mein Programm veröffentliche, dann NIE!
UND: Ich wollte irgend etwas für´s ATARI-Magazin machen: Einen Kurs z.B. Und da ich mich nun mal den Adventures verschrieben habe – wollte ich das auch tun!

So hackte ich im Sommer 1997 die KOMPLETTE STORY zu „Im Land des Schreckens 1“ (an Wochenenden!!!! – da ich unter der Woche täglich in den Semesterferien arbeitete!) in den ATARI – feilte an den „Nichtlinearen“ Handlungsabläufen – dachte mir die Schweinereien mit dem verstopften Gewehr aus (Bundeswehr-Erfahrungen…) und die düstere Story mit den (noch) düstereren Folgen…

Es war der Start-Schuss in eine AKTIVE Mitarbeit und erneute Euphorie im ATARI-Bereich…
Es folgten diverse Verbesserungen des Programms.

Nebenbei entwickelte ich das LOTTO- Programm zum Auswerten der Mi + Sa -Lottozahlen… (Wer in einer LOTTO- Gemeinschaft spielt und die Verantwortung für das Tippen hat der weiß wohl warum J )

Der Versuch, den 1.Teil als Grafik-Version umzusetzen scheiterte an 2 Dingen:
1. Der Tod von Armin Stürmer, der sich bereiterklärte, die Bilder für das Programm zu liefern! – DAS wäre ein GRAFIK-Adv. geworden… Die Bilder, die Armin bereits gezeichnet hatte sind leider nicht mehr aufzufinden. Aber ich werde dennoch nicht vergessen, dass er die Zeit investiert hat und bedauere, ihn nie selbst kennen gelernt zu haben.
2. Der Speicherplatz! – Ich arbeite just noch an der Auslagerung von Routinen… mir fehlen noch ca. 2000 Bytes…

Nun – ich wage die Hoffnung, die Grafik-Version doch noch hinzubekommen…
Und – einen 2ten Teil im Jahr 2000 fertig zu stellen… – (Ich freue mich selbst schon drauf, mir den Wirt vorzuknöpfen…)

Es ist – wie es ist… Mitglieder schwinden… (Kategorie 1…)
Missgeschicke passieren… (Kategorie 2…)
Neue Dinge nehmen unsere Zeit ein… (Kategorie 3…)
Aber: Der ATARI bleibt – die Faszination… (Kategorie 4…)

Er bleibt, weil die Menschen bleiben, die mit ihm arbeiten. Und so bleiben auch die Bekanntschaften und Freundschaften, die sich dadurch entwickeln…
Und wenn DAS nichts mit dem ATARI zu tun hat – dann bin ich hier fehl am Platz – aber dann wären wir alle fehl am Platz…(Und wie war das mit der Logik… ? )
Ich wünsche allen auch weiterhin – oder besser: vor allem – im Hinblick auf das Jahr 2000 – viel Spaß mit diesem Hobby6 – und mehr von der Kategorie 5: „Trotz knapper Zeit – und ich weiß, wovon ich rede – nicht die Kategorie 4 vergessen…“

In diesem Sinne beenden wir unser Gebet mit A T A R I … J

P.S.: Für eintretende Folgen durch obigen Text (nach oder während des Lesens) kann der Autor keine (Langzeit) Garantie übernehmen – Für Äußerungen UNTER, ÜBER bzw. VOR oder HINTER der Gürtellinie ist ausschließlich die Phantasie des Lesers verantwortlich. Für Fehlinterpretationen ist eben so wenig der Autor der Haftung unterworfen wie für „sich beleidigt fühlende Dauernörgler“, „…Fanatiker…“ und sonstige Extremreagierende Individuen. Diesen empfehle ich einen Psychiater oder besser: einen Blick in die Länder der 3. Welt – denn dort werden einem die Augen geöffnet…

Wer noch immer nicht genug hat, dem empfehle ich: www.Michael-Berg.de
Wer mir per mail die Meinung sagen will: Michael_Berg@gmx.de

JHV 1999 (Nach(t)Gedanken)

Hallo ABBUCianer und ATARI-Fans …

Die 14te JHV ist vorbei und die Mitglieder sind gerüstet fürs Millennium, auf jeden Fall die, die da waren. Um es auf den Punkt zu bringen – es waren viel zu wenige. Soll denn der letzte große Anlaufpunkt in Sachen ATARI-8Bit auch noch aus Desinteresse oder Ignoranz das Handtuch werfen müssen? Kommen wir zurück zur JHV.

Am Samstagmorgen des 30.10.1999 um 6:00 Uhr klingelt es an der Tür und Walter Lauer kündigt durch Händereiben und einem breiten Grinsen im Gesicht seine Freude auf den Tag an. Nach einem Kaffee und Kisten verstauen fahren wir dann los. Schnell nach Luxemburg tanken und dann ab durch die Eifel und rauf auf den Highway.

Um 9:30 Uhr haben wir hinter’m Bürgerhaus den Anker geworfen und dann gab’s zuerst mal große Begrüßungszeremonien – man hat ja viele Gesichter ein Jahr lang nicht zu Gesicht bekommen. Trotzdem waren viele, auf die man gehofft hatte, letztendlich nicht erschienen (sniff).
Nach ein wenig Tischrücken hatte dann doch jeder ein Plätzchen gefunden und die Geräte surrten, summten, dudelten und ratterten um die Wette. Die ersten Besucher grasten die Stände ab um die besten Schnäppchen für sich zu ergattern.

11:10 Uhr! Die Fanfare ertönt oder war es Wolfgang, der die Mitglieder bat Platz zu nehmen für die Versammlung? Die obligatorische Begrüßung war schnell überstanden und der Jahresbericht wurde vorgelegt. Mit rund 470 Mitgliedern, wobei es einige Austritte gab, die wiederum durch Neuanmeldungen aufgefangen werden konnten, ist der ABBUC in den letzten zwei Jahren stabil geblieben. Wollen wir hoffen, dass es weiter so bleibt. Anschließend wurde der Vorstand neu gewählt. Das stellte sich als reine Fingerübung heraus, da alles beim alten geblieben ist – alles???
Nicht alles, denn Theo Schwacke, der bisher den PD-Service geleitet hatte, kann aus familiären Gründen diese Aufgabe nicht mehr wahrnehmen. So hatte der Vorstand in Erwägung gezogen den PD-Service „einzustampfen“. Das gab reichlich Anlass zur Diskussion. Zum einen wird sehr wenig Gebrauch davon gemacht – zum anderen aber ist diese Bibliothek ein Stück ABBUC – Nostalgie – und so etwas kann nicht einfach „gelöscht“ werden. Es gab eine Reihe von Vorschlägen (PD’s auf CD brennen, im Internet ablegen, etc.). Letztendlich fand sich doch jemand, der den Job von Theo nun übernehmen wird. Walter Lojek wird dies in Zukunft tun. Ich beneide Ihn nicht.

Ein weiteres Thema, das für Aufruhr sorgte, war das Erscheinungsformat des ABBUC – Magazins. Der Grund: viele User lesen das Disk-Magazin NUR noch auf dem Emulator (schämt Euch) und für jene ist es interessant, das Disk-Magazin auf 3 1/2 Zoll-Disk als Image (ATR, XFD) zu erhalten. Das aber würde nur noch alles komplizieren. Mein Vorschlag: es gibt sicher jemanden da draußen, der eine Web-Page hat und sich die Disk sowieso in ein Image wandelt. Soll doch jener auf seiner Homepage die Magazin-Images zum Download bereitstellen.
Ein weiter Punkt war das neue ATARI-Logo, das Hasbro nun verwendet. Im Grunde genommen ist es genauso wie das „alte“ – außer das ihm meiner Meinung nach der Schwung fehlt. Mir persönlich gefällt das alte Logo besser – es hat mehr Schwung. Das ist aber Ansichtsache!

Nach der Versammlung hatte jeder die Gelegenheit sich an den Ständen der Aussteller über Neuheiten oder bewährtes Altes zu informieren und das eine oder andere Angebot wahrzunehmen. Es waren eine Menge Aussteller dieses Jahr angereist. Leider hatte es den Anschein, als ob ein Teil davon nur gekommen war, um seine Hard- und Software zu verkaufen und es das letzte Mal war, wo man sie zu Gesicht bekam (ist eine rein innere Stimme, die mir das geflüstert hat). Gehen wir die Aussteller doch einfach mal durch, um zu sehen was es gab!

Der ABBUC hatte seine üblichen Stände aufgebaut PD, Infos, Kasse, Bauplanservice etc. Als Willkommensgeschenk verteilte der ABBUC dieses Jahr zwei Multimedia CDs, die zwar nichts mit dem XL direkt zu haben, aber trotzdem nicht schlecht sind.
Walter Lojek, wieder zurück aus den USA, hatte eine Menge Hardware aufgebaut, die es zu bestaunen gab. Wahrscheinlich hat er in den USA kräftig gesammelt!? Leider erfuhr ich zu spät, dass diese Sachen teilweise auch verkauft wurden.
Erhard Pütz musste seiner Aufgabe als Floppy-Doc gerecht werden und hatte alle Hände voll zu tun. Er bot Speedy, ROM-Disks usw. (aus dem ehemaligen Peters „Nachlaß“) zum Verkauf an.


Das ATARI-Fanzin „ATARI Classic“ war auch angereist und hatte ein wenig Publik für das Magazin gemacht. Das ATARI Classic ist ein ATARI-Papermag mit Schwerpunkt ST/TT/Falcon & Milan. Einige Seiten werden dem XL/XE gewidmet. Nach Angaben der Redakteure liegt das aber auch an der Mitarbeit der Leser. Wollen wir hoffen, dass sich da in nächster Zeit etwas tut!
Sascha Röber (der letzte ATARI-Händler) reiste dieses Mal nicht unter dem Label PPP/VERLAG RÄTZ, sondern präsentierte sich mit seinem PD-Mag-World Versand. Damit nicht genug. In nur drei Wochen hat Sascha es geschafft (ohne fremde Hilfe) ein Magazin auf Papier Fertigzustellen. Der Inhalt ist ein wenig PD-Mag-lastig, aber da wird sich mit Sicherheit noch einiges ändern. Als weiteres Highlight gab’s bei Sascha die zweite Auflage des Hint und Hunt Books. Natürlich gab es auch die gewohnte Palette Soft- und Hardware und nicht zu vergessen das Popcorn und die gebrannten Mandeln 🙂
Markus Römer (Kaisersoft) hatte leider nur seine Polenspiele mitgebracht und bot diese zum Verkauf an. Neues von Kaisersoft gab es nicht.
Aus dem Osten kam Bernd Dille mit einem Kollegen und bot eine Menge Soft- und Hardware zu günstigen Preisen an.
Dirk Dröger (ATARI Classic) hatte einen Stand mit einen XL auf dem Videos abliefen und eine Menge Restposten.
Mathy van Nisselroy zeigte einen XL mit einer 1 MB Speichererweiterung auf Basis von PC-Sims. An einem weiteren XL konnte man die Black Box bewundern.
Ein weiterer Holländer, Sijmen Schouten zeigte eine recht preiswerte Lösung zum Bau eines IDE-Interfaces. Dafür ist aber eine ruhige Hand und Löterfahrung erforderlich. Der Preis für die Bauteile, die benötigt werden, pendelt sich bei 20.-DM ein. Wirklich günstig!
Neben ihm zeigte Roland Scholz seinen IDE-BUS an dem eine Herkuleskarte die Ausgabe des ATARI in wunderschönen 80 Zeichen verarbeitete.
Wenn wir schon einmal bei den Niederländern sind dürfen natürlich auch die Gebrüder Schreures nicht fehlen. Sie hatten die POOLDISK II zum Schnäppchenpreis dabei und wie immer günstige Soft- und Hardware.
Thorsten Helbing (WASEO) präsentierte seine ATARI-XL-Musik-CDs und direkt daneben konnte man XL-Bilder auf einem PC sehen. Hat doch jemand einen Windows-Viewer für XL-Bilder geschrieben!

Soweit – so gut – aber wo sind denn die Regionalgruppen?

Von den Regionalgruppen waren die H.A.R. angereist und zeigten, leider immer noch, NUR einen Prototypen einer 512 KB Speichererweiterung auf Modul (Flash-Eprom). Nach Aussagen der H.A.R. hatten sie niemand, der die Module herstellt, da Christoph Kirsanowski keine Zeit mehr hat. Es hat sich im Laufe des Tages jemand mit genug elektronischem Know-how gefunden, der die Platinen und die weitere Fertigstellung übernimmt. Kaufen konnte man das neue Betriebssystem für die XF 551, wobei es hier Versionen für die 5 1/4 Zoll und für den 3 1/2 Zoll Umbau gab. Das QMEG+OS konnte man am Stand der H.A.R. natürlich auch erstehen.
Die R.A.F. aus dem Frankfurter Umland zeigten ihr SIO2PC und die dazugehörige Software. Zum Angebot gehörten ebenfalls das Voltmeter und die bewährten Schaltnetzteile. Die in Schreiersgrün von der R.A.F. geborene Idee „Best of Show“ wurde auf der JHV zum ersten und hoffentlich nicht zum letzten Mal abgehalten.
Die SWAT hatte keine Neuigkeiten außer das Disk Magazin von Andreas (XLE-Mag), dafür aber eine Menge Restposten zu Mitnahmepreisen. Bei dem von der SWAT veranstalteten Gewinnspiel (simple – da nur mit der Lightgun möglichst viele Treffer erschossen werden mußten) gab es zehn Preise zu gewinnen, die recht üppig ausfielen. Thorsten Butschke (FOUNDATION TWO/SWAT) hatte Premiere mit seinem nun dritten Spiel in kurzer Zeit. „Milligreen“ in bester Combat-Manier gewann den ersten Platz bei der Best of Show – Abteilung Spiele. Meinen HTML-Konverter musste ich aus Zeitgründen vorerst auf Eis legen, aber er kommt in einiger Zeit.
Vertreter der RELAG, WAF und der ARGS berichteten, das die große Zeit der Ruhe in ihre Regionalgruppen getreten sei und bis auf weiteres keine Besserung dieses Zustands zu erwarten ist.

Um 17:00 Uhr hatten die meisten schon abgebaut und die Sachen in den Autos verstaut. Gegen 18:00 Uhr trafen sich der harte Kern im Schnitzelhaus, um ein gemütliches Bier zu trinken, etwas zu Essen und vor allem – zum klönen über Gott und seine kleinen ATARI’s. Gegen 23:00 Uhr haben dann auch Walter und ich unsere Zelte abgebrochen und uns auf den Nachhauseweg gemacht, der mal wieder im strömenden Regen endete.


Traurig fand ich, dass nur etwa 80 User den Weg nach Herten gefunden haben und der Einladung des ABBUC gefolgt sind. Das muss besser werden Leute!
Leider konnte auch der Termin für „Schreiersgrün Millennium“ nicht bekannt gegeben werden, da Helmut Weidner nicht kam. Mittlerweile steht aber der Termin fest:
25. März 2000 in Schreiersgrün im alt bekanten Veranstaltungsgebäude.


Wollen wir hoffen, das die 15. JHV etwas mehr besucht ist!
Licht aus, Gute Nacht….
Highlander

Schreiersgrün Millennium

Wie Helmut Weidner kurz vor Redaktionsschluss mitteilte, findet die ATARI Messe Schreiersgrün 2000 am
25. März 2000 statt.
Die Anfahrt findet über Treuen statt. Von hier immer den Schildern „Schreiersgrün“ folgen. In den Ort geht es leicht bergauf. Ihr kommt dann an einer Gaststätte an (eine weitere gibt es nicht). Dort im Saal des oberen Stockwerkes solltet Ihr die anderen Bit Byter treffen.
Kontaktanschrift (für Tischreservierungen):

 

Helmut Weidner
D-08485 Lengenfeld
Hauptstr. 45
037606-2688

Die 1MB Speichererweiterung
(Das Update zum Upgrade)

Wie ihr euch vielleicht erinnern könnt, ist vor einiger Zeit eine Umfrage von mir im ABBUC Magazin erschienen. Für die, die nicht auf der JHV waren hier ein kurzes Update.

Meine Speichererweiterung läuft im Moment auf eine XEGS. Sie sollte aber auch auf andere XL und XE laufen. Ich hoffe in den nächsten Wochen einen 800XE und einen 800XL umzubauen.

Die Erweiterung ist voll 130XE kompatibel. Der separate ANTIC und CPU Zugriff auf das Zusatz RAM läuft einwandfrei. Software die vermeintlich nur auf einem Standard 130XE läuft, oder wo man andere Erweiterungen ausschalten muss, hat mit dieser Erweiterung null Probleme.

Auch verliert man nicht nach einiger Zeit die Daten im Zusatz RAM, wie bei so manch anderen Erweiterung.
Die RAMDisk ist als EINE RAMDisk nutzbar (8057 single density Sektoren nach Abzug von DUP.SYS und MEM.SAV). Wer will kann sie selbstverständlich über Software in kleinere Teile unterteilen. Es werden aber keine Schalter oder obskuren Adressen benutzt.
Was vielleicht auch noch zu erwähnen währe: Die Erweiterung auf meinen XEGS bringt nicht den Bildschirm zum Flimmern. Nicht beim Booten, nicht wenn man Turbo-BASIC von der RAMDisk startet und auch nicht wenn man von Turbo-BASIC eine Directory abfragt.
Weiterhin kann man immer noch über Software BASIC, das OS RAM, den Selbsttest und beim XEGS Missile Command ein- und ausschalten. Diese Sachen werden auch nicht ein- oder ausgeschaltet wenn auf das Zusatz RAM zugegriffen wird. OS RAM zum Beispiel braucht man für Turbo-BASIC und SpartaDOS. Außerdem, ohne Selbsttest läuft das Atari OS nicht.

Da so eine 130XE kompatible Speichererweiterung einiges an Lötarbeit erfordert, besonders dann wenn die Platine des Rechners nicht als 130XE ausgelegt ist und man dass nicht jedem zumuten kann, währe es nicht schlecht, wenn ich eine Platine herstellen lassen könnte.
Auf der Umfrage in Magazine #56 haben nur 5 Leute reagiert. Auf meine Umfrage im Internet reagiert noch eine weitere Person. Das sah also nicht gut aus. Zum Herstellen einer Platine braucht man, sofern ich jetzt weiß, nur um eine Druckvorlage (Maske) herzustellen schon DM 350 bis 400. Dann hat man immer noch keine Platine. Es kommen noch DM 5 bis 10 pro Platine dazu. Je mehr Platinen man herstellen lassen kann, desto billiger werden die einzelnen Platinen. (2 Platinen würden 400 + (2 x 10) gleich DM 420 kosten. Also DM 210 pro Platine. 20 Platinen würden 400 + (20 x 10) gleich DM 600 kosten. Oder DM 30 pro Stück.) Bei größeren Stückzahlen wird anders gerechnet.

Aber als ich im Internet ankündigte das der MEGA XEGS eine Tatsache ist, zeigten wieder einige Leute Interesse. Auch auf der JHV waren einige Personen sehr enthusiastisch. Da freut der Mensch sich.
Ein kleines Problem ist noch, dass beim XL die Komponenten anders platziert sind als im XE. Und im XEGS ist alles wieder ganz anders. Aus Kostengründen sollte es aber eine „universelle“ Platine werden.

Es gibt noch eine andere Möglichkeit, die ich einmal realisieren will:
Nicht dass es dafür schon Software gibt, aber wenn man eine zweite PIA (oder ein Latch) einbauen würde – die Hardware um dies zu kontrollieren ist in der Erweiterung schon drin – könnte man auch 4 oder 16 MB kontrollieren. Man sollte dann aber vielleicht keinen Kassettenrecorder benutzen um die RAMdisk zu füllen.
Tschüss,
Mathy van Nisselroy

Bei Interesse bitte Nachricht an:

Mathy G.F. van Nisselroy
NL- 6418 BL Heerlen
Caumerbord 61
nisse-ma@reze-1.rz.rwth-aachen.de

ABBUC – PD Sonderaktion

Auf der Jahreshauptversammlung 1999 hat sich Walter Lojek bereit erklärt,
die ABBBUC PD weiterzuführen. Mehr dazu im kommenden Magazin.
Wir haben uns außerdem entschlossen die PD-Preise drastisch zu
senken. Ab sofort kostet jede PD-Diskette nur noch 1,-DM Bei Bestellung
von 10 Disketten nur noch 7,50 DM inklusive einer Diskettenbox.
Hinzuzurechnen sind folgende Portokosten:
1 Diskettenseite oder 2 Diskettenseiten = 1,–DM plus 2,–DM Porto
3 Diskettenseiten oder 4 Diskettenseiten 2,–DM plus 3,–DM Porto
5 oder 6 Diskettenseiten = 3,–DM plus 3,–DM Porto
Sonderaktion: 10 PD Disketten 7,50DM plus 3,–DM Porto
mehr als 10 Disketten bitte 7,00 DM Portopauschale hinzurechnen


Allen Bit Bytern und
Ihren Angehörigen
wünscht der
Vorstand ein
gesegnetes
Weihnachtsfest

und natürlich einen
guten Rutsch, viel
Gesundheit und Glück für
das kommende Millennium !

 

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