Herní konzole Uzebox (2) a nástroje pro programování mikrořadičů Atmel AVR

29. 3. 2011

Doba čtení: 19 minut

Líbí se vám článek?
Podpořte redakci

V dnešní části seriálu o architekturách počítačů nejprve dokončíme popis herní konzole Uzebox vybavené osmibitovým mikrořadičem ATmega644. Poté si řekneme, jaké nástroje je možné použít pro vývoj programů pro mikrořadiče Atmel AVR. Samozřejmě se zaměříme především na ty nástroje, které jsou dostupné v Linuxu.

Obsah

1. Grafické režimy herní konzole Uzebox – pokračování

2. Grafické režimy využívající dlaždice uložené v paměti programu (Flash)

3. Skutečný bitmapový režim (Mode 8) a bitmapa uložená v paměti programu

4. Grafický režim číslo 9 (Mode 9)

5. Programování osmibitových mikrořadičů Atmel AVR

6. GCC AVR a AVR binutils

7. AVRA – Advanced AVR Macro Assembler

8. Uzem: emulátor herní konzole Uzebox

9. Odkazy na Internetu

1. Grafické režimy herní konzole Uzebox – pokračování

V předchozí části tohoto seriálu jsme si řekli základní informace o poněkud netypické herní konzoli Uzebox, která je založena na osmibitovém mikrořadiči ATmega644. Tento mikrořadič je kromě obvyklé činnosti (řízení hry, čtení vstupních zařízení atd.) mj. použit i pro generování obrazového signálu, jenž je posléze konvertován do formátu kompozitního videa nebo S-videa. Kromě popisu jednotlivých čipů a dalších elektronických součástek, z nichž se tato herní konzole skládá, jsme se seznámili i s principem grafických režimů implementovaných programově v kernelu nahraného do paměti Flash mikrořadiče. Připomeňme si, že grafické režimy (nebo alespoň jejich převážná část) implementované v kernelu herní konzole Uzebox nepoužívají klasický framebuffer, tj. obrazovou paměť, v níž by byl uložen rastrový obraz, který se má zobrazit na televizoru nebo monitoru. Implementace klasického framebufferu není při použití 256 barev možná z toho důvodu, že mikrořadič ATmega644 má pouze čtyři kilobajty paměti dat (SRAM), v níž se ukládá stav kernelu, stav hry, programový zásobník atd.

Obrázek 1: Herní konzole Uzebox sestavená na nepájivém kontaktním poli. Autor tohoto snímku testuje různé způsoby generování video signálu, tj. potřebuje časté změny v zapojení.

Většina grafických režimů podporovaných kernelem je založena na tom, že se grafická informace rozdělí na dvě části. První část představují bitmapové definice takzvaných dlaždic, jejichž velikost například dosahuje hodnot 6×8 pixelů či 8×8 pixelů a počet současně zobrazitelných barev je roven 256 (bitová hloubka=8bpp), což je současně i maximální počet barev, které herní konzole Uzebox dokáže zobrazit – viz též předchozí díl s vysvětlením funkce portu C a trojice digitálně-analogových převodníků pro barvové složky R, G, B. Vzhledem k tomu, že se bitmapy dlaždic pro danou hru či další aplikace většinou nemusí měnit, mohou být bitmapy uložené v paměti Flash, kam se nahrají společně s binárním kódem hry. Druhou částí grafické informace je pravidelná matice obsahující buď šestnáctibitové ukazatele na bitmapy jednotlivých dlaždic nebo osmibitové indexy těchto dlaždic (v tomto případě lze použít „jen“ 256 různých bitmap). Tato matice je uložena v datové paměti SRAM, protože se její obsah v průběhu hry neustále mění.

Obrázek 2: Měření signálu, který je posílán přes port C na digitálně-analogové převodníky, osciloskopem, generovaný snímek je současně přenášen i na televizor.

2. Grafické režimy využívající dlaždice uložené v paměti programu (Flash)

