Need tech support, about VRC7(IRQ & emulation related??) stuff.

[w7n]

OK, I don't know the answer to the spambot question on the NESDEV forum register form, so Mr.Bot is trying to look for an answer here.

Some time ago I did a simple experiment on the Super Mario Bros (JU) ROM--changing the mapper number from 0 to 85(VRC7 mp). Emulation on different emulators varied. On some emulators like VirtuaNES, NNNesterJ, all was well; on some others like Nestopia, it couldn't run. On FCEUX, emulation was OK, but when a savestate was loaded it started glitching.

This puzzles me. Truly, different mappers have different bank sys, IRQ sys etc. But this problem was beyond my explanation although seemingly simple. The SMB ROM sets the I flag at the very beginning and leaves it on. But when FCEUX loads a state, an IRQ is generated, and the IRQ routine(in SMB1 the routine is an infinite loop) is called, and the CHR banks are in a mess. I tried coding IRQ routines and handling(disabling) IRQs in different ways, but eventually I reached wit's end.

'It appears as if' loading the savestate in FCEUX sets some things which should have remained their own values. But this is highly impossible. The other explanation I can think of is that there are some settings which should be set in the reset routine, but if so, what are these settings? This is not related to VRC7 audio of course.

Waiting for a genius...

[Pikachumanson]

Powerpad is the answer.

[Bregalad]

Each mapper has it's own set of registers. If you just change the mapper number of a ROM from 0 to wathever, it will never touch the mapper registers, so how the game is emulated depends on the initial (internal) state of the mapper.

Electronically, the internal state is determined by flip-flops, and when power supply is applied (when you turn the console on) there is no defined state for flip-flops before something is written to them. Thus, it is perfectly normal that the behaviour depends on the emulator.

Same goes for RAM contents and VRAM contents.