laoo: skoro mam juz twoja uwage, to zapomniales o czyms jeszcze :P

a ja z kolei nie znam zadnej implementacji avr w ktorej to by gral mp3... owszem, sa playery ktore czytaja z sd i graja mp3 na avr, ale do mp3 jest specjalizowany uklad

:) - wypraszam sobie :)

http://www.atari8.info/trsdesktop.php

:D

Witam po dlugiej nieobecnosci.
Ponieważ mialem mozliwosc dyskutowania z Zenonem jego pomyslu, a takze konsultowania sie z XXL'em i Sebanem na bardzo podobny temat, pozwolę sobie na slowo komentarza.

Mam wrazenie, ze wiekszość komentatorów nie załapała co jest najważniejsze w pomyśle Zenona. Otóż najmniej ważne jest jaki procesor będzie na carcie! Najważniejszy jest pomysł na "wahadłową" zamianę dwóch 8kB banków pamięci między procesorem głównym a koprocesorem, przy czym ta zamiana jest sterowana zawsze przez 6502 komputera.

Pomysł koprocesora jest bowiem stary jak świat, ale "wąskim gardłem" był właśnie dostęp do pamięci (lub też wymiana danych między procesorem głównym a koprocem). W grę wchodziła dotąd albo fizyczna zamiana procesora w komputerze na mocniejszy, albo pomysł z pamięcią dwuportową.
Zrobiłem rozeznanie i pamięci dwuportowe są albo nieosiągalne albo baaardzo drogie.
Ja miałem jeszcze jeden pomysł: sprzętowa emulacja pamięci dwuportowej przez szybki procesor na carcie (np. Atmel). Ale po konsultacji z Zenonem i Sebanem pomsł wydał się za trudny w implementacji.

Tymczasem Zenon wymyślił genialny bufor: każdy z dwóch procesorów widzi naprzemiennie jeden z dwóch 8kB obszarów pamięci. I to jest istota jego pomysłu. Reszta to szczegóły, które mogą się zmieniać w konkretnych implementacjach.

Co nam to daje? Ano możemy sobie przyłączyć do tego interfejsu dowolny procesor. Jeśli będzie to 816 to będzie on uniwersalnym koprocesorem, a jego program będzie mu podawany w 8kB pamięci.
Ale, wbrew temu co napisał Candle może to być przecież mikrokontroler np AVR. Dlatego, że wcale nie musi on czytać swojego programu z zewnętrznego RAM'u dzielonego z Atari! Może mieć w swoim ROM'ie program (nazwijmy go "rdzeniem") a z Atari wymieniać jednynie dane.
Ograniczeniem będzie tu brak uniwersalności. Ale w ten sposób możemy sobie zrobić zależnie od potrzeb carta z rdzeniem wykonującym szybkie obliczenia matematyczne, albo z rdzeniem realizującym wieeelkie i liczne sprzętowe duchy.

Ja wręcz zastanawiałem się czy Weronika nie powinna być jednynie buforem obsługującym podmiane 8kB banków pamięci + złącze. I w to złącze możnaby sobie wstawiać płytkę z procesorem, byle potrafił on dostosowac swoją pracę do zasady działania Weroniki.
Wiem, że brzmi to dośc mgliście, ale myślałem nad tym od kilku miesięcy i uważam, że jest to możliwe.

A weźcie pod uwagę, że dzielimy tylko 8kB pamięci. A obszar cartridga w RAM'ie Atari ma 16kB. Czyli pozostałe 8kB z obszaru cartridga może zawierać zwykłą bankowaną pamięć gdzie może być umieszczona gra. Taki cart zawierałby wszystko co programiście i graczowi do szczęścia potrzebne. Np grę wymagającą sprzętowych duchów i procesor, który je realizuje.

A propos sprzętowych duchów, to dla mnie jest to najbardziej pociągający temat do implementacji w tym nowym cartridgu. W kolejnym poście postaram się dokładnie opisać jak mogłyby one działać na Weronice.

