Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Nowy firmware 1.5 dla SDrive-MAX Ulepszony tryb szybki i poprawki kaset w nowej wersji firmware
Ice-T 2.8.2 Nowa wersja Ice-T dla 8-bitowego Atari już dostępna - poprawki i nowe funkcje
Galactic Panic - nowa przygodówka na ST Darmowa gra point and click na Atari ST - ponad 100 ekranów przygody.
Nowa wersja ARIFE Tool od PVBest73 Uaktualniono uniwersalne narzędzie do analizy obrazów ROM i dysków Atari
Echa Sommarhack 2025 Podczas szwedzkiego party Sommarhack zaprezentowano kilkadziesiąt produkcji,
atari.area forum » Posty przez mono
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.
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 wynikuNie 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+33po 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.asxpo czym efekt kompiluję madsem
$ mads -l -t -o:plik.obx plik.tmpOczywiście możesz definiować dowolne makra preprocessora i ich używać, włączać pliki za pomocą #include i takie tam.
4 i w dodatku STEREO!
Na małym Atari jest to jeden z utworów demonstracyjnych w Future Composer - nazywa się RUNNER.FC.
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.
Stan "po spożyciu".
@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 atari800Zamiast 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.diffPo 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 atari800Zamiast 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.diffPo 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).
Brakuje opcji: "Lepszy".
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?
A co to za typ? :>
A czy byłoby rozsądne wykorzystanie dźwięku transmisji i/o, który przecież i tak jest wyprowadzony na audio out i ładowanie sektor po sektorze w standardowej 19200? Basic co prawda nie ma komunikacji z sio, ale programik asm w ciągu tekstowym byłby krótki i szybki.
Zrobiłem małe konwertery dwóch formatów obrazków z Atari Portfolio:
* PGF - pgf2ghg.sh
* PGC - pgc2ghg.sh
do formatu GHG używanego przez program Graph8.
Obydwa używa się podobnie:
$ ./pgf2ghg.sh < plik.pgf > plik.ghg
$ ./pgc2ghg.sh < plik.pgc > plik.ghgPodanie dowolnego parametru pokazuje sposób użycia.
atari.area forum » Posty przez mono
Wygenerowano w 0.090 sekund, wykonano 14 zapytań