> czyli dodatkowy procesor pisze do pamięci, kiedy jest ona niewidoczna dla Antica, po czym staje się widoczna, ale wtedy procesor nie może do niej pisać. Synchronizacja tego pewnie będzie spoczywać na głównym 6502 atarki, który będzie dodatkowego proca haltował i uruchamiał stosownie do potrzeb. Stwierdzenie, kiedy pamięć jest widoczna dla Antica a kiedy nie, spocznie na jego programie? Bo jakoś nie widzę jak to można zrobić sprzętowo. Czyli dodatkowy procek będzie działał od złapanego stanu VCOUNT sygnalizującego początek dolnej ramki do stanu sygnalizującego koniec górnej ramki?

z opisu wynika ze dodatkowy proc nie bedzie sie musial z niczym synchronizowac, nie bedzie musial byc tez haltowany i nie bedzie musial pracowac 'na wygaszeniu pionowym'. po prostu bedzie lecial z maksymalana predkoscia a jak sobie poradzi w jednej ramce z obrobka danych (przelaczana pamiec danych ma inne adresu od pamieci programu dodatkowego proca) to nawet najbardziej wymyslne efekty zawsze beda trzymac 50fpsow.

Idee WARPów i dopalaczy na kartach są ortogonalne i mogą sobie nie przeszkadzać, więc nie ma co się kłócić.

@macgyver: No właśnie ale jakie procesory? AVRy itp odpadają, bo to mikrokontrolery, inne nowoczesne wynalazki są mało atarowskie (zainstalować na karcie intela bym się nie odważył). To może jakiś core jakiegoś procesora zmieściłby się do CPLD? na górze pisałem o 65GZ032, ale nie wiadomo w jakim to jest stanie, ale jąder 6502 na opencores.org jest sporo...

Czemu nie intelowskie? IMHO jak już coś ładować, to niech to da potencjalnym programistom, którzy będą pod to tworzyć sensowne możliwości, choćby zaimplementowane komendy mnożenia i dzielenia.

W wypadku zastępowania 6502 przez 65816 (rozwiązania ala WARP, F7) musimy mieć 99,9% kompatybilności z 6502, aby stare programy mogły działać, natomiast nowy soft będzie wykorzystywał dodatkowe funkcjonalności. W wypadku "dopały cartridgeowej" możemy zastosować praktycznie dowolną architekturę, najlepiej coś, co będzie "ogólnodostępne" i jednocześnie będzie dawać programistom spore możliwości (to w końcu programiści będą tworzyć soft, który będzie wykorzystywał możliwości tego sprzętu).

A jeżeli już wrzucać core, to może np. MC 680x0 ? Zapytajcie koderów od dużego Atari/Amig, to jest świetna architektura dla programistów - 15 rejestrów ogólnego przeznaczenia o szerokości 32-bit, mnożenie, dzielenie... miodność.

A skąd będzie wiedział, kiedy "kończy się" ramka? To mu musi 6502 powiedzieć (albo go jakoś zahaltować). Tak czy owak, ponieważ jednoczesny dostęp dwóch procesorów i Antica do tej samej pamięci nie jest możliwy, jakoś to się będzie musiało synchronizować. Nawet żeby wycyklować całość programu zapuszczonego w karcie, trzeba wiedzieć, kiedy jest początek ramki, a skąd ma to wiedzieć procesor, który jest na zewnątrz komputera?

@laoo: no, pewnie że to jest niesprzeczne. Po prostu wydaje mi się, że taka dopałka będzie raczej praktycznie mało użyteczna, tzn. będzie z tego więcej kłopotu niż pożytku. Bo i do czego to? Do gier tylko i to niewielu typów (np. wektorówkę pewnie by mozna na tym zrobić, ale czy skorzystałby z tego jakiś Bomb Jack?), bo dema wymagającego włożenia dodatkowego karta nikt nie dopuści do ogólnego demo-compo, zresztą pewno na zasadzie ortodoksji pod hasłem "to już nie atari" i "dema tylko na fabryczne komputery" :) a zwykłe programy rzadko potrzebują cokolwiek liczyć.

