DSP: Fix missed external interrupts due to external interrupts being disabled #13463
Conversation
I'm not 100% sure about the LoadRegs(false) part.
This reverts commit f17bc0bc8e8ceac6cbfdadb2ade8f877d4eedaca.
…thout the free ROM. But it doesn't freeze.
This reverts commit a1f1ba5b157e833dd1788b20e29b87d979ce2059.
Before, I was getting an abort() call in debug builds when selecting Tools -> Load Wii System Menu (although I'm not sure if this will work on other machines consistently). It seems that CodeViewWidget::Update was constructing a CPUThreadGuard instance, and thus was calling Core::PauseAndLock(true, true), but the CPU thread hadn't started yet so Core::IsRunningAndStarted() returned false and thus Core::PauseAndLock() did nothing. However, after the code widget finished updating, CPUThreadGuard's destructor called PauseAndLock(false, true), and by this time the CPU thread *had* started so Core::PauseAndLock eventually called CPU::PauseAndLock(false, true, true). This resulted in s_stepping_lock.unlock() being called without a corresponding s_stepping_lock.lock() call, which calls abort() in debug builds.
This affected my interrupt_nested test; SR_100 always is clear, but after using SBSET dolphin-emu#2, it was temporarily set. This doesn't really make sense (why do they have an instruction to set a bit that cannot be set? why does this bit even exist?) but this change makes behavior match real hardware. The recompiler behaved correctly (as it uses dsp_op_write_reg).
This reverts commit 5224702.
|
Reverted commit from #11593, which was causing build failures. I'm not sure if it's still needed or not. |
|
The Mario Sunshine hang should be really easy to reproduce on master right now, as it seems to be happening on every boot. So, if this is working then that should boot. |
|
FifoCI detected that this change impacts graphical rendering. Here are the behavior differences detected by the system: automated-fifoci-reporter |
|
This change definitely fixes SMS with the interpreter, and probably also with the recompiler (but since that's random I haven't been able to confirm it). However, I did run into crashes and other weird hangs with DSPSpy and toggling settings (e.g. vsync), so there still seems to be an issue with the CPU thread (#11593). But that's probably separate. |
|
I also thought I updated GameCube_DSP_Users_Manual.tex at some point but it looks like I didn't. |
This is a very old branch that I last haven't touched since 2023 (other than last rebasing it in September 2024). I haven't even confirmed it builds, but I think it used to fix https://bugs.dolphin-emu.org/issues/11384 based on my findings in #11319.
I believe I ran into issues with tests that were nondeterministic on real hardware, or perhaps just weirdness with cycle timings between different instructions. I don't remember the details.