Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
TONY na małe Atari Nowa gra na małe Atari, w Hiresie, produkcja Rafała Dudka (brat XXL-a), Popmilo i Caruso.
Cosmic Hero 2 Bohater ratujący Ziemię w kryzysowej sytuacji powraca po 30 latach.
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
kod jest dla 6502, nie wykorzystywałem właściwości 65816, tylko większy zegar, wypadałoby ładować to do pamięci Rapidusa, ze względu na zajętość pamięci takiego rozpisanego kodu rastra, w pamięci podstawowej zmieszczenie zmian dla 240 linii jest kłopotliwe (5*44 * 240 = 52800 bajtów)
Nie znam się ale się zapytam.
Czy jest jakiś konkretny powód dla którego rapidus działa asynchronicznie w stosunku do swego dziadka ?
Powodem jest cel, którym było osiągnięcie równych 20MHz częstotliwości pracy procesora.
Czy ten powód jest wystarczająco dobry?
Jest wystarczająco dobry ;)
Ale jak jest jakis drobny zapas mozna by go spróbować pogonic ciut szybciej synchronicznie z dziadkiem.
Chyba nie próbowałem iść wyżej z częstotliwością, bo i tak musiałem nieźle pokombinować, żeby osiągnąć te 20MHz (jest to dużo powyżej tego co mówi specyfikacja układu). Pierwsze prototypy Rapidusa chodziły na 14MHz, kolejny na 16MHz aż wreszcie strzeliła dwudziestka.
Wg datasheet strona 29, Figure 4-2 F Max vs. VDD przy 5V powinien do jakichś 23MHz dać radę.
a czy dało by się dodać do Rapidusa jakieś zacne DMA, które po aktywacji (np. co VBL) samo kopiowało by dane z pamięci do rejestrów sprzętowych, np do rejestrów koloru? Dzięki temu CPU mógłby pracować równolegle z "trybem Tebe" :)
Na ST jest taki tryb Photochrome gdzie BLiTTER właśnie kopiuje dane koloru z RAM do rejestrów koloru SHIFTERa
@willy
Idąc tym tropem, to po podniesieniu zasilania do 5.25V będzie jeszcze więcej. Odpowiem, że może tak, może nie. Nie zmienia to jednak faktu, że wykres, na który się powołujesz, kończy się na 20MHz. Polecam analizę tabelki z gwarantowanymi czasówkami.
@Cyprian
Taki był plan na blitter w Rapidusie.
no to fajnie
@pasiu: oprócz blittera może nie tyle w planach, ile w koncercie życzeń, było też MMU. Żeby można było dowolny obszar (powiedzmy, że w porcjach po 2-4k, max. 8k) Fast/SD-RAM-u odłączyć zupełnie, przemapować na miejsce dowolnego innego, zamienić miejscami z innym, nałożyć na niego ochronę (żeby dostępy r, w, r/w, uruchomienie kodu powodowały Abort) itd.
I TO to rzeczywiście mogłoby sporo pomóc w emulacji takiego 128.
Poza tym, trochę SD-RAM-u się chyba marnuje. Czy nie dałoby się opcjonalnie podpiąć tej pamięci jako dodatkowych banków wiszących na PORTB. Weźmy takie przeciętne Atari (np. moje), ma wszystkiego 320k, gdyby można było do tego dołożyć ze 16 banków SD-RAM-u, to np. SDX działałby szybciej :)
@tebe: jasna sprawa. Ale też 4*44*240 = 42240.
Ostatnio edytowany przez drac030 (2017-01-22 13:34:58)
Altirra + RAPIDUS + pamięć liniowa
w załączniku ROM-y, obrazki z opisem konfiguracji Altirry, program testowy który przepisywany jest pod adres $013000 i zmieniający kolory w linii (obraz dyskietki disk.atr dla SDX)
uruchamiamy przez X
X RAS_.OBX
innymi słowy, nic nie stoi na przeszkodzie aby pisać dla RAPIDUS-a (65816) z pamięcią liniową :)
Ostatnio edytowany przez tebe (2017-06-06 20:44:57)
... nie znam się, ale po co makro MOVE jeśli '816 ma tego rodzaju rozkazy na pokładzie?
Pin: ustawiam się do Ciebie w kolejce po Tebe na korki z asemblera.
Bez obaw Pin, makro MOVE korzysta z 65816, pomaga tylko ustawić adresy 24bit oraz 16bit długość przenoszonych danych, tak dla wygody
Dobra, na lekcje assemblera zainteresowanych zapraszam od 1 września :D
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.080 sekund, wykonano 11 zapytań ]