ABBUC Magazin 042


IMPRESSUM

(c) 1995 Atari Bit Byter User Club e.V. c/o Wolfgang Burger, Wieschenbeck 45

D­45699 Herten, Tel. +49 2366 39623 FAX +49 2366 39623

Email: 0236639623-0001@dtag.de

Das Atari Bit Byter User Club Magazin. erscheint 1/4 jährlich. Jeweils 1/2 jährlich erscheint das Atari Bit Byter User Club Sondermagazin

Eingesandte Artikel müssen frei von Rechten Dritter sein. Mit der Zusendung gibt der Autor seine Zustimmung zur Veröffentlichung.

Veröffentlichungen, auch Auszugsweise nur mit schriftlicher Genehmigung

 

 

Liebe Bit Byter,
endlich wieder in unserer alten geliebten Wohnung, macht das Zusammenstellen des ABBUC-Magazines doppelt so viel Spaß. Ich werde mich nun noch 4 Wochen in Norwegen erholen um dann im Oktober mit Euch die Jahreshauptversammlung zu veranstalten. Freue mich schon auf ein persönliches „Wiedersehen“ mit Euch. Also, bleibt gesund, habt Spaß mit dem Magazin und kommt am 28. Oktober nach Herten.

Bis dahin verbleibe ich mit herzlichen Grüßen

Euer Wolfgang

 

Atari Messe in Hanau 95

Am 23. April 1995 fand in Hanau die 3. ATARI-8- bit­Messe statt.

Der Ausricher war wie auch in den vergangenen Jahren KE-Soft (Kemal Ezcan). Während bei den letzten KE-Messen Standgebühren verlangt wurden, die angeblich manchen Anbieter von der Teilnahme abgehalten hatte, wurde diesmal eine andere Regelung getroffen. Jeder Anbieter sollte in geeigneter Form auf die Messe hinweisen, mußte wie jeder an­dere Besucher den normalen Eintritt bezahlen und am Messestand ein Preisausschreiben veranstalten. Die ausgesetzten Preise sollten einen Gesamt­wert von mindestens 50 DM haben.

Erfreulicherweise mußten weder Aussteller noch Besucher den Eintritt in Höhe von 5 DM bezahlen. Andreas Magenheimer bezahlte im Voraus für 100 Besucher den Eintritt, um den Anreiz für einen Messebesuch zu erhöhen. An dieser Stelle sei Ihm im Namen aller ATARI-8- Bit-User für die großzügige Spende gedankt.

Der folgende Bericht wurde aus Interviews, die während der Messe stattfanden entnommen.

Am Stand von KE-SOFT wurde Software für verschiedene Computersysteme angeboten. Neben älterer Software für den ATARI-8bit waren auch Angebote für den PC und Amiga vertreten.

An Hardware für den XL gab es das Turbo-Link, die CX85 (Zusatztastatur), sowie ein Paket mit Joystick und einem Modul. Das angekündigte neue Floppy­Interface war leider nicht zu besichtigen.

Das TOP-Magazin, Kaisersoft und RAM (rheinland-. pfälzische ATARI Maniacs) teilten sich einen Messestand. Vorgestellt wurde eine Bildershow als Demo, Polenspiele, die per Sammelbestellung geordert werden und eine Zusammenstellung der besten Artikel aus dem TOP-Magazin. Das Ergebnis des vom TOP-Magazin ausgeschriebenen Ideenwettbewerbs für ein T-Shirt mit ATARI-Motiv wurde präsentiert und Bestellungen dafür aufgenommen (35 DM + 5 DM Nachnahme). Markus Römer kündigte den Vertrieb von einigen Produkten aus der Portronic-Reihe von Armin Stürmer an.

Auf der Messe wurde nach längerer Pause wieder ein neues Strange Invasion Diskeftenmagazin von Stefan Lausberg vorgestellt Er wird sich nach 10-monatiger Zwangspause durch den Grundwehrdienst wieder mehr dem ATARI zuwenden. Neben dem kostenlosen Magazin 1/95 konnte man noch Software- und Hardware-Restposten aus eigenem Bestand erstehen. Wie von Ihm zu erfahren war, ist die ARGS in Person von Roland Bühler mit der Entwicklung eines Festplatteninterfaces kurz vor dem Abschluß. Im weiteren ist die ARGS mit der Erstellung einer neuen Programmiersprache für den ATARI-8bit beschäftigt.

Am Stand von POWERSOFT wurde viel Software präsentiert Laut Markus Rösner werden von Ihm in Kürze weitere neue Softwaretitel angeboten. Aufgrund des großen Umfangs seiner Softwarepalette und des begrenzten Platzes in seinem Auto verzichtete er weitestgehend auf Hardwarearlikel.

Die ATARI-Regionalgruppe aus Worms wurde durch Torsten Scheu vertreten. An seinem Stand waren die Spielekonsole 65XE, der JAGUAR und das LYNX zu sehen und zu testen. Die passende Software dazu gab es selbstverständlich auch. Torsten sucht noch defekte ATARI-Hardware, die er in seinem ‚Second Hand Shop‘ recycelt Für zugesandte Hardware gibt es Portorückerstattung oder Restwertausgleich durch (PD)-Software. Außerdem hat er Kontakte zu Mailboxen und Servern in den USA hergestellt und viele Informationen zum ATARI-8bit gefunden; die Infos will er den anderen Usern gerne zur Verfügung stellen. Eine Veröffentlichung in der ABBUC-Mailbox hat er bereits zugesagt.

Armin Stürmer vom AMC präsentierte seine große PORTTRONIC-Hardwarepalette, die neben dem MULTIPAD 3 auch das POWERPAD beinhaltet. Weitere Produkte setzte er im Preisausschreiben ein. Die Teilnehmer sollten ein Suchspiel in möglichst kurzer Zeit lösen. Mit Hilfe von JOYPAD und des STEREOBLASTER PRO mußten in einem imaginären Raum 6 Schätze durch akustische Peilung gefunden werden. Der neu präsentierte STEREO PHASER ist ein Gerät zum Nachbearbeiten von Hüllkurven, das die Erzeugung neuer Klänge aus vorhandenen ermöglicht. Neue Software gab es nicht, aber alte Titel wurden gut verkauft

Eine Arbeitsgruppe aus Thüringen, stellte Ihre Ausrüstung vor. Die Aktivitäten der Mitglieder liegen im Bereich Hardware-Entwicklung und Action­Programmierung. Sie werden möglicherweise eine Regionalgruppe gründen, und Ihre Arbeiten den ATARI-8bit-Usern veröffentlichen.

John Maris von ANG Software berichtete uns über seine geplanten Aktivitäten. Neue Software aus dem Hause ANG gibt es nicht und wird es vermutlich auch nicht mehr aufgelegt. Auch die ANG selbst wird es in Zukunft nicht mehr geben. In der nächsten Zeit wird ANG noch einige Lizenzen verkaufen. Die bisher angebotene Software wird nun von POWERSOFT vertrieben. Einige Artikel davon führt auch KE-Soft. Anl
aß ist hauptsächlich ein Autounfall, von dem er sich bis jetzt noch nicht richtig erholt hat. Wenn überhaupt kann er sich nur noch vorstellen einige Artikel für das holländische POKEY-Magazin zu schreiben.

Es wurden in Hanau eine ganze Reihe Programmen von MIRAGE, einige englische Titel und holländische Programme angeboten. An Hardware gab es den Soundsampler, ein Druckerinterface und 2600­Spielekonsolen.

Der ABBUC wurde, wie auch im letzten Jahr, durch Thomas Grasel und Harry Reminder vertreten. Angeboten wurden Anleitungen zu diversen Programmen, der Bauplanservice, die Möglichkeit der Abo­Verlängerung und selbstverständlich auch der Bei­tritt in den Club.

Die ATARI Usergroup Frankfurt stellte diesmal außer Ihrem Schaltnetzteil (SNT), dem automatischen 2­Rechner-Interface und dem S102PC-Interface auch ein Digitalvoltmeter inklusive Software vor, das sowohl am XL als auch am PC betrieben werden kann. Weiterhin gab es Plafinen für den Nachbau des SNT und dazu einen neuen Bauplan. Einige Produkte sind auch als Bausatz zu erhalten.

An fast allen Ständen gab es Software-Restposten zu erstehen, die sehr begehrt waren. Die Besucherzahl war mit geschätzten 80 Leuten etwa gleich wie im Vorjahr, es waren aber mehr Aussteller auf der Messe. Die Preisverlosungen im Laufe des Nachmit­tags waren unterschiedlich ausgelegt sowohl in Bezug auf zu lösende Aufgaben als auch hinsichtlich der ausgesetzten Preise.

Die genaue Kilometerzahl für die Anreise des ANG konnte niemand erraten wie lange es den ABBUC schon gibt wußten jedoch einige Besucher. Aus diesen wurden die Gewinner ausgelost:

1. Preis, autom. 2-Rechner-Interface:Markus Rösner
2. Preis, das Spiel Shogun Master: Patrick Schnabel
3. Preis, 5 ABBUC PD-Gutscheine: Daniel Pralle
4. Preis, 3 ABBUC PD-Gutscheine: Andreas Volpini
5. Preis, 2 ABBUC PD-Gutscheine: Bastian Bührig

Atari Messe in Hanau 95

Wie ihr aus verschiedenen Geschreibsel von mir, in den letzten Magazinen vielleicht schon bemerkt habt, bin ich absoluter Verfechter des HDI von Erhard Pütz.Deshalb bin ich immer wieder am Probieren, welche Programme ohne, oder auch mit kleinen Problemen, unter DD mit 720kByte oder mit HD und 1,44MByte auf 3,5″ Laufwerken verwertbar sind. Nur, in der letzten Zeit (bei mehr oder minderem Schweine-Wetter) habe ich mich in meinem Arbeits­Zimmer mit dem BEWE-DOS beschäftigt. Leider ist dieses DOS meiner Ansicht nach etwas zu sehr auf die XF-551 zugeschnitten. Dadurch wird auf 3,5″ Disketten mehr oder weniger Speicherplatz verschenkt, da dieses DOS nur mit 360kByte in DD formatiert. Ansonsten ist es aber recht gut gelungen und man wird so richtig, bei manchen Befehlen, an seinen PC in der Firma erinnert Bezüglich den Befehlen wäre eventuell noch eine Anpassung an die Befehle von der letzten SPARTA-DOS-Version 3.2g wünschenswert (z.B. CWD in CD usw.). Mein gemischtes Doppel besteht nun aus einem Mischmasch von 2 verschiedenen, und beinahe kompatiblen, DOS-Varianten. Also, man formatiert eine DD­3,5″-Diskette mit dem SPARTA-DOS 3.2g, mit XINIT25 oder ähnlichem, mit 720kByte und schreibe das SPARTA-DOS mit auf die Diskette.

Nun macht man ein Subdirectory DOS auf und kopiert sich hier hinein das XBW110.DOS, Weiterhin das wichtige File XINIT25 vom SPARTA-DOS und vom BEWE­DOS so diverse Sachen wie: RAMDISK, CLOCK, TIME, DATE, IF, ELSE, PAUSE, MENU usw. Nun nimmt man sich eine jungfräuliche Diskette, forma­fiert diese mit XINIT25 und mit DOS. Da nunmehr das XBW110.DOS im Subdirectory steht, wird die Disk mit 720kByte formatiert und unter BEWE-DOS bootfähig. Die Vorteile bestehen nun darin, man hat unter BEWE-DOS eine voll funktionsfhäige Diskette mit DEUTSCHER UHRZEIT und DEUTSCHEM DATUM, d.h. man muß im SPARTA-DOS nicht irgendwelche Sektoren suchen und verändern, um die Uhrzeit richtig zu takten (50 Hz Netzfrequenz ge­genüber 60 Hz in Amerika). Die Diskette hat ihre volle Speicherkapazitt und mit einer schönen STARTUP.BAT kann man vor dem «Hochfahren“ des wunderbaren ATARI-800- XL-Systems noch verschiedenes setzen: Zum Beispiel:

BASIC OFF
RAMDISK 8
CLOCK ON
DATE
TIME
CWD „Programm-Name“
… usw.

Wer es geschickt macht, kann mit IF und ELSE nach der Eingabe von Zeit und Datum nochmals anhalten und fragen, ob alle Eingaben (TIME, DATE) richtig sind und diese eventuell noch verbessern. Ich habe schon verschiedene Programme mit dem GEMISCHTEN DOPPEL getestet und es geht ganz gut Man muß sich halt die Mühe machen und mit dem MENU vom BEWE-DOS die unter DOS 2.5 angelegten Files auf das andere Format umzukopieren.Mit etwas Geduld und verschiedentlichen Probieren bringt man so manches Programm zum Laufen. Entscheidend ist jedoch, das HDI wird mit den entsprechenden Disketten voll genutzt.

Werner Heilmuth,. Ransbachstr.Nr.19, 97711 POPPENLAUER, Tel.: 0973311859

XL Interlacing Bilder

Das ist eine Beschreibung des Interlace – Verfahrens auf dem XL. Es ist nämlich auch hier möglich, eine höhere Auflösung vorzutäuschen, ähnlich dem AMIGA… So können 16 Farben Bilder bei einer Auflösung von 160*200 statt 80*200 erscheinen, oder in Graphics 8 wird ein 80 Zeichen Modus erstellt!

Grundsätzlich ist sowohl horizontales, als auch verlikales Interlacing möglich. Beides zusammen allerdings nicht.

Nun, wie funktioniert es? Ganz einfach: Anstatt 50 mal pro Sekunde den normalen Screen aufzubauen werden einmal alle geraden und einmal alle ungeraden Zeilen oder Spalten dargestellt, also 25 mal pro Sekunde eines von 2 Halbbildern.

Jetzt sollte man aber nicht denken, daß die Bildaufbaurate von 50 Hz auf 25 Hz sinkt Das macht sie nämlich nur zum Teil, also nur Teile des Bildschirms werden mit nur 25 Hz aufgebaut Diesen Denkfehler machte ich anfangs auch.

Stellen wir uns vor: Ein Monochrom-, also ein Graphics 8 Bild wird vertikal ge-interlaced. Nun, mit den Farben Schwarz (POKE 710,0) und Weiß als Schriftfarbe. Jetzt wird ein 320*400 Bild in zwei 320*200 Ha Ibbilder zerlegt, von denen eins alle geraden und das andere alle ungeraden Zeilen enthält Im VBI werden dann jeweils die Bildspeicher getauscht. Die Bildspeicher? Ja, denn der ANTIC kann ja nur Bildspeicher bis 4 KByte verwalten. So muß beachtet werden, daß bei Grafikstufen wie Graphics 8, wo 7680 Bytes Bildspeicher vorhanden sind, ein zweiter Bildspeicher vorhanden ist. Overscan Bilder, also solche, mit dem 48 Zeichen Modus und bis zu 240 Zellen, brauchen über 8192 Bytes, so daß gar 3 Bildspeicherangaben nötig sind. Nun, jetzt kann es sein, daß sich die Informationen der beiden Halbbilder so gut wie gar nicht unterscheiden. Das heißt, (in Graphics 8) in beiden Halbbildern ist ein Punkt gesetzt oder nicht ges
etzt. An einer solchen Stelle ändert sich nichts beim Umschalten zwischen den 2 Halbbildschirmen. Hier bleibt quasi die Wiederholungsrate des Bildes bei den üblichen 50 Hz (oder 60Hz bei amerikanischen NTSC Geräten). Unterscheiden sich aber an einer Stelle Halbbild 1 und Halbbild 2, also ist in einem an dieser Stelle ein Punkt gesetzt und im anderen nicht, so flimmert das Bild an dieser Stelle. Die Bildwiederholrate sinkt dort auf 25 Hz (oder 30 Hz bei NTSC). Man sieht dies deutlich im Gesamtbild, da es meist nicht ganz flakkernd dargestellt wird, sondern immer nur Teile ei­nes Gesamtbildes flackern. Es gibt aber einen Trick, um das Flimmern zu verringern: Der Farbunter­schied (gehen wir immer noch von GRAPHICS 8 aus), ist zwischen Weiß und Schwarz sehr groß. Setzt man die Schrlftfarbe aber auf eine dunklere Graustufe, so läßt das Flimmern deutlich nach. Wieso das ? Nun, der Unterschied zwischen Schwarz und (Dunkel)-Grau ist geringer als zwischen Schwarz und Weiß. Wird jetzt dauernd umherge­schaltet, scheint das Bild weniger zu flackern.

