Egyszerre mind a 4096 szín Amigán

"Elősör" egy kis gyorstalpaló az Amiga (non-AGA) képernyőiről, illetve azok színkezeléséről. Az AGA megjelenése előtti Amigák 12-bites (csatornánként 4-bites) színmélységgel bírtak, azaz a teljes színskálájuk 4096 színre rúgott. A gépnek viszont csak paletta-bázisú képernyőmódjai voltak, a hardware maga 32 színregiszterrel bírt, a - planár felépítésű - videomemória maximálisan 6 bitplane-ből állhatott. A planár felépítés azt takarja, hogy a pixelek bitjei nem "pakolva" tárolódtak, pl. '76543210 76543210 76543210 76543210 76543210 76543210 76543210 76543210', hanem "síkokban", szétbontva: '00000000 11111111 22222222 33333333 44444444 55555555 66666666 77777777'. (A számok az egyes pixelek bitjeit jelölik.) Ezt a fajta felépítést ugyan jóval nehézkesebb "egyszerűen" kezelni, mint a chunky felépítést, viszont - többek között - az az előnye, hogy a bitsíkokat egymástól függetlenül is lehet kezelni, (pl. adatmozgatásnál, ha nincs minden síkra szükség, akkor nem kell mindet másolni, vagy a felesleget maszkolni), valamint, hogy a "nem szimmetrikus" (nem kettő hatványú) bitmélységeket így pazarlás és túlbonyolítás nélkül is lehet tárolni. Ennek megfelelően az Amiga nem csak a legtöbb gépen ismert 1, 2 és 4-bites - azaz 2, 4 és 16 színű - üzemmódokat támogatta, hanem a 3 és 5-bites - azaz 8 és 32 színű - felbontásokat is. Eddigre biztos feltűnt már pár kollégának, hogy ha 32 színregisztere van a gépnek, akkor miért állhat a videomemória 6 bitplane-ből? Nos, a hatodik bitplane három esetben van használva. Egyik eset az ún. "Dual-playfield", amikor két darab - egymástól függetlenül kezelt (mozgatott, módosított, stb.) - 3-bites képernyőt használunk egyszerre, amiből a "felül" lévő 7 színű lehet (a 0. szín "átlátszik"), az "alul" lévő pedig 8 színű. (A DPF lehet 2x1 vagy 2x2 bites is, de az értelemszerűen nem fog 6 bitsíkot elfoglalni.) A másik eset, az "Extra Half-Brite" mód (EHB), amikor az alap 32 szín mellett van egy az első 32 színből képzett imaginárius fél-fényerejű szekunder palettánk, azaz, ha a hatodik bitplane-en egy bit 1-es, akkor a hozzátartozó pixel fényereje megfeleződik. A harmadik eset pedig a bennünket jelenleg érdeklő "Hold-And-Modify" mód, innentől HAM, pontosabban HAM6, mert a HAM üzemmód lehet 4, 5, illetve AGA-n 8-bites is. (Bár az 5-bites verzióban csak a kék összetevőt lehet variálni, úgyhogy, kb. szinte semmi sem használja, a 4-bitesben meg csak palette set van, azaz kb. értelmetlen, de pár demo azért használta. Ismert HAM7 néven egy trükk, ahol 7 bitplane-nel inicializálják a HAM módot, de a név csalóka, mert OCS/ECS alatt csak 6 bitplane van - így ez a trükk - a hardware "kiakasztásával" csak 4 bitplane-t használ + 2 bitnyi konstans adatot - AGA-n pedig a HAM5 és HAM7 üzemmódokat már hardware-ből tiltja a gép, ki tudja miért...) A HAM módok lényege, hogy egy pixel nem feltétlenül "standalone", hanem az esetek többségében az előző pixel módosulata. A HAM6 (és az 5 is) úgy működik, hogy van egy 16 színű palettánk, aminek színeivel bárhol lerakhatunk egy pixelt és utána az egyes csatornák összetevőit megváltoztathatjuk, de egyszerre csak egyet. (Illetve HAM5-ben csak a kéket.) Egy HAM6 pixel így néz ki:

54 3210
ii vvvv

