Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Fujisan 1.1.3 Fujisan 1.1.3 to nowa odsłona emulatora opartego na libatari800, skupiona na integracji z FujiNet.
Śnieżna planeta w Cosmic Hero 2 Zelax prezentuje postępy nad kontynuacją klasyka. Zobacz mroźną planetę w Cosmic Hero 2.
ABBUC Creative Contest 2026 Poznaj zasady nowej edycji konkursu ABBUC Creative Contest dla twórców związanych z 8-bitowym Atari.
Gearlynx 1.0.0 Pierwsza stabilna wersja wieloplatformowego emulatora Atari Lynx o nazwie Gearlynx trafiła do sieci.
Jubileuszowy 25. odcinek kursu Larka Arkadiusz Lubaszka kontynuuje swoją serię poradników, publikując 25. lekcję programowania gier.
atari.area forum » Posty przez mono
mono napisał/a:1. PDVREG to nie jest żaden rejestr
PDVREG to jest rejestr... :/ rozwin sobie ten skrot chociazby... a zreszta... czy cos zmienia to co napisales w temacie ktory poruszamy?
Rejestr czyli spis, wykaz, lista :)
@xxl: Cieszę się, że to latach negowania ND zacząłeś się uczyć do czego to w ogóle w Atari jest i jak działa.
Nie bardzo rozumiem Twoje obiekcje, bo:
1. PDVREG to nie jest żaden rejestr - kiedy CPU zapisuje pod ten adres każde ND sprawdza na magistrali danych stan odpowiadającego mu bitu i się aktywuje bądź nie - urządzenie w sobie ma odpowiednią elektronikę w której zapamiętuje swój stan i udostępnia lub nie swoje rzeczy w przestrzeni adresowej komputera używając sygnałów PBI.
2. PDVINT to nie jest żaden rejestr - kiedy cokolwiek czyta z tego adresu każde urządzenie wystawia status IRQ (o ile w ogóle urządzenie obsługuje IRQ) na odpowiadającym mu bicie magistrali danych.
3. ND nigdy nie aktywuje i nie dezaktywuje się samo z siebie - ZAWSZE robi to programista - czy to będziesz Ty czy OS to nie ma znaczenia.
4. Interakcja OS-a z ND następuje przy:
- RESET - wtedy OS przeprowadza detekcję urządzeń na magistrali i zapisuje sobie maskę PDVMSK żeby potem wiedzieć które urządzenia są obecne a które nie, po czym wywołuje procedurę inicjalizacyjną ND która to ustawia rejestry OS np. informując w PINTMSK czy obsługiwane są przerwania,
- SIO - wtedy OS zanim zabierze się za magistralę SIO odpytuje każde istniejące ND czy przypadkiem nie zajmuje się obsługą danego DEVID, dopiero kiedy żadne z ND się danym urządzeniem nie zajmuje odbywa się komunikacja przez SIO.
- IRQ - OS najpierw sprawdza czy nie nastąpił odczyt z SIO (jako że jest to operacja najbardziej krytyczna czasowo), następnie testuje czy któreś ND nie zgłosiło przerwania, w dalszej kolejności dopiero idzie reszta. Przy inicjalizacji ND ustawia maskę przerwań wskazując OS-owi czy obsługuje przerwania - OS uwzględnia ją czytając PDVINT bo na bitach magistrali danych nie dopowiadających jakiemukolwiek urządzeniu, albo kiedy urządzenie nie obsługuje przerwań są stany nieustalone.
5. Poza elektroniką obsługującą interakcje z Atari ND może mieć elektronikę która coś robi i działa całkowicie niezależnie od tego co się dzieje w Atari, stąd ND może zgłaszać IRQ, albo grać coś przez linię AUDIO. Szkoda, że nie może generować obrazu, ale co zrobić :/
Tak więc jeśli nie korzystasz z OS-a to wszystko leży w Twoich rękach.
W odnośnikach zewnętrznych http://atariki.krap.pl/index.php/PBI znajdziesz trochę informacji.
Polecam również link w http://atariki.krap.pl/index.php/ROM_PBI str. 32.
Edit: PDVINT a nie PDVSTAT.
Takich rzeczy jest więcej, np. olewanie ZLOADA przy ładowaniu sterowników relokowalnych przez ACX.
Pytanie jeden kieruj do Autorów rozwiązań hardware'owych.
Pytanie dwa - na szynie są wszystkie odpowiednie sygnały żeby skanować operacje realizowane przez cokolwiek na całej pamięci.
@xxl: Zwróć uwagę, że Rapidus i U1MB w tym wykazie nie są ani urządzeniami CIO ani SIO.
Przyjacielu. ND nie musi być urządzeniem CIO.
Ładnie brzmi i wygląda. To jest tylko AY czy do spółki z POKEY-em?
DOS nie jest problemem, ponieważ można sobie napisać sterownik SIO obsługujący taki rodzaj transmisji. Mowa o Sparcie, bo pozostałe DOS-y nie dają takiej możliwości.
Co do komunikacji bez filesystemu - to też w SDX jest już zrobione, bo od chyba przeszło 10 lat jest sterownik do protokołu DOS2DOS nazywający się PCLINK.SYS i służy do komunikacji z pecetem (AspeQt i Altirra potrafią tak gadać). Wystarczy więc zaimplementować obsługę we własnym urządzeniu i wszystko będzie od ręki działać. Nie wiem czy autor FujiNET-a o tym wie...
Proponowałem Ci zresztą obsługę tego protokołu w WiFiPrime, ale nie znalazł był Ci on Twojego uznania.
Ale o co Ci chodzi?
na niemodyfikowanym romie pojdzie bez problemu
Hmmm
; SeND ENaBLe
;
; * = $EC17
;
LDA #%00000111
AND SKCTLS
ORA #%00100000 ;odczyt i zapis wg AUDF4
...
STA SKCTLS
STA SKCTL
...
;RECeiVe ENable
;
*= $EC40
;
LDA #%00000111
AND SKCTLS
ORA #%00010000 ;odczyt wg AUDF4, zapis wg CLOCK IN
STA SKCTLS
STA SKCTL
...jak sobie to wyobrażasz?
Edit: Szczerze bym się cieszył gdyby bez modyfikacji ROM-u można było komunikować się z dyskietką przez SIO bez użycia generatorów POKEY-a, ale póki co tylko NewDevice potrafi obsługiwać komunikację SIO własnymi procedurami. Z SIO można załadować własny handler do obsługi urządzenia, ale on nie przechwyci obsługi urządzenia SIO o numerze $3x.
Pięknie! Gdyby jeszcze taka komunikacja po SIO poszła na niemodyfikowanym ROM-ie...
Łatwiej kijek obcienkować niż go potem pogrubasić.
@Sikor: Oczywiście że jest lepszy DOS niż MyDOS - Sparta DOS 3.x Haaaaaa! Szach-mat.
Edit: Przypomnę jeszcze pewien link: http://www.atari.org.pl/forum/viewtopic.php?id=17136 bo potem będziesz płakał, że nikomu się nie chciało, a sam nawet się nie postarałeś o to żeby przypiąć topik. Prędzej, widzę, przypiąłbyś topik z bzdurną ankietą i gównoburzami.
@zbyti: ++ :) Jak to leciało o tej krowie...? :)
Edit: Zapodam Wam może linka do wspomnianego wątku - o tu jest: http://www.atari.org.pl/forum/viewtopic.php?id=17136
@Sikor: No jak to? Jest przecież :)
Tak'em myślał! Wielkie dzięki!
Jaka jest poprawna sekwencja:
1. odczytu wartości rejestru GRACTL oraz
2. zapisu wartości rejestru GRACTL
Sophii 2.
Pytanie właściwie ma na celu ustalenie kiedy następuje przełączenie okna rejestrów Sophii i zapis wartości do rejestru (i do którego). Nie mamy możliwości zapisu/odczytu pojedynczego bitu...
No to zostało już ustalone, że nie można. Zomo powinno go spałować i wysłać na syberię na dożywotnią katorgę, bo zagraża wszystkim dokoła i przez niego wszyscy będą do końca życia siedzieć w domu ze szmatą na ryju (a gdyby nie on to już dawno byśmy wrócili do dawnego trybu życia). Powinien być natychmiast osadzony w miejscu odosobnienia, a najlepiej skazany na krzesło elektryczne, powieszenie, utopienie, rozstrzelanie, kurhan, orchidee, na plasterki, infamię i dożywotnią banicję do czwartego pokolenia po uprzednim obowiązkowym złożeniu samokrytyki oraz czynnego żalu w formie pisemnej pod rygorem nieważności i mocnym postanowieniu poprawy na urzędowym formularzu w pięciu kopiach i ze znaczkiem skarbowym.
mozesz wystawic gdzies taka binarke pod windows?
Nie ponieważ tego nie używam.
@Krótki: Wymiana postów odbyła się w lipcu 2018 i nie jest to żadna tajemnica: https://sourceforge.net/p/atari800/mail … nth=201807. Na tym się właściwie rzecz zakończyła, więc nie drążyłem dalej tematu.
W międzyczasie dodałem jeszcze PSG i OPL2/3 i support dla kart Melody, SONari, YAMari, SIDari i Evie, a ostatnio też support do RAMCART-a (i ogólnie zmiany dla cartridgy zapisywalnych). Obecnie pracuję nad supportem dla PokeyMAX-a i SoundBoard-a.
Być może, ale chyba głównym priorytetem zespołu od Atari800 jest utrzymywanie emulatora możliwie prostym i szybkim tak aby mógł pracować na słabszych maszynach (np. Atari Falcon). Być może z tego powodu nie podobają się im moje poprawki. Nie mam zresztą do nich pretensji, bo moim celem jest mieć w ogóle daną rzecz w emulatorze (gdyż używam go do pisania programów dla Atari) a kompletnie nie koncentruję się na tym czy to jest szybkie czy nie.
Póki co konfigurację emulatora pod kątem używanych bibliotek przeprowadza się podczas kompilacji włączając różne fjuczery - dla moich rozszerzeń są to --enable-sid_emulation, --enable-psg_emulation i --enable-opl3_emulation.
Ponieważ nie każda rzecz którą ktoś sobie wydłubie musi zaraz zyskać akceptację zespołu trzymającego pieczę nad projektem i dbającego o koszerność :)
Pamiętam, że kiedy proponowałem im support do SlightSID-a to pytali mnie co SID ma wspólnego z Atari (przy czym w TODO stało jak byk: "SID implementation"). Z drugiej strony obsługą RAMCART-a są zainteresowani... Takie ich zbójeckie prawo :)
Możliwe, że nie lubią wykorzystywać obcych bibliotek a SID, AY i OPL bazuje jednak na pracy osób trzecich.
Tutaj masz repozytorium i opis kompilacji: http://www.atari.org.pl/forum/viewtopic … 26#p258626
Pamiętaj, że moja strona jest teraz w domenie i-demo.pl :)
atari.area forum » Posty przez mono
Wygenerowano w 0.106 sekund, wykonano 20 zapytań