"(...) Błąd ten polega na gubieniu niektórych zgłoszeń przerwań NMI gdy pojawiaja sie jednocześnie zgłoszenia IRQ." - ktokolwiek słyszał, ktokolwiek wie?

Zgłoszenie IRQ przez POKEYa trwa dopóki się go nie wyczyści w IRQEN, więc nie widzę, w jaki sposób mogłoby być gubione.

No ja slyszalem jak to by sie niby mialo odbywac, ale tez slyszalem tylko o odwrotnej sytuacji
czyli podczas poczatku obslugi przerwania IRQ wcina sie NMI i podobno wektor jest gubiony
(tzn. wykonuje sie przerwanie to co przyjal ale przez wektor NMI nie jest zapamietywane ze bylo tez IRQ). Podobnie mialo niby byc z NMI jak przyjdzie IRQ w trakcie piewszych o ile pamietam dobrze 4 cykli czy cus obslugi NMI. Natomiast nie wiem jak to mialo by wygladac bo chyba
zaczyna sie od ustawienia flagi I ? To nie wiem jak by wtedy mialo byc wywlolane IRQ skoro
jest blokada na maskowalne ? ...

(EDIT) Ano glupoty gadam, przeciez na stos sa wystawiane flagi BEZ ustawionego I,
wiec jednak jest jakis odstep czasowy zanim wstawi procek dane na stos
i ustawi I=1 wiec jezeli w tym czasie dojdzie zadanie IRQ to w zasadzie...
moglo by byc NMI zgubione.

Ostatnio edytowany przez Sc0rpi0 (2006-04-14 15:38:08)

Sc0rpi0: HINT: jak będziesz pisał po polsku, to więcej ludzi cię zrozumie. ;]

epi: HINT2: zeby zrozumiec trzeba czytac ze zrozumieniem :P
a żeby jeszcze bardziej zamotać chodziło o:
przerywanie procedury obsługi przerwania NMI
w poczatkowej fazie przez żądanie przerwania IRQ :) :P :)

Tak więc nie nęć przynęty przynętą gdy
przynęta przynętę przynentą nęci...  :P

calość - rewelka; lecz jedno (duże) zastrzeżenie. Nie wiem, jak to sie dzieje, lecz pomimo, że IK+ wstaje na Sparta DOS X (banked), to cala grafa "siedzaca" w ext ramie objawia się w postaci kaszaneczki. Zreszta tak samo jak w TEKBLAST. Dokladnie tak samo :). Zaznaczam, ze dokonalem poprawnego wyboru bankow dla SDX tak, by nie pogryzlo sie to z grą. No chyba, że IK+ po uruchomieniu i wykryciu czegos wiecej niż Atari 130XE siedzi w innych niż "oficjalny" standart (130) bankach.

... no chyba, ze problem polega na czyms innym :rolleyes:

Toż doskonale o tym wiem - tak jest stwierdzone oficjalnie ze procesor kończy
bieżącą instrukcję. Tylko w takim razie wytlumacz na przykład czemu BRK się
nie wykonuje do końca jak przyjdzie NMI w tym czasie tylko skacze pod wektor NMI
i jednocześnie ustawia flagą B ? Skoro jest taki bug to może warto sprawdzić i inne ?
To nie moje rewelacje po prostu kiedyś czytałem o tym i też nie wiem czy to prawda.
Z tekstu który wtedy na sieci znalazłem wynikało ze właśnie może się zdarzyć
na początku obsługi przerwania NMI ze IRQ je "wywlaszczy" choc niby nie powinno.

Nigdy nic podobnego nie twierdzilem :) mowilem o mozliwosci zgubienia NMI
przez IRQ, ktore przyszlo zaraz po starcie obslugi tego pierwszego. A NMI
że się tłumaczy Non Maskable Interrupt to też wiadomo.

Może po prostu błąd logiczny przy sprawdzaniu - zrobił pewnie jakieś JMP * :) i procek
kazde przerwanie tak wykonywal to sie wydawalo, że następnych nie wywoluje. Albo żartowal.

