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

Falcon030 má grafiku ve skutečnosti mnohem pružnější než jakýkoliv předchozí model. Stará se o to obvod VIDEL (místo Shiftera použitého v ostatních 16/32bit Atari počítačích) a tento VIDEL má mnoho registrů pro v podstatě volné naprogramování jakéhokoliv rozlišení při jakékoliv obnovovací frekvenci v daných barevných hloubkách (1,2,4,8 bitů bitplany a 15/16 bitů packed pixel). Vlastně to trochu připomíná např. Modeline u XFree86/X.org. Maximální rozlišení je dané pouze rychlostí datové sběrnice, po které proudí grafická data ze systémové RAM přes VIDEL na obrazovku. Původní takt 16 MHz umožnil rozlišení např. 800x600 na VGA (nebo i 1600x600 na televizi! :-), ale po urychlení sběrnice různými akcelerátory až na 25 MHz je možné vytáhnout z VIDELu rozlišení blížící se 1024x768.

Je zajímavé, že čím větší velikost takto definované videoram, a čím větší obnovovací frekvence, tím užší hrdlo má CPU do RAM, protože většinu šířky pásma zabral VIDEL. Takže náročná grafika v podstatě zpomaluje běh programů. Proto vedlejším efektem spořičů obrazovky, které přeprogramují VIDEL tak, aby nevysílal horizontální či vertikální obnovovací pulzy a tak vlastně přiměl VESA VGA monitor, aby přešel do proud šetřícího spánku, zároveň urychlí i běh programů, protože VIDEL vůbec nezdržuje na sběrnici.

Jeste doplnim, ze programovani registru lze (i kdyz v omezene mire) provadet i v prubehu zobrazovani a mit tak obrazovku rozdelenou na vic grafickych rezimu. To se trosku podoba Display Listum z osmibitovych Atarek nebo prepinani rezimu na Amize.

Prave diky rapidnimu zahlceni pametove sbernice se dnes vyrobci uchyluji k oddeleni RAM a video RAM (nejenom u PC), pro staticke sceny je to idealni, u dynamickych scen naopak vykon ztraci.

U dynamickych scen kreslenych procesorem. Pokud vetsinu sceny stejne dela graficky akcelerator, je to rychlejsi oddelene. Jinak, mel jsem pocit ze vetsina videokaret pouziva drazsi pameti nez je hlavni pamet pocitace - nevim jestli jde jen o dvoucestnost, nebo i o rychlost.

Ono v dobe, kdy se rozhodovalo o oddeleni pameti neslo o 3D a dnesni graficke akceleratory. Totiz i takova "primitivni" operace, jako je scroll teto stranky o par pixelu nahoru vlastne znamena prenos nekolika MB dat.

O tom se nehadam, nemam nejmensi poneti kdy to bylo. Chtel jsem rict, ze dneska je pitomost vracet to zpatky.

Ano, a jako na potvoru lze predpokladat, ze firefox nepouziva pro scrollovani akceleraci ...

Firefox by to snad mel zvladat, ostatne to neni jeho starost, ale knihoven "pod nim". Ale chce se mi brecet, kdyz si na notebooku pustim konzolu ve framebufferu (treba abych mel nativni rozliseni) a razem se rychlostne ocitnu tak o deset let zpatky.

Jojo, znamy to problem, naprosto neakcelerovany framebuffer versus extremne akcelerovana textova konzole ... proc myslis, ze doposud nepouzivam framebuffer ? K certu, scrollovani v XTermu je rychlejsi ... coz me vede k tomu, ze mozna ty Xka precejen nejakou akceleraci maji ...

Jasne, ze maju. HW->HW blity su akcelerovane skoro vo vsetkych driveroch. Takisto aj SW->HW. Co chyba, je poriadna akceleracia alpha-blendingu. Snad pomoze EXA...

Jasne dlouhou dobu mi taky stacil klasicky rezim 80x25 (presneji 720x400 pixelu se znaky 9x16) - ten je velmi citelny a po zkouseni ruznych tweakovanych rezimu a VESA rezimu jsem se k nemu vzdycky vratil. Ted vsak mam notebook (firemni) a je trosku blby se divat na ruzne rozmazana pismenka, tak jsem se snazil pracovat v nativnim framebufferu (1024x768), ale ta rychlost je otresna - to uz i osmibitove Atarko scrollovalo rychleji :-)

