Amiga ISO Collection

home *** CD-ROM | disk | FTP | other *** search

/ Amiga ISO Collection / AmigaDemoCD1.iso / DEMOS / ?-NamelessIssue4.DMS / ?-NamelessIssue4.adf / SOFTWARE / Kurs.pp / Kurs

Wrap

Text File | 1991-01-14 | 18.1 KB | 376 lines

@UB Teil -3- des Assemblerkurses von Ulf Zschukelt ........... @CO30 ReDaX -- Weiß der Teufel warum ich in der No. 3 diesen dritten Teil des umfangreichen Kurses vergessen hatte aufzunehmen. Hiermit hole ich dies nach. Infolge Platzmangel ist es mir allerdings nicht mehr möglich das Beiwerk zu dem Kurs, also Beispielprogis usw. auf die NameLess zu packen. Daher mein Angebot. Wer mir 1.50 DM in Briefmarken zuschickt bekommt die Bewispielprogis für diesen Kurs auf einer gesonderten Disk geliefert. Bei diesem Preis lege ich, wie leicht nachzurechnen ist, drauf -- ist mir aber die Mühe von Ulf wert. Für Leute (die es leider immer gibt) die meinen auf diese Weise an eine billige Disk zu kommen, ist dies nicht profitabel -- also kann ich das Angebot ruhigen Gewissens machen, - es werden sich hier vermutlich dann nur Programmierer mit echtem Interesse melden. Also nur zu .... @NS @CO30 *************************************************** * Copyright by SSC-Software * * c/o Ulf Zschuckelt * * Karl-Marx-Straße 1 * * O-8403 Nünchritz * * BR Deutschland * * Tel. (49) 035265-6791 * * * * Konto: 43305074 * * Kreissparkasse Riesa * * BLZ 85054982 * * * * Die Texte dürfen nur komplett weitergegeben * * oder nur mit meiner Zustimmung in anderen * * Serien veröffendlicht werden ! * * Diesen Kurs giebt es für alle kostenlos. Wer * * ihn gut findet und etwas damit anfangen kann, * * sollte mich freundlicher Weise mit neuen Pro- * * grammen oder finanziell unter stützen. Ich * * mußte für diesen Kurs viele Tage arbeiten !!! * *************************************************** @CO20 !! Rechtschreibfehler werden z.B. im DUDEN berichtigt !! ASSEMBLERKURS FÜR AMIGA (TEIL 3) Autor: Ulf Zschuckelt -------------------------------- Datum: 06.12.92 Thema: Scrolldemo System: AMIGA mit OS 2.0 1.Vorwort --------- Die Grundlage für schnelle Spiele ist das schnelle Scrolling von Grafiken über den Bildschirm in alle Richtungen. Auf Grund seiner Hardwarestruktur ist der AMIGA dazu ohne Probleme sehr gut zu gebrauchen. Es muß dabei nicht, wie bei anderen Computern, das ganze Bild verschoben werden. Der Copper kann uns die Arbeit abnehmen, indem er Startadressen des Bildschirms lädt und somit nur einen Ausschnitt auf dem Speicher zeigt. Es wird ein Bild mit 50 Hz dargestellt ohne die CPU zu beanspruchen. Mit Hilfe des Blitters kann dann in das Bild beliebige Grafik ein gearbeitet werden. Der Blitter kann wiederum ohne die CPU arbeiten. Zu Blitter-Arbeiten kommt eventuell noch ein Kurs. Aber es soll ja jetzt nur am das Scrolling gehen. Nach diesem Teil meines Assemblerkurses werde ich an meinem ersten Spielprojekt arbeiten. Später giebt es dann wieder Assemblerkurse (Blitter usw.). Dann werden sich schon 256 Farben über den Bildschirm quälen (A1200 und A4000 !!!). Das Beispielprogramm und das Bild (Kim.ILBM) sind gepackt. Also ein wenig Ausdauer. Die Datei "Kim" sind die reinen Bitplane-Bilddaten, die für den Quelltext benötigt werden. Das Scrolling kann auf 7 MHz AMIGAs unter Umständen mal stocken, da die Synchronisation sehr einfach gemacht ist. Das läßt sich auch noch änder. Das würde aber den Rahmen des Kures sprengen. Alles müßte auch unter Kickstart 1.3 laufen. Hab es aber nicht ausprobiert. Ich wünsche euch viel Erfolg beim Programmieren. Mal sehen, was ihr daraus macht ?! Ulf Zschuckelt 2.Beispielprogramm ------------------ 2.1.Grundprinzip ---------------- Das ganze Prinzip läuft wieder auf unseren guten alten Copper heraus. Der AMIGA hat immer eine Copperliste aktiv, in der das Bild aufgebaut wird. Wir erstellen uns auch eine Copperliste, die unser gewünschtes Bild aufbaut. Dieses Bild hat eine Größe von 640 x 512 Pixeln. Unser Bildschirm ist auf 320 x 256 Pixel eingestellt, so das wir wir nur ¼ des Bildes sehen. Um Alles sehen zukönnen mußen wir im Bild rollen. Dies erfolgt pixelweise wie beim Scrollen großer Lanschaften in Spielen. Die Routinen sollen ja auch in einem Spiel verwendet werden. Man muß dabei nur die Werte in der Copperliste verändern. Der Copper steuert dann den Bildaufbau so, daß 50 mal in der Sekunde das Bild aufgebaut wird. 2.2.Hardwaresteurung -------------------- Ich möchte zunächst alle Hardwareregister, die ich noch nicht erklärt haben, erklären. Ich beschränke mich dabei auf die, die in dem Beispielprohgramm benötigt werden. Ab $0e0 (plus Basisadresse $dff000) beginnen die Zeiger für die 6 möglichen Bitplanes. Das sind immer 4 Bytes, wobei das höherwertige Wort als erstes geschrieben wird. Hier werden die Anfangsadressen der Bitplanes des Bildes eingetragen, die sich auf der Größe des Bildes errechnen. Die Moduleregister für die geraden und ungeraden Bitplanes ($108 und $10a) legen fest wieviel Datenworte nach dem Aufbau einer Zeile übersprungen werden sollen. Dies ist wichtig, wenn wie in unserem Beispiel ein Ausschnitt aus einem übergroßen Bild dargestellt werden soll. Bei solchen Bildern beginnt für unseren Bildschirm die nächste Zeile erst später, da er nicht so breit ist. Die Modulowerte werden getrennt für gerade und ungerade Bitplanes eingegeben. Dadurch ist es uns möglich rechteckige Ausschnitte aus Bilder darzustellen. Die DIWSTRT ($08e) und DIWSTOP ($090) legen die Position und die Größe des Bildchirmfensters. Um einen normalen Bildschirm zu erhalten werden hier $3081 und $30c1 eingetragen. Die DDFSTRT ($092) und DDFSTOP ($094) legen den Start bzw. Stop des DMA fest. Es wird dabei festgelegt, wann horizontal mir dem Lesen von Daten begonnen bzw. geendet wird. Für einen normalen Bildschirm gibt es auch hier Standardwerte: $0038 und $00d0. Um unser Bild mit einem Joystick steuern zu können. Das erfolgt über das JAOYDAT1-Register ($dff00c). Wie daraus nun die nötigen Infos gewonnen werden wird in der Erklärung zum Quelltext erläutert. 2.3.Der Quelltext ----------------- 2.3.1 Vorprogramm ----------------- Als erstes werden alle Basepointer festgelegt. Das ganze spart kostbare Rechenzeit beim späteren Aufruf der Werte und macht es alles etwas übersichtlicher. Es werden nun die wichtigsten Größen zu Arbeit festgelegt: planesize: equ 40*256 ;Größe der Bit-Plane picsize: equ 80*512 ;Größe des Bildes clsize: equ 10*4 ;Länge der Copperliste chip: equ 2 ;Chip-Memory anfordern Der Bildschirm hat also eine Größe von 320 x 256 Pixel, was der normalen LO-RES-Auflösung entspricht. In horizontaler Richtung hat ein Byte 8 Pixel, also ist der Bildschirm 40 Bytes breit und 256 Zeilen hoch. Eine Bitplane hat somit 40*256 Bytes. Das gesamte Bild, das sich im Seicher befindet ist aber 640 x 512 Pixel groß. Eine Bitplane des Bildes hat eine Größe von 80*512 Bytes. Die Bilddaten und die Copperliste müssen sich im Chip-Memory befinden. Dieser wird mit Hilfe des Betriebssystems angefordert. Wenn man einen AMIGA mit Fast-Memory hat, ist es möglich, daß das Programm nicht in den Fast-Memory geladen wird. Dort ist es für die Coprozessoren des AMIGAS nicht mehr erreichbar. Es wird also in reservierten Speicher kopiert. Es wird der Platz für 4 Bitplanes angefordert. Es sind dadurch 16 Farben, die in unserem Beispiel GRaustufen sind, möglich. Für unsere Copperliste muß auch der Speicher angefordert werden. Der Copper soll den Bildaufbau steuern. Er muß also die Bitplanezeiger für 4 Bitplanes beschreiben. Das würde ungefähr so aussehen: AdrPlanexH = Adresse der Plane x , Bits 16-20 AdrPlanexL = Adresse der Plane x , Bits 0-15 move #AdrPlane1H,BPL1PTH ;Zeiger auf Bit-plane 1 setzen move #AdrPlane1L,BPL1PTL move #AdrPlane2H,BPL2PTH ;Zeiger auf Bit-plane 2 setzen move #AdrPlane2L,BPL2PTL move #AdrPlane3H,BPL3PTH ;Zeiger auf Bit-plane 3 setzen move #AdrPlane3L,BPL3PTL move #AdrPlane4H,BPL4PTH ;Zeiger auf Bit-plane 4 setzen move #AdrPlane4L,BPL4PTL wait ($ff,$fe) ;Ende der Copperliste Das Programm berechnet unsere Copperliste automatisch. Für andere Bildgrößen müßte es eventuell nur in der Anzahl der Bitplanes und der Länge des zu reservierenden Speichers verändert werden. Jetzt kommt ein Teil, woran sehr viele Programmieren nicht gedacht haben. Wieso denn auch ? Es läuft ja alles 1A bei ihnen. Das Problem ist, das ich bei vielen Programmen Probleme habe diese vom Productivity-Modus (nur mit Multi-Syncron-Monitor) aus gut nutzen zu können. Es entsteht dann der absolute Garfikmatsch, weil nicht korekt auf den Standard-Modus umgeschaltet wird. Alle Hardware-Hacker sollten es mal so versuchen, wie ich es versucht habe. Ich öffnen einen Screen mit 320 x 256 Punkten und 2 Farben. Das ganze verbraucht zwar etwas Speicherplatz, ist aber die sicherste Methode alles für den benötigten Screen umzuschalten. Nach dem Schließen diese Screens ist man wieder in dem Bildschirmmodus, wo man vor dem Start war. Geschwindigkeitsverlust für das später Programm bring das nicht, da dieser Bildschirm später unterdückt wird, wenn wir einen eigenen Bildschirm aufbauen. 2.3.2.Bildaufbau ---------------- Bevor das Hauptprogramm gestartet wird werden alle im Multitasking laufenden Programme Programme gestoppt, damit die volle Rechenleistung ausgenutzt werden kann. Dies gesschied mit der Exec-Funktion "Forbid". In das Adressregister A5 wird noch die Basisadresse der Hardwareregister $DFF000 geladen. Damit es bei dem Umstellen auf das neu Bild nicht zu Komplikationen kommt wird der DMA-Kontroller jetzt erst einmal gesperrt. Dazu wird in das DMA-Kontrollregister ($96) $01E0 (%0000000111100000) eingetragen. Das DMACON-Register hat folgenden Aufbau: Bit | Funktion ----|--------------------------------------------------------------------- 15 | SET/CLEAR 1: gesetzte Bits werden gesetzt | 0: gesetzte Bits werden gelöscht 14 | Blitter arbeitet gerade 13 | Ergebnis der letzten Blitteroperation war 0 12 | unbelegt 11 | unbelegt 10 | Blitter hat Priorität 9 | Ist dieses Bit gelöscht werden alle anderen Bits als gelöscht ange- | sehen 8 | BitPlane DMA 7 | Copper DMA 6 | Blitter DMA 5 | Sprite DMA 4 | Datenübertragung Disk-Amiga 3 | Soundausgabekanal #3 an 2 | Soundausgabekanal #2 an 1 | Soundausgabekanal #1 an 0 | Soundausgabekanal #0 an Mit dem Befehl werden also Bitplane-, Copper-, Bitter- und Sprite DMA ausgeschaltet. Unserer Copperliste kann jetzt gestartet werden. Die Anfangsadresse wird in das COP1LC-Register eingetragen und er Programmzähler des Coppers zurückgesetzt. Damit unser Bild in den gewünschten Farben erscheint müssen die RGB-Werte der 16 Farben in die Farbtabelle eingetragen werden. Die Farbewerte sind extra angegeben, da die reinen Bilddaten keine Auskunft darüber geben. Ansonsten würde das Bild in den vorher eingestellten Farben erscheinen. Diese Bild sieht dann unter Umständen sehr merkwürdig aus. Es werden die schon oben besprochenen Standartwerte für den Bildschirm eingetragen. DFFSTRT wird jedoch mit $0030 geladen. Der Bitplane-DMA beginnt 8 Taktzyklen eher. Das wird so gemacht, da ansonsten beim horizontalen Scrolling am rechten Rand ein schwarzer Steifen entstehen würde. Es wird ein zusetztliches Datenwort gelesen. Das Bild ist also 16 Punkte breiter. Diese 16 Punkte werden aber nur beim Feinscrolling sichtbar. Das Ganze hat noch einen Nachteil. Es werdem dem Sprite-DMA dadurch 8 Taktzyklen weggenommen, wodurch Sprite #7 nicht mehr genutzt werden kann. Im Bitplane-Kontrollregister ($100) wird festgelegt, welche Auflösung unser Bild haben soll. Es sind 320 x 256 Punkte (LO-RES) und 4 Bitplanes (16 Farben). In das Register wird der Wert %0100001000000000 eingetragen. Das BPLCON0 Regiser hat folgenden Aufbau: Bit | Funktion wenn gesetzt ----|-------------------------------------------------------------------- 15 | HIRES an (640 Punkte in X-Richtung) 14 | Die folgenden 3 Bits geben die Anzahle der Bitplanes an. Es sind 13 | Werte von 0 bis 6 möglich. 12 | 11 | HAM-Modus ein (4096 Farben) 10 | Dual-Playfield an 9 | Videoausgang Farbe an 8 | Genlock an 7 | unbenutzt 6 | SuperHires an (1280 Punkte in X-Richtung) 5 | unbenutzt 4 | unbenutzt 3 | Lightpen Eingang an 2 | Interlace an (512 Punkte in Y-Richtung) 1 | Externe Synchronisation ein 0 | unbenutzt Normalerweise müßte jetzt noch der Modulowert mit 40 eingetragen werden, da der Bildschirm 40 Bytes (320 Punkte) breit ist. Dieser Wert giebt an wieviel Bytes in der Bilddarstellung weitergesprungen werden soll. Da unser ganzes Bild 80 Bytes breit ist muß also 40 Bytes weiter mit der Darstellung der nächsten Zeile begonnen werden. Es wird also immer ein rechteckiger Bereich aus dem übergroßen Bild dargestellt. In dem Fall des Beispielprogramms ist der Modulowert nur 38, weil ja ein zusetzliches Wort gelesen wird. Es sind damit schon 42 Bytes dargestellt. Bis zu nächten Zeile sind es nur noch 38 Bytes. Die Modulowerte werden getrennt für die geraden und ungeraden Bitplanes eingetragen. Es ist jetzt alles für die Darstellung des Bildes eingetragen. Mit "move.w #$8380,dmacon(a5)" werden die DMA-Kontroller eingeschaltes und das Bild erscheint 50 mal in der Sekunde auf dem Bildschirm. 2.3.3. Joystickabfrage und Scrolling ------------------------------------ Um das ganze Programm beenden zu können wird gleichzeitig mit der Joystickabfrage die linke Maustaste abgefragt. Wie das fuktioniert hatten wir schon mal abgehandelt. Das Bild soll mittels Joystick also in alle Richtungen gescrollt werden. dazu muß das Programm in 4 Unterprogramme verzweigt werden. Für jede Richtung giebt es ein eigenen Unterprogramm. Für die Abfrage wird der Inhalt des JOYDAT1-Registers ($DFF00C) benötigt. Die Bits 15 bis 8 enthalten die vertikale und Bits 7 bis 0 die horizontale Position: Bits | 15 14 13 12 11 10 9 8 7 8 5 4 3 2 1 0 ---------|------------------------------------------------- Funktion | Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0 Der Joystick ist nach rechts gedrückt, wenn Bit X1 gesetzt ist. Der Joystick ist nach links gedrückt, wenn Bit Y1 gesetzt ist Der Joystick ist nach hinten gedrückt, wenn nur X0 oder nur X1 gesetzt ist Der Joystick ist nach hinten gedrückt, wenn nur Y0 oder nur Y1 gesetzt ist Die Joystickabfrage ist synchronisiert, d.h. es wird das VPOS-Register, welches die Elektronenstahlposition enthält, ständig abgefragt ob das Vertikal-Blanking erreicht ist. Das ist der Punkt, wo das volle Bild aufgebaut ist und der Elektronenstrahl zum linken oberen Bildschirmrand zurückkehrt. In dieser Zeit ist es am besten das Bild zu scrollen, das der Bildschirmaufbau nicht gestört werden kann, was sich in unangenehmem Blitzen des Bildes äußern kann. Ein weiter Vorteil ist, das der Bildschirm genau 50 Punkte in der Sekunde gescrollt werden kann und nicht schneller oder langsamer. Die Scrollroutinen sind recht lang, da das Bild ja nur bis zu einem bestimmten Punkt gescrollt werden darf. Diese Begrenzung kostet einige Befehle. Das Scrollen nach oben und unten ist denkbar einfach. Der Anfang des Bildes wird nur um eine Zeile (80 Bytes) nach unten oder oben verlegt. Diese neu errechneten Anfangsadresse der Bitplanes werden am Ende der Routine neu in die Copperliste eingetragen. Bei Scrollen nach rechts und links wird es schon etwas koplizierter. Als erstes kann das Bild nur Wortweise (16 Punkte) nach rechts und links verschoben werden, da der DMA-Kontroller nur mit geraden Adressen arbeitet. Abhilfe schafft das BPLCON1-Register ($102), daß ein Feinscrolling um 0 bis 15 Punkte zuläßt. Der Befehl wird mit in die Copperliste eingebunden, damit er beim Bildaufbau berücksichtigt wird. Aufbau des Registers: Bits 4-7 4 Bits für Verschiebung der ungeraden Planes Bits 0-3 4 Bits für Verschiebung der geraden Planes Wenn BPLCON1 mit 0 geladen ist das Bild nicht verschoben. Es wird als schrittweise um 15 Pixel verschoben. Beim 16 Pixel wird das BPLCON1-Register zurückgesetzt und das Bild um ein Wort verschoben. Wie das alles umgesetzt ist sollte man sich im Quelltext direkt anschauen. Das Programm erklärt sich von selbst. Am Ende erfolgt der Rüchsprung in das Hauptprogramm, wo der Joystick und die Maus wieder abgefragt wird. 2.3.4. Nachprogramm ------------------- Es folgen nun die üblichen Routinen um das Programm ordnungsgemäß zu beenden. Es wird die alte Copperliste gestartet und alle Multitasking funktionen eingeschaltet. Der belegte Speich von der Copperliste und dem Bild wird wieder für das Betriebssystem freigegeben. Der "Umschaltscreen" wird geschlossen und als letztes alle benutzten Libraries. Das Datenregister D0 wird gelöscht und das Programm mit "RTS" beendet. 3.Nachwort ---------- Ich möchte mich bei allen Leuten bedanken, die mir bei der Erstellung diese Kurses geholfen haben. Ich hoffe meine Ideen werden von einigen in neuen Programmen angewendet. Wenn ich mit den neuen AMIGAs (A1200 und A4000) zurechtkomme, werde ich den Kurs bestimmt fortsetzen. Bis dahin wünsche ich euch viel Spaß und Erfolg bei euren Progammierarbeiten. * © 1992 SSC-Software * Ulf Zschuckelt