Názory k článku
Grafické karty a grafické akcelerátory (3)

Velmi dobre pokracovanie.

Velmi dobré,
snad autor ještě neopomine zmínit, jak ty osmibitové možnosti byly dotaženy do konce, pokud už uvedl "trikovou" grafiku u ZX81.

Čip VIC u C64 se překonával opakovaně, viz
http://www.c64.cz/index.php?page=graficmode

Také ZX Spectrum dokáže trikově vytvořit barvu pozadí a popředí pouze pro osminu původního atributu, tedy pro 8x1 bod.
Co bylo v článku opomenuto, je funkce dvou vidoobrazovek u ZX Spectra 128,
kdy bylo možno vykreslit gamescreen zatímco byla zobrazena druhá obrazovka
a pak mezi nimi přepnout, výsledkem je plynulost animací.

Nevím, zda se autor vydá cestou stručného popisu např. Sharpu MZ a Amstradu CPC,
tedy dalších, alespoň u nás rozšířených zahraničních osmibitů,
nebo počítá i se zmínkou o raritách a o soumraku osmibitové grafiky.

Každopádně čtenářům doporučuji doplnit si informace
o Commodore 65 (skutečně, slovy "šedesát pět" :-),
který měl možnosti Amigy, např. viz
http://sam.speccy.cz/misc/c65_sys-spec.txt

V internetových osmibitových muzeích doporučuji prostudovat grafické možnosti
britského počítače (Elan, Flan) Enterprise.
Představu o konci osmibitů si také uděláte u počítače (nebo jeho emulátoru)
Sam Coupe či Amstrad PCW16.

Obecně o osmibitech např. na
http://emul8.xlabs.sk/emulators/index.html

Dobrý den,

V dalším pokračování tohoto seriálu bude řeč zejména o československých počítačích, tj. o IQ 151, PMD 85 a didakticích. Krátce se také zmíním o Sam Coupé a Sharp MZ-800.

Vím, že to není vyčerpávající přehled všech osmibitů (a to se ještě nebavíme o osmibitových konzolích), ale já nechci ten seriál moc natahovat a co nejdříve se dostat do dnešní doby, která IMHO není tak zajímavá jako svět osmibitů, protože dnes už nikoho vnitřnosti grafických karet nezajímají - proč taky, když tu znalost může po půl roce, s příchodem nové generace karet, klidně zapomenout :-(.

Samozřejmě si můžeme informace o dalších osmibitech sdělit tady v diskuzním fóru, to článek v mnoha směrech obohatí (zejména znalosti tehdejších programátorů na daných systémech, já v té době nejvíc programoval na Atari).

Děkuji za reakci,
má doplnění nepovažujte určitě za kritiku článku,
který je skvělý a jeho obsah v jednotlivých dílech je dostatečný, přiměřený tématu.

Snad bych ještě připomenul standard MSX,
- iniciativu sdružení ASCI a Microsoftu,
což dnešní uživatelé Voken jistě uvítají se zájmem.

S přáním dalších vydařených pokračování
Z.

Ještě by mě zajímalo "za koho kopete" :-) Podle Vašich příspěvků to vypadá na C=, ale zase to jméno "zilog" mi s tím nějak nesedí :-)))

[Z flamů Atari-C= nebo Atari-Spectrum už jsem jaksi vyrostl, ale na průmyslovce byly třídy striktně rozdělené :-)))] Nejhůř na tom byli majitelé PMDček, s těmi se totiž nikdo raději ani nehádal, bylo nám jich líto...

Hezký den,
to by mne mrzelo, kdybych zde navozoval atmosferu flameovani. ;-)

"Nekopu za nikoho", patrim k tem malo jedincum,
co si mysli, ze nemusi kazdych par let kupovat pocitac
a ze k zdravejsimu a spokojenejsimu zivotu
neni treba vetsi graficke rozliseni nez 672*256 bodu :-)

Ja jsem do roku 1990 vyrustal na ZX Spectru a IQ-151,
pote SAM Coupe, a o rok pozdeji (necekany dar) Commodore 128D.
Ze zvedavosti pak pribyl i Sharp, Amstrad, Enterprise a Laser.
Do roku 1999 jsem kazdodenne pouzival pouze dva osmibity, pak jsem poridil PC.
Po trech letech jsem skoncil opet u osmibitu,
PC zapinam kvuli internetu a emulatorum.

