I would like to use the BRK instruction in my program and therefore I need to be sure whether I am dealing with a BRK interrupt, an IRQ interrupt, or both. If I understand correctly, the "B" flag in the status register does not physically exist. And setting the "B" flag is only visible on the stack.
Then I have a question. What happens if the processor receives an IRQ signal while executing the BRK z instruction?

The interrupt disable bit will be set while processing the BRK, so unless you clear it, you are protected against a nested IRQ being handled - the IRQ will not get processed until the BRK handler returns.

A BRK will:
- push the PC on the stack
- push the Status Register on the stack (so with the I flag cleared)
- fetch the address of the Service Routine and load to the PC
- set the I flag
So the cpu will be unresponsive to other IRQs.
Having the Status Register pushed with the I flag not set is for when the RTI is executed: the Status Register will have the I flag cleared just by popping it from the stack.

All the interrupts behave like that, except for the Reset which will not push anything on the stack.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
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?

Indeed this thread included some nice Visual6502 experiments - it looks like this one in particular demonstrates an IRQ occuring during the early stages of processing a BRK, and you can see the bug occur - the flags were pushed on cycle 8 with the B bit not set, but the PC was incremented before being pushed, so cycle 19 returned to the instruction after the BRK, without executing the handler with the B bit set at all.

Just to reinforce the point about this being an NMOS-only bug - the modern WDC 65C02 does not suffer this bug and will instead process both the BRK and the IRQ separately without fail.

I think perhaps the defensive tactic in the ISR would be to check for interrupt sources before or after handling the BRK. (Unless, in a particular system design, BRK is intended to be quite heavy and there's no expectation of all ISRs being serviced.)

Thank you for all the information.
My goal is a system running on AppleII+, i.e. on an NMOS processor. I designed a circuit that works as follows:
The system detects 3 consecutive writes to RAM and checks whether the "B" flag is set during the 3rd write.

If all conditions are met, additional memory (usually invisible) with the BRK handler should appear at the top of memory $E000 - $FFFF.
This memory will be disconnected after RTI is performed.
I used this description:
https://www.nesdev.org/the%20'B'%20flag ... uction.txt
My system does not use the SYNC signal.
I understand that if I do SEI before BRK, I will avoid problems?

Interesting!

To me that seems less than certain. The process of interrupt recognition may already have begun as the SEI executes, and I'd be concerned that the SEI's actual effect may arrive too late.

You could answer the question by means of another Visual6502 experiment. But the question becomes irrelevant if you take Ed's suggestion and test for BRK at the beginning of the ISR. This may be a preferable approach anyway, given that it eliminates the need for a SEI before each BRK (and presumably also a CLI afterward).

-- Jeff

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

Yes I think this will prevent the NMOS bug at least for IRQs. NMIs could still cause it, and as Dr Jeffyl said it may be worth adapting the above visual6502 link to verify it.

How would you test for BRK since the 'B' flag does not actually exist within the status bits?

Looking for the 'B' bit within stuff on the stack does not appear to be reliable.

Looking into the stack for the B bit is the only way. Not sure what you mean by unreliable, unless you mean what's discussed in this thread, where we are seeking tactics. And finding them.

(Off the top of my head, I think there's no problem with NMI, as it uses a different vector and mechanism, but I'm not presently inclined to re-research!)

I just had another look at the visual6502 example I reposted higher in this thread, and it doesn't demonstrate what I thought it did, so apologies for that. I think your hardware solution will work, as will the more normal software method of checking bit 4 of the top byte on the stack, at the start of both the IRQ and NMI handlers. I guess the NMOS bug is just that you're not meant to need to do this in the NMI handler, but so long as you do (and also still perform whatever NMI handling is needed) then all should be well.

Here are visual6502 traces demonstrating the scenarios - first, a normal BRK instruction:
http://visual6502.org/JSSim/expert.html ... re=nmi,irq

Then a BRK instruction with an NMI occuring at the earliest point that leads to the vector read from FFFA but still allows the BRK to increment the program counter:
http://visual6502.org/JSSim/expert.html ... re=nmi,irq

And finally a BRK instruction with an IRQ occuring at that critical point, note though that execution is no different to the BRK instruction on its own so there's really no bug here:
http://visual6502.org/JSSim/expert.html ... re=nmi,irq

Thanks George! Clear explanations and simulations are very helpful, much more so than my vague recollections!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!