Przepraszam, że się wtrącam - lecz udostępnienie tego wynalazku wyłącznie w zestawie z grą jest bezsensu.

Na litość boską - udostępnijcie także karta wyłącznie z "akceleratorem", oraz szczegółowym opisem programowania tego wynalazku. Jeśli układ jest tani, nieskomplikowany, nie wymaga grzebania w bebechach kompa i działa to nic nie stoi na przeszkodzie, by używać urządzenia nie tylko w grach!

Jellonek: Jak zwal tak zwal, chodzi mi o to co funkcjonalnie jest rozszerzane, powiedzmy ze wyrecza to Antica (mi sie 256 zestaw znakow podoba) , tak jak VBXE wyrecza GTIA (a w zasadzie to po czesci Antica tez). Ja w kazdym razie nie widze pomiedzy nimi konfliktu a widze jak moga sie pieknie uzupelnic

O ile wiem gosc ktory to robi w USA ma jakies problemy i wstrzymal wszystkie projekty. Wiec na obecna chwile jest to prawda.

Tu 100% racji. Tylko kto ma to pisać skoro obecnie mamy w zasadzie dwa 'obozy' - hardware designers vs konsumenci hardware ktorzy kupia nawet gola plytke 'BO JEST' To nie sprzyja rozwojowi ;) Poza tym tutaj na AA jest moze 10 osob kompententych na tyle aby cokolwiek napisac na nowy sprzet :) Mortal Kombata z grzecznosci nie wypomne :)

Moze, ale nie musi. Vide spartados x. Najbardziej technologicznie dojrzaly dos na atari a ludzie raczej go nie lubia. (to nie flejm, uzytkownikow SDX w stosunku do innych dosow/loaderow jest moze 5% wg moich luznych rachunkow) Ale owszem, potencjal jest :)

w 100% sprzetowy - tryb antica. zwykly tryb tekstowy antica z zestawem 256 znakow + 1 lub 2 bitami atrybutow (tak, moze byc tez tryb tesktowy 1 lub 2 basica ale nie wiem czy bedzie obslugiwany).

---
> A koszty beda wsciekle

nie chce sie wypowiadac na temat kosztow produkcji takiego karta ale chcialbym uspokoic - sam nie wierzylem - koszt jest bardzo, bardzo niski...

dlaczego z gra: mam nadzieje Nosty nie porzuci swojego projektu i zgromadzi wokol niego kilku programistow, na wielu platformach powstawaly dopaly tylko pod okreslona gre (na karcie zreszta) na atari tez; mam nadzieje tym razem tez tak bedzie. ja oczywiscie bede wspieral pomysl nostego; ale spokojnie, znajac zycie wkrotce pojawi sie ktos kto powie ze potrafi to zrobic lepiej/szybciej i w jednej warstwie szczuplejsze ;-) zerujac na pomysle pewnie bedzie sprzedawal wersje stad alone ;-)

---
> Nie wiem jak sie TOMEK-8 programuje,

duszki tak:
ldx #x_duszka
ldy #y_duszka
lda #numer_duszka
jsr _ustaw duszka na ekranie

nie wspomnialem ze sa oczywiscie priorytety duszkow, sa tez metody generowania duszka od tych z maska AND/ORA ale moze byc tez samo ORA albo tylko EOR, duszki moga wychodzi c za ekran lub "zawijac"
:D

---
co do kompatybilnosci ze Sparta. TOMEK-8 zajmuje cala strone $D5 a wiec to samo miejsce co Sparta (chyba, ze jest wersja Sparty, ktora ma swoje rejestry gdzie indziej)

Ostatnio edytowany przez xxl (2012-09-03 17:59:57)

i've made my bid on ATmega644

nie. ja mowie o trybie tekstowym antica a nie trybie graficznym Antic $0e

na vbxe niestety nie mozna tego zrobic (z obecnym rdzeniem), kilka razy trolowalem Electrona o taka mozliwosc niestety nie udalo sie uprosic.

ale po co faszerowac dl antica danymi przykrytymi bankiem carta, czasowo to sie nie wyrobi skoro wyjscie s-video moze byc na cartridge i wyciagac dane z bankow atarki tak samo wyjscie z atarki do carta i mix z generowanym, rozwiazanie tansze i szybsze imho

Ostatnio edytowany przez cougar (2012-09-03 22:24:18)

kurcze, ale zamieszalem... :)
juz jestem i zaraz opisze wiecej i dokladniej i wyjasnie domysly
dajcie mi 30 min na napisanie posta

Ponawiam pytanie z #34 ;)-

Nie wiem nie znam się, lecz pytanie mam takie, czy gdy jeśli rejestry SDX zajmują (jak mi się wydaje) kilka bajtów z końcówki strony $d5, to jaki wpływ na SDX będzie miał zapis / odczyt danych z pozostałej części strony?

Pytam dlatego, że pomysł jest idealny jeśli chodzi o wykorzystanie nie tylko w grach i szkoda by było takiej możliwości zmarnować.

Minęła godzina. Ludzie nie śpio i czekajo.

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ę.

Ostatnio edytowany przez nosty (2012-09-04 00:35:46)

Jak w NES :)