Unexpected mismatch

[OxayMint]

first of all, thank you so much for this life saver. It really saved me probably days of debugging. But there is one thing I can't understand. I'm passing all the blargg tests at this point but the 02-interrupts one doesn't get approved by your script. I get the following:

Mismatch in CPU state at line 151346:

MINE: A:04 F:C--- B:01 C:00 D:C7 E:BA H:90 L:00 SP:DFFD PC:C2C0 PCMEM:05,C2,B9,C1 YOURS: A:04 F:C--- B:01 C:00 D:C7 E:BA H:90 L:00 SP:DFFB PC:0050 PCMEM:3C,C9,00,00

However blargg tests print "passed". What can be the issue here? May it be because the rom itself has changed since your last upload?

[cluoma]

I ran into this as well. I believe the logging is simply happening before the interrupts are checked. The next log at line 151347 is:

MINE: A:05 F:C--- B:01 C:00 D:C7 E:BA H:90 L:00 SP:DFFB PC:0051 PCMEM:C9,00,00,00

So, likely it is logging PC at 0xC2C0, but the interrupt is going to 0x0050 and executing that instead.

Moving the logging around like this fixed the issue for me.

[robert]

Thanks for your messages both. @cluoma to make sure I understand - you think that the example logs are correct, but users have to make sure to insert their logging at the correct point in their emulator? How do you think I could edit the docs to make this clearer?

[Ptival]

I ran into a similar issue:

============== ERROR ==============

Mismatch in CPU state at line 151347:

MINE:	A:05 F:C--- B:01 C:00 D:C7 E:BA H:90 L:00 SP:DFFB PC:0051 PCMEM:C9,00,00,00
YOURS:	A:04 F:C--- B:01 C:00 D:C7 E:BA H:90 L:00 SP:DFFB PC:0050 PCMEM:3C,C9,00,00

The CPU state before this (at line 151346) was:

	A:04 F:10 B:01 C:00 D:C7 E:BA H:90 L:00 SP:DFFD PC:C2C0 PCMEM:05,C2,B9,C1

The last operation executed (in between lines 151346 and 151347) was:

	0x05 DEC B

Perhaps the problem is with this opcode, or with your interrupt handling?

It appears the the reference emulator will, all at once, set up the interrupt handler, and execute the first instruction of the handler.

So while my emulator was about to execute the first instruction of the handler (at 0x0050), the reference already has and is at 0x0051.

I think this should at least be documented.

[robert]

@Ptival thanks for tracking that down - would you be up for making a PR with a README.md update that would have made this clearer for you?