Historie vývoje počítačových her (111. část – Reality Co-Processor v herní konzoli Nintendo 64)

Pavel Tišnovský 16. 1. 2014

V dnešní části seriálu o historii vývoje počítačových her a herního hardware dokončíme popis čtvrté významné konzole páté generace – Nintendo 64. Budeme se zabývat především čipem nazvaným Reality Co-Processor, který byl určen jak pro vykreslování 2D a 3D scén, tak i pro syntézu hudby a zvuků.

Obsah

1. Historie vývoje počítačových her (111. část – Reality Co-Processor v herní konzoli Nintendo 64)

2. Interní struktura Reality Co-Processoru

3. Reality Signal Processor (RSP)

4. RSP jako jedna z mnoha implementací vektorového procesoru typu SIMD

5. Registry RSP

6. Instrukce RSP

7. Využití akumulátorů připojených ke každé ALU v RSP

8. Reality Display Processor (RDP)

9. Příkazy posílané do rasterizační jednotky

10. Odkazy na Internetu

1. Historie vývoje počítačových her (111. část – Reality Co-Processor v herní konzoli Nintendo 64)

V předchozí části tohoto seriálu jsme si popsali dva základní moduly herní konzole páté generace nazvané Nintendo 64. Jednalo se především o centrální procesorovou jednotku založenou na RISCovém jádru řady MIPS R4000. Tento mikroprocesor podporoval 32bitové i 64bitové operace a obsahoval i matematický koprocesor. Minule jsme si též popsali paměťový subsystém, v němž byly použity paměťové moduly s architekturou Rambus. Dnes se budeme převážně zabývat třetím důležitým čipem umístěným v této herní konzoli. Jedná se o čip nazvaný Reality Co-Processor, neboli zkráceně též RCP. V tomto čipu byl implementován především grafický a zvukový subsystém a pravděpodobně nejzajímavější vlastností RCP je jeho programovatelnost a konfigurovatelnost, což například znamená, že grafický subsystém (resp. vykreslovací pipeline s rasterizační jednotkou) bylo možné přeprogramovat, implementovat v něm různé grafické algoritmy a filtry, využít framebuffer jako texturu pro další vykreslování atd.

Z dnešního pohledu se jednalo o středně složitý čip s přibližně 2,6 miliony tranzistorů, jehož plocha byla přibližně 81mm2. Pro zajímavost: zhruba třetinu plochy čipu zabíral Display Processor (tj. konfigurovatelná vykreslovací/rasterizační jednotka řízená specializovanými příkazy), další třetinu zabraly paměti pro instrukce, data i textury a jen pětina plochy čipu byla rezervována pro vektorový procesor, jehož popisem se budeme zabývat v navazujících kapitolách. Hodinový signál čipu RCP byl nastaven na frekvenci 62,5 MHz, tj. frekvenci odlišnou od hodinové frekvence hlavního procesoru a jeho špičková spotřeba nepřesahovala 2,8W. Díky tomu bylo možné čip chladit pouze s využitím pasivního chladiče, podobně jako tomu bylo v případě hlavního mikroprocesoru. Komunikace mezi jednotlivými moduly tohoto čipu probíhala po interní 128bitové sběrnici, takže přenosová rychlost se blížila jednomu gigabajtu za sekundu (62,5×128/8).

2. Interní struktura Reality Co-Processoru

Při návrhu interní struktury čipu RCP stáli jeho tvůrci před úkolem navrhnout takový čip, který by umožnil provádět syntézu hudby, dekódovat video a zobrazovat dvoudimenzionální i třídimenzionální grafické scény. Když se zamyslíme nad tím, co mají tyto čtyři činnosti společné, zjistíme, že většina algoritmů z těchto oblastí vyžaduje operace typické pro DSP procesory (sčítání se saturací, operace typu multiply-and-accumulate) a taktéž práci s vektory a maticemi. Reality Co-Processor byl následně navržen takovým způsobem, aby tyto operace podporoval, ovšem na druhou stranu nesměla být výrobní cena čipu příliš velká, protože by mohlo dojít k situaci, kdy by celá herní konzole Nintendo 64 byla dražší než herní konzole vyráběné konkurencí. Výsledkem snahy o „cenovou optimalizaci“ byl čip složený ze dvou modulů – Reality Signal Processor (RSP)Reality Display Processor (RDP). Oba moduly byly široce konfigurovatelné a programovatelné a to dokonce do takové míry, že u RCP bylo možné měnit mikrokód na základě požadavků vývojářů hry.