Kdyby tam aspon byla dodelana takova ta skoro zapomenuta featurka z T602: pri male rychlosti graficke karty se prekreslovala pouze vrchni a spodni cast obrazu, tak bych si zvykl. Ale pri pitomem skrollu o jeden radek prenest cca 2 MB dat - to je dost velke plytvani vykonem, mymi nervy a baterkami :-)

Ja od doby, co mam linux, pouzivam 8x8 fonty (a jinak klasicky rezim). Mozna jsou o neco hur citelnejsi, ale 25 radek se vazne neda ... a zvyknul jsem si na nej natolik, ze uz me ostatni "lepsi" rezimy (napr. SVGATextMode) pripadaji horsi (zvlastni, ze v Xkach mi to nevadi ...).

Ano, v X-kach taky kupodivu pouzivam mnohem mensi fonty. Mozna je to tim, ze v textovem rezimu jsou znaky udelany tak, ze maji v horizontalnim smeru vzdycky obsazene dva pixely (maji tedy sirsi tahy) a pri vetsim rozliseni (SVGATextMode 0x..) se to zacina slivat. V X-kach mam font s jednopixelovymi tahy a tak to zvladnu precist i v mensi velikosti. (kdyz rikam "zvladnu precist", myslim tim dlouhodobou praci, jednorazove precist jde i sestibodove pismo. A prave pri dlouhodobe praci mi VESA rezimy nesedi).

>Ale pri pitomem skrollu o jeden radek prenest cca 2 MB dat - to je dost velke plytvani vykonem, mymi >nervy a baterkami :-)

A co to je za masinu? Vdyt i u neakcelerovanyho rezimu by mela bejt prenosova rychlost RAM-LFB par desitek MB/s u PCI grafiky a par set MB/s u AGP grafiky. Sou spravne naprogramovany MTRR registry? Nevim jesi to linux defaultne zapne uz pri bootu nebo az Xka. Napr. v DOSu to nikdo nepreprogramuje a tak bezi VESA grafika nekolikrat pomalejs nez by mela, na to sem si napsal jednoduchou utilitu. Windowsy to obvykle zapnou, tam neni problem.

V mem pripade to byl tusim Duron 600 a Celeron 500. Ale myslenka je to dobra, az/kdyz to budu zkouset priste, zkontroluju jestli jsou MTRR spravne naprogramovane ... mam ovsem pocit, ze minimalne na Duronu byly.

A nemeni to nic na tom, ze nepouzit alespon zakladni akceleraci framebuffer dost poskozuje.

Samozrejme, to ale zas vyzaduje uzpusobeni pro jednotlivy cipy, pac akceleraci uz nikdo nestih standartizovat, velika skoda :(
Jen sem chtel rict, ze se da bez problemu naprogramovat plynulej scrolling i bez akcelerace, jen pristupem pres LFB. Dyk treba takovej Duke Nukem 3 taky bezel ve VESA a nijak necukal a to i na pomalejsich strojich....


Jen pro poradek dodavam, ze MTRR maj byt naprogramovany do rezimu write-combining (misto defaultniho uncached) pro danej rozsah adres framebufferu. Pak se pouziva nakej burst zapis/cteni LFB kery je mnohem rychlejsi.

Jde jeste o to, jakym zpusobem je scrolling implementovany. Bud se muze opravdu provadet scrolling, tj. prenos dat VideoRAM-VideoRAM (coz invaliduje celou cache, takze je dobre ji vypnout, stejne tak to neumozni burst prenosy) nebo rendering textu a jeho jednosmerny prenos do VideoRAM. Sice jsem to nemeril, ale citim, ze druhy zpusob bude paradoxne rychlejsi.

No jestli se ta data prenasi klasicky (a z tohoto hlediska pekne mizerne) pomoci mov, rep movsd atd. (vsak to znate), tak se teoreticke prenosove rychlosti sbernice ani pameti v zadnem pripade nedosahne - prakticky vyzkouseno na jinem projektu, u ktereho jsem naopak data sosal z karty do RAM.

Pokud je to napsany spravne a vyuziva se napriklad prenos bus-master, tak si vlastne procesor odpocine a nezacne se "probouzet", jak to na notasu (zbytecne) dela prave pri scrollingu.

Abych pravdu rekl, tak nevim, jak je naprogramovany framebuffer pro Linux, ale podle praktickych zkusenosti to vidim prave na ty "rep movsd" :-) Podotykam, ze se porad bavim o konzolovem framebufferu, X-ka s timto nemaji zadny problem (teda krome alfa blendingu, ale to jsme na vyssim levelu :-)

