Problems with new emulator and SMB 3

[Zelex]

Hi all helpful peoples!

I come bearing gifts of puzzles to solve!

I started a new emulator that is accuracy focused, while also being fast enough to run on a mobile phone (a tall order, but I'm up to the challenge)

The problem is pretty much identical to viewtopic.php?f=3&t=9395&p=101095&hilit ... RQ#p101095

except that thread never got to a resolution. Starting solution attempts from top to bottom in Dwedit's first post.

> scanline 248 (vblank time): C000 = C1 ;next value for latch
check

> C001 = xx ;value C1 will be reloaded into the scanline counter at dot 260 of the prerender scanline
check

> E001 = xx ;allow MMC3 interrupts
check

> Interrupt should trigger at scanline 192, dot 260.
check

> CPU will be at the address of the IRQ handler at about dot 284-295.
huh? If the interrupt triggers, the address changes nearly immediately, certainly not 24 dots later? right? (nevermind, silly comment. check)

Then comes (for me)
scanline 241: 8000 = 0x64; no effect in this case, set command
scanline 241: A001 = 0;
scanline 241: E000 = 0; acknowledge, disable interrupt
scanline 243: A000 = 1; set horizontal nametable mirroring
scanline 243: A001 = 0;
scanline 33: 8000 = 0x46; no effect, set command
scanline 33: 8001 = 0x19; Load 8k rom bank to address 0xC000, bank #25 (out of 32 8k banks available)
scanline 34: 8000 = 0x47; no effect, set command
scanline 34: 8001 = 0x18; Load 8k rom bank to address 0xA000, bank #24
scanline 112: 8000 = 0x46; no effect, set command
scanline 112: 8001 = 0x19; Load 8k rom bank to address 0xC000, bank #25
scanline 112: 8000 = 0x47;
scanline 112: 8001 = 0x18; Load 8k rom bank to address 0xA000, bank #24
scanline 246: 8000 = 0x45;
scanline 246: 8001 = 0x7F; Load 4k vrom bank to address 0x1C00, bank #127

At this point there is garbage on the screen until the NMI, then it re-renders the curtain again, sets the MMC3 irq counter, and repeats the vicious cycle.

Any help or ideas would be much appreciated. I'm looking for a super accurate emulator I can compile in MSVC and compare with side by side that is not my javascript emulator (cuz I don't trust it for accuracy )

Thanks!
Jon

[lidnariq]

> CPU will be at the address of the IRQ handler at about dot 284-295.
huh? If the interrupt triggers, the address changes nearly immediately, certainly not 24 dots later? right?

Are you familiar with 6502 interrupt timing? It takes a while to save the return address and stuff after /IRQ is asserted.

[Zelex]

> CPU will be at the address of the IRQ handler at about dot 284-295.
huh? If the interrupt triggers, the address changes nearly immediately, certainly not 24 dots later? right?

Are you familiar with 6502 interrupt timing? It takes a while to save the return address and stuff after /IRQ is asserted.

ah, yeah. Thats what he means. I'll double check my code, but yeah I do that. I pass all of blargg's MMC3 test and all CPU tests.

[Zelex]

I know the interrupt has to be bad as its the only thing that makes sense, but I'm not sure how tbh. Is there a unit test ROM somewhere which specifically tests this? I need a sanity check.

It suggests that perhaps I'm loading the wrong ROM bank in somewhere, but if I disable the IRQ from MMC3 the game works just fine... (other than the broken stuff that relies on the MMC irq)

Edit: Found one. Trying out cpu_interrupts.nes
Edit Edit: and I failed some tests. So let me fix those first.
Edit Edit Edit: Amazingly, even FCEUX fails most of these tests.

[Alegend45]

That's because FCEUX kinda sucks compared to some of the better emulators out there. Try seeing Nintendulator's results, it's the most accurate NES emulator that is still being developed. Nestopia is good too, but it's confirmed dead until someone picks it back up.

[Quietust]

Try seeing Nintendulator's results, it's the most accurate NES emulator that is still being developed.

In all honesty, that classification probably belongs to another emulator by now, most likely Bizhawk.

[MottZilla]

Don't rely on test roms. The real tests are the games themselves.

Be sure your MMC3 IRQ behavior is correct. Be sure that the scanline counter counts correctly, IRQ is acknowledged properly, that your cpu core properly acts on pending IRQs. Maybe your pending IRQ just continues to trigger IRQs.

[Zelex]

I think I found the problem. It is writing to address $7964, which is Program RAM. I ignore those writes. Looks like its using that memory space as additional RAM.

[Zelex]

Yup, that was it. Fixed!

[Dwedit]

No PRG RAM is going to make it very hard to run SMB3, especially since it stores the levels there.