Obrázek 1: Interní struktura a moduly čipu Reality Co-Processor.

Důležitý byl i fakt, že Reality Signal Processor (RSP) byl zaměřen na práci s vektory, protože kromě klasické ALU, shifteru, pracovních registrů a (od sebe oddělených) pamětí pro instrukce a data obsahoval tento modul i osm paralelně pracujících 16/32 bitových aritmeticko-logických jednotek, z nichž každá byla připojena k samostatnému 32bitovému akumulátoru. Navíc byl Reality Signal Processor vybaven instrukcemi pro načítání a automatickou konverzi osmibitových hodnot, což souběžně s podporou operací se šestnáctibitovými a 32bitovými hodnotami dostačovalo jak pro implementaci audio algoritmů (digitální filtry, syntéza hudby), tak i pro algoritmy z oblasti 2D i 3D grafiky. Druhý modul Reality Display Processor (RDP), jenž byl přímo řízen z RSP, byl určen pro vykreslování 2D a 3D scén. Jeho hlavním úkolem bylo vykreslování trojúhelníků či obdélníků, které mohly být buď vyplněny barvou nebo pokryty texturou. Dále tento modul mohl při vykreslování provádět různé další operace, například aplikace filtrů atd. Výsledek vykreslování (rasterizace) se ukládal do framebufferu.

3. Reality Signal Processor (RSP)

V této kapitole si stručně popíšeme první modul čipu RCP, který se jmenuje Reality Signal Processor (RSP). Jedná se v podstatě o druhý samostatně pracující mikroprocesor založený na jádru MIPS R4000, podobně jako hlavní procesorová jednotka popsaná minule. Ovšem zatímco hlavní CPU dokázal provádět operace s 32bitovými i 64bitovými operandy, měl RSP poněkud odlišnou konfiguraci. Tento čip obsahoval 32bitové skalární pracovní registry a vlastní paměť pro data i instrukce – paměť pro data měla kapacitu 4kB a od ní oddělená paměť pro data měla tutéž kapacitu 4 kB. Pokud bylo zapotřebí pracovat s daty či instrukcemi umístěnými v hlavní paměti, musel být proveden přenos celého bloku dat s využitím DMA, protože RCP neměl do hlavní paměti přímý přístup, což je podobná koncepce, s jakou jsme se již několikrát setkali i u dalších herních konzolí páté generace (současně se však jedná i o úzké hrdlo celé konzole, což si ukážeme na příkladu texturovací jednotky).

Jedním z největších rozdílů mezi hlavní procesorovou jednotkou a modulem RSP bylo odstranění instrukcí pro práci s 64bitovými operandy i odstranění některých „pokročilejších“ instrukcí typu branch likely (opět viz předchozí část, kde jsou tyto instrukce z tohoto důvodu explicitně zmíněny) atd. Ovšem Reality Signal Processor byl naproti tomu obohacen o osm vektorových jednotek (Vector Unit – VU) pracujících paralelně, a to se vstupními operandy o šířce šestnáct bitů. Každá vektorová jednotka obsahovala vlastní aritmeticko-logickou jednotku (ALU), násobičku, shifter a taktéž 32bitový akumulátor, do něhož se ukládaly výsledky operací a který mohl sloužit i jako jeden vstupní operand (což znamená, že při vhodném naprogramování bylo možné provádět nejenom 16bitové operace, ale i operace částečně 32bitové). Navíc každá vektorová jednotka obsahovala i obvod umožňující provést součet všech osmi prvků vektorů. Celkový výpočetní výkon byl na dobu vzniku tohoto čipu úctyhodný – dosahoval až 500 000 000 operací typu multiply-and-accumulate za sekundu.

