> Once the instruction finishes, the current PC is pushed
Perhaps this is where we need to dive in - you're thinking of the previous instruction being interrupted. It's more accurate to say that the previous instruction finishes, and the next instruction is replaced by the actions of a BRK ...

When you do the RTI, the new PC value is popped off the stack and the next instruction is read from that address - there's no record or residue of what might previously have been at that address.

Okay, so if i'm understanding it correctly, it still needs to re-read what is currently at that ...

Here's a (contrived) scenario:

My (6502) emulator is executing code and an NMI occurs. It was in the middle of an instruction so the instruction finishes. Once the instruction finishes, the current PC is pushed the the stack (along with status, etc.), and the ISR routine is ran.

In the ISR routine ...

Thanks for the information. One more question:

On the 6502, According to https://en.wikipedia.org/wiki/Interrupts_in_65xx_processors, the following happens:

The detection of an NMI or IRQ signal, as well as the execution of a BRK instruction, will cause the same overall sequence of events, which ...

Just to confirm -- What is the behavior of the 6502 when an interrupt occurs in the middle of instruction? Does it handle the interrupt when it occurred, or does it finish the instruction and then perform the interrupt?

For example, if I'm executing an instruction and have 2 cycles left until that ...

Has anyone ran this on a real 6502? I'm trying to ballpark how long this test program would take on say, 1MHz 6502 processor. Before I start counting cycles, I was curious if anyone had a cycle count or estimate as to how long this program generally takes.

12979 ; decimal add/subtract test
12980 ; *** WARNING - tests documented behavior only! ***
12981 ; only valid BCD operands are tested, N V Z flags are ignored
12982 ; iterates through all valid combinations of operands and carry input
12983 ; uses increments/decrements to predict result & carry ...

I believe that you should consider the operation that you are requesting in a decimal representation:

$7F => 127 decimal
$FF => -1 decimal

the operation you are performing is 127 - (-1) = +128 which can not be represented in an 8-bit register. Hence the V flag should be set. Furthermore, the ...

I'm running a 6502 expression in a simulator and it's reporting that the overflow flag is getting set, even though I don't expect it to be set. Consider the following:

Carry flag is on.
acc = 0x7f

So I run the expression:

SBC #$ff

And the overflow flag gets set, and acc is 0x80.

I thought the ...

I'm trying to emulate a system that doesn't have support for BCD mode.

Looking at Klaus' "6502_functional_test.a65" file, does anyone know the point at which everything has been tested EXCEPT for BCD? I'm trying to figure out a place to put a breakpoint in my debugger so I don't creep into the BCD ...

The emulators just follow the behavior of a real 6502 or any of its hardware successors. The unused bit returns a 1 when read, because it is not present in hardware and reading an open circuit simply returns a logic high state. The same is true for the break bit, as it is not an existing flag bit ...

The B flag does not physically exist in the processor. It is only a position in the status byte that gets pushed when there's an interrupt; so to test it, you have to do PLA PHA AND#$10 from the ISR when status is at the top of the stack. PHP PLA AND#$10 won't work. There's an article on 6502 ...

This is perhaps a stupid question but:

Consider that the status register is defined as:

7 6 5 4 3 2 1 0
S V - B D I Z C

If I do the following code:

LDA #$00
PHA ; Push 00 to the stack
PLP ; Pop 00 into the status register

I now see the status register being 0x30. This means that bit 5 (reserved ...

To reproduce the issue:

Open Kowalski 6502 simulator. Click File->Load Code. Then select the attached hex file. Once opened click Simulator->Step Into, and continue stepping until stuck in the infinite loop.

Does it loop when you do that? Or did I miss additional steps in between? Thanks. :shock ...

Strange, there is nothing wrong with the generated listing. I ran my own hex file in Kowalski and it traps the break at $982, well beyond the branch range test (DEX loop). Changing the simulator option "Finish running program" from BRK to 0xBB continues to loop on the trap at $36E5, a known ...