Z rozmów z Zenonem zarysowała się niestety też jedna dośc poważna wada: konieczność użycia dośc dużej ilości układów cyfrowych - co najmniej kilkanaście. Może to oznaczać, że cart nie wejdzie w standardową obudowę, oraz co gorsza koszt tych układów może być wiekszy niż mikrokontrolera. Ale może da się te układy cyfrowe troche jeszcze zredukować albo nawet zastąpić jakąś programowalną logiką...? Kto wie.

Ostatnio edytowany przez nosty (2009-03-29 01:09:29)

@Candle:

Nie chodzi mi o dostarczanie w RAM programu dla uC w jakimkolwiek języku. Bardziej o specjalizowane polecenia do konkretnego zastosowania: np. obróć obiekt 3D o 7 stopni, albo przesuń ducha o 5 pikseli.

A przy takich zadaniach jak rysowanie duchów czy wspieranie animacji 3D, zamiana banków wystarczy że będzie robiona co 1/50 sekundy. Zresztą nie będzie to wcale takie wolne. Ot parę rozkazów.

A co do konkurencji rozszerzeń: pomysł Zenona ma tę zaletę, że montuje się go "bez użycia gwoździ" ;) Możesz dostarczyć użytkownikowi grę i dopałkę na cartridgu. Trudno o prostsze i bardziej kompatybilne rozwiązanie.
Martwię się tylko trochę o cenę...

No i kiedyś już chyba ustaliliśmy, że najgorsze co można zrobić to "zabraniać" komuś budowania własnego projektu, żeby nie mnożyć standardów. Ja sam się potem kajałem za niekonstruktywną krytykę VBXE. Więc proszę nie wysuwaj teraz takiego argumentu. Jeśli gra wymaga jakiegoś rozszerzenia to wymaga. Trudno. A jeśli sama dostarcza to rozszerzenie na swoim nośniku no to jest już bajka moim zdaniem.

Nosty pisząc o duchach sprzętowych chyba miał na myśli programowe, bo sprzętowo duchy wspiera GTIA albo VBXE dzięki swojemu blitterowi i trybowi Overlay

sprzętowo Weronika mogłaby wspierać kopiowanie pamięci, czyli służyć jako blitter

A te wielgachne "duchy" w grze "Upiór" (bohater i jego przeciwnicy) to jak powstały, że działają na "zwykłym" Atari??

Animacja na czarnym tle i ruch w tępie żółwia tych sprite'ów....oto jak powstały

Ja myślę o czymś bardziej ambitnym, a do tego 6502 jest za wolny...a coś wiem na ten temat po napisaniu BJ.

Jak już wcześniej wspominałem, w wydzielonej części pamięci 6502K (EPROM) umieszczony jest kod do obsługi prostego protokołu komunikacyjnego. Uwzględnia on przesyłanie elementarnych komend takich jak przerzucanie danych, wywołanie procedury, identyfikacja. Po wykonaniu komendy 6502K odpowiednio sygnalizuje to opuszczeniem swojego semafora. Wykrywa to 6502, czuwając nad całością wymiany danych. Do synchronizacji wykorzystane są dwa semafory, jeden dla 6502 drugi dla 652K. Zenon podawał ich opis wcześniej w tym wątku.

Skoro tak mówisz... Ja sie malo znam, ale wydaje się, że z punktu widzenia programisty i procesora Atari byłyby to duchy sprzętowe.
Atari definiuje ducha, pozycje itp, a resztę robi dodatkowy sprzęt (Weronika). Widzę to pewną analogię do współpracy z GTIA. Zerknij na poniższy "case study" użycia Weroniki:

Szybki pomysł jak zrobić obsługę duużych i licznych duchów za pomocą Weroniki:

Na cartridgu mamy szybki mikrokontroler (uC) z własnym programem (rdzeniem) w ROM i obsługą zewnętrznej pamięci SRAM (np. 64kB) (_oprócz_ dostępu do 8kB dzielonych z Atari). Przy odpowiednio szybkim procesorze wystarczy po prostu duża liczba obsługiwanych portów. Sprawdziłem - są takie Atmelki.
W rdzeniu uC znajduje się program specjalizowany wyłącznie do rysowania, przesuwania i obsługi kolizji duchów. Przy czym musi to oczywiście robić na pamięci ekranu zorganizowanej zgodnie z jakimś trybem (lub trybami) Atari.
Dla uproszczenia załóżmy obsługe wyłącznie jednego trybu graficznego.
Rdzeń rozumie też oczywiście polecenia dotyczące animacji duchów przekazywane mu z Atari.

Wazne: cartridge jest tak skonstruowany, że nie tylko wahadłowo dzielimy między procesorem i uC obszar 8kB, ale mamy też możliwość przekazywania do/z uC danych za pomocą niektorych rejestrów strony $D5xx. To jest mozliwe i potrzebne, bo idea jest taka, że dzielony wahadłowo obszar 8kB będzie pamięcią ekranu, a strona $D5xx będzie służyła do wysyłania danych i polecen między 6502 a uC.
Gdyby było to za trudne, to można obejść to wymaganie: Jeśli pamięć ekranu zajmowałaby mniej niż 8kB (np zrezygnowalibyśmy z wyświetlania kilku linii), to mamy pełny komfort: możemy zrezygnować z komunikacji przez stronę $D5xx i wykorzystać do przekazywania danych fragment 8kB obszaru pamięci, który jest już poza widoczną na ekranie pamięcią obrazu. Nie potrzeba tego wiele - wystarczy nam kilkadziesiąt bajtów.

Pamięć robocza SRAM (do której dostęp ma oczywiście tylko uC na cartridgu) zawierać będzie obszary:
(A) 8kB - pamiec tla,
(B) XkB - definicje duchow,

Oczywiście są one zgodne z trybem graficznym Atari, który obsługujemy. Załóżmy, że pamięć ekranu zajmuje w tym trybie 8kB.

Wyobraźmy sobie na początek dla uproszczenia grę, w której tło jest stabilne (bez scrola) a poruszają się po nim animowane obiekty. Takimi grami sa np. Bomb Jack albo World Karate.

Grę piszemy w taki sposób, że procesor w Atari nie zapisuje niczego do pamięci ekranu! Całą budowę ekranu przerzucimy na uC na cartridgu. Trzeba mu tylko dostarczyć odpowiednie dane.

A obsluga gry i duszków dziala tak:
1. Na poczatku Atari przekazuje do carta tło danej planszy oraz definicje duchow (wszystkie obiekty w różnych fazach ruchu). Można to zrobić przez stronę $D5xx albo przez wspóldzieloną pamięć. Będzie to ciut wolne, ale na czasie nam tu specjlanie nie zależy - gra się jeszcze nie zaczęła. uC odbiera te dane umieszcza je w obszarze SRAM przeznaczonym na tło (A) i duchy (B).
2. Atari ustala pozycje, widocznosc, animacje, priorytety i inne parametry duchow.
3. Pamięć ekranu zostaje ustawiona na współdzielnony obszar 8kB cartridga.
4. uC wykonuje polecenia Atari dotyczące duchów nakladajac duchy na tlo i zapisujac do 8kB "połówki" dzielonej pamięci do której akurat na dostęp. Ma na to 1/50 sekundy - czas ramki.
W tym czasie wykrywa rowniez kolizje duchow. Będzie je mógł później przekazać do Atari przez odpowiednie rejestry strony $D5xx.
5. W czasie przerwania VBI Atari wysyła polecenie zamiany wspóldzielonych połówek 8kB. Na ekran trafia właśnie przygotowany obraz. A od tego momentu uC może zająć się przygotowaniem kolejnej klatki wg przekazanych przez Atari nowych pozycji i faz animacji duchów.

I tak w kółko.

