Cart oczywiscie zawiera mikrokontroler. Jest to 16-bitowy PIC24 produkcji Microchipa. Wydajnosc 40MIPS, 8KB RAM, 128KB flash. Od razu powiem, ze poczatkwo wybralem ten model jedynie do zrobienia prototypu proof-of-concept, a docelowo chcialem uzyc drozszego i mocniejszego procka. Ale niespodziewanie okazalo sie, ze ten tez bedzie calkiem uzyteczny a przy tym jest tak tani ze mozna go bedzie uzyc do wydawania konkretnych gier. Ale o tym pozniej.
Na cartridgu znajduja sie 4 chipy: PIC, 7400, 2x konwerter napiecia 3V3<->5V. Do tego kilka elementow dyskretnych i to wszystko.
Koszt elementow <30zl.
Koprocesor na cartridgu byl moja idee fix od wielu lat. Jest to latwe, ale problemem byla zawsze wymiana danych z Atari. Bo cart jak wiadomo nie moze zhaltowac 6502 i Antica zeby uzyskac dostep do RAM'u Atari. Byly znane co najmniej 3 rozwiazania tego problemu:
1. Zwykla pamiec 8KB wpieta w obszar $A000-$BFFF ktorej szyny danych i adresowa sa wahadlowo zamieniane miedzy Atari a koprocesorem. To zastosowal Zenon i Konop w Weronice, ale elektronika potrzebna do tego jest dosc spora.
2. Pamiec dual-port. Z tym eksperymentowal Seban, ale ta pamiec jest trudno dostepna i droga.
3. Moj stary pomysl: na tyle szybki koprocesor zeby zdolal dekodowac adresy i podstawic dla Atari odpowiednie dane, niejako symulujac dla Atrai zwykla pamiec wlaczona w obszar cartridga, a w tle wykonujac zlecone obliczenia.
Ale tydzien po Glucholazach mialem nagle olsnienie i wymyslilem czwarty sposob :) Zrezygnowalem z dekodowania adresow. Bo wymyslilem jak zrobic to wszystko co pokazalem w demie i co opisal XXL, bez podlaczania do koprocesora szyny adresowej. I to jest (mowiac nieskromnie) jedyny przeblysk geniuszu jaki mialem :)
Tak wiec Atari komunikuje sie z cartem TOMEK-8 wylacznie przez strone $D5xx. I teraz najwazniejsze: koprocesor nie ma pojecia gdzie na tej stronie zapisuje/czyta Atari. A mimo to jest w stanie realizowac rozkazy. O ile tylko programista po stronie Atari bedzie sie trzymal protokolu.
A jest to prosty protokol. Np mnozenie realizuje sie tak:
lda #$40 ;rozkaz mnozenia
sta $D500
lda mnozna
sta $D500
lda mnoznik
sta $D500
lda $D500 ;lsb wyniku
ldy $D500 ;msb wyniku
W przypadku rozkazow, ktorych wykonanie zajmuje wiecej czasu i dane nie moga byc odebrane natychmiast, odczyt ze strony $D5 bedzie zwracal kod wydanego rozkazu dotąd az obliczenia trwaja, a po ich zakonczeniu zwroci 0. Jest to sygnal ze mozna odebrac wyniki (jesli rozkaz zaklada ze jakies wyniki beda zwracane), badz wydac kolejny rozkaz.
Ale jak zauwazyl bezrobotny, nawet przy najlepszym wsparciu, Atari nie zdązyloby narysowac takich efektow. A Jell dobrze napisal, ze koprocesor jest "generatorem zawartosci ramu, czytanym przez antic".
Tyle ze wymyslilem proste i chyba pomyslowe rozwiazanie: pamiec ekranu jest w RAM'ie koprocesora. Ustalamy ilosc linii, szerokosc ekranu, tryb graficzny.
Ustalamy tlo, wydajemy rozkazy przesuwajace obiekty (jak widzieliscie nawet kilkadziesiat duzych duszkow na ramke), a nastepnie, co ramkę, zanim Antic zacznie pobierac dane, wydajemy prosty rozkaz: "generuj dane dla Antica".
Caly myk w tym, ze Display List wyglada tak (dla trybu hi-res):
;display list
dl
dta $70,$70,$70
:192 dta $4F,a($D500)
dta $41,a(dl)
Czyli pamiec kazdej linii wskazuje na strone $D5 :)
Dodatkowy zysk z takiego pomyslu do zyska paru KB pamieci w Atari.
To zmienilo cartridge w karte graficzną z banalnie prostą obslugą ze strony Atari. Napisalem na razie prosty frimeware do trybu hi-res: obsluga "duszkow" o dowolnej wielkosci, rysowanie punktow, linii, pisanie tekstu itp. Tworze dokumentacje. Jak wroce zajme sie trybami kolorowymi.
Ale nic nie stoi na przeszkodzie zeby dopisac np obsluge przeksztalcen 2D i 3D, tekstur i co sobie tylko ktos zamarzy. Tzn na przeszkodzie stoją moje marne umiejetnosci. Ale jesli ktos z doswiadczeniem i umiejetnosciami np tebe albo Konop zechcial stworzyc take rozkazy, to mysle ze Doom na Atari bylby w naszym zasiegu.
Dodam, ze cart developerski pozwalajacy wygodnie tworzyc i debugowac program PIC'a z poziomu PC to koszt okolo 160zl i ja chetnie sfinansuje takie narzedzie dla wyzej wspomnianych albo innego doswiadczonego programisty-scenowca, ktory zechce wziac udzial w stworzeniu takiego uniwersalnego frimeware.
Co do pytan o wydanosc, przyklady:
- narysowanie w wybranym miejscu ekranu (co do piksela) obiektu 64x64 piksele OR tlo (lub XOR, lub AND), to okolo 110 taktow Atari,
- narysowanie linii o dlugosci 100 punktow (bresenhamem) to 63 takty Atari,
- przepisanie tla 320x192 punkty to okolo 175 taktow. (tebe miales racje pytajac czy to bity czy bajty, a xxl odpowiedzial blednie. Ten rozkaz nie ma precyzji bitowej tylko 2-bajtową, tzn wykorzystuje to ze koprocesor jest 16-bitowy i dlatego tak to zasuwa)
Czyli jest szybko. Bardzo szybko. A pamietajcie ze ze mnie jest programista dosc mizerny a to byl dla mnie kompletnie nowy asembler, ktorego ucze sie od miesiaca. Mysle ze np rysowanie duszkow spokojnie mogloby byc o 30% szybsze gdyby pisal to np Konop :)
Co jeszcze?
Wspracie dla grafiki jest imho najwazniejsze, ale mozna dopisac do frimeware kalkulator dla liczb rzeczywistych, mozna wsparcie dla obliczen macierzowych, mozna player do muzyki, nie ma ograniczen.
Zrobilem kilka ciekawych eksperymentow. Np cartridge jest na tyle szybki ze jest w stanie wystawic kod dla Atari na strone $D5xx. Do czego to wykorzysac? Mam kilka ciekawych pomyslow na przyszlosc...
Albo zrobilem taki eksperyment: ustawilem DL tryb tekstowy $02 gdzie kazda linia wskazuje na $D500. Jednoczesnie ustawilem adres generatora znakow (CHBAS) na adres $D400. I cartridge generowal dla Antica jednoczesnie dane obrazu w trybie tekstowym jak i dane znakow (od 32 do 63).
Mam tez pomysl jak napisac wsparcie dla odtwarzania muzyki.
No i pomysl sprzed paru dni. Jestem prawie pewny ze bede mogl bootowac Atari z tego cartridga bez pamieci EPROM.
Zalaczam fotke obecnego protorypu. Elementy do zlozenia kolejnych, bardziej przypominajacych cart bede mial niestety dopiero za 2 tygodnie. Jesli dotre na party do Warszawy do oczywiscie przywioze i zademonstruję.