4. RSP jako jedna z mnoha implementací vektorového procesoru typu SIMD

Reality Signal Processor je příkladem čipu, v němž se spojily vlastnosti RISCových procesorů s architekturou SIMD neboli Single Instruction Multiple Data. Jedná se o v současnosti značně populární architekturu, jejíž kořeny ovšem sahají hluboko do minulosti, konkrétně do šedesátých a sedmdesátých let minulého století (tato oblast výpočetní techniky je spojena se Symourem Crayem a jeho superpočítači). Do této kategorie patří ty architektury procesorů, u kterých se pomocí jedné instrukce může zpracovat větší množství dat. Například u rozšířené instrukční sady MMX je možné pomocí jediné instrukce provést součet dvou vektorů číselných hodnot. Může se jednat o osm osmibitových hodnot uložených v jednom vektoru, čtyři šestnáctibitové hodnoty v jednom vektoru atd. Této vlastnosti se dá v mnoha případech využít pro urychlení běhu programů, protože některé algoritmy (ve skutečnosti je těchto algoritmů možná až udivující počet) provádí velké množství stejných operací s rozsáhlým objemem dat – například se může jednat o aplikaci konvolučního filtru na rastrový obrázek, zpracování zvukového signálu, vynásobení matice vektorem, vynásobení dvou matic atd.

Obrázek 2: Schéma systému patřícího do kategorie SIMD.

Mezi přednosti čipů náležejících do kategorie SIMD patří jak relativně kompaktní instrukční sada, tak i paralelní a tím pádem i rychlý běh mnoha algoritmů, ovšem za cenu větších nároků kladených na programátora, popř. na překladač. Stále jen velmi malé množství programovacích jazyků totiž umožňuje explicitně vyjádřit vektorové či maticové operace (například u překladače Fortranu určeného pro superpočítače Cray bylo v manuálu explicitně řečeno, které jazykové konstrukce se budou skutečně provádět ve vektorové – SISD – jednotce). Z tohoto důvodu také není možné většinu SIMD konstrukcí zapsat v konvenčním vyšším programovacím jazyce: musí se použít buď hotová makra, ručně optimalizované knihovní funkce nebo specializované programovací jazyky. Určitou, ale nezanedbatelnou výjimku představují GPU na grafických akcelerátorech, které explicitně pracují s 2D a 3D vektory, přičemž programátor může předem zjistit, které operace budou skutečně provedeny paralelně.

5. Registry RSP

Při programování modulu Reality Signal Processor měli vývojáři k dispozici dvě skupiny pracovních registrů. V první skupině se nacházelo třicet dva skalárních pracovních registrů, z nichž každý měl šířku 32 bitů. Tyto pracovní registry měly stejnou funkci, jakou jsme si popsali již v předchozí části tohoto seriálu – provádění běžných skalárních celočíselných aritmetických a logických operací, konverzi dat při jejich načítání a ukládání do paměti atd. Tato skupina registrů nás tedy dnes již nebude dále zajímat, ovšem o to zajímavější je druhá skupina pracovních registrů.

Ve druhé skupině se nacházelo taktéž třicet dva registrů, ovšem každý registr měl šířku plných 128 bitů. Těchto 128 bitů bylo interně rozděleno na osm částí, což znamenalo, že se vlastně jednalo o vektor s osmi prvky, přičemž každý prvek měl bitovou šířku šestnáct bitů. Každý prvek tohoto vektoru tedy mohl být samostatně zpracováván jinou vektorovou jednotkou, popř. se do vybraného registru mohlo uložit osm šestnáctibitových výsledků vypočtených paralelně ve všech osmi vektorových jednotkách. Některé instrukce navíc umožňovaly takzvané párování registrů, tj. provádění 32bitových operací. Mimochodem – datová paměť o kapacitě 4kB, o níž jsme se zmínili ve třetí kapitole, byla organizována po 128 bitových slovech, což znamenalo, že celý vektorový registr bylo možné z této paměti načíst či naopak uložit po přenosu jediného slova.

