                             DAS IFF-ILBM FORMAT
                              (von A. Kroeller)

Eine IFF-Datei kann verschiedene Arten von Informationen enthalten, z.B.
Bilder oder Sounds.

In jeder Datei sind eine oder mehrere sog. Forms enthalten, wobei jede Form
ein eigenes Objekt enthaelt. Eine IFF-Datei kann also auch als Archiv
aufgefasst werden, was aber selten genutzt wird, da die wenigsten Programme
auf bestimmte Teile einer Datei zugreifen koennen, sondern meistens nur auf
das erste.
Eine IFF-Datei ist im allgemeinen so aufgebaut:

   4-Byte ASCII-Text     "FORM"
   4-Byte Longword       Laenge der Form (in Byte)
       .
       :
   Naechste Form oder ende der Datei

Eine Datei kann so mehrere Forms, also mehrere Bilder oder sonstwas,
enthalten.

Als erstes in einer Form stehen 4 Bytes mit einem Ascii-Text, der
die Art der Form angibt, hier koennen z.B. stehen:
   - "ILBM"
   - "ACBM"
   - "8SVX"
Die ersten beiden sind Grafiken, 8SVX Sounds. Es gibt noch weitere Forms, die
aber unbedeutend sind. Hier interessieren uns aber nur die "ILBM"-Dateien,
eine Datei saehe also bisher Folgendermassen aus:
   "FORMxxxxILBM"

Eine ILBM-Form (Interleaved Bitmap) besteht aus unterschiedlichen Chunks,
die die Grafik beschreiben.
Dazu stehen am Anfang eines jeden Chunks 4 Bytes, die den Chunktyp angeben.
Darauf folgt ein 4-Byte-Longword, dass die Laenge des Chunks angibt.

Erklaerung der Chunktypen:

"BMHD" - BitmapHeader:
          ("BMHDxxxx")
	Offset	Typ	*	Bezeichnung
	+000	Word	*	Breite der Grafik in Pixeln
	+002	Word	*	Hoehe der Grafik in Pixeln
	+004	Word		X-Position der Grafik
	+006	Word		Y-Position der Grafik
	+008	Byte	*	Anzahl der Bitplanes
	+009	Byte		Masking
				 0=kein Masking
				 1=Masking
				 2=Transparent
				 3=Lasso
	+010	Byte	*	Datenkompression
				 0=keine Kompression
				 1=ByteRun1-Algorithmus
	+011	Byte		unbenutzt
	+012	Word		Farbnummer der transparenten Farbe
	+014	Byte		X-Aspekt
	+015	Byte		Y-Aspekt
	+016	Word		Breite der Quellseite
	+018	Word		Hoehe der Quellseite
(Hierbei sind fuer reine Grafikviewer nur die mit "*" gekennzeichneten
 interressant)

-------------------------------------------------------------------------------
"CCRT" - Graphicraft Colorcycle Daten:
          ("CCRTxxxx")
	Offset	Typ	*	Bezeichnung
	+000	Word	*	Richtung
				 0=rueckwaerts
				 1=vorwaerts
	+002	Byte	* Startfarbnummer
	+003	Byte	* Endfarbnummer
	+004	Long	* Sekunden
	+008	Long	* Mikrosekunden

-------------------------------------------------------------------------------
"CAMG" - Amiga Viewport Modi
          ("CAMGxxxx")
	Offset	Typ	*	Bezeichnung
	+000	Long	*	Viewportmodi
				Bit 1: Genlock Video
				Bit 2: Interlace
				Bit 6: PFBA
				Bit 7: Extra Halfbrite
				Bit 8: Genlock Audio
				Bit 10: DualPF
				Bit 11: HAM
				Bit 13: VP-Hide
				Bit 14: Sprites
				Bit 15: HiRes