Atari s C64 a na druhe strane zilogisticke stroje
- to je neco jako ohen a voda,
ale Commodore 128 ma dva procesory z obou taboru
(a navic ma zajimavy VDC chip pro 640*200 pixelu).

Za nejlepsi a nejintuitivnejsi stroje povazuji Sinclairy (od ZX80) a jejich periferie,
jak technicke reseni, tak ovladani - zajimave je napr. porovnani
syntaxe Basicu - u sinclairovske rady a jejich periferii lze pouzivat prikazy temer intuitivne, u commodoru a atarek se neobejdete bez manualu (zavani to Microsoftem).

Za nejlepsi osmibit povazuji Sam Coupe, viz
http://sam.speccy.cz
(kouknete na parametry jeho basicu).

Pokud vsak nekdo hleda nejlepsi osmibitovy procesor:
6809 v americkem Tandy CoCo a britskem Dragon.

Zaverem se priznam, ze toho prilis nevim o Atari, krome
cca 5 ceskych starsich technickych prirucek
a novejsiho infa na
http://raster.infos.cz/atari/
V mem okoli bylo totiz vzdy spousta ataristu,
ale kdyz jsme se my ostatni spectriste, sharpiste, commodoriste aj.
bavili o systemech, bastleni a programovani,
atariste vetsinou znali jen hry - o nichz debatovali dlouhe hodiny...
:o)
Mel jsem tedy asi smulu, jinak bych navic urcite mel doma treba krasne protazene modelovane Atari 600XL.

z.

Ja jsem nechtel flamovat, po Internetu me to nikdy moc nebavilo (neco jineho je si sednout se sinclairistou na dve pivca a poradne si to vyrikat :-)))

Jen jsem se chtel zeptat na Vase zkusenosti a vidim, ze jsou velmi rozsahle. S tim nejlepsim osmibitovym procesorem mate pravdu (i kdyz Coco a Dragon neznam), dodneska se sedesat-osm-nula-devitka pouziva, pouziva napriklad v prumyslu, kde zdatne konkuruje na jedne strane PICum a 68HC11tkam, na strane druhe potom ruznym embedded sestnactibitum.

Osobne za nejlepsi rozliseni povazuji 720x400 textove (VGA rezim pro znaky 9x16 pixelu). Obnovovaci frekvence dostacujici, tmave pozadi, horizontalni kurzor (ne ty nesmyslne vertikalni GUI "carets") a hlavne jsou krasne vytvorene znaky - "pouze" jednopixelove serify udrzujici oko na radku, nenasilne a pritom citelne pismo. Pro psani za dlouhych zimnich veceru idealni :-)

Pro Commodory nevim, ale pro osmibitova Atari existoval jakysi Microsoft Basic a byla to dost tragedie (snad pokus o jakousi normu, tj. zadne programy napsane v jinych Atari Basicich na tom nepracovaly, rychlost a pametove naroky hanba mluvit), zejmena v porovnani s opravdu "profesionalnimi Basicy": Turbo Basicem od F. Ostrowskeho a XL Basicem.

Turbo Basic se zabudovanou podporou pro Turbo 2000 a hardcopy na BT-100 je muj favorit :-)

Tak se podívejte :)

http://en.wikipedia.org/wiki/Commodore_BASIC

Ja sice nejsem commodorista, ale ti co znam, nemeli std. Basic moc v lasce. Porad basnili o nejakem Simons' Basicu. Ale jak rikam, rozdily prakticky vubec neznam (v std. C= Basicu jsem neco malo delal, ostatne C= byl prvni pocitac, na kterem jsem videl Basicovy program :-)

Commodore vždycky používal MS BASICy, ovčem BASIC 7.0 ze 128ky byl už opravdu použitelný.

Nicméně, co si budeme namlouvat, nejlepší jazyk pro osmibity (z paměťových důvodů) je FORTH :)

Ano, o tom bych mel neco vedet :-)))

Víme, čteme, hltáme lačnýma očima :)

Ad "Commodore vždycky používal MS BASICy, ovčem BASIC 7.0 ze 128ky byl už opravdu použitelný":
Velmi použitelný byl už BASIC 3.5, který měl nejen lepší syntaxi pro ovládání disk. jednotky, ale také větvení, odchytávání chyb, podporu grafiky apod. Byl bohužel dodáván v "experimentálních" typech commodorů, např. typu +4.

Ad "nejlepší jazyk pro osmibity (z paměťových důvodů) je FORTH :-)":
Nejlépe v kombinaci s hardwarem od Sinclaira: JUPITER ACE :-)

