Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Programowanie - 8 bit » Rapidus - zmiana koloru w linii
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.
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ą :)
... 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ź
atari.area forum » Programowanie - 8 bit » Rapidus - zmiana koloru w linii
Wygenerowano w 0.029 sekund, wykonano 72 zapytań