N64: Disabled Expansion Pak doesn't seem to be emulated accurately

[flagrama]

This seems to be a regression in mupen64plus-core.

Running a game that requires the Expansion Pak without one doesn't seem to "work" properly. Where working would mean either a black screen, or an error screen. This is confirmed to be an issue with Ocarina of Time Randomizer, and Majora's Mask.

We only realized this because Ocarina of Time Randomizer should not boot without the expansion slot, and yet only new code that stores music in the Expansion Pak RAM has started to cause issues. If you load a save state with these new code changes the game will crash when it tries to play the music.

Standalone mupen64plus-core (2.5.9) properly shows an error screen for Majora's Mask and a black screen for Ocarina of Time Randomizer when "DisableExtraMem" is enabled.

[YoshiRulz]

Regression from which version? I'd like to bisect.

[Nicholas-Steel]

So loading the games works fine, no issues at all but loading a Save State causes issues. As far as my untrained eye can tell it seems like the Expansion Pak is enabled when loading the ROM (despite the setting being disabled) and the Load State is honouring the Expansion Pak setting (which is disabled), this means the Load State function is loading a state with Expansion pak data in to an environment without an Expansion Pak, resulting in the crashes.

[darkangel93x]

i assume you mean the BizHawk version usually 2.3.0 or higher.

[flagrama]

I did some limited testing and from what I see BizHawk and mupen64plus-core 2.5 both behave the same. It's the new 2.5.9 pre-release I've been using that emulates the lack of expansion pak correctly. So not a regression, just more accurate emulation upstream that hasn't been added yet.

[CasualPokePlayer]

Games which require the expansion pak (according to gamedb) are forced to have the expansion pak regardless of settings here:

BizHawk/src/BizHawk.Emulation.Cores/Consoles/Nintendo/N64/N64.cs

Lines 44 to 49 in 5e34dc6

	// Override the user's expansion slot setting if it is mentioned in the gamedb (it is mentioned but the game MUST have this setting or else not work
	if (game.OptionValue("expansionpak") != null && game.OptionValue("expansionpak") == "1")
	{
	_disableExpansionSlot = false;
	IsOverridingUserExpansionSlotSetting = true;
	}

Randos wouldn't be identified via gamedb so that casues another issue: all disabling the expansion pak actually does in mupen is simply tell the game the expansion pak is not available. Not all games actually abide by this and some will detect the expansion pak present (as it is internally present and nothing blocks read/writes to it). Savestate issues with this should be "fixed" with 5e34dc6

[flagrama]

all disabling the expansion pak actually does in mupen is simply tell the game the expansion pak is not available.

To be clear this is mupen64plus 2.5 behaviour: https://github.com/mupen64plus/mupen64plus-core/blob/2.5/src/ri/rdram.c#L65-L83 which is currently what bizhawk uses.

In mupen64plus 2.6 writes to rdram outside of the known size are ignored and reads from outside of the known size return 0 which is accurate to console, and games will use this behaviour to test if there is 8MB of RAM or they will crash due once they read bad data from the missing RAM (what happens to OoT Rando)