ABBUC Magazin 039

Veröffentlichungen, auch auszugsweise nur mit schriftlicher Genehmigung

Impressum

Das ABBUC-Magazin erscheint 1/4 jährlich. Jeweils halbjährlich erscheint je ein Sondermagazin.
Eingesandte Artikel müssen frei von Rechten Dritter sein.
Mit der Zusendung gibt der Autor seine Zustimmung zur Veröffentlichung.

Copyright 1994 by ABBUC e.V. Atari Bit Byter User Club e. V. c/o Wolfgang Burger Wieschenbeck 45

D-45699 Herten

Tel./FAX +49 2366 39623

Veröffentlichungen, auch auszugsweise nur mit schriftlicher Genehmigung

Achtung!

Die ABBUC-Box hat ab sofort eine neue Telefonnummer

Die XEP-80 Teil 2

Als ich in meinem letzten Artikel über die XEP80 schrieb, daß ich mich über ein Echo freuen würde, meinte ich eigentlich, daß ich mich über ein ECHO freuen würde, und nicht über EIN Echo. Aber ich sollte nicht meckern, besser EIN Echo als KEIN Echo. Nun will ich aber langsam zum Thema kommen. Das Echo sagte zu mir: Erhard, nachdem ich Deinen Artikel über die XEP80 im letzten ABBUC-Magazin gelesen hatte, habe ich doch noch mal meine XEP80 aus der Schublade gekramt. Ich wollte sie schon immer unter Bobterm benutzen, aber weil der XEP80-Treiber von Bobterm die XEP80 nicht auf die deutsche Fernsehnorm umstellt, hatte ich immer ein flimmerndes und zu kleines Bild. Läßt sich daran nichts ändern?
Klar sag ich, man nimmt einfach den XIO-Befehl, der die XEP80 auf die 50 Hz Norm umstellt, schreibt das Ganze als kleines Maschinenprogramm und lädt das einfach als AUTORUN.SYS vor Bobterm – Moment, so geht s nicht. Dann ist ja noch gar kein XEP-Treiber installiert, und der X10-Befehl geht ins Leere. Na ja, ist doch klar, erst der XEPTreiber, dann der X10-Befehl und dann Bobterm
Mhmm, geht auch nicht. Der XEP-Treiber von Bobterm wird gar nicht in den normalen Editor eingeklinkt. Und außerdem wird der Treiber von BOBTEAM geladen und installiert. -Denkpause-. Der Treiber enthält das Unterprogramm zum Senden von Daten an die. XEP. Das ist der Teil aus dem letzten Magazin. Jetzt noch mal die Adressdaten des Treibers: Speicher von $4000-$422E und RUN $4001. Ah ja, das könnte gehen. An das Ende des Files vor die Run-Adresse, hänge ich ein kleines Programm an und leite die Run-Adresse darauf um. Das sieht so aus:
$422F SEC ;Ein Kommando wird über
tragen
$4230 LDA #$D7 ;Die Zahl $D7 schaltet die XEP auf 50 Hz im Textmodus
$4232 JSR $4145;An der Stelle beginnt die Senderoutine
$4235 JMP $4001;Treiber installieren
.ORG $02E0 ;RUN-Vektor
.WORD $422F :RUN-Adresse
Ausprobiert, klappt. Bei der ganzen Ausprobiererei habe ich natürlich den XEP-Treiber öfter durchforstet und dabei ist mir aufgefallen, daß die Senderoutine etwas früher beginnt, als im letzten Magazin gelistet. Nämlich so:
$4139 X_DAT CLC ;Daten werden gesendet
$413A .BYTE $24
$413B X_DAT SEC ;Ein Kommando wird übertragen
$413C PHP ;Carry-Status retten
$413D WAIT_3 LDX VCOUNT ;Nr. der gerade
erzeugten Bild
zeile durch 2 $4140 CPX #$6B ;Ist die größer oder
gleich 107?
$4142 BCS WAIT_3 ;Ja, dann warte PLP 4 4
1 ;Carry-Satus zurück-
$4
holen
$4145 ROR ;Byte solange rechts
drehen, daß Bit 0 $4146 ROR ;zuerst gesendet wird $4147 ROR
$4148 ROR $4149 ROR
… und hier gehts dann mit dem Teil aus Magazin 38 weiter.
Was sehen denn meine rechteckigen Augen da? Schon wieder eine Warteschleife? Was macht die denn? Also, grob geschätzt sollen während des Vertical Blank keine Daten uebertragen werden. Allerdings ist mir nicht klar, warum. Der VBI ist sowieso ausgeschaltet. Ob das WSYNC-Register in der Austastlücke nicht das erforderliche Timing liefert? Einfach ausprobieren. Gesagt, getan. Ab $413D schreibe ich einfach 7 mal den NOP-Befehl. Dann wird zwar immer noch etwas Zeit verschwendet, aber es wird nicht 50 mal in der Sekunde gewartet. Also, BOBTEAM mit dem geänderten Treiber geladen, und – sieh mal einer guck. Auf einmal geht BOBTEAM mit der XEP80 ja mit 9600 Baud! Nicht nur 4800. Das hab ich dann gleich mal noch ein wenig ausgetestet, aber nachteilige Folgen konnte ich keine feststellen. Also. gleich mal die ABBUC-Box angerufen und schau einer da, Funktionuckelt wunderhübsch. Mit stolzgeschwellter Brust rufe ich gleich den ABBUCianer an, der mir die Arbeit aufgehalst : -) hat. Ich hab s, ich hab s, verkünde ich, und nicht nur 50 Hz sondern auch 9600 Bd.
Vorgestern habe ich mich dann entschlossen, mit meinem neu erworbenem Wissen im ABBUC Magazin zu prahlen. Also habe ich Wolfgang gefragt, ob er an einer Fortsetzung über die XEP80 interessiert ist. Klar, sagt er, und so ist der Weg frei, den nach Informationen lechzenden ABBUCianern zu helfen. Und damit es nicht bei diesem mageren Häppchen bleibt, kommt hier noch eine kleine Zugabe. Ab $40E0 stehn 13 Folgende Byte, mit denen die XEP initialisiert wird:
$D9 Cursor dauernd an
$D4 Benutze ATASCII Zeichensatz
$DE Helle Buchstaben auf dunklem Untergrund
$D3 Burst Modus, es werden keine Cursor-Daten zurückgesandt
$60 Linker Rand 0 Low Nibble
$70 Linker Rand 0 Hi Nibble
$AF Rechter Rand Low Nibble 15 + 4*16 Hi Nibble = 79
$B4 Rechter Rand Hi Nibble
$00 horizontale Cursorposition = 0
$80 vertikale Cursorposition = 0
$D0 List-Flag löschen
$C5 Fülle RAM mit SPACE-Zeichen
$DC Setze das Scroll-Fenster auf die X-Cursorposition

Da mir die ganze Herumraterei zu ätzend wurde, habe ich heute MAL EBEN den Treiber reassembliert, so daß ich jetzt ein relativ lesbares Programm vorliegen habe, womit ich weiterarbeiten kann. Das bedeutet, das ich weitere Artikel über die XEP80 auf euch loslassen werde. Da ich noch weitere Informationen über die XEP80 ausgraben konnte, kann ich jetzt schon eines sagen: die 19200 Bc1 sind in greifbare Nähe gerückt und mit meiner Vermutung mit dem 6551 510-Baustein aus dem 1. Artikel bin ich auf einer heißen Spur (glaub ich jedenfalls).

Deeper Dungeons

Der Videocontroller in der XEP80 ist ein Chip mit 48 Pins. Er hat einen 16 Bit breiten Datenbus auf der Videoseite. Ruf diese Weise könnten 2 AAMs gleichzeitig ausgelesen werden, nämlich eines, das den darzustellenden Text enthält und ein zweites, das Textattribute enthält. Es sind 8 Attribute möglich:
Invers: Ein Buchstabe mit dem Umgebenden Feld wird invertiert dargestellt.
Halb hell : Der Buchstabe wird mit verminderter Helligkeit dargestellt. Wahlweise sind eine stärkere Helligkeit und sogar Farbe möglich.
Blinkend: an, aus, an, aus….
Doppelt H: Text
in doppelter Höhe, wobei hier intern einige Voraussetzungen zu beachten sind
Doppelt W: Text in doppelter Breite. Die Folgende Speicherzelle kann dann nicht dargestellt werden, also eine Lücke lassen]
Unterstr. : Ein offenbar Frei definierbares Zeichen wird hinzugemischt. Dies kann das erwünschte Unterstreichen sein, oder auch ein Strich darüber oder ein Strich quer durch oder was man will.
Versteckt : Der Text wird gar nicht dargestellt. Bei einem doppelt hohem Zeichen muß dieses Attribut ebenfalls gesetzt werden, damit der Controller weiß, daß es sich um die untere Hälfte des Zeichens hon delt.
Grafik: Da es sich hierbei um ein Attribut handelt, können Text und Blockgrafik belle big gemischt werden. Außer doppelter Höhe können alle anderen Attribute
gleichzeitig benutzt werden.
Dann ist da noch der Grafikmodus der XEP80. Genau wie das Thema Blockgrafik ist er Umfangreich und wird an dieser Stelle nicht weiter besprochen.

Der Light“ Pen

Der Controller ermöglicht den Anschluß eines Light Pen. Per Interrupt werden die horizontale und die vertikale Position in 2 Registern abgespeichert. HPEN ist 7 Bit breit (128 Positionen) und VPEN ist 5 Bit breit (32 Positionen). Da dies keine besonders hohe Auflösung ist, kann man ein Zeichnen mit dem Light Pen wohl vergessen.

Die serielle Schnittstelle

Hierbei handelt ‚es sich um einen LABT (Universal Asynchronus Receiver Transmitter), der in seiner Funktion und den Registern dem bekannte 6551 so sehr gleicht, daß ich davon ausgehe, daß es sich genau darum handelt. Lediglich der Baudratengenerator ist ein wenig anders aufgebaut. Mit einem 4 Bit Vorteiler wird der Systemtakt (12 MHz bei der XEP80) in einer von 16 Stufen heruntergeteilt. Die Abstufung ist 3.4, 4, 4.5 … 11. Der eigentliche Baudrotenteiler ist 11 Bit breit und wird am Ausgang noch mal fest durch 16 geteilt. Bei der XEP 80 ist eine Baudrate von 15625 eingestellt. Die Rechnung könnte aber auch so aussehen:,

12 MHz: 6.5 ca.1.8432 MHz

1,8432 MHZ :6 = 307200 Hz
1,8432 MHZ :3 = 614400 Hz
307200 Hz :16 = 19.200 Khz
307200 Hz :16 = 38.400 Khz

Die 19.200 KHz liegen innerhalb der Herstellerspezifikationen. In wie weit die 38.400 KHz funktionieren, bliebe zu probieren. Da andererseits die Teiler aber noch lange nicht ausgenutzt werden (es geht ja noch viel schneller), warum also nicht.
So, das wär s für dieses Mal.

Grüße, Euer Floppydoc.

Cracking the code Teil 2

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

(Zum besseren Verständnis – wenigstens hoffe ich das – werde ich auch in diesem Kapitel ein paar zusätzliche Erläuterungen einfügen.) Seit dem ersten Artikel hattet Ihr genug Zeit, mit Binär-und Hex-Zahlen zu üben. Dieser zweite Teil befaßt sich mit dem Aufbau des Computers und führt weiter zu einleitenden Maschinensprache-Anweisungen.

Basis / Grundlagen

Der Microprozessor (im folgenden CPU genannt) im Atari (8-Bit) Computer ist der bekannte und außerordentlich gut dokumentierte 6502-Chip. Der 6502 besitzt 16 Adreß- (oder Adressier-) und acht Datenleitungen, um mit dem Rest des Computers Kontakt aufzunehmen bzw. zu halten.