Za sebe muzu jen rict, ze ten rozdil mezi MTRR uncached a write-combining dela u me (na iBX, AGP karte)
62 MB/s vs 315 MB/s pri zapisu dat z RAM do LFB. Nevim jakou instrukci se to provadi, pouzivam ceckovou movedata(), typuju MOVSD.

Podle me je i tech 62 MB/s dostatecnych na rozumne rychly scrolling. Ja v linuxu framebufer nepouzivam, tak ani nevim jesi skroluje jako po pixelech (hladce) nebo po celych radcich. No takze treba pro 1024/768/32 by bylo potreba ~50ms na precteni LFB, dalsich ~50ms na zapis LFB na novou pozici, takze by se to melo porad hybat nakych 10FPS...

A muzu se zeptat, jak to zatezuje system a procesor? Protoze presouvat data procesorem je sice nejjednodussi, ale precejen se pouzivalo tak pred petadvaceti lety (uz pro i8080 existoval radic DMA, bylo to tusim 8257). To mozna bude prave ten problem Linuxoveho framebufferu, protoze pri praci na notebooku procesor vecne spi (co by taky pri psani ve Vimu a par ssh pripojenich mel delat?) a ten scrolling ho asi nestaci dostatecne rychle probudit a vznikaji tak ty pomale odezvy.

No asi dost... A btw hry jako duke pouzivaly na kopirovani FB DMA?

No je to mozny, asi to zalezi jak ma ACPI dlouhy ty timeslicy, na mojom desktopu to je v radu jednotek milisekund. Urcuje se pomer kolik slicu to bude spat a kolik to bude vzhuru. Ale nejsem zadnej expert na PM, jen sem si hral sn akou utilitou co to umoznuje nastavovat.

Dost pochybuju, ze DMA DOSove hry pouzivaly, sice je to pomerne jednoduche, ale musi se spravne nainicializovat druha strana, tj. radic sbernice na graficke karte. Tady bych to spis sazel na klasicke "rep movsd" apod. s vyuzitim VBE 2.0 (mam dojem, ze predchozi standardy neumoznovaly mapovani celeho framebufferu do hornich oblasti pameti a musel se pouzivat strasne pitomy a pomaly rezim oken).

No ja si taky myslim. Ano, mapovani LFB pridalo az VBE 2.0
Sice se to dalo naemulovat pres UniVBE, ale pokud to karta proste neumela, tak se pozuival bankswitch a narust rychlosti byl nulovej. VBE 3.0 nepridava nic zasadniho, za zminku stoji moznost naprogramovani refresh rate pres standartizovany CRTC, takze pak neni problem si nastavit nakou ergonomickou frekvenci.

10FPS rozhodne neni dost rychle. Zvlast kdyz si uvedomis, jak rychle scrolluje obycejna textova konzole.

Ted si prestavam byt tim vyuzitim akcelerace ve Firefoxu jistej :-) Ne ze by to scrollovalo pomalu, ale pri prepinani mezi taby se mi (nekdy) na chvili zobrazi jakoby nahodna cast pameti (znas to, proste rozsypany vsebarevny obraz). Nedela to vzdycky, takze se ani nechystam se na to podivat vic do hloubky, ale mozna to o necem vypovida :-)

Firefox akceleraci scrollování má, ale pro kreslení nového
textu používá double-buffering --- nejřív si stránku
překreslí do paměti a pak paměť naráz zkopíruje do videoram.
Je to proto, aby stránka neblikala.
(asi kvůli nějakému bugu na chvíli překreslil nesmyl)

Netscape tohle neměl a aby to neblikalo, řešil to tak, že
začal zobrazovat, až když bylo přesně dáno, na kterou pozici
co přijde --- t.j. např. tabulku zobrazil, až když ji měl
celou; pokud byl v textu obrázek neznámé velikosti, počkal
se zobrazováním textu, dokud tento obrázek nenatáhl.

V grafickém linksu double-buffer nepoužívám (kvůli
pomalosti), tam jsem problém s blikáním vyřešil tak, že
vykreslovací rutina vykreslí každý pixel právě jednou.

