The nature of stacks means you can nest them as deeply as you want, with no interference in that regard. You would still have to be careful of course if there's a chance that a second or third nested ISR would use other resources before the first one is finished with them. I've brought a lot of products to market using PIC16 microcontrollers, and with those, since they don't give the programmer direct access to the stack (which is quite shallow anyway), you have to use variables to save your W (working register, like the 6502's accumulator), status register, PCLATH (program counter latch high byte, so you can get back to the right program memory page if you're using more than just page 0), meaning that a nested interrupt would step on the variables used by the outer one. The 6502 doesn't have this problem though.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thank you for the insight. I will have to careful with the "stack" of memory page pointers that I keep in the background. Its as deep as the 6502 stack, but there is no way to read it (from the code) at the moment. Anyway with a proper defined logic I should be able to handle nested interrupts so that memory page pointers stick to were they are used.

With many interrupts, the obvious problem is to manage the page pointers for the different interrupts (as you said). Currently I only have one for IRQ and one for NMI, so I will have to think about how to make a handler for that..

If you're writing your own ISRs, you don't have to have nested IRQs unless you choose to. If you do use CLI in your ISR, then you may see nested interrupts, but if you don't, the RTI will clear the I flag for you and the ISR calls will be serialised.

But there's nothing you can do in software about the NMIs because they are non-maskable: it's a question of whether the hardware is able to raise them faster than they are serviced, I think.

kakemoms, you seem to be referring to an '02 system with banking, something I missed earlier. Perhaps you've been discussing it in another topic. It's hard to keep everyone's projects straight in my mind.

The need for nested IRQ ISRs should be pretty rare. The interrupts primer just mentions the possibility of needing to service a second, more-urgent one before getting back to the first one which may take longer to finish servicing. I've heard people advocate for ISRs that are so short they're basically just leaving a flag for the background program to poll and take care of; but if they're going to poll anyway, what's the point in generating and interrupt?!

The 6502 stacks treatise might prove helpful.

As for NMIs, they are by definition not maskable; but you can still tell the interrupt source to stop generating interrupts until further notice.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thank you all for the helping comments.

I am currently working with a 6522 that generates IRQ and another that generates NMI for the 6502. I didn't think the NMI would be a problem since its only triggered by a key (or BRK) and that should only happen once when that key is pressed. A human being isn't fast enough to press this key twice, so the first NMI should be finished before another can happen.

Now, I see that it does happen several times. E.g. the key can trigger anything from 1 to 10+ NMIs in a row (probably due to the mechanical "switch" being a trigger) before one NMI has been finished (with a RTI). That is interesting in its own (the interrupt only lasting 20-50 CPU cycles), but I also have to handle it in the MMU. If one NMI happens before another one is finished, it does not seem to end in two RTI instances. E.g. the code returns to the address were the first NMI happened, but not to the second.

This is what seems to happen:


This is what I thought would happen:


Is this how the non-maskable interrupt is supposed to work? If so, I have to keep record of recurring NMI instances without a RTI in between.

If I get a BRK and a NMI a few cycles after, will the first RTI return to the address of the BRK command and not the NMI?

Oh, and this is for NMOS 6502.

There's nothing magic about RTI. It's no different than an RTS with a free pop of the status register. Other than that, it has no special properties.

What I don't know, but I'm sure Garth's interrupt primer covers, is exactly when in the NMI processing cycle another NMI fires. But as I recall, NMI is edge triggered, vs IRQ which is level triggered. I don't think an NMI can actually interrupt an NMI until after it's pushed both the address and status register.

But also don't forget, that when the second NMI does fire, the address it does push is very likely in your NMI handler already, so it's easy to see how it looks like the NMI is returning back to just ADDR if you miss the part where it re-entered the NMI handler.

You can definitely nest NMI's, and the processor won't get confused as to where to return to. However, if for example the ISR starts processing a two-byte variable, and gets one byte through it, and starts over, you can see there could be trouble. [Edit: This if if the same part of the ISR runs, using the same variables (without stacking them) and other resources. If the initial polling determines that the interrupt came from a different source and requires different service, this particular problem probably won't arise; but having multiple NMI sources may lead to other (worse) problems, also discussed in the interrupts primer.]


As mentioned in the interrupts primer, one of the NMOS 6502 bugs is that if an NMI hits during a BRK instruction, the BRK interrupt will not get executed. (This, as well as all other NMOS 6502 bugs, have been fixed in the CMOS 65C02.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

If (and only if) your NMI handler is re-entrant, it should be able to nest within anything including itself comfortably (up to the stack limit) just like any other stack-based routine.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Ok. Thanks for all the tips. Apparently I have some more debugging to do.

This issue alone could account for most or all of your difficulty. You could -- either for debugging or as a permanent solution -- add a debounce filter in hardware to guarantee the CPU's NMI input sees only a single transition for every keypress. An RC network followed by a Schmitt trigger would do the trick. Otherwise you could alter your NMI ISR and/or the use of the VIA's IFR to filter out the switch bounce.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Yes I added such a filter. In the event that more than one NMI happens, it will only care about one. I will remove it again since it will make a mess of the logic (that takes care of nested interrupts), but for now I keep it to find the other bug I am experiencing (see below).

Reading what happens in the 6502 based entirely on the data/address bus is not easy, and for IRQ/NMI it is less obvious. I can look for the IRQ and NMI vectors on the address bus, but what is making this difficult is that the last opcode (to run) is not the last thing that appears on the databus. I run this code on the 6502:



The "NOP" opcode $FC is my MMU instruction that the Verilog code reads to switch memory page (here its page $33 which translates to address $33xxx). The STA $A000 accesses the external memory that is controlled by the MMU ($A000-$AFFF range) so that these two opcodes end in a STA to address $33000,X. This usually works but not if a IRQ happen. The following debug waveform shows what is happening:


As you can see from the address and databus, an IRQ had been triggered and eventually access address $FFFE and $FFFF (this shows up as $3FFE and $3FFF here since I don't read A14 and A15). Anyway, the trigger happen after the "NOP $0033,X" instruction (with opcode $FC), but for some reason the next opcode byte $9D (STA) appears on the databus before the IRQ actually triggers. That is what was confusing my MMU decoder.

I have tested this in the Visual6502 simulator and it also happens there, so I just have to adjust the code to cope with this quirk..

Edit: I have adjusted the code and it now seems to work as expected.

Thanks to you all for all the help! (again!)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I came to this topic looking for information on how the 6502 handles overlapping BRKs, IRQs, and NMIs - I think the visual6502 examples above are a great illustration of this for the older NMOS chips. On those it appears that an NMI, for example, occuring in the middle of a BRK instruction or IRQ sequence, will change the vector that gets loaded at the end of the sequence, to the NMI vector. This is actually a bug, as the program counter has already advanced past the BRK instruction, and it leads to the BRK being skipped.

In addition I found by modifying the visual6502 example that an NMI that occurs during the vector fetch is actually ignored; also, short low pulses on NMI seem to be ignored, it is necessary for NMI to be low at the falling edge of PHI2 for the low transition to be spotted by the NMOS CPU. This is consistent with the timing documentation in the datasheet even for the CMOS part.

Knowing that the bug in particular was fixed in the WDC 65C02, and that I'm going to be dependent on it, I thought it worth carrying out more tests on the newer hardware, and thought I'd share the results here as it differs quite a bit from the NMOS behaviour. I performed these tests by hooking up an Arduino to a bare 65C02 and having it drive the control signals and data bus appropriately, logging the results.

Firstly, as a reference I wanted to measure the timing behaviour of IRQB - after it goes low, how long is it before the interrupt sequence can begin? It appears that, for a sync cycle to start the interrupt sequence, IRQB needs to have been low back at the start of a full cycle before it (treating a cycle as the low phase followed by the high phase of the PHI2 clock) - i.e. it must have gone low during the high phase of the cycle two before the current cycle, otherwise the current sync cycle will execute its instruction as normal.

Here's a log taken by an Arduino that's carefully driving the CPU at a fairly slow clock rate. Each line is the bus state in the middle of a half-cycle. 'i' means IRQB is low; transitions happen in the middle of the half-cycle, before the state is printed. 'S' means it's a sync cycle.

So there's a baseline for IRQ latency. What about NMIB? Well as I said above, unlike the NMOS version, brief low pulses seem to be enough to trigger an NMI with the CMOS part, so it is clearly no longer being latched on a clock edge. Here are examples of that - 'n' indicates that NMIB was brought low then quickly high again, in the middle of the half-cycle. The timing is substantially the same as for IRQB.


Next, here are typical BRK and IRQ sequences for reference:

What happens if IRQ and BRK happen at roughly the same time? On the NMOS CPUs the BRK sequence would be converted (mostly) into an IRQ sequence, just with the PC being incremented incorrectly. On the CMOS CPUs it depends which happens first:

In the latter case of course the BRK will execute after the RTI from the interrupt handler's response to IRQB.

Finally, how do NMI and IRQ behave when they collide? On NMOS, an NMI during an IRQ sequence changes the vector to the NMI vector, effectively masking the IRQ. If IRQB is still low after the NMI returns then the IRQ sequence will run at that point.

However, on CMOS, if NMI is not triggered soon enough before the interrupt sequence begins, the CPU delays processing the NMI until after the interrupt sequence that's in progress. So we see the IRQ sequence run to completion, followed by an immediate NMI sequence:

The same is true for an NMI occuring during a BRK sequence. Essentially, the NMI has to wait until the next viable SYNC cycle, just as it would for any other instruction - the ability to modify the sequence that's already in progress is no longer there in the CMOS version. But even though it doesn't run the NMI sequence straight away, it does remember that NMIB was triggered and an NMI sequence is due, unlike the NMOS CPU in some cases.

I hope this is useful to some people - it has highlighted some issues that would have occured if I'd gone ahead as planned, especially in these differences to the behaviour seen for the NMOS CPU in visual6502. In case anybody else wants to try this out, I'll attach my Arduino code - it's set up for an Arduino Mega.

Thanks for the analysis, George! And BTW there's another interrupt quirk worth mentioning. I don't know if you've already seen this, or whether it might affect your plans, but FWIW...

A taken branch delays interrupt handling by one instruction

-- Jeff

Edited to add: in some scenarios it's important for external logic to be "aware" that an interrupt sequence is beginning, and that -- although SYNC has gone high -- the opcode on the bus will NOT be executed. Luckily, it doesn't taken much to detect this. Normally, the address bus will always increment to fetch the next byte after the opcode, but this increment is absent if an interrupt sequence is beginning... and the missing increment can be detected by capturing A0 when SYNC is high and, in the following cycle, doing an XOR of the new A0 with the captured A0.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Thanks Jeff - my plans were already scuppered by what I found, as I was going to rely on disabling NMIs in hardware based on the IRQ's vector fetch - and what I found above means that won't work as it's possible for an NMI triggered before an IRQ even begins to take place after the IRQ sequence. So I'm moving to some backup plans now