Osobně jsem měl AGA v dobách, kdy jsem vlastnil A1200 (cca roky 1995-1999), velmi rád. Možnost mít Productivity mód ve více než 16 barvách 4 barvách z palety 64 (omezení ECS) bylo fajn. Ale stejně jsem Workbench a programy při 31kHz proháněl jen ve dvou nebo max třech bitplanes a více barev tak bylo dobré leda na statické obrázky.
Amigu 1200 patřičně dovybavenou nějakou rozumnou turbokartou (B1230?) doteď považuju za to nejlepší, co si člověk může pro ukojení své nostalgie pořídit.
Ale smutným faktem je, že AGA byla hodně velká bída.
Z pohledu programátora přinesla jen tři věci navíc: 1. Větší počet bitplanes (osm), 2. Lepší podpora 35 nSec pixelů (rozlišení), 3. 4x data fetch mode. To první a druhé bylo nutností, pokud Commodore chtěl aspoň trochu zlepšit konkurenceschopnost Amigy proti VGA (SVGA) PC kartám (a dalším počítačům jako byl Mac, Atari Falcon, ...). A to třetí byla nutnost, protože Commodore nezrychlil Chip-RAM sběrnici. Proč tak neučinil netuším. Nejspíš kvůli ceně a zpětné kompatibilitě? Samozřejmě A1200 těch vylepšení přinesla o něco víc (68020, expansion slot, PCMCIA, IDE, ...), ale co se týče on-board grafiky, tak to byla bída.
Zvětšení počtu bitplanes je jistě skvělá věc. Jenomže sběrnice zůstala stejně pomalá, jako u OCS z roku 1985. Na šestnáct vygenerovaných low-res pixelů stále existuje jen osm DMA slotů. Takže udělat fetch všech osmi bitplanes sebere všechny DMA sloty a tak se, když se generuje obraz, nikdo do Chip-RAM (a ke custom chip registrům) nedostane. Copper, Blitter, CPU - nikdo. A pokud by chtěl programátor použít 72nSec nebo 35nSec rozlišení (640, 1280), tak prostě není možno přečíst data z víc jak čtyř (nebo dvou) bitplánů. Tak jak je to tedy u AGA řešené? Commodore přidal 2x a 4x fetch mody. Když se zapnou, tak Alice pro Lisu čte v jednom DMA slotu (taktu sběrnice) 4 nebo dokonce 8 bajtů (oproti původním dvěma). Jen díky tomu je možno mít 1280 horizontální rozlišení (nebo chcete-li 640 při 31kHz) v 256 barvách.
A pokud programátor použije menší rozlišení (ve hrách tedy klasický 140nSec pixely), má k dispozici hodně volných DMA slotů (pro Copper, Blitter, CPU). Zatím to tedy vypadá všechno nádherně. Problém je v omezeních. Tím menším (ale pro začínajícího programátora asi překvapivým) je, že tento 32-bit a 64-bit přístup má skutečně jen Alice. Takže CPU a Copper nemá možnost nakrmit Lisu v jednom taktu čtyřmi bajty. Ale nevadí. Horší je, že adresa začátku každého řádku v bitplanes musí být zarovnána na 4 nebo 8 bajtů (v případě 2x nebo 4x fetch). A to už začíná být poněkud otravné. Ale dá se s tím žít, i když to může v některých případech zbytečně plýtvat Chip-RAM. Ale horší to je pokud by programátor chtěl použít 4x fetch mode a současně chce použít hardwarovou podporu horizontálního scrollu. V tom případě musí zajistit, aby se prvních osm bajtů ze všech bitplánů načetlo dostatečně s předstihem vpravo na řádku (než se pixely začnou zobrazovat). Jenomže takové včasné načtení se bohužel překrývá s fixně danými sloty pro načítání sprajtů! Co to znamená? Pokud chceme mít hw horizontální scroll pro screeny širší než 256 pixelů a využít 4x fetch mode (protože to je to největší zrychlení AGA), tak musíme oželet téměř všechny sprajty (myslím, že tak jeden dva nám zbudou). Dá se to vyřešit tím, že si hra vystačí jen s užší obrazovkou nebo použijeme Copper k načítání dat potřebných sprajtů. Není to neřešitelné, ale je to prostě pruda.
No a pak tu máme barvy. Je jich 256. Jenomže jak dostat toto množství do palety, která má i u AGA jen 32 položek? Commodore to vyřešil tak, že existuje osm palet, které se přepínají zápisem do registru BPLCON3. Bohužel tím to nekončí, protože AGA má osm bitů u R, G a B odstínů ("true-color"). Jenomže barevné registry mají jen 4 bity na barevnou složku. Takže nastavením bitu LOCT v BPLCON3 se přepíná, jestli ty čtyří bity jsou horní nebo dolní. Přičemž kvůli zpětné kompatibilitě se musejí nejdřív nastavovat ty horní. Opět se s tím vším dá žít, ale je to pruda.
Copper se u AGA nijak nezlepšil. CPU sice může po sběrnici číst a zapisovat v jednom taktů až 4 bajty, ale Copper zůstal stejný jako v roce 1985 a umí zapisovat jen 16 bitů v jedné instrukci. Stejný zůstal i Blitter, který se tak stal skoro zbytečným. Umí sice využít (téměř) každý volný DMA slot, ale umí číst a zapisovat jen po 16 bitech. CPU se sice dostane ke sběrnici jen v každém druhém taktu (když je volná), ale umí načíst a zapsat rovnou 4 bajty. CPU má ale instrukční cache (a 030+ ji má nejen větší, ale má i datovou) a jeho frekvence se zdvojnásobila, takže na jeden takt sběrnice má své čtyři vlastní. Když se k tomu přidá zlepšené provádění aritmetických a logických operací (např. bit-shift má konstantní počet taktů bez ohledu na délku posunu) a Fast-RAM, tak byl Blitter už v podstatě zbytečný.
Sprajty se na AGA zlepšily jen díky fetch modu. Tak jako Alice krmí Lisu až čtyřmi nebo osmi bajty v jednom taktu z bitplanes, je schopná předat Lise i více dat sprajtů v jednom taktu. A tak se nám šířka sprajtu zvětšila na 32 nebo 64 pixelů (2x nebo 4x fetch). Ale to je vše. Barevná hloubla zůstala, protože stále máme jen SPRxDATA a SPRxDATB registry -- takže tři barvy (nebo sedm při spřažení). Jo a sprajty se tentokrát dají kreslít i na okrajích obrazu. U OCS je Denisa kreslila jen když generovala obraz z bitplanes. No jupííí.
Takže si to shrňme: Sprajty se v roce 1992 sice rozšíříly na 64 pixelů, ale jejich počet a barevnost zůstala. Při tom ale Blitter byl stále stejně rychlý (nebo spíše pomalý)- Přístup k bitplanes se sice o něco zrychlil (bylo víc volných DMA slotů + CPU mělo 32-bit přístup), ale objem dat se zvýšil až dvojnásobně (osm bitplánů). A to v době, kdy se hráči už běžně dívali na hry na SNESu, Sega Megadrive nebo PC Engine (nemluvě o Arcade strojích)...
Ještě tu bylo logické rozšíření dual-playfield a HAM modu (ten první měl 4+4 bitplanes, ten druhý měl víc bitů na modifikování barevné složky a větší základní paletu). 15 barev pro jednu nezávislou vrstvu ze dvou? Jako je to fajn, ale nic moc převratného. Aspoň že ten HAM8 mod umožňoval hezké "true-color" chunky2planar mody, tak často vídané v demáčích. Ale to zase vyžadovalo rychlejší procesor, aby to bylo k užitku a v běžných hrách to asi k vidění nebylo (mimo 3D).
Nějak mne už nenapadá víc vylepšení, které přineslo AGA pro běžného programátora, který chtěl dělat hry nebo si prostě chtěl hrát s grafikou. Tohle byla vylepšení, která Commodoru trvala 7 let.
Ale klidně mne vyveďte z omylu. Diskuzi o výhodách/nevýhodách AGA se vůbec nebráním.
Ještě bych dodal, že OCS je stále zajímavé pro svou nostalgickou hodnotu, pro své (ve své době) skvělé navržení a určitou revolučnost. AGA se naproti tomu jeví spíše jako takový rychlý "hack". A další výhodou OCS je v současné době skvělá cycle-exact emulace (emulují se i chyby). U AGA to myslím stále neplatí.
Amigu 1200 patřičně dovybavenou nějakou rozumnou turbokartou (B1230?) doteď považuju za to nejlepší, co si člověk může pro ukojení své nostalgie pořídit.
Ale smutným faktem je, že AGA byla hodně velká bída.
Z pohledu programátora přinesla jen tři věci navíc: 1. Větší počet bitplanes (osm), 2. Lepší podpora 35 nSec pixelů (rozlišení), 3. 4x data fetch mode. To první a druhé bylo nutností, pokud Commodore chtěl aspoň trochu zlepšit konkurenceschopnost Amigy proti VGA (SVGA) PC kartám (a dalším počítačům jako byl Mac, Atari Falcon, ...). A to třetí byla nutnost, protože Commodore nezrychlil Chip-RAM sběrnici. Proč tak neučinil netuším. Nejspíš kvůli ceně a zpětné kompatibilitě? Samozřejmě A1200 těch vylepšení přinesla o něco víc (68020, expansion slot, PCMCIA, IDE, ...), ale co se týče on-board grafiky, tak to byla bída.
Zvětšení počtu bitplanes je jistě skvělá věc. Jenomže sběrnice zůstala stejně pomalá, jako u OCS z roku 1985. Na šestnáct vygenerovaných low-res pixelů stále existuje jen osm DMA slotů. Takže udělat fetch všech osmi bitplanes sebere všechny DMA sloty a tak se, když se generuje obraz, nikdo do Chip-RAM (a ke custom chip registrům) nedostane. Copper, Blitter, CPU - nikdo. A pokud by chtěl programátor použít 72nSec nebo 35nSec rozlišení (640, 1280), tak prostě není možno přečíst data z víc jak čtyř (nebo dvou) bitplánů. Tak jak je to tedy u AGA řešené? Commodore přidal 2x a 4x fetch mody. Když se zapnou, tak Alice pro Lisu čte v jednom DMA slotu (taktu sběrnice) 4 nebo dokonce 8 bajtů (oproti původním dvěma). Jen díky tomu je možno mít 1280 horizontální rozlišení (nebo chcete-li 640 při 31kHz) v 256 barvách.
A pokud programátor použije menší rozlišení (ve hrách tedy klasický 140nSec pixely), má k dispozici hodně volných DMA slotů (pro Copper, Blitter, CPU). Zatím to tedy vypadá všechno nádherně. Problém je v omezeních. Tím menším (ale pro začínajícího programátora asi překvapivým) je, že tento 32-bit a 64-bit přístup má skutečně jen Alice. Takže CPU a Copper nemá možnost nakrmit Lisu v jednom taktu čtyřmi bajty. Ale nevadí. Horší je, že adresa začátku každého řádku v bitplanes musí být zarovnána na 4 nebo 8 bajtů (v případě 2x nebo 4x fetch). A to už začíná být poněkud otravné. Ale dá se s tím žít, i když to může v některých případech zbytečně plýtvat Chip-RAM. Ale horší to je pokud by programátor chtěl použít 4x fetch mode a současně chce použít hardwarovou podporu horizontálního scrollu. V tom případě musí zajistit, aby se prvních osm bajtů ze všech bitplánů načetlo dostatečně s předstihem vpravo na řádku (než se pixely začnou zobrazovat). Jenomže takové včasné načtení se bohužel překrývá s fixně danými sloty pro načítání sprajtů! Co to znamená? Pokud chceme mít hw horizontální scroll pro screeny širší než 256 pixelů a využít 4x fetch mode (protože to je to největší zrychlení AGA), tak musíme oželet téměř všechny sprajty (myslím, že tak jeden dva nám zbudou). Dá se to vyřešit tím, že si hra vystačí jen s užší obrazovkou nebo použijeme Copper k načítání dat potřebných sprajtů. Není to neřešitelné, ale je to prostě pruda.
No a pak tu máme barvy. Je jich 256. Jenomže jak dostat toto množství do palety, která má i u AGA jen 32 položek? Commodore to vyřešil tak, že existuje osm palet, které se přepínají zápisem do registru BPLCON3. Bohužel tím to nekončí, protože AGA má osm bitů u R, G a B odstínů ("true-color"). Jenomže barevné registry mají jen 4 bity na barevnou složku. Takže nastavením bitu LOCT v BPLCON3 se přepíná, jestli ty čtyří bity jsou horní nebo dolní. Přičemž kvůli zpětné kompatibilitě se musejí nejdřív nastavovat ty horní. Opět se s tím vším dá žít, ale je to pruda.
Copper se u AGA nijak nezlepšil. CPU sice může po sběrnici číst a zapisovat v jednom taktů až 4 bajty, ale Copper zůstal stejný jako v roce 1985 a umí zapisovat jen 16 bitů v jedné instrukci. Stejný zůstal i Blitter, který se tak stal skoro zbytečným. Umí sice využít (téměř) každý volný DMA slot, ale umí číst a zapisovat jen po 16 bitech. CPU se sice dostane ke sběrnici jen v každém druhém taktu (když je volná), ale umí načíst a zapsat rovnou 4 bajty. CPU má ale instrukční cache (a 030+ ji má nejen větší, ale má i datovou) a jeho frekvence se zdvojnásobila, takže na jeden takt sběrnice má své čtyři vlastní. Když se k tomu přidá zlepšené provádění aritmetických a logických operací (např. bit-shift má konstantní počet taktů bez ohledu na délku posunu) a Fast-RAM, tak byl Blitter už v podstatě zbytečný.
Sprajty se na AGA zlepšily jen díky fetch modu. Tak jako Alice krmí Lisu až čtyřmi nebo osmi bajty v jednom taktu z bitplanes, je schopná předat Lise i více dat sprajtů v jednom taktu. A tak se nám šířka sprajtu zvětšila na 32 nebo 64 pixelů (2x nebo 4x fetch). Ale to je vše. Barevná hloubla zůstala, protože stále máme jen SPRxDATA a SPRxDATB registry -- takže tři barvy (nebo sedm při spřažení). Jo a sprajty se tentokrát dají kreslít i na okrajích obrazu. U OCS je Denisa kreslila jen když generovala obraz z bitplanes. No jupííí.
Takže si to shrňme: Sprajty se v roce 1992 sice rozšíříly na 64 pixelů, ale jejich počet a barevnost zůstala. Při tom ale Blitter byl stále stejně rychlý (nebo spíše pomalý)- Přístup k bitplanes se sice o něco zrychlil (bylo víc volných DMA slotů + CPU mělo 32-bit přístup), ale objem dat se zvýšil až dvojnásobně (osm bitplánů). A to v době, kdy se hráči už běžně dívali na hry na SNESu, Sega Megadrive nebo PC Engine (nemluvě o Arcade strojích)...
Ještě tu bylo logické rozšíření dual-playfield a HAM modu (ten první měl 4+4 bitplanes, ten druhý měl víc bitů na modifikování barevné složky a větší základní paletu). 15 barev pro jednu nezávislou vrstvu ze dvou? Jako je to fajn, ale nic moc převratného. Aspoň že ten HAM8 mod umožňoval hezké "true-color" chunky2planar mody, tak často vídané v demáčích. Ale to zase vyžadovalo rychlejší procesor, aby to bylo k užitku a v běžných hrách to asi k vidění nebylo (mimo 3D).
Nějak mne už nenapadá víc vylepšení, které přineslo AGA pro běžného programátora, který chtěl dělat hry nebo si prostě chtěl hrát s grafikou. Tohle byla vylepšení, která Commodoru trvala 7 let.
Ale klidně mne vyveďte z omylu. Diskuzi o výhodách/nevýhodách AGA se vůbec nebráním.
Ještě bych dodal, že OCS je stále zajímavé pro svou nostalgickou hodnotu, pro své (ve své době) skvělé navržení a určitou revolučnost. AGA se naproti tomu jeví spíše jako takový rychlý "hack". A další výhodou OCS je v současné době skvělá cycle-exact emulace (emulují se i chyby). U AGA to myslím stále neplatí.
Fakt ovšem je, že Intel je poněkud větší firma a dočasné technologické zaostávání ustojí s větší pravděpodobností.
Komentovat