Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
STOS BASIC V5.5 Alpha Popularny język programowania dla Atari ST powraca po ponad 30 latach w nowoczesnej wersji.
Command & Conquer na Atari ST Kultowy RTS Command & Conquer zmierza na Atari ST. Zobacz niesamowity port legendarnej strategii.
Altirra 4.50 test 13 Avery Lee udostępnił kolejną wersję testową najdoskonalszego emulatora Atari.
CT60 TOS 1.03e Po blisko 21 latach ukazała się oficjalna aktualizacja CT60 TOS do wersji 1.03e.
Gearlynx 1.2.14 Ukazała się kolejna odsłona zaawansowanego emulatora Gearlynx dla konsoli Atari Lynx.
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.097 sekund, wykonano 19 zapytań