Hello!
I've been working on a small NES/6502 simulator in JavaScript for the past few weeks, this forum has helped me a lot.
Today is the day I register, for a very specific question:

According to many sources/specs, conditional branches (like BEQ, BNE, BVS, BVC, ...) take:
- 2 cycles when the branch doesn't occur
- 3 cycles when the branch occurs on the same page
- 4 cycles when the branch occurs on a different page

So I implemented it like that and it seemed to work fine.

However, there is a famous NES homebrew called nestest that aims to test every combination of addressing modes and instructions, and it comes with a handy log file showing the status of the CPU before each opcode.

And at a certain point, nestest only counts 3 cycles during what I assume to be a cross-page BEQ:



Am I wrong to consider this a cross-page branch (the opcode being on $CFFE-$CFFF and the target address on $D005), or is nestest wrong to consider it a same-page branch?

If I am wrong, does it mean I should compare the first byte after the opcode (PC+2) with the target address?

Thanks a lot!

After loading the branch offset, the next instruction is at $D000, which is on the same page as $D005.

What behaviour do you get if you place the branch instruction at address $CFFD instead of $CFFE?

@rwiker: thanks for your answer! When I do like you say (compare the next instruction's address with the branch target address), indeed, they are on the same page and my emulator is compliant with nestest's results (3 cycles).

If I put my instruction on $CFFD, the cross-page is also well detected (4 cycles).

So is that officially the right way to do? (consider the next instruction's address instead of the opcode's address)
I didn't see it in the proc's specs.

Thanks again

Yes, the processor needs to decide what happens after the conditional branch. It already knows the full 16-bit address to fetch from if the branch is NOT taken. But if the branch *is* taken then it needs to add the branch offset, and doing so will take at least one and perhaps two cycles.

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

You can test this in visual6502, by twiddling the reset and code addresses in a URL like this:
http://visual6502.org/JSSim/expert.html ... lu,alucout

Thanks a lot!

Another clue here is that the offset is encoded as a two's complement byte from the address following the complete branch instruction. This fact is not easy to spot if you only look at the assembly source. The critical reason for the extra cycle is the need to propagate the carry or borrow to the high byte following the addition of the offset.