DSP: Fix missed external interrupts due to external interrupts being disabled #13463
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
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. |
|
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. |
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.
Pokechu22
force-pushed
the
dsp-missed-interrupts
branch
from
13ea2c7 to
c8dcbb6
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.