Turbo Basic byl super. A taky dodnes je, vzdyt jeho casti jsou pouzite v naslednem GFA basicu pro ST.

Vyborny clanok, vyborna seria. Len tak dalej.

Až teprve teď vidím, jak bylo moje CPC 464 na svojí dobu pokročilé. Disponovalo třemi grafickými režimy:
160x200, 16 barev z 32
320x200, 4 barvy z 32
640x200, 2 barvy z 32

Každý znak mohl mít libovolnou barvu písma i pozadí (samozřejmě z dané palety), písmo, pozadí i okraje obrazovky (tzv. "border") mohl blikat.

Dost často jsem ale v hrách vídával režim emulovaného spectra, tzn. 256x192 a 8 barev najednou. Docela bych byl rád, kdybych se něco dočetl i o grafice v CPC.

Máte pravdu, CPCčka - zejména verze s integrovanou disketovou jednotkou - patřila ve své době na určité pomezí mezi osmibitovými a šestnáctibitovými počítači. Tím mám na mysli, jak jejich hardwarové vybavení (operační paměť, grafika, možnost připojení periferií), tak i určení těchto počítačů. CPCčka se často používala v kancelářích - to vyžadovalo použití monitorů namísto televizí.

Z toho také vycházely zmíněné grafické režimy, které by se na "herních" osmibitech neužily (rychlost překreslování, možnosti TV, obsazená kapacita operační paměti).

Doporučuji hledat na internetu informace
o CPC 6128+ s paletou 4096 barev.
I pro tuto verzi CPC jsou emulátory.

Pozn.
Amstrad byl dobrý,
ale SAM Coupe měl rozšíření Kaleidoscope,
které poskytovalo paletu 32768 barev.
:-)

Jen bych doplnil, ze pokud vim, tak ty "prohazene" radky na Spectru byly kvuli tomu, aby se neseslo na delsi dobu zobrazovani a refresh RAM (nebo neco takoveho???). Taky program v dolnich 32k, ve kterych byla bitpama obcas popobihal ponekud "trhane", jak si zobrazovaci cip zabiral sbernici ;-)

Prohazeni videoram ma jiny duvod.

Pokud ma atribut a pod nim umistena bitmapa tutez cast radkove adresy, je mozne ji zavest do DRAM v dobe /RAS a druhy byte pak cist zrychlenym cyklem jen zmenou /CAS (tzv. page-read mode). Tj. nacteni dvojice atributu (tak pracovala ULA v 48k/128k kazdych 16T) je provedeno za 6 pristupu misto za 8.

O refresh zde vubec nejde, puvodni model issue 1 pocital s refreshovanim jen ze strany CPU (!) v dobe nezobrazovani, a az pozdeji se zjistilo, ze i vlastni beh ULA nad vycitanou VRAM k udrzeni informace bohate staci (issue 2 - chybi tu uz zbytecna weak vazba na /rfsh cpu).

A ted to prohazeni - ULA zkratka pri postupu snimkem udrzuje spodnich 7 bitu (vram zx byla 2^7 x 2^7 organizovany blok dram - didaktik M/hobbit ULA musi udrzovat 8, ale organizace vram tomuto vyhovuje) konstantnich po dobu zobrazovani jedne linky se spol. atributy. Proto je navazujici radek o 256b vyse, etc. Samozrejme, CPU mohl mit adresy ve vram multiplexeru prohazene stejnym stylem (A6..A7 <-> A8..A10), a pak by se bitmapa jevila pro CPU stale jako linearni, ale za soucasneho navrhu vycitaci logiky by byla atributova cast uz v adr. prostoru nekompaktni, co by byl nuz do zad puvodnimu BASICu, ktery se delil s VRAM o 1 16k banku od #4000-#7fffh.

A to je pravy duvod, uvedomte si, ze v dobe issue 1 navrhari o refreshovani samotnou ULA neuvazovali, a dokonce takto prohazena VRAM ma z hlediska fyzickeho obcerstvovani daleko HORSI vlastnosti, nez tupe vycitana bitmapa na 8T...

zxm.speccy.cz
ci5.speccy.cz
www.pandora.cz - konference Speccy - stale zijeme ;)

Zilogat0r

