to Quake mogę już pisać na twojego kompka ?AVT-2250 Wsad.
O ile mikrokontroler da radę. O prostych grach myślałem, nie jestem tylko pewien, czy tutaj to by wyszło.
Ewentualnie myślałem o "dopalaczu". Mianowicie główny mikrokontroler zajmowałby się wyświetlaniem i pobieraniem z pamięci, a drugi (podłączony np. przez SPI) obliczeniami dla gry. Czyli coś jak akcelerator.
Niewykluczone, że zrobię taki "dopalacz" jako karta rozszerzeń (po to wyprowadziłem sygnały na zewnątrz).
Ewentualnie myślałem o "dopalaczu". Mianowicie główny mikrokontroler zajmowałby się wyświetlaniem i pobieraniem z pamięci, a drugi (podłączony np. przez SPI) obliczeniami dla gry. Czyli coś jak akcelerator.
Niewykluczone, że zrobię taki "dopalacz" jako karta rozszerzeń (po to wyprowadziłem sygnały na zewnątrz).
Tylko jest małe ale. C64 posiada układ VIC, który w znacznej mierze odciążał mikrokontroler od wielu operacji. Aby wyświetlić przykładowo obrazek 16-bitowy w moim mikrokomputerze, który jest w RAM, potrzeba około 0.1s.
Poza tym AT89S8253 ma tryb X2, z którego korzystam. Zastosowałem kwarc 22.1184MHz, dzięki czemu mikrokontroler jest taktowany tak, jakby zwykły 8051 miał kwarc 44,2368MHz. A ściślej biorąc, skoro przypada mu 6 cykli zegarowych na cykl maszynowy (a nie 12 jak w standardowym 8051), to sam rdzeń jest taktowany z częstotliwością 3,6864MHz.
Pokażę, jak wygląda schemat komputerka (płyta główna), który zbudowałem: http://www15.zippyshare.com/v/28962705/file.html
Jak testy przejdą pomyślnie, opiszę go wraz z modułem wyświetlacza oraz zasilacza.
Poza tym AT89S8253 ma tryb X2, z którego korzystam. Zastosowałem kwarc 22.1184MHz, dzięki czemu mikrokontroler jest taktowany tak, jakby zwykły 8051 miał kwarc 44,2368MHz. A ściślej biorąc, skoro przypada mu 6 cykli zegarowych na cykl maszynowy (a nie 12 jak w standardowym 8051), to sam rdzeń jest taktowany z częstotliwością 3,6864MHz.
Pokażę, jak wygląda schemat komputerka (płyta główna), który zbudowałem: http://www15.zippyshare.com/v/28962705/file.html
Jak testy przejdą pomyślnie, opiszę go wraz z modułem wyświetlacza oraz zasilacza.
VIC akurat Commodora w niczym nie odciąża a nawet dociąża, bo kradnie cykle magistrali, bo pamięć RAM i obrazu jest wspólna, tak jak w zintegrowanych kartach graficznych z płytą główną.Tylko jest małe ale. C64 posiada układ VIC, który w znacznej mierze odciążał mikrokontroler od wielu operacji. Aby wyświetlić przykładowo obrazek 16-bitowy w moim mikrokomputerze, który jest w RAM, potrzeba około 0.1s.
Co do czasu dostępu do danych to sa sztuczki, gry programuje się inaczej niż normalne programy,
, to bardziej sztuka oszukiwania zmysłów, a jeżeli wyświetlacz masz na sprzętowym SPI to nie ma problemu, obraz można wysyłać w przerwaniach od SPI całkowicie sprzętowo, a miedzy nimi obliczać kolejną klatkę.Co do sztuczek.
Np. ekran N6100 w trybie 256BPP, to 128x128Pix czyli 16384B RAM na bufor. WOW 1/4 RAM
Ale nie koniecznie ? Pierwszym i podstawowym błędem jest myślenie, że musimy przechowywać i obliczać naraz cały obszar ekranu. Otóż możemy zastosować metodę kafelkową (modne słowo ostatnio) czyli podzielić ekran na kafelki o wymiarach 64x64pix, to już daje bufor 64x64 czyli 4096B, czyli 4KB, ale musimy zachować płynność obliczeń i wyświetlania obrazu wiec potrzebujemy dwa takie bufory, na przemian zapisywanie i wysyłane na ekran, co daje na 8KB RAM, ale to i tak postęp wedle tradycyjnej metody o 50%, a to dużo. Oczywiście można robić mniejsze kafelki np 32x32, ale trzeba pamiętać że zawsze jest coś za coś, mniej RAMu, ale więcej nakładów obliczeniowych (tu konkretnie operacji kopiowania danych, a nie mamy DMA) i bardziej rygorystyczne (krótsze) czasy wykonywania tych operacji, więc trzeba zawsze szukać kompromisu między jednym a drugim.Dzięki różnym sztuczkom na C64 można uzyskać np. to:
http://www.youtube.com/watch?v=r6aXUOdAN1c
Na ATARI zrobiono wolfenstein 3D.
http://www.youtube.com/watch?v=Z3-J2-VeoH8
No tak do końca nie jestem pewien. Mianowicie chodzi mi o sprite'y. One na pewno ułatwiają pracę programisty i w jakiś sposób odciążają mikrokontroler, ale mniejsza w sumie o to.
Co do tego, żeby nie liczyć całego ekranu, to jasne i oczywiste. Od razu wiedziałem, że najlepiej zmieniać tylko zawartość, która tego faktycznie wymaga, a nie cały ekran.
Co do tego, żeby nie liczyć całego ekranu, to jasne i oczywiste. Od razu wiedziałem, że najlepiej zmieniać tylko zawartość, która tego faktycznie wymaga, a nie cały ekran.