Interessant sind hier vor allem die Bits 2,7,11 und 15.
Bit 2: Gesetzt: Das Bild ist in Interlace darzustellen
Bit 7: Das Bild ist ein HalfBrite-Bild (s.w.u.)
Bit 11: Das Bild ist ein HAM-Bild (s.w.u.)
Bit 15: Das Bild ist in HiRes, also die horizontale Schirmaufloesung ist
        verdoppelt.

-------------------------------------------------------------------------------
"CMAP" - ColorMap
          ("CMAPxxxx")
Hier stehen die Farben, und zwar jeweils 3 Byte pro Farbe, fuer die
Farbnummern von 0 bis (2^Tiefe)-1, maximal jedoch 31, also 5 Bitplanes.
Jedes Byte gibt entweder Rot, Gruen
oder Blaukomponente (in dieser Reihenfolge) der Farbe als Bytewert
von 0-255 an. (0=kein Anteil, 255=voller Anteil)


-------------------------------------------------------------------------------
"BODY" - Bitplanes
          ("BODYxxxx")
Die Bitplanes 0-(Tiefe-1) sind hier gespeichert, und zwar werden die Bytes
einer Bitplane auf dem Monitor zeilenweise angeordnet, also:
   0  1  2  3  4  5  6  7  8  9
  10 11 12 13 14 15 16 17 18 19
  20 21 22 23 24 25 26 27 28 29 (Bei einer 80x3x1-Grafik)

Wenn das Bild im "ByteRun1-Encoding" (->BMHD) gepackt ist, sind nur die
Bitplanes gepackt, und zwar mit Kontrollbytes. Das erste Byte einer
Bitplane ist dann immer ein Kontrollbyte. Jedes K.B. gibt folgendes an:
 x=Wert des Kontrollbytes
 
 x=128   NOP (No operation, sollte eigentlich nicht vorkommen)
 x<128   Die naechsten x Bytes (exklusive Kontrollbyte) sind uncodiert und
         koennen so uebernommen werden, danach folgt das naechste Kontroll-
         byte oder die naechste Bitplane
 x>128   Das naechste Byte soll (257-x)mal in die Bitplane eingefuegt
         werden, danach folgt das naechste Kontrollbyte oder die naechste
         Bitplane

Als Beispiel:
Eine Bitplane sei mit ByteRun1 codiert und beginne so:
005 001 002 003 004 005 254 006 002 007 008.....
decodiert saehe das dann so aus:
001 002 003 004 005 006 006 006 007 008.....
-------------------------------------------------------------------------------
Die einzelnen Chunks muessen nicht in dieser Reihenfolge vorliegen und auch
nicht vollzaehlig vorhanden sein. Die haeufigste Reihenfolge ist
BMHD-CMAP-BODY-CAMG-CCRT, wobei CCRT fast nie enthalten ist.
-------------------------------------------------------------------------------
Erklaerung des HalfBrite und Hold-And-Modify-Modus.

Beide Sonderfaelle haben 6 Bitplanes, abere trotzdem nur eine Farbtabelle
mit 32 bzw. 16 Farben.

HalfBrite:
 Die Farben 0-31 werden der Farbpalette nach normal dargestellt, nur die
 Rot-, Gruen- und Blauwerte der Farben 32-63 entsprechen denen der ersten
 32, sind jedoch halbiert, also um ein Bit verschoben
 (r>>1;g>>1;b>>1)

Hold-And-Modify:
 Dieser Modus hat nur eine 16-Farben-Tabelle. Diese Farben (0-15) werden
 normal dargestellt. Bei den anderen hat der Punkt die selbe Farbe wie der,
 der links davon ist, nur dass eine Komponente veraendert wurde. Punkte in
 der linken Bildschirmspalte haben als Vorgaengerpunkt den Rahmen, also die
 Hintergrundfarbe (Farbnummer 0).

 Farben  0-15: Echtfarben
 Farben 16-31: HAM_Color Type 1, Rotwert wird veraendert (Auf [Farbnr-16] )
 Farben 32-47: HAM_Color Type 2, Gruenwert "      "        "     "    32
 Farben 48-63: HAM_Color Type 3, Blauwert  "      "        "     "    48