Logischerweise müßte dann bei Farbbildern folgen­des auftreten: Je geringer der Farbunterschied zwischen den Halbbildern an einer bestimmten Stelle, desto ruhiger wird das Bild an dieser Stelle dargestellt.

Wer schon mal große Interlace Bilder auf dem AMIGA oder anderen Rechnern gesehen hat kennt das vielleicht. Helle Farben auf dunklem Grund flimmern sehr schlimm, digitalisierte Bilder mit vielen Farbab­stufungen und kaum krassen Übergängen hingegen werden ziemlich ruhig dargestellt Man könnte praktisch sagen, daß bei Farbbildern ein breites Spektrum von Bildwiederholungsraten zwischen 25 und 50 Hz anzutreffen ist (bzw. 30 bis 60 Hz).

So, jetzt kurz zur Technik. Höchst simpel und ohne großen Verbrauch von Rechenzeit. Im VBI wird abwechselnd Halbbild 1 und im nächsten Durchlauf Halbbild 2 dargestellt. Mehr nicht. Zu beachten gilt nur, wie gesagt, daß alle Bildspeicheradressen im jedem VBI geändert werden müssen. Auf jeden Fall ist es wichtig, daß in jedem zweiten VBI ein Bild wie­der dargestellt wird. Das Ganze kostet praktisch nur wenige Taktzyklen und kann problemlos parallel zu LadeoperatIonen, Sampleausgaben, DLIs, usw. ver­arbeitet werden. Der VBI eignet sich meiner Meinung nach am besten. Eventuell könnte man aber auch den DLI benutzen .

FARBINTERLACING

Ganz kurz sei hier noch eine weitere Technik angesprochen: Das Farbinterlacing. Hier befinden sich nicht in den beiden Halbbildern jeweils gerade oder ungerade Zeilen, sondern Bilder mit verschiedenen Farbinformationen. Die Farbinförmationen beider Bilder zusammen ergeben eine neue Farbe. Zum Beispiel sind in einem Bild Graustufenwerte gespeichert, im anderen Helligkeiten. Hier sei nur an die Grafikstufen 9 und 11 erinnert, lediglich der Bild­schirm muß umgeschaltet werden und 64 (Graphics 9) oder 192 (Graphics 11) nach 623 geschrieben werden.

16 Graustufen * 16 Helligkeiten machen 256 Farben. Für das Flackern gilt das Gleiche wie vorhin gesagt Je stärker die Farbunterschiede, desto stärker flim­mert es. Deswegen flimmern helle Farben meist mehr als dunkle. Aber hier gilt es zu probieren. Mit dieser Technik, sind bunte Bilder kein Problem. So wäre ein Bild mit 16 Farben (2 Screens mit je 4 Farben, 4*4=16) möglich, das statt 8000 natür­lich nun 16000 Bytes benötigt klar. Die Palette wäre theoretisch 128^2 =16384 Farben (!) . 128 Farben, da in Grafikstufe 15 bzw. ANTIC Mode 14 nur 128 Farben möglich sind. 16 aus 16384 Farben, wirklich viel. Allerdings, ob nun Farbe A in Bild 1 und Farbe B in Bild 2 oder umgekehrt ist, macht nichts aus, es fallen also einige Farben weg. Außerdem flimmern einige Kombinationen dermaßen arg, daß auch sie praktisch wertlos sind. Trotzdem sind mehrere tausend Farben möglich.

Im Modus 10, wo wirklich 256 Farben möglich sind, wären so gar 256 ^ 2 = 65536 Farben möglich, mit den beschriebenen Abzogen, darstellbar wären na­türlich nur 81 (9*9, da 9 Farben in Graphics 10).

Nimmt man in Grafikstufe 15 noch die Player dazu, wären statt 4 nun 9 Farben drin, also könnten noch mehr Farben in ein Interlaced-Bild gebracht werden, wer will kann das ja mal probieren. Wenn man aberjetzt in jeder der 240 Zeilen der zwei Farb-‚Halbbildee via DLI eine eigene Palette mit 4 unabhängigen Farben kreiert, dann stünden theoretisch 240164840 Farben aus ca. 16000 zur Verfügung, wobei noch 5 farbig unabhängige Player- bzw. 4 Player und 4 Missiles dargestellt werden könnten. Allerdings wird es wahrscheinlich rechenzeitmäßig nicht hinhauen mit 240 Zeilen, zumindest wird’s schon kritisch. Ja, der Nachteil ist allerdings a) das Geflacker, b) bei Einsatz des DLIs ein enormer Rechenzeitverbrauch, bei 240 Zeilen, c) der Speicherverbrauch verdoppelt sich. Trotzdem, Titelbilder oder Demobilder, die nicht der Dauerbetrachtung ausgesetzt sind, können mit dieser Technik nahezu die Qualität von weitaus teureren Geräten erzielen. In Grafikstufe 8 ist diese Technik, wegen der eigentlichen 1% Farben weniger gut einzusetzen, aber experimentieren und mit try and erroe das Beste herausfinden.

Die in der Textbeilage zu Magazin 41 beschriebene Technik zu ‚ColorvieW ist übrigens wieder etwas anderes. Hier werden ja Rot /Grün/Blau Anteile berücksichtigt, während die Color-Interlacing Technik einfach 2 Bilder überdeckt in denen zum Beispiel in Graphics 15 je 4 beliebige Farben aus 128 pro ‚Halbbild‘ zur Verfügung stehen. Bei geschickter Farbwahl ist das Bild ruhig und flackert kaum ! So abschließend hoffe ich, daß das Geschilderte von dem einen oder anderen verwendet wird. Ich werde es jedenfalls tun, für Titelbilder von Spielen bieten sich solche Bilder, kombiniert mit Digisound doch geradezu an. Eins muß ich aber sagen: Man sollte niemanden eine Dauerbetrachtung dieser Interlace-Bilder zumuten. Das heißt keine Adventurebilder oder Spielgraflken so erzeugen, da die Augen doch auf Dauer ermüden und kein stundenlanges Arbeiten möglich ist.

Beim XL ist meiner Meinung nach ein horizontales Interlacen sehr sinnvoll, vertikal sind ja immer bis zu 240 Zellen drin. Aber, gerade Graphics 9 und 11 oder auch Graphics 10 mit 9 (stimmt das?) echt frei definierbaren Farben ‚leiden‘ doch an der geringen horizontalen Auflösung von 80 Pixel. Und 16 Farben (Graphics 9 oder 11) bzw. 9 Farben (Graphics 10), darstellbar bei bis zu 197240 Punkten (48 Zeichenmodus, 240 Zeilen) sind ja echt nicht zu verachten, oder? Kombiniertes Interlacing /Dithering, wie es beim 256 Farbverfahren verwendet wird (80120 bei 256 Farben) könnte tolle Bilder hervorbringen (160120 bei 256 Farben). Aber welcher 8 Bit Rech­ner bietef schon 16 echte Graustufen oder gar 256 Farben gleichzeitig ?

Auch 640 (768) * 192 (240) in Graphics 8 wären nicht zu verachten! Vertikal könnte die Bildgröße­maximal auf 384 (480) gesteigert werden. Doch, ne­ben dem Flacker- Nachteil gibt es noch einen weite­ren gravierenden Nachteil: Der Speicherverbrauch pro Bild steigt natürlich um das Doppelte, da ja 2 Halbbilder vor
handen sein müssen. Außerdem sinkt die Geschwindigkeit da Bildoperationen immer auf beiden Bildern stattfinden müssen. Auch arbeiten die ganzen BASIC-Bildoperationen nicht mit dieser Technik zusammen. Allerdings könnten natürlich schnelle Operationen entwickelt werden, speziell für diese Grafikmodi, falls Interesse besteht. Man sollte stets versuchen, die Kontraste der Farben möglichst gering zü halten, damit sich das Flimmern in Gren­zen hält Starke Hell/Dunkel Kontraste sollten mög­lichst vermieden werden, sowohl bei Interlacing zur Auflösungsverdopplung als auch beim Color­Interlacing.

Mit 640*200 hat man in Graphics 8 die Möglichkeit zur Darstellung von 80 Zeichen/Zeile. Ich habe den ATARI ST 8*16 Font konvertiert und man kann ihn nutzen!

Alles in allem, es ist ein interessanter Effekt, der es durchaus wert ist auf dem XL benutzt zu werden. Ich für meinen Teil werde es tun und rate anderen Usern, es auch mal zu probieren. Also, viel Spaß beim Interlacen!

Ach, fast hätte ich es vergessen. Man könnte via Interlacing auch die Anzahl der Player/Missiles verdoppeln, indem eben jede 50tel Sekunde ein Player an einer anderen Position gesetzt wird. Oder, man stellt abwechselnd zwei Halbplayer dar, um eine höhere Auflösung der Player zu simulieren. Via Interlace-Technik sollten also, je nach Kontrast zum Hintergrund, mehr oder weniger flimmernd 8 Player und 8 Missiles pro Zelle (man kann immer über DLI die horizontale Position der Player in jeder Zeile ändern) darstellbar sein. Oder 16*240 Pixel Player, also doppelte Auflösung horizontal bzw. auch vertikales Interlacing. Probieren ist alles!

Ich habe ein Programm zum Verdoppeln der Playeranzahl mit dieser Technik entwickelt eher eine Routine, simpel aber ausbaufähig! Allerdings, etwas komplizierter wird es wiederum, wenn jeder der neuen 8 Player ein anderes Aussehen hat Dann muß natürlich auch dafür gesorgt werden, daß immer die richtigen Daten ausgegeben werden können. Aber auch das sollte kein größeres Hindernis darstellen ! Auch hierfür entwickelte ich Demos, eine, die 8 verschiedenfarbige(!) Player, eine die 16 verschieden­farbige Player und eine die 32 verschiedenfarbige Player in einer Zeile darstellt wobei die ‚Redraw’­Rate je nach Playeranzahl dramatisch sinkt, also 32 Player sehr flackerig sind. Aber 8 oder vielleicht 16 Player, mit wie gesagt individuellen Farben sind auch was, oder? Zumal da ja noch die 4 Missiles sind bzw. der daraus formbare Player! So wären ne­ben den 8 Player (relativ sauber) noch 8 Missiles oder 2 weitere Player drin, pro Zeile natürlich. Da kann man aber wirklich nicht mehr sagen, der XL hätte zuwenig Spriftes. Zumal sich das Ganze noch vervielfachen ließe, indem eben die Positionen der Player alle paar Zeilen geändert werden (also das bekannte vertikale Splittert der Player via DLI). Allerdings, der DLI und der VBI sind bei der hier genannten Technik schon aktiv!

Nun, vielleicht schreibt mal jemand ein Ballerspiel oder so etwas, daß sich solchen Techniken zu Nutze macht. Schließlich gibt’s z. B. auf dem C64 sehr viele horizontal scrollende, vor Sprites strotzende Spiele, obwohl dieses Gerät auch nur 8 Sprites hat, soviel ich weiß. Und allzu viel Rechenzeit braucht man bei dieser Playerverdopplung auch nicht unbedingt, im Gegensatz zu Shapes (Software-Sprites) braucht man sich bei den Player übrigens nicht um Hintergrundrettung usw. zu kümmern. Na ja, ob man da noch von ‚lnterlacing‘ in dem Sinne sprechen kann ist die Frage, aber ich nenn’s halt mal so, ir­gendein Name muß sein!

Ich habe das Ganze auf einem normalen PAL Fernsehgerät getestet, wie es auf einem Monitor oder NTSC Gerät wirkt, kann ich deshalb leider nicht sagen.

Persönliche Eindrücke

  • Sowohl 640*200 als auch 320*400 kommen gut rüber, es flimmert deutlich weniger, wenn der Farbkontrast Schriftfarbe/Hintergrund nicht allzu kraß ist
  • 160*200 bei 16 Farben, Graphics 9: Flackert recht stark, Bild sieht erst bei etwas Entfernung vom Bildschirm gut aus. Kommt aber auch auf das Motiv an.
  • 80*400 bei 16 Farben, Graphics 9: Kommt recht gut rüber, auch das Flackern ist nicht allzu stark. Lediglich die geringe horizontale Auflösung ist etwas störend.
  • 320*200 bei 4 Farben, Graphics 15: Bis jetzt recht wenige Tests, scheint ganz brauchbar zu sein, auch nicht allzu stark flackernd. Wird sich auf die Dauer zeigen müssen !
  • Colorinterlacing: Tja, manche Farbkombinationen flimmern einfach grauenvoll, manche sind ziem­lich ruhig. Getestet habe ich Graphics 15, mit nunmehr 16 Farben pro Zeile und Graphics 9/11 überdeckt, mit insgesamt 256 Farben, was allerdings unheimlich flackerte.
  • Player-Verdopplung: Flackert, wie immer, je nach Unterschied von Hintergrund zu Player. Bei geschicktem Einsatz sicher in Spielen oder Demos nutzbar, warum nicht ?

Eins steht fest Weder für tolle Farbpracht noch für hohe Auflösung hat man einen der so hoch geprie­senen PCs nötig, mit trickreicher Programmierung ist aus dem XL mehr herauszuholen als man denkt Wenn’s zu wenig Farben sind, macht man sich halt neue, wenn’s zuwenig Sprites sind (Player), machen wir halt mehr dazu . . .

Das IFF – ILBM Picture Format

IFF Format ? Was hat das auf dem XL zu suchen ?Nun, ich suchte ein Bildformat, um Bilder von ATARI ST, AMIGA, PC auf den XL zu konvertieren. Die Anforderungen waren diese: variable Auflösung, variable Farbtiefe, einfach ladbar, möglichst leistungsfähige aber trotzdem einfache Kompression, möglich große Kompatibilität innerhalb verschie­dener Systeme. Nun, das IFF Format bietet das. Variable Farbanzahl/Auflösung, sehr einfache Kornpression, trotzdem recht brauchbar und auf AMI­GA,ST und PC verbreitet (Deluxe Paint). Also, be­nutzte ich dieses Format.

Aufbau des Dateiheaders:

Langworte/Worte im Motorola Format, also bei Word Hi Byte und dann Lo Byte ! (ganz kurz zu den Langworten: beim XL werden diese 32-Bit Werte höchst selten benötigt, ihr Wert errechnet sich aus:

Byte l*16777216+Byte2*65536+Byte3*256+Byte4

Die einzelnen Teile des IFF Dateiheaders werden als ‚Chunks‘ (eng. für ‚Brocken‘) bezeichnet und bieten ein sehr ausbaufähiges System, da leicht Zu­satzchunks eingebaut werden können, die bei Nicht­gebrauch überlesen werden. «FORM“ (ASCII) + 4 Bytes Restlänge des Files (Longword) Dies ist die allgemeine IFF Kennung, auch bei IFF Samples oder Texten zu finden.

„ILBM“ + 4 Bytes Längenangabe: Kennzeichnung als Bild Datei

„BMHD“ (Bitmapheader): hier sind 20 Bytes mit ver­schiedenen Bildinfos zu finden.

Die Words wie immer im Motorola Hi/Lo Format!
1 & 2 Bildbreite in Pixeln
3&4 Bildhöhe in Pixeln
5&6 Abstand vom linken Rand (bei Ganzbild 0)
7&8 Abstand vorn oberen Rand (bei Ganzbild 0)
9 Anzahl der Bitplanes ergibt 2APlanes Farben
10 Masking (??? Meist unbenutzt)
11 Compression ((l= gepackt, 0 = ungepackt, evtl. auch 1 für andere als das,Standard Packverfahren)
12 unbenutzt
13 & 14 Transparent (bei Masking wichtig)
15 Breite eines Pixels (xaspect, normal =1)

16 Pixelhöhe (yaspect, normal =1)
17 & 18 Breite des Grafikschirms in Pixeln
19 & 20 Höhe des Grafikschirms in Pixeln

„CMAP“ (Colormap): 4 Bes CMAP Länge, dann 3*Farbanzahl Bytes, wobei die Farben hier im RGB Format aufgebaut sind (je ein Byte Rot- ein Blau-, und ein Grünanteil). Die RGB-Bits sind linksbündig, d. h. in den oberen vier Bits eines Bytes gespeichert, da der AMIGA und auch der ATARI STE 16 Rot Grün oder Blau Stufen zulassen, allerdings nutzen PC IFFs (bei VGA Palette) auch die unteren 4 Bits aus ( 4 Bit Palette: 16*16*16=4096 Farben, 6 Bit Palette 64*64*64 =262144).

BODY“ (Grafikdaten) + 4 Bytes die angeben wieviele Bytes die eigentl. Grafik groß ist Es folgen jetzt die Grafikbytes. Allerdings, je nach Anzahl der Bitplanes eine Zeile von Plane 1, eine von Plane 2…. Plane n bis Zeile 2 von Plane 1, Plane 2 … Hat man z. B. ein 4 Farbbild, gibt’s 2 Bitplanes. Die Auflösung soll 160*200 sein. Also, 40 Bytes pro Zeile. So sind da zuerst 20 Bytes Plane 1 (Zeile 1), dann 20 Byles Plane 2 (Zelle 1), dann 20 Bytes Plane 1 (Zeile 2) und 20 Bytes Plane 2 (Zeile 2)

Kompression

Falls das Bild komprimiert ist geht man folgend vor: Man liest ein Byte. Es wird als Steuerbyte interpretiert. Ist es <128 Bytes (positiv, da Bit 7 nicht ge­setzt), so werden die im Byte angegebene Anzahl an Bytes + 1 in die Bitmap geschrieben (ungepackte Daten). Ist das Byte 128 (negativ), so wird das dar­auffolgende Byte (256-Wert des Steuerbytes ) +1 mal in die Bitmap geschrieben. (eine gepackte Bytefolge) Das Steuerbyte 128 sollte im Normalfall nicht vorkommen, falls doch wird es überlesen (Zu beachten ist aber, daß 128 auch schon als negativ interpretiert wird). Ich erwähne das mit positiv/negativ, da ein Entpacker schnell mit BPL/BMI abfragen kann (in Assembler), die 128 sollte echt nicht vorkommen !

Sourcecode habe ich leider keinen, da ich die Routine über Datazeilen gebastelt habe, also direkt mit Zahlencodes ! Die Kompression ist manchmal erstaunlich gut und andere Lauflängenverfahren sind meist nicht weltbewegend besser, wenn überhaupt Dazu trägt bei Farbbildern auch die Zellenaufteilung bei. Es existieren evtl. andere Kompressionsverfahren (Kompressionsbytel), die mir allerdings nicht bekannt sind.

Apropos Kompression: Die schwarzweiß Clip Arts (auf ABBUC-PD Nr. 446 ft) waren ursprünglich im ATARI ST STAD.PAC Format gespeichert. Dieses packt Mono- Bilder sehr gut, auch mit Lauflängenkodierung, allerdings horizontal oder vertikal, wobei letzteres meist eine weit bessere Packrate liefert. Das liegt einfach daran, daß mehr gleiche Bytes in dieser Reihenfolge vorliegen. Beim dem Koala For­mat ist soviel ich weiß auch eine vertikale Kompression möglich. Wer noch bessere Kompression wünscht, sollte Formate wie GIF oder TIFF (wobei es dort verschiedene Verfahren gibt bzw. bei GIF auch 87 oder 89). Allerdings sind mir diese Verfahren nicht bekannt.

Manchmal kommen auch noch andere Chunks vor, wie etwa das CRNG Chunk für das in Dpaint mögli­che Colorcycling, auch Namens-Chunks oder Chunks die die Herkunft des Bildes bezeichnen gibt es. Ein eigenes Programm braucht nur die Wirklich benötigten Chunks zu lesen, nicht benötigte können überlesen werden. So ist die Headerlänge variabel.

Auf dem XL benutze ich einen über eine Tabelle laufenden Konverter, um Bilder vom Bitplane in das XL Grafikformat zu wandeln. Bei monochromen Bildern ist dies allerdings nicht nötig. Die Daten nach­dem BODY Chunk + 4 können einfach in die Bitmap (Graphics 8 z. B. falls 320192) geschrieben werden. Die RGB Farbpalette ist recht unbrauchbar für den XL. Allerdings, Graustufenbilder können schnell ermittelt werden, indem die 3 RGB Werte addiert und durch 3 geteilt werden. Ansonsten wäre eventuell ei­ne Konvertierungstabelle möglich. Da ich zu 99% Graustufenbilder konvertiere, die sowieso immer dieselben Graustufen haben, war das CMAP Chunk bislang für mich eher zweitrangig.

Ein Sonderfall sind Bilder im HAM (Hold and Modify) Modus des AMIGA, 4096 Farben, allerdings mit nur 6 Bitplanes (normal = 64 Farben). Hier sollte keine CMAP aktiv sein. Schließlich sind hier alle AMIGA Farben möglich, allerdings in Abhängigkeit voneinander. Dieses Format sollte sich eigentlich in das ‚Colorview‘ Format wandeln lassen und phantastische Bilder auf dem XL ermöglichen. Dummerweise können HAM Bilder nicht einfach halbiert oder gevierteilt werden in der Horizontalen (vertikal schon), da durch die Abhängigkeit der Farben so ein totales Chaos entstehen würde. Man müßte ein solches Bild erst in ein ‚Echtfarbenbild‘, mit 12 Bit (4096 Farben) pro Pixel wandeln und dann verkleinern.

Englische Kurzbeschreibung des HAM Modes: (aus dem AMOS Buch entnommen): Each colour value on the AMIGA is created from a mixkture of three separate components. These determine the relative strength of the pilmary colours RedGreen and Blue in the final colour. Possible intensities range from 0 to 15. Ham mode splits the Amigas colour values into four separate groups. Colour registers 0-15.-The first 16 colours take a value directly from a colour register. These colours are treatedjust like those on a stan­dard 16 colour screen. Red components 16­31: However, if a point is set to a colour number in the range 16 to 31, the colour value is loaded from the pixel to its immediate left. The Red component of this colour is now replaced with a value from 0 to 15 which is caiculated from the formula : Intensity = Colour index – 16 Green components 32­47.-Similaily,a colour number from 32 to 47 takes the current shade, an changes the green component. The intensity of this component is set to the value of Colour-32. Blue components 48-63: These colour numbers grab the colour value from the point on the left of the cuffent pixel, and load a new blue compo­nent from your colour number like so : intensity= Colour index-48

So, hab’s mal in englisch gelassen, wegen evtl. Übersetzungsfehlern. Es dürfte wohl klar sein, daß mit diesem Verfahren sehr einfach sanfte Übergänge von Farben geschaffen werden können. Außerdem sollte so klar sein, wieso ein solches Bild nur 6 an­statt 12 Bitplanes für 4096 Farben benötigt. Um jetzt ein HAM Bild ins Colorview Format z. B. zu konver­tieren, sollte man die ‚echte‘ Farbe eines Punktes ermitteln und aus den RGB Werten die entsprechenden Werte für Rot(Grün und Blau holen. Man sollte nur nicht hergehen und einfach Werte überspringen, da ja sonst wegen der Farbabhängigkeit Verfälschungen auftreten!

So sollte für jeden Punkt, auch wenn er nicht gesetzt wird, die Farbe ermittelt werden. Falls man von 320 Pixeln pro Zeile nur 80 plottet, werden alle anderen Pixelfarben zwar auch bestimmt nur dann ignoriert. So sollte es möglich sein, auch AMIGA HAM Bilder ins Colorview – Format zu übernehmen.

Achtung! Diese Ausführungen gelten nur für den Standard HAM-Modus, nicht aber für den neuen HAM-8 Modus der AGA AMIGAs.

Ein in der letzen Zeit stark in Mode gekommenes Format ist ‚JPEG‘. Kombiniert mit Interlacing/Color­Interlacing oder der’Colorview‘-Technik sollten doch diese auf dem XL anzeigbar sein, Allerdings ist auch dieses Format mir gänzlich unbekannt Ich habe ein paar Jaguar Bilder in diesem Forrnat, die auf dem XL sicher gut rübe
rkommen könnten. Leider befürchte ich, daß ein 64Kb 800XL nicht mehr ausreichen wird. Aber, ich laß mich gerne eines besseren belehren!

So, das wars dann fürs erste. Aber, wie man sieht es gibt noch so viele Möglichkeiten die mit Interlacing, Farb-/Player-‚interlacing‘ und so weiter offen sind. Vielleicht fällt dem einen oder anderen noch was ein. Und eins beweist es ganz sicher: Auch nach mehr als 15 Jahren kann man nicht sagen, daß der 800 /XL/XE zu 100% ausgenutzt sei. Das sollte auch denen zu denken geben, die eben glauben alle Jahre wieder einen neuen Rechner (sprich schnelleren und größeren PC) ‚brauchen‘. Deswegen: Zeigt, daß die 8 Bitter nicht zum ‚alten Eisen‘ gehören und die angeblichen ‚Super-PCs‘ in der Praxis nichts wirklich ‚mehr‘ können.

Also, viel Spaß beim Tricksen auf dem 800 IXL/XE!!! Meine Adresse: Thimo, Gräf Ringstraße 2, 56462 Höhn-Schönberg, Tel.02661140338 oder /8137

Dietmar’s Spielecke

Hallo Leute,
heute der dritte Teil meiner Spielecke. Ich wünsche Euch viel Erfolg und Spaß mit meinen Tips. Also los geht es:

Zebu-Land von Ke-Soft
Hier sind die weiteren Codewörter:

01.ZEBU  02.BLAP  03.ZOFF  04.BONG 05.BAFF  06.BING  07.HOPP  08.FLAM 09.PENG  10.BANG  11.PLOP  12.BEEP 13.MOEP  14.UGLE  15.ZIPF  16.MONK 17.TONN  18.ZATZ  19.BLOY  20.ARCH 21.HEPP  22.SUPP  23.JUPP  24.ZSCH 25.PCHH  26.YARG  27.SNAG  28.GNOZ 29.NAJA  30.HUTY  31.WEST  32.NORD 33.SUED  34.TOLL  35.MATT  36.DOAD 37.HAHA  38.LOGI  39.DEPP  40.SACK

Die letzten Codewörter zu diesem Spiel gibt es in der kommenden Ausgabe.

LAZER-MAZE von KE-Soft
Hier sind die weiteren Codewörter:

01.LASER 02.HYPER 03.SPACE 04.DIGIT 05.TUNED 06.ATARI 07.MARIO 08.TECNO 09.SOGON 10.BASIL 11.LEVEL 12.NODUL 13.HOOCH 14.HONEY 15.ELEGY 16.DEATH 17.CACAO 18.CABAL 19.BIGOT 20.AGAIN 21.HAITI 22.INDIA 23.JESUS 24.KOREA 

Die letzten Codewörter zu diesem Spiel gibt es in der kommenden Ausgabe.

NEPTUN’S DAUGHT
von :THE ENGLISHE SOFTWARE COMPANY

EDITOR:
Sektor 101 Byte 121 HEX von 05 in 14=20 Leben
oder:
Sektor 101 Byte 121 HEX von 05 in 3E=62 Leben
oder:
Sektor 101 Byte 121 HEX von 05 in 63=99 Leben
oder:
Sektor 101 Byte 121 HEX von 05 in FF=255 Leben

CHICKEN
von:SYNAPSE SOFTWARE

EDITOR:
Sektor 24 Byte 86 HEX von 03 in 09=9 Leben
oder:
Sektor 24 Byte 86 HEX von 03 in 1E=30 Leben
oder:
Sektor 24 Byte 86 HEX von 03 in 63= 99 Leben
oder:
Sektor 24 Byte 86 HEX von 03 in FF=255 Leben für beide Player

DIAMONDS
von:THE ENGLISCHE SOFTWARE

EDITOR:
Sektor 14 Byte 144 HEX von 03 in 09=9 Leben
oder:
Sektor 14 Byte 144 HEX von 03 in 149=20 Leben
oder:
Sektor 14 Byte 144 HEX von 03 in 1E=30 Leben
oder:
Sektor 14 Byte 144 HEX von 03 in 28=40 Leben für beide Player

MR. M
von: ANTHONY KU-THE WASTELAND

EDITOR:
Sektor 11 Byte 23 HEX von 03 in 06=unedl. Leben

CROSS FIRE
AUTOR UNBEKANNT

EDITOR:
Sektor 63 Byte 78 HEX von 03 in 20=32 Leben
oder:
Sektor 63 Byte 78 HEX von 03 in 40=64 Leben
oder:
Sektor 63 Byte 78 HEX von 03 in 99=155 Leben

Das war es für heute. ich habe alle Programme selbst ausprobiert

– GOOD Byte – DIETMAR

S.A.M. Die Antwort

Ja, dann will ich mal in den Tiefen meiner Erinnerungen buddeln, was ich zu diesem Thema noch an Informationen hervorholen kann. Werner hat im Magazin #40 so viele verschiedene Punkte angesprochen. Ich denke, ich werde etwas schreiben zu:

A) MyDOS, HDI & 1.44 MB

Immer und immer wieder werde ich von Leuten darauf angesprochen, daß MyDOS angeblich nicht mit 1.44 MB Disketten funktioniert. Also, warum nicht noch mal im ABBUC Magazin darauf eingehen, obwohl es in der HDI-Anleitung natürlich auch steht.

Seit langer Zeit wurden Laufwerke für den XL/XE gebaut, die eine größere Kapazität als die Atari 810 oder 1050 hatten. Viele dieser Laufwerke waren aber genauso dumm wie die XF 551 – sie erkannten NICHT selbstständig die Kapazität der eingelegten Diskette. Deshalb war es erforderlich, daß die Anwendersoftware dies erledigte. So schreiben zum Beispiel MyDOS, DISKCOMM und zum Teil auch Bibo DOS den sogenannten PERCOM-Block zum Laufwerk. MyDOS und DISKCOMM erkennen Dis­ketten bis 720 KB korrekt Als MyDOS geschrieben wurde, gab es noch keine 1.44 MB Disketten für den XL. Das Problem ist nun, das MyDOS beim Booten automatisch das Laufwerk, sprich das HDI, programmiert Aber bei einer 1.44 MB Diskette wird es auf 720 KB programmiert. Die Folge ist, daß die Diskette nicht weiter gelesen werden kann. Abhilfe: Unter MyDOS gibt es einen Menüpunkt um die Laufwerke zu konfigurieren. Dort muß man intelligente Laufwerke wie das HDI ABMELDEN! Also zum Beispiel: Dl formatieren. Laufwerk 1 abmelden. Dann erst das DOS auf 1 schreiben. Danach kann man einwandfrei booten. Wenn man nur intelligente Laufwerke wie das HDI und 1050 verwendet, kann man getrost alle Laufwerke abmelden. Eine XF 551 sollte jedoch angemeldet bleiben, weil sonst unter Umständen die zweite Seite nicht erkannt wird.

B) S.A.M. und DOS 2.5

S.A.M. wurde für die ausschließliche Verwendung unter DOS 2.5 geschrieben. Es benutzt einige der letzten Sektoren auf der Diskette, auf die das DOS in mittlerer Dichte (MD) nicht zugreifen kann, für die Funktion ‚EDI‘, in dem es die Sektoren direkt liest Ferner springt S.A.M. bei 1/0 Operationen illegal di­rekt in Routinen des DOS. Wenn man nun ein ande­res DOS verwendet, wird dies in der Regel zu Feh­lern führen, weil an eben diesen Stellen nun etwas ganz anderes steht Sinnvollerweise sollte man also S.A.M. nur mit DOS 2.5 verwenden, auch wenn dabei ein würgendes Gefühl im Halse entsteht. Vielleicht findet sich ja jemand, der S.A.M. anpaßt, aber in diesem Leben wohl nicht mehr…

C) StarTexter

Ich habe eine ganze Zeit lang versucht, mit StarTexter auf dem HDI zu arbeiten. Aber StarTexter leidet unter dem gleichen Problem, wie S.A.M. – es springt illegal direkt ins DOS. Allerdings habe ich nach einiger Zeit die offenbar einzige Stelle gefunden. Diese liegt im AUTORUN.SYS und springt nach LOAD (glaube ich). Glücklicherweise konnte ich das AU­TORUN.SYS von StarTexter umprogrammieren und an diese Stelle einen XIO – Befehl implementeren, der für Sparta DOS und nun auch für BW-DOS Gültigkeit hat Unter Sparta DOS lief StarTexter bei mir eine ganze Zeit lang, nur durfte man den 80-Zeichen Bildschirm nicht aufrufen, da dann das DOS im Speicher gekillt wurde. Mit BW-DOS funktioniert das Ganze bei mir nun auf einer 1.44 MB Partition auf der Festplatte. Auf die Verwendung von Unterverzeichnissen muß man aber Verzichten, da StarTexter die Eingabe von Dateinamen nach Atari – DOS Kriterien überprüft. Für BW-DOS teste ich zur Zeit einen Treiber für die Echtzeituhr R-Time-8, so daß die Dateien dann auch übers aktuelle Datum verfügen. Für die Echtzeituhr der ARGS gibts nun auch einen Treiber für BW-DOS.

D) Programme & 1.44