Az ii az utasítás, a vvvv az érték, a számok itt is a pixel bitsorszámát jelölik. Az utasítás - értelemszerűen - négyféle lehet:

Az érték az első (00) esetben a színregiszter indexe, a többiben pedig a kiválasztott csatorna új értéke. (És ebből az is kiderült, hogy a HAM5 miért csak a kék összetevőt tudja variálni.) Namármost, ebben a módban igazából mindennemű trükközéssel is ki lehet rakni mind a 4096 színt, csak beállítjuk valamelyik színregisztert feketére, kirakjuk legelsőként, majd egyesével elkezdjük inkrementálgatni a pl. vöröset, aztán, ha elérte a maximumot, akkor két lépésben - és két pixelben - visszavesszük nullára és mellette pl. a zöldet meg inkrementáljuk és - ha mindkettő elérte a maximumot, akkor - ugyanezt a kékkel is, csak azt már három lépésben. Ez azonban így ocsmány, összefolyó lesz, az egyes színek egypixelnyiek, azaz megkülönböztethetetlenek, ráadásul a "váltásoknál" látszani fog a "maszatolás" is. Ennek megfelelően, ha valami ilyesmit szeretnénk csinálni,

ami ki is néz valahogy, akkor bajban leszünk, a "váltások" miatt, hiszen - mint kitárgyaltuk - egyszerre csak egy színösszetevő változtatható meg, azaz, ha nem akarjuk, hogy amikor egyszerre kettőt kell megváltoztatni, akkor maszatoljon, akkor ott nem változtatni kell, hanem a palettát használni. Igen ám, de a paletta csak 16 elemű, "váltás" meg összesen 256 lesz (4096 / 16). Egyszóval már a 256. színnél ki fogunk futni a palettából. Itt jön képbe a Copper nevű co-processor, aminek funkciója, hogy a képernyő elektronsugarának pozíciójával időzítve tudja írkálni az Amiga hardverregisztereit. Mivel színsoronként kemény 4 db "váltás" van, ezért kibökjük mondjuk a 4-7-ig terjedő színregisztereket erre a célra és színsoronként - azaz 4 soronként (mivel egy ilyen négyzet 4x4-es) - újratöltjük őket a következő színsor által igényelt színekkel. Így gyakorlatilag a kék és zöld összetevők cserélgetését a Copper fogja intézni, nekünk a bittérképben csak a vörössel és a palettával kell foglalkoznunk. Ennek megfelelően egy sor bittérképe (egyelőre chunky felírással) így áll össze (itt egy sor egy két "váltás" közti "szekció", de az egész egy színsorhoz tartozik):

00.0100|10.0001|10.0010|10.0011|10.0100|10.0101|10.0110|10.0111|10.1000|10.1001|10.1010|10.1011|10.1100|10.1101|10.1110|10.1111
00.0101|10.0001|10.0010|10.0011|10.0100|10.0101|10.0110|10.0111|10.1000|10.1001|10.1010|10.1011|10.1100|10.1101|10.1110|10.1111
00.0110|10.0001|10.0010|10.0011|10.0100|10.0101|10.0110|10.0111|10.1000|10.1001|10.1010|10.1011|10.1100|10.1101|10.1110|10.1111
00.0111|10.0001|10.0010|10.0011|10.0100|10.0101|10.0110|10.0111|10.1000|10.1001|10.1010|10.1011|10.1100|10.1101|10.1110|10.1111

Illetve, mivel ez így még csak 64 pixel széles, ezért az egyes elemek négyszer fognak ismétlődni. És - mivel a többivel a Copper foglalkozik - ezt kell megismételni 256-szor. Viszont, mivel ez chunky, így ezt még át kell írni planárra. A hat bitplane egy-egy sora tehát hexában így fog kinézni:

plane 0: 0f0f 0f0f 0f0f 0f0f * ff0f 0f0f 0f0f 0f0f * 0f0f 0f0f 0f0f 0f0f * ff0f 0f0f 0f0f 0f0f
plane 1: 00ff 00ff 00ff 00ff * 00ff 00ff 00ff 00ff * f0ff 00ff 00ff 00ff * f0ff 00ff 00ff 00ff
plane 2: f000 ffff 0000 ffff * f000 ffff 0000 ffff * f000 ffff 0000 ffff * f000 ffff 0000 ffff
plane 3: 0000 0000 ffff ffff * 0000 0000 ffff ffff * 0000 0000 ffff ffff * 0000 0000 ffff ffff
plane 4: 0000 0000 0000 0000 * 0000 0000 0000 0000 * 0000 0000 0000 0000 * 0000 0000 0000 0000
plane 5: 0fff ffff ffff ffff * 0fff ffff ffff ffff * 0fff ffff ffff ffff * 0fff ffff ffff ffff

Akkor itt az ideje, hogy kódoljunk is egy kicsit. Nyitásként pl. húzzuk be a szükséges headereket.

#include <exec/types.h>
#include <exec/memory.h>
#include <clib/intuition_protos.h>
#include <clib/graphics_protos.h>
#include <graphics/gfxmacros.h>
#include <hardware/custom.h>

Aztán a main()-ben nyissunk egy HAM6 képernyőt:

struct NewScreen ns;
ns.LeftEdge = 32;
ns.TopEdge = 0;
ns.Width = 256;
ns.Height = 256;
ns.Depth = 6;
ns.DetailPen = DETAILPEN;
ns.BlockPen = BLOCKPEN;
ns.ViewModes = HAM;
ns.Type = SCREENQUIET;
ns.Font = NULL;
ns.DefaultTitle = (void *)"";
ns.Gadgets = NULL;
ns.CustomBitMap = NULL;
struct Screen *screen = OpenScreen(&ns);
SetRGB4(&screen->ViewPort, 0, 0, 0, 0);

Amint látszik, a szokásos 320 pixel széles képernyő helyett direkt egy 32 pixelnyivel eltolt 256 pixeles képernyőt nyitunk, így nem kell a középreigazítással foglalkozni, lehet folyamatosan írni a képernyőmemóriát, bár igazából ez mellékes. A program befejezésekor kell neki egy CloseScreen(screen); meghívás is (legvégén, hibakezelésnél, stb.). Eztán, foglaljunk némi előre törölt memóriát a Chip RAM-ban Copperlist-nek. (Hibakezelést majd mindenki maga.)

struct UCopList *copperlist = (struct UCopList *)AllocMem(sizeof(struct UCopList), MEMF_CHIP|MEMF_PUBLIC|MEMF_CLEAR);

(Gyors magyarázat, hogy mi az a Chip RAM: Amigán alapvetően kétféle RAM van, a custom chipek által is "látott" Chip RAM (maximum 2 MB), illetve a csak a CPU által hozzáférhető Fast RAM (maximum 2 GB, mínusz, ami a különféle címterekkel lejön belőle). Akit jobban érdekel, itt találhat egy memóriatérképet.) Ezután inicializáljuk a listát a CINIT() makró segítségével.

CINIT(copperlist, (64 * 5) + 1);

A második paraméter nem byte-okat, hanem Copper utasításokat takar. A Copper háromféle utasítást ismer:

• Az elektronsugár pozíciójára várakozó WAIT-et
• A regiszterekbe írkáló MOVE-ot
• És az adott feltétel (elektronsugár pozíciója) esetén a következő MOVE utasítást átugró SKIP-et, ami egyébként bennünket most nem érint.

Nekünk 64 színsorunk van és minden színsorban 4 regiszter-írásra van szükségünk, viszont meg is kell várni a következő színsort (minden 4. sor), tehát egy színsorhoz 5 db Copper utasítás fog tartozni. Így jön ki a 64 * 5. A +1 az a lezáró utasítás a lista végén. Kell tehát egy 64 iterációból álló ciklus (pl. for (int i = 0; i < 64; ++i)), amiben a következő utasítások szerepelnek. Először is meg kell várni a megfelelő sort a CWAIT makróval:

CWAIT(copperlist, i << 2, 0);

(Az i négyszerese adja ki mindig a megvárandó sort, lévén egy színsor 4 pixel magas, a vízszintes koordináta pedig nulla, azaz az újratöltéseket a HBlank alatt fogja intézni.) Utána pedig fel kell tölteni a regisztereket a CMOVE makróval:

CMOVE(copperlist, custom.color[4], cc[i]);
CMOVE(copperlist, custom.color[5], cc[i] + 0x10);
CMOVE(copperlist, custom.color[6], cc[i] + 0x20);
CMOVE(copperlist, custom.color[7], cc[i] + 0x30);

A custom a hardware/custom.h headerben található struct Custom struktúrára hivatkozik (extern struct Custom custom;), amit a linker a végén a hardware regiszterekre (0x00dff000) irányít majd át. A cc tömb pedig az egyes színsorok elején szükséges zöld és kék összetevőket tartalmazza, a zöld csatorna menetközbeni inkrementálását pedig helyben adjuk hozzá. Mint a képen látszik, a "mátrix" 64x64-es, azaz egy sorban négyszer megy körbe a vörös és négyszer inkrementálódik a zöld, míg a kék négy soronként lép egyet előre, azaz a táblában a zöldet elemenként néggyel, a kéket meg négy elemenként kell inkrementálni.

const UWORD cc[0x40] =
{
	0x0000,	0x0040,	0x0080,	0x00c0,
	0x0001,	0x0041,	0x0081,	0x00c1,
	0x0002,	0x0042,	0x0082,	0x00c2,
	0x0003,	0x0043,	0x0083,	0x00c3,
	0x0004,	0x0044,	0x0084,	0x00c4,
	0x0005,	0x0045,	0x0085,	0x00c5,
	0x0006,	0x0046,	0x0086,	0x00c6,
	0x0007,	0x0047,	0x0087,	0x00c7,
	0x0008,	0x0048,	0x0088,	0x00c8,
	0x0009,	0x0049,	0x0089,	0x00c9,
	0x000a,	0x004a,	0x008a,	0x00ca,
	0x000b,	0x004b,	0x008b,	0x00cb,
	0x000c,	0x004c,	0x008c,	0x00cc,
	0x000d,	0x004d,	0x008d,	0x00cd,
	0x000e,	0x004e,	0x008e,	0x00ce,
	0x000f,	0x004f,	0x008f,	0x00cf
};

A ciklus után le kell zárni a listát a CEND() makróval. Utána a kapott listát csatolni kell a képernyőhöz úgy, hogy először letiltjuk a taszkváltást a Forbid()-dal, majd a listát belerakjuk az elején megnyitott képernyő ViewPort struktúrájának UCopIns tagjába, utána pedig Permit()-tel feloldjuk a taszkváltási tilalmat, végül újrarajzoltatjuk a képernyőt a RethinkDisplay() meghívásával.

CEND(copperlist);
Forbid();
screen->ViewPort.UCopIns = copperlist;
Permit();
RethinkDisplay();

Ezzel meg is van a Copper része, most már csak a képernyőmemória bitplane-jeit kell feltölteni adattal. Egy sor 256 pixel széles, azaz egy bitplane egy sora 256 bit hosszú, ahogy a fentebbi táblában látszik is. Ha jobban szemügyre vesszük a táblát, akkor kiderül, hogy a 4-es bitplane mindig nulla, a 2-es, 3-as és 5-ös pedig 4 szavanként ismétlődik. Ennek megfelelően a következő LUT-öket tudjuk létrehozni:

const UWORD p0vals[0x10] = {0x0f0f, 0x0f0f, 0x0f0f, 0x0f0f, 0xff0f, 0x0f0f, 0x0f0f, 0x0f0f, 0x0f0f, 0x0f0f, 0x0f0f, 0x0f0f, 0xff0f, 0x0f0f, 0x0f0f, 0x0f0f};
const UWORD p1vals[0x10] = {0x00ff, 0x00ff, 0x00ff, 0x00ff, 0x00ff, 0x00ff, 0x00ff, 0x00ff, 0xf0ff, 0x00ff, 0x00ff, 0x00ff, 0xf0ff, 0x00ff, 0x00ff, 0x00ff};
const UWORD p2vals[0x04] = {0xf000, 0xffff, 0x0000, 0xffff};
const UWORD p3vals[0x04] = {0x0000, 0x0000, 0xffff, 0xffff};
const UWORD p5vals[0x04] = {0x0fff, 0xffff, 0xffff, 0xffff};

