nie wiem czy to jest blad, jesli p.1 jest prawda to wlasnie takiego zachowania bym oczekiwal (nie wykonanie sie NMI) chyba ze chodzi o niefortunna nazwe "niemaskowalne" ;-) np. 'kolejkowanie' irq jeszcze bym zrozumial (jesli tak jest - p.9) ale odpalenie nmi poniewczasie juz zupelnie nie.

Na niektóre pytania odpowiedzi są w Resjestry POKEY-a oraz w dokumentacji
9. Wszystkie bity w IRQST poza 3. (XMTDONE) są zatrzaskowe. Tylko skasowanie danego bitu IRQEN powoduje zresetowanie odpowiedniego bitu w IRQST (poza bitem XMTDONE).
10. Tak, ale wyjątkiem znowu jest bit XMTDONE - nawet gdy przerwanie jest zablokowane, jego wartość może zostać przez POKEY zmieniona.

W 65C02 i następnych zostało to poprawione, zatem wg twórców był to błąd.

Nie wiem, cytowałem Atariki.

Właściwie to jest ciekawa sprawa. W żadnej dostępnej literaturze nie ma informacji o tym, że w 6502 IRQ ma prioryter nad NMI - co więcej, źródła twierdzą coś wprost przeciwnego. Np. 6502.org:

Note also that if an NMI and an IRQ hit at the same time, the NMI has the higher priority and will get serviced first.

W dyskusji na AtariAge mówili, że nie jest to problem samego procesora, tylko specyficznej architektury Atari, i że nie występuje on w innych komputerach używających 6502. Być może powodem ignorowania NMI przez procesor jest fakt, że ANTIC umie zatrzymać zegar CPU.

Więc może informacje w Atariki są nieścisłe.

EDIT: A wystarczyło doczytać do końca :) Faktycznie chodzi o to, że jeśli CPU już zaczyna obsługiwać IRQ i w tym momencie na nóżkę NMI procesora przyjdzie sygnał, i jeśli dodatkowo sygnał ten jest krótszy niż 3 cykle, to przerwanie NMI zostanie zignorowane. Natomiast wszystko będzie dobrze jeśli sygnał NMI będzie dłuższy.

Tyle że w przypadku Atari, ANTIC ustawia linię NMI tylko na 2 cykle. Co więcej, podobno stara dokumentacja do 6502 mówi, że minimalny czas trwania sygnału NMI to właśnie 2 cykle. Można więc powiedzieć, że błąd jest nie tyle w procesorze, co w dokumentacji :)

A ponieważ 65C02 jest procesorem CMOS o zupełnie innej konstrukcji, to problem został w tym procku rozwiązany może nawet nieświadomie.

taka wiedza moze sie przydac nie tylko mnie

Tak, dokładnie. Z tym, że cała sztuczka jest, powiedziałbym, nietrywialna i wymaga porządnego opisu, na który trzeba czasu. Kiedyś postaram się to zrobić. Póki co mogę podesłać kod, gdyby ktoś potrzebował pilnie.

Tak bym zrobił. Tylko tego pierwszego pha chyba nie powinno być. Jeśli DLI nie jest krytyczne czasowo, to od razu zrobiłbym STA NMIRES.

@xxl: Niestety reset NMI jest konieczny przy paczowaniu IRQ.
Dlaczego?
Założenie projektantów OSa było (domyślam się) takie: DLI jest krytyczne czasowo, więc nie robimy tu niczego zbędnego - widać to po tym, że nie robią nawet PHA a przechodzą do DLI najszybciej jak się da. Ponieważ w XL/XE (nie wiem, jak to wygląda w 400/800) przerwania NMI są tylko 2, to nawet jak wystąpi DLI i status w NMIST po jego obsłudze zostanie w rejestrze, to nic się nie stanie, bo następnym przerwaniem NMI będzie i tak tylko kolejne DLI. Aż do momentu wystąpienia VBLK, bo najwyraźniej przy jego wystąpieniu NMIST.7 jest kasowany i dlatego systemowa procedura VBLK ma szansę się wykonać.
Jeśli natomiast po (albo równocześnie z) DLI wystąpi IRQ to bez skasowania NMIST obsługa przerwania IRQ zawsze przejdzie do obsługi DLI i nigdy nie wykona właściwego IRQ.
Dlaczego uważam, że powinien to robić user implementujący DLI? Ponieważ mamy jeden wektor VDLST, który używa NMI i IRQ a obsługa przerwania powinna być IMHO spójna. STx nie zmieniają znaczników więc można to robić tuż przed RTI po zakończeniu krytycznych czasowo rzeczy. Byłaby to więc dobra praktyka pozwalająca działać programowi zarówno w standardowym, jak i spaczowanym środowisku.

