Vyvojova deska pro ARM

[Petr Kubáč]

Nazdar Jiri
 Nevim jestli panove vedi co pisou, protoze soucasne grafiky kdy kazdy pixel 
je jeden cely (nebo dokonce vice byte) se obsluhuje dramaticky jinak nez 
stare grafiky ve stylu CGA/EGA/VGA karet ktere mely 1-4 bity na pixel. 
(nebereme li to ze dneska uz stejne veskerou manipulaci s VideoRAM dela GPU)

VGA hardware se tvari jako 1-4 bitove roviny nad sebou. Procesor vidi jen 
jednu bitovou rovinu jako pole bitu - jeden pixel jeden bit. Ktera bitova 
rovina to je se nsstavuje v MASK registru takze pixel se zapisuje tak, ze si 
nastavis si barvu pixelu do mask registru a pak nastavis ten jediny bit ve 
videoram - VGA hardvare nastavi tento bit ve vsech rovinach ktere maji 
jednicku v MASK registru. Takze z hlediska zachazeni s Videoram je 16 
barevne vga uplne identicke s tvym jednobitovym 640x400 (az na absenci MASK 
registru)

Pro radikalnni urychleni BitBlt se v techto systemech kupodivu pouziva 
jednoducha finta - oblast odkud i oblast kam se prenasi je zarovnana na cely 
byte a i velikost (delka radku je delitelna 8 (cely pocet bytu) - pak se pri 
BITBLT nemusi delat bitove posuny - jestli nekdo mate stare WIN3.1 nastavte 
si 16 barevne rozliseni a zahybejte oknem - skoro nikdo si toho bez 
upozorneni nevsimne ze okno skace v 8pixelovem rastru). Navic aby byl BitBlt 
efektivnejsi prenaseji se s transferem jedineho bitu  pres zachytne registry 
vsechny bitove roviny, takze presun jednoho byte je vlastne presun 4 bytu.

Ve tvem pripade nevim jestli sis tuhle operaci tema dvema videoramkami 
paralelne nezkomplikoval.
ale zarovnavani posouvanych oblasti na cely byte je velka uspora

Jinak bych snad nekde vyhrabal vlastni VGA kninovnu pro 1-16 barev do 
rozliseni 800x600 psanou v X86 assembleru - kde je to pekne videt.

Zdravi Petr Kubac



----- Original Message ----- 
From: "Jiri Bezstarosti" <jiri@bezstarosti.cz>
To: "HW-news" <hw-list@list.hw.cz>
Sent: Thursday, June 19, 2008 7:28 PM
Subject: Re: Vyvojova deska pro ARM


> Jasne, ale trosku mi to koliduje s nejjednodussim resenim. V tom totiz v
> jednu chvili uvolnim sbernici k videoram a zapisu obsah zachytnych
> registru (adresa i data jdou mimo CPLD), pak ji zase prevezmu CPLD a ctu
> 8 bodu a to stale dokola. Takze vzdycky 3 faze oscilatoru ctu pro
> zobrazeni, 1 fazi mam uvolnovani sbernice, 3 faze zapisuji a 1 faze zase
> pro uvolneni sbernice. Tim vzdycky behem cteni nactu 8 bodu a pokryju
> tim potrebu tech 8 fazi pro zobrazeni.
>
> Jenze pokud posunu zobrazeni, musim posunout i kam zapisuji, abych mel
> stale horni levy roh zobrazeni na zacatku adresniho prostoru videoram.
> To je pomerne vyrazne zesloziteni. Kdyz ale uvazim, ze bych chtel
> vykreslovat nejaka okenka, posuvem cele obrazovky si stejne moc
> nepomuzu. Takze je to dobre akorat pro ciste textovy rezim pres celou
> obrazovku a nebo pro grafiku ve stylu "raketka/auticko leti/jede nad/po
> krajine a ta se posouva pod nim".
>
> Myslim, ze posuv cele obrazovky ozelim.
>
> --
> Jiri Bezstarosti
>
> Jan Waclawek napsal(a):
>
>>No, musis mat najprv register na ten posuv, no a potom ho bud adderom 
>>pricitas tesne pred vystupom na adresy videoRAM, alebo len ho pouzijes ako 
>>restart hodnotu citaca adresy pre obnovovanie (ktory musi byt vhodne 
>>zacykleny, samozrejme).
>>
>>Tieto dve moznosti sa potom lisia v software, druhemu sa meni adresa 
>>"prveho riadku", prvemu nie...
>>
>>wek
>>
>>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list@list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list