Minule jsme si též popsali původní grafický režim nazývaný Mode 1, který byl implementovaný již v raných verzích kernelu herní konzole Uzebox. V tomto režimu se používaly dlaždice mající velikost 6×8 pixelů a matice se šestnáctibitovými ukazateli (na dlaždice v paměti Flash) měla rozměry 40×28 dlaždic. Rozlišení výsledného obrazu zobrazeného na televizoru bylo rovno 240×224 pixelům (40×6=240, 28×8=224), ovšem alokovaná kapacita pro matici v paměti programu byla poměrně velká: 40×28×2=2240 bajtů, což znamenalo, že pro kernel, samotnou hru, zásobník atd. zůstalo k dispozici pouze 1856 bajtů paměti RAM. Z tohoto důvodu se u většiny dalších grafických režimů namísto šestnáctibitových ukazatelů používají osmibitové indexy, přičemž výpočet skutečné adresy, kde leží bitmapové informace dlaždic, je ponechán na kernelu (většinou se jedná o pouhý bitový posun a přičtení offsetu). Jedním z důsledků je omezení počtu dlaždic na 256, což je sice většinou více než dostatečný počet pro samotnou hru, ale potíže mohou nastat například při návrhu úvodní obrazovky, protože se původně bitmapový obrázek musí rozdělit na dlaždice s maximálně 256 bitmapovými vzorky.

Obrázek 3: Jednou ze známých her pro domácí osmibitové počítače Atari, kde byl využit grafický režim číslo 12 (číslování dle Atari Basicu, nejedná se o kód používaný čipem Antic), je Boulder Dash, mimochodem taktéž převedený na herní konzoli Uzebox.

Tento způsob uspořádání grafické paměti ostatně není nijak nový – velmi podobný způsob byl totiž použit již v osmdesátých letech minulého století u herních automatů (viz též bitmapy získané z ROM těchto automatů) a taktéž v osmibitových počítačích Atari. Řeč je v tomto případě o grafických režimech číslo 12 a 13, kde byly jednotlivé dlaždice uloženy jako znaky kdekoli v operační paměti a obrazová paměť (taktéž alokovaná kdekoli v operační paměti) obsahovala pouze matici o velikosti 40×24 (960 bajtů) resp. 40×12 (pouze 480 bajtů) barevných „znaků“. Vzhledem k různým omezení grafického čipu ANTIC bylo možné současně zobrazit pouze pět barev, pokud ovšem nebyly použity sprity a popř. i dynamická změna barvové palety. Na herní konzoli Uzebox je tento způsob uspořádání grafické paměti použit u grafických režimů Mode 2, Mode 3, Mode 4 a částečně i v režimu Mode 9, kterým se ještě budeme podrobněji zabývat v dalším textu.

Obrázek 4: Další známá hra z osmibitového domácího počítače Atari využívající grafický režim číslo 12 – Monty.

3. Skutečný bitmapový režim (Mode 8) a bitmapa uložená v paměti programu

Kernel herní konzole Uzebox obsahuje i jeden bitmapový režim se skutečným framebufferem, jehož rozlišení a počet současně zobrazitelných barev však musel být snížen z toho důvodu, že celý framebuffer musí být uložen v datové paměti (SRAM). Rozlišení tohoto grafického režimu (konkrétně se jedná o Mode 8) je pouze 120×96 pixelů a počet současně zobrazitelných barev se snížil na 4 barvy, teoreticky je však možné barvovou paletu dynamicky měnit, například po vykreslení každého obrazového řádku. Vzhledem k tomu, že pro reprezentaci jedné ze čtyř barev pixelu dostačují dva bity (2bpp), je spotřeba datové paměti rovna 120×96×2=23040 bitům, tj. 2880 bajtům. Použití tohoto grafického režimu není ve hrách příliš časté, protože s každým pohybem hráče, nebo dokonce pohybem celé scény, je nutné přepočítat hodnoty jednotlivých pixelů, což v sobě zahrnuje i relativně pomalou manipulaci s jednotlivými bity (mnohem jednodušší a rychlejší je manipulace s celými bajty, což je ostatně jeden z důvodů, proč většina dalších grafických režimů používá 256 barev, tj. osm bitů na pixel).

Obrázek 5: Mandelbrotova množina vykreslená v bitmapovém grafickém režimu číslo 8.

Existují ovšem situace, ve kterých není nutno zobrazovat bitmapu, jejíž pixely se mají měnit – může se jednat například o úvodní obrazovku hry. V tomto případě je možné mít celou bitmapu uloženou v paměti programu (Flash), díky jejíž mnohem větší kapacitě lze použít rastrové obrázky s 256 barvami. Ovšem i v tomto případě je vhodné myslet na to, že rastrové obrázky uložené v bitmapě mohou mít poměrně značnou velikost – například bitmapa o rozlišení 240×224 pixelů s 256 současně zobrazitelnými barvami by obsadila 53760 bajtů z dostupných 65536 bajtů. Řešením je tedy buď snížit počet barev (což však vede k méně výkonné vykreslovací rutině omezující rozlišení obrazového řádku) nebo snížit horizontální a/nebo vertikální rozlišení. Pokud se například spokojíme s bitmapou mající rozlišení 160×120 pixelů, sníží se spotřeba paměti Flash na 19200 bajtů, což je již v některých případech akceptovatelná hodnota – nesmíme totiž zapomenout na to, že ve Flash je uložen kernel, samotný kód hry, ale i rastrové obrázky jednotlivých dlaždic.

