Hi, first time poster on great looking forum.

I'm after a sanity check from someone knowledgeable in 6502 assembly.

I am writing an NES emulator which has a 6502 at its core. I've finished the 6502 and am testing its output using an NES test cartridge program called NESTEST.nes, which also comes with a debug log of key processor parameters.

I ran the test cart, outputted my own debug log and then wrote a program to compare my debug log with the supplied one.

I have found several issues, but it looks like the issues are with the provided Test debug log, and not with my processor output.

The issues hinge with Push / Pull processor status and Push / Pull Accumulator. When Processor status is pushed onto stack then pulled into A, it seems to gain 10H, and lose 10H when you reverse the process.

Excerpt of supplied debug log below. Am I correct in stating that A should be 6f after PLA and not 7f as the log shows?

Many thanks for any help.

C7E7 08 PHP A:00 X:00 Y:00 P:6F SP:FB PPU: 1,214 CYC:185 – Push Processor Status (6F) onto Stack
C7E8 68 PLA A:00 X:00 Y:00 P:6F SP:FA PPU: 1,223 CYC:188 – Pull Stack Pointer address Contents Into A. Check Z and N flags
C7E9 29 EF AND #$EF A:7F X:00 Y:00 P:6D SP:FB PPU: 1,235 CYC:192 – Why has mem(SP) changed from 6F to 7F?

Welcome! Sounds like you're doing pretty well. The B bit in the status register is a familiar stumbling block - I've listed a few previous threads below. The interesting and important observation is that there is no B bit stored in the CPU: when P is pushed with PHP, the B position is always written as a 1, and when P is pulled with PLP, the B bit from the stack has no effect.

In a sense, the problem arises when an emulator reports the B bit in the P register as a zero - it never is zero, and this leads to confusion.

The reason the B bit is meaningful is that when an IRQ causes P to be pushed, the B position is written as a zero, and in this case when the saved P is read from the stack with a PLA, the zero is meaningful. (Indeed, when the saved P is read with a PLA and the B position is read as a one, that's meaningful, if the P was saved by a BRK.)

I thought there was an essay about this in the reference section, but I don't see it... oh, in fact it's here, on the visual 6502 wiki, presently accessible only from the Internet Archive.

Hope this helps!

Here are some previous threads:
Odd behavior with BRK bit being set
BRK detection
brk flag useless?

(There might be some misguided "corrections" to some of our terminology here - best to ignore them, as we have so many threads hijacked for pointlessly pedantic purposes. Rest assured, your terminology and mine is widely used and perfectly acceptable to all reasonable people.)

Wow. Thank you so much for the reply and info! Exactly the info I was after.

I will go through this more thoroughly later when I can write some code but this sounds like it will resolve the issue that I am seeing in my debug log.

To be fair, I was pretty sure that experienced coders wouldn't be making mistakes in their test roms and knew it had to be something that I was missing.

Thanks again!

Welcome, Raandaall_Flaagg!

-- Jeff

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