Blitter die Datenschleuder – das Beast, Herzstück des visuellen Amigas [wird upgedatet] | ResearchBlog Swissdigitization

Der Blitter (https://de.wikipedia.org/wiki/Blitter_(Amiga)) ist einer der CustomChips, die den Amiga einzigartig gemacht haben im Homecomputerbereich. Das Herzstück des Amigas der 68000er Prozessor von Motorola ist zwar schnell und mächtig und einfach zu programmieren. Er ist aber – das zeigt der Atari ST – am Anschlag, wenn es darum geht Games mit vielen Objekten zu handeln.

Anders der Amiga – er hat neben peinlichen 8 Sprites – Sonderchips – wie später alle Computermodelle. Und der mächtigste unter ihnen ist der Amiga-Blitter.

Er ist in der Lage grosse Blöcke zu kopieren und zu kombinieren. Dabei meint man mit Blöcken nicht etwa rechteckige Blöcke auf einem Blatt sondern Speicherblöcke also hintereinanderliegender Speicher. Dies ist eine wichtige Einschränkung, was die Programmierung auf Hardwareebene (Assembler), sehr mühsam macht.

Der Blitter besteht prinzipiell aus 4 Kanälen (vgl. DMA), die kombiniert werden können. Die Kombinationsmöglichkeiten lassen sich hier ausprobieren:
http://deadliners.net/BLTCONCheatSheet/index.html

Im obigen Bild sieht man die Möglichkeit der sogenannten Blobs eine Art „HardSoftsprites“. Das heisst die Kombination eines Hintergrunds mit einer Maske und einem Objekt. Dazu braucht der ABlitter das gesamte Potential. Es gibt aber auch die Möglichkeit in der Kombination Dinge zu füllen, zu kopieren etc.

Die Möglichkeiten sind teilweise auch völlig unsinnig und in der Programmierung ist es denn auch schwierig genau zu verstehen, was passiert. Der Chip ist eine Art Black Box.

Konkrete Programmierung

Der Chip funktioniert (und das ganz anders als davor etwa auf dem C64) als eine Art Channelsystem. Das heisst die Konfiguration wird erstellt in dem man sagt, was mit was kombiniert wird etwa als eine Art Befehl in einer Speicherstelle.

Befehl: Channel A ist Source & Channel B ist Destination

Dann definiert man die Speicheradresse für den Source
Dann definiert man die Speicheradresse für die Destination

Jetzt muss man definieren, wie der Chip vorgehen soll, wenn er den Befehl prozessiert. Es wird also angegeben wieviel er springen soll (skip) bei jeder Linie, die er abarbeitet. Der Chip behandelt ja nur Blöcke!

Sind etwa Source und Destination Screens, so muss man eine Zeile (320Pixel/8b) 40 bytes – die Breite des VisuellenBlockes springen – sagen wir 64Pixel (64/8) 8 bytes. Das heisst der Chip springt pro Zeil 8 Bytes und macht da weiter.

Der Befehl wird dann ausgelöst, wenn das Programm die Grösse des Blockes reinschreibt. In unserem Fall wären das 64 Pixel x 64 Pixel (64/8) 8b * 64. Also 512bytes lang.

        move.l #$09f00000,BLTCON0(a6) ; copy command a>d 
	move.l #$ffffffff,BLTAFWM(a6) ; mask 
	move.l ADRESSESOURCE,BLTAPTH(a6) ; source
	move.l ADRESSEDESTINATION,BLTDPTH(a6); target - screen
	move.w #(320-64)/8,BLTAMOD(a6); skip source (in bytes)
	move.w #(320-64)/8,BLTDMOD(a6); ; skip destination (in bytes)
	move.w #(64/8)*64,BLTSIZE(a6) ; size of the block (height*64 + wdith/16)

        (Zur Erklörung: A6 ist die Adresse des Chips)

Die Fehlermöglichkeiten sind dabei unendlich. Und zu allem Überfluss macht der Chip auch immer noch etwas, das dargestellt wird. Das Debugging ist dementsprechend schwierig.

Da der Amiga seine Grafik mit Planes aufbaut, ist die Sache noch komplizierter. Das heisst ein Screen ist aufgeteilt in Ebenen von 0/1. Diese Ebenen werden dann kombiniert und zum Bild. Ist das Bild monochrom dann gibt es eine Ebene. Bei 16 Farben sind es dann 4 Ebenen und 32 Farben 5 Ebenen. Dabei ist jede Ebene 2 hoch x. das heisst die Farben entstehen zusammengestellt: 2^0 + 2^1 + 2^2 + 2^3. Dadurch kann das System erweitert werden, Memory gespart werden und allerlei Tricks gemacht werden: Etwa eine Schrift nur auf einer Ebene scrollen etc. Der Preis dafür ist aber auch ein total kompliziertes System. Anders gesagt, es muss bei 16 Farben die Prozedur jeweils 4mal angewandt werden: Also 4x Kopie auf jedem Layer und alle Grafik muss in diesen gelayerten Planes daherkommen.

Es ist fast schon unglaublich, wie die Entwickler damals dieses „Biest“ in den Griff bekommen haben. Die Stunden müssen hier mal noch evaluiert werden, welche Aufwände da betrieben wurden.

Warten auf den Blitter

Da der Blitter unabhänig vom Rest der Hardware funktioniert (auch hier ein Paradigmenwechsel etwa zum C64) darf nichts in den Chip geschrieben werden. Die Folgen sehen etwa so aus:

Hier wird der Blitter während dem Ausführen mit neuen Daten gefüttert. Es ist also ein Muss zu warten bis der Blitter zu Ende ist. Diese Parallelisierung von Prozessen erfordert eine dynamischere Sicht des Computers als davor, als alles linear war. Das trifft gerade – anders als bei der Demoscene – auf interaktive Games zu, die sich permanent verändern.

Bobs – Blitter Objects – HardwareSimulierte Sprites

Noch komplizierter wird es bei den BOBS. Diese sind eigentliche virtualisierte Sprites ohne deren Vorteile (null Rechenzeit, automatisches Refresh des visuellen Dahinters, kein Flackern, Mangement von Position, Kollision). Dafür sind sie flexibel. Die mageren 8Sprites des Amiga machten es also unumgänglich diesen Chip zu nutzen und so lässt sich vermuten (anhand der Berichte und Texte), dass fast jedes Games diese benutzt haben muss. Eine Analyse der Schweizer Spiele und Demos steht noch aus.

Bobs bestehen bei den Sources den Visuellen Daten und einer Maske – immer gelayered als Planes. Dies sieht dann in etwa wie folgt aus für ein 16×16 Bob:

bob1616_1:		
                ; plane_0
		dc.b %11111111,%11111111,0,0
		dc.b %00000000,%00011110,0,0
                ; x8

                ; plane_1
                [..]
                ; plane_1[..]
                [..]

bob1616_1_mask:
		 ; mask
                 dc.w %1111111111111100,0
		 dc.w %1110001100011100,0
                 ; x8

Man kann nun fragen, warum die Zusatzbytes bei den Planes ,0,0 oder bei der Maske ,0. Dies ist, weil die Bobs ja sich auch horizontal verschieben können müssen. Die Logik ist sonst, dass der Bildschirmspeicher in 8Pixel unterteilt ist. Und so müssen die Bobs zur Seite geschoben (shift) werden, damit sie dann am richtigen Ort wieder reinpassen. Anders gesagt, die Logik des Bildschirms ist in Byte aufgeteilt also 1b ist 8Pixel und alles weitere muss mühsam – hier mit Blitter – verschoben werden.

Und in diese zwei Bytes wird quasi geshiftet. Daraus ergeben sich in der Konfiguration die Hinzunahme von weiteren Channels:

Channel 1: Maske des Bobs (mit 2 bytes mehr)
Channel 2: Visuelle Daten Bobs
Channel 3: Destination mit was kombiniert werden soll (Screen)
Channel 4: Destination, wohin das Resultat geschrieben werden soll

Das führt zu einem Set, das wirklich nicht einfach ist und nur im Resultat slim und logisch aussieht. Aber Stunden, Tage, Wochen braucht bis man es zusammengepuzzelt hat. Veteranen werden selbstverständlich das Gegenteil dazu aussagen. Aber es ist auch schon 35 Jahre her.

Der Code, selbstverständlich müsste dieser erweitert werden auf 4 Planes:

		move.l #$ffff0000,BLTAFWM(a6) ; mask 
			
                move.w	#7,BLTCON1(a6) ;  position x: %16+7<
		or.w	#$0fca,d1	; 	set up the A scroll value and the
		move.w	d1,BLTCON0(a6)	;	minterm for D = notA.C + B
		        
                move.l #bob1616_1_mask,BLTAPTH(a6) ; source maske
	        move.l #bob1616_1,BLTBPTH(a6); ; source bitplane
			
                move.l #Gamescreen+(320+64)/8,BLTCPTH(a6); target source 			                        
                move.l #Gamescreen+(320+64)/8,BLTDPTH(a6); target - screen
			
	        move.w #0,BLTBMOD(a6); skip source (in bytes)			
		move.w #0,BLTAMOD(a6); skip source (in bytes)
		move.w #(320-(16+16))/8,BLTCMOD(a6); ; skip destination (in bytes)
		move.w #(320-(16+16))/8,BLTDMOD(a6); ; skip destination (in bytes)
			
		move.w #16*64+(16+16)/16,BLTSIZE(a6) 
                ; size of the block (height*64 + wdith/16)

Kurzes Fazit

Der Blitter (Teil des Agnus Chips) hat die Art, wie eine Application aufgebaut ist stark verändert und parallelisiert. Und hat die Art wie im Homecomputerbereich Spiele entwickelt wurden verändert, indem er den Blitter statt Sprites in den Vordergrund stellte und damit HardwareSprites auch „virtualisiert“. Der Blitter ist das Ding, warum auch heute der Amiga eine der Demomaschinen par exellence ist. Damit lässt sich immer noch neues finden und rumtrixen. „Amiga!Amiga!“ schreit die Szene da normalerweise.

Der Blitter ist aber auch ein schwer zu kontrollierendes Stück Hardware. Er ist aber auch eine Art Black Box für die Entwickler*. Die Entwickler* geben Macht vom Prozessor – hier dem 68k ab und überlassen es einem CustomChip, parallel etwas zu tun. Dadurch liegt zwar noch alle Macht beim Programmierer* aber eben nicht mehr in seinem Code.

Insofern bleibt fraglich, wer im Vergleich die grössen Cracks waren, die Leute auf dem Atari ST, die aus lausiger Hardware wahnsinnig viel rausholten oder die Amiga-Cracks, die aus einer einzigartigen Hardware auch maximal viel herausgeholt haben. Die Systeme müssen bis heute als eigene Systeme betrachtet werden, auch wenn im Spielemarkt eigentlich beide eher Brüder als zwei Cousins waren.

Anwendungen in CH-Spielen und CH-Demos

Vermutlich muss man eher fragen, wer verwendete den Blitter mit Bobs und Co in Amiga-Spielen!

Dennoch hier ein Beispiel mit vielen Tricks.
https://en.wikipedia.org/wiki/Supaplex

Weiterführende Links

Wem dies alles nur Kratzen an der Oberfläche war, hier weitergehende Links zum Eintauchen ins Datenschleudern:

https://www.stashofcode.fr/afficher-sprites-et-bobs-sur-amiga-2/
https://codetapper.com/amiga/diary-of-a-game/menace/part-5-aliens-2/
https://eab.abime.net/showthread.php?t=68011
https://www.stashofcode.fr/afficher-sprites-et-bobs-sur-amiga-2/
https://www.markwrobel.dk/post/amiga-machine-code-letter7/

ResearchBlog Swissdigitization – Latest findings and outcomes.

Blitter die Datenschleuder – das Beast, Herzstück des visuellen Amigas [wird upgedatet]