Jak to scrollovani firefox akceleruje? gtk akceleraci nevyuziva...

Taky jsem mel ten dojem.
Ted me napadlo, jestli firefox neni "akcelerovan" tim, ze kdyz scrollujete rychle, neposouva po radkach ale rovnou po vetsich kusech ...

Určitě akceleraci používá --- mám tak pomalý počítač, že
překreslování bez akcelerace je na něm dost pomalé a firefox
a mozilla scrollují rychle.

Gtk nemá s akcelerací co dělat, gtk používá xlib, xlib
posílá požadavky xserveru a xserver dělá akceleraci. Takže
záleží na tom, jaký máte xserver, případně jak je nastavený.

Jak se to vezme - ano, fyzicky akceleraci provadi XServer, ale cela rada funkcnosti akcelerace funguje jen kdyz se s XServerem bavis specialnimi funkcemi ...

Ono se to smeti nezobrazilo pri scrollovani, ale pri prepnuti tabu. Tj. na tabove liste se vizualne provedlo prepnuti a textova cast se proste rozpadla a po chvili se vykreslila stranka (spravne).

Ono to scrollovani neni tak jednoduche, jak se na prvni pohled zda (ale to urcite vis). K dispozici jsou ruzne strategie, ktere se lisi rychlosti a kapacitou alokovane pameti. Pokud je dost pameti, tak je nejrychlejsi vyrendrovat celou stranku a potom ji jenom blitovat na obrazovku (nebo se posouvat ve Video RAM). Tolik pameti vsak vetsinou neni k dispozici, proto se musi vyrenderovane casti vhodne kesovat, aby to pri scrollingu porad nemuselo prekreslovat ty stejne casti.

Pekne je to videt na GhostScriptu/GhostView, a to diky tomu, ze je extremne pomaly :-)

Taky bys byl extremne pomaly, kdybys stranku kreslil interpretovanim turing-kompletniho zasobnikoveho jazyka.

Tim si nejsem tak jistej, i kdyz znam mnohem rychlejsi jazyky nez interpretovany PostScript (ktery ma i dalsi problemy, napriklad ten, ze se musi v pameti uchovavat cela stranka).

Napriklad PostScriptove tiskarny nedelaji celou dobu nic jineho a to v mnohem vyssim rozliseni nez je pitome CRT. Zatimco GhostScript musi vyrenderovat cca 1024x768 pixelu, tj. necely milion (dobre at nezeru, tak dva miliony, kdyz to renderuje i spodni pulku), tak si tiskarny musi poradit napriklad s 600x8x600x10=cca 29 miliony pixelu a dneska je to vlastne jeste ctyrikrat vic (u 1200 DPI). A nerekl bych, ze tam maji nejak extra rychle procesory.

PDF je taky zalozene na PostScriptu a renderuje se neskonale rychleji, takze tady to spis bude problem pomaleho interpreteru nebo renderovace v GhostScriptu.

Nerikam, ze interpret v ghostscriptu je nejrychlejsi mozny, ale IMHO ho dost zpomaluje dodrzovani norem - v ghostscriptu by melo fungovat KAZDE ps, tiskarny na nekterych vecech vytuhavaji (pravda, nejcasteji jim proste dojde pamet ...). Krome toho, nejsem si jisty jestli nekresli do vetsiho rozliseni nez ma CRT (a to i kdyz neantialiasuje).

PDF je sice zalozene na postscriptu, ale je v mnoha smerech zjednodusene (v jinych naopak rozsirene, pravda). Myslim, ze nektera z tech zjednoduseni byla za ucelem zrychleni ...

Ano, je pravda, ze v nekterych pripadech je GhostScript (jako konvertor ps->ps) jedine reseni u zmrsenych dokumentu, ktere pri poslani na tiskarnu zlobi. Vetsinou za to muzou napriklad spatne uvedene prikazy clearpage apod. (a samozrejme vsechno produkovane jednou nejmenovanou kancelari :-). Nevim, proc by GS vykresloval do vetsiho rozliseni, to by prece melo mnohem vyssi naroky na pamet, ale nevylucuji, ze se tam neco takoveho deje.

