Przejdź do treści forum
atari.area
Twoje polskie źródło informacji o Atari
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Aktualności ze świata Atari
Gearlynx 1.2.24 Ukazała się kolejna aktualizacja emulatora Gearlynx, oferująca poprawione wsparcie dla ComLynx i liczne poprawki błędów.
NRG 2026: 11 kategorii i 33 statuetki Znamy kategorie konkursowe NRG 2026. Na zwycięzców czekają szklane statuetki i atrakcyjne nagrody.
W.I.P. demo C.E.T.A.S Wersja robocza gry C.E.T.A.S jest już dostępna do pobrania na naszym forum.
RastaConverter 1.0 RC12 Nowa wersja konwertera grafiki dla 8-bitowego Atari z wieloma poprawkami i samodzielnymi pakietami.
NeoST 0.5.2 Poznaj NeoST, wszechstronny emulator Atari ST działający w przeglądarce oraz na systemach desktopowych.
Opcje wyszukiwania (Strona 88 z 123)
Nie cośtam, tylko chiptunes.
xxl napisał/a:Moze chodzilo o to, zeby w ktoryms z obszarow karta mozna bylo uzywac rozkazow ktore generuja podwojny odczyt
Dokładnie o to mi chodziło.
Można też sobie wyobrazić, że z wyniku obliczeń trzeba będzie korzystać wielokrotnie, co zwolni programistę od buforowania wyniku w ramie.
nosty napisał/a:Brak dekodowania adresow wymusza dyscyplinę u programisty Atari. Musi on trzymac sie protokołów
komunikacji. Nie moze nastapic zaden przypadkowy odczyt ze strony $D5xx bo urzadzenia sie rozsynchronizują.
Ale to sie sprawdza. Te animacje z dema zostawilem kiedys wlaczoną na całą noc i rano w dalszym ciagu działała.
Co do wykorzystania rozkazow, ktore wykonuja np dwa odczyty to tak jak napisal Jell sam cartridge nie ma jak sie tego domyslec. Musialbys miec frimeware ktory "wie", o tym ze uzyjesz takich rozkazow.
A ja bym proponował inne rozwiązanie.
1. Obszar adresowany przez antic, jak wiadomo nie będzie wymagał żadnych cudów i można założyć, że podwójne odczyty się nie zdarzą. Można więc wydzielić obszar np. $d500..$d52f, w którym pojawiałaby się pamięć ekranu do odczytu przez antic.
2. Wszystkie procedury ułatwiające żywot programiście niech korzystają z osobnych komórek. Dzięki temu nie zmuszamy go do dyscypliny (i znajomości niuansów 6502), a dajemy możliwość korzystania z dowolnego trybu adresowania jaki mu w danej chwili się zamarzy. Twój kod do mnożenia wyglądałby tak:
lda #$40 ;rozkaz mnozenia
sta $D530
lda factorA
sta $D531
lda factorB
sta $D532
lda $D533 ;lsb wyniku
ldy $D534 ;msb wyniku
Nie ma niespodzianek.
Edit: adresy
Efekt porażający! Nosty - gdyby była wersja z możliwością flashowania romu tego microchipa, to byłoby świetnie - gry mógłbyś puszczać jak dotąd z dodatkowym wkładem dla pica tak, jak to jest w przypadku vbxe :)
Jeśli dobrze zrozumiałem, to urządzenie działa tak, że sekwencyjne odczyty z tych samych rejestrów (np. $d500) powodują otrzymywanie kolejnych danych (kolejne bajty wyniku w załączonym przez Ciebie przykładzie na mnożenie, lub też zawartość kolejnych linii ekranowych kiedy antic adresuje urządzenie). Czy Twoje rozwiązanie będzie poprawnie działać z trybem adresowania (zpg,x) ?
Edit: BTW ponieważ mnożenie (jak i dodawanie) jest przemienne, to nie ma czegoś takiego, jak mnożna i mnożnik, a są wyłącznie czynniki mnożenia (analogicznie dodajna, dodajnik - składniki).
drugi problem (przed takim blokiem wstawial automatycznie wczesniej zdefiniowany z parametrem...)
Zdefiniuj sobie makro np ORIGIN z parametrami, które przy generowaniu bloku przed nim wstawi ci co tam potrzebujesz, i zamiast ORG używaj ORIGIN.
@xxl: Zestaw sobie potok cpp && mads (zamiast cpp możesz oczywiście użyć jakiegokolwiek innego preprocessora makr jak m4 czy gpp).
Ja używam tego do definiowania odwołań względem symboli w czytelnej formie (np. COMFNAM = COMTAB+33) podczas pisania kodu pod SDX.
Wygląda to tak, że definiuję sobie np. rzeczony COMFNAM:
#define COMFNAM COMTAB+33
po czym w kodzie używam już nazwy COMFNAM zamiast COMTAB+33, które nic mi nie mówi.
Kompilacja przebiega dwustopniowo - najpierw z pliku .asx za pomocą preprocessora generuję plik do kompilacji madsem:
$ cpp -P -o plik.tmp plik.asx
po czym efekt kompiluję madsem
$ mads -l -t -o:plik.obx plik.tmp
Oczywiście możesz definiować dowolne makra preprocessora i ich używać, włączać pliki za pomocą #include i takie tam.
Na małym Atari jest to jeden z utworów demonstracyjnych w Future Composer - nazywa się RUNNER.FC.
YERZMYEY/HOOY-PROGRAM napisał/a:Albo najpewniej w pierwszej kopie pijusów wieczorami zgarnianych w sporych rozmiarów kopce. <ciach />
Też sobie znalazłeś towarzystwo. Wolisz obok Piusa XI czy może XII?
O przegapiłem grupowe zdjęcie :/
Wielkie dzięki dla organizatora i dla uczestników za super atmosferę. Wracam za rok :)
My powinniśmy być z Candlem,Electronem (jak bógda) i Yerzozwyerzem po południu w piątek.
Sarkofag sam wstąpi na Ciebie w stosownej chwili.
@syscall: Identyczny, jak przy wykrywaniu dowolnego rozszerzenia dla PORTB - testowany jest tylko obszar między $5000..$57ff. W zasadze to prosto pod tym kątem można by zmodyfikować procedurę wykrywania extramu. Jedyny ból że MapRAM jest dostępny kiedy masz OS wyłączony :/ no ale jeśli traktować to, jak pamięć RAM POD ROM...
http://drac030.krap.pl/APT_spec.pdf
Edit: I jeszcze zobacz co tu jest zrobione
Zrobiłem łatę na atari800, która dodaje support dla MapRAM.
1. Ściągamy z CVS źródła atari800
$ cvs -d:pserver:anonymous@atari800.cvs.sourceforge.net:/cvsroot/atari800 login
$ cvs -z3 -d:pserver:anonymous@atari800.cvs.sourceforge.net:/cvsroot/atari800 export -r HEAD atari800
Zamiast HEAD można podać datę np. 2012/07/14.
2. Ściągamy i aplikujemy łatę:
$ wget http://mono.atari.pl/atari800/atari800-20120713-mapram-patch.diff
$ patch -p0 <atari800-20120713-mapram-patch.diff
Po czym kompilujemy zgodnie z instrukcją.
To oczywiście wersja świeża więc mogą się pojawić bugi. Testowałem to z programami xxla (w załącznikach).
Bugs & requests mile widziane.
Jakiś czas temu zrobiłem mikrołatę na atari800, która pozwala na montowanie .atr'ów o rozmiarze sektora 512 bajtów.
1. Ściągamy z CVS źródła atari800
$ cvs -d:pserver:anonymous@atari800.cvs.sourceforge.net:/cvsroot/atari800 login
$ cvs -z3 -d:pserver:anonymous@atari800.cvs.sourceforge.net:/cvsroot/atari800 export -r HEAD atari800
Zamiast HEAD można podać datę np. 2012/07/14.
2. Ściągamy i aplikujemy łatę:
$ wget http://mono.atari.pl/atari800/atari800-20110928-512bps-patch.diff
$ patch -p0 <atari800-20110928-512bps-patch.diff
Po czym kompilujemy zgodnie z instrukcją.
Działam na tym już jakiś czas i wygląda na to, że działa.
Bugs & requests mile widziane.
To ja jeszcze się zapytam: dlaczego dostęp do pamięci podstawowej musi być uaktywniony naraz dla ANTICa i CPU? Czy nie ładniej byłoby używać tylko bitu 4 (dostęp do podstawowej dla CPU) tak, jak to jest w rozszerzeniach pamięci?
Wyobraźmy sobie, że mamy 130XE i ANTIC wyświetla nam obraz na podstawie danych z pamięci dodatkowej. Aby użyć pamięci spod I/O aktualnie musimy zmusić na chwilę ANTICa, żeby pokazywał jednak dane z podstawowej pamięci więc ANTIC pociągnie śmieci z podstawowej :/
MMU w Atari steruje pamięcią w obszarze $5000..$57ff tak:
b7 b0
0 0 - RAM podstawowy
1 0 - RAM podstawowy
0 1 - SELF TEST
1 1 - RAM podstawowy
W kombinacji 00 mógłby być podłączany RAM spod I/O (oczywiście zakładam b4=1 czyli dostęp CPU do pamięci podstawowej).
A do której pamięci będzie miał dostęp ANTIC, jak równocześnie z włączeniem mapramu w $5000..$57ff wybierzemy też bank pamięci w $4000..$7fff?
Znalezione posty [ 2,176 do 2,200 z 3,054 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 1.522 sekund, wykonano 1 zapytań