6. Instrukce RSP

Většina „vektorových“ instrukcí podporovaných modulem Reality Signal Processor měla tři operandy, což znamená, že dva operandy byly zdrojové a třetí operand cílový. Navíc bylo možné u druhého operandu uvést takzvaný modifikátor, který určoval, se kterými prvky osmibitového vektoru bude operace prováděna. Uveďme si jednoduchý příklad s instrukcí typu vadd (vector add), tj. instrukcí pro součet dvou osmiprvkových vektorů. Jedná se o instrukci se třemi operandy (dva operandy zdrojové a jeden operand cílový), přičemž u druhého zdrojového operandu (zde konkrétně u vektorového registru v3) je uveden modifikátor:

Instrukce Operace se provede s prvky
vadd $v1, $v2, $v3 0 1 2 3 4 5 6 7
vadd $v1, $v2, $v3[0] 0 0 0 0 0 0 0 0
vadd $v1, $v2, $v3[0q] 0 1 2 3 0 1 2 3
vadd $v1, $v2, $v3[1q] 4 5 6 7 4 5 6 7

Z tohoto příkladu je patrné, že i takto jednoduchá instrukce může být překvapivě flexibilní.

V následující tabulce jsou vypsány základní aritmetické instrukce prováděné nad osmiprvkovými vektory:

# Instrukce Význam
1 VADD  součet vektorů
2 VSUB  rozdíl vektorů
3 VSUT  opačný rozdíl vektorů (prohození operandů)
4 VABS  výpočet absolutní hodnoty prvků vektorů
5 VADDC součet s přenosem
6 VSUBC rozdíl s přenosem

Vektorové jednotky však mohly provádět i různé logické a bitové operace, například:

# Instrukce Význam
1 VLT   porovnání prvků vektorů (less than)
2 VEQ   porovnání prvků vektorů (equal)
3 VNE   porovnání prvků vektorů (not equal)
4 VGE   porovnání prvků vektorů (greater than or equal to)
5 VCR   jedničkový doplněk (negace)
6 VAND  operace typu AND prováděná nad prvky dvou vektorů
7 VNAND operace typu NAND prováděná nad prvky dvou vektorů
8 VOR   operace typu OR prováděná nad prvky dvou vektorů
9 VNOR  operace typu NOR prováděná nad prvky dvou vektorů
10 VXOR  operace typu XOR prováděná nad prvky dvou vektorů
11 VNXOR negace XOR prováděná nad prvky dvou vektorů

Tyto instrukce mají velký význam například pro implementaci 2D grafických algoritmů (maskování spritu apod.).

7. Využití akumulátorů připojených ke každé ALU v RSP

Jednou z často prováděných operací při implementaci různých algoritmů z oblasti zpracování audio signálu či 2D grafiky, jsou operace typu multiply-and-accumulate, tj. součin následovaný přičtením výsledku součinu k mezivýsledku uloženého do akumulátoru. Modul Reality Signal Processor pro podporu provádění těchto operací obsahuje osm 32bitových akumulátorů, přičemž každý akumulátor je umístěn na výstupu ALU+shifteru každé vektorové jednotky. Instrukční sada RSP je rozšířena o několik instrukcí, které tento akumulátor využívají. Tyto instrukce jsou založeny na násobení dvou šestnáctibitových operandů, přičemž výsledek je 32bitový. Tento výsledek je buď přímo uložen do akumulátoru (tj. přepíše předchozí hodnotu), nebo je přičten k aktuální hodnotě akumulátoru. Povšimněte si, že se stále jedná o tříoperandové instrukce i toho, jakým způsobem je vypočten výsledek vrácený v cílovém operandu:

# Instrukce Prováděná operace
1 VMUDL acc  = (src1 * src2) >> 16, dest = acc & 0×ffff
2 VMADL acc += (src1 * src2) >> 16, dest = acc & 0×ffff
3 VMUDM acc  = (src1 * src2), dest = acc >> 16
4 VMADM acc += (src1 * src2), dest = acc >> 16
5 VMUDN acc  = (src1 * src2), dest = acc & 0×ffff
6 VMADN acc += (src1 * src2), dest = acc & 0×ffff
7 VMUDH acc  = (src1 * src2) >> 16, dest = acc >> 16
8 VMADH acc += (src1 * src2) >> 16, dest = acc >> 16

To, že je šířka akumulátoru 32 bitů, zatímco šířka všech operandů jen šestnáct bitů, není v oblasti zpracování signálu žádná novinka, protože v mnoha DSP je šířka akumulátoru větší než bitová šířka ostatních registrů i buněk operační paměti – například mnohé digitální signálové procesory určené pro práci s audio signálem zpracovávají sice šestnáctibitové vzorky, ovšem mezivýsledky jsou ukládány do akumulátoru o šířce 20 či 24 bitů.

Druhou modifikací sčítačky a násobičky v mnoha DSP je to, že pracují s takzvanou saturací. Její princip je velmi jednoduchý – výsledky aritmetických operací nepřetíkají (nepočítá se tedy „modulo N“), ale v případě, že je výsledek operace větší než nejvyšší reprezentovatelná hodnota, zapíše se do výstupního registru maximální hodnota, například 65535 u DSP pracujícího s šestnáctibitovými čísly bez znaménka (to je přesně případ RSP). Podobně je tomu u minimálních hodnot, pokud jsou vzorky reprezentovány čísly se znaménkem. Kvůli saturaci sice taktéž dochází ke ztrátě informace – například ořezání maximálních hodnot u audio signálu – jedná se ovšem o mnohem menší zlo, než kdyby došlo k přetečení a uložení pouze spodních bitů výsledku se zanedbáním bitů s nejvyššími váhami.

8. Reality Display Processor (RDP)

Druhou jednotkou umístěnou na čipu Reality Co-Processor je modul RDP neboli plným jménem Reality Display Processor. Jedná se o konfigurovatelnou rasterizační a texturovací jednotku řízenou příkazy posílanými z modulu RSP popsaného výše (viz též schéma zobrazené pod tímto odstavcem). To znamená, že při správném naprogramování RSP bylo zajištěno plně automatické vykreslování 2D či 3D scén, a to bez nutnosti toho, aby do tohoto procesu jakkoli zasahoval hlavní mikroprocesor. Reality Display Processor byl navíc vybaven i lokální pamětí o kapacitě čtyři kilobajty, která byla použita pro uložení právě využívané textury. Textury mohly být uloženy v několika různých formátech, od běžného 16bitového či 24bitového RGBA přes osmibitový formát s paletou až po formát, v němž byla textura reprezentována texely se specifikací světlosti, popř. světlosti a průhlednosti (použití různých formátů bylo vynuceno mj. i relativně malou kapacitou paměti pro textury, o níž jsme se zmínili výše).

Obrázek 3: Reality Display Processor je řízen příkazy posílanými z Reality Signal Processoru.

Reality Display Processor se od některých dalších dobových 3D akcelerátorů odlišoval především tím, že byl široce konfigurovatelný, což znamenalo, že programátoři mohli (samozřejmě opět přes RSP) implementovat celou řadu různých grafických algoritmů, včetně Gouraudova stínování, využití paměti hloubky (Z-bufferu), environment mappingu, bilineární či dokonce trilineární interpolace při texturování popř. provádění antialiasingu při vykreslování hran. Zejména díky trilineární interpolaci a antialiasingu byly 3D scény vykreslované herní konzolí Nintendo 64 většinou kvalitnější v porovnání s konkurenčními konzolemi, a to přesto, že velikost (rozlišení) textur byla omezena relativně malou kapacitou texturovací paměti (navíc se při použití trilineární interpolace musela textura ukládat vícekrát, například s rozlišením 32×32 pixelů, 16×16 pixelů a 8×8 pixelů). Při texturování bylo též možné provádět perspektivní korekci na úrovni jednotlivých pixelů, použít framebuffer (do něhož se vykreslování provádělo) jako zdroj pro další texturu (efekty zrcadlení) apod.