Z praktickeho hlediska mi tam vadi neexistence funkce "zoom window", takhle pohled musim pri zkoumani nejake titernosti slozite zvetsovat, zmensovat a posouvat, coz pri pomalosti renderovani uzasne zpomaluje praci. Nebo by stacilo neco na zpusob "zvetsovaciho skla", ktery je implementovany v mnoha DVI prohlizecich (to stejne bych nekdy potreboval i u Firefoxu, kdyz neco doladuji na pixely :-).

Trosku bych doplnil k tomu Falconu. Jeho graficky chip se jmenuje VIDEL, ktery na vystupu podporuje jak RGB tak VGA monitory. Je velice pruzny, takze se da "naprogramovat" pro ruzna rozliseni a neni nutne vybirat jenom z prednastavenych.

Rozliseni mohou byt bud plane orientovana (monochrom, 4, 16, 256 barev) nebo nebo muze bezet v 15 nebo 16 bitovem "chunky" rezimu. Barevna paleta pro bitplanove rozliseni je az 244000. Velikost frame bufferu, ktery lezi v hlavni pameti, se samozrejme muze hodne lisit. Monochromaticky obraz zabira zhruba 32KB, v barevnych rezimech to muze byt klidne i megabyte. Se zvetsujicim se framebufferem ale dochazi k zahlcovani pomale sbernice a system se tak zpomaluje.

Kvuli ruznym typum zobrazovacu, muze byt VIDEL taktovan z nekolika zdroju. Zakladni je 25 MHz (pro RGB rozliseni), dalsi je odvozena od hlavniho oscilatoru, ktery bezi bez pretaktovani na 32MHz (hlavni CPU bezi na polovine teto frekvence) nebo je mozno i pripojit externi oscilator treba pro uz zmineny genlocking. Rozsah generovanych frekvenci obrazu je taky pomerne dobry, jenze dosazitelna frekvence rapidne klesa s narustajicim rozlisenim. Vyhodne je tedy pouziti LCD monitoru, ktery je schopny zobrazovat i 1024x768 bodu na 50Hz bez velkeho blikani.

pokial si dobre spominam na svoje programatorske zaciatky, tak player/missile graphics na ATARI mala 4 hracov (sprites) + 4 strely a nie 8 ako tu uvadzate...
sice som mal ATARI 800XE, ale aj tak myslim, ze to bolo na vsetkych ATARI 8bitoch rovnake...

Omlouvam se, samozrejme, ze GTIA podporuje ctyri strely a ctyri hrace. Nechapu, jak jsem to mohl splest :-(, taky jsem mel Atarko (800XL) a s ANTICem a GTIA jsem si dost pohral.

Přemýšlím, jak se asi programuje 100 pohybujících se předmětů s 48 bajty RAM.

No, ono je mozne jeste vyuzit 256 bytu na cartridgi (kdyz byly pritomny). Ale udelat napriklad "prulet hvezdokupou" (tak se to tusim nazyva ve Windows) je na RAMku velmi nenarocne, protoze hvezdy jsou generovany pseudo random generatorem.

To je pravda. Ale stejně nechápu, jaké triky se při tom používají. Pseudonáhodný generátor vytvoří polohu předmětu. Jenže to je mi k ničemu, pokud se zrovna nenachází na řádku, který mám vykreslovat, nebo pokud pseudonáhodný generátor není tak geniální, že by předměty generoval v pořadí podle svislé osy.

Polohu si nemohu uložit, protože nemám dost paměti, a počítat před každým řádkem to zase nestihnu. S 256 bajty už je to lepší.

Dalsi vec pro premysleni je treba hra Snowball se 7000 mistnostmi nebo Sentinel s 10000 urovnemi a to vse na 48kB, oboji nedynamicky generovane :-)

Hmm, proti tomu je Starquake s 512 obrazovkami malej do skolky :-) Do teto hry jsem se trosku dival a vypada to, ze na jednu obrazovku "vyplacali" pouze 56 bytu. Take je tady Elite s mnoha tisici obydlenymi svety...

Jóó Sentinel, to byla klasika ..

Nevíte někdo jestli existuje předělávka na PC ?

Schvalne jsem si ve volne chvili predstavil, jak bych do 48 bajtu nacpal takoveho PacMana. A ono to jde, tech objektu je tam sice dost, ale stavove informace maji pro kazdy objekt tak osm bytu (pozice, vektor rychlosti, casovac pro "modre duchy", casovac pro chvili, kdy duch vyjede z centra obrazovky, prediktor pohybu) a dalsi informace zabiraji opravdu par bytu (score, hi-score, level, zivoty, casovac pro bonusy atd.).

