NMI service question

[drac030]

It is probably documented somewhere, but I cannot find the answer, so I though I would ask here.

 

It is said that after the NMI line goes low, the CPU cannot accept another NMI until the NMI line goes up and low again. So, assuming that there are glitches on the NMI line, so that after the initial, full pulse the line shortly goes high and then low again (uncontrollably or under external control, no matter), so that there are effectively multiple valid NMI pulses within the span of, say, 20-30 CPU clock cycles, then, after the CPU starts servicing the first NMI pulse of the series, when will be the earliest point (or time), in which it will be able to accept and start servicing another NMI?

 

I.e. immediately after loading the vectors to the PC, or perhaps after the first instruction of the handler?

 

[Rybags]

Good question.  I would assume the next valid point where an NMI could be accepted would be fairly early - the mechanism for NMI is near identical to IRQ and we have documented the interaction and interference that can occur there.

Of course the Atari only generates NMI at a specfic part of the scanline and also the "bug" in that the line isn't held low long enough resulting in occasional missed NMIs if an IRQ is coincident at the right time.

 

On the C64, retaining the NMI line low is actually performed by some games as (the only actual possible way) means of disabling the Restore key - which is functionally equivalent to System Reset on the 400/800 (though needing the user to hold Run/Stop as well to cause the warmstart)

 

There's multiple scenarios of NMI repetition and mixed IRQ/NMI that would do well to be properly documented though our machine by default wouldn't be able to recreate many of them.

Not sure if the C64 could either, I think their only NMI sources are the Restore key and one of the CIA's Timer interrupts (the other one only generating an IRQ) - and in any case the Timer NMI there needs CPU intervention to acknowledge and enable a subsequent one.   Unsure if relevant here but I seem to remember there being some trick they can use to speed up some interrupt acks by vectoring the service routine to hit the hardware, saving having to execute an instruction to do it.

Also there's a sometimes used trick to disable the Restore key by generating a timer NMI, then not clearing it so keeping the line low.

 

Though it's probably not documented, the common sense approach to NMIs would be that you don't have them more often than every 30-40 CPU cycles anyway since you'd have a high chance of stack wraparound and a crashed machine.

Edited September 23, 2020 by Rybags

[ivop]

1 hour ago, Rybags said:

Unsure if relevant here but I seem to remember there being some trick they can use to speed up some interrupt acks by vectoring the service routine to hit the hardware, saving having to execute an instruction to do it.

That sounds pretty neat! But how is the service routine valid 6502 code? Do you have an example?

 

 

[phaeron]

I believe that the 6502 will always execute the first instruction of the NMI handler before starting to handle the next one, based on IRQ/BRK testing. NMI handling should be similar as the 6502 uses common behavior to begin handling an interrupt and only later in the 7-cycle sequence actually decides which vector to use.

 

As for the earliest point where the internal NMI flag is cleared and can be retriggered by signal, though, that I'm not sure. visual6502 should reveal this.