Jeste drobnost k ZX Spectru: kolem graficke oblasti byl (docela siroky) okraj (tzv. border), ktery mohl mit jednu z osmi barev. Rychlym stridanim teto barvy okraje slo vykouzlit ruzne barevne prouzky na okrajich obrazovky nebo dokonce i citelne pismo v hornim okraji obrazovky (sam jsem to kdysi zmastil v asembleru). Taky v clanku chybela informace, kolik melo ZX Spectrum barev. Takze bylo jich 8, kdyz pripocitame jasovou slozku, tak dokonce 15 (to protoze svetle cerna a tmave cerna byla porad stejna). To jen tak na okraj:) Jinak super clanek!

Vidite, na pocet barev jsem zapomel, uvedl jsem pouze fakt, ze na atribut byl zapotrebi cely byte (popredi, pozadi, blikani). Ostatne v tomto nazev Spectrum nelhal - pouzivaly se vsechny zakladni barvy barvoveho spektra + cerna a bila :-)

Zdravim,

snad je par dodatku, ktere autor pominul u VICu. Jak jiz bylo naznaceno, neni 8 spritu, ale jen jen 8 spritu v Xove souradnici, jinak jich muze byt treba 200... Proto ty pekne strilecky :) "Specialni klopne obvody" neni nic jineho, nez 2 bity z CIA 6526 z hlediska pozuivani. Tech triku co jdou s VICem delat je mnohem vic, pocinaje stridani modu na obrazovce, udelani 26 textovych radek, 'otevirani' borderu a tim zvetsovani grafickeho rozliseni (bezproblemove az do 386x284). Resizovani grafiky/sprite (az na celou obrazovku) a tak dale... Je toho pekna hromada.

Skoda ze se autor nedotkl 'narocnosti' grafiky na CPU. Treba takove Atarko, ac melo temer 2nasobny kmitocet, bylo defacto stejne rychle jako C64ka. Teda pokud si nezavrelo cast obrazovky. Vic si data z pameti bere prez DMA a ovlivnuje ho zejmena pocet zobrazenych spritu a podobne. Cim je jich vic, tim vice DMA je potreba a tim vic 'zpomaluje' CPU. Na ataraku pak je to zavisle dokonce na pouzitem grafickem modu. Je to dano zdilenim pameti.

Ad SID - existuji opravdu pekne synthy zalozene jen na SIDech (treba na 16ti). Sidstation a podobne.

R.

Zapomel jsem jeste na jednu blbustku, bez nichz by hry vypadali dost osklive. Jedna se o moznost posouvani veskerych adres pro VIC v pameti, cili, moznost delat doublebufery a podobne blbosti. Celkem dulezita vec. Jedine, co nejde posouvat je COLOR RAM (je fixne na adrese $d800, pokud je tedy zapnuta, zapina se soucasne s I/O ala SID/VIC). VRAM lze posouvat v krocich po $0400 kamkoliv, bitmapu potom v krocich $2000. V pripade rastrovani pak pro kazdy radek zvlast (jako displaylist na atarku).

R.

ad rychlost C= a Atari:

na Atarku si data pro grafiku cetl Antic sam, urcite se tedy neskakalo do nejakeho preruseni apod. Jde ale o to, ze nektere graficke mody byly opravdu tak narocne, ze se Antic a CPU o sbernici/cykly delilo klidne i pul na pul :-(, takze realna vypocetni rychlost CPU klesla na polovinu. O porovnani rychlosti byl pekny (a fundovany) clanecek ve Zpravodaji Atari klubu a vychazelo to v realu priblizne nastejno.

Jeste jedna zajimavost: na prenosove pasmo byl na Atarku nejnarocnejsi paradoxne ten nejjednodussi rezim: text 40x24. Proc? No nejenom, ze bylo zapotrebi nacist vsechny znaky na obrazovce (960 byte) a display-list (od oka reknu 40 byte), ale jeste se musela nacist pro kazdy znak jeho bitmapa 8x8 pixelu (8 byte), tj. pro obnoveni celeho obrazu musel Antic prenest vic jak 8KB, coz je na textovy rezim (prekvapive) hodne. Pisu to proto, ze ne vzdy musi platit: textovy rezim rychlejsi nez grafika.

as SID: prodava se jeste Sidstation? Mel jsem dojem, ze tvurci tohoto synthu skoupili vsechny dostupne SIDy z vyroby (po de-facto krachu C=) a SID se uz nevytabi (nikdo nevi, jak presne vevnitr pracuje a novy "odkoukany" design by asi nebyl pro fajnsmekry :-)))

