Witam,
Z Akiko sprawa jest dosc trudna, ale i ciekawa - z wielu wzgledow. Informacji na jej temat jest malo, z racji tego ze C= padlo dosc szybko po pojawieniu sie CD32 a scena niezbyt zainteresowala sie konsola. Tak samo bylo z tworcami gier - woleli robic wersje AGA, ktore to mieli szanse sprzedawac wiekszej ilosci uzytkownikow (1200+CD32). Do wersji konsolowej dodawano zwykle wiecej animacji/muzyki, ale to samo mozna bylo osciagnac na zwyklej A1200+CD. Tylko nieliczne tytuly powstaly wylacznie z mysla o CD32.
Teraz o Akiko/CD32:
1. CD32 jest deko okrojona A1200 (bo nie ma klawiatury, stacji, portow IO, itd) a deko rozszerzona (bo ma CD, Kick3.1 z dodatkowymi procedurami dla niej i wlasnie Akiko).
2. Akiko jest z tego co wiem ukladem logicznym, wiec nie procesorem, ale ma wpisany w strukture "cos jakby program" do realizacji pewnych funkcji, w tym ten slawny Chunky-2-Planar (c2p) o czym za chwile. Kosc ta podobno bierze tez udzial w transferze danych z CD do pamieci - jesli to prawda, bylaby wiec czyms podobnym do DMA.
3. Pod wzgledem graficznym A1200 z AGA jest ubozsza od CD32 wlasnie o mozliwosci ktore daje Akiko (c2p). Miedzy graficznymi mozliwosciami 1200 a CD32 nie ma w praktyce jakiejs przepasci - wlasnie dlatego, ze Akiko byla malo wykorzystywana. Moim zdaniem zdecydowanie wiekszy dystans dzieli kosci AGA i OCS/ECS. Akiko nie zwieksza ilosci kolorow - za kolory odpowiada koprocesor graficzny Copper od poczatku istnienia Amigi.
4. Akiko nie ma wplywu na przyspieszenie pracy procesora w sposob hardwarowy - nie jest dopalaczem, cache, nie zmienia taktowania i nie jest typowmym procesorem takim jak MC680x0. Moze go wspomoc wykonujac szybciej od niego pewnie czasochlonne zadania i do tego zostala stworzona (klopot w tym ze malo kto z tego korzystal).
5a. Czar Akiko - c2p. Chodzi w tym o to, ze od poczatku istnienia, Ami wyswielta obraz w sposob "planarny" czyli calymi plaszczyznami (bit-plane'y), linia po lini, wrzucajac 8 bitow z kazdego bajtu jeden za drugim. Jesli ekran ma szerokosc 320pix, to 1 linia bedzie skladac sie z 40 bajtow po 8 bitow/pixeli. Wrzucamy po kolei na ekran 256 takich linii po 40 bajtow i mamy zapisany caly ekran, tyle ze w max 2 kolorach, bo bit moze byc w jednym kolorze (bit ustawiony na 0) lub w drugim (bit ustawiony na 1). Zeby uzyskac wiecej kolorow - trzeba "poglebic" ilosc wartw (bit-plane'ow) przypadajacych na 1 pixel. Jeden bit-plane (bpl) = 2 kolory, 2bpl = 4 kolory, 3bpl = 8 kol, 4bpl = 16 kol, 5bpl = 32 kol, ..., 8bpl = 256 kolorow. Wszystko fajnie, tylko ze te plaszczyzny leza dosc daleko od siebie w pamieci, wiec zeby ustawic kolor dla 1 punktu trzeba wykonac nie dosc, ze 8 operacji zapisu w rozne miejsca pamieci (powolny ChipRAM), to jeszcze trzeba zapisywac konkretny 1 bit z 8-miu bitow, co w praktyce wiaze sie z niemala procedurka, ktora "kosztuje" spory czas procesora (niezbyt szybkiego jak wiemy). Tak wyglada wyswietlanie obrazu na wszystkoch Amigach. Byl to dobry pomysl, gdy grami glownie byly gry typu platformowki lub strzelanki pionowe lub poziome - calymi bajtami latwo przerzucalo sie duze ilosci ciaglych danych, a dzieki specjalnym rejestrom sprzetowym mozna bylo przescrollowac caly ekran o dowolna ilosc pixeli z przedzialu 0-15, w pione i poziomie. Z nadejsciem ery 3D, teksturowania, oswietlania, itd - zmienilo sie programowanie graficznych obiektow. Wektorowka (3D), na poczatku plaska, byla latwa do zrealizowania (blitter rysowal i wypelnial obszary "dosc szybko"). Cieniowanie jednak i teksturowanie wymaga osobnego potraktowania kazdego punktu z cieniowanej/teksturowanej powierzchni. Obliczenia koloru i swiatla - kosztuja czas. Jesli do tego dodamy dlugi czas na zapisywanie kazdego punktu - mamy klopot. Jak wiemy era 3D rozkwitla na PC z miedzy innymi z tego powodu, ze karta graficzna VGA posiada tryb 13h, 256 kolorowy - zwany wlasnie chunky, w ktorym to 1 pixel kolorowany jest 1 bajtem (8bit), czyli nie ma plaszczyzn jak w Ami, ale kazdy punkt jest opisany 8 bitowa glebokoscia w 1 miejscu. Tak wiec zamiast sporej procedury pisania po 8 plaszczyznach i po 8 bitach wsrod 8 bajtow - robimy 1 zapis bajtu w miejsce punktu i po sprawie. Wniosek? Zyskujemy czas na inne zadania a gra zyskuje PREDKOSC. Mamy czas na czasochlonne przeliczanie oswietlenia/tekstury/obiektow 3D, etc.
5b. c2p - to sposob by w buforach pamieci obliczac sobie kolor/teksture "na sposob PC" (najlepiej w FastRAM) a wyswietlac to na Ami (w ChipRAM). Czyli przygotowujemy sobie dana "scenke" obliczajac wszystko "szybko" a potem wyniki tych obliczen konwertujemy ze sposobu wyswietlania PC na wolniejszy Ami (mam nadzieje idea obliczen i przygotowywania dzialan na buforach jest ogolnie znana). Jesli konwersja i zapis c2p jest szybki, to mozemy pisac gry w technikach 3D z oswietleniem, teksturowaniem itd (Wing Commanderm, Microcosm, DOOM, Q123, etc). Na Ami, konwersja c2p odbywala sie programowo, za pomoca bardzo pomyslowych i wysrubowanych procedur (uzywajac samego procka, w 040+ pipeliningu, Coppera, Blittera - pomyslow bylo sporo). Tyle ze nawet te super-optymalizowane procedury byly nadal wolne i zajmowaly czas procesora. I tu pojawia sie Akiko, ktore konwersje c2p robi - sprzetowo i to szybko! Procesor wrzuca opracowane dane chunky a wyciaga ciag bajtow planarnych gotowych do wyswietlenia w graficznych trybach Amigi. I to jest nasz wlasnie happy end - nasze gry chodza szybciej, programisci nie traca czasu na optymalizacje kodu gry i procedur c2p. Szkoda ze AGA w 1200 nie miala sprzetowego c2p - moze sprawy wygladalyby deko inaczej.
5c. Tak to wyglada w zarysie. Jaka jest faktyczna wydajnosc Akiko - tego nie wiem. Za malo materialow, a kodow zrodlowych w ogole nie widzialem, wlasnych eksperymentow _jeszcze_ nie przeprowadzilem - mam nadzieje ze zrobie to niedlugo, jak mi sie uda zdobyc w koncu ProMod'a
6. Oczywiscie mozna pisac gry tak, by wykrywaly obecnosc Akiko i uzywaly sprzetowego c2p, a jesli 1200 - programowego. Wtedy bycmoze 040+ moca procesora mogloby nadrabiac brak Akiko. Pozostaj kwestie obslugi CD bez procedur Kickstartu CD32 (chyba proste do obejscia) i czytania pod'a (tu juz kwestia zaprojektowania gry).
7. Moim zdaniem jesli chodzi o wyswietlanie filmow czy animiacji, konwerter c2p nie ma chyba znaczenia. Tutaj pomocna wydaje sie czesc Akiko odpowiedzialna za transfer danych z CD do pamieci obrazu. Raczej animacje/filmy na CD zapisywane byly w planarnym formacie, a nie chunky.
Mam nadzieje cos wyjasnilem - pozdro. Sachy