W ogole dziwnie to odbieram - sam sie pytałeś "(...) Błąd ten polega na gubieniu niektórych zgłoszeń przerwań NMI gdy pojawiaja sie jednocześnie zgłoszenia IRQ." - ktokolwiek słyszał, ktokolwiek wie?", a gdy mowie co SLYSZALEM czy też CZYTALEM na sieci to sie rzucacie
jakbym to ja zaczal ten temat w ogóle wałkować. Podałem TEORIĘ, że MOŻE w czasie
obslugiwania NMI w trakcie wstawiania na stos flag i adresu powrotu procek nie ustawil
jeszcze I=1 i jezeli w tym krótkim okresie czasu przylezie żądanie IRQ to właśnie coś
takiego sie może stać. Może się wam wydawać idiotyczna, bo oficjalnie jest tak
że niby coś takiego nie ma prawa bytu, ale bugi się zdarzały i zdarzać mogą. Nastepnym
razem zamiast pytac czy ktos slyszal to google skoro chcesz poglosek a jednoczesnie
nie chcesz...  Np:

(znalesc dot. 6502)
czy tez tutaj lub tu

Jakoś nie mogę znaleźć tego artykułu który wtedy czytałem, a szkoda, bo tam było
trochę więcej napisane ogólnie na temat przerwań i związanych z tym bugów w 6502.

tebe: wątpię, czy Ci się to opłaci, ze względu na konieczność odświeżania POKEYa na każdym przerwaniu, co kosztuje dużo czasu w stosunku do czasu trwania jednej linii. Mnie się udała wersja minimalna (wystarczy jedno DEC ^2E), ale działa tylko w szczególnych warunkach. W sumie 14 cykli na start i powrót z przerwania, 6 cykli na DEC, 5 na przechowanie i odtworzenie akumulatora, to już 25 cykli, więc w pustej linii poza obrazem zostaje ci 80, oczywiście pod warunkiem, że przerwanie jest uruchamiane przez wektor sprzętowy ($FFFE)!

Jeśli chodzi o inicjalizację, to poniższy fragment powinien działać, jeśli oczywiście niczego nie pominąłem przy kopiowaniu, bo było dość porozrzucane:

        sei
        lda     #0
        sta     ^21
        sta     ^29
        sta     ^2e
        mva     #%01000000      ^28
        mva     #period ^20
        mwa     #IRQ     $fffe
        mva     #1      ^2e
        cli

Zegar POKEYa jest tu przestawiany na częstotliwość ZTCW tę samą, co CPU, więc jeżeli właściwy okres licznika to wartość "period"+1, powinno być 113, żeby szło co linię. Nie testowałem, więc mówię - nie bić, jeśli się mylę.

No i oczywiście brakuje tutaj stworzenia pewnych specyficznych warunków, o których była mowa powyżej, ale tu muszę się przyznać, że nie wiem dokładnie w jaki sposób należy tego dokonać. :P Skutecznie natomiast robi to SIO, próbując dostać się do urządzenia, które nie odpowiada. ;)

Proponuję jeszcze przenieść ten wątek do fabryki, programowania, gier... W każdym razie robi się tu zbyt poważnie, jak na bałagan. ;)

To jest jasne jak słońce (6502 w odpowiedzi na każde przerwanie ustawia flagę I i jest to fakt powszechnie znany), ale napisałeś poprzednio coś odwrotnego: że początek obsługi IRQ powoduje, iż nie będzie przyjmowane NMI, przez co foxowi oczy zrobiły się jak spodki :P

Chłopaki !! :)
Ludzie !!!
Co Wy robicie ??!!
Chcecie chyba abym popadł w jakieś kompleksy !
Czytając Was dochodzę do wniosku że już nic nie pamiętam ;-(
... chyba będę musiał sobie na dole wywalić te "800XL" :-P

pzdr. :-)

114 cykli. Czyli jak używasz 8-bit 1.77 to AUDF na 110. A prościej włączyć 15 kHz, czyli dzielnik 114 i wtedy AUDF=0 to co skanlinię. Bardzo dawno temu to sprawdzałem i synchronizacja z obrazem była idealna. Ale tak jak napisał Epi, raczej na tym nie zarobisz.

Jeśli pogrubione przez Ciebie fragmenty wyjaśniają gubienie przerwań, to rzeczywiście mam coś z oczami.
Odwlekanie IRQ przez inne przerwanie (czy to NMI, czy IRQ), które ustawiło I to nic specjalnego. Chodzi o to, w jakiej sytuacji przerwanie może się zgubić?

MW: a bana chce?