Obrázek 6: Hra Dungeon Slash využívající grafický režim s dlaždicemi o rozměrech 16×16 pixelů, který je navíc ve spodní části rozšířen o možnost výpisu textů, přičemž jednotlivé znaky používají dlaždice o menší velikosti.

4. Grafický režim číslo 9 (Mode 9)

Jedním z nejnovějších grafických režimů, které byly na herní konzoli Uzebox implementovány, je grafický režim číslo 9 (Mode 9). Jedná se sice o režim založený na dlaždicích (tiles), tj. rozdělení grafické paměti na bitmapové dlaždice a matici obsahující osmibitové indexy těchto dlaždic, ovšem oproti dalším „dlaždicovým“ grafickým režimům se Mode 9 odlišuje v jednom detailu: dlaždice nejsou v paměti Flash uloženy jako pouhé bitmapy, které musí subrutina obsažená v kernelu postupně načítat bajt po bajtu, ale jedná se o plnohodnotné podprogramy volané kernelem (ten se nestará o to, co tyto podprogramy dělají, ostatně na to ani nemá během vykreslování čas). Každá dlaždice je tedy realizována jako podprogram uložený ve Flash, což mj. i urychluje vykreslování, protože lze použít instrukce typu LDI trvající pouhý jeden strojový takt. Díky tomu bylo možné zvýšit rozlišení v tomto režimu na 360×240 pixelů, což odpovídá matici o velikosti 45×30 dlaždic, přičemž každá dlaždice je představována programem generujícím bitmapu o velikosti 8×8 pixelů.

Obrázek 7: Grafický režim číslo 9 je použit například v demoverzi hry Uze Snakes.

Alternativně je též možné použít dlaždice o velikosti 6×8 pixelů, přičemž se v tomto případě matice dlaždic zvětší na rozměry 60×30. Již se dokonce objevily i návrhy na vytvoření her tradičně pracujících v textovém režimu, které by již byly díky matici 60×30 dlaždic snadno realizovatelné, a to dokonce s poměrně dobře čitelným fontem s rozlišením jednotlivých znaků 6×8 pixelů (mimochodem – bitmapy s fonty lze získat zde). Jednou z nevýhod tohoto grafického režimu je však mnohem větší spotřeba paměti typu Flash, protože namísto jednotlivých bajtů tvořících dlaždice 8×8 pixelů (tj. 64 bajtů na každou dlaždici) je nutné v grafickém režimu číslo 9 vytvořit sérii instrukcí pro načtení konstanty a následný zápis této konstanty na port C (kam jsou připojeny D/A převodníky). Spotřeba paměti Flash je tak zhruba šestkrát větší než v případě použití klasických bitmapových dlaždic. Ani myšlenka dlaždic reprezentovaných programovým kódem však není zcela nová – na podobném principu jsou například založeny takzvané kompilované sprajty v knihovně Allegro.

Obrázek 8: Font používající znaky definované v matici 6×8 pixelů.

5. Programování osmibitových mikrořadičů Atmel AVR

Ve druhé části tohoto článku si stručně popíšeme, jaké nástroje je možné použít pro programování osmibitových mikrořadičů Atmel AVR. Jeden cyklus programování je možné rozdělit na dva kroky. V prvním kroku se provede kompilace a slinkování programu, přičemž výsledkem je binární či „hexa“ soubor (je podporovaný formát firmy Intel i Motorola), který obsahuje obraz programu v paměti Flash. Ve druhém kroku je nutné takto vytvořená data buď nějakým způsobem skutečně nahrát do paměti Flash mikrořadiče, nebo tato data načíst v emulátoru. Nejprve se zmíním o druhé části problému – nahrávání programu do paměti Flash mikrořadiče. Vzhledem k tomu, že čipy AVR jsou vybaveny takzvanou technologií ISP, lze je přeprogramovávat i ve chvíli, kdy jsou tyto mikrořadiče umístěny na plošném spoji a jsou k nim připojeny další elektronické součástky – není tedy zapotřebí je vyjímat a vkládat do programátoru (samozřejmě za předpokladu, že čtveřice dále zmíněných pinů není příliš zatížena). Pro samotný přenos dat postačují čtyři vodiče – RESET, CLK, MISO a MOSI (viz též předcházející části tohoto seriálu).