Im ersten Teil sahen wir eine Diagrammdarstellung des Binärcodes. Dargestellt wurden bis zu acht Kolumnen (Spalten) bzw. bis zu acht Bits (Nicht zu verwechseln mit einem beliebten – auch in Bayern bekannten -Getränk! A.K.). Wenn wir uns nun zu diesen acht weitere acht Spalten dazudenken, erhalten wir die Anzahl der zur Verfügung stehenden Adreßleitungen. So stünden als in den verschiedenen Spalten (von rechts nach links) folgende Werte: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768. (Erinnern wir uns: Binärcode heißt, wir finden in jeder dieser Spalten entweder eine Null oder eine Eins. Jede Spalte hat also entweder den Wert „Null x Spaltenwert = Null“ oder „Einmal Spaltenwerf‘ also je nach Spalte „2“, „64“ oder gar „32768“ A.K.). Enthielte jede dieser 16 Spalten eine 1, so hätte die Gesamtzahl den Wert all dieser 16 Spalten zusammen, also 65535. Enthielte jede dieser 16 Spalten eine Null, so hätte die Gesamtzahl den Wert Null. Das heißt es können insgesamt 65536 Adressen angesprochen werden (Wer’s nicht ganz versteht, darf auch sagen „angeschrieben werden“; dann weiß er auch, warum von Adressen gesprochen wird, A.K.).

Dies ist nun der geeignete Moment, ein bekannte Abkürzung einzuführen: „K“ für Kilobyte, womit man die Menge von (exakt!) 1024 Byte bezeichnet. Teilt man 65536 durch 1024, erhält man als ‚Ergebnis 64, was man als „64K“ schreibt. Jede dieser 65536 Adressen kann man sich als eine Schachtel vorstellen, in der man ein Stück Datenmaterial speichern kann (ablegen, aufheben, lagern …). Eine solche Box bezeichnet man als „Byte“. Jedes Byte wiederum ist unterteilt in acht Bits (wobei jedes dieser acht Bits eine Stelle in unserer Binärzahl darstellt).

Wie wir wissen, kann man mit acht Bits eine Zahl von Null bis 255 darstellen, was zusammen 256 Möglichkeiten ergibt. Also haben die Zellen des Computerspeichers (Memory) eine Nummer von Null bis 255, die via Datenleitungen übertragen werden.

64K Arbeitsspeicher, das hört sich viel an! Leider aber steht uns nicht all dieser Speicher für Programme und Arbeitsdaten zur Verfügung. (Zur Erläuterung: Das Programm, das ich jetzt benutze ist der Compyshop-Editor, die Daten sind der Text den Ihr ge- rade lest. A.K.). Startet man den Atari ohne BASIC ( = mit OPTION), so bleiben 48K des RAM-Speichers für unsere Arbeit frei (RAM = Random Access Memory d.h. Speicher, der dem Benutzer zur freien Verfügung steht; random = beliebig; access = Zugang; A.K.). Die restlichen 16K sind dem ROM zugewiesen (ROM = Read Only Memo- ry, einer Art Speicher, dem man als Benutzer nur Daten entnehmen kann, nicht aber reinschreiben kann. Wenn der Vergleich gestattet ist ist RAM eine Art Gepäckaufbewahrung, während ROM einem Koffer- und Taschen-Geschäft entspricht. A.K.). In diese 16K wird das Operationssystem gelagert. Von da aus verwaltet werden auch die üblichen Eingabe-/Ausgabe-Geräte: Tastatur, Bildschirm und Casseitenrecorder. (Das Operationssystem, kurz „OS“, enthält alle für den Computer wichtigen Grundanweisungen, daß er beispielsweise weiß, daß er Daten bekommt wenn Ihr in die Tasten haut daß er diese ggf. auf dem Bildschirm darstellen soll, daß er weiß, was eine Floppy ist und was man damit machen kann‘ usw. Vergleichen wir unseren Kleinen mit anderen Menschen, so bedeutet „OS“ all das, was man uns in unseren ersten 10 bis 20 Jahren so beigebracht hat angefangen von Links und Rechts übers Fußballspielen bis zum Au- tofahren. Man könnte gewissermaßen von eingebauter Erziehung sprechen. So gesehen ist unser Kleiner – verglichen mit anderen Menschen – sehr gut erzogen. Verglichen mit einer sog. DOSe ist er sogar perfekt denn die muß ihr OS bei jedem Booten neu laden, Unser XL/XE holt sich all dieses Grundwissen mal so nebenbei aus dem OS- ROM-Baustein. A.K.).

Der 6502 Prozessor

Der 6502-Prozessor enthält mehrere unterschiedliche Register. Alle
diese Register sind acht Bit groß, außer dem Programm-Zähler (program counter), häufig als „PC“ abgekürzt; er ist 16 Bit groß. Die anderen Register sind der „Accumulator“, kurz „A“, die zwei Index- Register „X“ und „Y“, das Prozessor-Flag-Register „P“, und der Stackpointer „S“ (Als Stack bezeichnet man einen Lagerhaufen, beim Kartenspielen kurz als „Haufen“ bezeichnet; Pointer heißt Zeiger; A.K.). Das „PC“-Register ist 16 Bits groß, da es dieMö,glichkeit haben muß, auf jede einzelne Stelle des 64K-Speichers zu deuten bzw. zuzugreifen. Auf dasjenige Byte, auf das so gedeutet wird, wird zugegriffen; aus ihm wird Information entnommen oder dorthin wird Information geschrieben.

Das meistbenutzte Register ist der Accumulator. Dort werden die meisten Berechnungen und Werte bereitgehalten, Die beiden Indexregister sind Vielzweckregister. Sie können für sich allein oder im Zusammenhang mit dem Accumulator genutzt werden. Das „P“-Register enthält die Information über den gegenwärtigen (=aktuellen) Status (Zustand) des Prozessors. Das „S“-Register deutet zur aktuellen Position im Stock.

Keine Angst, es handelt sich hier nur um eine Schnelleinführung in die Register des 6502. Das Ganze wird später noch deutlich vertieft.

Das Konzept des paging