Stejně jako grafika u starších a novějších C64
vykazují rozdíl (zjevný i na TV obrazovce) - odstíny barev,
podobně SID existuje ve dvou verzích, které na poslech rozezná i "nehudebník".
(Znalci říkají, že starší je lepší :-)

Existuje i společné zapojení dvou SIDů - StereoSID,
který je u Commodore 65 již jako standard.

Zase na druhou stranu (jedna pani=Google povidala) se pry prvni verze SIDu hodne prehrivala a C= je snad dokonce musel v nekterych modelech C64 z tohoto duvodu vymenovat. Pravda je, ze SIDy obecne hodne topily, asi to bylo zpusobeno malou plochou cipu a napajecim napetim.

SIDy se neprehrivali nijak... Aspon jsem to nikdy neregistroval a ze jsem C64rek orpavil peknou radu. Casto odchazeli vynou vadneho trafa (to byla bolest). Existuje NEW a OLD Sid - 6581 a 8580. Lisi se filtrama (co vsechno zvladaji), prehravanim samlu a dalsima detajlama. Zvukove jsou rozeznatatelne v urcitych pripadech.

Rozidly barev jsou mezi VIC a VIC II (revize). Ty se defacto nijak HW nelisili - jen prave tim rozdilem na TV.

Do C64 lze snadno dat 2 a vice sidu. Bezne se davaji 2 (stereo). Jsou ale karty do expansion portu, ktere maji i 4 SIDy. Ono vubec expansion port je pekne navrzenej, takze existuje od IDE az po SCPU prakticky cokoliv, vcetne modemu, ethernet sitovek a tak dale. A to je pro C64 i operani sysem ktery ma telnet, webovej prohlizec, VNC implementaci a podobne...

Neco malo:

http://www.volny.cz/dundera
http://www.dunkels.com/adam/tfe/
http://lng.sourceforge.net/

Zapomněli jste na důležitou funkci která umožnila všechny ty efekty které původně nebyly možné (otvírání borderu, FLI..) - a to je možnost nastavit si přerušení na libovolný řádek zobrazení a možnost číst aktuální číslo řádku proceesorem. To umožnilo synchronizaci rutiny se zobrazením až na úroveň 1 strojového cyklu (který odpovídal 8 pixelům).

Zdar 2H :) Je super videt, ze jeste proad zijes :)

To jsem bral vicemene jako samozrejmost, neb neco podobneho mel i atarak. Ono mezi nami devcaty nebylo ani tak vyhodne pouivat pro IRQ vertikalni paprsek, ale CIA casovace. Lze s nima a jejich prensosti mnohem efektivneji ustalit rastr presne na cykl (pro neznale, pri preseni se dokonci aktualni instrukce, coz muze znamenat zpozdeni oproti paprskyu 2 az 8 cyklu). Pokud se to casovalo prez CIA casovace, tak zpetnym dotazem se dalo ustalit behem 'par' strojovych cyklu. Klasicky prez VIZ a VIRQ to byla prace na 2-3 radky. V nekterych vecech jsem pouzival oba casovace z obou CIA (tedy IRQ i MNI) a jeste VIRQ. A i tak se chudacek CPU pekne potil. Beq kvalitnich CIA by rada efektu nebyla mozna, protoze rezie by byla natolik velka .... (treba 80x40 pripadne 80x80 grafickej mod).

Pokud jsem se nezminil o otevirani bordelu (jako horizontalne tak vertikalne) a 26. textovem radku, sypu si popel na hlavu :)

8mi pixlum odpovidal jak kdy. V zavislosti na pozici na obrazovce, poctu spritu, etc. proste co zrovna VIC tahal prez DMA...

Oproti ataraku ma jeste C64 jednu velkou vyhodu. Displaylist je sice vec pekna, ale neumozni 'rotaci' rgafiky. C64 grafiku umi 'rotovat' dokola, displalyst pouze posouvat, coz je problem pri grafickych hrach (o textu to neplati). Dlouho jsem se o tom s atary-priznivcema handrkoval, az mne donutili kus dema (na atary), kde tohle bylo pekne videt... Vsechno ma svoje :)

R.

Atari 800XL a vubec cela tahle rada mela tzv. Display list - byl to program pro grafickej procesor, kterej mu rikal, co ma delat. Diky tomu slo na obrazovce soucasne pouzivat skoro vsechny graficky i textovy mody najednou. Detaily si nepamatuju, ale jednou jsem to pouzil na editor spritu.
Predpokladam, ze by tim sly delat obdobny triky jako u VICu.