9. Příkazy posílané do rasterizační jednotky

Do rasterizační jednotky byly z Reality Signal Processoru postupně posílány příkazy, které jednotka ihned začala vykonávat. Většina příkazů měla délku 64 bitů a lze je rozdělit do třech kategorií: konfigurační příkazy, řízení rasterizační a texturovací pipeline a vykreslovací příkazy. Nejkomplexnější byly konfigurační příkazy sloužící pro nastavení či přenastavení RDP. Mohl se například přesně specifikovat formát výstupu/framebufferu (RGBA, YUV, intenzita, intenzita+průhlednost), formát pixelů ve framebuferu (4bit, 8bit, 16/32bit RGBA), šířka framebufferu, adresa framebufferu (šla snadno změnit), adresa Z bufferu atd. U textur bylo taktéž možné přesně specifikovat jejich formát.

Obrázek 4: Do RDP vstupují údaje o trojúhelnících/obdélnících i o texturách, celá vykreslovací pipeline je konfigurovatelná.

Nejzajímavější jsou konfigurační příkazy určené pro řízení vykreslování: zde bylo možné nastavit ořezávací box (scissor test), povolit interpolaci textur (včetně typu interpolace), povolit perspektivní korekci při mapování textur, zapnout dithering (v závislosti na formátu framebufferu), měnit stav Z bufferu (zákaz zápisu, zákaz aplikace testu na hloubku fragmentů) apod.

widgety

Vykreslovací příkazy byly poněkud překvapivě (zejména při porovnání s příkazy, které jsme si uvedli u dalších herních konzolí) velmi jednoduché. Jednalo se o příkaz pro vykreslení vyplněného čtyřúhelníku a o příkaz pro vykreslení čtyřúhelníku pokrytého texturou. Jak budou tyto čtyřúhelníky vytvořeny bylo ponecháno na programovatelném modulu RSP, který většinou ve svých vektorových jednotkách prováděl jak výpočty projekce, tak i výpočty související s osvětlovacím modelem. Do poslední skupiny příkazů patří příkazy pro řízení vykreslovací pipeline. Většinou se používal příkaz pro synchronizaci pipeline ve chvíli, kdy došlo ke změně textury.

Z tohoto popisu je zřejmé, že díky kombinaci RSPRDP byl grafický subsystém herní konzole Nintendo 64 velmi flexibilní, ovšem v některých případech se negativně projevovalo omezení rozlišení textur kvůli poměrně malé kapacitě vyrovnávací paměti pro textury. K tomuto tématu se vrátíme při popisu a porovnání her vytvořených pro jednotlivé herní konzole páté generace.