Nun, um große Diskettenkapazitäten ausnutzen zu können, braucht man als erstes ein geeignetes DOS. Davon kenne ich drei: Sparta DOS, BW-DOS und MyDOS. Wobei ich mit MyDOS eigentlich nicht arbeite. Als nächstes braucht man jetzt Software, die mit diesen DOS zusammenarbeitet. Und da gibt es mittlerweile doch wirklich eine ganze Menge und um einige davon zu nennen:

DFÜ:
Bobterm (Robert Puff)

Textverarbeitung:
EDIT16.COM (Compy Shop)

Textverarbeitung 80 Zeichen:
TurboWord+ (XEP 80)
Atariwriter 80 XE (XEP 80)
StarTexter (BW-DOS)

Druckersoft:
SPRINTXL
Daisy DOT III

Programmieren:
BASIC
Turbo Basic (nur mit BW-DOS)
Mac/65 (Assembler)
MAE (Assembler)

Briefe schreibe ich zur Zeit mit Atariwriter 80 XE und drucke sie dann mit Daisy DOT III aus. Abgesehen von ein paar Fehlern, die Atariwriter hat, aber auf die man sich einstellen kann, bin ich mit dem Ausdruck hinterher sehr zufrieden!

Euer Floppydoc

 

Sparta DOS X

Eine Einführung von Larry Popa

Die Anpassung von Sparta Dos X

Einige Leute haben mir Fragen über die Anpassung von Sparta Dos X (SDX) gestellt. So dachte ich mir, daß ein Artikel, der einige dieser Dinge klarstellt, an­gebracht wäre. (Die Anpassung wird durch eine Textdatei vorgenommen, die CONFIG.SYS heißen muß).

Das in SDX eingebaute CONFIG.SYS mit dessen Voreinstellungen ist überhaupt nicht so gut, besoni ders wenn es auf einem nicht erweiterten Atari 130 XE läuft, deshalb ist in den meisten Fällen ein neues CONFIG.SYS von Nöten. Eine Sache die ich gar nicht genug betonen kann, ist. „Drückt NICHT die OPTION – Taste beim Booten!“ Wenn Ihr OPTION beim Booten drückt, überspriingt SDX automatisch das CONFIG.SYS auf Diskette und lädt direkt das eingebaute, was ja genau das ist was Ihr nicht möchtet.

Ich unterteile diesen Artikel jetzt in zwei Teile: der erste für Rechner mit 128 KB oder mehr Speicher und der zweite für 64 KB Rechner.

DieAnpassung bei l28KB (oder mehr)

Schritt 1: Das ‚USE‘ Kommando

In der allerersten Zeile sollte stehen:

USE BANKED

Dies stellt SDX so ein, daß es eine der 16 KB Banken einer Speichererweiterung für seine Puffer usw. benutzt. Denkt nicht einmal daran, diese Zeile auszulassen, weil Ihr sonst die Möglichkeiten von SDX sehr stark einschränkt. Viel weniger Programme werden sich laden lassen, wenn OSRAM anstatt von BANKED benutzt wird (zum Beispiel laufen Turbo Basic und Megablast 1 beide nicht wenn SDX OS­RAM benutzt, aber sie tun es mit BANKED).

Schritt 2: Geräte (‚DEVICE‘)

In der zweiten Zeile sollte stehen: DEVICE SPARTA 16,16

Dies lädt den Sparta Dos Treiber und ist notwendig, damit SDX funktioniert. Die erste 16 ist die Zahl der Sektorpuffer und die zweite ist die Zähl der Dateien, die gleichzeitig geöffnet sein können. Wir stellen sie beide auf 16, da der dafür benötigte Speicher vom BANKED RAM, auf das wir SDX vorher eingestellt haben, genommen wird. Die ganzen 16 KB werden benutzt, unabhängig davon, ob alles verbraucht wird, also können wir genauso gut für beides die Maximalwerte nehmen.

In der dritten Zeile sollte stehen:

DEVICE SIO

Dieser Befehl lädt den Highspeed 1/0 Treiber für SDX. Diese Zeile muß sein, oder SDX funktioniert nicht

In der vierten Zeile sollte stehen: DEVICE ATARIDOS oder DEVICE A:>DOS>ATARIDOS

Im ersten Fall wird der ATARI DOS Treiber aus dem SDX Modul geladen und der zweite lädt einen anderen von Diskette. Benutzt die erste Methode, wenn Ihr SDX Version 4.2 oder höher habt und nehmt die zweite bei Version 4.19 oder darunter (was ich tun muß). Dieser Treiber gibt SDX die Fä­higkeit, ATARI DOS oder MyDOS Diskettenformate zu lesen. Bei der zweiten Methode muß das richtige Laufwerk und Unterverzeichnis angegeben werden, auf dem der Treiber sich befindet (und Ihr möchtet es vielleicht im Unterverzeichnis DOS haben – Ihr habt doch ein DOS Unterverzeichnis, oder nicht?)

Die nächste Zeile ist wahlfrei: DEVICE INDUS

Verwendet diese Zeile, wenn ihr Induslaufwerke oder Laufwerke mit Happy verwendet Wenn nicht, laßt den Befehl weg (aber laßt keine Leerzeile in der CONFIG.SYS Datei)! (Ed: Ist diese Zeile für Lauf­werke mit US Doubler? Mit anderen Worten ein Ul­traspeed – Treiber??)

Die nächste Zelle lautet entweder DEVICE CLOCK oder DEVICE JIFFY

Dies sind die Uhren – Treiber. Nehmt den ersten, wenn ihr ein R-Time-8 Modul habt (oh Du Glücklicher) und die zweite, wenn nicht.

Und zum Schluß das letzte Gerät: DEVICE RAMDISK I,?

Dies ist der Ramdisk Treiber. Das T setzt die Ramdisk auf Laufwerk ‚1:‘ (D9: für jene, die noch Laufwerksnummern benutzen – würg!) Die Frage ist nun, wieviel Banken ihr für die Ramdisk benutzen könnt und wollt Um herauszufinden, wieviele Ban­ken zur Verfügung stehen, verwendet die folgende Formel:

((Gesamtzpeicher des Computers – 64K)/16)-1

Ich habe zum Beispiel einen 130 XE mit 320 KB, also ziehe ich 64K davon ab und komme auf 256K. Dies geteilt durch 16 ergibt ebenfalls 16. Davon ziehe ich noch 1 ab (die Bank die für SDX reserviert ist, wißt ihr noch?) und es bleiben 15 über. Man muß nicht alle verfügbaren Banken verwenden (Ich tue es nicht) aber vielleicht ist es genau das, was ihr wollt. Die Wahl liegt bei Euch!

Was wir bis jetzt haben ist:

  • USE BANKED
  • DEVICE SPARTA 16,16
  • DEVICE SIO
  • DEVICE ATARIDOS oder A:\DOS\ATARIDOS
  • DEVICE INDUS (oder eben nicht)
  • DEVICE CLOCK oder JIFFY
  • DEVICE RAMDISK

Eine letzte Bemerkung zu den Geräten: Macht Euch keine Gedanken darüber, ob Ihr den XEP80 -Treiber in das CONFIG.SYS aufnehmen sollt oder nicht Wenn Ihr jemals den XEP80 – Treiber für ir­gendein Programm brauchen solltet, könnt Ihr ihn von der Kommandozeile aus laden:

(A:)XEP80.SYS(RETURN)

Wenn Ihr ihn in das CONFIG.SYS aufnehmt, beschränkt ihr Euch nur bei den Programmen, die dann noch laufen.

Schritt 3: Das ‚SET‘ Kommando

Wenn Ihr nur mit Floppies arbeitet und keine Festplatte habt, dann laßt diesen Schritt aus. Aus uner­findlichem Grund braucht die Ausführung eines CONFIG.SYS, daß SET Kommandos beinhaltet, sehr lange, wenn es auf Floppy läuft. Von Festplatte aus geht das prächtig. Wenn Ihr mit Floppies arbei­tet, dann lest diesen Abschnitt trotzdem und legt die ‚SET‘ Kommandos,statt dessen in die Datei AUTOE­XEC.BAT.

PATH

Ihr könnt eine Pfad festlegen, nach dem SDX nach Dateien sucht Zum Beispiel könnt ihr auf Laufwerk 3 ein Unterverzeichnis mit dem Namen ‚DOS‘ erstellen und dortjedes Sparta DOS Kommando ablegen, das ihr findet. Wenn Ihr dann zum Beispiel in Eurem TEXTPRO Unterverzeichnis auf Laufwerk 1 seid und WDIR eingebt, dann erhaltet Ihr ein (breites?) Inhaltsverzeichnis, vorausgesetzt Ihr habt das File WDIR.COM in dem DOS – Verzeichnis. Ein solches Verzeichnis erhöht die Fähigkeiten Eures Systems beträchtlich. Und so wird es im CONFIG.SYS verwendet:

SET PATH=CAR:;C:>DOS>

Das ‚CAR:‘ veranlaßt SDX, zuerst dessen eigebautes Inhaltsverzeichnis (ROM-Disk), dann ‚C:>DOS> und danach das aktuelle Inhaltsverzeichnis, welches auch immer, zu durchsuchen. Man kann auch meh­rere Pfade angeben, sie müssen nur durch ein Se­mikolon (;) getrennt eingegeben werden. Zum Beispiel geht:

SET PATH=CAR:;C:>DOS>;A:>TPX>

PROMPT

Die Grundeinstellung beim SDX – Prompt muß eine der Dümmsten sein, die ich je gesehen habe-. Wenn mann wissen will, in weichem Verzeichnis man ist, muß man DIR eingeben. Es gibt einen besseren Weg:

SET PROMPT=$L:$P>

Dies ändert das DOS – Prompt in

C:>

Wenn man dann CD TPX eingibt, erhaelt man

C:>TPX>

Dies ist ziemlich offensichtlich ein viel informativeres Prompt und sieht dem MS-DOS Prompt sehr ähnlich.Wenn Euch MS-DOS zu abschreckend ist dann versucht das:

SET PROMPT=D$N:$P>

was in Anlehnung an das vorherige Beispile ergibt:

D3:>TPX>

Auf diese Weise kann man sich das Sparta DOS -Gefühl erhalten und sich trotzdem den Gebrauch erleichtern und die Fähigkeiten zu verbessern.

BASIC / CAR

Man kann auch angeben, wo die Dateien BASIC.SAV und CAR.SAV abgespeichert werden. Die meisten brauchen das vielleicht nicht, weil die Vorgaben für diesen Zweck recht gut sind, wenn die Ramdisk auf D9: liegt. Wenn man es aber unbedingt ändern will, dann geht zum Beispiel:

SET BASIC=A:>DOS>BASIC.SAV
SET CAR=A:>DOS>CAR.SAV

oder um sie auszuschalten

SET BASIC
SET CAR

Und nun zu einem Beispiel für CONFIG.SYS. Es ist das CONFIG.SYS, wie ich es auf meinem System benutze. Ich habe einen 130 XE mit 320K, eine 65 MB Festplatte, Express! Cartridge, 1050 mit US Doubler, eine normale 1050 und eine Happy 810. Und hier ist das CONFIG.SYS, daß ich für dieses Equipment nehme:

USE BANKED
DEVICE SPARTA 16,16
DEVICE SIO
DEVICE C:>DOS>ATARIDOS
DEVICE INDUS
DEVICE JIFFY
DEVICE RAMDISK I,7
SET CAR
SET PATH=CAR:;C:>DOS>
SET PROMPT=$L:$P>

Anpassung von SDX bei 64K

Da ich schon vorher alles über die Geräte und Kommandos gesagt habe, bin ich bei der Konfiguration auf 64K nicht so ausführlich.

DEVICE SPARTA OSRAM
DEVICE SIO
DEVICE ATARIDOS oder
DEVICE A:>DOS>ATARIDOS
DEVICE INDUS (wahlfrei)
DEVICE CLOCK oder
DEVICE JIFFY

Der Teil mit OSRAM befiehlt SDX die Verwendung des OS RAM für die Puffer usw. Danach die Geräte und die gewünschten ‚SET‘ Befehle (wenn man mit Festplatte arbeitet – wenn nicht, kommen die in die AUTOEXEC.BAT).

Das wärs! Larry Popa, 8-Bit Vizepräsident

(Falls Ihr noch nichts davon gehört habt: Larry war der 8-Bit Vizepräsident von HBO. Er war das, was wir für unseren 8-Bit Softwarespezialisten halten. Die Anleitung für SDX wird fortgeführt werden und wir hoffen auch in Zukunft auf andere softwarebezogene Artikel.)

Übersetzung aus dem Englischen: Erhard Pütz, den 6. Juni 1995, Ohne Gewähr

Nichts Neues ?

Armin Stürmer beklagte sich in einem Brief an den Atari Bit Byter User Club über den lapidaren Satz „Nichts Neues“, der immer wieder in den noch bestehenden Atari 8-Bit Publikationen zu lesen ist.

Er führt auf, daß es beim AMC-Verlag sehr wohl neue Hardware gibt:

  • Powerpad 3
  • Stereo Blaster PRO
  • Stereo Blaster PRO LC
  • Stereo Headphone Amplifier
  • Portverlängerungskabel
  1.   30 cm
  2.   60 cm
  3.  100 cm
  4.  200 cm

Port Converter für

  1. XE-Portverlängerung
  2. rechte Maustaste
  3. AMIGA Maus an XLIXE
  4. Koala Programme mit Maltafeinutzung
  5. Tausch von Maltafeltasten rechtsAinks
  6. Tausch von Paddle 0 und Paddle 1

Wir hoffen, diese Produkte im kommenden Magazin ausführlich vorstellen zu können. Wer schon jetzt weitere Infos haben will: Armin Stürmer, Blücherstr. 17, 65195 Wiesbaden, 0611-405611

Frankfurter Hardware

Von Thomas Grasel, Usergroup Frankfurt / Main.
Hallo ATARI-User!

Wieder ist ein Jahr vorbei und es geht in großen Schritten auf die nächste Jahreshauptversammlung (JHV) des ABBUC zu. Langsam wird es Zeit sich um Mitfahrgelegenheiten zu kümmern und evtl. Urlaub für den Samstag zu nehmen.

Auch die Usergroup Frankfurt / Main wird wieder mit einem Stand auf der JHV vertreten sein. Mitgebracht wird auch die ganze Hardwareproduktpalette. Da nur begrenzter Transportplatz zur Verfügung steht, kön­nen nur wenige Exemplare jedes Gerätes mitgebracht werden. Daher möchte ich jedem ABBUC-Mitglied die Möglichkeit geben jetzt schon die Produkte zu bestellen und sie dann auf der JHV entgegen zu nehmen und auch dort zu bezahlen. Das bietet für jeden Beteiligten Vorteile: Du brauchst keine Versandkosten bezahlen, und ich weiß was ich in welcher Menge mitnehmen muß.

Als Neuheit wird es ab der JHV’95 auch erstmals das 8­fach Digitalvoltmeter für den XL und PC zu kaufen geben. Der Preis steht aller­dings noch nicht endgültig fest, da zur Zeit noch einige Feinarbeiten ausgeführt werden.

Möchtest Du genauere Informationen zu einem der Produkte, dann schreib mir einfach. Liegt ein fran­kierter und adressierter Rückumschlag bei, dann wird jeder Brief binnen kürzester Zeit beantwortet

Bei Bestellungen, die auf der JHV abgeholt werden entfallen alle Versandkosten. Bitte gib das auf dem Bestellschein deutlich durch Liefertermin JHV’95 an! Hier noch eine wichtige Information für alle User, die das SIO2PC-Interface benutzen und noch keine Registrierung in den USA durchgeführt haben:

Ich werde versuchen eine Sammelregistrierung für die SIO2PC-Software zu organisieren, genauere In­formation an meinem Messestand auf der JHV!

ATARI-User im Großraunn Frankfurt / Main aufgepaßt!!

Da ich weiß, daß es hier einige User gibt, die Interesse an Messen haben möchte ich Euch die Möglichkeit einer Mitfahrgelegenheit nach Heden anbieten. Wer also nach Herten will und kein Auto hat oder eines hat aber nicht allein fahren will, soll sich möglichst schnell an mich wenden.

Bitte legt Eurem Schreiben einen frankierten Rückumschlag bei!

Im folgenden meine Preisliste für Bestellungen:

Artikel Bauart Versandgruppe Preis
S102PC­
S102PC­
SIO-Kabel
Modern-Kabel (2m, 25pol)
Autornafisches 2­
Autornafisches 2­
Automatisches 2­
Schaltnetztell für ATARI 8bit
Schaltnetztell nach
Schaltnetzteil für ATARI
Zusatzplatine für SNT incl.
Bauplan B514
Fertiggerät
Platine


