tebe napisał/a: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
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.