10. Odkazy na Internetu

  1. Great Microprocessors of the Past and Present: Part IX: Signetics 8×300, Early cambrian DSP ancestor (1978):
    http://www.cpushack.com/CPU/cpu2­.html#Sec2Part9
  2. Introduction to DSP – DSP processors:
    http://www.bores.com/courses/in­tro/chips/index.htm
  3. The Scientist and Engineer's Guide to Digital Signal Processing:
    http://www.dspguide.com/
  4. Digital signal processor (Wikipedia EN)
    http://en.wikipedia.org/wi­ki/Digital_signal_processor
  5. Digitální signálový procesor (Wikipedia CZ)
    http://cs.wikipedia.org/wi­ki/Digitální_signálový_pro­cesor
  6. Digital Signal Processing FAQs
    http://dspguru.com/dsp/faqs
  7. FIR Filter FAQ
    http://dspguru.com/dsp/faqs/fir
  8. Finite impulse response (Wikipedia)
    http://en.wikipedia.org/wi­ki/Finite_impulse_response
  9. DSPRelated
    http://www.dsprelated.com/
  10. Don't Blame Rare, Blame Rambus
    http://www.therwp.com/forum­s/showthread.php?t=881
  11. RDRAM
    http://en.wikipedia.org/wiki/RDRAM
  12. MIPS Architecture Overview
    http://tams-www.informatik.uni-hamburg.de/applets/hades/web­demos/mips.html
  13. MIPS Technologies R3000
    http://www.cpu-world.com/CPUs/R3000/
  14. Sony PlayStation (Wikipedia)
    http://en.wikipedia.org/wi­ki/PlayStation_(console)
  15. The Official PlayStation muzeum
    http://playstationmuseum.com/pla­ystation-systems/
  16. CPU-collection: IDT R3010 FPU
    http://www.cpu-collection.de/?tn=0&l0=co&l1=ID­T&l2=R3010+FPU
  17. The MIPS R2000 Instruction Set
    http://suraj.lums.edu.pk/~cs423a05/Re­ference/MIPSCodeTable.pdf
  18. Maska mikroprocesoru RISC 1
    http://www.cs.berkeley.edu/~pat­trsn/Arch/RISC1.jpg
  19. Maska mikroprocesoru RISC 2
    http://www.cs.berkeley.edu/~pat­trsn/Arch/RISC2.jpg
  20. The MIPS Register Usage Conventions
    http://pages.cs.wisc.edu/~cs354–2/beyond354/conventions.html
  21. C.E. Sequin and D.A.Patterson: Design and Implementation of RISC I
    http://www.eecs.berkeley.e­du/Pubs/TechRpts/1982/CSD-82–106.pdf
  22. Berkeley RISC
    http://en.wikipedia.org/wi­ki/Berkeley_RISC
  23. Great moments in microprocessor history
    http://www.ibm.com/develo­perworks/library/pa-microhist.html
  24. Great Microprocessors of the Past and Present
    http://www.cpushack.com/CPU/cpu1.html
  25. Sega documentation
    http://koti.kapsi.fi/~anti­me/sega/docs.html
  26. 1995 Programming on the Sega Saturn
    http://cowboyprogramming.com/2010/06/03/1995-programming-on-the-sega-saturn/
  27. Sega Myths-Saturn was the most difficult console to program for of 5th Gen
    http://forums.sega.com/show­thread.php?313485-Sega-Myths-Saturn-was-the-most-difficult-console-to-program-for-of-5th-Gen
  28. SuperH RISC engine Family
    http://www.renesas.com/pro­ducts/mpumcu/superh/index­.jsp
  29. Sega Saturn
    http://en.wikipedia.org/wi­ki/Sega_saturn
  30. Jaguar Sector – II
    http://www.jaguarsector.com/index.php
  31. Atari Age: Atari Jaguar History
    http://www.atariage.com/Ja­guar/history.html
  32. Jaguar
    http://www.giantbomb.com/jaguar/3045–28/
  33. Consoles that won't die: The Atari Jaguar
    http://venturebeat.com/2013/04/25/con­soles-that-wont-die-atari-jaguar/
  34. Atari Jaguar and Atari Jaguar CD
    http://videogamecritic.com/ja­guarinfo.htm
  35. Atari Jaguar Documentation (Forum)
    http://www.jaguarsector.com/in­dex.php?showforum=65
  36. Atari Jaguar Programming (Forum)
    http://www.jaguarsector.com/in­dex.php?showforum=63
  37. The Jaguar Underground Documentation
    http://justclaws.atari.or­g/devcats/dox/dox.htm
  38. Blitter (Wikipedia CZ)
    http://cs.wikipedia.org/wiki/Blitter
  39. Blitter (Wikipedia EN)
    http://en.wikipedia.org/wiki/Blitter
  40. Bit blit
    http://en.wikipedia.org/wiki/Bit_blit
  41. Disassembler for the portable Jaguar DSP emulator (zdrojový kód s instrukcemi)
    http://mamedev.org/source/src/e­mu/cpu/jaguar/jagdasm.c.html
  42. Fourth-Generation Consoles
    http://gaming.wikia.com/wiki/Fourth-Generation_Consoles
  43. Fifth-Generation Consoles
    http://gaming.wikia.com/wiki/Fifth-Generation_Consoles
  44. History of video game consoles (fifth generation)
    http://en.wikipedia.org/wi­ki/History_of_video_game_con­soles_(fifth_generation)
  45. Atari Jaguar
    http://gaming.wikia.com/wi­ki/Atari_Jaguar
  46. Atari Jaguar Games
    http://gaming.wikia.com/wi­ki/List_of_Atari_Jaguar_ga­mes
  47. MyMedia Games Network Retrospective – Nintendo Super FX chip
    http://psp.mmgn.com/News/MyMedia-Games-Network-Retrospe-G6W
  48. Wikipedia: Super FX
    http://en.wikipedia.org/wiki/Super_FX
  49. IGN: Top 25 Consoles
    http://www.ign.com/top-25-consoles/13.html
  50. Sega Mega Drive
    http://sega.jp/archive/segahard/md/
  51. The16bit Era Of Console Video Games
    http://tvtropes.org/pmwiki/pmwi­ki.php/Main/The16bitEraOf­ConsoleVideoGames
  52. The Console Wars
    http://www.cracked.com/funny-2590-the-console-wars/
  53. Console Wars
    http://tvtropes.org/pmwiki/pmwi­ki.php/Main/ConsoleWars
  54. Era of the „Bit Wars“
    http://www.gtplanet.net/fo­rum/threads/era-of-the-bit-wars.119796/
  55. Rez Wars: How the Bit Wars never really ended
    http://www.ign.com/blogs/be­astmastertoad/2013/01/31/rez-wars-how-the-bit-wars-never-really-ended
  56. Which system ended the „Bit Wars“?
    http://atariage.com/forum­s/topic/199163-which-system-ended-the-bit-wars/