ale hej, boli nove hry - ich hlavnym (poslednym) produktom v 8bit linii bol XE Game System, ktory mal primarne hry v cartridgi, ale bol to vlastne 800XE s oddelenou klavesnicou a novym lookom a trochu pozmenenym OS (mal tam zabudovanu gamesku). Ale je pravda, ze s C64 ci ZX sa to neda porovnat, 8bit Atarko na trhu upadalo od cca 85-teho...

skutocne moznosti grafiky... no, hmm, to sa da tazko jednoznacne povedat, doslova zalezi od doby - napr v sucasnosti nie je problem 160x192x256 farieb alebo 640x192 (rozne triky s ANTICom)... ale hej, tych 320x192 je dvojfarebna.

sprites - vertikalne neobmedzene, horizontalne 8 pixelov v najjemnejsej grafike, ktore sa dali skalovat (2x, 4x) a farby mohli mat z celej palety (128 farebnej).

ale inak mas pravdu - tramiel pre technologiu 8bit atari nespravil nic. takze islo fakt o pouzitie toho perfektneho navrhu este zo 70-tych rokov.

S tou grafikou na Atarku (ale nejenom na nem) je to tezke povedet presne. Playfield grafiky 320x192 byl opravdu cernobily (lepe receno monochromaticky, protoze specielne v tomto rezimu nezbyly takty pro vyber dvou barvovych registru), ale slo ho kombinovat se sprity a pomoci display listu menit barvove registry na kazdem obrazovem radku. Jeden z nejprofanovanejsich efektu na Atarku byla duha, kdy se soucasne zobrazovalo a menilo vsech 128 barev.

Take bylo mozne playfield rozsirit na cca 384x224 pixelu. Horizontalne se totiz dalo volit mezi 256, 320 nebo 384 pixely, vertikalne zalezelo na display listu, takze se k tem standardnim 192 dalo cca 32 radku bez problemu pridat (potom pry blbla synchronizace, ale to je spis problem NTSC nez PALu).

Co se tyce spritu a strel, tak ty byly barevne nezavisle na pozadi a jejich maximalni rozmery byly 8x256 pixelu (sprity) a 2x256 pixelu (strely). Kazdy sprite byl jednobarevny, ale opet se barvy daly menit v prubehu horizontalniho zatemneni. Nektere hry "jakoby" zobrazovaly i vice spritu, jednoduse si totiz prepsaly pamet se sprity v horizontalnim zatemneni, takze jeden fyzicky sprite se na obrazovce vyskytoval nekolikrat (nemohl vsak byt na stejne horizontalni urovni, ale "pod sebou").

Barvy se daly měnit kdykoliv, nejen podle horizontálního zatemnění. Hardware byl dokonale synchronní, refresh DRAM přicházel v přesně definovaných okamžicích a byl synchronizovaný s horizontálním rozkladem, grafický procesor četl z paměti v přesně definovaných okamžicích, takže s tabulkou doby vykonávání strojových instrukcí nebylo problém časovat změnu barvy i vertikálně.

Svého času jsem napsal klon Tetrisu, který tyto triky používal na obarvení kostiček. Bude-li zájem, mohu ho vystavit. Zajímavé je, že emulátor atari800 má časování dokonale vychytané a v poslední verzi již funguje zcela přesně.

Ano, pokud si s tim nekdo vyhral na jednotlive takty, tak se opravdu daly barvy menit i v prubehu jednoho radku (jestli si dobre pamatuji, tak co jeden pixel, to jeden takt, v gr.8 byly dva pixely na takt). Ja jsem vsak, jako mirne stredne pokrocily, skoncil pouze s obsluhou horizontalniho zatemneni :-)

Ten refresh DRAM byl opravdu synchronizovany s horizontalnim rozkladem, vyjimkou byl tusim gr.0 (textovy rezim), kde se to na zacatku snimku neustihalo a tak se misto deviti (?) refreshu provadel jen jeden. Ale uz je to tak davno, ze si presne casovani nepamatuji, jen vim, ze gr.0 byla takova specialitka.