Obrázek 9: Převaděč mezi sběrnicí USB a paralelním portem.

Paradoxně bylo programování mikrořadičů Atmel AVR jednodušší v minulosti, kdy byly prakticky všechny osobní počítače vybavené paralelním portem, na němž se dala programově simulovat sériová sběrnice využívající výše uvedené čtyři vodiče. Poněkud složitější je propojení mikrořadiče a PC přes sériový port, především z toho důvodu, že je zapotřebí měnit napěťové úrovně. I to je však možné zařídit s několika pasivními součástkami, i když není norma RS-232C dodržena zcela přesně. S příchodem sběrnice USB však pomalu začal z osobních počítačů mizet nejdříve paralelní port a poté i port sériový, takže se vývojáři používající mikrořadiče museli přeorientovat právě na použití sběrnice USB. Z tohoto důvodu vznikl „otevřený“ projekt programátoru nazvaného USBtinyISP, který je založený (což asi není překvapivé) taktéž na mikrořadiči Atmel AVR.

Obrázek 10: Schéma zapojení převaděče mezi sběrnicí USB a paralelním portem.

Mikrořadič použitý v tomto programátoru konvertuje datový tok ze sběrnice USB na formát vhodný pro programování mikrořadičů, tj. na čtveřici signálů RESET, CLK, MISO a MOSI. Pro vlastní přenos dat lze použít nástroj AVRDUDE (AVR Downloader/UploaDEr), což je relativně malý program (balíček má velikost zhruba 780 kB) ovládaný z příkazové řádky, který dokáže mikrořadič programovat jak přes paralelní a sériový port, tak i přes programátory připojované ke sběrnici USB, včetně programátoru USBtinyISP.

6. GCC AVR a AVR binutils

Programy pro osmibitové mikrořadiče se dnes většinou připravují (editují, kompilují i linkují) na osobním počítači s tím, že se teprve výsledná přeložená binární podoba aplikace převede do programové paměti mikrořadiče. Výjimku představují pouze některá interaktivní prostředí založená většinou na programovacím jazyku Forth, kdy je možné osobní počítač použít pouze jako terminál komunikující s mikrořadičem (další výjimkou jsou již v minulosti zmíněné pokusy o převod programovacího jazyka Basic na mikrořadiče). My se však budeme zabývat především dnes nejpoužívanějším způsobem vývoje – vytvářením aplikací pro osmibitové mikrořadiče v programovacím jazyku C, přičemž tyto aplikace jsou překládány cross-compilerem na osobním počítači, kde jsou taktéž slinkovány a převedeny do binárního či textového (hexa) tvaru, kterým rozumí například výše zmíněná utilita AVRDUDE. V případě osmibitových mikrořadičů Atmel mají vývojáři k dispozici kromě komerčních nástrojů i velmi dobrý překladač GCC AVR (balíček se většinou jmenuje gcc-avr), který je doplněný standardní knihovnou avr-libs (balíček se jmenuje stejně) a v neposlední řadě i sadou nezbytných utilit binutils AVR (balíček binutils-avr).

Obrázek 11: Jedna z možných podob programátoru mikrořadičů Atmel AVR, který se k osobnímu počítači připojuje přes USB.

Některé základní utility dostupné v binutils AVR jsou vypsány v následující tabulce. Kromě těchto utilit mohou vývojáři samozřejmě používat i většinu dalších nástrojů, které jim Linux pro vývoj v programovacím jazyku C nabízí, například nástroje ctags, make, indent atd.:

Utilita	Popis
gcc	překladač programovacího jazyka C, při překladu pro AVR se volí model mikrořadiče (ten ovlivňuje i to, které instrukce se při překladu budou generovat)
avr-ar	práce s archivy (knihovnami), v nichž jsou většinou uloženy přeložené objektové soubory
avr-as	GNU assembler používaný překladačem céčka
avr-ld	linker
avr-gprof	zpracování a zobrazení informací získaných profilerem
avr-strip	odstranění symbolů (například debugovacích informací) z objektových souborů

Obrázek 12: USBASP – další typ programátoru připojitelného na sběrnici USB.

7. AVRA – Advanced AVR Macro Assembler

