... Nosty, bo jak sam wspominasz, jeśli by to miało służyć do muzykowania, czy bardziej użytkowego zastosowania (a wykminiłem milion takowych:) ) to nadało by się, by nie zjadło się to ze Spartą. Dlatego tak bardzo męczę w temacie $D5 ;)-

Co do kompatybilnosci ze Spartą i innymi rozszerzeniami wykorzystujacymi strone $D5:

W sumie nie potrzebuje calej strony. Minimalna ilosc jaką muszę miec to 1/4 strony (Antic musi skads czytac kolejne bajty pamieci obrazu linii: od 32 do 48 bajtow). Ale to mocno ograniczy niektore funkcje.

Gdybym mogl wykorzystac pol strony $D5 to juz bylbym zadowolony. Dlaczego?
Bo pierwszy opis cartridga troszke uproscilem :) Tak naprawde PIC dekoduje mi sprzetowo 2 linie adresowe, ktore podlaczylem pod adresy A6 i A7 Atari. Czyli mowiac inaczej cartride wie do ktorej cwiartki strony $D5 Atari sie odwoluje. A to mozna wykorzystac na wiele fajnych sposobow. np do jednej cwiartki bedzie czytal/pisal procesor a na druga ustawimy pamiec ekranu, czyli bedzie do niej siegal tylko Antic. To pozwoli cartridgowi jednoczesnie obslugiwac rozkazy otrzymywane od procesora i niezaleznie generowac w tym samym czasie dane obrazu dla Antica.

Takze najlepiej byloby gdybym mial cala strone "dla siebie", ale jesli rezygnacja z polowy strony $D5 spowoduje ze cart bedzie kompatybilny ze Spartą, to to chyba dobry pomysl.

PS. Fajnie by bylo napisac wsparcie graficze dla tego projektu :) http://www.atariage.com/forums/topic/15 … __st__1800
Ale to chyba wlasnie przyklad frimewaru, ktory musialby byc szyty "na miare".

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

ograniczenia 8KB nie zabija szczytnej ideii a pomysł z czyszczeniem PICa i operacjach na flashu/ modyfikowanie firmwaru to może i nieelegancke ale bardzo elastyczne rozwiązanie, to musi być proste i tanie jak barszcz a wtedy znajdą się chętni by z tego korzystać, podstawowy firmware załóżmy że obsluguje tylko wątki i zarzadzanie pamięcią.. kopiowanie bloków danych/nakladanie spritów (wtedy zależnie od zamiarów programisty można tam pakować czy to player czy silnik 3d, zostawiac przestrzen pod sparte, co kto woli) ale najwazniejsze co tam musi być to odpowiednia obsluga komunikacjii Cart-Atari bo jesli to będzie projekt otwarty a wg przeznaczenia carta przerwanie dl Antica defacto jest wykonywane co każdą linie, zastanawia mnie co się stanie jak PIC nie bedzie się wyrabiał z generowaniem danych co linie(mimo duzej szybkosci teoretycznie to możliwe), powiedzmy, ze na karcie oprócz prostych procedur znajdą się proc. obróbki tekstur lub dekompresjii, które wymagają różnych czasów, jedynym sygnałem synchronizacji jest zwrot kodu wydanego rozkazu, tak ?, Cart i Atari komunikując się bezmyślnie, bez kontroli ze strony programisty moze wywalać po prostu kaszkę nawet jesli na przerwaniu DL będzie informacja, że danych jeszcze nie ma to Antic i tak bedzie musiał przejsc do rysowania kolejnej lini.

Tak więc co znajdzie się we flashu i co antic bedzie robił z danymi to już broszka programisty a firmware carta niech tylko zarządza wątkami, pamięcią, komunikacją (kontolą obciążenia mikrokontrolera) lub np emulacją 6502 i przechwytywaniem kodu. Wtedy nawet taki core mozna pisać pod różne kontrolery i bedzie stanowił przyszłościowe rozwiązanie nie tylko pod kątem gier a w cartridge bedzie można wpychać różne procki .....no ale to na razie teoria....

nosty: jako zbieracz cartow - wolalbys cart per gra. ja, jako enduser - wolalbym jeden mocniejszy, z ladowana (spod sparty ;) ) zawartoscia.
mysl intensywniej nad tym mocniejszym cartem.

ps. skoro wykorzystujesz tylko 3 linie do dekodowania adresu (rd5, a6, a7) to dolozenie przed nie jednego malego xilinxa (9536) za niecale 8pln od sztuki (przy wiecej niz 25szt. wychodzi mniej niz 5.5o pln od sztuki) - zapewni ci jeszcze prostrze dekodowanie, z mozliwoscia rozdzielenia przestrzeni adresowej pod antica, odrebnego rejestru pod funkcje koproca, co tam jeszcze bys chcial.
co wiecej - cart zajmowalby wtedy cwiartke d5, z mozliwoscia wyboru skad ma sie zaczynac, co do paragrafu (a wiec programowo by sie dalo pogodzic pewnie z niemal kazdym rozszerzeniem).

