Názor k článku Karta EGA: první použitelná barevná grafika na PC od ondra.novacisko.cz - Organizace po bitových rovinách mě v té době jako...

Organizace po bitových rovinách mě v té době jako teenagera zaskočila… (píšu v té době, ale nesmíme zapomenout, že k nám se grafické adaptery EGA/VGA dostali až po roce 1989 a já osobně jsem začínal z 386DX, kde už byla paradajska, která uměla i 256 barev). Bylo to první setkání s I/O mapovanými do paměti, kdy najednou paměť se nechovala tak jak by se chovat měla, tedy co do ní uložím, to z ní vytáhnu.

Do paměti bitových rovin se dalo zapisovat různě, jsou tam tři zápisové a dva čtecí řežimy. Zapisovat lze buď tak, že zapisuju bitovou masku bodů, které se mají nastavit na předem určenou barvu, nebo že nejprve vyberu body, které se mají nastavit a pak zapíšu barvu do paměti.

Důležité pro programování je nutnost vědět, že existují Latch-registry, ty se plní vždy čtecí operací procesoru. Je v danou chvíli jedno, co se přečte, důležitá je adresa čtení, která způsobí naplnění registrů. Při zápisu se pak podle zvolené operace provede zkombinování zapsaného bajtu s latch-registry a přepsání registrů zpět do videopaměti.

Problém v pomalosti je zejména v pomalých I/O operací. Nevím proč, ale i dodnes se mi I/O operace jeví vždy pomalejší, než mapovat framebuffer do paměti. Pokud jsem někde generoval obrázek do back-bufferu, vykresloval jsem jej na obrazovku pomocí čtyř blokových operací, pro každou bitovou rovinu jeden. Ale bohužel to blikání bylo dost vidět i na rychlých PCI kartách. TurboPascalovská funkce putImage (tuším) ukládala obrázek po řádkách, vždy 4 bitové roviny na jeden řádek. Zobrazení pak probíhalo tak, že se blokově přenesl čtyřikrát 1 řádek, a pak 4× druhý, atd…

Další nevýhodou pro zápis je nemožnost použít 16bitových a 32bitových přesunů. Jak už bylo řečeno, latch registry se musí před zápisem přečíst, což vyřazuje ze hry blokové operace pomocí MOVSB. Pro zápis jsem používal ALU operaci OR, případně XCHG, obě nejprve operandy přečtou a pak zapíší. U OR se přitom musel nastavit takový čtecí režim, na který adapter odpověděl za všech okolností nulou. XCHG je obecně pomalejší, protože od 386 drží procesor během XCHG příznak LOCK a navíc je to serializační operace (tuším).

Zápisový režim 1 (blokové přesuny) byl dobrý možná pro ukládání pozadí (podklady oken) ve videopaměti, pokud jí bylo dost. (v režimu EGA 256kB byla k dispozici celá jedna stránka). Nevýhodou tohoto režimu je opět nemožnost použít 16-bitové přesuny, protože latch registry se prostě načtou a zapíši. Pokud by se provedlo dvakrát čtení a dvakrát zápis, byl by výsledek jiný (nepoužitelný). Mimochodem od 386 byly 32-bitové blokové operace rychlejší, než adekvátní přesun dat po osmi bitech přes latch registry, ale nebylo je možné prostě použít.

Ještě k tomu zapisování po bitových rovinách. Pokud se dostaneme k VGA a XMODE, tak třeba zajímavý postřeh, pokud jste někdo hrál DOOMa, v těch první verzích. XMODE obsahoval 4 stránky a bitové roviny byly mapovány vedle sebe, tedy na jedné adrese leželi čtyři body vedle sebe. DOOM generoval obraz po sloupcích algoritmem ray-casting. Vždy nastavil pomocí adapteru bitovou rovinu (pozn, naprosto stejným způsobem jako na EGA/VGA) a vygeneroval celý sloupec. V režimu LOWres přitom zapisoval do dvou bitových rovin naráz a generoval obraz s polovičním horizontálním rozlišením. Geniální využití šíleně navrženého systému vedlo k rozmachu 3D, byť se velice záhy začaly používat akcelerátory. Tento způsob však byl podkladem pro vznik poptávku po takovýchto hrách.