home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga MA Magazine 1998 #6
/
amigamamagazinepolishissue1998.iso
/
coders
/
assembler-kurs
/
lektionen
/
lektion1.txt
< prev
next >
Wrap
Text File
|
1977-12-31
|
74KB
|
1,165 lines
Vollständiger Assembler-Programmierkurs
auf zwei Disketten
By
Fabio Ciucci (Randy/Ram Jam) - 1994/95
Für all jene, die jemals zu lernen versucht haben, Demos und Spiele zu
schreiben, die die Hardware des Amiga vollständig ausnutzen wollen, es
aber nie geschafft haben, entweder weil die Handbücher der Programmier-
sprachen zu schwierig oder zu abstrakt geschrieben waren und die Source-
Codes (Programm-Listings) zu wenig dokumentiert oder zu schwierig waren,
oder für jene, die es noch nie versucht haben und und die es wundert, wie
es zu schaffen wäre.
Ich möchte all denen danken, die materiell und moralisch zur Entstehung
dieser zwei Diketten beigetragen haben:
Luca Forlizzi (The Dark Coder/Morbid Visions)
Andrea Fasce (Executor/RAM JAM)
Sirio Zuelli (PROXIMA DESIGN)
Alberto Longo (Fields of Vision)
Alvise Spano' (Aga/Lustrones)
Nicht desto weniger jenen, die die Übungen getestet haben und
feststellten, ob sie sie mehr oder weniger verstanden:
Andrea Scarafoni, Federico "GONZO" Stango und andere.
Zum Schluß möchte ich noch meine Freundin Kety grüßen, die darauf
achtete, daß ich nicht zu viel Zeit vor dem Computer verbrachte.
In meiner Karriere als Hobbyprogrammierer kann ich einige Demos/Intros für
BBS als Meine bezeichnen, zum Beispiel "AMILINK.EXE" für die Datenbank
"AmigaLink" oder für Clubs wie dem neuen "Amiga Expert Team". Meine
größten "Werke" sind mein erstes Demo für das AGA-Chipset, "World of
Manga", und "NAOS2, das ich für die Gruppe NOVA ACIES programmiert habe.
Ich möchte vorausschicken, daß es irgendwie angebracht wäre, mindestens
eine Grundkenntnis des DOS zu besitzen, mindestens gerade soviel wie
nötig, um die Listings abspeichern zu können! Ihr müßtet dafür beim Kauf
ein Handbuch mitbekommen haben... Kurzum, auf den Disks (seien es nun
Harddisks oder Floppy) sind die Daten als "File" gespeichert, das sind
schier endlose Reihen von Ziffern, die zusammen dann z.B. ein
Graphicfile, ein Musikfile, einen ausfühbaren File, ein Listing usw.
ergeben. Es ist außerdem darauf zu achten, daß eine nagelneue Diskette
FORMATTIERT werden muß, bevor man auf ihr Daten speichern kann. Ist sie
einmal formattiert, kann man darauf jeden Typ von File speichern, seien es
nun Bilder von einem Graphicprogramm oder Texte (wie den, den ihr gerade
lest). Ein File kann man von einer Diskette auf eine andere kopieren,
man kann ihn löschen oder seinen Namen ändern usw. Auf einer Diskette
haben so viele Files Platz, bis sie voll ist (so ein Wunder...), das
entspricht in etwa 880kB. Das heißt, ich habe zwei Dateien zu ca 400kB
platz, oder mehrere kleinere, Hauptsache sie überschreiten zusammen nicht
die Grenze der 880kB. Des weiteren kann man auf der Disk auch ein bißchen
Ordnung schaffen, imdem man sog. "Subdirectorys" anlegt, das sind kleine
Abteilungen in denen man die Files legen kann. So wäre es denkbar, eine
Subdirectory "Texte" und eine "Bilder" anzulegen, in die wir jeweils
unsere Liebesbriefe an die Freundin geben bzw. unsere Bilder, die wir mit
DPaint oder einem anderen Malprogramm zusammengeschmiert haben. Es ist
ungefähr so, als wäre die Diskette/Harddisk wie ein Schrank, und die
Subdirectorys sind deren Schubladen. Nun ist es aber auch möglich,
innerhalb der Directorys noch weitere Directorys zu machen, also kann eine
Subd. Files oder weitere Subdirectorys beinhalten. Um sich nun in dieser
Struktur fortbewegen und verschiedene Operationen durchführen zu können,
muß man einige Befehle kennen, die man über die Shell/CLI eingibt:
Dir = Listet alle Files / Subdir. auf dieser Diskette/
Platte bzw. in dieser Directory auf
Copy = Kopiert ein File
Delete = Löscht ein File ( Geht vorsichtig mit diesem
Befehl um!)
Makedir = erzeugt eine "Schublade" (Subdir)
Eine andere Methode ist die, alles von der Workbench aus zu erledeigen,
dort sind die File als Ikons (Bildchen) und die Subdirs als Schubladen
dargestellt. Weiters ist zu wissen, daß der interne Floppydrive "df0:"
heißt, die externen "df1:", "df2:" etc. Die Harddisk heißt meistens "DH0:"
oder "HD0:". Schneller geht´s, wenn man Utilities wie Directory Opus oder
DiskMaster verwendet. Wenn ihr also ein Listing geschrieben habt, dann
müßt ihr es auf einer (formattierten) Diskette oder auf der Festplatte
(Harddisk) in einer Subdir speichern. Eine weitere Sache, die ihr wissen
solltet, ist, wie man eine "autoboot"-fähige Diskette herstellt. Das sind
jene Disks, die automatisch nach dem Anschalten des Computers oder nach
einem Reset laden, wenn sie im Laufwerk eingelegt sind. Nehmen wir mal an,
wir haben ein AUSFÜHRBARES Programm geschrieben, das den Namen
"Mein_Programm" trägt und dieses auf eine Diskette kopiert. Um es nun
automatisch loslegen zu lassen, wenn wir den Computer starten, müssen wir
auf der Diskette eine Subdir mit dem Namen "S" erzeugen und darin einen
Textfile mit dem Namen "startup-sequence" speichern, in dem eigentlich nur
der Name des zu Startendem Programmes steht:
Mein_Programm
Die startup-sequence könnt ihr zum Beispiel mit dem gleichen Programm
schreiben (editieren), mit dem ihr gerade diesen Text lest. Es fungiert
auch als Text-Editor. Letze Sache: ihr müßt die betreffende Diskette noch
"installieren", das passiert mit dem Shell-Befehl "install":
Install df0:
Oder "Install df1:" , wenn die betreffende Diskette im Laufwerk df1:
liegt.
Dies vorausgeschickt, kann mit den Anmerkungen begonnen werden:
Anmerkung: Wenn ihr den Assemblerkurs auf die Harddisk installieren wollt,
vergesst nicht, das File "TRASH´M-ONE16.pref" in eure S: Directroy zu
kopieren. Er befindet sich in der s: Directory der Diskette.
Anmerkung2: Wenn ihr die Listings ausdrucken wollt, beachtet, daß sie mit
dem PowerPacker gepackt sind. Ihr benötigt also den PowerPacker Patcher,
der in diesem Kurs benötigt wurde, er befindet sich in der Directory "C"
dieser Diskette und heißt "PP". Um ihn zu installieren müßt ihr nur in
eurer LIBS: -Directory die "powerpacker.library" haben und "PP" tippen.
Die Listings sind selbstentkomprimierend (A.d.Ü : tut mir leid, ich kenne
kein kürzeres Wort dafür) beim Start.
In diesem Kurs werden verschiedene Argumente behandelt, wie der COPPER,
die SPRITES, der BLITTER sowie das neue AGA-Chipset und die Graphickarte
Picasso II. Auf der Disk 1 sind folgende Themen enthalten: 68000, Copper,
Playfields und Sprites. Der Blitter, AGA und der Rest sind auf Disk 2 und
3, leider noch nicht ganz vollständig.
Was die Verbreitung und Kopie dieser Diskette angeht, solltet ihr wissen,
daß sie GiftWare/Shareware ist und nicht wirklich Public Domain. Damit
meine ich, daß ihr den Kurs ohne Weiters euren Freunden kopieren dürft,
Hauptsache, ihr VERKAUFT ihn NICHT, da die Rechte auf diesem Kurs beim
Autor liegen, also bei mir, und nicht beim ersten Schlaumax, der auf der
Arbeit eines anderen spekuliert. Es ist aber auch wahr, daß ihr ihn einzig
und alleine zum Preis der einzelnen verwendeten, leeren Diskette verkaufen
dürft. Falls ihr es aber schafft, nachher selbstständig etwas zu
programmieren, dann habt ihr aus meiner Arbeit Nutzen gezogen, und ihr
MÜßT mir in irgend einer Art danken, vor allem wenn ihr die reichsten
Programmierer der Welt geworden seid (na ja, man kann ja nie wissen...).
Dieser Dank liegt ganz in eurem Ermessen, am liebsten habe ich
natürlich 10-DM-Scheine. Der rege Zufluß von Kies/Kohle würde mich
(Fabio Ciucci) ermutigen, weitere Lektionen zu schreiben, und
meinen Übersetzer (Martin De Tomaso), sie ins Deutsche zu
übersetzen. Das Geld (mindestens 10 DM) schickt ihr bitte an ihn:
Martin De Tomaso
Nicolodistr. 24/3
39100 BOZEN
ITALY ; Internet: mdetomas@inf.unitn.it
Bitte habt Verständnis, daß wir aus technischen Gründen (Zeit, Uni)
nicht imstande sind, eure Listings zu verbessern, genausowenig wie
auf tausenden von Zuschriften zu antworten. Stellt euch mal vor, so
ca. 50 Briefe am Tag vor euch liegen zu sehen, wenn ihr in die Uni
gehen müßt und euch dann auch noch die Freundin steßt.
Wenn ihr aber gute und brave Programmierer seid, und die
Amiga-Szene retten wollt (hey Chaos, Mr.Pet, Tron, Azure,
Touchstone, Wayne Mendoza, .... where are you? On the PC scene? ),
dann könnt - oder MÜßT- ihr mit uns Kontakt aufnehmen. Was kostet
es euch schon, ein altes Listing zu kommentieren? Habt ihr nicht
gesehen, wieviele MB an Listings die Coder auf den PC´s hergeben?
Man braucht nur die CD-ROM der PARTY4 und der ASSEMBLY94 ansehen,
oder sie von Internet runterholen.
Ein anderer Grund, uns anzuleuten wäre, daß ihr imstande seid, den
Kurs GUT ins ENGLISCHE zu übersetzen (bzw. in irgend eine andere
Sprache). In diesem Fall habt ihr ein Anrecht auf einen guten
Prozentsatz (30% - 50%) des Profites, der von euch übersetzten
Version.
Ihr würdet mir auch einen großen Gefallen machen, wenn ihr diese erste
Diskette allen weiterkopiert, die ihr kennt, auch wenn euch selbst
persönlich Assembler nicht interessiert, da ihr somit anderen die
Möglichkeit gebt, programmieren zu lernen. Ich habe beschlossen, den ASM -
Kurs (ASM=Assembler) zu schreiben, weil 10000 Personen mich darum baten,
und da ich es aus reinem Spaß tue, ist er auch in einer recht
umstreitbaren Form geschrieben, aber den Anfängern wird es so leichter
fallen, denn wenn sie einmal "drinnen" sind, können sie immer noch selbst
die Argumente vertiefen. Wer hingegen Assembler schon seit längerem
programmiert, wird die Lektionen teils lustig finden, teils auch gewisse
Ungereimtheiten, deswegen rate ich denjenigen, sich sofort die Listings
anzuschauen: dieser Kurs ist für die gedacht, die bei NULL starten. Aus
eigener Erfahrung, und laut dem, was mir die zukünftigen "CODER" so sagen,
liegen die größten Probleme in den ersten zwei oder drei Programmen, und
darin alles zu verstehen, danach ist man selbst imstande, fortzufahren.
Ich biete mich also an, den Personen, die nicht einmal wissen was der
68000er ist,beizubringen, Kugeln auf dem Bildschirm hin und her zu jagen
und dort hüpfende Schriften anzuzeigen. Wenn die dann Programmierer bei
TEAM 17 werden wollen, reicht es, wenn sie weitermachen und dazulernen.
UM EIN SPIEL WIE GODS, PROJEKT X ODER ÄHNLICHES ZU PROGRAMMIEREN, DAS
NICHT GERADE EIN FLUGSIMULATOR IST ODER EIN 3D-SPIEL MIT ROTIERENDEN
WÜRFELN MIT TEXTURE-MAPPING ODER SINUS-TUNNELN á la STARDUST HABEN,
REICHEN DIE MATHEKENNTNISSE DER MITTELSCHULE.
Damit will ich jedem aus dem Kopf schalgen, daß er für die
Assemblerprogrammierung des Amiga weiß Gott was für Mathematik braucht.
Ich persönlich glaube, Mathes hat gar nix damit zu tun. Wenn man ein
Mathematikprogramm schreiben will, ok, dann braucht man
Mathematikkenntnisse, genauso wie wenn man ein Fußballspiel schreiben
will, man Fußball kennen muß. Das Wichtige ist zu wissen, wie der Amiga
funktioniert, seinen Prozessor kennen (beim Amiga ein Motorola 68000 oder
größer), seine CustomChips (praktisch die Teile, die die Graphic auf den
Bildschirm bringen und die Musik spielen). Ich selbst habe eine
Kunsthochschule in meiner Stadt besucht, und habe die ASM-Programmierung
gelernt, wenn ich in der Mittelschule war, es reicht also, die Zeit, in
der der Amiga eingeschaltet ist, gut zu nützen, und nicht nur zu spielen:
man muß nicht Informatik an der Uni studieren, denn dort bringen sie dir
sowieso nicht das Programmieren von Demos und Spielen auf einem Amiga bei!
Aber wieso sollte man lernen, Demos und Spiele zu programmieren? Und was
sind überhaupt diese Demos? Also, was Spiele sind, wissen hoffentlich
alle, deswegen kann man davon ausgehen, daß diejenigen, die Spiele selber
programmieren, es satt haben, Spiele zu sehen, die nicht so sind wie man
möchte, und man halt einmal sein eigenes machen will, Pixel für Pixel.
Demo ist ein Synonym für "demonstration", praktisch "zeigen","beweisen",
meist Graphic. Aber was zeigen, beweisen? Klarer Fall, die Power, die der
Amiga in sich hat und die Bravour der Programmierer. Aber da gibt´s noch
mehr: die Szene. Nein, nicht die Theaterszene, die Amiga-Szene, die "AMIGA
SCENE" (englisch ist die offizielle SCENE-Sprache...). Stellt euch die
Musikszene vor: dort gibe es verschiedene Gruppen, mit Sängern,
Schlagzeugern etc. In der AMIGA-SCENE hingegen gibt es verschiedene CODER
(Programmierer), GFX Artists (Graphiker), MUSICIANS (Musiker), die anstatt
ein "VIDEO" als Beitrag zu drehen, ein Demo schreiben, das sich zu den
anderen reiht, die von jemand anderem, zu einer anderen Zeit und in einem
anderen Ort geschrieben wurden, fügen. Dann gibt´s da noch die SWAPPER und
die TRADER, die jeweils diese Demos tauschen und über Post oder Modem
verbreiten. Die produzieren zwar gar nichts, haben aber auch ihre
Wichtigkeit in der Szene: etwas, was nicht zirkuliert, ist so, als ob es
nicht existieren würde. Andererseits streben sie danach, selbst CODER,
Graphiker oder Musicians zu werden, um selbst einmal bei einem Demo
mitgewirkt zu haben. Es gibt viele Gruppen in der Amiga-Szene, die
Mitglieder in der ganzen Welt haben, vor allem in Europa. Einige der
bekanntesten Gruppen sind ANDROMEDA, BALANCE, COMPLEX, ESSENCE, FAIRLIGHT,
FREEZERS, MELON DEZIGN, POLKA BROTHERS, PYGMY PROJECTS, RAM JAM, SANITY,
SPACEBALLS... Zu Bemerken ist, daß jedes Mitglied einer Gruppe ein
Pseudonym hat, ein sog. "handle". Kurzum, es sind Künstlernamen: zum
Beispiel heißen sich zwei Programmierer der ANDROMEDA "Dr. Jeckyll" und
"Mr. Hyde", einer der FREEZERS heißt sich "Sputnik", und dann sind andere
von anderen Gruppen:Hannibal, Dan, Paradroid, Dak, Wayne Mendoza,
Performer, Bannasoft, Laxity, Vention, Psyonic, Slammer, Tron, Mr. Pet,
Chaos, Lone Starr, Dr. Skull, Tsunami, Dweezil..... Der vollständige Name
besteht aus dem handle und der Gruppe, der man angehört, z.B.:
CHAOS/SANITY, DWEEZIL/STELLAR, DAK/MAD ELKS, und so weiter. Ich bin in der
Szene "RANDY/RAM JAM", aber klarerweise Fabio Ciucci für alle, die mit der
Szene nichts am Hut haben, sonst wäre es wohl etwas verwirrend. Die Szene
organisiert Partys, eine Art Begegnungs-Fete, wo die Gruppen ihre Demos
vorführen, mit einer Art "Wettkampf" um das beste Demo, mit Bewertung und
Preisen, auch in der Tausend-Mark-und-mehr-Gegend für die Gewinner. Einige
Programmierer der Szene gehen mit der Zeit über und programmieren Spiele,
die Argumente liegen ja sehr nah. So ist zum Bleistift der Programmierer
von "BANSHEE" Hannibal/Lemon, von "ELFMANIA" ist es Saviour/Complex, die
von "STARDUST" sind DESTOP/CNCD und SCY/CNCD, und die Liste ginge weiter
und weiter... Auf jeden Fall, auf Disk zwei ist eine ganze Lektion nur
über die SCENE enthalten.
Um zur Assemblerprogrammierung zurückzukommen, ob ihr nun Spiele oder
Demos auscodieren wollt, rate ich euch wärmstens davon ab, 3D-Routinen
(Routine=Teil eines Listings, eines Programmes) zu studieren, da sie die
komplexesten und somit die schwierigsten sind, und die ich selbst schlecht
verdaue, nicht wegen der Programmierart, aber wegen der grausligen
Matheformeln, die sie beinhalten. Aber Achtung! Ihr dürft auch nicht
glauben, daß wenn keine Mathematik-Kenntnisse gefragt sind, ihr nun
Elektronikgenies sein müßt und die Schaltpläne des Amiga durchbüffeln
müßt! Das ist nur der Fall, wenn ihr eine Graphik-Karte ansteuern müßt,
einen Videodigitizer oder ähnliches. Ich versichere euch, daß ihr getrost
die Figur eines Bayern auf den Bildschirm holt und dazu eine Polka spielen
läßt, ohne zu wissen, wo die Drähte ´rumführen!!!! Ich kenne Leute, die
Assembler mit 12 gelernt haben, andere mit 30 oder 40, ohne sich jemals
mit Mathematik befaßt zu haben und ohne Englischkenntnisse. GENAU! DENN
AUCH DEN MYTHOS, PERFEKT ENGLISCH KÖNNEN ZU MÜSSEN,SCHLAGT EUCH SOFORT AUS
DEM KOPF! Ich gebe zu, englisch zu können erleichtert die Arbeit manchmal
schon, denn die ASM-Befehle sind Abkürzungen von Wörtern aus dem
Englischen, wie SUB und ADD, was soviel wie Subtraktion und Addition
heißt. Die Kenntnis der WorkBench und des AmigaDOS werden euch in der
Programmierarbeit an und für sich nicht recht nützlich sein, da der
Computer in Wirklichkeit ziemlich anders funktioniert. Einfach
ausgedrückt, sind diese "Überstrukturen" das Betriebssystem, die in den
Kickstart-Chips lokalisiert sind, und ohne die beim Einschalten nicht
einmal die Bildschirmseite angezeigt würde, die verlangt, eine Diskette
einzulegen. Die Fenster, die ihr seht und verstellt, sind das Ergebnis von
tausenden Zeilen in ASM, die im Kickstart enthalten sind, zur Bestätigung
reicht es aus, die Unterschiede zwischen Kick 1.3 und 2.0 anzusehen. Es
hat sich nichts an den Disketten geändert, aber an den Kickstarts selbst.
Wenn ihr Programme wie Deluxe Paint, Kontoüberwachung, Haushaltskasse oder
Word-Processor schreiben wollt, also Programme, die unter der Workbench
laufen sollen, mit all ihren Fenstern, Menues, Gadgets und Multitasking,
dann rate ich euch, die Programmiersprache "C" zu lernen. Sie ist für eure
Art von Tätigkeit besser geeignet, und ihr könnt ohne größere
Schwierigkeiten eure Programme nach MS-DOS und WINDOWS konvertieren, im
Falle, daß ihr unsere Freundin verlassen (oder verraten?) wollt. Wenn ihr
aber von Graphicdemos mit springenden Kugeln, metallern glizzernden
Schriften und Super-Soundtracks im Hintergrund fasziniert seid, und davon
träumt, Spiele wie AGONY,LIONHEART, SHADOW OF THE BEAST, TURRICAN, APYDIA,
PROJECT X, SUPERFROG, ZOOL, GODS, CHAOS ENGINE, XENON II, LOTUS ESPRIT zu
programmieren, dann sollte klar sein, daß das nur in REINEM ASSEMBLER
machbar ist!! Und es braucht keine speziellen Vorkenntnisse in Mathe, es
reichen die üblichen Additionen, Subtraktionen, Multiplikationen und
Divisionen, vielleicht manchmal eine Sinustabelle oder eine Kosinustabelle
um zum Beispiel die Kugeln in einer gewissen Laufbahn flizzen zu lassen,
sei es nun eine Parabelform oder sonst eine Art von Kurve. Diese Tabellen
sind nichts anderes als eine Serie von Zahlen im Speicher, wie z.B.
1,2,3,5,8,10,13,15,18,23, die wiederum nichts anderes darstellen als die
X-Position bei einer bestimmten Y-Position. Diese Serien von Zahlen, die
Tabellen oder SINUSTAB, erzeugt der ASMONE auf Wunsch auch von selbst.
Dafür gibt´s den Befehl CS, der, ohne genaues Wissen über Trigonometrie
und ähnlichem Zeug, die Tabelle von selbst erstellt, es reicht ihm die
richtigen Parameter zu übergeben, schlimmstenfalls probiert man halt so
lange, bis es mehr oder weniger paßt. Solche SINUSTAB kommen in Demos und
Spielen oft vor, da viele wellenartige Bewegungen nicht in diesem Moment
berechnet werden. Wenn ihr aber davon träumt, Adventurespiele wie Monkey
Island zu schreiben bzw. Managerspiele, in denen nur stehende
Graphicseiten auftreten, und sich darin höchstens hie und da mal eine
Figur langsam bewegt, in denen der Sinn des Spieles darin besteht, die
richtigen Objekte oder Schriftzüge mit der Maus auszuwählen, dann ist auch
C besser am Platz. Es wird auch leichter, es auf PC zu konvertieren, auf
dem man dan leicht einen Haufen Geld verdienen kann. Andererseits wird C
in den technischen Hochsculen unterrichtet, und sehr gut an den
Universitäten, also machen schon die das große Geld.
Anmerkung: Das Beherrschen des Assemblers des Amiga kann sich als sehr
nützlich erweisen, wenn man in Zukunft auf ein anderes System umsteigt,
das mit dem gleichen Prozessor arbeitet, eben dem 68000 von Motorola.
Solche Systeme sind Apple MacIntosh und AtariST. Diese Systeme haben aber
ein anderes Betriebssystem als das im Kickstart des Amiga enthaltene, und
andere Chips für die Darstellung der Graphic und des Tons, also werden
euch die erworbenen Fähigkeiten für den Prozessor, nicht aber für das
andere Betriebssystem oder die anderen Graphic/Sound-Chips zu Gute kommen.
Für diese müßt ihr immer von NULL beginnen. Aber auch bei Sprachen wie dem
"C" bleibt euch das Erlernen der neuern Umgebung nicht erspart. Wenn ihr
zum Beispiel ein Programm in C unter der Workbench schreibt, das ein
Fenster öffnet, und darin Berge zeichnet, und ihr steigt auf PC-MSDOS um
(grober Fehler!), dann könnt ihr den Teil des Programmes, der die Berge
berechnet wiederverwerten, aber der Teil, der die Fenster öffnet, die
Gadgets und ähnliches unter der Workbench verwaltet, ist zu verwerfen und
komplett neu zu schreiben. Und ich versichere euch, auf ein anderes System
umzusteigen und alles neu zu lernen kostet Monate wenn nich Jahre an Zeit.
Anmerkung:Ein Programm, das in 68000er Assembler geschrieben ist,
funktioniert tadellos auf höheren Prozessoren, man muß nur einige Dinge
beachten.
Wenn ihr noch da seid und lest, dann heißt das, ihr seid noch
unerschrocken. Also beende ich das Aufzählen der Vorzüge des Assembler...
(die Sprache an und für sich heißt ASSEMBLY, das Programm, das es
compiliert nennt man ASSEMBLER, aber einfacherweise nennt man alles
ASSEMBLER, auch die Sprache selbst). Als erstes wird Assembler immer die
schnellste Sprache sein, was Geschwindigkeit der Programme angeht. Vor
allem, wenn sie gut geschrieben wurden, werden sie immer schneller laufen
als mit einem x-beliebigen anderen Compiler. Weiters kann man damit
spezielle Grafikeffekte erzeugen, die es noch nie gegeben hat: ok, ihr
könnt sie auch mit einem Titler erzeugen, aber halt immer nur die
gleichen. Es ist nicht schwer zu erkennen, mit welchem Programm ein
gewisser Effekt erzeugt wurde. Das gleiche gilt auch für die Demo Maker.
Der Beste darunter ist der TRSI DEMOMAKER, und er hat zweifelslos
interessante Effekte, aber inzwischen erkennt auch ein Kind eine Sache,
die mit dem Demomaker gemacht wurde, weil da immer die goldene Schrift
oben und unten auftaucht, und in der Mitte entweder die Kügelchen oder die
Sternchen... JETZT REICHTS! Man kann´s schon bald nicht mehr seh´n! Aber
mit Assembler kann man dauernd neue Effekte erfinden, die noch niemand
gesehen hat, und man muß sich nicht darauf beschränken, unter einem
Dutzend Vordefinierten auszusuchen, die schon tausende andere Personen
verwendet haben und Privatfernsehn damit angehäuft haben. Um euch eine
Idee davon zu verschaffen, was ihr alles anstellen könnt, möchte ich das
Demo von SPACEBALLS "State of the Art" nennen, eines der bekanntesten
Demos, weil es alle erstaunte wegen der stilisierten Mädels, die in Mitten
von Spezialeffekten tanzten. Ist nicht Schwieriges zu programmieren.
Wenn ein Programmierer genug Geduld hat, kann er sich auch an ein Spiel
heranwagen, zuerst um es selber zu spielen, um das Spiel seiner Träume zu
kreiren, um zu experimentieren, wieviele Männchen er bewegen kann, ohne
Geschwindigkeitseinbußen, um die wahren Grenzen des Amiga zu finden, und,
später, vielleicht ein kommerzielles Spiel auf die Beine zu stellen, das
auch die Mitarbeit von Grafikern und Musikern erfordert. Weiters braucht
es dann noch einen, der an der Werbetrommel rüttelt, denn die ist oft
ausschlaggebender als der effektive Wert des Spieles, außer in einigen
Fällen, in denen das Spiel einfach so toll ist, das es trotzdem zum Erfolg
kommt. Wieso nicht ein Spiel für CD32 entwickeln?? Es reicht, ein
AGA-Spiel zu machen, das die 600MB einer CD ausnützt, z.B. mit einer Art
von "Film", die in Echtzeit im Hintergrund geladen wird, auf der sich ein
Alles-Töten-Rambo oder ein Raumschiff bewegt. Es ist gar nicht so schwer,
ein solches Spiel zu machen: das Chipset ist mehr oder weniger das
gleiche, es sind nur einige Register dazuzulernen, der Prozessor
unterscheidet sich um NULL komma Josef, und die Verwaltung der CD ist noch
einfacher. Da gibt´s nämlich das "CD32 Developer Kit", zwei Disketten mit
allem Nötigen, das unter den Programmierern zirkuliert. Im Endeffekt ist
an der Schwelle zum 2000 Assembler noch an der Spitze mit dabei, und wenn,
wie viele PC-Typen prophezeien, nur mehr CD´s die Welt regieren, wird auch
der Amiga mit seinen CD´s aufwarten. Denn zur Zeit sind es ja noch vor
allem die PC-Fanaten, die voll aufrüsten um nur noch CD-Games zu spielen
und sich Slideshows von nackten Girls anzuschauen. Na ja, und wenn eines
Tages ein eine Software auf CD für den Amiga hervorkommt, dann ist es
möglich, daß alles mit einem uns nicht unbekanntem Assemblerkurs begann...
Wenn man dann einmal versteht, wie die Dinge in Wirklichkeit laufen, kann
man auch versuchen, die Spiele und Programme zu verändern. So habe ich
einige Male ein Programm so veränert, daß es den virtuellen Speicher des
A4000 verwendet oder habe ich gewisse Routinen von PD-Programmen
verändert, so daß sie schneller liefen. Bei Spielen kann man die
sogenannten Trainer schreiben, in etwa so, daß wenn Player 1 stirbt, er
ein Leben dazukriegt und ihm somit zur Unsterblichkeit verhelfen. Um
solche Spielereien aufzuziehen muß man aber schon einiges auf der Platte
haben, und vor allem braucht es dazu eine Utility, die MS-Monitor genannt
wird. Diese erlaubt das disassemblieren von Maschinencode, also das
anzeigen von gewissen Teilen des Speichers, und wenn man dann genau den
erwischt, in dem die Leben des Player 1 stehen, ist die Sache geritzt.
Besser noch sind aber die Cartridges wie die ACTION REPLAY. MS steht für
Maschinensprache, es ist praktisch die Sprache, die der Prozessor direkt
verwerten kann und die der Assembler erzeugt. MS ist aber für uns Menschen
extrem unverständlich, und so hat man sie in Assembler gekleidet, der uns
alles sehr viel leichter macht. Diese Operationen sind aber wie schon
gesagt, recht schwierig, und es hat auch keinen rechten Sinn, einfach auf
geradewohl loszuhacken und zu versuchen, ein blaues Männchen grün werden
zu lassen. Ich habe Typen erlebt, die ihre Zeit damit vergeudeten,
blindlings mit MS-Monitoren und Cartridges darauf loszuschießen um
Änderungen vorzunehmen, die eingentlich kein Mensch richtig verstand -sie
selbst inklusive- nur um dann zu Behaupten, sie hätten weiß der Geier was
für Verbesserungen an dem Programm/Spiel angebracht. Diese können heute
immer noch nicht eine Grafik in Assembler anzeigen; im Jargon heißen
solche Typen LAMER.
Bringen wir mal alles auf einen Punkt: wenn ihr einer dieser klassischen
18 jährigen, bleichgesichtigen, buckligen Jungs ohne Mädels seid, und auf
gut Glück mit einem MS-Monitor in den Intimitäten eures armen Amiga
rumfuchtelt, und behauptet, ein großer Hacker zu sein, dann legt den
Monitor bei Seite und folgt mir auf den rechten Weg. Auch ich habe auf
dieser lächerlichen Art und Weise begonnen (aber mit 8 Jahren, nicht mit
18!), habe aber bemerkt, daß es zu nichts führt und somit begonnen, Bücher
zu lesen ohne Seiten zu überspringen.
*Anmerkung des Übersetzers: An diesem Punkt werden einige Bücher
aufgezählt, die es (nicht) wert sind, unter die Lupe genommen zu werden,
die meisten jedoch von italienischen Herausgebern mit ausschließlich
italienischen Auflagen. Ich zähle sie trotzdem auf und verweise auf jene,
die in englisch oder deutsch zu haben sind. Hätte jemand einen Beitrag,
also wenn jemand ein Buch empfehlen kann, dann bitte schreib mir!!! Meine
Adresse findest du auf der Diskette!!
"IL MANUALE DELL´ HARDWARE DELL´AMIGA" Herausgeber IHT. Ist einen Versuch
wert, eine deutsche Version zu suchen. Soll scheinbar mächtig gut sein! In
ihm werden die Hardware-Bausteine wie CUSTOM-CHIPS und FLOPPY unter die
Lupe genommen, Register beschrieben usw. Es ist aber mehr eine Ansammlung
von abstrakten Daten und Tabellen ohne Beispielen, aber die findet ihr ja
in diesem Kurs. Für die Register braucht ihr nur im ASMONE den Befehl "=C"
zu tippen, und es kommen die Informationen über die Register $DFFXXX, sei
es generell wie speziell: =C 040 gibt euch eine Zusammenfassung über das
Register DFF040, das ist BLTCON0, ein Blitterregister.
"HARDWARE REFERENCE MANUAL" nur in englischer Version.
"ROM KERNEL MANUAL" nicht recht empfohlen für hüpfende Kugeln etc, nur
wenn man in ASM unter der WorkBench programmieren möchte.
Weiters gibts dann noch das "AMIGA GURU BOOK", wenn ich nicht voll daneben
liege, in englisch, und weiter wie "Amiga Spiele Programmierung", "Amiga
Assembler Praxis" ü.ä. Ich kann sie weder empfehlen noch abraten, denn ich
kenne sie (noch) nicht. Wenn jemand genaueres weiß, dann weiß er ja, was
er zu tun hat... *Ende der Anmerkungen des Übersetzers.
Anmerkung: Wenn ihr hingegen nicht die bleichen MS-Monitor-per-Zufall-User
seid, sondern gierige Forscher von neuen Spielen, die es zu kopieren und
zu beenden gilt, und ihr Stunden damit verbringt, am Telefon zu hocken um
euch über die Neuigkeiten zu informieren, und die restlichen Stunden damit
verbringt, mit XCOPY zu kopieren und zu spielen, vielleicht immer mit
eingeschaltenem Trainer um früher ans Ende zu kommen, dann ist es noch
schlimmer als bucklig mit dem MS-Monitor zu sein: entweder ihr macht
Schluß mit diesem atemlosen Kummer, immer auf der Suche nach Kopierbarem
zu sein, oder ihr werdet immer überspannt und gestresst sein und nie
erfahren, wieso sich die Figuren über den Bildschirm bewegen, und ihr
werdet nie erfahren, wie man sich selber einen Trainer mit Menu und viel
Trara macht, und ich versichere euch, wenn ihr mal einen Trainer für ein
Spiel geschrieben habt, dann kratzt euch nicht mehr, das Spiel zu beenden,
sondern nur zu verstehn, wie´s wohl läuft!!! Das ist der Unterschied
zwischen dem Spieler und dem Erschaffer des Spieles, zwischen dem
unterworfenem Volk und dem herrschendem Regime, das ihm quasi befiehlt, in
schlaflosen Nächten Unmengen an Spielen zu Ende zu bringen, entweder mit
oder ohne Tainer, und egal, welche Spiele, Hauptsache, es sind Neue und
Viele, wenn möglich mit XCopy kopiert (verwendet mindestens einen besseren
Kopierer, XCopy ist einer der schlechtesten!). P.S.: Weil wir grade von
Mädels sprachen... Ich habe noch NIE was von einer Frau in ASM
programmiert gesehen!! Wenn das gerade eine Vertreterin des weiblichen
Geschlechtes liest, dann glaube ich, ist es ein weiteres Motiv, die Erste
zu sein!! Wenn sich ein Mädchen für anderes als Tuschel über fremde Leute
und Vetrinen von Geschäften interessieren würde, und fetzige Dinge in ASM
schreiben, dann glaube ich, könnte sie so manchen Boy in eine Krise
versetzen, da die meisten davon bei den (weinigen) Girls, die sie kennen,
so sehr angeben, wie gut sie den Mauspointer über den Bildschirm bewegen,
und ihnen vorgaukeln, mit der NASA in Verbindung zu stehen, weil sie
glauben, die versteh´n eh nicht die Bohne. Meistens können die nicht mal
´ne Diskette formattieren.
Ich möchte hier schon mal vorweg nehmen, daß die Lektion2.TXT mit ihren
Beispielen die schwierigste von allen ist. Wenn ihr die überstanden habt,
dann ist die Sache gelaufen. Denn schon ab Kapitel 3 beginnen wir mit den
ersten Coppereffekten, und von da an werdet ihr schnell wie Kanonenkugeln
sein. Also bitte ich euch, die ersten beiden Lektionen mit Ruhe zu
verdauen, ohne Dinge zu überspringen und -wie bei Romanen- die letzte
Seite am Anfang zu lesen. Es bringt nichts.
Nun schau´n wir mal, was wir zum programmieren brauchen:
-Der ASSEMBLER ist das Programm, das die Listings mit ihren Befehlen (ADD,
SUB,...), für den Programmierer lesbar, in das Äquivalente von binären
Zahlen übersetzt (für den Microprozessor lesbar). So wird z.B. der Befehl
"RTS" in $4e75 übersetzt, usw. Das macht programmieren halbwegs
menschlich, denn stellt euch vor, ihr müßtet jeden Befehl als Nummer
auswendig wissen! Das würde programmieren in reiner MS bedeuten, es ist
aber klar, daß es viel besser ist, in ASSEMBLY zu tippen! Der nun
entstandene binäre Code wird Objekt-Code genannt und ist direkt vom
Computer ausführbar. Man kann ihn als ausführbares File abspeichern oder
direkt testen. Ach ja, erinnert euch auch, daß in Assembler die
Numerierung in Hexadezimal gängig ist! Hex-Zahlen sind jene, die das
"$"-Symbol am Anfang stehen haben. Sie arbeiten mit der Basis 16, im
Gegensatz zum Dezimalsystem, das mit Basis 10 arbeitet, das heißt, es
kommen auch die Buchstaben A,B,C,D,E,F vor, wie im vorherigen Beispiel
$4e75. Es ist egal, ob die Buchstaben groß oder klein geschrieben sind,
$4e75 ist identisch mit $4E75. Wenn in einem Listing "Grammatik"-Fehler
vorkommen, dann weist uns der Assembler darauf hin. Denn es gibt einige
präzise Regeln, die einzuhalten sind. So z.B. muß ein LABEL (oder
Etikette) am Anfang einer Zeile stehen, es dürfen keine Leerzeichen davor
sein, und es muß mit einem Doppelpunkt (:) enden. Ein korrektes Label
sieht so aus:
PLUTO:
Der Name kann nach Belieben vergeben werden, und PLUTO geht gut, denn es
beinhaltet keine komischen Zeichen wie +-=^ usw, es beginnt am Anfang
einer Zeile und endet mit :. Labels werden im ganzen Programm an "Dinge"
vergeben, und sie dienen dazu, diese Dinge zu merken, sie zu finden, wenn
man sie sucht. Wenn man innerhalb des Programmes einer Reihe von Befehlen
den Namen PLUTO gibt, und dann zu irgend einem Zeitpunkt den Befehl gibt,
Pluto auszuführen, dann werden die Instruktionen darunter abgearbeitet.
Genauso können wir einem Bild oder einem Musikstück ein Label geben. Die
Labels stellen also die Speicherstelle dar, an der etwas liegt, genauso,
wie Städtenamen die geographische Position der selben angibt! Wenn ich
nach Sidney gehen will, dann gehe ich da hin, wo das Label Sidney: steht.
Erinnert euch aber, daß Labels nur uns Codern als Gedächtnisstütze dienen,
der Assembler verwandelt dann alles in Zahlen, seien es nun Befehle oder
Labels (die ja nur Speicherstellen sind und somit eine Adresse, eine
Haus-"Nummer" haben).
Dann gibt´s noch die Befehle, die IMMER von einem oder mehreren
Leerstellen vorangegangen werden muß, besser noch von einem TAB, der
gleich 8 auf einen Schlag macht (es ist die Taste über CTRL), gefolgt von
den Operanden.
Pluto: MOVE.L $10,$20
In diesem Fall ist MOVE.L der Befehl (oder Instruktion), während der erste
Operand $10 ist und der zweite $20. Manche Befehle brauchen nur einen
Operanden, andere überhaupt keinen, z.B.:
CLR.L $10
Nur ein Operand. Befehle wie RTS brauchen z.B. keinen. Dann ist da noch
der Kommentar, der uns hilft, zu erinnern, was wir gerade tun: er wird
immer nach einem Strichpunkt (;) geschrieben.
Pluto: ;LABEL, stellt die Adresse von MOVE dar MOVE.L $10,$20 ;Befehl mit
2 Operanden CLR.L $10 ;Befehl mit 1 Operand RTS ;Befehl ohne Operanden
Die Kommentare werden beim assemblieren verworfen, also könnt ihr
schreiben, was und wieviel ihr wollt, Hauptsache nach dem ;. Das war die
Grammatik. Nach diesen einfachen Regeln wird das Programm erzeugt, und ob
es dann tut, was ihr wolltet, hängt dann ganz von euch ab!
-Ein EDITOR hingegen ist ein Programm, das euch ermöglicht, Texte zu
schreiben und zu modifizieren, in unserem Fall werden wir damit die
Listings schreiben, die ja nichts anderes sind als Text, der die Befehle
(Move, Sub,...) und die Kommentare enthält. Bessere Editoren haben dann
Such- und Ersetzoptionen, mit denen gewisse Zeichenfolgen gesucht und
ersetzt werden können. Normalerweise endet der Filename von ASM-Listings
mit .ASM oder .S. Ich bevorzuge .S, TExte, die zum lesen bestimmt sind,
enden mit .TXT. Der Name des File aber beeinflußt in keiner Weise die
Funktionsweise des Assemblers, der frißt alles.
-Ein MONITOR ist in diesem Fall nicht die Glotze des Computers,sondern ein
anderes Programm, das euch ermöglicht, die Inhalte des Speichers zu sehen,
z.B. was auf Speicherzelle $100 steht usw. Normalerweise haben Monitore
auch einen DISASSEMBLER, das Gegenteil des Assemblers, mit integriert,
das das Sehen des Speichers als Befehlen erlaubt. Er verwandelt also MS in
Assembly, er verwandelt $4e75 in "RTS".
-Ein DEBUGGER, wortwörtlich "Entwanzer", dient dazu, ein Programm Befehl
für Befehl durchzugehen und zu testen. Damit findet man meistens die
Stelle, an der ein Fehler liegt.
Manchmal muß der Objektcode, um einwandfrei unter dem Betriebssystem zu
arbeiten, gelinkt werden, denn ein ausführbares File enthält nicht nur
einen Block von Befehlen, sondern auch Angaben darüber, wie er in den
Speicher geladen werden soll. Das geschieht mit dem LINKER. Das gilt für
.EXE und .COM Files unter MSDOS genauso wie bei allen anderen
Betriebssystemem. Das ist auch der Grund, warum unter Atari oder MacIntosh
Amigafiles nicht gelesen werden, obwohl sie den gleichen Prozessor
besitzen: weil das Format eben anders ist. Speziell unter dem Amiga gibt´s
die HUNKs, und um Objectcode durch Mausklick oder Shellbefehl ausführbar
zu machen, müssen sie gelinkt werden. Zum Glück haben die meisten
Assembler den Linker eingebaut, und ihr müßt euch nicht darum sorgen!
Gut, der Assembler, der diesem Kurs beigefügt ist, der TRASH´M´ONE, hat
einen Editor, einen Assembler, einen Debugger/Monitor und einen Linker!!!
Alles in einem, was will man denn mehr! Es ist die modifizierte PD-Version
des Asmone.
Übrigens, zum Editor, ihr könnt einen Text suchen, indem ihr die Tasten
AMIGA rechts+Shift+S gleichzeitig drückt, oder mit der rechten Maustaste
aus dem Menue die Option SEARCH unter dem Titel "Edit Funkt." auswählt.
Nun erscheint links oben die Schrift "Search for:", wo ihr das -oder
dieWorte eingebt, die ihr suchen wollt. Es kann nützlich werden, z.B. um
die Stelle wiederzufinden, an der ihr aufgehört habt, zu lesen, in diesem
Fall Zeile 592 (wird links unten angezeigt), oder ihr sucht das Wort
"Funkt." oder "Zeile 592" oder was euch grade einfällt.
Natürlich hätten wir normalerweise das Listing mit einem Editor schreiben
müssen und mit einem beliebigen Namen abspeichern.Dann mit einem Assembler
laden, assemblieren und den Objektcode speichern. Um das Programm dann zu
guter Letzt testen zu könne, kommt auch noch das linken dazu. Um es
verändern zu können, wieder mit dem Editor laden, speichern, usw. bis zur
Vergasung. Auf den PC-MS-Dosen ist das so der Fall, und ich hab´s
aufgegeben, dort in Assembly zu programmieren. Aber beim Amiga, mit
Multitasking kann man gleichzeitig Editor und Assembler laden, etc. Und,
als würde das noch nicht reichen, hat jemand den ruhmvollen SEKA erfunden,
ähnlich dem jetzigem ASMONE, der Editor, Assembler und Monitor alles in
einem hatte. Dann ging die Entwicklung weiter zum MasterSeka, dann zum
ASMONE und dann endlos viele, von Hobbyprogrammierern modifizierte,
Versionen dessen. Die zwei verbissensten Verbesserer (die sind wirklich
gut!) sind die TFA die den TFA ASMONE hervorgebracht haben, und DEFTRONIC,
die diesen TRASH´M´ONE ins Leben riefen. Ich habe den von DEFTRONIC
ausgewählt, weil er am wenigsten BUGS (Fehler) hat, denn die meisten
anderen Versionen assemblieren oft saDFSDAF SADFFDSASAD, aber man kann es
ihnen ja nicht verübeln, denn sie tun es ja aus purem Spaß, ohne etwas zu
verdienen!
Das Endergebnis ist also, daß ihr ein Listing eintippen könnt, und dann,
mit ESC, zum Assembler/Monitor überwechseln, und dort (mit "A")
assemblieren oder den Speicherinhalt ansehen, sei es nun als Zahlen oder
als Befehle dargestellt, und zum Schluß -aber nicht weniger interessant-
disassemblieren. Um das ausführbare File direkt abspeichern zu können,
tippt "WO" in der Kommandozeile (das ist die Zeile, die ihr erreicht, wenn
ihr mit ESC den Editor verlasst). Damit keine Verwechslungen auftreten,
stellen wir noch mal klar, daß es einen Unterschied zwischen Listing und
Programm gibt: das Listing ist ein Text, der die Befehle/Anweisungen in
ASM enthält, und es ist mit jedem Editor editierbar, z.B. dem CED oder
GoldED.Das Listing wird durch "W" abgespeichert. Das Programm hingegen ist
das schon assemblierte File, es ist von der WorkBench/Cli/Shell
ausführbar, es hat schon den Hunk angehängt etc. Abspeichern durch "WO".
Der Editor im ASMONE ist also nur ein Editor wie alle anderen, ihr könnt
damit auch die Startup-sequence ändern oder einen Brief an eure Mutti
schreiben.
Alsodann, jetzt werde ich -auf meine Art- mit den Erklärungen fortfahren,
wie der Computer funktioniert.
Derjenige, der alles organisiert ist der Prozessor, oder CPU (Central
Processing Unit), praktisch der Boss...Er führt Befehle aus, in der Tat
besitzt er ein genaues Set von Anweisungen, die er ausführen kann, nur die
und keine anderen. Er geht dabei immer der Reihe nach, erst eine, dann die
nächste, usw., außer man befiehlt ihm, nach weiter vorne oder hinten zu
springen, oder eine Schleife (Loop) auszuführen. Einige Befehle
(Anweisungen) sind: MOVE, das soviel bedeutet wie bewegen, hier aber als
"kopieren" zu interpretieren. Move $10,$20 sagt also "Kopiere das, was in
$10 (Adresse/Speicherzelle) nach $20" aus. Dann CLR, Abkürzung für Clear,
also Lösche, setze auf NULL: CLR $10 -> lösche die Adresse/Zelle $10. Als
Adresse, Speicherzelle oder Zelle meine ich einen Punkt im Speicher, der
dem Prozessor zugänglich ist.
Übrigens, der Prozessor operiert im Speicher!! Erstellen wir also eine Art
"Karte" darüber:
Wenn die Befehle mit Adressen herumhantieren, die kleiner als $200000
sind, dann befinden wir uns im CHIP RAM. Von $000000 bis $80000 befinden
sich die ersten 512kB Chip Ram, also die der alten A500 und A2000, wenn
die Ram aber bis $100000 weitergeht, haben wir 1MB Chip Ram, wie z.B. die
A500+, A600 oder die neueren A2000. Bei den A1200, auffrisierten
(erweiterten) A500+ oder A600 hingegen reicht die Chip Ram bis $200000.
Also sind Befehle unter $200000 in der Chip Ram:
CLR.L $30000 MOVE.L $150000,$1a0000
Das waren Instruktionen, die in der ChipRam arbeiten. Wenn aber mit
Adressen über $200000 gearbeitet wird, dann befinden wir uns in der Fast
Ram. Ein alter A500 mit 1MB Speicher ist in zwei Blöcke zu 512kB (512kB
Fast + 512kB Chip) aufgeteilt:
1) von $000000 bis $80000 ;ersten 512kB CHIP RAM 2) von $c00000 bis
$c80000 ;512kB FAST RAM
Mit Utilities wie SYSINFO könnt ihr feststellen, wie eure Speicherblöcke
verteilt sind.
Dann existieren noch spezielle Speicherzonen, wie in etwa die der ROM,
also des Kickstarts. Die beginnt normalerweise bei $fc0000 für Kick 1.2
und 1.3 und $f80000 für Kick 2.0 und 3.0. Die ROM kann im Gegensatz zur
RAM nur gelesen, nicht aber überschrieben werden. Sie bleibt auch nach
abschalten des Computers intakt.
Eine extrem wichtige Adresse ist noch $DFF000, denn von $DFF000 bis
$DFF1FE sitzen die CUSTOM CHIPS für Grafik und Sound. Um eine Grafik
anzuzeigen oder Musik spielen zu lassen, muß man in die Adressen $DFFXXX
die richtigen Werte schreiben, sonst passiert gar nix. Diese speziellen
Adressen werden auch REGISTER genannt. Probiert mal, in der Kommandozeile
(mit ESC schaltet ihr zwischen Kommandozeile und Editor um!) den Befehl
"=C" einzutippen, ihr werdet eine Zusammenfassung der Register mit ihrer
Adresse erhalten. Die Zahlen sind die Adressen, 000 steht für $DFF000, 100
für $DFF100, und die Namen sind daneben geschrieben, z.B. ist $dff006
VHPOSR, und $dff100 BPLCON0. Diese Adressen kann man entweder nur
beschreiben oder nur lesen, z.B. $dff006 ist nur lesbar, $dff100 nur
beschreibbar. Ihr werdet zwischen Zahl und Namen entweder ein W oder ein R
stehen sehen : W (write) -> nur schreiben, R (read) nur lesen. Andere sind
S (strobe) oder ER (EarlyRead), wir werden sie besprechen, wenn wir sie
verwenden.
Weitere Spezialadressen befinden sich in der Gegend von $bfeXXX, genau
gesehen von $bfe001 bis $bfef01. Sie beziehen sich auf den Chip CIAA, der
verschiedene Dinge beinhaltet, wie den Timer oder die Kontrolle über
verschiedene Ports, z.B. den Parallelport, das ist der, an dem der Drucker
hängt. Analog dazu gibt´s die CIAB, sie hängt an den Adressen $bfdXXX.
In Erinnerung behalten müßt ihr eigentlich nur, daß wenn ihr eine Adresse
vom Typ $bfeXXX, $dfdXXX oder $dffXXX seht, sie sich auf die CustomChips
bezieht, die Farbänderungen auf dem Bilschirm zur Folge haben, oder
Bewegungen von Maus oder Joystick einlesen uvm.
Was die RAM angeht, sei es nun CHIP oder FAST, braucht ihr euch nicht
darum zu kümmern, wo welcher Befehl landet. Das erledigt für uns der
ASMONE, wir müssen lediglich einige LABELs verteilen,um gewisse Stellen zu
markieren, danach ersetzt der Assembler sie mit den realen Adresswerten.
Wen´s interessiert, er kann danach nachschauen, wo die Instruktionen
gelandet sind.
Aber fahren wir mit den Beispielen fort: Es gibt Befehle wie ADD und SUB,
die soviel wie Addition und Subtraktion bedeuten, un so bedeutet z.B. SUB
#10,ENERGIE "ziehe von ENERGIE 10 ab". Weiters Multiplikationen und
Divisionen wie MULS, MULU, DIVS und DIVU und die logischen Operationen OR,
AND NOT und andere. JMP bedeutet JUMP ("Springe"), also springe zu einer
bestimmten Adresse (z.B. JMP $40000), JSR hingegen veranlasst den
Prozessor, zu einer Routine auf einer bestimmten Adresse zu springen und
diese durchzuführen, bis er einem RTS begegnet (JSR "Jump to SubRoutine"
-> "Springe zu SubRoutine"), (RTS "Return from Subroutine" -> "Verlasse
SubRoutine, kehre zurück"). RTS steht also für "komm zurück, die Routine
ist fertig", und die Abarbeitung des Programmes fährt nach dem JSR wieder
fort. BRA tut im Wesentlichen das geliche wie JMP, BSR wie JSR. TST heißt
"Test" (gegenüber NULL), es testet also eine bestimmte Adresse oder ein
Register, ob es NULL ist. Diese Instruktion oder die Instruktion CMP
("Compare", ->Vergleiche), die etwas mit etwas Anderem vergleicht, ist
normalerweise von einem sog. "Bedingtem Sprung" gefolgt: z.B. BEQ ("Branch
if Equal" -> "Springe wenn Bedingung erfüllt") oder BNE ("Branch if not
Equal" -> "Springe wenn Bedingung NICHT erfüllt"). So kann man
verschiedene Verzweigungen erzeügen, hier ein dummes Beispiel:
Anfang: BSR GLOCKEN ; BSR -> springt bis unter das Label "GLOCKEN" ;
danache kommt er hierher zurück und führt WarteMaus aus BSR WarteMaus ;
Wartet, bis Mausknopf gedrückt wird BSR PAVAROTTI RTS ; verläßt das
Programm, kehrt zum ASMONE oder zur Workbench zurück, jenachdem, von wo
aus es gestartet wurde.
WarteMaus: Hier wird kontrolliert, ob der Mausknopf gedrückt wurde. Wenn
NICHT, springt er zu WarteMaus zurück, er läuft praktisch im Kreis, bis
der Mausknopf gedrückt wird, wie ein Hund, der versucht, seinen eigenen
Schwanz zu fangen. In diesem Fall werden wir ein "BNE WarteMaus"
verwenden.
RTS ; Ende der Subroutine, kehre unter das ; aufrufende "BRS" zurück
GLOCKEN: DingDong ; eine Routine, die "DingDong" spielt
RTS
PAVAROTTI: AAAAAAAHHHHHHHHH ; Diese Routine läßt den Pavarotti singen
RTS
END ; zeigt das Ende des Listings an, kann man ; auch weglassen
(Was unter dem END geschrieben wird, wird vom Assembler nicht gelesen)
Also, wenn wir dieses hypotetische Programm starten würden, dann könnten
wir sagen, daß es bei "Anfang" beginnt, und diese Routine die Hauptroutine
ist, die drei UnterRoutinen (SubRoutines, Teile eines Programmes, denen
man einen Namen gibt, z.B. PAVAROTTI) der Reihe nach aufruft: als ertes
würde der Prozessor zu "GLOCKEN" springen und die Glocken läuten lassen,
dann findet er ein RTS, kehrt also unter das BSR GLOCKEN zurück, dort
findet er aber ein weiteres BSR, das, das ihn zu WarteMaus bringt. Dort
bleibt er, bis jemand die Maus drückt (eine Knopf davon, versteht
sich...). Der Prozessor kontrolliert auch eine Milliarde mal, ob der
Mausknopf gedrückt wurde, und erst, wenn das eintrifft, kann er die
Routine verlassen, da der Endloszyklus unterbrochen wird, weil das BNE
nicht mehr wahr ist. Am RTS von WarteMaus angekommen, hüpft er zum
Hauptprogramm zurück, wo ihn schon das nächste BSR erwartet: PAVAROTTI.
Wenn er dann vom Pavarottikonzert zurückkommt, findet er nur mehr ein RTS
vor: für ihn bedeutet das, daß er aussteigen soll, zum ASMONE oder zur
Workbench, jenachdem. Das Programm ist zu ENDE.
Jetzt erkläre ich euch besser, wie der Prozessor sich mit den
verschiedenen Befehlen verhält: Im Falle von "BEQ Label" sprechen wir von
einer Verzweigung, denn an diesem Punkt gibt es zwei Alternativen: stellt
euch einen Baum vor, so einen richtig alten und trockenen ohne Blättern,
eine uralte Eiche mit einem knotigen Stamm, der sich an einem gewissen
Punkt in zwei Äste unterteilt, und jedes der Äste verzweigt sich nochmal
in zwei kleinere Äste, und so weiter. Wenn wir nun am BEQ ankommen, ist
es, als wären wir eine kleine Ameise, die am Anfang des Programmes - also
des Stammes - gestartet ist, wo unser Ameisenhaufen START: steht. Gut, wo
wir nun zur VERZWEIGUNG: gekommen sind, müssen wir wählen, entweder den
linken Ast oder den rechten. Diese Wahl trifft der 68000 auf Grund des
Resultates einer vorherigen Bedingung, praktisch eines CMP oder eines TST:
START: ; Ameisenhaufen im Gras ... ... TST.B LABEL30 ; ist das Byte von
LABEL30 = 0 ??? (Beispielbedingung) BEQ RECHTERAST ; wenn ja, springe zu
RECHTERAST ; wenn nicht (ungleich 0), dann fahre mit LINKERAST fort. (das
bedeutet, das Byte hatte einen Wert zwischen $01 und $FF)
... ; Befehle von LINKERAST ... ...
RTS ; ENDE, wir steigen aus. Wir haben den linken Ast ; genommen.
RECHTERAST: ... ; Befehle vom rechten Ast... ... ... RTS ; Ende, wir haben
den rechten Ast genommen.
In diesem Fall verwenden wir eine Testbedingung (TST, Vergleich mit 0,
oder CMP, vergleich zwischen zwei Operatoren), gefolgt von einem BEQ (wenn
ja, springe...) oder einem BNE (wenn nicht, springe...), um entweder eine
Serie von Befehlen auszuführen oder eine andere. Wir haben das BNE schon
verwendet, um eine Schleife (LOOP) durchzuführen, in der eine gewisse
Anzahl von Instruktionen wiederholt ausgeführt werden, bis nicht eine
bestimmte Kondition (Bedingung) eintrifft, zum Beispiel der Mausdruck.
Eine Schleife kann man vielleicht besser mit einem Roboter vergleichen,
der immer die gleiche Handlung ausführt, auch zig-millionen mal, ohne zu
ermüden oder zu streiken:
GEH IN DIE KÜCHE, KONTROLLIERE, OB DER KUCHEN FERTIG IST, WENN ER NOCH
NICHT FERTIG IST, GEH INS WOHNZIMMER UND ENTLAUSE DEN HUND FÜR 30
SEKUNDEN, DANN GEH IN DIE KÜCHE, KONTROLLIERE, OB DER KUCHEN FERTIG IST,
WENN ER NOCH NICHT FERTIG IST, GEH INS WOHNZIMMER UND ENTLAUSE DEN HUND
FÜR 30 SEKUNDEN, DANN GEH IN DIE KÜCHE, KONTROLLIERE, OB DER KUCHEN FERTIG
IST, WENN ER NOCH NICHT FERTIG IST, GEH INS WOHNZIMMER UND ENTLAUSE DEN
HUND FÜR 30 SEKUNDEN, DANN GEH IN DIE KÜCHE, KONTROLLIERE, OB DER KUCHEN
FERTIG IST, WENN ER NOCH NICHT FERTIG IST, GEH INS WOHNZIMMER UND ENTLAUSE
DEN HUND FÜR 30 SEKUNDEN, DANN
Es ist wohl recht eindeutig, daß sich ein Mensch rebellieren würde, für
die Dauer eines Kuchenbackens dieses Hin und Her ertragen zu müssen. Aber
der 68000 macht keinen Mucks, er wiederholt alles, bis der Kuche endlich
gar ist, also das BEQ eintritt, und der Roboter zur Routine
HOLIHNAUSDEMROHROHNEDIRDIEHÄNDEZUVERBRENNENUNDSTELLIHNAUFDENTISCH:.
Ihr werdet schon ahnen, daß mit einigen Verzweigungen hier und da, auch
innerhalb mehr oder weniger großen LOOPs, recht komplexe Strukturen
entstehen können. Man kann da z.B. an Programme denken, die das Wachsen
einer Stadt simulieren und dafür tausende von Bedingungen in Betracht
ziehen. All dies ist durch Verzweigungen möglich, die Teils mit sich
selbst, Teils mit Schleifen verbunden sind.
Die Äste, also die Brocken von Befehlen, die ausgeführt werden, nachdem
ein BEQ oder ein BNE eingetreten ist, oder einfach weil sie gerade da
waren, als der 68000 vorbeikam, werden ROUTINEN oder SUBROUTINEN genannt.
Es sind also Stücke von Programmen, bestehend aus einer Anzahl von
Befehlen, die ausgeführt werden, wenn eine bestimmte Aufgabe verlangt
wird, bei uns war es der Roboter, der den Kuchen aus dem Rohr holte. Diese
Aufgaben können praktisch in eine eigene Routine gelegt werden, die immer
dann angesprungen wird, wenn ein Kucken aus dem Rohr zu holen ist. Die
Aufgabe von Routinen liegt prinzipiell genau darin, nicht immer einen Teil
des Listings neuschreiben zu müssen, wenn z.B. ein Kuchen aus dem Rohr zu
holen ist. Wir können also diese Serie von Anweisungen, die dazu notwendig
sind, isoliert in eine Routine geben, ihr am Anfang ein Label versetzen
und am Ende ein RTS. Geben wir einer Subroutine eine Definition:
-SUBROUTINE wird folgende Struktur genannt, die aus einem Block von
Befehlen besteht, der von einem LABEL (Belibiger Namen, gefolgt von
Doppelpunkten) vorangegangen wird und mit einem speziellem Befehl, dem RTS
(ReTurn from Subroutine) endet. Sie wird normalerweise mit einem BSR,
gefolgt vom Namen der Subroutine, angesprungen. Nach abarbeiten derselben
fährt das Programm in der Zeile unterhalb des aufrufenden BSR weiter. Das
alles ist mit dem Käptn eines Unterseebootes vergleichbar, der in diesem
Fall das Hauptprogramm darstellt, der durch Verteilen von Ordern
gewissermaßen Subroutinen durchführt, z.B. wenn er im Periskop ein
feindliches Schiff sieht, wird er ein BSR TorpedosLaden durchführen, also
den Befehl geben, die Torpedos scharf zu machen. Bis die Subroutine
TorpedosLaden nicht fertig ist, kann er nicht fortfahren. Wenn er dann die
Mitteilung erhält, daß diese klar sind, wird er mit der Prozedur
fortfahren: BSR SchiffLinks und BSR SchiffRechts, bis es nicht auf der
Schußlinie zum gegnerischen Schiff liegt; das kann man mit einer Schleife
vergleichen, die mit einem CMP SCHIFF,SCHUßLINIE, gefolgt von einem BNE
VERSTELLUBOOT, aufgebaut ist, d.h.: "Ist das Label, die die Position des
feindlichen Schiffs enthält, gleich mit dem Label, die die Position
enthält, die die Torpedos treffen werden (Schußlinie)?" wenn noch nicht
(BNE), dann verstelle noch, also kehre zur Routine zurück, die zuerst
erkennt, ob wir zu weit links oder zu weit rechts sind, und dann
dementsprechend die Routinen SchiffLinks oder ShiffRechts aufruft. Dies
ist mit dem Loop des Roboters vergleichbar, der darauf wartete, daß der
Kuchen gar ist, nur müssen wir hier selbst aktiv die Position erreichen,
wie beim WarteMaus, bei dem wir die Maustaste drücken mußten, um den
Zyklus zu unterbrechen. Wir waren bei der Zielschleife stehengeblieben:
auf einmal giebt der Kommandant den Befehl, die Torpedos zu feuern! (BSR
SCHUßEINS, BSR SCHUßZWEI). BOOOOOOOOM... Es hat funktioniert... überall
liegen Tote rum, Socken schwimmen auf dem Wasser, Witwen und Waisen sind
über ganz Deutschland verstreut (in den Kriegsfilmen sterben immer die
Deutschen...), ein Relikt am Meeresgrund. RUHIG BLUT! Es war nur eine gute
Computersimulation!
Wenn ihr nun in die Logik des Prozessors eingegangen seid, dann ist alles
in Butter. Alles, was ihr auf dem Computer so laufen seht, sei es nun ein
Programm für die Wettervorhersage, ein Demo mit Kuben und Kügelchen, ein
Actionspiel, besteht aus Stücken von Programmen, die zyklisch oder
sequentiell (in einer Schleife oder Nacheinander) aufeinander abfolgen, je
nach Ergebnis der Abfragen wie TST, CMP, BTST. Also ist jede durchgeführte
Operation, auch wenn sie noch so kompliziert und komplex erscheint, eine
Summe von einfachen Abfragen und Verzweigungen, gefolgt von Anweisungen.
Jede Subroutine kann aus vielen, kleineren Subroutinen bestehen, z.B.
HOLDENKUCHENAUSDEMROHR:
HOLDENKUCHENAUSDEMROHR: BSR SchaltDasRohrAus BSR ÖffneDasRohr BSR
NimmDenKuchen (Es ist ja ein Roboter, der verbrennt sich nicht) BSR
LegDenKuchenAufDenTisch
RTS
Jede dieser SubRoutinen kann durch weitere Subroutinen aufgeteilt werden:
SchaltDasRohrAus: BSR GehZumSchalter BSR DrehIhnNachLinks
RTS
Der größte Komfort der SR (Subroutinen) liegt darin, daß man das Programm
in logische Teile gliedern kann, die es somit klarer und einfacher
gestaten, und daß man Sammlungen von ihnen anlegen kann, die immer
wiederverwenden kann, z.B. eine Joystickabfrage. Diese kann man in jedem
Spiel einfügen, muß vielleicht einige leichte Änderungen daran vornehmen,
aber die größte Arbeit ist getan. Das gleiche gilt für Musikroutinen oder
SR, die ein Männchen bewegen.
Damit wollte ich euch eine Idee verschaffen, wie der arme Prozessor hin-
und hergejagt wird, je nach Ausgang einer Abfrage. Wenn bei diesem
Hinundhergehüpfe dann mal ein Fehler auftritt, z.B. fehlerhaft geladene
Daten von der Disk oder wo Programmierer versagt hat, dann tritt das
mythische GURU MEDITATION bzw. SOFTWARE FAILURE in seinem unheimlich
leuchtendem rotem Fenster auf. Der RAM-Speicher kann man beschreiben, er
wird, wie schon gesagt, in FAST und CHIP aufgeteilt. Der Unterschied liegt
darin, daß Grafiken und SOUND unbedingt in die CHIP-RAM gelegt werden
müssen, während Instruktionen für den Prozessor genausogut in FAST wie IN
CHIP leben. Z.B. hat der alte A500 mit Kick 1.2 oder 1.3 512kB Ram, und
wenn man ihn erweitert insgesamt 1MB, aber die ersten 512kB sind CHIP, die
anderen FAST! Deswegen endet der Speicher unter DeluxePaint bei einem A500
mit 1MB schneller als bei einem A500+, der den ganzen 1MB nur CHIP hat.
Beim A500 sind die 512kB FastRam übrig, sie sind zum Öffnen von Fenstern
ungeeignet, deswegen meldet er, daß kein Speicher mehr frei ist. Wenn man
programmiert, und versucht, Grafik in die FAST-RAM zu legen, dann passiert
so ziemlich alles, aber es wird keine Grafik angezeigt. Der Speicher ist
in Blöcke aufgeteilt, beim A500 geht er von $00000 bis $80000, und die
512kB Erweiterungsspeicher von $c00000 bis $c80000: das Betriebssystem
weiß genau, wie der Speicher verteilt ist, und es legt ein Programm, das
von der Workbench oder von der CLI/Shell geladen wurde, je nach
Anforderung in Chip oder Fast. Danach springt der Prozessor an diesen
Punkt und beginnt mit der Abarbeitung. Dem Anwender bleibt aber unklar, wo
sein Programm hingeladen wurde und wo der Prozessor gerade arbeitet. Ich
ahbe gesagt, daß der Speicher beim A500 von $00000 bis $80000 geht, der
Speicher ist in der Tat in Teile zerlegt, wie eine Straße mit vielen
Häusern, von denen jedes eine Adresse hat: nicht ohne Grund heißen die
Adressen (Adress, in englisch): Am Anfang der Straße ist das Haus mit der
Nummer 0, dann Nummer 1, usw. Es wird aber das Hexadezimalsystem
verwendet, also mit Basis 16. Aber das ist kein Problem, denn unter dem
ASMONE kann man jede Hexziffer sofort konvertieren, indem man den "?"
verwendet: ?$80000 ergibt 524288 in Dezimal, also 512*1024, also ein
halber kB, "ein halbes Kilo", multipliziert mit 1024 (-> 1kB), das dann
einen halben Mega ergibt. $100000 hingegen ist das doppelte, probiert mal
?$80000*2 ("*" -> "Mal", multiplikation). Die Hexzahlen werden von einem
Dollarzeichen angeführt, wie ihr gesehen habt, die Dezimalzahlen von
nichts, die Binärzahlen von einem %. Diese Dinge sind von grundlegender
Bedeutung: so, wie es für die Distanz das Meter, den Dezimeter und den
Zentimeter gibt, gibt es für den Speicher des BIT, das BYTE, das WORD und
das LONGWORD. Das Bit ist die kleinste Einheit im Speicher. Ein Byte
besteht aus 8 Bit, und das ist eine Einheit, die eine Adresse besitzt:
Hier kann der Prozessor sagen: Bewege (oder besser: kopiere) das Byte aus
dem Haus in der Speicherallee Nr. 10 in das Haus in der Speicherallee Nr.
16. In diesem Fall hat er die acht Bit, die im Byte 10 (also $A in
Hexadezimal) enthlaten waren, ins Byte 16 kopiert. Um Durcheinander zu
vermeiden, hier das Beispiel in Zeitlupe: die Bit´s können entweder 0 oder
1 sein; die Bit im Byte 10 waren : 00110110, im Byte 16 hingegen 11110010.
nach dem MOVE.B 10,16 bleibt das Byte 10, wie es war, und das Byte 16 ist
nun 00110110. Das .B nach dem Move deutet an, daß nur ein Byte verschoben
wird, also der kleinste Teil, den wir direkt ansprechen können. Man kann
auch ein MOVE.W oder ein MOVE.L einsetzen, also ein WORD(.W) oder ein
LONGWORD(.L), die nichts anderes sind als: 1 Word = 2 Byte, ein Longword =
4 Byte = 2 Word. Wenn man also ein MOVE.W 10,16 ausführt, dann werden zwei
Bytes kopiert: in die Zelle (Adresse) 16 kommt das Byte von Adresse 10, in
die Zelle 17 das Byte von Adresse 11. Im Falle eines MOVE.L werden 4 Bytes
verstellt: 10->16, 11->17, 12->18, 13->19. Machen wir ein kleines Schema:
VOR dem MOVE.B 16,10 08/09/10/11/12/13/14/15/16/17/18/19/20
W O R T P E D A L
NACH dem MOVE.B 16,10 08/09/10/11/12/13/14/15/16/17/18/19/20
P O R T P E D A L
Wenn wir ein MOVE.L 10,15 08/09/10/11/12/13/14/15/16/17/18/19/20
machen P O R T P O R T A L
In unserem Beispiel waren die Adressen 8, 9, 14, 15 leer, also auf NULL,
während die Adressen 10-13 und 16-20 Werte (in unserem Fall Buchstaben)
enthielten.
Beenden wir das Werk mit einem MOVE.W 8,10 und einem MOVE.W 10,12
08/09/10/11/12/13/14/15/16/17/18/19/20
P O R T A L
Mit vier Befehlen haben wir WORT PEDAL in PORTAL verwandelt!! Scherz
beiseite, fahrt nicht fort bevor ihr nicht in das echte Hirn die
Arbeitsweise des synthetischen Hirns geprägt habt! Probiert ein paar
Spielchen mit den MOVE.x, das tut euch gut! Probiert zum Beispiel NEGER in
REGEN zu verwandeln, oder PAPPIS BART in BARBAPAPA, MEIN HAUS in MEINE
MAUS...
Erinnert euch,daß Prozessoranweisungen immer an geraden Adressen stehen
müssen, wie 2, 4, 6, usw., also an WORD angepasst, sonst geht alles zum
GURU... Um euch die Zweifel zu nehmen: im Speicher sind eine Reihe von
Werten hintereinander gereiht, ob es nun Prozessorbefehle sind oder Daten
für Grafik, Sound, SINUSTAB oder Rollschriften... Im Speicher aber liegen
sie nicht als MOVE.B 10,16 vor, das ist eine Disassemblierte Version, in
Wirklichkeit sieht dieser Befehl so aus: $13 $F9 $00 $00 $00 $0A $00 $00
$00 $10. Er besteht aus 10 Byte, wobei $13F9 in groben Zügen dem MOVE.B
entspricht, $000A der 10 und $00010 der 13 (Hex 0A= 10 dezimal, Hex 10 =
16 dezimal). Auf diese Art besitzt jede Operation ein Bytemuster im
Speicher, sogar NOP, No Operation, -> keine Operation, tut nix, hat
eines:$4e71. Vorausgreifend möchte ich sagen, daß der Prozessor, außer auf
den Speicher zuzugreifen, auch noch Register besitzt: Datenregister und
Adressregister. Insgesamt sind es 16 und jedes ist ein Longword lang (4
Byte). Die Adressregister heißen A0, A1, A2, A3, A4, A5, A6, A7, die
Datenregister D0, D1, D2, D3, D4, D5, D6, D7. Da sich die Registrer
innerhalb des Prozessors befinden, sind sie sehr schnell, auf jeden Fall
schneller, als der Speicher. So ist die Operation MOVE.L d0,d1 schneller
als MOVE.L $100,$200, man bevorzugt also jene, die mit Registern arbeiten.
Die ROM - wie schon gesagt- kann man nicht beschreiben, ein MOVE, das
dorthin schreibt bleibt also effektlos: ein MOVE auf $FC0000 oder auf
$F80000 ist für gar nichts gut. Es ist nur möglich, Routinen auszuführen,
die in der ROM gespeichert sind. Da aber bei jeder Version der Kick ANDERS
ist, darf man ihn NIE DIREKT anspringen. Das Betriebssystem ist so
ausgelegt, daß jede Routine, also Programmstück, das in im Kickstart
enthalten ist, auf die gleiche Art aufgerufen werden kann, egal, um welche
Version es sich handelt und wo im Speicher sie sich befindet: das wird mit
einem JSR, oder JUMP TO SUBROUTINE (Spring zu Adresse xxxx, dann kehre
unter das JSR zurück und fahre dort weiter), gemacht. Die "Schrittweiten"
für die JSR der verschiedenen SR sind fix, starten aber immer bei der
Adresse, die in Adresse 4 enthalten ist. In der Adresse 4 ist also die
richtige Adresse eingetragen, ab welcher sich die SR befinden, und man muß
sich IMMER daran halten, um Routinen des Kickstarts verwenden zu können.
Die Programme, die WorkBench-Fenster öffnen, Buchstaben auf den Bildschirm
schreiben oder Files von einer Disk lesen oder auf eine Disk schreiben,
müssen jedesmal auf solche SR im Chip des Kick zugreifen, und ihnen z.B.
den Namen des Files übermitteln, den man öffnen möckte oder die Größe des
Fensters... Wenn ein Spiel, ein Programm oder ein Demo das Betriebssystem
überspringt, es also nicht verwendet, dann werden keine Aufrufe zum
Kickstart gemacht. Ein Beispiel ist das bekannte XCopy, das einen eigenen
Screen öffnet, eindeutig das Multitasking über den Haufen wirft, keine
WorkBenchfenster hat und auch keine Rechte-Maus-Taste-Menüs, wie sie aus
dem AmigaDOS bekannt sind. Genauso würde ein Spiel, wie ich einige vorher
angeführt habe, z.B. SENSIBLE SOCCER, funktionien, wenn man den Kickstart
nach dem BOOT (Start) entfernen würde, da es keine Routinen aufgerufen
werden, die ein File laden oder ein Fenster öffnen. Die Dinge, die am
Bildschirm erscheinen, werden Eins nach dem anderen kontrolliert, und die
Daten werden nicht als DOS-Files von der Diskette geladen, sondern als
Spuren, die direkt über den Lesekopf eingelesen werden, der wiederum "von
Hand" gesteuert wird, indem man an den verschiedenen Pin des DRIVE
Spannung anlegt oder nicht (natürlich softwaremäßig). Leuchtet diese
Differenz ein?? Zwischen Programmen und Spielen, die dauernd
Kickstart-Routinen verwenden, deswegen in Multitasking laufen und den
Programmen, die keine Fenster verwenden, oder zumindest nicht die der
Workbench, und nicht mit DeluxePaint im Hintergrund laufen, und die es
nicht erlauben, zwischen den Applikationen umzuschalten oder einfach das
Fenster herunterzuziehen?? Kurzum, die ROM kümmert sich darum, für uns mit
der HARDWARE in Kommunikation zu bleiben, und sie führt einige
vordefinierte Dinge aus, aber wenn wir beschließen, selbst mit der
Hardware in Kontakt zu treten, können wir alles Mögliche tun, Hauptsache,
wir sind es im Stande!!!
Wir werden uns daum bemühen, Code ohne ROM-Unterstützung zu erzeugen. Aber
dann verwenden wir nur den Prozessor? Und wie zeigt man da eine Grafik an
oder läßt Musik spielen? Mit vielen MOVE??? Jetzt kommen die CUSTOM-CHIPS
ins Spiel!! Diese Chips heißen PAULA, AGNUS und DENISE, außerdem noch zwei
weitere, CIAA und CIAB genannt. Diese Schlaumeier sind dafür zuständig,
den Amiga aufspielen zu lassen und die Farben auf den Schirm zu bringen.
Die meisten Register, die zu deren Kontrolle notwendig sind, befinden sich
auf den Adressen zwischen $DFF000 und $DFF1FE, die anderen, die mit den
Serialund Parallelport und den Disk Drive zu tun haben, sitzen auf $BFExxx
und $BFDxxx. Wenn man einmal die Befehle des 68000 gelernt hat, kann man
Programme so groß wie einen Berg schreiben, aber es wird noch nichts
angezeigt oder gespielt. Mit dem Prozessor muß man diese Chips ansteuern;
einer davon ist der BLITTER, der die Aufgabe hat, Linien zu zeichnen,
Speicherstücke wie Scrolls oder Männchen auf dem Bildschirm rumzukopieren,
Flächen zu füllen (Die 3d Körper werden mit dem Blitter gezeichnet und
gefüllt; der Prozessor kümmert sich nur darum, die Koordinaten zu
errechnen, den Rest macht der Blitter). Derjenige, der jedoch alles
anzeigt und die Farben bestimmt ist der COPPER: um ein Beispiel zu machen,
$DFF180 entspricht der Farbe 0, $DFF182 der Farbe 2, während in $DFF006
die Linie gespeichert ist, die der Elektronenstrahl gerade auf den
Bildschirm malt. Dieser wird 50 mal in der Sekunde neu erstellt. Diese
Register sind entweder nur zum Lesen oder nur zum Schreiben: in das
Register $DFF180 kann man nur einen Wert hineinschreiben, aber keinen
auslesen (um zu erfahren, welche Farbe gerade Farbe 0 ist...), während
$DFF006 nur lesbar ist. Um die Position des Elektronenstrahls zu verändern
gibt es aber ein bestimmtes Register, genauso wie für viele andere. Mit
den Registern $BFExxx kann man die Ports kontrollieren, unter anderem die
Maus: z.B. entspricht Bit 6 der Adresse $BFE001 dem Status des linken
Mausknopfes, ob er gedrückt ist oder nicht. Man kann dieses Bit mittels
Prozessors kontrollieren und abwarten, bis der Mausknopf gedrückt wird,
bevor das Programm verlassen wird. Und das wird das erste Beispiel des
Kurses sein, das Du analysieren kannst, indem Du Lektion1a.s ladest. Es
beinhaltet eine Schleife mit dem 68000, die Verwendung eines
$DFFxxx-Registers und eines $BFExxx-Registers. Ladet es in einen anderen
Textbuffer, wie weiter unten erklärt.
Eine kleine Anmerkung, wie man den Assembler - in unserem Fall den ASMONE
-verwendet: Am Anfang wird man entscheiden, ob CHIP- oder FAST-Speicher
reserviert werden soll. Für die Beispiele des Kurses sollte CHIP-RAM
gewählt werden, jenachdem wieviel ihr habt, aber mindestens 250kB. Um eine
Directory oder ein anderes Laufwerk auszuwählen, tippe "V", z.B. um in die
Directory der Lektionen zu kommen, tippt "V df0:Lektionen", um in die
Directory der Listings zu gelangen "V df0:Listings". Um nun ein Listing zu
lesen, gibt es den Befehl "R". Wählt ein Listing im Fenster aus. Mit ESC
wechselt man zwichen Editor und Kommandozeile. Drückt also ESC, und ihr
könnt das Listing verändern, dann nochmal, und ihr seit wieder in der
Kommandozeile, wo ihr das Listing ASSEMBLIEREN könnt. Dafür verwendet den
Befehl "A" (wie "Assemblieren"...), danach, um es auszuführen, "J", wie
"JSR"!! Ihr könnt bis zu 10 Texte gleichzeitig laden, wenn ihr im
EDIT-Modus seit, könnt ihr mit den Tasten F1...F10 zwischen den
verschiedenen Textbuffern (Textfenstern) herumspringen. So könnt ihr im
Ersten die Lektion1.TXT laden, im zweiten (F2) das erste Beispiel,
Listing1a.s, im Dritten (F3) das nächste (Listing1b.s) usw. Wenn ihr was
vergessen habt, könnt ihr mit F1 wieder zum Text springen und nachlesen.
Anmerkung: um seitenweise rauf oder runter zu gehen, verwendet die
Pfeiltasten + SHIFT, für die, die keinen C64 hatten, es ist die große
Taste über ALT, die mit dem Pfeil. Nun erkläre ich euch, was passiert,
wenn ihr "A" eingebt: das Listing (oder Source-Code) ist in stinknormalem
Textformat und besteht aus Schlüsselworten, die die Befehle sind oder
anderen Zeichen, die der Assembler kennt. Um eine Gruppe von Befehlen,
eine "Variabel", den Beginn einer Tabelle zu kennzeichnen oder jeglichen
Anhaltspunkt im Listing zu haben, werden Namen mit Doppelpunkten vergeben,
eben dem LABEL oder ETIKETTEN. Der Name des Label kann beliebig sein, er
darf aber nicht gleich einem 68000er Befehl sein!! Beispiel:
WAITMOUSE: ;das Label
btst #6,$bfe001 ;Linke Taste gedrückt?
bne.s WAITMOUSE ;wenn nicht, zurück zu WAITMOUSE
;(wiederhole das btst)
RTS ;Ende, steig aus
Ich erinnere euch daran, daß die von Befehle mindestens einer Leerstelle
vorangegangen werden müssen. Ich habe ein TAB genommen, das gleich 8
Leerzeichen auf einem Schlag erledigt. Achtet auch darauf, daß KEINE
Doppelpunkte gesetzt werden, wenn ein LABEL aufgerufen wird, NUR wenn sie
selbst erzeugt wird. Also, einmal editiert wird das Listing assembliert,
das geschieht durch "A"; diese Operation läßt den ASMONE den Text lesen,
und der verwandelt ihn in CODE, den der 68000er lesen kann. Einmal
assembliert, ist der Code in einem Teil des Speichers, der mit "=R"
gelesen werden kann, und mit "J" springt der Prozessor auf diesen Punkt
und führt unser Programm aus. Wenn vom ASMONE ein Fehler gefunden wird,
assembliert er nicht zu Ende, bis der Fehler nicht behoben wurde. Die
Listings, die im Kurs enthalten sind, funktionieren auch mit anderen
Assemblern, wie dem DEVPAC3 oder dem MASTERSEKA, mit allen Kickstart und
mit allen Amigas, auch denen mit dem AGA-Chipset, den A1200 und dem A4000.
Wenn ihr die Funktion von Listing1a.s überprüft habt, ladet "Lektion2.TXT"
in einen anderen Textbuffer (F3, z.B). Verwendet dazu "R".
Sollte es an Speicher mangeln, wenn ihr zwischen den Buffern
herumschaltet, dann bedeutet das, daß ihr am Anfang (bei ALLOCATE), zuviel
reserviert habt, und euch nicht genug für die RAM DISK übrig geblieben
ist. Wählt das nächste Mal weniger aus.