Entsprechend der „Architektur“ oder dem internen .Layout (auf deutsch: der inneren Struktur, Anordnung) des 6502 ist der Arbeitsspeicher in sog. Pages (auf deutsch: Seiten; vergleiche: Ein Buch, das auf Endlospapier gedruckt wäre, wäre nicht sehr handlich, insbesondere, wenn man eine bestimmte Stelle suchen muß. Folglich unterteilt und bindet man es in Seiten. A.K.). Jede solche Page umfaßt 256 Bytes. Teilt man die 65536 Bytes des XL, so erhält man 256 Pages. Warum hat man den Speicher so aufgeteilt? Die Ursache liegt darin, daß der 6502 ein 8-Bit-Prozessor ist, und der Adreß- Bus 16-Bit „breit“ ist. (Wir erinnern uns:

Es stehen 16 Adreßleitungen zur Verfügung! Es können also gleichzeitig Daten in bis 255 zu 16 Stellen 256 großen Binärzahlen transportiert werden. Und weil etwas transportiert wird, spricht man vom Bus. .Es können nun auf dem (oder mit dem) Bus zwei 8 Bit- Wörter gleichzeitig transportiert werden. Unter „Wort‘ versteht man hier eine 8 Bit große Zahl, kurz: ein Byte.
Die höheren acht Bits deuten nun auf eine der 256 Pages (Seiten), die 65535 niedrigeren acht Bits auf das (gewünschte) Byte in dieser Page. (Vergl. Figur 1)

Diese Einteilung des Arbeitsspeichers in Seiten (Pages) ist nicht unbedingt von grundsätzlicher Bedeutung. Denn der gesamte Arbeitsspeicher erscheint dem Programmierer wie ein einziges großes Feld von Speicheradressen (locations). Dennoch ist es – programmiert man in Maschinensprache – aus zwei Gründen wichtig, daß man sich über diese Einteilung im Klaren ist. Der weniger wichtige: man verliert jedesmal, wenn man die Grenze zu einer anderen Seite überschreitet, etwas Zeit. Der andere Grund hängt mit den Grenzen mancher Adressier-Modi (Modus = Art; Modi = Arten), wobei eben manche Adressier-Modi nur eine Seite gleichzeitig ansprechen können. Mehr darüber später.


Anweisungen in Maschinensprache
Madtne Coie gnstructions

MC Programme werden in den Arbeitsspeicher als eine Folge binärer Zahlen geschrieben. Dabei startet der 6502 das Programm mit dem ersten Byte, auf das das Programm-Zähler- Register (Program Counter, oder kurz: PC) Dieses teilt dem 6502 mit, welcher Befehl eingebunden werden muß. Man bezeichnet dies als das Operation-Code- oder kurz Opt Code-Byte. Diesem Opt Code folgen entweder gar kein, eines oder zwei weitere Bytes, je nach dem Typ der Anweisung, die auszuführen ist. Sie werden vom 6502 automatisch gelesen, wobei das PC-Register jedesmal eins weiterzahlt, Man bezeichnet diese Bytes häufig als Operanden-Bytes. Sie dienen entweder dazu, auf eine Speicheradresse zu deuten, wo der Op-Code seine Aufgabe(n) ausführen soll, oder der Operand ist selbst die Datenmenge, mit der der OpCode etwas machen soll. In anderen Worten, im einen Fall holt sich der Op-Code seine Arbeitsdaten von der Speicherstelle, auf die das Operanden-Byte deutet, im anderen Fall benötigt das Op-Code-Byte die Daten des Operanden-Bytes selbst als Arbeitsdaten. Anders als in BASIC – wo man als Anwender per ERROR-Meldung über fehlerhafte Eingaben informiert wird – dreht der 6502 regelrecht durch, wenn er Op-Code-Daten bekommt, die nicht mit den Anweisungen übereinstimmen, die ihm vorliegen. Der 6502 „hängt sich auf‘ oder „crasht, und die einzige Möglichkeit weiterzuarbeiten ist: Computer ausschalten und neu anfangen. Kaltstart! (Der (Hardware Stich) Wie bereits erwähnt besitzt der 6502 einen Stuck Pointer (S). Das S-Register ist acht Bit breit und kann daher jeden beliebigen Punkt innerhalb einer Seite (Page) ansprechen (adressieren). Im 6502 adressiert das 5-Register die Side One). Die Seite Null (Page Zero) ist reserviert, da sie für manche der 6502-Anweisungen eine wichtige Rolle spielt. Deshalb ist der Stack den man an und für sich an jeder beliebigen Stelle hätte unterbringen können, auf der nächstmöglichen Seite, also Seite 1 untergebracht worden. Diesen Stack bezeichnet man als den Hardware Stack, da er direkt vom 6502 unterstützt wird. Es gibt auch andere Stocks, sie werden aber nur softwaremäßig unterstützt. BASIC erstellt sich z.B. einen „Runtime-Stack“ um dort die Return-Adressen für Subroutinen abzulegen.

Der Stack wird benutzt, um Daten, auf die man einerseits ganz schnell Zugriff haben muß, die aber andererseits nur vorübergehend benötigt werden, zwischenzulagern. Diese müßte man sonst auf ein anderes internes Register legen, wovon nur eine begrenzte Menge zur Verfügung steht. Sozusagen eine Frage der Praktikabilität! (der original- englische Ausdruck ist: … for high speed temporary storage …) Die internen Register A, X und Y setzt man ein für den schnellen Umgang mit Zahlen. Müßten diese Zahlen aber mal gerade eben zwischengespeichert werden, weil man (der 6502!) eben zwischendurch etwas anderes tun muß, z.B. eine andere Routine durchzuführen hat, dann ist der Stack ein idealer Platz dafür. (Um das Ganze noch anschaulicher zu machen: Wenn Wolfgang mir diesen Text zum Übersetzen schickt dann sitze ich gewöhnlich gerade an einer ganz anderen Arbeit sei es beruflich, halbberuflich oder privat. Ich lege also alles schnellstens beiseite, um Wolfgangs Bitte(n) zu erfüllen. Es entsteht also auf meinem Schreibtisch ein Haufen = Stack. Sobald ich mit Wolfgangs bzw. der Clubarbeit fertig bin, wende ich mich wieder der beiseitegelegten Arbeit zu und mache da weiter, wo ich aufgehört habe. Das ist die Theorie des Stocks. Die Praxis sieht anders aus: Wenn ich Glück habe, wird die Clubarbeit „am Stück“ fertig. Aber bevor ich zu meinem Ur-Stack zurückkehren kann, ergibt sich meistens die „Gelegenheit‘ für einen zweiten Stack, dann einen dritten, vierten … – jeweils „on top“, d.h. obendrauf. Was ist so ein XL doch für eine geniale, ordentliche Maschine! A.K.)

Die einzige andere Möglichkeit, diese Zahlen zwischenzuspeichern,sie im Arbeitsspeicher (RAM) abzulegen. Das st nur unwesentlich langsamer, ABER man (der 6502!) muß sich jedesmal merken, auf welchem Speicherplatz die Zahlen abgelegt sind, Im Falle des Stocks geschieht dies aufgrund der erwähnten Hardwareunterstützung automatisch.

Tja, warum nützt man dann den Stock nicht für alle Speichervorgänge? Dafür gibt es zwei Gründe: Zum einen ist die Aufnahme-fähi
gkeit des Stocks begrenzt. Dort kann höchstens eine Page (Seite), also maximal 256 Bytes gespeichert werden. Zum anderen ist der Stuck so strukturiert, daß alle Daten „sequentiell“ gelagert werden, das bedeutet alle Daten werden in derselben Reihenfolge abgerufen, in der sie dort abgelagert wurden. (Man stelle sich das vor wie eine Gepäckaufbewahrung, in der Hochbetrieb herrscht aber nur ein Mann für alle Arbeiten zur Verfügung steht. Er nimmt also Taschen und Koffer an und stellt sie – mal eben so, also nur in der Reihenfolge der Annahme – neben sich ab. Wenn er nun wieder welche rausgeben soll, kommt er nur noch an die vordersten ran. Die müssen also zuerst wieder raus, bevor er an die hinteren Gepäckstücke kommt. Zur Erinnerung an mein voriges Beispiel: Nun könnt Ihr Euch vorstellen, wie es auf meinem Schreibtisch manchmal aussieht! A.K.) Diese Form eines Stucks bezeichnet man in der Fachsprache als einen LIFO-Stack. Das bedeutet soviel wie: Last-infirst-out oder auf deutsch: Die letzten Eingaben werden als erste abgearbeitet. (Biblisch ausgedrückt Die Letzten werden die Ersten sein. – Oder ganz schlicht: Immer feste druff!)

Eine besondere Art, wie man den Stock nutzt, ist der Einsatz von Subroutinen. Wird eine Subroutine aufgerufen, d.h, in Gang gesetzt so wird der momentane Inhalt des PC-Registers auf dem Stock abgelegt. Anschließend wird die Adresse der Subroutine dazugeladen und diese ausgeführt. Nachdem dieser komplette Programmschritt abgeschlossen ist – also nach Durchführung der Subroutine – wird vom Stock der Inhalt des PC-Registers zurückgeladen zusammen mit den Adressdaten, an welcher Stelle das Hauptprogramm verlassen wurde.

Anzumerken ist folgendes: Werden in einer Subroutine Zahlen auf dem Stock abgelegt, müssen diese unbedingt mit derselben Subroutine wieder heruntergenommen werden, bevor man ins Hauptprogramm zurückkehren kann. An- Page dernfalls würde die Return Adresse nicht stimmen, was wiederum ein unerwünschtes Er gebnis bewirken würde. Sind Subroutinen ineinander verschachtelt, d.h eine Subroutine würde
dazu benutzt eine weitere (untergeordnete) aufzurufen, (vergl. Figur 2), dann sollte darauf geachtet werden, daß nicht mehr als 256 Bytes oder maximal 128 Subroutinen auf dem Stack abgelagert werden. Hält man sich nicht daran, so wird dort information überschrieben, da sich die Informationen auf dem Stack dann überlappen/ überschreiben würden. In der Praxis können jedoch gewöhnlich noch nicht einmal 128 Subroutinen aufgerufen werden, weil dort meist bereits Informationen gespeichert sind.

Möglichkeiten der Adressierung

Es gibt sechs Hauptarten, wie man adressieren kann (Adressing Modes): Um den unmittelbaren bzw. direkten Modus (Immediate Mode) (wie schon erwähnt) handelt es sich, wenn es sich beim eingegebenen Operand um die benötigte Information selbst handelt (vergl. Figur 3), d.h. die benötigten Daten werden nicht errechnet oder dergl., sondern direkt eingegeben.

Der absolute Modus (Absolute Mode) ist der andere bereits erwähnte Fall, wobei der Operand auf die Stelle deutet an der die benötigten Daten stehen (vergl. Figur 4). Achtung: Dieser Modus gilt für den gesamten Speicherbereich einschließlich der Page 0. Das Kurz-Adressieren bzw. Page-O-Adressieren ist dasselbe wie das absolute Adressieren, außer daß nur ein Byte benötigt wird, um auf eine beliebige Stelle innerhalb der Page 0 zu deuten (vergl. Figur 5).

Zur Erinnerung: Das absolute Adressieren funktioniert auch mit dieser Page (Page 0), es ist lediglich etwas langsamer und benötigt ein zweites Byte. Index-Adressieren bedient sich als Ausgangsbasis einer absoluten Adresse (absolute base address) und addiert dazu entweder die Werte/den Inhalt des X-oder des Y-Registers, um somit eine endgültige „kalkulierte“ (=errechnete) Adresse zu ermitteln (vergl. Figur 6). Der indirekte Modus bedient sich zweier Angaben innerhalb der Page 0, um (damit) auf eine andere Speicheradresse zu deuten (vergl. Figur 7). Der letzte Typ ist der sog. Implied Mode, der keine Daten braucht und nur festen, internen Aufgaben dient. Es handelt sich bei all diesen nur um die grundsätzlichen Möglichkeiten (basic modes), die in der Praxis in allen möglichen, unterschiedlichen Weisen kombiniert werden können. Über sie folgt innerhalb dieses Kurses noch mehr. Diese Adressier-Techniken gelten für alle Instruktionen, von ein paar Ausnahmen abgesehen (Wußte ich doch, daß da ein Haken dran ist! A.K.) Wichtig zu verstehen ist daß alle diese unterschiedlichen Adressier-Modes nur verschiedene Wege sind, an Daten ranzukommen außer im Falle des „Implied Mode“. Fast alle diese Instruktionen, die man benutzen kann, beeinflussen das Flog-Register des Prozessors (P). Un terschiedliche Instruktionen beeinflussen unterschiedliche Register, wo jedes Bit entweder richtig (1) ist oder falsch (0).

Was eine bstimmte Instruktion tat sächlich bewirkt, hängt letzten Endes vom Status des jeweiligen Bits im Flag- Register ab.  Ein weiters Beispiel:

Binär Dezimal
10011000 152
(+) 10001110 (+) 142
( ) 1 0 01 0 01 1 0 ( -) 294
Rechnet man diese Aufgabe in gleicher Weise nach, erhält man als Ergebnis eine neunstellige Binärzahl, da sich in der achtn Stelle als Ergebnis drei,also binär 11 ergibt. Weil nun aber der 6502 nur mit 8 Bit rechnet, bräuchte man beim Addieren von 8-Bit-Zahlen bis zu 9 Bit. Das Maximum wäre also

Binär Dezimal
11111111 255
(+) 11111111 (+) 255
(-) 111111110 (-) 510

(2) Gekennzeichnete Zahlen (Signed Numbers) Zahlen kann eine Polarität zugeordnet werden, entweder positiv oder negativ. (In meiner Schulzeit,nannte man das „Guthaben“ und „Schulden“ – 0 mei, warn das noch Zeiten! A.K.) Dies macht man, indem man in das entscheidende Bit (Bit 7) eine Null schreibt, falls es einen positiven Wert darstellen soll bzw. eine 1 für einen negativen.

Hier ein paar Beispiele:
00001011 = 11 (dezimal)
Das am weitesten links stehende Bit (msb) ist eine Null, was bedeutet„ daß die gesamte Zahl einen positiven Wert hat, also +11.

01111111 = 127 (dezimal)
Wieder hat die Zahl einen positiven Wert; mit dieser Methode ist 127 jedoch der höchste Wert den wir darstellen können.

10001011 = -11 (dezimal)
Die Eins von Bit 7 gibt an, daß es sich um eine negative Zahl handelt, daher Minus Elf (-11),

11111111 = -127 (dezimal)
Wieder handelt es sich um die größte negative Zahl, die wir auf diese Weise darstellen können. Das Addieren zweier (so) gekennzeichneter Zahlen kann zu Komplikationen führen:
Binär Dezimal
01010111 + 87
(+) 01110000 (+) + 112
(-) 11000111 (-) – 71
(und das ist falsch! )

Indem wir eine „1“ vom Bit 6 ins Bit 7 übertragen haben, wurde das Vorzeichen unabsichtlich in ein Minus geändert, so daß wir ein falsches Ergebnis erhalten haben. Addieren wir diese Zahlen mit Hilfe des 6502, so hat dieser „keine Ahnung“, daß es sich in Wirklichkeit um „markierte Vorzeichen-Zahlen‘ handelt. Seitens des 6502 findet folglich keinerlei Korrektur statt. Es bleibt also Aufgabe des Programmierers, derartige Ergebnisse zu berücksichtigen und zu korrigieren. Allerdings gibt der 6502 einen Hinweis auf die Änderung des Vorzeichens, indem er eine „1“ in das Overflow Flag (V) de
s Registers (P) setzt. Man kann daher alle nötigen Korrekturen vornehmen, indem man vor einer Berechnung das Overflow Flog (V) „leer macht‘ (deur) und nach der Berechnung dort wieder nachschaut, ob dorthin eine „1“ übertragen worden ist. Diese „Signed Mode“ Methode ist nicht allzu zuverlässig; denn es gibt viele Fälle, in denen das Ergebnis unkorrekt ist selbst wenn kein Übertragen damit verbunden ist.:

Binär Dezimal
00010011 + 19
(+) 10011011 (+) 27
(-) 10101110 – 49 (falsch)

Selbstverständlich sollte 19 minus 27 nicht minus 46, sondern minus 8 ergeben. Es interessant, festzustellen, daß das Ergebnis immrhin das richtige Vorzeichen hat (minus), und plus 19 und plus 27 ergibt 46, daher das falsche Ergebnis.

(3) Kombination aus beiden (Two’s Complement)

Wegen der hier aufgezeigten Schwierigkeiten bedarf es eines besseren Systems, Zahlen mit Vorzeichen darzustellen. Im Falle von ‚Two’s Complemenr werden positive Zahlen immer noch durch eine Null in Bit 7 dargestellt, die restlichen sieben Stellen geben den Wert der Zahl bis zu einer Größe von 127 an. Um das Vorzeichen umzukehren, also von Minus zu Plus und umgekehrt, werden folgende Funktionen auf die Zahl angewandt: erst werden alle Bits ausgetauscht (invertiert), eine 0 wird also eine 1, und eine 1 wird eine 0. Danach wird dem jeweiligen Ergebnis 00000001 hinzuaddiert.

Wollen wir also -27 darstellen, so schreiben wir erst mal den Binärcode für plus 27, dann tauschen wir jedes Bit gegen sein Gegenstück aus und addieren schließlich eins um die ‚Two’s Complimentär-Darstellung von -27 zu erhalten.

Binär Dezimal
00011011 +27 11100100
(jedes Bit vertauscht/invertiert) (+)00000001 (dazu 1 addiert)
11100101 -27

Geht man ebenso mit einer negativen Zahl dieser „Two’s Complimenr-Darstellung vor, erhält man folgerichtig einen positiven Wert.

Binär Dezimal
11100101 -27 00011010
(jedes Bit vertauscht/invertiert) (+) 00000001 (dazu 1 addiert)
00011011 +27

Um +19 und -27 zu addieren, gehen wir wie folgt vor: Wir suchen die ‚Two’s Complement‘- Zahl für 27, um daraus die -27 zu formen:
Binär Dezimal
00011011 +27 11100100
(vertauscht/invertiert)
(+) 00000001 (dazu 1 addiert)
11100101 -27

Nun addieren wir die beiden „Signed“ Zahlen in der „Two’s Complemenr-Form
Binär Dezimal
00010011 +19
(+) 11100101 (+) -27
11111000 -8

Die Eins im Bit 7 des Ergebnisses teilt uns mit, daß das komplette Ergebnis negativ und eine ‚Two’s Complement“-Darstellung von minus acht ist. Nur um einmal zu zeigen, daß es sich tatsächlich um (-8) handelt, können wir nochmals eine ‚Two’s ComplemenrParallelzahl erstellen; wir dürfen aber nicht übersehen, daß sich dabei das Vorzeichen wieder (zu positiv) ändert:

Binär Dezimal
11111000 -8
00000111
(vertauscht/invertiert)
(+) 00000001 (dazu 1 addiert)
00001000 +8

Wir haben nun also ein brauchbares System, mit dem wir zuverlässi-ge Ergebnisse erzielen können. Trotz allem müssen wir immer vorsichtig sein, wenn sich ein Übertrag über die acht Stellen (Bit 0 bis Bit7) bzw. in die achte Stelle (Bit 7) ergeben sollte, so daß Bit 7 unbeabsichtigt verändert wird. Diese Änderung muß dann erst wieder rückgängig gemacht werden, damit man die korrekte Zahl zur Verfügung hat.

(4) Der dezimale Modus
Eine 8 Bit-Binärzahl auf dem Bildschirm darzustellen ist im Hex-Format recht einfach, da man die Binärzahl leicht in zwei 4 Bit-Blöcke unterteilen kann, für die man dann jeweils ein Hex-Zeichen einsetzen kann. Diese aber nun auf dem Schirm in Dezimalzahlen darzustellen ist vergleichsweise schwierig. Aus diesem Grund har man dem 6502 einen „Dezimal-Modus“ verpaßt, Darin benutzt man zwei 4 Bit-Blöcke um zwei Dezimal-Zeichen darzustellen. Es werden nur die Codes von 0 bis 9 verwendet, 10 – 15 bleiben unbenutzt. Jedes Byte enthält zwei Dezimalzeichen, so daß man mit einem kompletten Byte alle Zahlen von 00 bis 99 darstellen kann. (Zum Vergleich: sowohl mit der reinen Binär-Darstellung als auch mit der Hex-Darstellung kann man die Zahlen von 00 bis 127 darstellen, falls man mit negativen und positiven Zahlen arbeitet; bei nur positiven Zahlen geht’s sogar bis 255! A.K.) Diese Form des Umgangs mit Dezimalzahlen bezeichnet man als den „Binary Code Decimal (BCD)“, auf deutsch etwa: Binärer Dezimalcode. Es folgt eine Liste der 4 BitBinär-Codes für die Zahlen von 0 bis 9:

Dezimal BCD
0 0000
1 0001
2 0010
3 0011
4 0100
5 0101
6 0110
7 0111
8 1000
9 1001

Probieren wir jetzt mal mit Hilfe dieser Information ein paar 8 Bit-Darstellungen von zweistelligen Dezimalzahlen:

In diesem Dezimalmodus berücksichtigt der 6502 beim Addieren von Zahlen automatisch einen evtl. Übertrag von Bit 4 nach Bit 5 (wenn sich also im rechten 4 Bit-Block ein Wert größer als 9 ergibt was ja im Binär-Modus noch längst keinen Übertrag bewirken würde; denn da ist noch Platz bis 15. A.K.). Dieser Modus ist dann aktiviert, wenn die (D) Flag im (P) Register gesetzt ist. Hiermit sind die wesentlichen Grundlagen für ein genaues Verständnis der Maschinensprache gegeben. Beim nächsten Mal werden wir uns einigermaßen gründlich mit Assembler beschäftigen.

Arbeiten mit dem Atari-Bus
2. Teil

4. RS 232-Modul

Diesmal wenden wir uns einem anderen Baustein zu. Er trägt die Bezeichnung 6551 und heißt „ACTA“. Er ist ebenfalls ein Peripheriebaustein Für die 65-er CPU und wird zur seriellen Datenübertragung eingesetzt. Er hat wie die PIA vier Register und übernimmt alle nötigen Funktionen für die Datenübertragung.

Bauteile:
1* ACIA 6551(A) + Quarz 1.8432 1* MAX 232 (oder Ersatztyp) 4* Elko 22 MikroF

Bauplanbeschreibung und Bedienung:
X Dig Schaltung lehnt sich teilweise an das RS232 Interface des Atari-Magazins an (Atari Magazin 12/88). Dort sind auch weitere Informationen über, Funktion und Programmierung des Bausteins zu finden. Geändert wurde die Steueradresse. Außerdem wurde auf drei HardwarehandshakeLeitungen (DIR, DSR, DCD) verzichtet. Das alles vereinfacht die Schaltung ungemein und ermöglicht den Einbau in ein Modulgehäuse für den Modulschacht. X Die IRQ-Leitung läßt sich am Modulschacht leider nicht abfragen. Aber der Baustein hat ein Register, in dem ein ausgelöster Interupt softwaremäßig angezeigt wird. So kann man über einen externen lnterupt. (VBI, Poker) dieses Register abfragen und so auf den Hardewareinterupt verzichten. X Nullmodembetrieb: Die Standard-Leitungen für eine serielle Datenübertragung sind
(=“Nullmodemkobel“) sin TxD (Datensendung)<br /> RxD (Datenempfang)<br /> Masse/Ground.<br /> Alle Informationen werden über diese Leitungen ausgetauscht.<br /> DATA Ein-/Ausgabe<br /> STATUS IRQ, Fehler, DSR, DCD<br /> COMMAND Parität, Echo, IRQ, RTS<br /> DATA Baud, Stopbit, Wortlänge</p> <p>Es ist nur ein sogenanntes „Softwarehandshake“ möglich. Dies geschieht norm
alerweise über die Befehle
* „XON“ (17, CTRL-Q)
= Datenempfang möglich
* „XOFF“ (19, CTRL-S)
= kein Datenempfang möglich‘

Achtung: Man muß beim ARGR-RS-Modul zusätzlich die Leitungen RTS und CTS- miteinander verbinden. Beim PC oder anderen Rechnern muß u.U. auch noch DSR, DCD miteinander verbunden werden.
X Standard für den Atari XL/XE. ist der Befehlssatz des 850er Interfaces. Eine billige Alternative ist das Datatari-Kabel, das ‚ein einfaches Nullmodemkabel darstellt und für diesen Einsatz kompatibel zum 850er ist. Der Handler für das ARGS-Interface ist (bisher nur) teilweise kompatibel zum 850er.
X Man muß beim Datenaustausch immer bedenken, daß der Atari für Return den Wert 155 hat und nicht 13 (=> Wandlung III)

Software für das RS-232-Modul

Was man dazu braucht ist schlicht ein R:-Handler. Nun hat aber das 850-er Interface einen Standard vorgegeben, an den man sich halten sollte. Deswegen muß der Handler nicht nur mit dem KIR-Baustein umgehen können, sondern muß auch die Befehle des 850-er Interfaces verstehen. Das macht die Sache leider etwas komplizierter, aber nicht unmöglich.
Nun zur Software:

-> ARGSRS2.** R:-Handler mit hoher Kompatibilität zum 850-er Interface. Neue Version, Stand Juli 1994. Steht ab $2000 im Speicher und legt MEMLO hoch.

-> ARGSRSM.** (M=Mini) Auf das Nötigste reduzierter R:-Handler. Nur Veränderung der Baud-Rate. Festeinstellung von Wortlänge (8 Bit), Parität (keine) und Stopbits (1). Nur Hardwarehandshake und keine Zeichenwandlung von 155 in 13. Reicht aber zB. für BobTerm völlig. Steht auch ab $2000 im Speicher.

-> ARGSRSRE.COM (RE=RElocabel) Relocierbarer R:- Handler (ARGSRSM s.o.), der sich ab MEMLOW in den Speicher legt und dann MEMLOW entsprechend erhöht.

Welche Programme laufen nun mit diesen Handlern? Auf jeden Fall alle, die das 850-er Interface voraussetzen und die Handler „sauber“ abfragen und nicht irgendwie direkt einspringen, dh. Buffer direkt auslesen.

Es funktioniezen nicht :
-> KEAMIT
-> ANSITERM (hat wohl gor keinen echten R:- Hondler)

Roland Bühler

Konvertierungen Teil 2

Bildkonvertierung vom AMIGA/ST(E) auf den XL

Die Bilder habe ich zunächst vom AMIGA auf den STE übertragen. Das Format der Bilder auf dem AMIGA ist Fast ausschließlich IFF, von ein paar GIF Bildern mal abgesehen. Auf dem STE habe ich das Programm GEMVIEW 2.13 zur Konvertierung benutzt, um Bilder von meist 32 auf 16 Farben umzurechnen, da ich die Bilder in erster Linie für meinen STE wollte. Die XL Bilder sind also eigentlich von STE 16-Farb Bildern konvertiert (aber nicht alle, manche wurden mit Prismpoint von 32 bzw 64 auf 4 Farben umgerechnet I).

Nun, die auf 16 Farben berechneten Bilder habe ich im GIF-Format gespeichert (gut komprimiert) und dann ins Malprogramm PAISMPAINT geladen. Wichtig war, daß ich hier die mittlere ST-Auflösung (640*200 Punkte bei 4 Farben) verwendete, wobei ein geladenes Gif-Bild so durch das Malprogramm von 16 Farben auf 4 Graustufen umgerechnet wurde. Außerdem halbiere ich das Bild noch (aus einem 320 * 200 16 Forb-Bild wird so ein 160*200 4-Forb-Bild).

Das könnte man zwar auch mit GEMVIEW machen, aber leider kann mon da nur mir im Aufbau unbekannte Formate (wie GIF) speichern.

Weiterhin war es für mich wichtig, daß ich in der mittleren Auflösung bis zu vier 160*200 4-Forb Bilder unterbringen konnte (in einem 640 * 200 Bild vier 160*200 Bilder). Meist belasse ich es aber bei zwei Bildern. Dann wurde das Bild als DEGAS PI2 Bild obgespeichert und auf den XL via Terminolprogramm & Turbolink übertragen.

Der Vorteil ist klar: Ich kann statt einem Bild, das auf dem ST bei 320*200 Punkte mit 16 Farben 32000 Bytes frißt 1- 4 Bilder in 32000 Bytes und zwar schon auf 4 Farben runtergerechnet übertragen. Das einzige, was der XL noch zu tun hat, ist das Bild vom ST-Format, wo es über Bitplones aufgebaut wird auf das XL Format rüberzufechnen.

Ach ja, AMIGA 32 Farben Bilder direkt auf den XL zu bringen wäre Blödsinn, diese brauchen nämlich 40000 Bytes (320*200 5 Bitplanes). Ich habe auch ein paar interlace-HAM Bilder sowie AMIGA 16-Farb Hires Pics konvertiert die 96000 Bytes bzw. 128000 Bytes Bildspeicher brauchen (dabei seien Overscan – Bilder nicht zu vergessen … ein 384*512 HAM Bild oder 704*512 Bilder H ires/Interlaced …)

HAM steht übrigens für Hold And Modify, dies ist der AMIGA 4096-Forb-Modus. Hier hängt die Farbe eines Punktes jedoch von den Nachbarpunkten ab . Im Interlace-Modus verdoppelt der AMIGA die Zeilenanzahl (200->400), allerdings verringert sich die Bildwiederholungsfrequenz, das Bild flimmert ziemlich schlimm (ähnlich XL-256 Forb Bildern, die durch Pageflipding erzeugt werden, ich meine das Flimmern) Dies nur zur Erläuterung, ich kenne mich mit dem AMIGA jedoch nicht besonders gut aus Wandlung ST-Bitplanes XL Antic Mode 14 (=Graphics 15)

Ein ST-640*200 Bild ist so aufgebaut:
plane 0 plane 1 plane 0 plane 1
word 0 word 1 word 2 word 3 16 Pixels 16 Pixels

Die Farbe von Pixel 0 Wird dadurch bestimmt, wie Bit 15 in word 0 und Bit 15 in word 1 gesetzt sind (beide 0, 0/1, 1/0, 1/1), Pixel 1 durch Bit 14 in word 0 und 1 usw. Der ST-Bildschirm beginnt normal bei $f8000. Bei $f8000 liegt word 0, bei $f8002 word 1. Diese beiden Planes bestimmen die Farben der ersten 16 Pixels. Bei $f8004 und $f8006 liegen dann die nächsten beiden words, die die nächsten 16 Pixels bestimmen. Eine Zeile braucht so 160 Bytes (640 – Pixel, 4 Bit pro Pixel -> 640/4=160), das Bild 32000 (160*200). So, mein Programm auf dem XL liest nun, je nach Position des Bildes (ich sagte, ich kann bis zu 4
160*200 Bilder in einem PI2 Bild speichern) jeweils die ersten 40 Bytes, Byte 40-79, Byte 80-119 oder Byte 120 bis 159 aus. Will ich also das erste 160*200 Bild haben so lese ich 200 mal Bytes 0-39, die restlichen 120 Bytes pro Zeile werden ignoriert. Für das 2.Bild lese ich halt 200 mal die Bytes 40-79 usw.

Mittels einer Tabelle berechnet es aus jeweils 4 Bits eines words aus Plane 0 und 4 Bits aus Plane 1 ein zu setzendes Byte auf dem XL. Ein Graphics 15 Byte enthält ja schließlich 4 Farben. Dies geht solange, bis Zeile 200 erreicht ist. Beispielsweise konvertiere ich jetzt das erste Bild, das auf dem ST 200 Zeilen in den Bytes 0-39 belegt.. Mein Programm liest nun 2 Words von diesen 40 Bytes aus, wobei das erste zu Plane 0, das zweite zu Plane 2 gehört. Es werden nun jeweils 4 Bit aus Plane 0 und Plane 1 gelesen; wonach man zwei 4-Bit Werte hat, von denen einer mal 16 plus den anderen genommen wird : wert 1+ 16*Luert2

So erhält man einen Index. Aus der vorberechneten Bytetabelle wird jetzt ein Byte entnommen, das die konvertierte Bitfolge im XL-Format enthält. Das ganze geschieht vier mal (da ein word 16 Bit braucht). Die oberen vier Bits Plane 0/1 ergeben ein Byte. Die mittleren acht Bit Plane 0/1 ergeben zwei Bytes. Die unteren vier Bit Plane 0/1 ergeben ein Byte. insgesamt werden vier Bytes (=2 words) vom Bitplane-Format ins XL-Format konvertiert, wo die Bits innerhalb eines Bytes die Farbe eines Pixels bestimmen. Das mag vielleicht für „Nicht-STKenner“ unverständlich sein, aber extrem wichtig ist es nun auch wieder nicht ! Auch Bilder breiter als 160 Pixel können so konvertiert werden, ebenfalls geht’s vertikal noch besser (nur leider kann ein Degos PI2-Bild nur 200 Zeilen lang sein, AMIGA Overscan Bilder haben ober meist 256 Zeilen. Mon kann zwar auch auf dem ST overscannen, doch dos ist nun wirklich ein anderes Thema. Mein Programm lädt übrigens immer nur einen Teil
des Bildes, da 32000 Bytes (mit den Farbdaten, die ich allerdings überspringe 32034 Bytes) für Turbo Basic zu viel sind.

IFF Bilder (ganz kurz)

IFF ist eigentlich ein speziell Für den AMIGA gebräuchliches Format. Nun , es hat aber seinen Vorteile , wenn sich dort ein einziges Format als Standard herausgestellt hat. Auf dem XL wäre es im prinzip auch nicht schlecht, ein Dateiformat wie IFF, das variable Bildgrößen bearbeiten kann zu entwickeln. Vielleicht ein speziell auf den XL -Schirm angepasstes IFF. Nun aber zum AMIGA IFF : Der IFF Header braucht jetzt mal nicht zu interessieren. Wichtig ist , daß ein IFF Bild (gehen wir mal von einem ungepackten aus , obwohl der IFF-Komprimieralgorithmus sehr simpel ist) ,ploneweise abgespeichert ist. Nehmen wir an, es ist 160 Pixel breit und hat 2 Planes (=4 Farben ) , also wie manche der Overscon Pics. Dann folgt noch dem Header (noch die BODY-Kennung + 4 Bytes) der Datenblock. Hier sind nun 20 Bytes von Plane 1 gespeichert , dann 20 Bytes von Plane 2 , dann wieder 20 von Plane 1 „usw.
Hätten wir 4 Planes (-21’4=16 Farben), so würden bei gleicher Auflösung je 20 Bytes der Planes 1,2,3,4, 1,2,3,4,1,…. folgen.
Für den AMIGA, ist dies sehr praktisch, einfach und schnell programmierbar. Auf dem XL muß aber immer ein Graphics 15 Pixel gesetzt werden, wie die entsprechenden Bits in Plane 1 und 2 stehen (00,01,10,11). Dies geschieht am bestem über eine Tabelle Ach habe das schon bei der Wandlung von PI2 ATARI ST Bildern beschrieben. Falls am genauen Aufbau des IFF Formats Interesse besteht bzw. über dessen Komprimierverfahren (was übrigens ein sehr einfaches, aber zum Teil wirkungsvolles ALE-Verfahren ist) könnte ich dies auch noch erläutern]
Wichtig ist: Words treten bei diesem Format nicht wie beim XL üblich im Lo/Hi Format auf , sondern 68000er gerecht Hi/Lo. Allerdings arbeitet das Format bei den Längenangaben mit Longwords , also 32 Bit Werten, natürlich im 68000er Format (also so wie man den Wert im Hexcode schreiben würde und nicht irgendwie vertauscht I).
Wie gesagt , ein variables, auflösungsunabhängiges Format wäre auf dem XL gar nicht so übel, gerade wegen der vielen möglichen Auflösungen , von denen zumindest Graphics 7 , 8 , 9 (10,11) und 15 wichtig sind , aber es wäre dann schon wieder ein neuer Standard. Da es für den XL ja auch schon andere IFF – bzw. GIF-Konverter gibt , es hat durchaus seine Vorteile über Rechnergrenzen portable Dateiformate zu benutzen

Anmerkungen:

• Es ist vielleicht sinnvoller, den ST auch dieses übernehmen zu lassen, anstatt das XL-Programm mal in Assembler zu coden. Natürlich muß ich dann mehr Bilder übertragen, jedoch sind diese direkt vom XL benutzbar.
• Auf dem AMIGA sind die Bitplanes nicht wie beim ST ineinander verschränkt, ein AMIGA 640*200 4-Farb Bild hätte also 16000 Bytes. Plane 0 gefolgt von 16000 Bytes. Plane 1 anstatt 1 word plane 0, 1 word plane 1, 1 word plane 0, … wie beim ST.
• Wer also vom AMIGA direkt konvertieren möchte, kann das auch tun. Deluxe Point ist auch sehr gut dafür geeignet, Bilder auf weniger Farben umzurechnen. Zum Ubertragen kann mon (unkomprimiertes) IFF-Format nehmen. Wer sich damit besser auskennet, soll’s mal probieren.
• Vom Aufbau von MS-DOS Bildschirmen bei vaiGrafik habe ich leider keine Ahnung. Ich glaube hier läuft das nicht mit Bitplanes … Außerdem, in GIF-, TIFF usw. Formaten, könnte ich solche Bilder auch mit dem ST konvertieren…
• AMIGA ARM Bilder werden entweder auf dem STE auf 16 Graustufen reduziert oder gedithered (Punktroster—>mehr Farben). Deswegen sind auch solche Bilder auf dem XL noch gut (z.B. manche Fantasy-Bilder, die Autos …).
• Bei manchen Bildern klappt es mit der Graustufenkonvertierung leider nicht. Da hat man nur undefinierbaren Mülll Manchmal ist auch die Auflösung des XL’s doch zu klein. Da hat mon leider Pech gehabt.
• Hier steht vielleicht zuviel 68000er ST und Amigo Kram drin. Aber das mit den Bitplanes ist nunmal wichtig 1 .
• Man hätte auch kürzer ausführen können. Ich wollte jedoch nicht einfach Begriffe wie Hm im Raum stehen lossen.
• Auch HiRes Bilder sehen meist noch gut aus, obwohl sie, wenn sie auf dem AMIGA 640*400 Pixels bei 16 Farbe hotten, auf dem XL bei vier Graustufen nur 1/8 so groß sind.
• Da der AMIGA eine ziemlich flexible Hardware bezüglich der Grafikdarstellung hat (so wie auch unser XL), gibt es dort sehr viele verschiedene Bildgrößen. Deswegen wird auch das Auflösung und Bilgrößen unabhängige IFF-Format benutzt.
• -Auf dem XL haben die Bilder keine Farbinfos, da es sich nur um Graustufen handelt (bei allen 1)
• Die Bilder brauchen 200 Zeilen, also sollte man in der Dlist 8 zusätzliche Zeilen installieren. Bei manchen Bildern sind auch nicht alle 200 Zeilen genutzt. Sie brauchen jedenfalls 64 Sektoren (65 Sektoren manchmal, wobei hier 202 Zeilen versehentlich gespeichert wurden).
• Wenn jemand für seine Demos solche Bilder braucht, kann er mich kontakten.
• Mein Dank gilt auch noch denen, die diese Bilder gemalt bzw. gescannt oder anders digitalisiert haben.
• Die Programme findet ihr auf der Magazindiskette .

So, das wars. Hasta la Vista ….

Thimo Gräf
56462 Höhn-Schönberg Tel. 02661/8137

Wenn der Strom swingt

So ein Schaltnetzteil ist doch manchmal ein recht kompliziertes Gebilde. Wie ich so mitbekam, gibt es doch noch, so hin und wieder, Probleme mit diesen Dingern.
Durch die Taktfrequenz bedingt. (je nach Typ und Ausführung von 20 …..50 kHz), mit der hier transformiert wird, kann es unter sehr ungünstigem Umständen vorkommen, daß sich Oberwellen dieser Frequenz auf die Ausgangsspannung bzw. Ausgangsleitungen der +/- 5 Volt Seite überlagern.

Wie in meinem Artikel in ABBUC-Magazin # 38 beschrieben, sollte mon ja möglichst kurze Leitungen mit möglichst großen Querschnitten verlegen. Aus den Grundlagen der Elektrotechnik weiß man ja, es gibt elektrische und magnetische Felder, die überall nur so herumschwirren. Ruch Leitungen, die vom Strom durchflossen werden, bilden bzw. beinhalten Kapazitäten und Induktivitäten, die sich je nach Gelegenheit, mehr oder weniger stark auswirken und da ihre Spielchen betreiben. Viel mehr möchte ich hier jedoch nicht ausführen, denn dann müßte ich einen. kompletten Grundlehrgang in Elektro-Technik bzw. Elektronik hier abdrucken.

Tatsache ist, daß so manche Gleichspannung führende Leitung ins Schwingen kommen kann. In der Regel passiert das äußerst selten, aber wie gesagt. Zur Abhilfe von derartigen Effekten genügt an und für sich, ein Verdrillen der Speise- bzw. Gleichspannungsleitungen, womit sich die vielleicht vorhandenen Wechselfelder gegenseitig den Garaus machen.

Sollte dies nicht den gewünschten Erfolg bringen, experimentiere man mit einem Kondensator am Ende der Gleichspannungsleitung. Das heißt: direkt am Anschluß des zu versorgenden Verbrauchers (ATARI 800XL, HDI, Floppy usw.). Werte zwischen 0,001pf und 0,01pF haben sich zum Abblocken bzw. zum Kurzschließen der Frequenzen auf der Gleichspannungsleitung als praktikabel erwiesen.

Wie gesagt, treten solche Erscheinuungen äußerst selten auf, jedoch wie heißt es so schön: „SAG NIEMALS NIET“

Werner Hellmuth

Frankfurter Hardware

Hallo,
in diesem
Artikel möchte ich auf einige Beiträge des letzten ABBUC-Magazins eingehen und olle, die die JHV in Herten verpaßt haben auf die von mir ent wickelten bzw. in der Entwicklung befindlichen Geräte hinweisen.

Zunächst zum Magazin #38. Ich war ziemlich überrascht, daß ein Brief an Joost von mir veröffentlicht wurde, denn dafür war er eigentlich nicht gedachtl Daher möge man mir verzeihen wenn ich zuviel vom Stand des ABBUC und zu wenig von den anderen Ausstellern geschrieben habe. Der Bericht war eigentlich dafür gedacht den Vorstand des ABBUC über die Geschehnisse an seinem Messestand zu informieren.

Der Artikel über die Messe in Halle hat mir sehr gut gefallen. Die Bilder zeigten auch weniger erfahrenen Mitgliedern, wie denn nun eigentlich der eine oder andere aussieht. – Prima Rolf!!! Im Artikel noch einmal Schaltnetzteile wurde gut beschrieben, welche Fehler man beim Einsatz eines Schaltnetzteiles machen kann. Leider ist das beschriebene Netzteil am Erscheinungstermin des Magazins schon längst ausverkauft gewesen. Im übrigen muß ich darauf hinweisen, daß das beschriebene Netzteil lediglich mehrere Rechner betreiben kann. Der Anschluß an eine Floppy ist wegen der viel zu niedrigen Amperezahl der 12 Volt Ausgangsspannung nicht möglich] Das heißt, wenn man einen Rechner und zwei Floppies besitzt, braucht man neben dem beschriebenen Schaltnetzteil der Fa. Conrad weiterhin die zwei Trafos für die Floppies und erhält sich somit die Backöfen innerhalb und außerhalb der Floppies.