Czyli, jak mówię, byłoby to urządzenie raczej niezbyt uniwersalne (IMHO).

A i tak mu nie działa ;)

Niech wypowie się zainteresowany, jak było.

Może pisać do tego obszaru pamięci, innego bufora obrazu.

O tym decydować będzie 6502 w synchronizacji z VBL.

Może działać przez prawie całą ramkę, aż do otrzymania sygnału o zmianie bufora ekranu.

Co do halt'owania... Takie samo występuje przy pracy na każdym CPU/buforze pamięci ekranu, aby uniknąć artefaktów wizualnych. Po to stosuje się n-buforowanie, które pozwala na zagospodarowanie sporej części czasu procesora, który byśmy musieli nominalnie przeznaczyć na straty. W przypadku, gdy efekt będzie renderował klatki z częstotiwością wyższą od odświerzania ekranu, nie będzie żadnego problemu. Przy wyższej można skorzystać z n-buforowania. Poza tym, można moc procesora CAR spożytkować na wykonywanie innych czynności niż tylko generacja danych obrazu, także część z tego "straconego" czasu można "odzyskać".

Można oczywiście przerzucać/wyświetlać dane przez kopiowanie. Kosztem obciążenia 6502 i w konsekwencji ryzyka spadku fps'u, możemy skolejkować więcej buforów ekranu w pamięci CAR. Którą metodę wybrać, zależało będzie od charakterystyki czasowej efektu.

Aktualizacja

Chęć zachowania po części "ducha" komputerka. Dochodzi również łatwość pisania programów na dobrze znaną platformę.

Szybkość każdego procesora jest ograniczona :>.  A na poważnie, w prototypie Zenona jest 6502, ponieważ tak jest mu wygodnie - testowane są najpierw warianty podstawowe, komunikacja/synchronizacja. Jak już wspominaliśmy oboje, nie ma sensu zbyt daleko wybiegać w przyszłość i gdybać, dajmy na to, ile konkretnie mocy będzie można w to włożyć, dopóki pierwsze testy nie pokażą sensowności podejścia na ogólnym poziomie.

Nie wiem jak wygląda sprawa z konkretnymi edycjami układów 6502, ale pamiętam, że ktoś kiedyś wspominał o wyższym taktowaniu tego procesora. Chyba drac cytował korespondencję od osoby, która projektowała wtenczas te procesory i chwaliła się, że można osiągnąć częstotliwości taktowania w okolicach ~10 MHz. Nam na początek tyle nie jest potrzebne. Gdzieś na forum powinien być o tym wątek.

816 pasuje tutaj jak ulał.

Ostatnio edytowany przez Marek Konopka (2009-03-12 12:07:49)

Jak już kiedyś pisałem dawniej, kiedy o tym dyskutowaliśmy, nie myślałem o innych zastosowaniach. Zenon w swoim dokumencie również na to kładzie nacisk. Z takiego założenia wychodziłem od samego początku. Dzisiaj dochodzę do wniosku, że możliwości są szersze i można sobie pozwolić na tworzenie gier z większą ilością grafiki, sprite'ów, lepszą muzyką. Procesor na CAR można wykorzystać do generacji buforów audio dla POKEY'a (sampli). To wszystko na razie jest oczywiście teorią, ale skoro sobie gdybamy, to warto o takich zastosowaniach wspomnieć.

Rozumiem, że chętniej widziałbyś bardziej ogólne zastosowania, być może jakiś system operacyjny, dodatkową pamięć, coś na kształt Geos'a, ale czy na pewno to nie jest osiągalne w tej formie, w jakiejś dalszej perspektywie czasowej?