(Igen, a 0-ás és 1-es bitplane 2-2 szót leszámítva mindig ugyanaz, de összesen 64 byte-ot spórolnánk meg a LUT-jükön, viszont a ciklust megspékelnénk 4 db komparálással (+ a bitaritmetika és a komparálások közti OR) és utána vagy egy-egy ternary-vel, vagy egy-egy a komparációk eredményével indexelt tömbolvasással (ami +8 byte-ot jelent, tehát úgy csak 56 byte-ot spórolnánk). Több kár, mint haszon.) A képernyő 256x256-os, amit 16 bitenként 4096 körből tudunk végigírni. Előbb azonban szükségünk lesz hat darab pointerre, hogy legyen mivel címezni a bitplane-eket, meg be kell állítani őket az egyes síkok kezdetére.

UWORD *p0 = (UWORD *)&(screen->RastPort.BitMap->Planes[0][0]);
UWORD *p1 = (UWORD *)&(screen->RastPort.BitMap->Planes[1][0]);
UWORD *p2 = (UWORD *)&(screen->RastPort.BitMap->Planes[2][0]);
UWORD *p3 = (UWORD *)&(screen->RastPort.BitMap->Planes[3][0]);
UWORD *p4 = (UWORD *)&(screen->RastPort.BitMap->Planes[4][0]);
UWORD *p5 = (UWORD *)&(screen->RastPort.BitMap->Planes[5][0]);
UBYTE tmp;
for (i = 0; i < 4096; ++i)
{
	tmp = i & 0x0f;
	*p0++ = p0vals[tmp];
	*p1++ = p1vals[tmp];
	tmp &= 0x03;
	*p2++ = p2vals[tmp];
	*p3++ = p3vals[tmp];
	*p4++ = 0x0000;
	*p5++ = p5vals[tmp];
}

Vagy, ha valaki spórolni akar a címregiszterekkel, akkor használhat egy darab pointert is, amit a nullás plane elejére állít be, viszont akkor azt minden kiírásnál 8192 byte-tal kell odébbléptetni, hogy a következő sík aktuális címét megkapjuk, majd az utolsó sík után 40958 byte-tal vissza ((5 * 8192) - 2). Kinek mi tetszik jobban. Ezután már csak várakoztatni kell a programot valami inputra, hogy ne lője le magát azonnal és lássuk is a végeredményt, pl. egér/joystickgombra (while ((*((UBYTE *)0xbfe001) & 0xc0) == 0xc0)), csak ne felejtsünk el időzítést is rakni bele, hogy ne terheljük rommá a rendszert. Erre a célra itt van pl. a Timer unitom, aki akarja viszi. A már futó program WinUAE-ből:

Az A500+-omon vaku nélkül:

Az A500+-omon vakuval:

A program elérhető itt, ha valakit érdekelne. Elméletileg működik minden Amigán, én 1.3-on, 3.1-en, valamint A500+-on és A1200-on teszteltem. Lábjegyzetnek még annyit, hogy bár a Copper egy soron belül is képes várni, a vízszintes minimum, amire várni tud, az 4 pixel, ha alacsony felbontásban vagyunk és 8 pixel, ha magasban, azonfelül maguk az utasítások is időbe kerülnek, 5 bitplane-ig 8 ciklusba (pixelbe), 5 bitplane-en 8 vagy 12 ciklusba, 6 bitplane-en pedig 16-ba. Ez azt jelenti, hogy a kevés színű bitmélységeknél túl sűrűn kéne ahhoz írni a regisztereket, hogy ne essen szét az egész, a sokszínűeken meg túl sok regisztert kéne egyszerre átírni. Arról nem is beszélve, hogy a 0. színregiszter piszkálása a keretszínt is állítani fogja. Ennek megfelelően ezt ilyen egyszerűen csak HAM képernyőn lehet kivitelezni. (Biztos megoldható máshogy is (pl. CPU-ból időzítve az egész regiszterírásosdit), csak az minden lesz, csak triviális nem.) Hát ennyi volt az Amiga/kóderrovat mára. Remélem, ha más nem is, legalább érdekes volt.