Fixes https://bugs.dolphin-emu.org/issues/10265 (Star Wars: The Clone
Wars hangs on loading screen with DSP-HLE and JIT Recompiler).
The Clone Wars hangs upon initial boot if this interrupt happens too
quickly after submitting a command list. When played in DSP-LLE, the
interrupt lags by about 160,000 cycles, though any value greater than or
equal to 814 will work. In other games, the lag can be as small as 50,000
cycles (in Metroid Prime) and as large as 718,092 cycles (in Tales of
Symphonia!).
All credit to @hthh, who put in a heroic(!) amount of detective work and
discovered that The Clone Wars tracks a "AXCommandListCycles" variable
which matches the aforementioned 160,000 cycles. It's initialized to ~2500
cycles for a minimal, empty command list, so that should be a safe number
for pretty much anything a game does (*crosses fingers*).
These settings are already loaded and saved to the SYSCONF. The INI
load/saves are redundant and do not work anyway because they are
overwritten by SYSCONF.
This file is pretty small now that it doesn't handle Wii
partitions anymore, so let's move its contents to Volume.cpp.
This is also more consistent with how blob creation works.
This happened to work without any problems because the only way for a
file system to be invalid was to not have the right GC/Wii magic word
in the unencrypted area, and a volume could not be created without
having the right GC/Wii magic word there. Now that file systems read
the magic word from a partition instead, a fix is needed.
I replaced m_OffsetShift with m_Wii in bb93336 to support
the decrypt parameter for read functions. Doing that is no
longer necessary, so m_offset_shift is now used like before.
By removing mutable state in VolumeWiiCrypted, this change makes
partition-related code simpler. It also gets rid of other ugly things,
like ISOProperties's "over 9000" loop that creates a list of
partitions by trying possible combinations, and DiscScrubber's
volume swapping that recreates the entire volume when it needs to
change partition.
- Makes DSP-LLE code checksums the same as those from DSP-HLE. I'm
assuming DSP-HLE was doing it correctly, since there are numerous
references to these pre-endian-swapped checksums (including in
DSPHost.cpp itself).
- Fixes disassembly when dumping code from DSP-LLE, which was using the
wrong endianness and giving totally bogus output.
- Reveals error messages of the format, "Bah! ReadAnnotatedAssembly
couldn't find the file ../../docs/DSP/DSP_UC_AX_07F88145.txt," which
seems to be intended behavior that was previously hidden.
This change centralizes all of the path handling and file writing logic
in DumpDSPCode. DSP-HLE also gains the feature of DSP-LLE to
automatically disassemble dumped code and write it to an accompanying
text file.
With the relocation of DumpDSPCode to DSPCodeUtils, the only remaining
function in DSPLLETools is DumpCWCode. This function 1) is not used
anywhere (not even in DSPTool), 2) doesn't seem to really do anything,
and 3) has a single comment saying "TODO make this useful :p"
This is something that should be the responsibility of the frontend
booting the game. Making this part of the host 'interface' inherently
requires frontends to leak internal details (much like the other
UI-related functions in the interface).
This also decouples more behavior from the debugger and the
initialization process in the wx frontend. This also eliminates several
usages of the parent menubar in the debugger code window.
