Historie vývoje počítačových her (105. část – herní konzole Atari Jaguar)

28. 11. 2013

Doba čtení: 13 minut

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

V dnešní části seriálu o historii vývoje počítačových her si popíšeme parametry herní konzole Atari Jaguar. I když se z komerčního hlediska nejednalo o úspěšný výrobek, je interní struktura konzole velmi zajímavá a neobvyklá, protože kombinovala možnosti RISC procesorů s generátorem grafiky a blitterem.

Obsah

1. Historie vývoje počítačových her (105. část – herní konzole Atari Jaguar)

2. Byl Jaguar skutečnou 64bitovou herní konzolí?

3. Interní struktura konzole Atari Jaguar

4. Základní vlastnosti RISCových procesorů GPU a DSP

5. Object processor a způsob generování grafiky

6. Blitter – důležitá součást grafického subsystému

7. Rastrové operace prováděné blitterem

8. Vývoj her pro konzoli Atari Jaguar

9. Odkazy na Internetu

1. Historie vývoje počítačových her (105. část – herní konzole Atari Jaguar)

V předchozích částech tohoto seriálu jsme se mj. dozvěděli, že jednou z nejdůležitějších firem v oblasti videoher a herních konzolí byla v sedmdesátých letech minulého století společnost Atari, která vyráběla jak různé videoautomaty (včetně legendární hry Pong), tak i osmibitovou programovatelnou herní konzoli Atari 2600. Dominance této firmy pokračovala i na začátku osmdesátých let, ovšem právě společnost Atari byla poměrně vážně postižena krachem na trhu s videohrami v roce 1983. Tyto problémy způsobily v roce 1984 rozdělení celé firmy na dvě samostatné divize a jak vedení společnosti, tak i zákazníci (hráči) očekávali, jaké nové konzole tato společnost dokáže navrhnout a prodávat. Po neúspěchu osmibitové konzole Atari 5200 a relativním neúspěchu taktéž osmibitového stroje Atari 7800 bylo rozhodnuto provést velký skok dopředu a vytvořit či zakoupit práva na mnohem výkonnější herní konzole vybavené buď 32bitovými či dokonce 64bitovými čipy (takto velkého skoku se žádná další firma neodvážila).

Původní návrh nových typů herních konzolí vznikl na základě výzkumu provedeného v britské společnosti Flare Technology, která již na začátku devadesátých let vytvořila návrh konzole nazvané Konix Multisystem. Společnosti Atari a Flare Technology vytvořily novou firmu nazvanou Flare Two, na jejíž půdě byly navrženy dvě konzole, které dostaly označení Panther a Jaguar. Panther měla být poněkud méně výkonná 32bitová konzole, jenž měla konkurovat a výkonově překonat SNES či Segu Genesis, zatímco Jaguar měl být jednou z nejvýkonnějších dostupných herních konzolí na trhu. Ovšem již v průběhu vývoje, kdy začalo být zřejmé, že se na trhu v průběhu cca dvou let objeví Sega Saturn a PlayStation, byl projekt Panther ukončen a celý vývoj se soustředil na jediný výrobek – Jaguar (dokonce došlo i k zastavení projektu počítače Falcon 040). Jaguar se nakonec stal posledním zařízením tohoto typu, který společnost Atari oficiálně vydala (posledním titulem pro Jaguara byla hra Fight For Life z roku 1996). Existovaly sice i prototypy konzole Jaguar II, ty se však již nedostaly na výrobní linky.

2. Byl Jaguar skutečnou 64bitovou herní konzolí?