Da ich auf der Messe immer wieder angesprochen wurde wieso man anstatt dem von mir vorgestellten ‚Schaltnetzteil für ATARI 8-bit‘ denn nicht einfach ein billigeres PC-Schaltnetzteil einbauen kann, möchte hierzu noch einmal kurz darauf eingehen:

* Das PC-Schaltnetzteil braucht noch einmal ein extra Gehäuse. (ca. 60 DM)
Es müssen extra Adopterkobel hergestellt wer den (ca. 20 DM)
Ein nervender Lüfter, den es bei meiner Entwick lung nicht gibt!
Im Falle eines Kurzschlusses sind die angeschlossenen Geräte in höchster Gefahr. Die PC-Schaltnetzteile können ca. 10-20 Ampere bei 5V im Kurzschlußfall liefern und alle Leiterbahnen auf der (Rechner-) Platine verschmorenl

Es fehlen die zwei 230V-Steckdosen zum Anschluß von z.B. Monitor und Drucker.
Leider mußte ich selber schon feststellen, wie schnell ein XE beim Betrieb mit einem PC Schaltnetzteil stirbt‘

Auf der Messe habe ich von einigen Besuchern gehört, daß sie das, von mir entwickelte, Schaltnetzteil für ATARI 8-bit schon nachgebaut hoben. Daher möchte ich diese hiermit auffordern doch einmal einen unabhängigen Testbericht über das Schaltnetzteil zu verfassen und hier im ABBUC-Magazin zu veröffentl ichen!!!

