It is currently Mon Dec 18, 2017 1:46 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 28 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: NMI & IRQ
PostPosted: Fri Dec 28, 2007 8:23 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
- If both are pending to trigger, I'm allowing the NMI to trigger first, then the IRQ at the next instruction / byte fetch. Is this correct?

_________________
Zepper
RockNES developer


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 28, 2007 9:04 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Since NMI raises the I flag, the IRQ would not happen until I is cleared again (by CLI/RTI or whatever)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 28, 2007 9:17 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
- Yes.
- I don't remember of a test ROM for this behaviour though... does it exist?

_________________
Zepper
RockNES developer


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 28, 2007 10:57 am 
Offline

Joined: Wed Mar 22, 2006 8:00 am
Posts: 354
Some situations get a little tricky. For example, suppose an IRQ is pending, then during the first four cycles of the 7-cycle interrupt sequence an NMI occurs. The CPU will then continue the seven-cycle sequence (no new sequence begins), but it will jump to ($FFFA) as if the first interrupt were an NMI instead of an IRQ. If the NMI occurs during the fifth or sixth cycle of the seven-cycle sequence, a new seven-cycle sequence will begin immediately after the conclusion of the current sequence (with the value of PC pushed to the stack being the same asthe ($FFFE) vector). Finally, if the NMI comes during the last cycle, one instruction of the IRQ handler will execute before the NMI is processed.

A similar phenomenon exists if BRK is interrupted by NMI. If the NMI comes during the first four cycles of BRK, the CPU will treat the BRK as if it were the NMI and jump to ($FFFA). However, the B flag will still be set in the processor flags on the stack, and the return address on the stack will still point to the instruction after BRK (instead of pointing to the BRK). Thus, if a program used BRK and if there was a possibility of an NMI occurring during the BRK, that program would have to test for the B flag in both the NMI and IRQ handlers, since either of them could have the flag set.

_________________
"Last version was better," says Floyd. "More bugs. Bugs make game fun."


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 28, 2007 2:16 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
Test ROM: nmi_during_brk.zip

Result when run on NES:

NMI BRK X
$26 $36 $00
$26 $36 $00
$36 $00 $00
$36 $00 $00
$36 $00 $00
$36 $00 $00
$36 $00 $00
$26 $36 $00
$26 $36 $00

PASSED

Test has NMI occur one clock later on each successive row, such that it eventually suppresses the BRK (apparently there's a 5-clock window for this). First column is the processor status on the stack when the NMI occurs, second when BRK occurs (zero if it didn't occur), third should always be zero.

As you can see, when the BRK is suppressed, the B flag (bit 4) is set in the status during NMI.

(If I think of a way to test NMI during IRQ this cleanly, I'll code and post)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 28, 2007 3:03 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
blargg wrote:
(If I think of a way to test NMI during IRQ this cleanly, I'll code and post)


Could you use CPU triggered MMC3 IRQs? I thought you did something like that for some of your MMC3 IRQ test ROMs.

Also -- thanks! More test ROMs are always excellent.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 28, 2007 3:09 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19356
Location: NE Indiana, USA (NTSC)
Or you could do it once for MMC3 IRQs, once for DMC IRQs, and once for APU Frame IRQs, to catch emulator developers in the act of getting hacky with one IRQ source and not the others.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 28, 2007 3:12 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
APU Frame IRQs I could see -- but can you get that tight of timing on DMC IRQs?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 28, 2007 3:28 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
The main trick is getting an IRQ to occur at an arbitrary time, since the NMI timing can't be meaningfully changed (or maybe it could, if the enabling-mid-VBL-causes-immediate-NMI behavior were used).


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 28, 2007 3:31 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
that's why I thought MMC3 would work. You can trigger the IRQ any time with a $2007 read/write under the right conditions (which you can set up beforehand)

Using that would require minimal code changes from what you have now. Just replace the BRK with like a $2007 read, put some $2006 writes just prior to it and maybe adjust your wait time to accomidate.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 28, 2007 6:12 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
I'm unable to download that file, website seems down..?

_________________
Zepper
RockNES developer


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 30, 2007 4:48 am 
Offline

Joined: Sun Dec 30, 2007 4:42 am
Posts: 4
Inside the sync_nmi routine, I noticed that the beq instruction branches directly to cmp and not lda. Was this intentional? I seem to get stuck inside this loop on the very last test since the nmi flag hasn't been set at that point yet. Nice work nevertheless.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 30, 2007 10:43 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
FentonCole wrote:
Inside the sync_nmi routine, I noticed that the beq instruction branches directly to cmp and not lda. Was this intentional? I seem to get stuck inside this loop on the very last test since the nmi flag hasn't been set at that point yet. Nice work nevertheless.


Yes, same here... ^_^;; I'm doing a deep examination... but supposely, it's waiting for a NMI or IRQ to occur.

_________________
Zepper
RockNES developer


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 30, 2007 5:45 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
I finally got an NMI interrupting an IRQ at varying times: nmi_during_irq.zip

Sorry for terseness, I just don't have the energy to do more. I can answer questions.
Code:
; Critical test code
lda #0
clv
sec
; Z and C set, others clear

; NMI occurs here first,
lda   #1    ; clear Z flag
; then here for two clocks,
clc         ; clear C flag
; then here.

; IRQ always occurs here.
sec
...

; IRQ handler is the same except it saves into irq_flag
nmi:
    ...
    pla           ; save status byte from stack
    sta nmi_flag
    pha
    bit $4015     ; clear APU IRQ flag
    ...
    rti

Each row of the following table is for NMI occurring one clock later than the previous.

NMI IRQ
-----------------------------------------------------------
$23 $00  NMI occurs before LDA #1
$21 $00  NMI occurs after LDA #1 (Z flag clear)
$21 $00
$20 $00  NMI occurs after CLC, interrupting IRQ
$20 $00
$20 $00
$20 $00
$20 $00
$20 $00
$20 $00  Same result for 7 clocks before IRQ is vectored
$24 $20  IRQ occurs, then NMI occurs immediately after
$24 $20


Top
 Profile  
 
 Post subject:
PostPosted: Sun Dec 30, 2007 6:18 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
Man, I can't download from that server, for some reason... -_-;;

_________________
Zepper
RockNES developer


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: domlebo70, krzysiobal and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group