Nic, to po prostu inne podejście. Nie ma sensu już dyskutować o podstawowych różnicach. Dla mnie rozwiązanie z CAR jest bardziej eleganckie i podoba mi się w nim to, że ma szanse większego upowszechnienia się. O projektach F7/Warp tego nie można powiedzieć. Sam cytowałeś liczbę działających egzemplarzy. Dla mnie oczywiste ograniczenia rozwiązania z CAR są do stolerowania. Nawet powiem więcej, podoba mi się to, że istnieją, gdyż stanowią jakiś wyróżnik i tworzą platformę do realizacji nowych, ciekawych pomysłów, wyciśnięcia maksimum z układów "maluszka".

Aktualizacja

Przewidziany jest bootstrap w przestrzeni CAR, pakowany z EPROM'u we fragment przestrzeni adresowej CAR, z kodem obsługującym prosty protokół komunikacyjny, umożliwiający przenoszenie danych/kodu do pamięci CAR pod wyspecyfikowane w protokole lokacje. Jedną z komend będzie egzekucja procedury pod wyspecyfikowanym adresem.

Pierwotna idea jest taka - 2 "banki" po 16K naprzemiennie wpinane w przestrzeń adresową (64k) procka na CAR/6502. Gdzie dokładnie w procku na CAR, to już mniej ważne. Reszta ramu klasycznie w przestrzeni procka. Można to oczywiście rozszerzać, rozważyć 816 z adresowaniem 24-bitowym, w razie powodzeń.

Ostatnio edytowany przez Marek Konopka (2009-03-12 12:19:46)

Przeczytaj o czym wcześniej pisał Laoo, w mojej wypowiedzi padło słowo "core" więc następnym razem przeczytaj coś uważnie kilka razy, zanim rzucisz komentarzem, do kawałka wypowiedzi wyrwanego z kontekstu.

A co "antyczności" 68k jest zdecydowanie bardziej nowoczesną architekturą, niż 6502, więc czemu tu się nie czepiasz? No chyba, że wg. Ciebie firmy Apple, Atari i Commodore zrobiły w swoim czasie krok wstecz przechodząc z procesorów 65xx na rodzinę 68k :P

Ostatnio edytowany przez macgyver (2009-03-12 12:10:49)

Mamy sprite'y. Z tego co widziałem ostatnio na zrzutach z Geos'a, również tam są one zastosowane - http://www.guidebookgallery.org/screenshots/geosc64 . Tutaj widzę raczej inny problem, a mianowicie ograniczenie ilości pamięci na okno (16kB). Ewentualnie byłoby to na styk, chyba, że darujemy sobie buforowanie pamięci ekranu.

Można rozważyć liniową przestrzeń adresową procesora 816 przy 24-bitowej adresacji. Oczywiście należałoby uwzględnić "okno" komunikacyjne. Można podzielić pamięć sprytnie, aby ta powyżej okna, przy jego odpowiednio niskiej lokalizacji w przestrzeni procesora CAR, była zmaksymalizowana dla programów/systemu i liniowa. Nawet gdyby istniało okno, dzielące obszar pamięci operacyjnej na rozdzielne części, to nie jest to jakiś szczególny problem. Normą w obecnych systemach jest fragmentacja pamięci, a alokatory sobie z tym radzić muszą.

Oczywiście, że jest z tym trochę zabawy, ale czy specyfiką old-schoolowych komputerków nie jest właśnie ta konieczność zmagania się z takimi problemami?

Basic w rozważaniach świadomie skreślam. Nie ma to dla mnie praktycznego zastosowania. Dla zainteresowanych można oczywiście stworzyć własną implementację Basic'a i z tego co widziałem na Twojej stronie, coś takiego tworzysz. Oczywiście kompatybilność wsteczna z modelem pamięci OS'u atarowskiego nie ma w tym wariancie miejsca.

Być może omawiany projekt jest okazją, aby pewne rozwiązania przy jego implementacji powiązać/zintegrować.

W tym układzie rolę blitter'a musiałby przejąć sam procesor na CAR, przy założeniu jego odpowiednio wysokiej mocy. Widziałem jak TOS odświerza okna. Jestem przekonany, że można zrobić to lepiej.

Rozwiązanie z przełączaniem banków dotyczy wyłącznie komunikacji/transferu danych pomiędzy 6502, a procesorem CAR. Sam model pamięci procesora na CAR może być w dużym stopniu od tego niezależny.

