PLP and the Break Flag

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
PLP and the Break Flag
by Aliasmk on 2015-10-08 (#156917)
I seem to have some difficulty understanding this behavior. Below is an excerpt from NESTEST.log:

Code:
C822  A9 FF     LDA #$FF                        A:2F X:00 Y:00 P:2F SP:FB CYC: 80 SL:243
C824  48        PHA                             A:FF X:00 Y:00 P:AD SP:FB CYC: 86 SL:243
C825  28        PLP                             A:FF X:00 Y:00 P:AD SP:FA CYC: 95 SL:243
C826  D0 09     BNE $C831                       A:FF X:00 Y:00 P:EF SP:FB CYC:107 SL:243


As far as I understand, 0xFF is loaded into A, which is pushed onto the stack. Finally it is brought out of the stack and placed in the status registers... or not... because 0xFF went in to the operation and somehow the processor flags were set as 0xEF (missing the break flag).

Anyone have any information about why this is the case? Thanks!
Re: PLP and the Break Flag
by lidnariq on 2015-10-08 (#156918)
The break flag doesn't exist. It's an entirely fictitious concept that exists only on the stack.
http://visual6502.org/wiki/index.php?ti ... _and_B_bit
Re: PLP and the Break Flag
by tepples on 2015-10-08 (#156919)
Bits 6 and 5 of the processor status register (P) do not exist as physical bits on the 6502 CPU. They are created by the circuit that pushes P to the stack: 10 for interrupts, 11 for PHP/BRK. In a log like this, the values in bits 6 and 5 of P can be disregarded. This means $CF, $DF, $EF, and $FF are equivalent in P.

See CPU status flag behavior on the wiki.
Re: PLP and the Break Flag
by Aliasmk on 2015-10-08 (#156926)
So assuming that the B flag only exists within the context of the stack, is it worth accounting for? Is there any reason a programmer would PHP -> PLA and perform operations based on the status flags plus the B "flag" where it would be necessary to have a predictable value?
Re: PLP and the Break Flag
by Myask on 2015-10-09 (#156946)
The reason to check the B flag is to detect software interrupts (that is, a BRK command). This has uses in crash detection, assertions, and some other options...

I can't think of any reason to check I that wouldn't be just as well served by doing a push and overwriting. VNZC are all branchable. So that leaves D...which can be used for one bit of data storage. But that's a bit arcane. hee hee.