To po krotce tyle.
Jak pisałem - nie ma sensu, żeby procesor Atari sam modyfikował pamięć obrazu bo te zmieny i tak zostaną "przykryte" po 1/50 sekundy przez kolejną klatkę przygotowaną przez uC.

Zenon!
Wg Twojego pomysłu mamy 2 obszary 8kB każdy. Jeśli jeden widziany jest przez 6502 w Atari to drugi  przez uC na cartridgu. Po wydaniu polecenia przez 6502 następuje zamiana widocznych obszarów.

A dałoby się zrobić łatwo taką modyfikację dzielonego wahadłowo 8kB obszaru pamięci jak opisuję niżej?

Mamy 4 fizyczne obszary, każdy po 8kB (czyli w sumie pamięć 32kB).
Nazwijmy je: A, B, C, D.

Zamiana następuje dokładnie tak jak opisałeś z jednym ALE:

Jeśli Atari widzi i czyta obszar A to próba zapisu do tego obszaru spowoduje zapis fizyczny do obszaru B.
W tym samym czasie uC na carcie może czytać obszar C a zapisywać tylko do obszaru D.

A po zamianie banków:

Atari czyta obszar D a zapisuje do C.
uC na carcie czyta obszar B i zapisuje do A.

Wydaje mi się, że sprzętowo powinno to być dość proste: odpowiednie 2 nogi adresowe pamięci dzielonej musiałaby być sterowana przez sygnały R/W z 6502 i uC.

Tak, to nie pomyłka. W tym trybie pracy, żaden uC nie czytałby tego co przed chwilą zapisał, a jednocześnie po zamianie banków każdy z nich odczytywałby to co w poprzednim "cyklu" zapisał drugi procesor.

Co to daje?
Ano wyobraźcie sobie, że implementujemy na uC Weroniki obsługe duchów - opisałem to w poprzednim poście.
Pamięć ekranu zajmuje całe 8kB pamięci dzielonej.
Przy takim trybie pracy pamięci jaki teraz opisuję Atari i Antic zawsze czytają pamięć obrazu przygotowaną w poprzedniej klatce przez Weronikę. A jednocześnie procesor Atari może zapisywać do 8kB obszaru informacje dla uC, które odczyta on po przełączeniu obszarów (po 1/50 sekudny).
Te informacje, to może być np tło obrazu dla gry:
Procesor Atari definiuje tło dla kolejnej klatki zapisując je do pamięci obrazu. Może to robić w dowolnym momencie, nie bojąc się, że popsuje właśnie wyświetlany obraz.
Po przełączeniu obszarów (w czasie przerwania ramki), uC na to tło nałoży duchy i zapisze wynik tej operacji do tego samego adresowo miejsca pamięci dzielonej (ale fizycznie do innego banku!).
Innymi słowy w takim trybie pracy pamięci, 6502 zawsze czyta tło+nałożone na niego duchy a zapisuje samo tło.
uC w Weronice odwrotnie: czyta tło (nigdy go nie modyfikuje) a zapisuje do tego samego obszaru tło+nałożone duchy. Obszar adresowy ten sam, ale pamięć fizycznie inna.

Wiem, ze opisałem to ciut chaotycznie, ale ciężko mi to ubrać tak na gorąco w słowa ;)

Ostatnio edytowany przez nosty (2009-03-29 13:45:37)

80 bajtów na linię w trybie HIP * 200 poziomych liń daje 16 000, czyli ilość mieszczącą się w 16kB obszarze CAR. Gdyby to z jakichś powodów było nieosiągalne lub wartością za małą, to mamy możliwość przełączania banków pamięci w połowie ekranu, co zredukuje nam wymagania dot. wielkości okna komunikacyjnego dla wyświetlanego bufora ekranu. Komplikuje to kod po stronie 6502K, ale jest osiągalne dla pewnych zastosowań (sprite'y), a tym bardziej przy większej mocy 6502K.

Weronika, to nie projekt karty graficznej z nowymi trybami graficznymi.

Ostatnio edytowany przez Marek Konopka (2009-03-29 14:00:23)