To obarveni kosticek (=zmenu barvoych registru) jste stihal provadet pro jednotlive pixely? To se na 6502 snad ani neda ustihat, ale rad se necham poucit.

Jednotlivé kostičky obarvit nešly. Ale už si přesně nepamatuji proč, nevyházely mi barvy na zobrazení příští kostičky. Takže jsem musel nastavit barvu a na začátku hrací plochy bylo třeba barvu změnit. Pomáhal jsem si také sprity, které šly také dynamicky posouvat.

Zdroják jsem našel, ale nevyznám se v něm. Večer ho dám na své stránky.

Tak jsem si dal praci a v Atari literature (papirove) jsem nasel podrobnosti o casovani. Takze, pri frekvenci procesoru 1,79MHz (tj. verze PAL) je na jeden radek poskytnuto 114 strojovych cyklu, pricemz se pocita s 312 radky.

Kazdy strojovy cyklus odpovida delce trvani vykresleni dvou obrazovych bodu, tj. rozliseni by bylo pouze 228 pixelu horizontalne. Pouze gr.8 (a na nej navazujici gr.9, 10 a 11) ma vyjimku, tam pixely trvaji pouze 1/2 obrazoveho bodu - tady se to pekne plete s dnesnim nahledem na pixely jako obrazove body. Horizontalni zatemneni trva 40 strojovych cyklu.

Obnoveni trva opravdu 9 strojovych cyklu (to mam pamet!), dalsi cykly zabere DMA pro hrace a strely (to se provadi v horizontalnim zatemneni) a take pro display list.

Takze barvu opravdu nejde zmenit pro kazdy pixel (114<<320), odhaduji, ze pro takovou osmici sousednich pixelu to je mozne (zalezi na tom, jak je program napsan, zda si barvy pamatuje v nulte strance pameti atd.)

Tady je můj Tetris včetně zdrojáku: http://www.penguin.cz/~utx/ftp/atari/tetris/

Pokud se dobře pamatuji, časování paprsku jsem použil na obrázky kostiček vlevo od hrací plochy.

Ano, to je pravda, i kdyz ne u vsech pocitacu se to dalo v obsluze zatemneni udelat tak komfortne.

Ale nevim, jak jinak popsat grafiku u osmibitovych pocitacu, aby se daly mezi sebou srovnavat. Dneska je to jednoduche - horizontalni x vertikalni rozliseni x pocet barev x snimkova frekvence (nebo frekvence pixelclocku). Ale prakticky vsechny osmibity nejak obchazely omezene mnozstvi pameti pro framebuffer - at uz to jsou sprity ci "blokove" atributy u Spectra ci C=.

Snad "nejhorsi" je to u Amigy, zejmena u HAM rezimu. Jak se tento rezim da popsat - prece to neni rezim, kde muzu obarvit kazdy pixel jakoukoli barvou...

Jeste k J. Tramielovi. On je to v prvni rade obchodnik, ktery doslova prohlasil, ze osmibitovou radu Atarek bude produkovat pouze tak dlouho, dokud pro ne bude mit odbyt. Paradoxne prave na zadost "socialistickych" zemi se Atari 800XE vyrabelo a dovazelo prave do vychodni Evropy a to i v dobe, kdy se v zapadnich zemich ve velkem presedlavalo na stroje s MC68xxx.

Graficky je na tom Atarko srovnatelne napriklad s C64, v necem je to lepsi (display list, organizace pameti), v necem zase horsi (sprity). Pri produkci her vsak az tak nezalezi na HW kvalitach, ale na rozsireni, podpore atd.

Je však bohužel pravda, že hry na C64 vypadají obecně o dost líp než na Atari 800 XE/XL. Neříkám, že všechny (např. Tomahawk je ve verzi pro Atari nejhezčí), ale jinak většina her byla úplně pod úrovní Atari - tedy pod úrovní jeho možností (většina jich nedosahuje ani 25kB!!?).
Viz jinak na porovnání třeba tu: http://porovnani8bitu.spaces.live.com/

Tak tohle je bohužel pravda, Atari jsem v tomto nikdy nepochopil, vůbec nevím, proč ani nejnovější hry nemohli pořádně promakat, všechno to vypadalo jak na počítačích o 10 let zpátky. Přitom na C64 vyšly i takový hity jako Elvira (prakticky srovnatelná s verzí Amigy) aj.