Emulator Issues #12799
open
Rick Dangerous Wii - Doesn't Boot
Added by ZephyrSurfer over 2 years ago. Updated almost 2 years ago.
0%
Description
Game Name?
Rick Dangerous
Game ID? (right click the game in the game list, Properties, Info tab)
N/A
MD5 Hash? (right click the game in the game list, Properties, Verify tab, Verify Integrity button)
N/A
What's the problem? Describe what went wrong.
This homebrew no longer works.
The homebrew is called "Rick Dangerous Wii".
What steps will reproduce the problem?
Get the homebrew and try and play it. Will hang on a black screen immediately,
Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.
Yes, 5.0-15874
Is the issue present in the latest stable version?
Yes, 5.0
If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)
4.0-2543 (Plays fine)
4.0-2547 (Audio plays way too fast) -> https://github.com/dolphin-emu/dolphin/pull/762
4.0-9345 (No change. Audio still plays way too fast)
4.0-9347 (Game no longer boots) -> https://github.com/dolphin-emu/dolphin/pull/3829
(The second PR mentions the first one, so they are related.)
If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer
[Attach any fifologs if possible, write a description of fifologs and screenshots here to assist people unfamiliar with the game.]
What are your PC specifications? (CPU, GPU, Operating System, more)
i7-8750H
GTX 1060
Windows 10
8GB DDR4
Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)
Let me know, I'll see what else I can do.
Files
| Capture d’écran 2022-07-05 110948.png (34.6 KB) Capture d’écran 2022-07-05 110948.png | Massouille, 07/05/2022 09:10 AM |
Updated by pokechu22 over 2 years ago
The game is described at https://wiibrew.org/wiki/Rick_Dangerous_Wii and available at https://web.archive.org/web/20150204191844/http://www.gouky.com/game/RickWii_10.zip. It doesn't work even with DSP LLE Recompiler or Interpreter.
Updated by pokechu22 over 2 years ago
I was unable to get the game to boot on either of my Wiis (both of which have BootMii as boot2, but I tried both directly launching it from the homebrew channel, booting to the homebrew channel, then opening the system menu and going back to the homebrew channel, and removing my SD card so it boots to the system menu and then launching the homebrew channel). One has 4.3U, and the other has 4.1U. Both have progressive video output disabled (because that's how my cables are currently set up, though I can use component cables if needed; it'll just require some annoying cable management).
The talk page on the wiki has one other user reporting that they were unable to get it to boot.
I also was able to start it in Dolphin 4.0-2543, but rendering was weird on the menu (fixed by setting the texture cache accuracy to safe), and when I started the game, it immediately opened the pause menu and Dolphin crashed upon trying to close it (by pressing the home button, at least).
Are you able to get it to run on your own Wii? If so, are there any settings you recommend I try?
Updated by Massouille almost 2 years ago
Hello,
I have the same problem, don’t boot on my real Wii 4.3 and don’t boot on the last dolphin version.
Updated by Massouille almost 2 years ago
https://m.youtube.com/watch?v=8CxdPjHGask
It is ok on old dolphin version ?
Updated by pokechu22 almost 2 years ago
- Status changed from New to Accepted
I've investigated a bit further.
The main thing that jumps out is that this is spammed a TON in the logs (as in it shows up thousands of times in a .03 seconds):
48:21:091 Core\HW\DSP.cpp:392 I[AI]: Audio DMA configured: 120 blocks from 0x00497480
After looking at the relevant code for #12281 (and PR 10741) I have a bit of a better idea of how this audio DMA system is supposed to work. I also looked at what the game's doing; here's the relevant function (at 8003b6a4) that gets called when an audio DMA interrupt occurs:
void AIDCallback(void)
{
AUDIO_StopDMA();
AUDIO_InitDMA(AudioDMAAddresses[AudioDMAIndex],AudioDMABlockCount);
AUDIO_StartDMA();
FUN_8004fbc4(DAT_80138bc8);
return;
}
When a new DMA is started, we trigger an interrupt a bit later, as long as no DMA was already active. But here, they call AUDIO_StopDMA beforehand, so no DMA is ever active, and thus AUDIO_StartDMA causes an interrupt, which ends up calling AIDCallback, resulting in an infinite loop.
I've come up with two possible fixes (the blank - and + lines are to work around a redmine whitespace limitation; you can use these patches with cat /dev/clipboard | git apply):
diff --git a/Source/Core/Core/HW/DSP.cpp b/Source/Core/Core/HW/DSP.cpp
index 5edc5314a5..e63fdffc15 100644
--- a/Source/Core/Core/HW/DSP.cpp
+++ b/Source/Core/Core/HW/DSP.cpp
@@ -376,28 +376,29 @@ void RegisterMMIO(MMIO::Mapping* mmio, u32 base)
// Audio DMA MMIO controlling the DMA start.
mmio->Register(
base | AUDIO_DMA_CONTROL_LEN, MMIO::DirectRead<u16>(&s_audioDMA.AudioDMAControl.Hex),
MMIO::ComplexWrite<u16>([](u32, u16 val) {
- bool already_enabled = s_audioDMA.AudioDMAControl.Enable;
+ bool already_enabled =
+ s_audioDMA.AudioDMAControl.Enable || s_audioDMA.remaining_blocks_count != 0;
s_audioDMA.AudioDMAControl.Hex = val;
-
+
// Only load new values if were not already doing a DMA transfer,
// otherwise just let the new values be autoloaded in when the
// current transfer ends.
if (!already_enabled && s_audioDMA.AudioDMAControl.Enable)
{
s_audioDMA.current_source_address = s_audioDMA.SourceAddress;
s_audioDMA.remaining_blocks_count = s_audioDMA.AudioDMAControl.NumBlocks;
-
+
INFO_LOG_FMT(AUDIO_INTERFACE, "Audio DMA configured: {} blocks from {:#010x}",
s_audioDMA.AudioDMAControl.NumBlocks, s_audioDMA.SourceAddress);
-
+
// We make the samples ready as soon as possible
void* address = Memory::GetPointer(s_audioDMA.SourceAddress);
AudioCommon::SendAIBuffer((short*)address, s_audioDMA.AudioDMAControl.NumBlocks * 8);
-
+
// TODO: need hardware tests for the timing of this interrupt.
// Sky Crawlers crashes at boot if this is scheduled less than 87 cycles in the future.
// Other Namco games crash too, see issue 9509. For now we will just push it to 200 cycles
CoreTiming::ScheduleEvent(200, s_et_GenerateDSPInterrupt, INT_AID);
}
}));
Patch BPatch B
diff --git a/Source/Core/Core/HW/DSP.cpp b/Source/Core/Core/HW/DSP.cpp
index 5edc5314a5..e63fdffc15 100644
--- a/Source/Core/Core/HW/DSP.cpp
+++ b/Source/Core/Core/HW/DSP.cpp
@@ -376,28 +376,23 @@ void RegisterMMIO(MMIO::Mapping* mmio, u32 base)
// Audio DMA MMIO controlling the DMA start.
mmio->Register(
base | AUDIO_DMA_CONTROL_LEN, MMIO::DirectRead<u16>(&s_audioDMA.AudioDMAControl.Hex),
MMIO::ComplexWrite<u16>([](u32, u16 val) {
bool already_enabled = s_audioDMA.AudioDMAControl.Enable;
s_audioDMA.AudioDMAControl.Hex = val;
-
+
// Only load new values if were not already doing a DMA transfer,
// otherwise just let the new values be autoloaded in when the
// current transfer ends.
if (!already_enabled && s_audioDMA.AudioDMAControl.Enable)
{
s_audioDMA.current_source_address = s_audioDMA.SourceAddress;
s_audioDMA.remaining_blocks_count = s_audioDMA.AudioDMAControl.NumBlocks;
-
+
INFO_LOG_FMT(AUDIO_INTERFACE, "Audio DMA configured: {} blocks from {:#010x}",
s_audioDMA.AudioDMAControl.NumBlocks, s_audioDMA.SourceAddress);
-
+
// We make the samples ready as soon as possible
void* address = Memory::GetPointer(s_audioDMA.SourceAddress);
AudioCommon::SendAIBuffer((short*)address, s_audioDMA.AudioDMAControl.NumBlocks * 8);
-
- // TODO: need hardware tests for the timing of this interrupt.
- // Sky Crawlers crashes at boot if this is scheduled less than 87 cycles in the future.
- // Other Namco games crash too, see issue 9509. For now we will just push it to 200 cycles
- CoreTiming::ScheduleEvent(200, s_et_GenerateDSPInterrupt, INT_AID);
}
}));
After PR 10741 the patches become
Patch A updatedPatch A updated
diff --git a/Source/Core/Core/HW/DSP.cpp b/Source/Core/Core/HW/DSP.cpp
index 96467284fc..c0700322e3 100644
--- a/Source/Core/Core/HW/DSP.cpp
+++ b/Source/Core/Core/HW/DSP.cpp
@@ -376,25 +376,26 @@ void RegisterMMIO(MMIO::Mapping* mmio, u32 base)
// Audio DMA MMIO controlling the DMA start.
mmio->Register(base | AUDIO_DMA_CONTROL_LEN,
MMIO::DirectRead<u16>(&s_audioDMA.AudioDMAControl.Hex),
MMIO::ComplexWrite<u16>([](u32, u16 val) {
- bool already_enabled = s_audioDMA.AudioDMAControl.Enable;
+ bool already_enabled =
+ s_audioDMA.AudioDMAControl.Enable || s_audioDMA.remaining_blocks_count != 0;
s_audioDMA.AudioDMAControl.Hex = val;
-
+
// Only load new values if we're not already doing a DMA transfer,
// otherwise just let the new values be autoloaded in when the
// current transfer ends.
if (!already_enabled && s_audioDMA.AudioDMAControl.Enable)
{
s_audioDMA.current_source_address = s_audioDMA.SourceAddress;
s_audioDMA.remaining_blocks_count = s_audioDMA.AudioDMAControl.NumBlocks;
-
+
INFO_LOG_FMT(AUDIO_INTERFACE, "Audio DMA configured: {} blocks from {:#010x}",
s_audioDMA.AudioDMAControl.NumBlocks, s_audioDMA.SourceAddress);
-
+
// TODO: need hardware tests for the timing of this interrupt.
// Sky Crawlers crashes at boot if this is scheduled less than 87 cycles in the
// future. Other Namco games crash too, see issue 9509. For now we will just
// push it to 200 cycles
CoreTiming::ScheduleEvent(200, s_et_GenerateDSPInterrupt, INT_AID);
}
}));
Patch B updatedPatch B updated
diff --git a/Source/Core/Core/HW/DSP.cpp b/Source/Core/Core/HW/DSP.cpp
index 96467284fc..8f9ca4b8a3 100644
--- a/Source/Core/Core/HW/DSP.cpp
+++ b/Source/Core/Core/HW/DSP.cpp
@@ -376,25 +376,19 @@ void RegisterMMIO(MMIO::Mapping* mmio, u32 base)
// Audio DMA MMIO controlling the DMA start.
mmio->Register(base | AUDIO_DMA_CONTROL_LEN,
MMIO::DirectRead<u16>(&s_audioDMA.AudioDMAControl.Hex),
MMIO::ComplexWrite<u16>([](u32, u16 val) {
bool already_enabled = s_audioDMA.AudioDMAControl.Enable;
s_audioDMA.AudioDMAControl.Hex = val;
-
+
// Only load new values if we're not already doing a DMA transfer,
// otherwise just let the new values be autoloaded in when the
// current transfer ends.
if (!already_enabled && s_audioDMA.AudioDMAControl.Enable)
{
s_audioDMA.current_source_address = s_audioDMA.SourceAddress;
s_audioDMA.remaining_blocks_count = s_audioDMA.AudioDMAControl.NumBlocks;
-
+
INFO_LOG_FMT(AUDIO_INTERFACE, "Audio DMA configured: {} blocks from {:#010x}",
s_audioDMA.AudioDMAControl.NumBlocks, s_audioDMA.SourceAddress);
-
- // TODO: need hardware tests for the timing of this interrupt.
- // Sky Crawlers crashes at boot if this is scheduled less than 87 cycles in the
- // future. Other Namco games crash too, see issue 9509. For now we will just
- // push it to 200 cycles
- CoreTiming::ScheduleEvent(200, s_et_GenerateDSPInterrupt, INT_AID);
}
}));
Both Patch A and Patch B work correctly for Rick Dangerous (after working around some other problems, see below). However, I don't think either patch is correct. With PR 10741, on Action Replay, Patch A results in corrupt sounds for the longer sound effects, while Patch B results in sounds playing twice.
Patch A results in this being being logged once:
48:21:091 Core\HW\DSP.cpp:392 I[AI]: Audio DMA configured: 120 blocks from 0x00497480
while Patch B results in repeated logging of this (but at a semi-reasonable rate):
43:25:083 Core\HW\DSP.cpp:392 I[AI]: Audio DMA configured: 120 blocks from 0x00497480
43:25:112 Core\HW\DSP.cpp:392 I[AI]: Audio DMA configured: 120 blocks from 0x0049b0a0
I think Patch B is more correct here since there is other code that changes AudioDMAIndex between 0 and 1 (and AudioDMAAddresses contains 0x00497480 and 0x0049b0a0), which seems like it should be run, but I don't hear a difference between the two.
In addition to fixing the audio DMA issue, the game also crashes unless MMU is disabled (and even with MMU disabled you get several "Invalid read from 0x0000000c, PC = 0x8004a080" messages, but the game will boot if you ignore them). I'll investigate why that happens. It also crashes if you press the HOME button (which presumably would return to the program that loaded it, something that generally doesn't work in Dolphin). The screen is also cut off slightly (which matches with the video you showed, and is also mentioned on the wiibrew article).
I also got confused before about the controls; sideways wii remote is needed, and pressing + during the opening cutscene skips it and opens the pause menu. To close the pause menu, you need to press 1 (not 2 like I expected). After pressing 1 (or just not skipping the opening cutscene) everything seems to work fine.
Updated by pokechu22 almost 2 years ago
The crash that disabling MMU bypasses is a libogc bug: https://github.com/devkitPro/libogc/commit/8a12a333492311489bc079f2a5b4679d3fde5f3d (this is something to do with USB, but I'm not sure what conditions would allow it to work on real hardware).
Updated by pokechu22 almost 2 years ago
The MMU-related crash can be fixed by hex-editing the DOL: at offset 0x46164, replace 4800001c with 4800004c, and at offset 46170, replace 419e0010 with 419e0040.
This fixes the libogc bug by changing
for(i=0;i<((u8_t *)p->payload)[0];i++) {
resp_off = i*4;
hci_dev->acl_max_pkt += le16toh(*((u16_t *)(((u8_t *)p->payload) + 3 + resp_off)));
connhdl = le16toh(*((u16_t *)(((u8_t *)p->payload) + 1 + resp_off)));
for(link = hci_active_links; link != NULL; link = link->next) {
if(link->connhdl == connhdl) break;
}
q = link->p;
/* Queued packet present? */
if (q != NULL) {
/* NULL attached buffer immediately */
link->p = NULL;
/* Send the queued packet */
lp_acl_write(&link->bdaddr, q, link->len, link->pb);
/* Free the queued packet */
btpbuf_free(q);
}
}
break;
into
for(i=0;i<((u8_t *)p->payload)[0];i++) {
resp_off = i*4;
hci_dev->acl_max_pkt += le16toh(*((u16_t *)(((u8_t *)p->payload) + 3 + resp_off)));
connhdl = le16toh(*((u16_t *)(((u8_t *)p->payload) + 1 + resp_off)));
for(link = hci_active_links; link != NULL; link = link->next) {
if(link->connhdl == connhdl) {
q = link->p;
/* Queued packet present? */
if (q != NULL) {
/* NULL attached buffer immediately */
link->p = NULL;
/* Send the queued packet */
lp_acl_write(&link->bdaddr, q, link->len, link->pb);
/* Free the queued packet */
btpbuf_free(q);
}
break;
}
}
}
break;
The original DOL has an MD5 of 2fe637d8fc6a2ab9d0ad007fd6c73759, and the patched one has a MD5 of b753880862c7a4e4e039f013af3caf7a.
This patch can also be done using Dolphin's patching system:
[OnFrame_Enabled]
$Fix USB-related libogc crash bug
[OnFrame]
$Fix USB-related libogc crash bug
0x8004A064:dword:0x4800004C
0x8004A070:dword:0x419E0040
Unfortunately, it seems like this patch does not cause the game to work on real hardware, at least for me; it still hangs on a black screen. It does remove the requirement of disabling MMU on Dolphin, though (but it doesn't fix the main "Audio DMA configured" issue).
Updated by Massouille almost 2 years ago
Hello, thanks for this explication and work. I have modified my original DOL, new MD5 is b753880862c7a4e4e039f013af3caf7a.
But on Dolphin last version stable, I have the same error, black screen.
Thanks in advance
Updated by pokechu22 almost 2 years ago
Sorry, I was a bit unclear. The hex-editing I suggested in comment 7 is a workaround for a second issue, but it doesn't help unless the main issue is fixed. Comment 5 contains two separate ways that the main issue could be fixed (in the form of changes you can make when compiling Dolphin yourself), but both of them have downsides for other games and thus I haven't submitted either of them as pull requests that could be included in stable dolphin.
Updated by pokechu22 almost 2 years ago
- Related to Emulator Issues #12498: Syobon Action Wii (Homebrew) Doesn't Work added
Updated by pokechu22 almost 2 years ago
Based on #12498, it's possible to boot the game if you set the emulated CPU clock override to 10%. This seems to work even without the patch I made above.
Updated by Massouille almost 2 years ago
Hello,
Perfect, when I modify the emulator configuration : game correct boot.
Now, I want create a ini file to set parameter with :
DGGA.ini
[Core]
OverclockEnable = True
Overclock = 0.1
I have a doubt, what is the gameId of the game?
That's good: DGGA?
https://www.gametdb.com/Wii/DGGA
Because when I'm on Dolphin, I don't see the game, so I don't see the gameId of the game (see screenshot)
Dolphin don't see my *.DOL file, I have to open the game via the Open file menu
Thanks in advance for your help
Updated by Massouille almost 2 years ago
Aie, Sorry, my extension file was .DOL and not .dol
ID game is : ID-DGAA
Thanks
Updated by pokechu22 almost 2 years ago
5.0-14344 is over a year old; there was an issue with .DOL instead of .dol, but that was fixed in 5.0-15903 5 months ago. It should be a lot easier to create a custom gameini for it as such. (However, for a file named RickWii.DOL or RickWii.dol, the ID would be ID-RickWii. DGGA is (presumably) used if you installed it as a channel to the Wii menu (using WAD tools of some sort).)
Updated by Massouille almost 2 years ago
Hello,
I updated Dolphin to the latest version of the site, thanks.
Now when I play, I have game freezes, every 3 to 5 seconds or game lags.
What settings can I change?
Thanks in advance,
Have a good day,
Updated by pokechu22 over 1 year ago
- Related to Emulator Issues #9410: Audio Crackling in Homebrew Demo, not present on 4.0.2 added