Edit: I tak takie DLI opóźnione jest o 7 cykli (CLD+JMP ind), chyba że podpinamy się pod wektor IRQVEC zamiast VIMIRQ, ale wtedy trzeba by zrobić jeszcze CLD przed SVS.

@0xf: Racja - poprawione.

A nie wynika to z tego, że przerwanie jest przyjmowane po zakończeniu bieżącego cyklu rozkazowego więc mając np LDA NMIST i NMI, które wystąpi po prefetchu a przed 4 cyklem rozkazu w A dostaniemy info o NMI?

Ha! (za https://atariwiki.org/wiki/Wiki.jsp?pag … %20Listing ):

;
; NMI HANDLER
;
; DETERMINE CAUSE AND JUMP THRU VECTOR
;
PNMI:    BIT      NMIST
          BPL      PNMI1         ;SEE IF DISPLAY LIST
          JMP      (VDSLST)
PNMI1:  PHA
          LDA      NMIST
          AND      #$20          ;SEE IF RESET
          BEQ      *+5
          JMP      WARMSV        ;DO THRU WARM START JUMP
          TXA                      ;SAVE REGISTERS
          PHA
          TYA
          PHA
          STA      NMIRES        ;RESET INTERRUPT STATUS
          JMP      (VVBLKI)     ;JUMP THRU VECTOR

W XL/XE oczywiście dodano CLD  i usunięto test NMIST.5.

jmi/jvc - nie wiedziałem, że tak można :) Ale wygląda ładnie.

CLD sobie trzeba dodać przed obsługą IRQ, bo SIO liczy np. sumę kontrolną.

Z moich testów wynika, że nie ma jak wykryć wykonania BRK kiedy wraz z nim wystąpiło jakiekolwiek przerwanie sprzętowe (nie może być jak IRQ odroczone). Chciałbym się bardzo pomylić w tej kwestii, bo podoba mi się wołanie funkcji systemowych za pomocą BRK #fn.

Jump if MInus: bmi albo jeśli za daleko to spl + jmp; analogicznie Jump if V Clear.

Edit: No i BRK wykona się przy zapalonym I.

@mono: zobacz "Edit 2" z posta 16.

Rozwijając wypowiedź: przerwanie transmisji SIO aktualizuje sumę kontrolną używając ADC, więc D=1 robi kuku. Z drugiej strony, czy ktoś robi SED w czasie transmisji SIO?

Nie było mowy o tym, gdzie wpinamy poprawione IRQ. Być może pod wektor systemowy, więc OS zrobił już za nas CLD.
Nie pamiętam natomiast, gdzie powinno być CLD dla VBLKI.

Co do BRK, to nie jest czasem tak, że jak wykona się razem z IRQ lub NMI, to jednak znacznik B na stosie jest ustawiony i trzeba go sprawdzić na początku w przypadku IRQ oraz sprawdzić w ogóle w przypadku NMI.

Rozwijając wypowiedź: to pseudorozkazy xasm (ale widziałem je też w innym asemblerze, chyba ca65), np.

 jmi target

to

 bpl skip
 jmp target
skip

Edit:

Tak jest.

Nie używam BRK w produkcyjnym kodzie. :)

> Rozwijając wypowiedź: przerwanie transmisji SIO aktualizuje sumę kontrolną używając ADC, więc D=1 robi kuku. Z drugiej strony, czy ktoś robi SED w czasie transmisji SIO?

ale mozna sobie wyobrazic procedure IRQ np. timera1 ktora bedzie uzywala przykladowo ADC - nie przypominam sobie, zeby jakakolwiek procedura obslugi przerwania IRQ usera miala rozkaz CLD

> Nie używam BRK w produkcyjnym kodzie.

w przypadku gdy jednoczesnie wystapi IRQ i BRK to bit B stanu procesora na stosie jest ustawiony czy skasowany?