V předchozí kapitole byl mj. zmíněn i nástroj nazvaný avr-as. Jedná se o GNU assembler (gas), který je využíván překladačem GCC pro tvorbu objektových souborů, tj. binárních souborů obsahující programový kód přeložený do strojového jazyka, který je dále určený pro slinkování linkerem. Ovšem GNU assembler není z několika důvodů příliš vhodný pro ruční překlad programů z assembleru (jazyka symbolických instrukcí), nehledě na to, že jeho syntaxe není v případě mikrořadičů Atmel AVR kompatibilní s původním assemblerem AVRASM32 dodávaného samotnou firmou Atmel. Jako náhrada za proprietární assembler AVRASM32 vznikla poměrně malá aplikace nazvaná AVRA (balíček s binárním programem a dokumentací má pouze 150 kB), která je vytvořená v ANSI C a lze ji tedy přeložit a používat na prakticky jakémkoli systému vybaveném překladačem splňujícím normu ANSI C.

Obrázek 13: Pro usnadnění vývoje programů pro čipy Atmel AVR existuje i sada pluginů pro vývojové prostředí Eclipse.

Snahou autorů bylo dosažení co nejlepší kompatibility s AVRASM32, ovšem s několika vylepšeními. Mezi tato vylepšení patří například podpora maker preprocesoru; jedná se například o makra .if, .else, .define, .undef, .include atd. Dále může tento assembler vytvářet soubory ve formátu COFF (Common Object File Format), které díky přítomnosti ladicích informací umožňují použití GDB při ladění programů. Taktéž jsou podporována makra s parametry. V následujícím jednoduchém příkladu jsou nejprve vytvořena symbolická jména pro čtyři pracovní registry R16 až R19, poté je nadefinováno makro subs₁₆_16 počítající rozdíl dvou šestnáctibitových operandů a následně je makro zavoláno s dvojicí dvojic :-) pracovních registrů:

.def    a = r16
.def    b = r17
.def    c = r18
.def    d = r19

; makro s parametry:
.macro  subs_16_16
        sub     @1,@3
        sbc     @0,@2
.endm

; zavolání makra s dvojicí dvojic registrů
subs    [a:b,c:d]

Obrázek 14: Pluginy v prostředí Eclipse používají externí nástroje zmíněné v předchozí kapitole.

8. Uzem: emulátor herní konzole Uzebox

Pro vývoj her i dalších aplikací určených pro herní konzolu Uzebox lze použít emulátor nazvaný jednoduše Uzem (UZebox EMulator), který je možné získat na stránce http://code.google.com/p/Uzebox/downloads/list. Uzem emuluje originální Uzebox s mikrořadičem ATmega644. Pro generování grafiky a zvuků používá tento emulátor známou multimediální knihovnu SDL, taktéž podporuje myš a čtení stavů joysticků. Z toho důvodu, že emulátor Uzem používá multiplatformní knihovnu SDL (konkrétně minimálně verzi 1.2), lze ho použít na mnoha operačních systémech, samozřejmě včetně Linuxu, Microsoft Windows či MacOS. Vzhledem k tomu, že herní konzole Uzebox nepoužívá pro ovládání her a dalších programů klávesnici či myš, ale dvojici ovladačů určených pro konzole NES a SNES, je funkce těchto ovladačů emulována, a to buď jenom na klávesnicí, nebo i s využitím joysticku.

Obrázek 15: Plně osazený programátor USBtinyISP.

Zajímavá a užitečná je taktéž emulace prokládání obrazu na televizorech, díky níž je možné i na počítačovém monitoru (používajícím dnes vesměs neprokládané zobrazení) odhalit některé vizuální chyby, které by se objevily až na reálné konzoli s připojeným televizorem (pravda je, že Uzebox díky malému triku umožněnému normami PAL i NTSC zobrazuje obraz neprokládaně za cenu nižšího vertikálního rozlišení, ovšem i tak může existence dvou prokládaných půlsnímků způsobovat nepěkné chvění, ovlivnění barev sousedních pixelů atd.). Ovšem pro vývoj her pro herní konzoli Uzebox lze použít i mnoho dalších programů, především editory a konvertory spritů a dlaždic, které dokážou tato grafická data připojit k binárnímu strojovému kódu hry a nahrát vše současně do paměti Flash mikrořadiče ATmega644. K dispozici jsou i nástroje specializované pro určitý typ her, například LePlatz Level Editor určený pro přípravu plošinovek (nutno říci, že tento program je dobře použitelný i pro vývoj plošinovek na PC).