I just took a look at every 6502 instruction and noticed non of them used the brk flag, not even the branch and set flag instructions. Does the brk flag do anything at all?

Yes. It's used by an interrupt handler to look at the flags saved on the stack and determine if it was called because of a software interrupt (BRK instruction) or a hardware interrupt (IRQ). Note that some (all?) versions of the 6502 can combine IRQ and BRK processing if the timing comes out correctly, so one call to the interrupt handler could be from both a BRK and an IRQ.

So, it's useful, but only in the context of the flags stored on the stack when starting an interrupt handler.

-- Alastair Bridgewater

Indeed, so it's (often) read by PLA in an interrupt handler. You can't read the 'break flag' because there is no flag in that sense: there's a slot in the saved P state which is stuffed as needed when an interrupt or break happens, but there's no bit to be read in P. If you PHP and PLA you'll always see 1. Even if you push 0 and PLP it'll still be 1. See http://www.visual6502.org/JSSim/expert. ... a&steps=44 for example.

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

Might be worth noting how Acorn's OS on the Beeb does this - they use a global to save A which means no need to dip into the stack:

See http://mdfs.net/Docs/Comp/BBC/OS1-20/DC1C

Cheers
Ed

Similarly on the Atom:

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

Fair point about re-entrancy!

I'm not sure that is much of a shortcoming... I'd expect A to be restored and if necessary pushed on the stack before interrupts are re-enabled, and that the BRK instruction would not be used in interrupt handlers.

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

Hi BDD surely it's a valid point that A can be restored from ZP within a few instructions, and so long as that happens before CLI, all is well.
Ed

The Atom code does a quick check for BRK by saving A in ZP. Since IRQ is not enabled, that's perfectly safe. If the BRK code does not need to be reentrant, it's also safe to leave A in the ZP location while handling the BRK. Only when the code has decided it's dealing with an IRQ, and this particular type of IRQ is reentrant, the A is read from the ZP location, and pushed on the stack (like the Atom code does). What rwiker was referring to is the fact that this fails when you do a BRK inside the IRQ while the ZP location still holds A. But if you're careful enough not to do that, all is well.



The NMI handler doesn't have to check for BRK, so it can just do PHA, and everything will work fine.

I think that this is the bug that I'm remembering: A badly-timed coincidence of BRK and NMI can cause the NMI handler to be entered with the BRK flag stored on the stack just as would normally happen with BRK and the IRQ handler. The catch being that the NMI handler is then left "holding the bag", as it were, for dealing with the BRK as well. I'm not sure if this applies to the more recent CMOS chips, just the original NMOS chips, or maybe all chips, but it's the sort of thing that could cause once-in-a-blue-moon missed BRK processing.

Or my memory could be massively faulty right about now and I'm making the whole thing up, or it applies to an entirely separate CPU family or something.

It's a good point: there are some subtleties. There's a writeup at
http://visual6502.org/wiki/index.php?ti ... _and_B_bit
Cheers
Ed

Permit me to express my opinion and thereby also reveal my ignorance on interrupts: I dislike interrupts. I've never used them. They seem to have been made for slow machines.
However the level of detail being paid attention here recently in this discussion is very interesting regarding NMI and IRQ(hardware trigger or software BRK opcode). I've never wrote software to take these things into account, so some of the shared code is appreciated.
A fast enough 6502 doesn't need interrupts does it? It should have sufficient time to poll all flags/inputs within the system.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502