bo VBXE jest ale nie ma produkcji na to.
Jak by na łamach naszej gazety co ma być, zrobić kurs programowania z uzyciem VBXE to moze by przyciągneło chętnych do nauki i jakichś produkcji.

Przy obecnym kursie dolara to daje jakiej 550-560 PLN. Sorki ale moje VBXE kosztowalo cos 50-60% tej ceny. Poza tym to USA nie EU - zapomniales o cle.

A moze kurs czytania i pisania? :) Jest dokumentacja. Nawet ja zrozumialem :) Chociaz ja wiem ze z egzamplami jest przyjemniej.

panowie - przeniescie dywagacje o vbxe do innego watka. raz juz o to proszono.

Przepraszam, ale jeszcze tylko dodam coś o vbxe i znikam (szukajcie u Heisenberga).

Mylicie tu rzeczy na poziomie podstawowym. VBXE to zupełnie i absolutnie coś innego niż taki cart i o ile na vbxe można zrobić to samo co na tym carcie to odwrotnie już nie za bardzo. A narzekania o tym, że nie ma produkcji i / lub nie wiadomo jak to programować mogę skwitować tylko pobłażliwym uśmiechem : jak już Wieczor napisał : kurs czytania i pisania by się przydał, bo jedyne czego zabrakło to chęci - ja ze swojej strony zrobiłem wiele - example i pełną dokumentację każdy może sobie pobrać. Kilka osób zresztą udowodniło, że da się.

Nosty: kart jest fajny jako dedykowany do gier na std. konfig i rób dalej swoje, tylko rzeczywiście uważaj na tę stronę D5, żeby nie było konfliktów z np. spartą. No i więcej ram by się przydało w środku.

I ostatnie: wkrótce premiera nowych rdzeni dla vbxe - poprawki emulacyjne i PAL BLENDING - słyszysz PIN ?

electron to nie temat VBXE jak już wspomniano, z całym szacunem ale problem rozpowszechnienia VBXE to nie problem dokumentacji, dostępności czy ceny tylko sensu wkladania silnika ferrari do malucha, zakladania mu spoilera i robienia z niego ferrari stawiając na równi z możliwosciami gfx 16bitowcow. Maluch niech pozostanie tym czym bym w zamyśle konstruktorów w erze świetności 8-bit, cart nostego daje feeling lat 80tych i osobiscie uwazam geniusz pomyslu w prostocie i cenie wykonania. Kiedyś tandemy typu ramcharger, atr8000, AF, Bit3 i inne antyczne wynalazki poległy bo totalnie mijały się z tą powszechną ideą oraz ceną a tu zamawiasz carta za 30-40 PLN i mozesz korzystac z okienek, namiastki multitaskingu czy gier 3d na 100% real hardware, istotna jest możliwość podmiany procka i upgradu firmware, pozostawienie otwartej architektury pod wiele opcji imho bardziej szedłbym w prostote i interdyscyplinarnosć tego rozwiązania niz kolejnej drogiej dopałki lub karty gfx, ważne by był tani,prosto opisany jak VBXE a znajdą się na pewno chętni do stworzenia na niego programowania

VBXE to super sprawa tylko ideowo chybione dlatego pozostanie egzotyką bo na upartego mozna w cartridge umiescic też to:

http://dmitry.co/index.php?p=./04.Thoug … 0on%208bit

tylko po to by potwierdzić, że to możliwe. TOMEK-8 musi być tani i prosty by trafił do mas i tego należy się trzymać, dzieki takim wytycznym popularność zdobyly rozwiazania typu COVOX w latach 80tych

Ostatnio edytowany przez cougar (2012-09-04 10:34:11)

@nosty: "Wymyslilem sobie,  ze ten cart bedzie sluzyl do wydawania gier, a nie bedzie "niezaleznym" rozszerzeniem z 4 powodow:(...)"
Mi jako enduserowi ta idea _bardzo_ się podoba :-)

takie rozwiązanie zmniejszy ilość oprogramowania wynalazku o 95% ;)-

Ależ Pin, sądzę, że ilość oprogramowania i tak będzie niska, a poza tym ograniczenia sprzętu carta wskazują raczej na konieczność dostosowania gry do carta i vice versa a więc tym bardziej gra plus cart będą sobie dedykowane. Na dodatek forma CART jakby z domysłu pozwala na przenoszenie kompletu gra + sprzęt do jej odpalenia i to jest całkiem fajne. Poza tym powiązanie carta (przy jego względnie niskiej cenie) z grą tworzy zamkniętą całość, nie podlegającą apdejtom i nie tracącą na aktualności np. tak jak co niektórzy zarzucają vbxe "bo on ciągle coś zmienia w rdzeniu".