I was just wondering if anybody's found any other game where this functionality makes a difference, or else I'll just omit it.
Perhaps someone doesn't have this problem at all with Laser Invasion?

/Martin

Author:

Hyde [ Thu Nov 04, 2004 4:33 pm ]

Post subject:

Re: NMIs triggered inside VBlank

Nessie wrote:

I recently added a little thing to my emu:

Not so little when it comes to games such as Dynamite Bowl and Spelunker (probably lots of others too). If these two games work fine on your emulator then I don't know what could be the problem (perhaps the fact that the game uses MMC5 has to do something with it).

Author:

Nessie [ Thu Nov 04, 2004 4:56 pm ]

Post subject:

Hmm, they both work, regardless of the NMI thing. Where are they supposed to glitch?
Did you get Laser Invasion to work with this NMI thing?

Author:

Quietust [ Thu Nov 04, 2004 6:15 pm ]

Post subject:

I use said 'NMI thing' in my emulator, and Laser Invasion works perfectly.

Author:

Nessie [ Thu Nov 04, 2004 8:13 pm ]

Post subject:

Ok, thanks. I guess it's my MMC5 code then. Probably the IRQs... - $5204.7 is set on the scanline ($5203) if rendering is enabled.
- If IRQs are enabled, an IRQ is also triggered.
- Both the bit and the pending IRQ are cleared when reading $5204.
- Are they cleared under any other condition? I tried clearing them on scanline 240, without luck.

Or else i'll just ignore that 'NMI thing' and hope most games work anyway

Author:

Bregalad [ Sat Nov 13, 2004 1:23 pm ]

Post subject:

Try to clear both $5204.7 and the IRQ if the scanline ($5203)+1 is reatched without clearing it by reading.

Author:

Disch [ Thu Mar 10, 2005 8:47 pm ]

Post subject:

I know I'm bumping a very old topic with this... but I've recently been running into problems with this implimentation.

Not with Laser Invasion... but with Eggerland, and Adventures of Lolo 2 & 3.. causing hangups in all 3 games. I've been looking at Eggerland, specifically... and it seems to do a large drawing routine in when rendering is turned off, during which times it enables, then shortly after disables NMIs (without waiting for NMIs). It does it several times in the frame, spilling into next frame's VBlank, where enabling NMIs triggers an NMI... which screws the whole thing up -- it eventually goes in a wait-for-NMI infinite loop without NMIs enabled (locking up the game)

Is there some sort of delay between the $2000 write and the following NMI? Or does it happen immediately? Did anyone else have these problems with these games? Any ideas?

Author:

Hyde [ Thu Mar 10, 2005 9:40 pm ]

Post subject:

Try triggering the NMI right after the instruction that follows sta $xxxx or whatever. Like so:

sta $2000
(some instruction)
jsr 8000; trigger the NMI right before this occurs

Author:

Disch [ Thu Mar 10, 2005 9:45 pm ]

Post subject:

I thought about doing that -- from what I looked at Eggerland's code it looks like it would solve its problem. However that seems awfully hackish....

edit: I guess -- if there's a short delay between the start of VBlank and an NMI... perhaps it does make sense that there's a delay between the $2000 write and an NMI.

Author:

Quietust [ Thu Mar 10, 2005 9:57 pm ]

Post subject:

Hyde wrote:

Try triggering the NMI right after the instruction that follows sta $xxxx or whatever. Like so:

sta $2000(some instruction)jsr 8000; trigger the NMI right before this occurs

This is exactly what should be done - a small test I wrote verifies this behaviour on a real NES.