DL byla pekna vec, usetrial neco casu a CPU, ale na druhou stranu byla bohuzel strasne omezena, napriklad jak uz jsem zminoval 'rotaci' grafiky. Ja bych si na detajly i jeste treba vzpomenul :) Ale zase tolik jsem na atarku nedelal. Nevyhoda DL byla primarne ta, ze fungoval hlavne an radky a neumoznoval jiz delat neco 'vertikalne'. Mel 'dane' moznosti. Oprotitomu C64 (ac to stalo vykon) nmela moznosti dane - kdykoliv si mohl udelat cokoliv - a bud to proslo nebo to neproslo :)

Nektere efekty (treba takove vertikalni plazmy) se na atary delaji krasne. Staci si nakreslit velkem trojuhelnik na orbazovku /\ a pak prez DL jen generovat nejakou plazmicku. Na c64 je tohle relativne slozitej efekt, kdy se musi VIC donutit nacitat znaky kazdou radku (prez DMA). Kdyz se pak ale porovna ten vykon, tak na atary to toho CPU sezere vic, ikdyz se CPU defacto 'flaka'. Na C64 se tomuhle obecne rika FLI (byt je to zname hlavne ve spojistosti s grafikou). Tech zkratek existuje milion a ja jsem si je nikdy nedokazal zapamatovat.

Plati to i opacne, nektere veci jsou na C64 vylozene primitovni a na atary nekdy az nemozne. Kdyz si ale atarak zavrel obrazovku, tak umel pekne hrat samly, nebo rendrovat. Tak se projevil 2x rychlejsi CPU a plne care...

R.

Ako dlhorocny programator na ZX bych len dodal, ze prekladane riadkovanie malo pre programatora skor vyhody, ako nevyhody. Idealne sa pocitala napr. pozicia textu, a predovsetkym, na jednu 4 taktovu instrukciu sa dalo skoro vzdy prejst na nasledujuci / predchadzajuci riadok a stlpec vo VRAM (inc l, dec l pre +/-x, inc h, dec h pre +/-y). Pokial programator vedel co robi, spritova grafika sa dala aj vdaka prekladanemu riadkovaniu celkom efektivne emulovat. Napr. zmazanie celeho screenu znamenalo iba vynulovanie pamate atributov (768 bajtov), atd...

Najlepsi priklad je napr. strielacka Zynaps, ktora mala vdaka tomu neuveritelne plynulu a rychlu spritovu grafiku a scroll (25fps, k tomu generovane zvuky na speaker), cim sa z programatorskeho hladiska u mna radi na #1 medzi hrami na ZX :) Atributovym artefaktom sa nedalo vyhnut pri koliziach spritov, ale napr. pri scrollovani pozadia sa dal vhodnym navrhom pozatia tento defekt uplne potlacit.

Ale inak pekny serial, rad si ho precitam az do konca...

Mate pravdu, u Spectra ta organizace obrazove pameti jeste nebyla tak hrozna (a ja chapu technologicke duvody, ktere k tomu vedly), ale to jenom diky tomu, ze melo 256 pixelu na radek (proto take sly pouzit Vami zminovane incy a decy).

Co vsak nedokazu pochopit je, ze se tato organizace objevila i na grafickych kartach na PCckach - CGA, Hercules. Schvalne si zkuste napsat procedurku pro vypocet adresy pixelu dejme tomu na CGAcku - jsou zapotrebi minimalne tri registry, par shiftu, scitani atd. Proste nic prijemneho.

Na 128k Spektrach s dvoma videoram bolo mozne prepinanim videoramiek dosiahnut ich farebny "blend". Napriklad oranzova farba sa dala simulovat 25 Hz preblikavanim cervenej a zltej.

Tohto optickeho efektu sa da vhodne "zneuzit". Kedze jeden pixel ma 2 mozne stavy v 2 moznych bitovych rovinach, celkovo je mozne v jednom 8x8 atribute pouzit 4 nezavisle farby per-pixel. Ak sa vhodne vybranymi 4 farbami zditheruje kazdy atribut v obrazku, vysledky su uzasne. Autorom konverznej ditherovacej utility na obrazky je tu pritomny Zil0gator a jej vysledky si mozete pozriet tu:

http://zoom.czweb.org/dithvide.htm

...sorry za pripadny double-post