Odp: Projekt "WERONIKA"
Candle: Faktycznie. Wiedziałem, że gdzieś jest haczyk, ale o arch. harwardzkiej zapomniałem.
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Silly Venture 2024 SE - stuff Dostępny jest już stuff z zeszłomiesięcznego party Silly Venture 2024
FujiCup FujiCup ma na celu wspieranie sceny gier retro, dając uczestnikom szansę na pokazanie swojego talentu
Echa Silly Venture 2024 SE Są już dostępne wyniki Silly Venture 2024 SE
Uaktualnienie firmware do The400 Poprawki do "fizycznego" emulatora ośmiobitowych komputerów i konsol Atari.
Akcja - Wsparcie w reverse-engineering Wspierajmy tych, którzy do tej pory zrobili wiele!
Strony Poprzednia 1 2 3 4 5 … 9 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Candle: Faktycznie. Wiedziałem, że gdzieś jest haczyk, ale o arch. harwardzkiej zapomniałem.
laoo: skoro mam juz twoja uwage, to zapomniales o czyms jeszcze :P
> 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 :-)
Gdzieś kiedyś czytałem że szacowana potrzebna moc obliczeniowa to 10 MIPSów na kanał. +- zależnie od bitrate pewnie.
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
(...)Od tego to mamy VBXE (sorry, ale graficzny desktop musi być ładny, a z 320x192 w dwóch kolorach nic ładnego nie powstanie, bo potrzebne sa co najmniej 3 kolory, żeby to jakoś wyglądało).
:) - wypraszam sobie :)
http://www.atari8.info/trsdesktop.php
:D
pin: z takim idiota na tapecie to nie moze byc ladne :P
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)
nikt nie broni nikomu napisac np interpretera basica na avr ktory bedzie mial kod basicowy w pamieci zewnetrznej, tylko jakie to by mialo zalety?
mnozarke tez mozna zrobic z avr (avr mnozy w dwoch cyklach 2 liczby 8 bit), ile zajmie wydobycie wyniku, to juz pomijam
sprzetowe duchy z kolei zapewnia blitter vbxe
bardzo obawiam sie sytuacji w ktorej mamy rozszerzenia x i y i ktos mial wizje, ze on bedzie pisal na x, bo y jest be i nie atari i on sie nim brzydzi, tymczasem inna osoba bedzie miala rozszerzenie y i bedzie chciala sobie to obejrzec i sie dowie ze jest nie atari i autor piszacy na x ja zdyskryminowal
mysle tez, ze czas dodany na obsluge protokolu wymiany bankow bedzie dosc znaczacy
@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.
cpld znacznie obnizy koszta i zmniejszy rozmiar calosci
i to raczej nie beda gale... chociaz jesli troche ograniczyc apetyt pewnie cos by sie dalo zrobic i galem
nikomu nie mam zamiaru nic tu zabraniac - powiem wiecej - jestem wdzieczny za kazdy projekt jaki sie pojawia tak dlugo jak wnosi cos nowego (np moje obydwa ktore doczekaly sie realizacji w wiecej jak jednej sztuce niczego nowego nie wnosza, jeden ktory cos nowego wnosil, jakos zainteresowania sie nie doczekal), ale idac ta droga to mam skomplikowany interfejs do tv - szczegolnie jesli cale obciazenie przejmie procesor rozszerzenia
czy to zle? sa tacy ktorzy powiedza ze tak
zreszta, mysle ze Zenon i tak zbuduje swoja Weronike, czy ktos tego chce, czy nie, a czy bedzie to dobry pomysl - czas pokaze
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
Mnie się ten projekt bardzo podoba. Mam nadzieje, że będzie to kompatybilne z "CORINĄ". Mając coś takiego BOMB JAKE byłby jeszcze lepszy:)
Taki procek (lub blitter) zniósłby ograniczenia szybkościowe.
Od strony programistycznej w grach najbardziej brakuje dużej ilości i sporych rozmiarów duchów programowych.
Mam nadzieję, że dodatkowy procek znacząco przyśpieszy takie oto operacje w pamięci:
1) kopiowania bloków pamięci.
2) nakładanie 2 bloków pamięci na siebie (AND, OR, EOR) i tworzenie 3-ciego z tego.
3) przesunięcie bitów w obrębie bajtu. (od razu w całym bloku pamięci)
4) dekompresja danych w czasie rzeczywistym:)
Od strony programistycznej w grach najbardziej brakuje (...) sporych rozmiarów duchów programowych.
A te wielgachne "duchy" w grze "Upiór" (bohater i jego przeciwnicy) to jak powstały, że działają na "zwykłym" Atari??
mysle tez, ze czas dodany na obsluge protokolu wymiany bankow bedzie dosc znaczacy
Protokół komunikacyjny jest gotowy. Nie ma tam żadnych lagów. 6502 testuje semafor (bit) z rejestru 6502K w prostej pętli. Samo ustawienie rejestru/przełączenie banku to prosta sekwencja operacji: lda rejestr, and #maska, ora #wartosc, sta rejestr. 6502 nie musi (nie powinien) czekać bezczynnie na dane od 6502K. Można podzielić odpowiednio porcję danych do obróbki pomiędzy 6502 oraz 6502K tak, aby moment ich scalenia występował w mniej więcej tym samym czasie po obu stronach. W ten sposób można zrealizować proste przetwarzanie równoległe.
Nie mam zbyt wielkiego pojęcia o vbxe, ale wyobrażam sobie przykładowo, że 6502K może wygenerować złożoną grafikę w jednym z trybów vbxe, lokując bufor pod CAR, a sam vbxe dokona wyświetlenia tych danych. W takim scenariuszu oba rozszerzenia są komplementarne i nie gryzą się ze sobą. Można również sobie wyobrazić scenariusz z podziałem ról, tzn. podziałem ekranu na strefy, do których dostęp będą miały osobno - blitter vbxe oraz weronika.
Jeszcze jedna ciekawa obserwacja. Dzięki przełączaniu banków zlokalizowanych po stronie 6502K i umieszczeniu buforów ekranu pod adresem CAR, nie musimy realizować żadnego dodatkowego dwubuforowania po stronie 6502, w sensie alokacji dodatkowej pamięci. Bufory te są zlokalizowane w dwóch bankach pamięci współdzielonej, umieszczonej na CAR, także moje wcześniejsze założenia, iż byłaby konieczność alokacji tych buforów w każdym banku są nieścisłe.
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.
vbxe nie jest w stanie odczytac zadnych danych z atarki
atarka zapisuje i odczytuje dane z vbxe tylko dla tego, ze vbxe podpycha atarce swoja pamiec tak jak robi to cart
czyli to pamiec vbxe pojawia sie w atarce, tak samo jak pamiec weroniki sie pojawia
chcac przerzucic dane z weroniki na vbxe musialby to robic 6502 w atarce
ponadto skad weronika wie co w ogole ma robic i jak jej to wyperswadowac i zaprzedz do robienia czegos innego?
ponadto skad weronika wie co w ogole ma robic i jak jej to wyperswadowac i zaprzedz do robienia czegos innego?
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.
przyjolem do wiadomosci
czas pokaze czy to ma sens
jak dla mnie to rozszerzenie typu drugie costam (pokey, antic (tez byly), pia itp) z technologia sprzed 30 lat - i to mnie najbardziej boli
nikla kupowalnosc czesci nowych
no ale - nie bede tu agitowal ze be, fuj i w ogole nie cacy
poswiecacie projektowi swoj czas i widze ze sporo pracy zostalo juz w to wlozone
kiedy mozna spodziewac sie jakis przykladow wykozystania? (w postaci filmidla)
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.
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.
Wymiana danych przez stronę $d5xx nie jest konieczna. Jest raczej kłopotliwa, bowiem ogranicza możliwości konstruowania innych rozszerzeń. Do realizacji pomysłu wystarczy jedna komórka pamięci na stronie $d5xx. Rozmiar jednej strony jest na tyle nieistotny, że nie stanowi to żadnego problemu w kontekście rozmiarów bufora ekranu zlokalizowanego pod pamięcia CAR.
Grę piszemy w taki sposób, że procesor w Atari nie zapisuje niczego do pamięci ekranu!
Co ciekawe, może to robić. Przy odpowiednim docyklowaniu może dołożyć do wyświetlanego bufora dodatkowe dane.
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.
Ma to sens w wariancie, gdy procesor 6502K posiada zbliżoną wydajność do 6502. Wtenczas opłaca się podzielić ekran na 2 osobe bufory, do których wyłączny dostęp będą miały odpowiednie procesory. Oczywiście w wariancie bardziej wydajnego procesora po stronie Weroniki to podejście traci sens.
Aktualizacja:
jak dla mnie to rozszerzenie typu drugie costam (pokey, antic (tez byly), pia itp) z technologia sprzed 30 lat - i to mnie najbardziej boli nikla kupowalnosc czesci nowych.
Można docelowo wziąć pod uwagę wariant z FPGA.
kiedy mozna spodziewac sie jakis przykladow wykozystania? (w postaci filmidla)
Będzie to miało miejsce, gdy Pan Zenon skonstruuje prototyp z większą ilością pamięci (65kB). Do tego czasu będą testowane elementarne programy komunikacyjne. Co do konkretnych terminów, proszę pytać o to jego samego.
Ostatnio edytowany przez Marek Konopka (2009-03-29 13:46:37)
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)
acha, ale po tym wszystkim output jest i tak w 4 (5) kolorach
interlace? kolejne wyrzeczenia - ostatecznie mozemy dostac obrazek z cala masa kolorow, tylko ze wielkosci znaczka pocztowego
acha, ale po tym wszystkim output jest i tak w 4 (5) kolorach
interlace? kolejne wyrzeczenia - ostatecznie mozemy dostac obrazek z cala masa kolorow, tylko ze wielkosci znaczka pocztowego
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)
no wlasnie
nie jest
tak naprawde to chodzi tylko o to nieszczesne 6502 i jego ogromny power without the price
czekam niecierpliwie na jakies przyklady zastosowan praktycznych
byc moze ogranicza mnie wyobraznia...
Strony Poprzednia 1 2 3 4 5 … 9 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.105 sekund, wykonano 10 zapytań ]