Tak mnie dzisiaj naszło, czy można w razie braku pamięci podstawowej (48k), przełączyć na bank w którym będzie np.muzyka, odegrać, po czym przełączyć spowrotem i kontynuować resztę programu ?
To akurat jest jednym z podstawowych zastosowań dodatkowej pamięci w 128 - zwróć uwagę, że w większości (zwłaszcza starszych) gier z muzyczką na AY (a co za tym idzie i w wykorzystujących te muzyczki demach) muzyczki znajdowały się powyżej $C000 czyli w obszarze przełączanej pamięci. Co więcej - często w starszych demkach trzeba było się nakombinować, bo wszystkie muzyczki musiały grać mniej więcej w tym samym obszarze i przy przełączaniu trzeba było najpierw zamienić miejscami fragmenty pamięci zanim zaczęło się grać kolejną muzyczkę.
W jaki sposób i do czego właściwie używa się pamięci ekranu w 128k. Proszę o jakieś przykłady, czego nie da rady zrealizować na 48k, a dodatkowe ekrany w 128k to umożliwiają. Dzięki
Co do używania drugiego ekranu to tu sprawa jest trochę bardziej skomplikowana. Problem polega głównie na tym, że większość firm robiących gry chciała mieć swoje produkcje zarówno w wersji 48 jak i 128. Użycie podwójnego ekranu automatycznie uniemożliwia albo bardzo utrudnia takie rozwiązanie. Chodzi oczywiście o to, że w trybie 48 ekran znajduje się pod $4000, w trybie 128 drugi ekran siedzi pod $C000. Mechanizm mapowania pozwala przełączyć pod $C000 dowolny blok 16kB dzięki czemu jeśli decydujemy się na pisanie wyłącznie dla 128 procedury graficzne można "celować" pod $C000 i jednym OUTem przełączać ekran roboczy i wyświetlany.
Część gier dla 128 była robiona w dwóch wersjach - uboższej dla 48 i bardziej rozbudowanej dla 128, część w trybie 128 po prostu nie wczytywała muzyki, dodatkowej grafiki itp.
Kwestia tego co ci daje sprzętowy podwójny ekran i czy jest on "do szczęścia" niezbędny to zupełnie inna dyskusja
Oczywiście jak napisał RafalM większość efektów (zwłaszcza w grach) da się zrobić bez drugiego ekranu - co najwyżej będzie wolniej. Problem w tym, że o ile można sobie pozwolić na zrobienie gry, która odrysowuje ekran co drugą, trzecią chy nawet czwartą ramkę o tyle zrobienie dema w taki sposób jest właściwie niedopuszczalne.
Jedyne efekty przy których mniej niż 50 FPS jest do przyjęcia to te w których konieczne jest wykonywanie zaawansowanych obliczeń - wszelkiego rodzaju 3D, fraktale, zaawansowane plazmy czy tunele. Standardowe efekty bitmapowe, scrolle, sprite'y, boby itp. w zasadzie nie mają prawa chodzić inaczej niż w pojedynczej ramce
Zaleta zastosowania podwójnego ekranu wymaga wyjaśnienia ogólnej zasady tworzenia takich efektów. Oczywiście szczegóły będą zależały od tego nad czym konkretnie pracujesz, ale zasada jest właściwie zawsze ta sama - najpierw musisz przygotować "pole robocze" a następnie wygenerować kolejną klatkę animacji. Jeśli animacja/efekt za każdym razem odrysowuje całe pole robocze to jego przygotowanie nie jest niezbędne.
Załóżmy teraz, że wymyśliłeś fajny efekt, który będzie się wyświetlał na dwóch tercjach ekranu a na jego wygenerowanie jest ci potrzebne 25000 taktów. Kod startuje od początku ramki czyli w momencie, kiedy raster zaczyna wyświetlać górny border - przez ~14300 taktów masz nieograniczony dostęp do pamięci ale potem raster dochodzi do początku bitmapy i ULA zaczyna pobierać dane grafiki zwalniając w razie potrzeby procesor. W najgorszym wypadku może to oznaczać, że dostęp do pamięci ekranu zostanie wydłużony o 6 taktów. Pozostałe z naszego efektu 10700 taktów może się znacznie wydłużyć zwłaszcza jeśli najpierw coś przeliczałeś a na koniec wrzucasz dane na ekran. Przy braku contention (czyli wstrzymań dostępu do pamięci) 10700 taktów to niecałe 48 linii ekranu. Po doliczeniu contention - powiedzmy 64. Oznacza to tyle, że jeśli twój efekt zmienia pierwsze 64 linie ekranu to z dużą dozą prawdopodobieństwa w którymś momencie nastąpi "ścięcie" dające widoczny efekt - na przykład kulka przecięta w połowie tak, że wyżej widać ją juz przesuniętą a np. od połowy jest jeszcze poprzednia klatka.
Części takich problemów można uniknąć przesuwając pozycję na ekranie, części poprzez odpowiednią modyfikację kodu tak, żeby modyfikacja ekranu następowała w trakcie wyświetlania ramki itp. Ogólnie "zmagania z rastrem" są wyzwaniem samym w sobie i niewątpliwie dobrze zrobione dema pracujące w trybie 48 są dowodem na fachowość koderów
Wracając jednak do naszego przykładu - skończyliśmy generowanie efektu i co dalej? Dalej należy odczekać aż raster przejdzie poniżej obszaru w którym znajduje się świeżo wygenerowana grafika a następnie przygotować pole robocze dla kolejnej klatki - zwykle po prostu wyczyścić to, cośmy tam przed chwilą narysowali albo odtworzyć tło z bufora. I znowu - jeśli zaczniemy to robić za wcześnie skasujemy część grafiki, jeśli za późno - nie zmieścimy się w ramce. Czekanie też jest trochę bez sensu - zwykle w tym czasie coś jednak robimy (gramy muzykę, przeliczamy kolejne efekty itp.) jednak trzeba w tym wypadku dokładnie dopilnować tego, żeby cały czas nie był ani za długi ani za krótki. A na zakończenie po prostu czekamy na kolejne przerwanie i cała zabawa zaczyna się od początku.
I tu dochodzimy do najważniejszego zastosowania podwójnego ekranu - jest on odpowiedzią na całą "walkę z rastrem". Dzięki temu, że mamy dwa ekrany możemy całą procedurę zorganizować "logicznie i po kolei" - nie musimy kombinować kolejności a potem zastanawiać się dlaczego akurat tak to zrobiłem. Możemy spokojnie na początku ramki włączyć wyświetlanie jednego ekranu a w obszar $C000 zmapować drugi i na nim przygotowywać kolejną klatkę - najpierw wyczyścić to, co ma być wyczyszczone, potem wrzucić to, co się tam ma pojawić na koniec przeliczyć dane do kolejnej klatki i całość zakończyć odtworzeniem muzyczki. I jedyna rzecz której musimy pilnować to to, żeby zmieścić się z całością w jednej ramce. Raster nie ogranicza nam pozycjonowania grafiki, nie ogranicza czasów wykonania poszczególnych kawałków, nie wymusza bezproduktywnego czekania itp. Na koniec po prostu czekamy na koniec ramki, robimy jednego XORa przełączając bity wyświetlanego ekranu i banku pamięci potem tylko jeden OUT i możemy rysować następną ramkę
Powyższe jest oczywiście sporym uproszczeniem tematu i nie zahacza nawet o "mrugające" tryby graficzne czy podbijanie liczby kolorów poprzez "mruganie" atrybutami itp., ale to jest właśnie podstawowe - kanoniczne - zastosowanie podwójnego buforowania ekranu.
Ufff