Herní konzole Atari Jaguar byla již od svého prvního ohlášení oficiálně označována jako 64bitové zařízení. O tom, co vlastně označení 64bitů v tomto konkrétním případě znamená, bylo již popsáno mnoho papíru a zaplněno mnoho diskusních fór :-), nicméně skutečností zůstává, že i při podrobné znalosti interních struktur této herní konzole je jen velmi obtížné určit skutečnou „bitovost“ jak celé konzole, tak i jejich jednotlivých částí, o čemž se ostatně budete moci přesvědčit sami, protože zatímco některé čipy pracují s 64bitovými daty, další čipy zde použité jsou pouze 32bitové, i když mezi sebou i mezi operační pamětí komunikují po 64bitové sběrnici (zde se jednalo asi o největší přednost této konzole oproti některým konkurenčním výrobkům, protože při přenosu dat s použitím hodinového signálu 13,3 MHz se dosahovalo teoretické maximální rychlosti 100 MB/s, což vůbec není špatná hodnota pro relativně levné zařízení určené pro masový trh).

Mohlo by se dokonce zdát, že bitová šířka zpracovávaných údajů má u herních konzolí jen minimální význam, což je zajisté pravda (ostatně dnes se již tento údaj většinou neuvádí, minimálně ne s takovým důrazem, jako v době postupného přechodu od osmibitových konzolí ke konzolím 64bitovým – viz též již několikrát použitý termín „bit wars“), nicméně společnost Atari postavila reklamu na Jaugara právě na tomto faktu, že se jedná o skutečnou a přelomovou 64bitovou konzoli, zatímco (jak reklama mohla jen naznačovat) konkurence prodává „pouze“ technologicky zaostalé 32bitové systémy (3DO Interactive Multiplayer, Sega Saturn) či dokonce 16bitové systémy (SNES, Sega Genesis). Navíc je nápis 64-BIT INTERACTIVE MULTIMEDIA SYSTEM natištěn přímo na obalu této konzole, takže bude pravděpodobně zajímavé prozkoumat, zda je toto tvrzení pravdivé či nikoli.

3. Interní struktura konzole Atari Jaguar

Nejzajímavější jsou na herní konzoli Atari Jaguar použité čipy i způsob jejich vzájemného propojení a komunikace. Veškeré funkce totiž byly soustředěny do tří čipů, z nichž dva (nazývané „Tom“ a „Jerry“) byly vyvinuty přímo pro potřeby Jaguara, zatímco třetím čipem byl klasický a lety ověřený mikroprocesor Motorola 68000, který však původně v této konzoli měl plnit spíše pomocnou roli (což se však ve skutečnosti nestalo, protože mnozí vývojáři právě na tomto CPU prováděli převážnou část výpočtů). Čipy Tom a Jerry obsahovaly architektonicky prakticky shodné 32bitové RISCové procesory, které se však využívaly k odlišným operacím: procesor na čipu Tom se staral o zobrazování grafiky, zatímco procesor na čipu Jerry byl využíván pro zvuky a hudbu. Tom navíc obsahoval dva další moduly: 64bitový Objektový procesor (Object Processor) a taktéž 64bitový blitter. Zajímavé je, že jednotlivé čipy používaly odlišný endianess, tj. způsob uložení bajtů v 32bitových a 64bitových slovech.

Nejdůležitější vlastnosti všech tří čipů tvořících základ herní konzole Atari Jaguar jsou vypsány v následujících třech tabulkách:

Čip	Frekvence	Poznámka
Tom	26,591 MHz	video procesor
Jerry	26,591 MHz	zvukový subsystém (DSP, FM+AM syntéza)
M68000	13,296 MHz	použitý mj. i pro bootstrap celého systému

Moduly čipu Tom	Popis
GPU	32-bitový Grafický procesor (GPU) (32bit RISC architektura)
OP	64-bitový Objektový procesor 64bit RISC, generování grafiky, podpora až 24bitů RGB
Blitter	64-bitový Blitter, mohl realizovat z-buffering, Gouraudovo stínování