So, nun ober für all diejenigen, die die von mir angebotenen Geräte noch nicht kennen eine kurze Beschreibung:

Schaltnetzteil Für ATARI 8-bit

Den Bauplan zum Scholtnetzteil gibt es beim ABBUC Bauplanservice unter der Nummer 8514. Es ist eine 18-seitige Anleitung, die neben allen notwendigen Zeichnungen, Bildern und dem Bauplan auch eine kurze Erklärung der Hintergründe beinhaltet die zur Entwicklung des SNT geführt haben. Im folgenden kurz die wichtigsten Punkte:
* Eine Stromversorgung für alle Geräte der Anlage (Die alten Orginalnetzteile werden nicht mehr benötigt)
* kurzschlußfeste Ausgänge
* Genügend Reserven zum Anschluß zusätzlicher Geräte
* Entspricht den VDE ßestimmungungen
* Keine heißen Orinolnetzteile mehr
* Keine heißen ATARI-Floppies mehr
* Ein Powerschalter für alle angeschlossenen Geräte
* Zwei 230V Steckdosen für den Anschluß von weiteren Geräten
* Nur noch eine Wandsteckdose für die komplette Computeranlage nötig
* Platzersparnis gegenüber den Orignialnetzteilen
* Weniger Kabelwirrwarr
Das Gerät kann auch als Fertiggerät über mich bezogen werden. Die genauen Kosten hängen von Deinen Wünschen ab. Wenn Du also Interesse an einem Fertiggerät hast dann schicke mir einen Brief in dem Du mir die Anzahl und Art der Geräte, die Du an das SNT anschließen willst, mitteilst. Natürlich können dabei auch Deine Sonderwünsche berücksichtigt werden. Ich schicke Dir dann unverbindlich ein Angebot mit dem genauen Preis für Deine ganz spezielle Version zu.