Ostatnio edytowany przez Marek Konopka (2009-03-12 13:03:07)

> juz w wyobrazni slysze mp3 dekodowane na carcie

avr robi to w locie na jakims niskim zegarku, ile mhz potrzebuje na to 65816 lub 68xxx ? :-) acha... z tylu kompa w gniezdzie ?karta? jest tez audio in wiec mozna naprawde poszalec z dzwiekiem :-)

> A może wykorzystać któregoś ARM'a?

nie znam konkretnych rozwiazan mozliwe ze trzeba by sie bylo temu przyjrzec, ale za avr zaplacisz 5zl wiec mozna go wsadzic do kazdego karta z gra...

> Tak więc nie bardzo widzę, do czego miałoby mi się to osobiście przydać, a poza tym nasuwa się ogólniejsza obserwacja, że rozwój komputerów poszedł w tym kierunku, w jakim poszedł (mam tu głównie na myśli, że tam, gdzie jest więcej pamięci, jest ona dostępna w jednym kawałku) pewnie dlatego, że jest to rozwiązanie najlepsze i nie ma co wynajdywać prochu, który się na dodatek kiepsko pali...

nie samym chlebem.... a jak sie ma sprawa z automatami i konsolami? 3-4 procki dzialjace niezaleznie to norma :D i w ta strone trzeba sie poruszac skoro architektura a8 na to pozwala. przykladow takich rozwiazan mozna wymienic kilka jak ktos jest zainteresowany.

ogolnie, jesli to bedzie procek b.szybki,nowoczesny i tani zeby na karta z gra mozna go bylo upchnac to fajnie - jestem za, tylko jak przelamac strach ludzi przed nowoscia? wszystkie 65816 i 68xxx wypadaja strasznie blado w porownaniu z takim avr... a narzedzi na tego ostatniego jest cala masaaa.

> W tym układzie rolę blitter'a musiałby przejąć sam procesor na CAR, przy założeniu jego odpowiednio wysokiej mocy

65816 nie poradzilby sobie z emulacja procesora wektorowego np z asteroida :-) ... jesli myslicie o 65xxx to lepiej nie rozbudzac nadzei...

Trzeci (czwarty) kolor do rozróżnienia obszarów desktopu, okien, ikon byłby przydatny, podobnie jak na tych zrzutach z Geos'a.

Oczywiście, w domyśle chodziłoby o stworzenie nowego systemu operacyjnego, który współpracowałbym z CAR'tem, gdzie z kolei umieszczone byłby specyficzne funkcje API. Kompatybilość wsteczna z istniejącymi programami byłaby iluzoryczna. CART spełniałby tutaj rolę koprocesora.

Inny przykład, to zmodyfikowanie BASIC'a ładowanego do pamięci 6502, aby zamiast wywoływania czasochłonnych wersji procedur zmiennoprzecinkowych, zlecał to zadanie wyselekcjonowanemu podzbiorowi funkcji API na CART'cie, po uprzedniej detekcji CART'a. Sama ich implementacja mogłaby być identyczna z tymi już istniejącymi. Zysk z tego konkretnego zastosowania byłby wprost proporcjonalny do nadwyżki mocy zewn. CPU w stosunku do 6502 na maluszku, czyli taki nowszy TurboBasic XL. Inne zastosowanie, to szybsze odrysowywanie grafiki, edytory tekstu, graficzne, muzyczne. Do sprzętu musiałaby odwoływać się bezpośrednio część systemu zlokalizowana po stronie komputera, więc generalnie byłaby to jakaś hybryda.

Nie rozważaliśmy żadnych emulacji. W domyśle chodzi o zbiór funkcji API wrzucanych do szybkiej pamięci procesora na CARTcie. To jaki to będzie zbiór i z jaką skutecznością zaimplementowany, to już osobna sprawa i zależałoby od wielu czynników.

Ostatnio edytowany przez Marek Konopka (2009-03-12 16:13:29)