Moduly čipu Jerry	Popis
DSP	RISC 32bit, stejný jako jádro GPU
	16bitový stereo výstup (tj. CD kvalita)
	FM syntéza, AM syntéza, wavetable syntéza
	(jednotlivé tvary vln pro FM a AM syntézu jsou uloženy v paměti: sinus, pila, …

4. Základní vlastnosti RISCových procesorů GPU a DSP

Základem čipů Tom i Jerry jsou RISCové procesory, jejichž architektura je z velké části odvozena od „klasické“ architektury RISC I, i když zde nalezneme některé odlišnosti, jejichž princip byl převzat spíše z mikroprocesorů s architekturou CISC (instrukce proměnné délky, některé složitější instrukce rozkládané na sekvenci podoperací). Oba RISCové procesory obsahovaly dvě banky registrů, přičemž v každé bance bylo uloženo třicet dva pracovních registrů o šířce 32 bitů, které byly označovány jmény R0 až R31. Jak je tomu u „klasické“ RISC architektury poměrně obvyklé, obsahovat registr R0 konstantu 0, zatímco registr R31 byl použit jako ukazatel na vrchol zásobníku (SP). Zajímavé bylo, že operační kódy většiny instrukcí měly šířku pouze dva bajty (16 bitů), což znamená, že při načtení 64bitového slova z operační paměti bylo možné načíst a začít zpracovávat čtyři instrukce. Jen několik instrukcí mělo dvojnásobnou šířku, což je ale logické, když si uvědomíme nutnost práce s číselnými konstantami či cíli skoků.

Kromě běžných instrukcí, které lze u klasických RISCových procesorů očekávat zde můžeme nalézt i speciálnější instrukce, například několik instrukcí pro sčítání osmibitových, šestnáctibitových či 24bitových slov se saturací, tj. bez přetečení (u většiny formátů byly podporovány jak znaménkové, tak i bezznaménkové hodnoty). Sčítání se saturací bylo možné použít při mnoha operacích s rastrovými obrázky i při práci se zvukem, takže vlastně není překvapivé, že zde – u procesorů navržených pro herní konzoli – tyto operace nalezneme. Kromě těchto instrukcí stojí za zmínku i další specializované instrukce PACK (Pixel Pack), UNPACK (Pixel Unpack), MIRROR a především MMULT (násobení matic). Poslední jmenovaná instrukce se rozkládala na sekvenci instrukcí jednodušších, což sice není zcela čisté „RISCové“ řešení, ovšem zde hrálo velkou úlohu především praktické využití, stejně jako existence děličky pracující paralelně s ALU (mimochodem: dělení trvalo osmnáct taktů :-).

5. Object processor a způsob generování grafiky

Herní konzole Atari Jaguar má překvapivě jednu věc společnou se svým slavným prapředkem Atari 2600. Obě tyto konzole, které od sebe dělilo celých patnáct let (což znamená jak jednu generaci hráčů, tak i zcela odlišné technologie), totiž neobsahovaly klasický framebuffer. Na Atari 2600 byl obraz generován na základě údajů uložených do několika osmibitových registrů (sprity + pozadí), zatímco u Atari Jaguaru se o vytváření obrazu staral do velké míry takzvaný Object Processor (64bitový modul), jenž byl součástí čipu Tom. Object Processor postupně načítal rastrové objekty (říkejme jim taktéž sprity) z paměti, vzájemně je kombinoval a ukládal výsledek do takzvaného line bufferu, jenž se skládal z pouhých dvou obrazových řádků – řádku právě vykreslovaného a řádku následujícího. Samotný modul, který se staral o tvorbu videosignálu, pouze četl obrazová data z line bufferu a vůbec neměl přístup do operační paměti, což značně zjednodušilo spolupráci všech čipů na sběrnici.

Jaké objekty však byly Object Processorem zpracovávány? Základem byl jednoduchý lineárně vázaný seznam nazývaný object list, který obsahoval objekty různých typů. Jednalo se především o rastrové obrázky obsahující buď přímo barvy či odkazy do palety, takzvaný GPU objekt (způsobil zastavení GPU a provedení jiné subrutiny), objekt způsobující rozvětvení seznamu o konečně objekt obsahující značku konce seznamu (zde Object Processor ukončil zpracování obrazového řádku). Object list se neustále zpracovával pro každý obrazový řádek, což mj. znamenalo, že bylo možné jeho obsah měnit a provádět tak posuny objektů, změnu jejich priorit (posunem objektu v seznamu dopředu či dozadu) atd. Rastrové objekty samozřejmě mohly mít nastavené transparentní pixely a původní modul pro řízení priority spritů zde byl nahrazen jednoduchým mechanismem – priority vykreslování (či spíše překreslování) jednotlivých objektů jsou určeny pozicí objektu v object listu, což je vlastně logické (Object Processor vezme jeden objekt a vykreslí z něj příslušnou vodorovnou sekvenci pixelů, nezávisle na tom, co je již předtím vykresleno do line bufferu.

6. Blitter – důležitá součást grafického subsystému

Další velmi důležitou a současně i praktickou součástí čipu Tom byl i modul Blitter. Tento termín, jenž je odvozen od zkratky BLock Image Transfer (BLIT), je již tradičně používán pro označení čipu či modulu, jehož hlavní funkcí je přenos rastrových obrazových dat společně s prováděním určené operace nad přenášenými daty – může se jednat například o základní rastrové operace typu maskování či naopak o pokročilejší operace typu změny měřítka či rotace obrázku (záleží na schopnostech daného blitteru). Prvním blitterem použitým v elektronickém zařízení dostupném široké veřejnosti byl Blitter, jenž byl součástí čipu Agnus ve slavném OCS (Original Chipset) použitém v osobních mikropočítačích Amiga. Později byl použit název BLiTTER (kvůli ochranným známkám psaný takovým způsobem, jak je zde uvedeno) pro podobně pracující čip zabudovaný do osobních mikropočítačů Atari Mega ST a odtud je již relativně přímá cesta k mnohem výkonnějšímu Blitteru, s nímž se můžeme setkat v herní konzoli Atari Jaguar.

Při návrhu blitteru vhodného pro herní konzoli Atari Jaguar se inženýři vyvarovali některých problémů, které provázely použití BLiTTERu v mikropočítačích Atari Mega ST. Konfigurace blitteru v Jaguaru je totiž při provádění většiny operací velmi snadná, což je důležité, protože pokud by bylo nutné pro každou funkci blitteru nastavit například třicet různých registrů, bylo by asi výhodnější veškeré operace raději provádět programově :-). V případě Jaguaru většinou postačovalo nastavit jen pět konfiguračních registrů a i přesto byly operace, které mohl Blitter při kopii rastrových (či jiných!) dat provádět, poměrně široké. Především bylo možné pro zdrojovou i cílovou bitmapu nastavit různou bitovou hloubku (1, 2, 4, 8, 16 či 32bitů), bylo možné operovat buď nad pixely či nad 64bitovými slovy (4× rychlejší operace, ovšem za cenu některých omezení) a rychlost přenosu a zpracování v režimu práce s pixely dosahovala hodnoty 2,7 milionů pixelů za sekundu, což je více než 50000 pixelů na snímek.

7. Rastrové operace prováděné blitterem

Při přenosu dat blitterem mohly být automaticky prováděny operace spočívající v kombinaci zdrojových pixelů (či dat) a cílových pixelů (dat). Díky existenci těchto operací bylo snadné zajistit například maskování obrázku, vymazání cílového obrázku (resp. obecně vymazání bloku paměti) apod. V následující tabulce je vypsáno všech šestnáct operací, které blitter dokázal s daty provádět (! značí negaci, & bitový součin a | bitový součet):

#	Název	Prováděná operace
0	LFU_ZERO/LFU_CLEAR	DST = 0
1	LFU_NSAND	DST = ! SRC & ! DST
2	LFU_NSAD	DST = ! SRC & DST
3	LFU_NOTS	DST = ! SRC
4	LFU_SAND	DST = SRC & ! DST
5	LFU_NOTD	DST = ! DST
6	LFU_N_SXORD	DST = ! (SRC ^ DST)
7	LFU_NSORND	DST = ! SRC \| ! DST
8	LFU_SAD	DST = SRC & DST
9	LFU_SXORD/LFU_XOR	DST = SRC ^ DST
10	LFU_D	DST = DST
11	LFU_NSORD	DST = ! SRC \| DST
12	LFU_S/LFU_REPLACE	DST = SRC
13	LFU_SORND	DST = SRC \| ! DST
14	LFU_SORD	DST = SRC \| DST
15	LFU_ONE	DST = 1

To ovšem není zdaleka vše, protože Blitter dokázal při přenosu provádět změnu měřítka a dokonce i rotovat bitmapu o libovolný úhel. Pro přenášenou bitmapu bylo totiž možné nastavit jak počátek kopírování, tak i sklon původně vodorovné osy, čímž došlo k rotaci. Při správně nastavených parametrech tak mohl Blitter vykreslovat i úsečky. Ke kopírovaným pixelům bylo možné přičítat i konstantu, což byla operace, kterou bylo možné použít pro provádění Gouraudova stínování (přechod mezi intenzitami jedné barvy atd.). Stačilo, aby zdrojová bitmapa či zde spíše úsečka měla konstantní barvu a automatické přičítání nastavené konstanty (s jejím postupným zvětšováním) vedlo ke kýženému efektu. Blitter taktéž umožňoval vykreslování s využitím paměti hloubky (Z-buffer). Zde bylo nutné kombinovat barvy s hodnotami hloubky (vlastně další barva, i když nevykreslovaná) a při kopii bitmap se provádělo porovnání s uloženou hloubkou. Výsledek porovnání určil, zda se má pixel zkopírovat či nikoli.

8. Vývoj her pro konzoli Atari Jaguar

Z předchozího popisu je zřejmé, že se tvorba her na konzoli Atari Jaguar dosti podstatným způsobem odlišovala od způsobu tvorby her na osobních počítačích či na dalších herních konzolích. Základem bylo vybudování object listu, tj. seznamu vykreslovaných rastrových obrázků (spritů). Při jejich vzájemné kombinaci a tvorbě mohl být použit blitter a (alespoň teoreticky) měly být veškeré tyto operace řízeny přímo RISC procesorem umístěným na čipu Tom, zatímco nezávisle na jeho práci se měly čipem Jerry generovat zvuky a hudba. Při tvorbě 3D her se měl – podle původního návrhu – na generování grafiky podílet především blitter, a to díky podpoře Gouraudova stínování a Z-bufferu. Ovšem samotné rozložení trojúhelníků na obrazové řádky, zajištění zdrojové textury atd. museli vývojáři provádět ručně, takže se nedá říci, že by čip Tom zahrnoval všechny funkce grafického akcelerátoru.

Mikroprocesor Motorola 68000 měl provádět spíše koordinační činnost (staral se taktéž o bootstrap celého systému), ovšem u mnoha her se (později, reverse engineeringem :-) zjistilo, že mnoho operací bylo prováděno právě na M68000 a nikoli na k tomu určené dvojici RISC procesorů (pro vývojáře se jednalo o nejjednodušší řešení, protože s M68000 měli již mnoho zkušeností, vývojové nástroje atd.). To se samozřejmě projevilo na nižším výkonu her, než by se mohlo při pohledu na technickou specifikaci Atari Jaguaru očekávat. Je to škoda, protože možnosti Jaguaru nebyly prakticky nikdy plně využity a až po mnoha letech (například při konverzi slavné hry Another World) se ukázalo, jaké možnosti Atari Jaguar vývojářům a hráčům ve skutečnosti nabízel.