Automatisches 2-Rechnerinterface

Das automatische 2-Rechnerinterface dient dazu gleichzeitig zwei Rechner über die 510-Schnittstelle an ein oder mehrere Peripheriegeräte anzuschließen. Mit Peripheriegeräten sind alle Geräte gemeint, die von ATARI zum Anschluß an den 510-Port angeboten werden. Eine Ausnahme sind nur die Datenrecorder, sie müssen direkt an die Rechner angeschlossen werden.
Das Rechnerinterface unterstützt Übertragungsraten von bis zu 200000 Baud. Somit werden alle bekannten Diskspeeder voll unterstützt.

Das Gerät befindet sich in einem nur 101 x60x26mm großen schwarzen Kunststoffgehäuse. Es verfügt über zwei Eingangsbuchsen und ein Ausgangskabel mit Stecker. Die zwei Rechner werden mit Hilfe von ’normalen‘ SIO-Leitungen mit den Eingangsbuchsen des Rechnerinterface verbunden. Die Ausgangsleitung wird wie üblich in das Peripheriegerät gesteckt.
Peripheriegeräte können sowohl zwischen dem jeweiligen Rechner und dem Rechnerinterface, oder dahinter angeschlossen werden. Geräte zwischen Rechner und Interface können nur von dem direkt angeschlossenen Rechner angesprochen werden. Das Peripheriegerät arbeitet ‚lokal‘.
Alle Geräte die hinter dem Rechnerinterface angeschlossen sind, können ‚global‘ benutzt werden. D.h. sie sind durch beide Rechner ansprechbar. Vergleiche dazu auch das Bild.
Die Spannungsversorgung des Rechnerinterface erfolgt über die SIO-Schnittstelle eines der beiden angeschlossenen Rechner. Der Stromverbrauch beträgt ca. 5m8, so daß selbst Rechner mit schwachen Netzteilen ohne Probleme angeschlossen werden können.
Der Betriebszustand des 2-Rechnerinterface wird ständig über drei Leuchtdioden angezeigt. Da das automatische 2-Rechnerinterface keinen Scholter mehr besitzt muß auch nicht mehr darauf geachtet werden, wann mit welchen Rechner auf den 510- Port zugegriffen wird. Sollten einmal beide Rechner absolut zeitgleich zugreifen wollen, so erhält einer von beiden die Meldung Error 138 – Gerät antwortet nicht.
Gegenüber der einfachen Verkopplung der SIOKabel mit Dioden, wie es einige User vorgeschlagen haben, läßt das automatische 2-Rechnerinterface nur einen Rechner zu einem Zeitpunkt auf die globalen Floppies zugreifen. Damit ist ein BUS-Chrash ausgeschlossen. Außerdem sind durch die Pufferung der BUS-Signale auch größere Leitungslängen möglich.
Das Automatische 2-Rechnerinterface gibt bei mir als Komplettbausatz Für 70DM oder als Fertiggerät für 100 DM zu kaufen.

Digitalvoltmeter V3.2

Ein weiteres Projekt, welches sich kurz vor seiner Fertigstellung befindet, ist ein Meßgerät, das sowohl an den XL, wie auch an den PC angeschlossen werden kann!! Das neue Digitalvoltmeter wird voraussichtlich Anfang nächsten Jahres Fertiggestellt werden.

> Es verfügt über 8 Messeingänge mit gemeinsamem Massepotential oder 4 Differentialeingängen. Auch Kombinationen ‚dazwischen sind möglich.
> Im Unterschied zu komerziell erhältlichen Messgeräten erfolgen bis zu 1000 Messungen pro. Sekunde. Somit lassen sich auch Scholtvorgänge oder Signale niedriger Frequenz verfolgen.
> Der Anschluß am 8-bit ATARI erfolgt am Joystickport 2. Der erste Joysickport bleibt Frei zum Anschluß von Relais die vom Digitalvoltmeter gesteuert werden können.
> Wird das Digitalvoltmeter mit einem PC betrieben, so wird lediglich ein spezielles Adapterkabel zwischen das Digitalvoltmeter und einem Centronicsanschluß (Drucker) des PCs angesc
hlossen, und die mitgelieferte Software installiert. Hier stehen 8 Ausgänge zur Ansteuerung von Relais bereit.
> Der Eingangsspannungsbereich beträgt +/- 20Volt bei 12bit Auflösung (10mV).
> Ein hoher Eingangswiderstand von 1M belastet die Quellen‘ nur sehr gering.

Selbstverständlich gehört zum Digitalvoltmeter V3.2 ein Softwarepaket, das unterschiedlichste Anwendungsbereiche abdeckt. So können die Messwerte digital oder, wie beim Oszilloskop, als Graph angezeigt werden. Für Schalt-und Regelaufgaben können Minimas und Makimos angegeben, werden bei deren Er reichen die Relais aktiviert werden.

Der Preis für die XL-Version wird voraussichtlich bei 100-120DM für das Fertiggerät liegen. Das Adapterkabel incl. Software Für den PC wird ca. 60 DM kosten. Wenn Du direkt noch dem Erscheinen des Digital-voltmeter informiert werden möchtest dann schicke mir einen an Dich adressierten und frankierten Rückumschlag zu. Zum Schluß möchte ich alle die im Besitz des überarbeiteten Bauplanes 8514 von ABBUC-Bouplanservice sind auf einen Fehler im Bauplan hinweisen. Die Fehler sind in allen Bauplänen die auf der JHV’94 verteilt wurden bereits behoben!! Auf Seite 9 sind die falschen DIN-Stecker und Buchsen spezifiziert. Im folgenden sind die richtigen beschrieben.

Sollten noch irgendwelche Fragen zu den Geräten offen sein, so setzte Dich bitte mit mir in Verbindung. Bestelllungen oder Fragen an folgende Adresse:

Thomas Grasel
Dillenburger Str. .61
60439 Frankfurt / Main
Tel.: 069 /577516

Atari XL/XE Stereo-Sound

In einem Mega-Magazin, ich glaube es war Ausgabe 1/93, wurde eine Stereo-Erweiterung für den 8-Bit ATARI vorgestellt.

Der Bauvorschlag stammt von Ch. Steinman, und ich denke es ist in jedermann Interesse wenn dieser Standard eine möglichst große Verbreitung findet, denn nur so hat es Sinn und Zweck, Software dafür zu Schreiben. Also entschloß ich mich, diesen Artikel für’s ABBUC-Mag zu schreiben.

1. Funktionsprinzip
Der Sound unserer Compy’s wird (mal abgesehen vom selten genutzten SOUND-Befehl) über die Speicherstellen $D200 – $D2OF gesteuert. Aus welchem Grund auch immer; mit den Speicherstellen $D210 – $D21F erreicht man das gleiche Ergebnis. Diese Doppelbelegung bildet die Grundlage Für die Stereo-Erweiterung. Die Adressleitung wird aufge trennt und ein zweiter Pokey (das IC macht u.a. den Ton im XL) wird eingebaut. Dadurch erhält der Rechner vier zusätzliche Tonkanäle. Ein Pokey macht den linken, der andere den rechten Soundausgang. Programmiert wird der Sound wie gehabt,nur mit einem Unterschied:

$D200 – $D2OF alter Pokey, links $D210 – $D21F neuer Pokey, rechts

Der Stereo-XL bleibt ganz kompatibel zu einem normalen Gerät, mit einer Ausnahme: unsaubere Soundprogrammierung. Bisher einziges Beispiel: Der Chaos Music Composer (CMC, von den Jungs aus Polen), eine debugte Version gibt es bei mir gegen eine Kopie des Original-Covers (ich veschicke natürlich keine Raubkopien). Im Mega-Magazine 2/93 wird im übrigen sehr genau die Programmierung für Stereo beschrieben (auch os modifizieren vorhandener Software).

2. Software
Der PD-Bibliothek geht eine Stereo-Version des ISoundMonitor Prof.‘ zu, (Mit freundlicher Genehmigung von Thorsten Karwoth, klar). Eine Stereo-Version vom ‚Chaos-Music-Monitor‘ ist Fertig (Auch dieses Programm. nur gegen Kopie des Original-Covers) The Römer (Andreas Witte) macht evtl. einen Speziellen Soundeditor, der mit 8 frei benutzbaren Kanälen und Digi-Drums (wer’s mag; ich auf jeden Fall) aufwarten wird. Die Firma a. n. g. aus Holland hat ein ähnliches Projekt in Arbeit. Naja, je mehr Interesse, desto mehr Software!

3. Einbau
Im Mega-Magazin #1/93 ist der Einbau ausführlich, allerdings in Englisch beschrieben. Ich baue aber auch jedem der will, die Stereo-Erweiterung gern und gegen Erstattung der Unkosten in seinen Rechner ein.
Der Einbau ist einfach (hab ich schon x-mal gemacht): einen Sockel Für den neuen Pokey ‚huckepack‘ auf den alten löten, einen Widerstand raus…
Ich hab die Übung. Es ist nichts für Laien, die ’nen Lötkolben nur aus dem Katalog kennen.
Die Kosten liegen etwa so:
incl. Sockel & Kabel,
1 Pokey, 741s14
2 Kondensatoren 150pF,‘
Widerstand 1k
Cinch/DIN-Buchse: 25,–DM
(wenn ihr noch einen Pokey habt 15,-)

Den Einbau mach ich umsonst, wenn Ihr das Porto für den Rechner zahlt. Ein Pokey kostet 17,50DM (a.n.g, incl.Portol) Falls noch jemand Fragen zum Thema STEREO hat, zu guter letzt noch meine Adresse:
Beetle of U.N.O Stefan Niestegge Faerberstrasse 41
49477 Bevergern Telefon 05459/7095 Telefax 05459/4731

Ach ja, wer schon Software Für Stereo Ataris gemacht hat möchte sich bitte auch bei mir melden!! Mit 8-Bit Grüßen… Euer Beetle

Soundeditoren

Für unseren XL/XE gibt es mittlerweile einige Musikprogramme. Der eine schwört auf jenes, der andere zieht jenes vor. Und jemand, der sich bisher nur wenig oder auch gar nicht mit Sound beschäftigt hat, der sich nun einen Soundeditor besorgen will weiß möglicherweise nicht, welches er nehmen soll. Hier greift nun der SOUND-EDITOR VERGLEICH. Folgende Punkte könnt Ihr hier lesen:
– Was gibt’s ?
– Allgemeines
– Vor- und Nachteile
– Fazit

Was gibt’s ?
Die bekanntesten Musikprogramme sind:
The Soundmachine <tsm>
Black Magic Composer <bmc>
Benji(Pegasus)Sound-Monitor <bsm>
Sound-Monitor Professional <smp>
Chaos Music Composer <cmc>
Masic <mas>

Allgemeines
mas ist eine Programmiersprache, die sich (Fast) ausschließlich um den Sound im XL kümmert.
mas ist strukturiert wie z.B. Pascal oder auch Quick.
tsm ist das einzige Programm, das die Noten grafisch darstellt.

Die anderen Programme haben einen Programmteil zum Instrumente editieren, einen um Tracks (oder auch Patterns) komponieren und letztendlich eine Tabelle in der die Track-Reihenfolge Festgelegt wird. Die Sounds aus allen Programmen lassen sich auch in eigene Produktionen einbauen.

Vor- und Nachteile

tsm
Dieses Teil ist schon ziemlich alt, und die Sounds die. mon damit machen kann, klingen heute nicht mehr besonders professionell. Gesteuert wird tsm teils über Tastatur und teils über den Joystick, das ist etwas langsam und mühselig. Die Instrumente lassen sich nicht so aufwendig gestalten wie das heute so üblich ist. Dafür muß man hier noch einmal die grafische Notendarstellung hervorheben.

bmc
Der bmc ist voll mausgesteuert, ST- und auch Amiga-(würg) Mäuse werden Flott unterstützt. Wer keine Maus hat, kann auch einen Joystick nehmen oder sein Keyboard. Des weiteren ist der bmc mit Fenstertechnik aufgebaut. Die Instrumente klingen gut, 16-Bit und Filtersound ist möglich. Als Bonbon bietet der bmc die Möglichkeit Digisound einzubinden! Mit einer trockenen Base-drum und anderen fetzigen Drums kriegen die bmc-Sounds ihren eigenen, professionellen Charakter.

bsm
Die mit dem bsm (der ja als „PegasusSoundMonitor“ die letzte ABBUC Jahresgabe war) erstellten Sounds klingen unheimlich gut. Mit keinem anderen Editor lossen sich derzeit so echt klingende Drums programmieren. Auch alle anderen Klänge sind machbar. Mit dem bsm läßt sich
so ziemlich das letzte aus dem Pokey (der XL/XE‘ Soundchip) holen. Die Bedienung ist umfangreich und hat alles was man braucht. Allerdings ist die Bedienung äußerst kompliziert und Zeitraubend. Es dauert schon seine Zeit, bis man erste eigene Klänge hört. Schade!

smp
Der smp ist ein PD-Programm, das sich vor‘ den kommerziellen keineswegs verstecken muß. Die Menü-Bedienung ist einfach und gut durchdacht (Bedienung per Tastatur). Im Pattern-Editor hat man z.B. die Möglichkeit das gleiche Instrument mit verschiedenen Lautstärken zu spielen oder inmitten eines Pattern das Tempo zu ändern. Das Soundkontrollregister läßt sich leider nicht frei editieren, der Autor hat „die besten Sounds ausgesucht“; daher klingen die smp-Stücke irgendwie alle ähnlich – es läßt sich nicht jeder mögliche Sound einstellen.

cmc
Der cmc wird fenstermäßig gesteuert, alle 3 Fenster sind immer offen: man springt mit der .TAB-Taste immer ein Fenster weiter. Sehr einfach und schnell!. Er hat nur drei programmierbare Tonkanäle. Der erste Tonkanal ist ein „Doppel-Kanal“. Je noch Instrument kann man hier einen einfachen Ton, einen Filter-Sound oder einen 16-Bit-Ton spielen. Die entsprechenden realen Tonkanäle werden automatisch verknüpft) Fast alle „Polen-Spiele und – Demos wurden mit dem cmc vertont. Zusätzlich sind die Patterns des cmc 64 Schritte lang (bei gleicher Dauer hoben die Patterns z.B. im smp nur 32 Schritte). Manko: Keine Directory-Funktion.

mas
Wer mit strukturiertem Programmieren gut zurande kommt, wird sich in mos schnell zurecht finden. Die Klangtechnischen Möglichkeiten von mas sind hervorragend:
– beliebig lange Pattern
– beliebig lange Hüllkurven
– Soundcontrol Frei programmierbar
– 16tel (oder sogar 32tel?) Noten

Allerdings dauert es ziemlich lange bis man zu hörenswerten Ergebnissen kommt: Sourcecode schreiben, speichern, compilieren, laden, hören, Sourcecode ändern etc. Der mas-Editor läßt sich auch für andere Dinge verwenden: Man benutzt ihn wie den BASIC-Editor und kann über 56 KB(!) Text in den Rechner tippen.

Fazit
Die Zeit der Soundmachine ist wohl abgelaufen. Wer aber auf Grafische Notendorstellung nicht verzichten will, wird wohl nicht drumherum kommen.Bezugsquelle: Rätz

Der Black-Magic-Composer ist ein netter Editor mit guter Bedienbarkeit, etwas kurzen Patterns und Digidrum-Unterstützung. Bezugsquelle: User-Mag

Der Benji-SoundMonitor ist ein wenig umständlich zu bedienen, wegen der super Ergebnisse aber hervorragender Editor Für Profis. Bezugsquelle: war ABBUC Jahresgabe 93

Den SoundMonitor Prof. kann man als einen einfach zu handhabenden relativ gut klingenden Editor bezeichnen. Ich würde ihn Einsteigern empfehlen, auch weil er PD ist (billig!) Bezugsquelle: PD

Der Chaos Music Composer ist ein sehr einfach bedienbarer und ehrlich gut klingender Editor. Für Einsteiger sowie Profis geeignet. Bezugsquelle: ang, Holland

MASIC ist eine struktur-orientierte Musik Programmiersprache mit ausgezeichneten Klangqualitäten. Nur für Sound- und Code- Profis zu empfehlen. (mir war’s zu schwerl) Bezugsquelle: Rätz

PS: z.B. den ‚KE-Musikeditor‘ kenne ich nicht. Vielleicht weiß jemand anders etwas über Programme, die hier noch nicht aufgeführt sind ?

Euer Beetle

 


JHV ’94

Eine Darstellung aus der Sicht eines Clubmitgliedes.
Hallo Bit-Byter, XL-Freaks und ATARI Freunde!

Im Folgenden will ich meine Eindrücke und Erfahrungen zu dieser Veranstaltung wiedergeben. Noch einer mehrtägigen Planung und Vorbereitung stortete ich mit meinem Kollegen um 7:30h in FrankFurt/Main mit dem Auto in Richtung Herten.

Noch einer langen ober problemlosen Fahrt erreichten wir das Bürgerhaus in Herten-Süd Punkt 10:00h. Wir wurden freundlich von dem ABBUC-Vorstand begrüßt, und bekamen unseren Austellungsplotz gezeigt. Der Aufbau unserer Computeranlage und der Anschluß oller Peripheriegeräte erwies sich dann doch langwieriger als vermutet. Es traten unerwartete Probleme mit defekten 510-Kabeln auf und leider mußten wir feststellen, daß eine Floppy kaputt war.

Um 11:15h begann dann offiziell die Hauptversammlung 1994. Der 1. Vorsitzende Wolfgang Burger teilte die wichtigsten Zahlen aus dem vergangenen Geschäftsjahr mit. Derzeit hat der Club 620 Mitglieder und das Vereinsvermögen steht auch recht gut dar.

Leider gab es auch eine schlechte Nachricht. Die Mailbox des ABBUC hatte einen Totalausfall wobei großer Schaden entstand. Ein Vereinsmitglied mit DFU-Erfahrung hat sich bereit erklärt den Vorstand in die sem Bereich zu entlasten. Damit ändert sich auch die Rufnummer und evtl. die Online-Zeiten der ABBUC-Mailbox.

Es wurde vorschlagen, Sparta-DOS für alle Clubmitglieder lizensieren zu lassen. Dies führte zu einer längeren Diskussion über die tatsächliche Nutzung, Lizenzgebühren und Alternativen. Zum Ende der Versammlung stellten sich die ‚verschiedenen Regionalgruppen mit ihren aktuellen Projekten vor. Auch die kommerziellen Anbietern konnten auf ihre Neuheiten und altbewährten Artikel hinweisen. Das war eine gute Gelegenheit auch unsere Produkte vorzustellen.