Fertiggerät
Komplettbausatz
Platine
Fertiggerät
Fertiggerät
Platine (Epoxyd)
Platine
19 Seiten

II
I

II
II
I
III
III
I
I
II

40 DM
10 DM
10 DM
10 DM

100 DM
70 DM
10 DM
300 DM
auf Anfrage
20 DM
5 DM
0 DM

*nur in Verbindung mit einem Fertiggerät oder Bausatz **ohne Zusatzplafine (-5V,-12V)

Versandkostenpauschalen:

Versandgruppe

Vorauskasse

Nachnahrne

I

mit 1 DM frankierter Rückumschlag

II

5DM

15 DM

III

20 DM

30 DM

Anschrift:

Thomas Grasel
Dillenburgerstraße 61
60439 Frankfurt(Main)
Telefon 069/57751

Bankverbindung:
Frankfurter Sparkasse
BLZ: 500 502 01
Kontonr.: 0315007613

Demo-Programmierung Teil 1

Hallo Bit Byter, warum einen Kurs über das geheimnisvolle Demo­programmieren werden sich einige Mitglieder jetzt fragen. Nun die kreativste Arbeit am XL ist das Pro­grammieren (finde ich zumindest). Ich bin ein leidenschaftlicher Demo-Sammler und finde es in­teressant, wie sich die Dernos in den vergangenen Jahren verändert haben. Auch ich erlag dem Trugschluß so was nicht programmieren zu können. Ich dachte, irgendwie ist es ein wenig Zauberei und ich kann das nie. Auch benötigt man Assembler­Kenntnisse, die über das Normale hinausgehen. So fing ich an im Jahre 1990 meine ersten Grafik­Demos zu schreiben und zwar in Assembler.

Was sind Demos eigentlich?

Demos haben eigentlich keinen Sinn, sie sollen den Betrachter durch nie (?) dagewesene Effekte beeindrucken. Sie sind eigentlich kleine Kunstwerke, wie Videoclips. Daneben kann der Programmierer sein Können unter Beweiß stellen. Wir werden sehen, daß es meistens nichts mit Können an sich zu tun hat sondern einfach mit Cleverness.

Welche Arten von Demos kann man unterscheiden?

Wie in jeder Szene gibts es gewisse Fachbegriffe, die für bestimmte Effekte benutzt werden. Doch unterscheidet man auch die Arten der Demos, d.h. wie sind sie aufgebaut sind in ihrer Grundstruktur. Hier folgt nun meine Einteilung der Demos, die nicht umbedingt vollständig ist:

  • Screen: Mit Screen bezeichnet man einen kompletten Bildschirmaufbau mit allen Effekten. Nach Beendigung durch den Betrachter, mei­stens per SHIFT oder START kehrt das Demo wieder ins DOS zurück oder macht einen Warmstart. Bsp. meistens die Titelbilder auf den Magazin-Disketten.
  • Intro: Intro werden oft kurze Demo-Screens oder Demos genannt. Wie der Name schon sagt, dienen sie als Einführung in den Hauptteil. Sie sind meistens nicht so aufwendig und wurden meistens in kurzer Zeit geschrieben. Dienen oft nur zum Installieren des Entpackers, der Lade routine, der Ausgabe des Titels und einer Please wait loading… -Mitteilung.
  • Outro: Gegenteil von Intro. Viele Demoprogrammierer und Gruppen verwenden ein Outro. Es ist als kleines Demo zum Schluß gedacht, vielleicht mit Credits (s.u.). Sonst gilt das gleiche wie für Intro. Danach wird entweder ein Kaltstart oder zumindest ein Reset ausgeführt.
  • Mainpart, Hauptteil. Oft eingekreist durch ein Intro und Outro. Aber häufig fehlt das Outro. Hier werden alle Effekte gezeigt die der Programmie­rer dem Betrachter offenbaren möchte.
  • Mega-Derno: Viele Demogruppen sc rei­ben nicht nur einen Effekt Und da der Haupt­speicher des Computers begrenzt ist, lagert man die Effekte auf Diskette aus. Fast immer wird mindestens eine Diskettenseite belegt. Solche Demos müssen gebootet werden. Ein Mega­Demo besteht aus mehreren Screens oder Parts. Nach dem Beenden durch den Betrachter wird der nächste Teil der Demo von Diskette geladen. Bei d
    en 16-Bittern hat eine Mega-Demo meistens ein Menu, durch welches man die verschiedenen Paris auswählen kann. Kommt aber bei XL­Demos sehr selten vor. Die Reihenfolge der ein­zelnen Teildemos ist meistens vorgegeben,
  • Menü: Es gibt verschieden Arten von Me­nüs. Die ersten Menüs waren aufgebaut wie das Dos 2.5 Menü. Durch A wurde Part 1 geladen, durch B Part 2 usw. Solche Menüs sind praktisch, aber langweilig. Die Demogruppen wollten den Betrachter mehr in die Demo einbeziehen und mehr Spaß vermitteln. So kamen die Game­Menüs auf. Per Joystick oder Cursortasten steu­ert der Betrachter wie in einem Videospiel eine Figur durch ein Labyrinth und führt es zu Türen oder Höhlen, hinter denen sich die einzelnen Demos befinden. Somit waren der Gestaltung von Menüs keine Grenzen mehr gesetzt Ein sol­ches Menü habe ich aber bis heute nicht auf dem XL gesehen!
  • Multipart. Multiarts kamen auf den 16-Bittern (Amiga, Atad ST) in Mode. Multipart heißt ja ei­gentlich übersetzt daß das Demo mehrere Effekte bzw. Screens hat. Was unterscheidet dann ein Multipart-Derno von einer Mega-Demo? Meistens ist ein Multipart keine Bootdiskette, sondern ein einzelnes File, das entweder vom Dos aus oder von einem Gamedos-Lader geladen wird. Ein Multipart ist also ein File, das mehrere Effekte enthält, die nacheinander gezeigt werden. Sie stehen komplett im Speicher und in der Regel wird nichts mehr nachgeladen. Auch hat der Be­trachter oft keine Möglichkeit zum nächsten Effekt zu springen, sei es durch einen beherzten Druck auf Space, Shift oder Start Multiparts sind auf je­denfall schwerer zu programmieren, da ja der komplette Speicher als Grenze dient, der Pro­grammcode länger ist und damit mehr Speicher benötigt Der Programmierer muß genau wissen, wo er weichen Effekt im Speicher hat Je mehr Effekte er unterbringen kann, umso effektiver hat er den Speicher genutzt und letztendlich abwechslungsreicher ist es. Ein Grund für das Aufkommen von Multiparts könnte gewesen sein, daß die Computer vermehrt mit Festplatte ausgestattet sind und wie soll man eine Bootdiskette (egal ob Amiga, ST oder PC), die noch für das jeweilige Dos unleserlich ist (wie auf dem XL,ST, Amiga), auf Festplatte installieren bzw. wie soll ein solche Mega-Demo dann auf Festplafte laufen?

Beispiele auf dem XL

Intros oder einzelne Demos: Titelbilder vom Abbuc­Magazin

Megadernos. Das Halle-Projekt, HARD-Megademo, Slight-Megadenlo,The Top 3, Sweet Illusions von den Shadows

Multiparts: The Top l+2, Shake-Demo, Just-Fancy­Demo

Oft werden Multiparts und Megademos kombiniert z.B. bei Shadows-Megademo. Der Effekt 1 -Part ent­hältja mehrere Effekte~ obwohl das Demo eine Me­gaderno, ist.

Aus welchen Mitgliedern besteht eine Demo Gruppe?

Diese Frage ist schwer zu beantworten, da jede Demogruppe ihren eigenen individuellen Aufbau hat. Folgende Bezeichnungen haben sich eingebürgert:

=> Coder. Sind Programmierer, die eigentliche Denkzentrale einer Demogruppe. Sie programmieren nächtelang an neuen Effekten und Routinen.

=> Grafiker, Grafiker haben meistens keine Ah­nung vom Programmieren, sind aber für Logos, Grafiken, Zeichensätze usw. verantwortlich.

=> Musiker. Sie schreiben den Demo-Screens passende Musik auf den Leib. Wie in einem gu­ten Film, sollte die Musik zur Action passen, d.h. z.B. langsame Musik bei einem schnellen Grafik­demo hat wohl wenig Sinn. Kommt aber auf den Geschmack an und was für eine Stimmung er­zeugt werden soll.

=> Swapper.- Sie sind für die Verbreitung der De­mo zuständig. In den Zeiten der Raubkopiererei, als Demos eigentlich nur von den Raupkopierern geschrieben wurden, um Intros; für ihre Cracks zu haben, haften Swapper die Aufgabe, die Kontakte zu den Tauschpartnern zu pflegen.. Heute aber so gut wie nicht mehr vorhanden, da die Demo-Szene sich von der Raupkopiererszene, Gott sei Dank, gelöst hat. There is no coding like demo coding!

Natürlich können mehrere Aufgaben in einer Person vereint sein. Sollte man allein Programmieren (so wie ich), stellt sich oft die Frage, wo bekomme ich z.B. Musikstücke oder Grafiken her. Haben sich mehrere Leute zusammengeschloßen, die unterschiedliche Aufgaben wahrnehmen, so wird die Demoprogrammierung auf jeden Fall einfacher und weniger zeitaufwendiger, die Demos sehen proffesioneller aus.

Die einzelnen Begriffbestimmungen für die jeweili­gen Effekte spare ich mir hier im Moment noch auf Sie sind meistens aus dem Englischen abgelei­tet und bezbichnen die Art des Effektes, das Aussehen oder die Programmierung (z.B. Plasma­Effekt soll eben Plasma darstellen). Dabei sind der Phantasie keine Grenzen gesetzt.

Kommen wir nun endlich zum eigentlichen Thema, dem Demoprogrammieren. Folgende Tools sollte man haben- Einen Assennbler, von dem man die Start-Adresse weiß oder zumindest resetfest ist Turbo-Basic, mit dem man seine Tabellen berechnet bzw. Routinen zuerst testen kann. Es ist einfacher erst einen Algorithmus in Basic zu schreiben und diesen dann in Assembler umzusetzen. Mehr benötigt man eigentlich nicht Ein Malprogramm wie z.B. Rambrandt XL wäre von Vorteil. Einen Zeichensat­zeditor für eigene Fonts. Was man aber unbedingt benötigt, ist eine genaue Beschreibung der XL Hardware, vor allem des Antics und des GTIAs. Ich benutze bzw. kann folgendes Buch schon auswen­dig, nämlich von Data Becker „Atari intern“. Und ganz wichtig ist Kreativität Grundkenntnisse in Assembler sollten vorhanden sein. Ein Demo besteht meistens nicht mehr als aus LDAs und STAs !!! (in Basic: Peeks und Pokes)

Wie geht man nun an ein neues Demo heran. Man könnte sich auf ein Blatt Papier eine Skizze machen, welchen Effekt man darstellen möchte. So habe ich das Titel-Demo für das Magazin 42 entwickelt Die Idee dazu entstand in einer Vorle­sung. Ich wollte, fasziniert durch die Pixel-Roufinen anderer Dernos, auch eine schnelle Plot-Routine schreiben. Wie geht man aber an die Sache heran. In Assennbler habe ich ja keine Hilfsbefehle wie in Basic, so scheidet also ein Plot-Befehl aus, genauso wie umfangreiche Berechnungen. Die Idee war, das vom oberen Bildschirmrand Pixel herunterfallen sollten. Ich stand nun vor zwei Problemen: Die Pixel­roufine sollte schnell sein, damit kein Geflackere auftritt und die Pixel sollten wie Gummibälle reali­stisch nach unten anhand einer physikalischen For­mel fallen. Da man in Assernbler keine Funktionen an sich hat, gab ich die Idee
vorerst auf.

Doch man könnte in Turbo-Basic eine Tabelle berechnen, die die Y-Koordinaten anhand einer physi­kalischen Formel berechnet und im RAM ablegt Meine Pixel-Routine mußte also nur die Werte aus dem Ram holen und die Pixel setzten. Das war ei­gentlich das ganze Geheimnis.

Diese Tabelle war schnell berechnet, nun folgte das eigentliche Problem, nämlich eine schnelle Pixelroutine zu schreiben.

Meine Pixel-Roufine entstand zu erst im Kopf Ich hafte schon im Jahre 1990 (glaube ich) eine Routine geschrieben. Ich war richtig stolz, sie war zwar in Assembler entwickelt worden, was nicht heisst dass sie schnell war. Ich hantierte mit LSR und ASL, was auch nicht gerade zur Geschwindigkeit beitrug. Dann kam mir aber die Idee, die ganzen Berechnungen schon vorher für jede Y­Koordinate durchzuführen und in einer Tabelle zu speichern. So konnte ich einfach die Y-Koordinate als Offset für eine Tabelle benutzen, die den Wert für den Bildschirmspeicher enthielt. Die X­Koordinate wurde als Offset für die Bildschirmadresse benutzt. So mußten auch keine Bildschirm­Adressen-Berechnungen stattfinden.

Als Grafikstufe wähle ich Gr.8. Die Auflösung beträgt 256 x 128 Pixel. Diese Werte passen hervoragend zum Konzept (256 paßt genau in ein Register).

Hier nochmal genauere Oberlegungen, wie ich ein Pixel setze:
Eine Bildschirmzeile in Gr.8 besteht aus 40 Bytes. Da ich aber nur 256 Pixel in X-Richtung darstellen wollte, mußte ich den Screen verkleinern. Dabei hilft der Antic. Durch ein simplen LDA #33, STA $d400 schalte ich auf 256 Pixel-Darstellung um. In Basic läßt sich das durch POKE 559,33 testen. Das Bild ist auch in der Mitte vom Schirm mit einem etwas größeren Rand rechts und links. Eine Zeile besteht jetzt aus 32 Bytes.

Um ein Pixel zu setzten, muss man zuerst wissen in welchem Byte das Pixel zu setzen ist. In Gr. 8 be­steht ein Byte aus 8 Pixel, d.h. jedes Bit repräsen­fiert ein sichtbares Pixel.

Folglich erhält man das Byte, indem man die X­Koordinate durch 8 teilt. (Kommastellen vernachläs­sigen!) Man multipliziert diesen Wert nun wieder mit 8. Nun zieht man von der X-Koordinate diesem Wert ab und erhält die Nr. des zu setzenden Pixels. An­hand von einer Tabelle ermittelt man den Wert, den man in das Bildschirmram schreiben muss. Die Bildschirmzeile erhält man, indem man die Y-Koordinate mit der Zeilenlänge multipliziert (hier mit 32, da eine Zeile 32’Bytes hat). Wer will kann dies anhand des Taschenrechners mal ausprobieren, hier ein kleines Beispiel:

Die Routine soll ein Pixel an der x-Koordinate 83 und an der y-Koordinate 50 setzen. Gehen wir nun an­hand der obigen Ausführungen vor. 83 geteilt durch 8 ergibt 10,375. Wir vernachlässigen die Nachkommastellen, d.h. wir erhalten den Wert 10. Jetzt wissen wir, daß wir in das 10. Byte in der noch zu ermittelnden Bildschirmzeile einen Wert schreiben müssen. Jetzt aber welchen Wert 7. Wir multiplizieren 10 wieder mit 8 und erhalten 80. Dieser Wert stellt die x-Koordinate des 10. Bytes dar, da 1 Byte 8 Bit bzw. hier Pixel hat. Jetzt ziehen wir 83 von 80 ab und erhalten als Ergebnis 3. Diese 3 sagt uns, wir müssen das 3. Bit von links setzen. Welchen Wert haben aber die einzelnen Bits? Anhand einer Tabelle ermitteln wir nun den Wert, den wir in das Bild­schirrn-Ram schreiben müssen.

Die Tabelle lautet 128,64,32,16,8,4,2,1. Der 3. Wert von links ist folg­lich 32. Jetzt haben wir den Wert, aber uns fehlt noch die richtige Bildschirmzeile. Deren Adresse wird in unserem Beispiel ermittelt, indem wir y­Koordinate 50 mit 32 multiplizieren, da eine Bild­schirmzeile 32 Bytes breit ist (32*8 Pixe]=256 Pixel pro Bildzeile). 50*32 ergibt 1600, d.h. wir müssen 1600 Bytes zu der Anfangsadresse des Bildschirm­Rams dazuaddieren. Zu dieser Adresse, die ja die Anfangsadresse der 50. Zeile ist, zählen wir noch die oben ermittelten10 dazu und haben die gesuchte Adresse. In diese Adresse schreiben wir den Wert 32 und sofort erscheint unser Pixel an der Koordina­te 83,50. Da aber Multiplikationen in Assembler recht langsam und kompliziert sind, könnte man doch schon vorher die Anfangsadressen jeder Bildschirm­zeile in einer Tabelle ablegen, getrennt nach Low­und Hi-Byte (hier scrtabl).

