Emulator

For reference, that bisect points to: https://dolphin-emu.org/download/dev/07a0d44b36c487967cbd957ed9bd20384bf3e33a/

Which yeah, seems plausible.

Can you attach logs with IOS - Drive Interface (IOS_DI), DVD Interface (DVD), and Processor Interface (PI) enabled in the log configuration?

Looks like the issue is in the game's antipiracy "Error #001" check, which attempts to make a read past the end of the disc, expecting it to fail with an out of bounds result (which wouldn't happen with DVD-Rs apparently). But instead of giving an out of bounds error, the disc drive wants the disc ID to be read since it was just reset (something that was only implemented in 5.0-12436). Testing the normal game, I don't see the write to PI_RESET_CODE happening, so it's probably something to do with the mod.

There are two possibilities:

• The write to PI_RESET_CODE shouldn't be happening but is for some reason
• The out-of-bounds error is supposed to take priority over the disc ID not read error (which seems unlikely to me)

I'll do some further testing. The one thing that strikes me as odd is that I'd expect the "Error #001" message to show up in this case instead of just a freeze.

I was able to reproduce, but it sent me back to the System Menu instead of freezing. Do you have a System Menu installed?

Project M is definitely intentionally writing 1 to PI_RESET_CODE (it actually logs 0xCC003024 = 1, but none of its log messages show up after WDVD OpenPartion because (as far as I can tell) after Dolphin detects a game switch, it resets the HLE patches since they usually don't apply anymore; in this case Project M has a few more log messages before it actually starts Smash). I don't see anything else that writes something else back to PI_RESET_CODE (Project M doesn't do it, and Smash only does it in one place that doesn't seem to apply and wasn't hit when launching the game normally).

It also turns out that the "Error #001" message won't show up in this case, because it actually checks the top byte of the error result (in this case 0x05020401) and returns false immediately if it's nonzero (it only performs further checking of the error code, which might result in the message, if the top byte is zero). Since the top byte is the drive state (with 5 being disc ID not read), it won't give the message. I'm guessing Nintendo did this so that if someone ejected the disc right after it started, it wouldn't make the claim about an unauthorized device. The false return value causes the calling code to run OSReturnToMenu(), so the System Menu part makes sense at least.

Unfortunately, I don't fully understand what's happening here. My first possibility doesn't apply (the write is clearly intended), and the second one also doesn't (even if the out-of-bounds error took priority in the no disc ID state, that'd result in a return of 0x05052100 because it still includes the state value of 5, and thus it would still return to menu). Possibly the implementation of PI_RESET_CODE is backwards (right now, we reset the drive when bit 2 (0x4) is cleared, but instead it should be reset when it's set), but that doesn't seem quite right to me since libogc's (and Nintendo's) DVD_LowReset clears it, waits, and then enables it again; I'd expect the reset signal to be the period when it's unset.

Fix: https://github.com/dolphin-emu/dolphin/pull/9060 (hardware testing seems to show PI_RESET_CODE not resetting DI in Wii mode)