Názory k článku Grafické režimy GTIA, podrobnější pohled na způsob zobrazení obrazu

GTIA 9 byl kdysi součástí programu na skenování fotek. Ano, to skutečně existovalo a dokonce české výroby. Stačilo na ploter Aritma přidat fototranzistor a výstup přivést do paddle (to má A/D převodník). Potom počkat asi hodinu :-) Fotka sice byla těch 80x192, ale zase v šestnácti odstínech, prostě tech edge tehdy.

Jinak má někdo jména dalších programů a her s GTIA režimy? Nic mě teď z hlavy nenapadá. Možná Koronis Rift? Ale ten byl "pixelatej" kvůli rychlosti asi...

Jo jo, na to skenování jsem tu taky vzpomínal. Dokonce kdo si postavil Alfigraf podle stavebnice z pražského Atari klubu, tak už tam měl rezervovanou jednu žílu v "joystickovém" kabelu. Jenom si nejsem jistý tím optimistickým časovým odhadem. Moje vzpomínky říkají něco o polovině odpoledne (cca 3 hodiny) :) Ale je pravda, že to byl ten Alfigraf ze stavebnice, Aritma byla asi rychlejší i přesnější.

Mimochodem, na kapitolu seriálu o PIA a ovládání portů se taky moc těším - ukáže to, jak už tehdy to bylo právě podobné dnešním Arduinům, ESP32 apod.: nastaví se maska pinů vstupní/výstupní, je datasheet, který pin umí A/D převodník a které jsou jen 0/1...

Tohle jsem si postavil doma za odpoledne z pujcene polorozbite Robotron termotiskarny - IR led a fototranzistor za par korun, napojeny na paddle A/D prevodnik. Byl tam myslim jeste zesilovaci tranzistor, ale uz si nejsem jistej.

Ten A/D prevodnik byl ultra pomalej, coz spolu s absenci optiky vedlo k vtipne malemu rozliseni scanu, ktere bylo celkem aligned s tim rozlisenim GR. 9. Jako na obrazovce to vypadalo fakt huste. Mel jsem na to svuj custom scanning software udelanej za dva dny v assembleru.

Fun fact: naprosto to failovalo pro barevne fotky, scanovalo to non-sense. Pro cernobile super.

Zkousel jsem tomu dat nejakou easy optiku a prepnout ten paddle to rychlejsiho modu (bit 2 v SKCTL), ale nikdy se to nepovedlo rozchodit. Tiskarnu jsem pak musel vratit, byla pujcena od kamose.

To byl rok 1994, posledni hrani s Atari 800 XL, po par mesicich vymenen za Amigu.

Asi muj nejvetsi hacking uspech, od te doby uz to jde se mnou jen z kopce :)

Využití GTIA módů v té době si taky pořádně nevybavuju, ony ty pixely 4x1 nejsou moc praktické. Možná někde pomocí DLI že by byly použité jen na část obrazovky? Neměl byste někdo víc příkladů?

V moderní době to používali jako jednu z možností, jak zobrazit více barev: různé triky se střídáním módů ať už po řádcích nebo po snímcích. Bohužel zdaleka ne vše z toho funguje dobře v emulátoru atari800, člověk by musel sehnat skutečný HW (včetně televize, nejlépe CRT). Např. Jeff D. Potter vyrobil APACView, který přečte GIF i JPG, rozloží je na R, G, B kanály a ty pak zobrazuje v gr. 9 s tím, že střídá za sebou červený, modrý a zelený snímek. A tvrdí, že pak oko uživatele vidí 4096 barev.

A takovýchto experimentů, typicky ukázaných na nějaké demo přehlídce, bylo víc, např. tzv. módy HIP, RIP a TIP, které různě střídaly módy 9, 10 a 11, aby docílily dojmu 160x192 s 256 barvami. Ale nikdy jsem neviděl, že by se to masivně používalo v nějakých hrách nebo programech, byly to jen experimenty v demu. A taky jsem je bohužel nikdy neviděl na žádné CRT televizi, tak nevím, jak moc použitelně vypadaly. Jo jo, přiznejme si, kolik procent dnešních spuštění Atari programů je ve skutečnosti jen v emulátorech...

Dám dnes malý dodatek pro ty z nás, kdo už CRT televize a monitory znají jen z muzeí. Odborníky ale předem varuji, že úplně do hloubky opravdu nejdu:

TV i monitory založené na CRT technologii nemají horizontální rozlišení pevně dané, jsou analogové. Rozlišení mají pouze vertikální, tj. počet řádků. Samozřejmě ta technologie měla limity, od určitého momentu zjemňování obrazu se začaly objevovat různé falešné barvy a jiné artefakty, podle normy televizního vysílání, barvy "pixelů", jejich patternu i pozice na obrazovce. Takže každý návrhář počítače si troufl na něco jiného (ZX Spectrum mělo 256, Atari v základním režimu 320, IQ 151 (modul Grafik) mělo prý dokonce 512 pro ČB obraz, ale jen 256 pro barevný.) Někdo se dokonce pokoušel využít ty efekty falešných barev k více barvám ve svých hrách, ale pochopitelně za běžných okolností to byl spíš problém než chtěné "vylepšení". Proto např. znaková sada Atari měla to "tučné písmo" - vždy horizontálně dva pixely širokou každou linku písma, aby tyhle efekty potlačili.

Nebylo tedy dané TV jako zařízením, jaká bude ta frekvence CPU a další závislosti, ale chtěným horizontálním rozlišením. Na Atari tedy potřebujeme frekvenci hodin, aby ANTIC vyráběl přesně to rozlišení 320, co chceme. A z toho se pak všechno ostatní odvozuje. Teoreticky by mohlo někoho napadnout mít jiné hodiny pro 6502, ale jelikož se ANTIC dělí o přístup k adresní i datové sběrnici s 6502, nedává to moc smysl.

Proč to tak zdůrazňuju je, abych "vypíchnul", že v timingu je na Atari jako hlavní procesor ANTIC, zatímco 6502 se dostane k paměti jen když ji ANTIC pustí. Proto se ty údaje o frekvencích a časech vztahují na vnitřní fungování ANTIC a nejdou tak snadno použít pro časování vlastních programů v 6502. Čas pro 6502 nejenže neplyne tak rychle, jak by teoreticky podle frekvence měl, ale hlavně neplyne ani pořád stejně rychle.

Zní to zvláštně, tak si to pojďme zkusit! Např. kdybychom si předem připravili hodnoty pro červenou a modrou do registrů X a Y a pak během DLI na každém řádku prováděli tento kód na co nejrychlejší změnu barvy pomocí rozvinuté smyčky:

STX COLOR1
STY COLOR1
STX COLOR1
STY COLOR1
STX COLOR1
STY COLOR1
STX COLOR1
STY COLOR1
STX COLOR1
STY COLOR1

Tak nám sice vzniknou svislé pruhy, ale rozhodně ne tak úzké, jak bychom si představovali. Každá instrukce trvá sice jen 4 strojové cykly, ale podle grafického módu a např. počtu použitých sprajtů si šahá do paměti ANTIC a na 6502 zbývá jen ten čas mezitím. A tak budou pruhy nejen širší (v gr. 9 přes 30 pixelů), ale i různě široké - např. na začátku řádku čte ANTIC více dat a tudíž i náš levý barevný pruh bude širší... A dokonce se projeví i další věci kolem ANTIC, např. když ANTIC pro daný řádek načítá instrukci pro nastavení videoram, tak ho to o chvilku zdrží, přístup pro 6502 dá později a na tomto řádku budou tedy naše pruhy posunuté o několik pixelů vpravo. Podobný problém jsem už ukazoval v tomto příspěvku pod starším dílem.

Je to možná zvláštní představa pro někoho, kdo slyší o těchto počítačích poprvé, ale je to tak: zkrátka grafický procesor má v timingu vždy přednost. Na ZX Spectru měli na to jinou vychytávku: byly dané rozsahy ("banky") paměti, kam grafický čip (ULA) sahal, a program v hlavním procesoru (Z80) se zpomaloval pouze když sahal do tohoto prostoru (kód nebo data). Jinak nebyl grafickým čipem bržděný. Na Atari máme naprostou svobodu s nastavením video RAM a jiných parametrů, jdou s tím dělat kouzla, ale platíme za to tím, že se zdržení od ANTICu nemůžeme vyhnout.

A jeden z důsledků je, že nikdy nemůžeme použít všechny efekty, které (každý jeden z nich) Atari umí: není na ně dost času. Např. některé zajímavé techniky na barevnější obraz se nedaly použít se zvukem, protože i zvuk se musí stíhat ovládat v přesné okamžiky. Natož aby byl čas ještě třeba na vlastní herní logiku, kdybychom chtěli celou hru...
Některá dema ze soutěží jsem jako mladší nechápal (každý ten efekt z nich jsem znal a i asi uměl udělat), ale vůbec mi nedocházelo, že kouzlo toho dema je v tom, jakou optimalizaci dotyčný vymyslel, aby je mohl předvést NARÁZ...