Našli jste v článku chybu?
Root.cz: Podívejte se na shořelé Samsung Note 7

Podívejte se na shořelé Samsung Note 7

Vitalia.cz: 5 důvodů, proč jet na výlov rybníka

5 důvodů, proč jet na výlov rybníka

Měšec.cz: TEST: Vyzkoušeli jsme pražské taxikáře

TEST: Vyzkoušeli jsme pražské taxikáře

DigiZone.cz: Světový pohár v přímém přenosu na ČT

Světový pohár v přímém přenosu na ČT

Lupa.cz: Co všechno je Facebook schopný cenzurovat?

Co všechno je Facebook schopný cenzurovat?

Lupa.cz: Jak levné procesory změnily svět?

Jak levné procesory změnily svět?

Podnikatel.cz: Udělali jsme velkou chybu, napsal Čupr

Udělali jsme velkou chybu, napsal Čupr

DigiZone.cz: DVB-T2 ověřeno: seznam TV zveřejněn

DVB-T2 ověřeno: seznam TV zveřejněn

DigiZone.cz: Parlamentní listy: kde končí PR...

Parlamentní listy: kde končí PR...

Vitalia.cz: Vodárny varují: Ve vodě z kohoutku jsou bakterie

Vodárny varují: Ve vodě z kohoutku jsou bakterie

DigiZone.cz: Nova opět stahuje „milionáře“

Nova opět stahuje „milionáře“

Vitalia.cz: Tradiční čínská medicína a rakovina

Tradiční čínská medicína a rakovina

Podnikatel.cz: Nemá dluhy? Zjistíte to na poště

Nemá dluhy? Zjistíte to na poště

120na80.cz: Co je padesátkrát sladší než cukr?

Co je padesátkrát sladší než cukr?

Lupa.cz: Jak se prodává firma za miliardu?

Jak se prodává firma za miliardu?

Vitalia.cz: Test dětských svačinek: Tyhle ne!

Test dětských svačinek: Tyhle ne!

Vitalia.cz: Jak Ondra o astma přišel

Jak Ondra o astma přišel

DigiZone.cz: Technisat připravuje trojici DAB

Technisat připravuje trojici DAB

Lupa.cz: Adblock Plus začal prodávat reklamy

Adblock Plus začal prodávat reklamy

Lupa.cz: Odkazy na pirátský obsah mohou být nelegální

Odkazy na pirátský obsah mohou být nelegální