Etwa um 13:00 h wurde die Versammlung geschlossen und alle Vereinsmitglieder und Besucher stürzten sich neugierig auf die Messestände. Erfahrungsgemäß kommen anfangs erst einmal die Leute zum Anschauen was es wo gibt, um sich dann gezielt mit Fragen und Wünschen an die Anbieter zu wenden. Wenn- dann später der Andrang nachläßt, hat man selbst Gelegenheit die Messestände zu besuchen. Dem war diesmal nicht so. Von Anfang an waren Leute da, um sich über die technischen Einzelheiten unserer Artikel zu informieren. Innerhalb, einer halben Stunde waren mehrere Geräte verkauft.

Unsere Präsentation eines wirkungsgradstarken Schaltnetzteiles und die graphische Darstellung von elektrischen Signalen mit dem neu entwickelten Meßgerät war sicherlich ein interessanter Anziehungspunkt. Wem der technische Kram zu langweilig war, kannte auf einem zweiten Rechner mit unserer Software spielen. Beide XLs teilten sich dabei über das neue 2-Rechnerinterface mit automatischer Umschaltung eine Floppy.

Gegen 16.00 h hatte ich dann endlich Gelegenheit, die Angebote der anderen Aussteller zu betrachten. Bei KE-Saft gab es außer Software auch Lose für eine Tombola. Um einen Softwaretitel oder gar wertvolleres zu gewinnen, mußte man schon viel Glück oder viele Lose hoben. Bei Klaus Peters gab es Hardware zu sehen und zu günstigen Messepreisen zu kaufen. 510-Kabel, andere Hardware und eine große Softwareauswahl hatte. der ANG aus Holland mitgebracht. Am Nochbarstand war meistens Musik aus einem umgebauten XE in Stereo zu hören, an anderen Ständen waren auch Fremdrechner im Einsatz (ST, Amiga, PC). Auffallend gut hatte wieder einmal Markus Rösner seine Softwareartikel präsentiert. Einige Regionalgruppen des ABBUC waren anwesend und zeigten ihre Eigenentwicklungen.

Selbstverständlich konnte man beim ABBUC sofort Mitglied werden, seinen Beitrag bezahlen, Restposten erstehen, oder von dem Schaltplan- und Reparaturservice Gebrauch machen.

Letzteres mußten wir auch gleich in Anspruch nehmen. Unser Floppydoc (Erhard Pütz) konnte den Fehler in unserer Floppy sehr schnell finden und reparieren.

Alle Namen der Aussteller konnte ich mir jedoch nicht merken, darum habt Verständnis, wenn Ihr Euch hier nicht erwähnt findet. Als wir uns dann selbst mit Hardware und Software eingedeckt hotten, war es auch bald Zeit den Stand abzubauen. Gegen 17:30 h waren einige Aussteller bereits auf dem We
g nach Hause.

Leider folgten nur wenige (30) der Einladung des Clubs zu einem ungezwungenen Beisammensein in privaterer Atmosphäre. Wir machten von dem Angebot Gebrauch, zumal sich spätestens jetzt der leere Magen mit unmißverständlichem Knurren meldete. In einer nahegelegenen Gaststätte haben wir unseren Magen beruhigt und einige lustige und interessante Gespräche mit den anderen Atari-Freunden geführt.

Gegen 21:30h mußten wir uns verabschieden, ein langer Heimweg lag vor uns. Um Mitternacht trafen wir endlich in Frankfurt ein. Als Aussteller ist eine Messe kein reines Vergnügen, die Mühen der Vorbereitung und der Streß vor Ort muß man auf sich nehmen. Dennoch ist es auch ein Erlebnis, das lange Zeit in Erinnerung bleibt.

Thomas Grasel

C-ARGS
– Die moderne Compiler sprache für den Atari XL/XE mit mind:128 KB RAM

Das Compilerteam der ARGS, das sind Jochen Scharrlach und Peter Straif, haben nach langem Überlegen beschlossen, eine Compiler-Sprache für den Atari XL/XE zu entwickeln. Natürlich wird der eine oder andere fragen, ob es denn überhaupt sinnvoll und notwendig ist, für den Atari XL/XE noch ein so großes Projekt (wir rechnen mit mind. einem Jahr Entwicklungszeit) in Angriff zu nehmen.

Verschiedene Punkte haben uns dazu gebracht, dies eindeutig mit JA zu beantworten:
– Es existieren eigentlich keine einfach einsetzbaren Pascal- und C-Compiler auf dem Atari.
– Die einzige sinnvolle Alternative ist ACTION!, welches aber kaum verbreitet und sehr teuer ist. Ausserdem ist ACTION! inzwischen auch einige Jahre alt, und läßt einige Eigenschaften einer modernen Programmiersprache vermissen.
– Wir haben genug von diversen Programmen, die in Turbobasic geschrieben und nachher durch den TB-Compiler gejagt wurden, und welchen in. Sachen Performance und
Vollständigkeit einfach Grenzen gesetzt sind.
– Es gibt kaum Programme, die von den inzwischen sehr weit verbreiteten RAM Erweiterungen gebrauch machen.

Daraus leiten sich auch schon unsere Anforderungen an die neue Programmiersprache ab: Es sollten die verschiedenen RAM-Erweiterungen unterstützt Werden, der Compiler muß Rücksicht auf die Rechengeschwindigkeit und Speicher des Atari nehmen (d.h. schnellen und kurzen Code erzeugen), eine im Kern offene und erweiterbare Struktur aufweisen, so daß es möglich ist, ihn später noch um wesentliche Aspekte zu erweitern, auch durch andere Benutzer. Desweiteren sollte die Mächtigkeit der Sprache im Bereich von C liegen. Im Endeffekt sollte es möglich sein, jedes Pascal- oder C-Programm einfach nach C-ARGS umzusetzen, dasselbe natürlich auch umgekehrt.

Durch ein ausgefeiltes Bibliothekskonzept wollen wir den Kern der Sprache klein und schnell halten, ohne die Sprache zu sehr abzuspecken. Ein geplanter Inline Assembler macht einen unbegrenzten Zugriff auf alle Resourcen des Atari möglich. Auch Konzepte wie modulares Programmieren sollen möglich sein. Eine Zielsetzung dabei ist auch, später ohne Probleme auf eine höhere Programmiersprache wie C, Pascal oder Modula umsteigen zu können, da alle wesentlichen Konzepte einer modernen Programmiersprache schon enthalten sind.

Durch das Bibliothekskonzept lassen sich auch sehr große Programme in C-ARGS entwickeln, da alle Bibliothektsroutinen vorcompiliert werden, und erst beim Bindevorgang Stück für Stück eingebunden werden. Dabei wird darauf geachtet werden, daß auch nur die Programmteile aus einer Bibliothek eingebunden werden, die vom Programm aus auch wirklich genutzt werden. Dadurch werden die lauffähigen Programme sehr bescheiden von ihren Speicheranforderungen her. Die Entwurfsphase haben wir bereits abgeschlossen. d.h. der Sprachumfang ist vollständig in einer Grammatik definiert. Nun wollen wir von euch Atari-Usern gerne wissen, ob überhaupt ein Interesse an einer solchen Programmiersprache besteht. Dazu haben wir einen Handzettel vorbereitet, den ihr Ausfüllen und an uns zurücksenden könnt.

Es ist verständlich, daß wir eine solch große Entwicklungsarbeit nur aufnehmen, falls genügend Interesse besteht. Euer Peter Straif und Jochen Scharrlach.

Die Features von C-ARGS in der Übersicht:
– Der Compiler und die Entwicklungsumgebung benötigen mindestens 64k Zusatzrain (130XE). Es [werden Erweiterungen bis 4 MB unterstützt und auch wirklich genutzt.
– Für den Compiler ist langfristig eine komplexe Entwicklungsumgebung geplant, die Komponenten wie Editor, Debugger, Throwback von Fehlermeldungen, Bibliotheksverwaltung usw. umfaßt.
– Bibliothekskonzept wie in C
– Inline-Assembler
– komplexe Ausdrücke wie A := (B+C) x D – E – volle Unterstützung der ARGS-Hardware – User-defined data types, overloading
– Exception-Handling

Ein Beispielprogramm in C-ARGS:
program beispiel;
use float_lib, math_lib;
use xep80_Iib, draw_lib;
const chars = 80;
type komplex_point =
struct
pl, p2 : complex;
winkel : int; end struct;
var test: int;
punktl,punkt2 komplex_point;
hilf : float;
begin
winkel 360 / chars;
punktl.pl.real := 100;
punktl .p I .irr := 50; punktl.winkel := winkel; komplex_plot( punktl , 1); komplex_draw( punktl, punktl 100 ); while punktl.winkel < 360 do
punktl punktl + 2; komplex_plot( punktl 1 );
inc (punkt1.winkel);
end while;
end program;

C-ARGS The Future is coming soon.

ABBUC PD-Neuheiten

MR. 424 MD8-FILES #4 6 S
Drei zweiseitige Disketten, randvoll mit MD8-Soundfiles. Die Sounds lassen sich zum Beispiel mit dem Programm FAMPY abspielen. Folgende Stücke sind auf diesen Disketten enthalten: AXELF, JET, DNS, GOTTYA, MIG, SPACEHA, ZINEII, EXICAT, SUBWAY, OPERATIN, INSPACE3, KGSTITLE, WALKINGF, und PLANETS. Die Disketten sind in Schreibdichte Medium bespielt. Sie wurde von Lutz Fransky zusammengestellt.

NR. 425 MOD-PLAYER 2 S
Der MOD-Player spielt normale 31-Sample MODS von ATARI ST und AMIGA ab. Leider sind viele MODS bedeutend länger als 64KB Trotzdem liegen auf der Disk MODs bei. Die MODs sind original vom ST/AMIGA übernommen , unkonvertiert ! Man kann sie also auf einen dieser Rechner zurückübertragen und dort anhören ! Zusammengestellt von Thimo Gräf.

NR. 426 AMIGA OVERSCANN PICTURE 2 S
Also doch was für’s Auge ! Diesmal hat Thimo Gräf einige Overscan-Bilder vom AMIGA übertragen. Die Original-Auflösung waren 384*480 HAM , 320(352)*512 HAM , 320+400 HAM und 704*512 bei 16 Farben. Da der XL auch so herrlich overscannen kann , nun selbst mal gucken! Aber Vorsicht , nicht jeder Monitor/Fernseher packt die volle Auflösung. Nun, dafür hat der ATARI immer noch HARDWARE-Scrolling (um das Bild ganz darzustellen) Bedient wird das Scrolling mittels Joystick in Port 1. Mit dem Feuerknopf wird das nächste Bild geladen.

NR. 427 THE BRITISH DEMO 1 S
Diese DEMO-Diskette enthält 6 verschieden Grafik/Sound Demos. Im einzelen sind das: NAD, MELANCHOLIC, MIDI, PRESENTING…, STARS, und BUCKED WHYLIN‘ . Leider haben die Autoren zwar ein Auswahlmenü geschrieben, es wird jedoch nicht dorthin zurückgesprungen, so muß man nach jedem Part die Disk neu booten.

NR. 428 RUN FOR IT 1 S
Ein Jump- und Run- Spiel. Finde dich in einem Labyrinth zurecht un
d sammel in jedem Raum Gegenstände ein. Natürlich muß man sich auch gegen Angreifer wehren. Gespielt wird mit dem Joystick in Port 1. Eine Hiscore -Tabelle spechert die Punkte ab. Achtung: Für jeden Raum steht nur eine gewisse Zeitspanne zur Verfügung.

NR. 429 THE CUBE 1 S
Erstelle einen Würfel mit eigenen Bildern und lasse ihn rotieren. Damit ist eine Demo oder ein Titel für einen Videofilm schnell erstellt. Du kannst eigene Bilder im MIC oder PIC-Format zu CUBE-Bildern konvertieren. Auf der Diskette findest Du die Anleitung in englischer Sprache. Weiterhin ein DEMO-Cube, der Dich sicher überraschen wird.

PD-BIBLIOTHEK: THEO SCHWACKE, HEINESTR. 17, 45699 HERTEN
Tel. 02366 -34696

 

 

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