Nun die alte Routine aus dem Jahre 1990:
CLC                                ;2      Carry-Bit löschen wegen LSR+ASL
LDA XPOS                     ;3      X-Koordinate
LSR                                 ;12     ;2 durch 8 teilen (LSR)
LSR                                 ;12     ;2
LSR                                 ;12     ;2
STA BYTE                      ;merken;3 jetzt hat man das gesuchte Byte
ASL                                 ;*2     ;2 im Sereen-Ram. Dieses wird wie­
ASL                                 ;*2     ;2 der mit 8 multipliziert (ASQ
ASL                                 ;*2     ;2
STA MERK                     ;merken;3
SEC                                 ;2 Carry-Bit setzten wegen SSC
LDA XPOS                     ;3 Xpos-Byte=Nr. des Pixels
SBC MERK                    ;3
TAX                                ;2      Nr. ins X-Register als Offset
LDA PIXTAB,X     &
nbsp;       ;4    Wert aus der Tabelle holen
 
STA PIXEL                    ;3
LDX YPOS                    ;Y-Koordinate       ;3
LDA SCRTABL,X         ;bildschirrnadresse aus Tabelle;4
STA VO                         ;3
LDA SCRTABH,X         ;4
STA VO+II                     ;3
LDY BYTE                     ;OFFSET FOR ZEILE                           ;3
LDA (VO),Y                   ;Wert aus Blidschirrn-RAM holen                           ;5
ORA PIXEL                    ;und mit pixel verknüpfen                             ;3
STA (VO),Y                    ;wieder ins RAM zurück                                ;6
RTS                                 ;6
                   SUMME TAKTZYKLEN             ;80

PIXTAB DFB $80,$40,$20,$10,$08,$04,$02,$01

Zur Erinnerung: Ein Byte hat 8 Bit (kein Scherz!!!): Jedes Bit representert ein sichtbares Pixel.

     Dual                                Hexadezimal %00000000                                  ;$00 %10000000                                  ;$20 %00010000                                  ;$10 %10000001                                  ;$81

Pixtab enthält also die Werte, die in den Bildschirm geschrieben werden müssen, damit bestimmte Pixel gesetztwerden. Kurz nochmal der Aufbau des Bildschirmrams in Gr.8: Anfangsadressen der Bildschirmzeilen werden in ei­ner Tabelle abgelegt Y-Wert:< ——— x-Wert ——– > (32 Bytes=256 Pixel)

1. Zeile:$3000 00 00 00 00 00 00 00 00 00 00 00 00 00  2. Zelle:$3020  3 Zeile:$3040  4. Zeile:$3060 

Man könnte nun staftjedesmal diese arithmetischen Operationen (asi+Isr) und die Pixelermitilung neu zu berechnen, diese schon vorab in einer Tabelle für jede mögliche x-Koord’nate durchführen und in Tabellen ablegen. Es genügt somit anhand der x­Koordinate den jeweiligen Wert für den Zeilenoffset und das Pixel aus den Tabellen zu holen. Dies kostet zwar Speicherplatz, aber es läßt sich einiges an Rechenzeiteinsparen.

So sieht die neue Routine’95 aus:

init        jsr tabinit;vorher natürlich die Tabellen berechnen   plot Icix xpos                                              ;Koordinaten stehen in xpos,ypos              ;3      [da bytetab,x                                         ;in welches Byte muß Pixel          ;4      sta byte                                                 ;merken ;3      Ida pixtab,x                                           ;welches Pixel setzen               ;4      sta pixel                                                 ;merken ;3      ldx ypos                                                ;3      Ida sortabl,x                             &n
bsp;            ;Screenadresse aus tabelle          ;4     sta v0                                                     ;low-byte                ;3     Ida seitabh,x                                            ;4     sta vo+I                                                  ;hi-byte  ;3     Idy byte                                                  ;3     Ida (v0),y                                                ;5     ora pixel                                                  ;3     sta (v0),y                                                ;ab damit ins sereen-ram          ;6     rts                                                           ;das war's              ;6                       SUMME TAKTZYKLEN                ;57­ tabinit ldx #0                                                 Hier werden die Tabellen vorbereitet     Ida #0                                                      ;aus Sicherheitsgründen alles auf 12     sta scrtabl,x           ;0 setzen (ich trau dem Entpacker nicht)     sta sertabh,x     sta bytetab,x     sta pixtab,x     inx                                                          ;256 mal     bne 12 

Ida #scradr.1                                        ;Screen-adresse für
sta vo                jede Zeile in die
Ida #scradrh                                         ;Tabelle sortabl,h
inx                                                        ;Für 256 Zeilen,(dargestellt werden nur 128)
    bne 13 sta v>I ;speichern, damit
    ldx #0                                    ;der Plot schneller 13 davon; lst
    sta sortabl,x             ;In dieser Tabelle stehen die
    sta vo+I      ;Anfangsadressen der Bildschimizeilen
    sta sortabh,x                                                        ;getrennt in Low- und Hibyte
    clc
    Ida v0
    ado #32       ;Zellen-Offset (32 Bytes pro Zeile)
    sta vo
    Ida v>I
    ado #0
    sta vo+I
    ldx #0                    ;Byte Tabelle vorbereiten
14                                                            txa           ;fürjedex-posifion.
    clc                                  ;Carry-Bit löschen
    Isr a                                 &nbs
p;    ;Xpos/8 ergibt
    sr a                                     ;Spalten-offset
    sr a                 ;- 3 mal nach rechts schieben
sta bytetab,x ;In welchem Byte Pixel zu setzen ist
    inx                                             ;bis xpos=255
    bne 14
    ldx #0                           ;Pixel-Werte vorbereiten
15 [da bytetab,x ;diese werden direkt (später durch Plot)
clo              ;in den Bildschirm geschrieben
asl a                                  ;*2 Bytewerr8
asl a                                                 ;*2
asl a                                                 ;*2
sta byte
sec                                      ;Subtraktion
txa                       ;Xpos-Bytepos=Pixelnr.
sbc byte
tay                          ;merken in y-register
     Ida pixwerty ;Pixel-Wert
     sta pixtab,x ;in Tabelle
     inx
     bne 15
     rts
pixweit DFB 128,64,32,16,8,4,2,1

Wie man aus der Summe der Taktzyklen erkennen kann, ist die zweite Routine schneller, was zur Folge hat daß mehr Pixel pro VBL dargestellt werden kön­nen, ca. 35% mehr. Es lassen sich weitere Ge­schwindigkeitsoptimierungen vornehmen, wie z.B. statt STA (V0),y könnte man die Werte direkt in den Code statt in VO schreiben.

Diese Routine setzt jetzt Pixels an jeder beliebigen Koordinate. Eine Tabelle mit den fallenden Y-Werten wurde auch schon berechnet Ablaufen soll der Effekt folgendermaßen: Zufällig wird ein Pixel in der ersten Zeile gesetzt Danach wird die Y-Positionen jede 1/50 Sekunde verändert indem die Routine den neuen Y-Wert aus der Tabelle holt Das alte Pixel wird gelöscht. Das Löschen kann durch die gleiche Routine erreicht werden, man verwendet statt „ora pixel“ eben .and pixel“ und eine andere Tabelle für die Pixelwer­te. Sie enthält die Werte zum Ausmaskieren von Bits. Die Plot-Roufine soll erstmal mit einem Pixel laufen, wenn dies klappt wird sie ausgedehnt auf max. 255 Pixel. Im Demo steigt die Zahl der fallenden Pi­xel auf 96 kontinuierlich. Hier die kleine Routine für ein Pixel:

Fallende Pixel Entwicklungstext; (c) 02.05.95

phase = Variable, die angibt, was mit dem Pixel gerade ge schieht.
Phase = 0 : Zufällige X-Position ermitteln (0-255) mit’LDA 53770′
Phase = 1 : Zähler auf 0 setzen, Phase auf 2 setzen
Phase = 2: Zähler ist Offset für die Tabelle mit den Y-Werten
In dieser Phase wird das Pixel jeden VBL bewegt bis Pixel aus dem Bildschirm’fällt“. Zähler wird jeden VBL um 1 erhöht.

Ida #0
sta zaehler
Ida 53770  ;Zufallszahl holen
sta xpos
loop                                ldx zaehler
[da ypostabx ;Werte aus Tabelle holen
sta ypos   ;)ffl ist bereits gesetzt
jsr plot      ;Punkt setzen
inc zaehler              ;Zähler erhöhen
Ida zaehler
beq exit     ;zaehler–0 (=255)?

exit Ida #0 sta phase ;neue Phase rts

Diese kleine Routine gilt nur für 1 Pixel. Erweiterbar ist sie auf max. 256,indem man eine Zähl-, Xpos­und Phasentabelle einführt (für jedes Pixel). Statt Ida zaehler‘ nun Ida zaehltab,x“ usw.

Jetzt hat man den Grundstock für eine Demo. Auf der Magazindiskette ist ein Beispiel-Source-Code, bei dem zufällig die Pixel herunterfallen.

Karolj Nadj
Maximilanstr. 153
75172 Pforzheim

Cracking the Code – Teil 5

Übersetzt für den Atari Bit Byter User Club von Alfons Klüpfel

Wir sind jetzt soweit, daß wir mit ein paar praktischen Sachen beginnen können. Wir bedienen uns jetzt eines Assemblers (mit Assembler ist immer ein Programm gemeint wie z.B. der Bibo-Assembler, Atmas oder, nach allem, was ich gehört habe, noch besser. Thorsten Katwoths „Makro-Assembler“ A.K.) und lassen einfach ein paar simple Beispiele ablaufen. Es empfiehlt sich, mit derart einfachen Programmen ein bißchen herumzuexperimentieren. Laßt Euch nicht entmutigen, wenn nicht alles so klappt, wie erwartet. Aus Fehlern kann man auch eine ganze Menge lernen. Und wenn’s nur das ist, daß man ein Programm erst mal abspeichert, bevor es abstürzen kann!

Warum ein Assembler?
Wir wissen schon, daß jede Instruktion mit einem Buchstaben-Wort versehen ist – Fachbegriff: Mnemonic – das einem beim Merken helfen soll. Im letzten Artikel bekamt Ihr eine ganze Liste dieser Mnemonics (z.B. LDA, STA usw.) und der zugehörigen OpCodes.

Unter dem Begriff „von Hand assemblieren“ versteht man das Konvertieren eines Assemblerprogrammes in ein Maschinenspracheprogramm unter Benutzung dieser Tabelle. Klingt ja ganz gut! Aber dieses Vorhaben wird erheblich da
durch erschwert, daß die meisten Mnemonics in der Tabelle unter verschiedenen Einträgen zu finden sind, d.h. daß sie je nach Adressiermodus einen ganz anderen Maschinensprache-Wert bekommen. (z.B. wird LDA im Immediate Mode als A9 konvertiert, im Zero-Page- Mode als A5 und im Absolute Mode als AD usw.) (Vergl. Kap. 4, Tab. 1; A.K.) Erschwerend kommt hinzu, daß alle Zahlen für den Computer in eine einzige Zahlenart konvertiert werden müssen, sagen wir mal in Dezimalzahlen. Es gibt noch eine Reihe weiterer Gründe, warum das „Per-Hand-Assemblieren“ recht mühsam und langwierig ist, ganz zu schweigen von den vielen Fehlermöglichkeiten, wenn man mit Page-Zahlen arbeitet.

Assembler beseitigen all diese Probleme, weil das Konvertieren von Assemblersprache (Mnemonics, Labels etc.) in Maschinensprache praktisch durch eine einzigen Befehl erledigt wird. Assembler haben aber noch viel mehr Möglichkeiten als bloß Assemblersprache zu konvertieren. Sie bieten einige Erleichterungen beim Entwickeln von Programmen. Die meisten Assembler haben einen mächtigen Editor (eine Art Textprogramm zum Erstellen und Bearbeiten des Quellcodes=Sourcecodes, also des Programms in Assemblersprache, A.K.) ein „Debug-“ oder „Moniior-Programm“, das es ermöglicht, sich die Speicherstellen (Adressen) anzusehen, Maschinensprache zu disassemblieren (also wieder aus der Maschinensprache in die Assemblersprache zurückzukonvertieren, A.K.) und eine Reihe weiterer nützlicher Hilfen, mit denen man das eigene Programm testen und korrigieren kann. Selbst wenn man nur ein paar kleine Subroutinen schreiben will, wird man feststellen, daß dies mit einem Assembler viel komfortabler geht. Ich rate Euch daher, etwas Geld in einen der verschiedenen Assembler zu investieren, falls Ihr Euch mit den folgenden Beispielen beschäftigen wollt. Langfristig wird Euch das einiges an Zeit und Frust ersparen.

Die Programmbeispiele dieser Artikelserie beziehen sich auf die Atari-Assembler-Editor-Cartridge, die vielleicht die verbreitetste ist Sie ist nicht das Beste, aber einfach einzusetzen und ganz gut verständlich. Abgesehen von der Geschwindigkeit, in der sie Quellcodes assemblieren, unterscheiden sich andere Assembler nur unwesentlich bzw. sie bieten Möglichkeiten, die nur für einen erfahrenen Programmierer von Nutzen sind, wie z.B. Makros. Einen ausgezeichneten, nicht kommerziellen Kompromiß stellt in dieser Hinsicht USERCOMP dar. Allerdings ist er in der Hinsicht etwas eingeschränkt, daß die meisten Möglichkeiten fehlen, die man gemeinhin mit dem Begriff Assembler verbindet Jedoch akzeptiert er alle Mnemonics und ist zum Schreiben kurzer Routinen oder zum Experimentieren sehr gut geeignet. Für den Preis von £1 oder gar umsonst kann man sicher nicht mehr verlangen!

Get The Fields In File! Bringt mal schön alle Felder auf die Reihe!
Es gibt im Zusammenhang mit Assembler zwei File-typen: das Quell- = Sourcefile und das Objectfile (das endgültige, anwendbare Maschinensprache-File A.K.). Beide werden auf Disk oder Cassette ab-gespeichert. Das Quellfile ist das Programm in Assemblersprache, das mit Hilfe des Editors erstellt und bearbeitet wird. Es entspricht in etwa der Art und Weise, wie man ein BASIC-Programm speichert und lädt, außer daß ein Assemblerprogramm als reiner Text, also genau wie eingetippt, abgespeichert wird (was bei BASIC in etwa einem LIST-File entspräche A.K.).

Will man das Programm als reinen Maschinencode haben, gibt man dem Assembler den Befehl, das Quellfile zu kompilieren. Das Quellfile wird dann vom Assembler gelesen, und danach wird von diesem ein Objectfile erzeugt (später z.B. an dem Extender .OBJ erkennbar. A.K.). Es handelt sich dann um ein Programm in reiner Maschinensprache, das man vom DOS aus (Funktion L) in den Computer laden könnte. Macht Euch klar, daß alle Änderungen an Eurem Programm im Quellfile vorgenommen werden sollten. Dieses wird dann erneut kompiliert, was eine Update-Version des Objectfiles erzeugt, die dann wieder lauffähig ist An dieser Stelle, sollte der grundsätzliche Unterschied zwischen einer (Hoch) Sprache wie BASIC und Assembler klar sein: BASIC ist eine Interpretersprache (Interpreter = Übersetzer!) und führt direkt die Befehl des Quellfiles aus, Zeile für Zeile. (Damit der Computer das kann, braucht er aber einen „Übersetzer“, der ihm den Hochsprache-Code sozusagen simultan in Maschinensprache „übersetzt“. A.K.) Aus diesem Grund muß BASIC im Speicher vorhanden sein, sonst könnte kein Programm laufen. (Zur Erinnerung: Schalten wir unseren XL ein, so wird automatisch das eingebaute BASIC aus einem entsprechenden ROM-Baustein auf der Mutterplatine in den Arbeitsspeicher – RAM -geladen und belegt den Platz „unter dem OS“. Der Computer meldet sich dann mit READY. Jetzt können wir BASIC-Befehle eingeben und ausführen lassen oder, falls ein DOS geladen ist, ein BASIC-Programm von der Disk laden und laufen lassen; LOAD und RUN sind bekanntlich BASIC- Befehle! Booten wir mit gedrückter OPTION-Taste, wird das BASIC nicht geladen, d.h. wir bekommen keinen blauen Bildschirm mit der Meldung READY. Ohne Diskstation geht der Computer in das SelbsttestMenu, mit Diskstation und DOS-Disk geht er ins DOS-Menu etc. – Und TURBO-BASIC? Nun, da wird das eingebaute BASIC natürlich nicht geladen, stattdessen eben das TURBO-BASIC von Disk o.ä., d.h. wir haben einfach ein anderes BASIC im Speicher. Und das meldet sich ebenfalls mit READY! Und das hat dann natürlich seinen eigenen BASIC-Interpreter eingebaut. TB-Programme laufen bekanntlich nicht unter dem normalen BASIC. Und werden sie gar kompiliert, braucht man immer das RUNTIMEProgramm, das wieder eine Art Interpreter darstellt. A.K.)

Ein Assembler ist eine Computersprache. (nochmal zur Klärung des Wortes kompilieren: Der Programmcode, der Programmtext wird zu reiner Computersprache gepackt; pule“ = Haufen; im Falle Assembler wir der Text in reine Maschinensprache umgewandelt, wie später erklärt wird.) Assembler arbeitet mit zwei Files, dem Quellfile und dem Objectfile. Er wandelt alle die Festlegungen und Aussagen aus dem Sourcefile in Maschinensprache im Objectfile um, die direkt vom Prozessor ausführbar ist Aus diesem Grund muß der Assembler nicht im Arbeitsspeicher (RAM) resident (vorhanden) sein, wenn man das Objectfile laufen lassen will.

Schauen wir jetzt nach der Struktur des Quellfiles im einzelnen (also nach dem Quelltext im Editor, noch nicht kompiliert. A.K.) Das File besteht aus Textzeilen. Jede Zeile enthält Felder mit Buchstaben. In Assembler besteht ein Feld aus einem oder mehreren zusammenhängenden Buchstaben. Jedes Feld ist durch ein oder mehrere Leerzeichen vom nächsten getrennt – so wie die Wörter in einem Satz voneinander getrennt sind. Das erste Feld ist normalerweise die Zeilennummer. Sie hat auf den Assembler keinerlei Auswirkung.

Zeilennummern dienen in den meisten Editorprogrammen dazu, beim Eingeben und Bearbeiten die Übersicht zu behalten bzw. schnell an bestimmte Programmteile zu finden. Vom Assembler werden sie weder beachtet noch benutzt Daher handelt es sich, wenn wir vom ersten Feld sprechen, nicht um die Zeilennummer, sondern um das erste Feld nach der Zeilennummer. Wird nicht nicht numeriert, handelt es sich um das erste Feld der Zeile. Das hängt davon ab, welchen Editor man benutzt. Eine Zeile kann ein bis vier verschiedene Felder enthalten:

Das Label-Feld
Ein Label beginnt immer mit einem Buchstaben und kann danach jede beliebige Kombination aus Buchstaben und Ziffern enthalten, die zusammen den „Namen“ des Labels bilden – ähnlich wie bei einem Variablennamen in BASIC, außer daß die Länge sechs Zeichen nicht überschreiten darf. Labels werden benutzt, Zahlenwerte darzustellen; hat man einmal einem Label einen Wert zugeordnet, dann wird an jeder Stelle, an der dieses Label benutzt wird, dessen Wert eingesetzt und berücksichtigt.

Das erste Feld einer Zeile ist für einen Labelnamen reserviert. – Wie man so ein Label einsetzt, werden wir gleich sehen.

Das Operation-Feld
Das zweite Feld heißt das Operation-Feld (englisch operation = das, was getan wird; also: wo was getan wird). Dorthinein werden die OpCode-Mnemonics geschrieben, wie etwa „LDA“. Scheinoperationen, auch als Assembler-Direktiven bezeichnet, werden ebenfalls hier eingetragen. Sie werden benutzt, die Arbeit des Assemblers beim Kompilieren des Source-Codes zu kontrollieren.

Das Operanden-Feld
Operanden werden ins 3. Feld geschrieben. Sie sind die Daten, die zum Operation-Feld gehören (a/so „LDA“ = LoaD Akkumulator im Operation-Feld mit „Operand xyz“ im Operanden-Feld. A.K.) Die Art der Operation bestimmt, ob ein Operand notwendig ist oder nicht. Jedes Label, das vorher definiert worden ist (Name im ersten Feld) kann im Operation-Feld benutzt werden. Der Effekt ist derselbe, als würde man den entsprechenden Wert des Labels im Klartext reinschreiben. Labels sind also nichts anderes als eine Art Ersatz für einen einmal festgelegten Wert, bzw. sie sind eine Konstante. (Wir erinnern uns an die Schule: Das Zeichen r – pi ist ein Label für die Konstante 3,14 etc. A.K.)

Das Kommentar-Feld
Kommentare sind einfach ein Reihe von Buchstaben und Zeichen, die Anmerkungen zu den Operationen des Programmes (das vor dem Strichpunkt steht) zum Inhalt haben, ähnlich wie die REM-Zeilen im BASIC. Üblicherweise beginnt der Kommentartext nach einem Strichpunkt (Semikolon). Der Rest einer Zeile nach einem Strichpunkt wird vom Assembler ignoriert Das Kommentarfeld ist insofern eine Ausnahme, daß es an jeder beliebigen Stelle in einer Zeile anfangen kann. Kommentarzeilen können eine komplette Zeile umfassen oder auch an einem Zeilenende beginnen. Kommentare helfen zu beschreiben, was das Programm bewirkt Sie sollten recht freizügig und durchgängig im Programm benutzt werden, damit man sich parallel zum Programm eine Dokumentation erstellt Es kommt immer wieder vor, daß man ein altes Programm in einer Schublade findet. Ein deutlicher Kommentar erweist sich dann als unbezahlbar, wenn man ein bißchen verstehen will, was das Programm tut und wie!

Und es war Ordnung auf den Feldern
Wenigstens ein Leerzeichen muß die diversen Felder voneinander trennen. Benutzt man einfach die TAB-Taste, um zum nächsten Feld zu gelangen, spart man sich das Problem, den nächsten Feldanfang exakt anzusteuern und bekommt außerdem ordentliche, übersichtliche Spalten. Das folgende Beispiel zeigt, wie so was aussehen kann:

100 LABEL LDA #$3A ;Minimalabstand. 200 PLA ;Nur Operation. 300 PLA ;Dasselbe, mit Minimalabstand.

Daher werden wir ab jetzt den Tabulator benutzen, um die Felder klar zu trennen. Listing 1 zeigt ein komplettes Programm. Es lädt den Akkumulator mit dem Wert Null, speichert ihn dann in die Adresse 3000 Hex und kehrt zurück zum aufrufenden Programm. Die 3. Zeile enthält „*= 0$600“. Das „“=“ ist eine Assembleranweisung, die den Ursprung oder den Speicherzähler (location counter) des Assemblers auf 600 Hex stellt. Das bewirkt, daß der Maschinencode von 600 aufwärts generiert wird. Ein derartiges Kommando muß jedem Programm vorangestellt sein, um festzulegen, wo der Code gespeichert werden soll. Es kann auch an jeder anderen Stelle benutzt werden, so daß der Code auf verschiedene Adressen verteilt werden kann, wenn erwünscht</p> <pre class=“MsoNormal“ style=“text-indent: 3.0pt;“>0100 ;Ein einfaches Programm, das den Nutzen der 0110 ;Tab-Taste für die Spalteneinteilung demonstriert 0120 x= $0600 ;Starte Code bei 600 hex 0130 LDA #0 ;Zero location 0140 STA $3000 ;3000 hex 0150 RTS ;Zurück zum Aufruf LISTING 1

Listing 2 ist die Form, wie sie der Assembler während des Assemblierens „zurechtrückt“ (vergl. BASIC, wo auch die Zeilen formal „in Ordnung“ gebracht werden. A.K.). Es handelt sich im Prinzip um eine exakte Kopie von Listing 1, außer daß links zwei Extraspalten mit Zahlen eingefügt worden sind. Sie zeigen den Inhalt des Location-Counters (Speicherzähler) und dementsprechend den Inhalt des Speichers. (Also: in Speicherzelle 0600 steht jetzt A900, in 0602 steht 8D0030 usw. A.K.) Wir können daraus erkennen, daß A9, der OpCode für IDA“ in Stelle 600 Hex gespeichert ist, und „00“, nämlich der Operand bzw. die Daten, in der nächsten Stelle, $601. Die nächste Zeile zeigt, was an der nächsten Stelle, $602, wie erwartet zu finden sind. Deshalb finden wir in der zweiten Spalte den genauen Inhalt des Object-Files, also des entsprechenden Maschinencodes für unser Programm und die Adresse jedes einzelnen Bytes.

0100 0101 ;Ein einfaches Programm, ;das den Nutzen der 0110 ;Tab-Taste für die Spalten  0111 ;einteilung demonstriert 0000 0120 x= $0600 ;Starte Code bei 600 hex 0600 0130 LDA #0 ;Zero location 0602 0140 STA $3000 ;3000 hex 0605 0150 RTS Zurück zum Aufruf LISTING 2

Aufkleber drauf! I Label it!
Listing 1 enthält im ersten Feld nichts, keine Labels. Schreibt man ins erste Feld ein Label, dann wird diesem ein Wert zugeordnet Der Wert ist der Inhalt des Location Counters, also die aktuelle Adresse. Eine andere Methode, dem Label einen Wert zuzuweisen, besteht darin, das „2 Zeichen („Ist Gleich“) ins zweite Feld zu schreiben.

Der Operand im folgenden Feld ist dann der Wert des Labels. Man sollte darauf achten, daß einem Label nur ein einziges Mal im Programm ein Wert zugeordnet werden kann. Sobald das Label einen Wert hat, kann es auch im Operandenfeld als Datawert für alles mögliche benutzt werden. Beim Assemblieren wird dann (durch den Assembler) statt des Labelnamens der Wert des Labels eingesetzt.

Labels werden benutzt, Adressen oder Daten Namen zu geben. Sie entlasten das Gedächtnis in der Weise, daß man nicht jedesmal einen bestimmten Wert nachschauen oder sich gar merken muß. Man kann seinem Wert einen Namen von irgendeiner Bedeutung geben, und dieser Name kann dann jedesmal benutzt werden, wo der Wert gebraucht wird. Ein anderer Vorteil liegt auf der Hand: Will man einen Wert ändern, so muß man nicht jedesmal das ganze Programm nach ihm durchsuchen und ihn x-mal ändern. Stattdessen ändert man ein einziges Mal den Wert des Labels (am Anfang des Listings). (Und es kann nicht passieren, daß man versehentlich einen Wert zuviel ändert, der zufällig genauso aussieht, aber nicht zu diesem Label gehört. A.K.

0100 0110 ;Programm, das die Anwendung von Labels zeigt;die für Speicherstellen oder Datas stehen  0120
SUM = $4000 Adresse, in der SUM gespeichert ist 0130 0140 INCR = x= $13 $0600 ;Wert erhöhen ;Location Counter einstellen 0150 CLC ;Carry löschen für die Addition 0160 LDA SUM ;aktuellen Wert für SUM einlesen 0170 ADC #INCR; INCR-Wert dazuzählen 0180 STA SUM; neuen Wert zurückschreiben 0190 RTS ;Zurück LISTING 3

Listing 3 zeigt, wie man Labels an der Stelle von Adressen oder Datas benutzt Das Programm zählt jedesmal einen Wert zur aktuellen Adresse dazu und speichert die so entstandene neue Zahl wieder ab. Zeile 120 weist dem Label SUM den Wert (hex) 4000 zu. Dies ist die Adresse, wo die Zahl, die man so erhöht hat, gespeichert wird. Die nächste Zeile weist INCR den Wert (hex) 13 zu.

Soviel soll zur Summe (SUM) dazugezählt werden. Der Rest des Programms läuft ebenfalls ganz normal ab, außer daß anstelle einer Adresse oder anstelle von Datas jedesmal der Labelname benutzt wird. Beim Assemblieren werden diese Labels einfach durch ihren Wert im Operandenfeld ersetzt Deshalb ist der Effekt derselbe, wie wenn in Zeile 160 stehen würde: „LDA $4000“.

Wollten wir jetzt die Adresse von SUM ändern, müßten wir nur die Zeile 120 ändern. Hätten wir in Zeile 120 den Festwert $4000 eingegeben, müßten wir (ohne Label) auch die Zeilen 160 und 180 ändern.

0100 ;Programm, das die Anwendung von Labels 0111 ;zeigt, um Punkte im Programm zu markie0112 ren  0120 COUNT.. $4000 ;enthält den aktuellen 0121 ;Count-Wert 0130 x= $0600 ;Location Counter 0131 ;einsterlen 0140 ADD CLC ;Carry löschen für die 0141 Addition 0150 LDA COUNT ;aktuellen Wert für 0151 ;COUNT einlesen 0160 ADC #2 ;INCR-Wert dazuzäh  0161 len 0170 STA COUNT ;neuen Wert zurück 0171 ;schreiben 0180 JMP ADD ;zurück zum Start  LISTING 4

Listing 4 arbeitet mit 2 Labels. Das erste ist definiert wie im Beispiel vorher. Es ist die Adresse eines Zählers (count = zählen). Zeile 140 enthält das 2. Label „ADD“. Allerdings steht es diesmal vor einem 6502-Mnemonic. In diesem Fall ist der Wert, der „ADD“ zugewiesen wird, die Adresse der Instruktion, vor der „ADD“ steht, in unserem Fall die Start-Adresse des Programms, also $600.

Zeile 180 enthält einen Sprungbefehl (jump instruction). Gesprungen wird zur Adresse, die in „ADD“ festgelegt wird. In diesem Falle könnte man also auch schreiben: „JMP $600“. Bewirkt wird, daß das Programm in einer Endlosschleife abläuft, wobei bei jedem Durchgang dem Label COUNT 2 hinzugerechnet werden.

Labels können natürlich an jeder beliebigen Stelle im Programm eingesetzt werden; man kann dann zu diesem Label springen (jump) oder verzweigen (branch), statt lange herumzurechnen, wo denn im Speicher die Instruktion gespeichert ist. Man kann sich diesem Einsatz von Labels als „Markierungspunkte“ vorstellen, auf die man nach Bedarf springen kann.

Odd Expressions !Seltsame Ausdrücke I
Ein anderer Vorteil eines Assemblers ist, daß er Ausdrücke im Operandenfeld auswerten kann, z.B. LABEL = 2 “ 3 +1 errechnet rechts vom „=“ den Wert 7 und weist ihn dem Label LABEL zu. Ein derartiger Ausdruck kann auch andere Labels enthalten, die bereits definiert sind. Diese Ausdrücke können auch als Operanden für eine 6502 Instruktion benutzt werden. Diese Möglichkeit bietet allerdings keine schlaue Abkürzung, um in Maschinensprache zu multiplizieren oder zu dividieren; die Ausdrücke werden während des Assemblierens ausgewertet und dann im Programm als fester Wert benutzt (also nicht: 2 “ 3 + 1, sondem einfach 7; A.K.). Die Möglichkeiten dieser Ausdrücke zu nutzen, spart uns aber den Einsatz eines Taschenrechners, um eine gerade benötigte Konstante zu berechnen. Stattdessen tut dies der Computer während des Assemblierens (d.h., der Assembler, der anschließend diesen „Text“ in einen Maschinenspracheprogramm kompiliert, kann multiplizieren. A.K.).

0100 ;Programm, um den Wert einer ASCII-Zahl 0110 ;herauszufinden 0120 CHAR = $4000 ',enthält das ASCII-Zeichen 0130 NUM = $4001 ;enthält den ASCII-Wert der Zahl 0140 x= $0600 0150 SEC ;Carry für Subtraktion einstellen 0160 LDA CHAR ;ASCII-Zeichen einlesen 0170 SBC #'0 ;ASCII-Wert der Null abziehen 0180 \ STA NUM ;Ergebnis als Zahl abspeichem 0190 RTS ;Zurück  LISTING 5

Eine recht nützliche Möglichkeit ist ein einfaches Anführungszeichen (‚) (So nennen das die Amerikaner, bei uns heißes Auslassungszeichen oder Apostroph. A.K.), gefolgt von einem ASCII-Zeichen. Ist der Ausdruck ausgewertet, wird der ASCII-Wert der Operand. Damit erspart man sich, extra in ASCII-Tabellen nachzuschlagen, und dann erst den Wert aufzuschreiben. Listing 5 demonstriert dies. Angenommen die Adresse für CHAR enthält den Wert einer Ziffer, von 0 bis 9, so wird dieses Programm die tatsächliche Zahl, für die das Zeichen steht, in die Adresse NUM schreiben. Der ASCII- Wert von 0 ist 48 (dez), die Zeichen 1 – 9 haben die darauffolgenden Werte 49 – 57. Um also das Zeichen in die dazugehörige Zahl zu wandeln, brauchen wir nur den Wert von ASCII 0 abzuziehen. Zeile 170 vollzieht diese Subtraktion. Die 0 hat den Wert 48, also ASCII für 0, das Ergebnis der Subtraktion wird in der Adresse NUM abgelegt Wäre beispielsweise das ASCII-Zeichen die 9, dann fänden wir unter CHAR den Wert 57, davon abgezogen würde 48, so daß wir (tatsächlich) den Wert 9 erhalten, der in NUM abgelegt wird.

Getting it together ! Wie kriegt man’s zusammen?
Nachdem wir nun eine Reihe von Beispielen gesehen haben, die die Möglichkeiten in Assembler aufzeigen, wollen wir uns im nächsten Teil endlich daran machen, ein Programm zu erstellen. Es soll aus dem BASIC aufgerufen werden (es wird also eine ML-Routine, d.h. eine Routine in Maschinensprache – ML = Machine Language – A.K.),- soll zwei ganze Zahlen (integer numbers) miteinander multiplizieren und die Antwort in BASIC ausgeben. Obwohl das nichts Besonderes ist, wird es hoffentlich eine ganze Reihe der Ideen und Prinzipien in sich vereinigen, die in dieser Serie bisher angesprochenen worden sind. Außerdem soll es ja auch in vollem Umfang verstehbar sein. Soviel sei jetzt schon verraten: Es handelt sich um den bekannten „USR“-Befehl.

Nicht vergessen

Am Samstag, den 28. Oktober 1995 Atari Bit Byter User Club e.V. Jahreshauptversammlung!

Siehe gesonderte Einladung!

Klappern gehört zum Handwerk…

(M)eine unendliche Druckergesch
ichte)
von Hermann Röttger

Es begann mit einem harmlosen Gespräch, das Uwe (seit Jahrhunderten in der Gastronomie beschäftigt) mit seiner Chefin führte…

Chefin (aufgeregt):
„Immer dieser Ärger mit der Tageskarte! Jetzt kann ich mich schon wieder an diese verfluchte Schreibmaschine setzen! Und mit weichem Ergeb­nis? Das „e« klemmt ich verhaue mich in der Rechtschreibung, und am Schluß fehlt mir (dies scheint ein ungeschriebenes Gesetz zu sein) stets EIN Zentimeter für das letzte Gericht…“

(Theatralische Pause) Uwe (nachdenklich): „Hmmm… Es gäbe da vielleicht noch eine andere Möglichkeit…
Chefin (frohlockend): „Nämlich ?“
Uwe (vorsichtig):
»Nunja… Ich habe einen Atari 800 XI – und-“ Küchenchef (im Bewußtsein seiner epochalen Leistung, den Netzschalter seines Peh-Zeh’s gefunden zu haben): „Wieviel Mämmori hat der denn ?‘
Uwe (stolz):
„64 Kilobyte!!!“
Küchenchef (mitleidig):
„VIERUNDSECHSIGKILOBYTE! Wat soll dat dann? Da hat ja mein Taschenrechner schon m-..“
Uwe (in seinem atarianischen Stolz aufs tödlichste beleidige:
„Kann ja alles sein… Mit ein bischen Trickserei hab‘ ich jedoch die gleiche Druckerauflösung wie du!“
Küchenchef (durch den Ausdruck Druckerauflösung sichtlich irritiert: „Glaub ich nich!“
Uwe (in Begeisterung geratend): „Ich könnte sogar unsere demnächst fällige neue Hauptkarte auf meinem Atari entwerfen und ausdrucken…“
Küchenchef (kopfschüttelnd): „Jetzt dreht er durch…“
Chefin (eine günstige Gelegenheit voffausahnend): „Meinst du wirklich, das klappt ? Wie du weißt, brauche ich die Wochenkarte sofort und die Hauptkarte in einem Monat…“
Uwe (lässig): „Null problemo……..“
3 Tage später. Bei einem Besuch beichtet mir Uwe seinen Anfall von Atariomanie
Uwe (locker): …und da hab‘ ich gedacht, wir könnten das ma‘ eben zusammen machen… …Kriegst auch 200 Mark
Ich (Unheil vorrausahnend): „Wieso 200 Mark ? Die Tageskarte ist doch in 10 Minuten fertig ! Wo ist das Problem ?“
Uwe (schuldbewußt): „Öh. Ich meinte eigentlich die Hauptkarte. Das ist doch kein Problem,oder?
Ich (Fred Feuerstein gedenkend): „Ohhhh MANNNN
5 Tage später. Schon seit Stunden schlage ich auf die Tastatur (und in Gedanken auf Uwe) ein… Das Programm für die Tageskarte ist längst im Speicher, aber die Hauptkarte bringt mich an den Rand der Verzweiflung. Folgende Anforderungen sind zu erfüllen:

* DIN A4-Format
* Zeichensatz in Druckerauflösung
* EINERIESENGROSSEGRAFIK (Schriftzug und Wappen) in Druckerauflösung und eingerahmt soll’s noch sein („Am besten schön aldmodisch verdreht…“)

Nach unzähligen Versuchen bin ich’s gegen 22 Uhr leid und verziehe mich mit der ABBUC-PD-Liste zwecks größerer Geschäfte in den kleinsten Raum meiner Wohnung. Die Denkerstellung macht sich bezahlt.“Daisy-Dot 3″, lese ich da, „neueste Version des legendären DD 2 auch große Zeichensätze Druckerauflösung…..“
„Warum das Rad 2x erfinden ? „,denke ich , und eile zum Telefon.

2 Tage später. Ungläubiges Erstaunen. Kaum geordert, liegt die PD schon in meinem Briefkasten. Durch dieses postalische Zeichen ermutigt, mache ich mich mit neuem Enthusiasmus an die Arbeit. 10 Minuten später. Gewitterstimmung. Keine deutschen Umlaute. Dann Erleichterung. Zeichensatzeditor vorhanden. Also: Joystick raus, aus B mach ß, ein paar Pünktchen hier, ein paar Pünktchen da. Der erste Probeausdruck macht deutlich,das an mir kein da Vinci verlorengegangen ist. Das ß liegt bis zur Unkenntlichkeit verstümmelt auf dem Bauch, die Pünktchen sehen aus wie Fliegenkot und liegen, allen Gesetzen der Wahrscheinlichkeit trotzend, ohne Ausnahme an verschiedenen Positionen.

Eine kleine Ewigkeit später ist auch dieses Problem gelöst. Meine künstlerischen Notschöpfungen würden zwar noch immer keine Medaille gewinnen, aber dafür für eine Teilnehmerurkunde dürfte es reichen….

Was jedoch bleibt ist die Frage, wie ich die einzelnen Text-und Grafikelemente zusammenfügen soll. Ein aus der Not der Jugend heraus getätigter Anruf bei KE bereichert mich um die Erkenntnis, das ich unbedingt den Typesetter brauche“, weil dieses Programm all jene Wunder vollbringt, die ich so drigend benötige. — ‚Also guf, denke ich, „ein ausseratarianisches Wunder kann einem schom mal 20 Mucken wert sein“. Ich bestelle also das Teil und warte. Und warte. Und warte. Und: „Warte, was ist das? Erst 2 1/2 Wochen um und schon da ? Na schön, also rein in die Floppy und los ! Dann grenzenloses Nichtbegreifen.

Als ich das zweite Bild des Titelschrifizugs an das erste anfügen will, wird dieses im wahrsten Sinne des Wortes ausgelöscht. In meiner ersten Verzweiflung boote ich erst mal neu. Das Ladegeräusch beweißt eine seit langem gehegte Vermutung: Mein Computer lebt. Und damit nicht genug: Er lacht mich aus!

Also rattere ich 10x das Programmierergebet herunter. „Mein Computer macht nur das, was ich ihm sage. Ich tippe, also bin ich!“ Mein Voodoo-Zauber scheint zu funktionieren: Ich erinnere mich nämlich an die Anleitung, die der geschulte Atarianer allein schon deshalb ignoriert, weil sie

  1. fehlt
  2. unverständlich ist
  3. genau DIE Bechreibung NICHT enthält, die man gerade braucht.

Diese Anleitung ist jedoch die löbliche Ausnahme der Regel, da sie mir genau erklärt, warum eine nicht vorhandene Option auch nicht funktionieren kann.

Mein zweiter Anruf bei KE erweist sich als äußerst aufschlußreich: Zur Gesamtübersicht der Seite ist, so lasse ich mich belehren, ein weiteres Wunder namens „Page­Designee‘ vonnöten, welches zwar ‚Typeseffer­Kompatibet‘, aber trotzdem ein selbstständig laufen­des Programm ist. Das „selbstständig laufende Pro­gramm“ hat natürlich auch einen selbstständigen Preis, den ich jedoch bereitwillig zu leisten bereit bin, da mich die Bezeichnung „selbstständiq“ irgendwie in einen entrückten Zustand versetzt hat…

Diesmal dauert das Warten nur 1 1/2 Wochen. Es scheint sich gelohnt zu haben: Bereits nach einer halben Stunde habe ich meinem Computer die gewünschte Funktion abgewrungen. Schulterklopfend betätige ich die Druckfunktion und… mein Drucker druckt tatsächlich !!!

Aber was ?? Auch wenn ich meine unterentwickelten künstlerischen Qualitäten berücksichtige, ist dies ganz eindeutig NICHT MEIN BILD, sondern…. Ja, was eigentlich?? Ich glaube, die Bezeichnung .nichtssagendes Chaos“ kommt noch am nächsten an die schreckliche Wahrheit heran.

Mein Drucker war natürlich schuld, erfahre ich aus der Anleitung. Falscher Druckertreiber. Dann an Wahnsinn grenzendes Glück. Der richtige Treiber ist ebenfalls vorhanden. Zärtlich boote ich meinen Lieb­ling erneut, nehme die Einstellungen vor, und streichle noch einmal über das Gehäuse. Er druckt! Und wie er druckt! Das ist unverkennbar meine Gra­fik! Heurekla, er hat’s gefunden!

Es ist natürlich klar, das natürlich nicht allIes klar wie Kloßbrühe war.

Die Druckerauflösung, auf dem „Typesetter“ noch zufriedenstellend, erreichte bestenfalls Graphics 7­Niveau. Ich ließ mich also scheiden, wanderte nach Sunnyyale aus, und gründete die Glaubensgemeinschaft der Druckernihilisten.

Doch ganz im Ernst. Bis auf den letzten Satz ist die­ser Bericht eher wahr als erstunken und erlogen. Zu KE’s Ehrenrettung ist noch hinzuzufügen, das er mir das unzureichende Wunder ohne lange Diskussionen nicht nur umgetauscht, sondern gleichwertig ersetzt hat.

Das es schließlich doch noch geklappt hat, könnt ihr der nächsten Seite dieses Magazins entnehmen.

 

 

 

 

 

 

 

 

 

 

 

 

 

Natürlich war es NICHT möglich, alles in einem Arbeitsgang zu erledigen. Es dauerte vielmehr 25 Stunden, bis mein geplagter Drucker das Werk vollbracht hatte. Warum 25 Stunden? Weil wir beschlossen, alle 35 erforderlichen Exemplare (‚a 6 Seiten) per Atari AUSZUDRUCKEN!

Eine Woche später teilte uns KE übrigens mit das er das Kopieren der einzelnen Seiten für ein Butterbrot (mit Aufschnitt) übernommen hätte…

„Vielleicht das nächste Mal‘, meinte Uwe großzügig, und stellte bei der Flucht aus meiner Wohnung den neuen Weltrekord im 100 Meter ein.

Alle, die trotz dieses Textes an den „technischen Zutaten“ interessiert sind, sollten sich das folgende Rezept antun:

Ihr benötigt:

  • Die Dalsy-Dot 3 Systemdiskette
  • Nach Möglichkeit eine Zusatzdiskette mit deutschen Zeichensätzten (gibt’s ebenfalls beim ABBUC)
  • Das DTP-Programm „Typesetter“
  • jede Menge Zeit
  • und Geduld

Nun noch eine Kurzbeschreibung, die euch verdeutlicht wie die abgebildete Karte letztendlich erstellt wurde:

Zunächst wurde der Rand entworfen. Hierzu wandelten wir mit einem beliebigen Zeichensatzeditor einige Zeichen um und entwarfen ein Programm, das diese auf die gewünschte Art anordnete. Zum Drucken verwendeten wir einen speziellen Treiber, der es ermöglicht Atari-Zeichen auszudrucken. (Treiber befindet sich auf der Magazindiskette)

Den „Typesefter“ verwendeten wir übrigens deshalb nicht, weil er (allen Beschreibungen zum Trotz) keine ganze Seite im Speicher hat.

Als nächstes entwarf ich mit einem Graphics-8 Mal­programm die Kopfgrafik, welche, ob ihrer Größe, zunächst aus 2 GR.8-Bildern bestand. Mit dem „Typesetter“ fügte ich diese dann zu einer Grafik zusammen. Da der Typesetter dies jedoch normalerweise nicht zuläßt, zerlegte ich die Bilder zunächst in 6 ‚Typesetter-inteme“ Grafiken. Diese Abschnitte wurden dann einzeln nachbearbeitet, um die hohe Druckerauflösung des „Typeseffers“ auszunutzen. Nun wechselten wir zurück in den k­beitsbildschirm und fügten das Puzzle wieder zu­sammen. Soviel zum Thema ’selbstständiges Programm,….

Was noch fehlte, war der Text Um auch hier die höchste Auflösung zu gewährleisten, benutzten wir zum Ausdrucken desselben den Daisy-Dot 3­Treiber. Für alle, die dieses Programm nicht kennen: Man entwirft den Text auf einem beliebigen Texteditor und druckt ihn anschließend mit DD3 aus. Für die Platzierung stehen Steuercodes zur Verfügung, wel­che der Einfachheit halber im Text angegeben, aber natürlich nicht ausgedruckt werden.

Daraus geht hervor, das für JEDE SEITE 3 Arbeitsgänge erforderlich waren. Bei 35 Karten a 6 Seiten macht das nach Adam Riese 630 Durchgänge…

Und wenn er nicht zerbrochen ist, so klappert er noch heute…

In diesem Sinne: Many good bytes to all ABBUC-Members

Hermann Röttger
Uwe Bruenninski

A.B.B.U.C. PD Neuheiten

0448 F.R.E.E. ED/2S
Demoversion des Spiels von Bertrand Le Roy aus Frankreich. Aufgemacht wie viele PC-Spiele. Auch die Demo macht reichlich Spaß. Testbericht des Spiels könnt Ihr auf der Magazindisk #42 nachlesen. Dort findet Ihr auch zwei tolle Screensdumps des Spiels. Bezugsquelle der Vollversion: Bertrand Le Roy, 72 Rue des Landes, F- 78400 Chatou, Frankreich. Preis: 100 FF

0449 Line up ED/1S
Ein Spiel aus Chile. Trotz der der spanischen Texte ist das Spiel leicht zu verstehen. Das Spiel ist ein Clone des bekannten Columns. Es ist optisch hervorragend auf dem ATARI aufbereitet. Die Level sind leicht zu spielen und eignen sich gut für Kinder und Anfänger. Gespielt wird mit dem Joystick. Das Drehen der Objekte erfolgt mit der Feuertaste. Eine lohnenswerte Anschaffung!

0450 AMC Demo Stereo Blaster Pro / Titelbildschau ED/2S
Alle Titelbilder der im AMC-Verlag erschienen Programme für den ATARI. Die Titelbilder sind toll gezeichnet und laufen nach der bekannten „Fader“-Art autmatisch ab. Die Automatik kann mittels [START] beschleunigt werden.

0451 frei

0452 First Transmition Result ED/1S Comic auf dem Atari von der polnischen Gruppe DISC Jokers. Die Bilder stammen vom C-64-Spiel TURICAN II. Mit der [SPACE] werden einzelne Comic Bilder teilweise geladen oder in vorhandene Szenen eingeblendet. Ein „Muss“ für Comic-Fans.

PD- Bibliothek: Theo Schwacke, Heinestr. 17, 45699 HERTEN, 202366-34696

 

 

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