Is this a free homebrew? If so can you link to where we can get it?

Yes, it is.
There's the link: https://wii.brewology.com/downloads/download.php?id=10491&mcid=3

Here is the official website with the source code

• https://web.archive.org/web/20160305112938/http://scognito.drunkencoders.com/projects/syobon-action.php
• Source: https://web.archive.org/web/20160314171536/http://scognito.drunkencoders.com/projects/downloads/syobon-action-src.rar

After digging more into the issue, I managed to find why the game doesn't resume. Basically, the audio interrupt is happening too quickly:

• https://github.com/devkitPro/libogc/blob/36f6bef9e1e8cb021a03d041ce0b47b568154d27/libasnd/asndlib.c#L268

This audio interrupt is also preventing Wii/Hollywood IRQs to be processed by libogc:

• IRQ priority: https://github.com/devkitPro/libogc/blob/master/libogc/irq.c#L74
• https://github.com/devkitPro/libogc/blob/master/libogc/irq.c#L254

The WPAD's IOS_IoctvAsync can't be processed due to that. It was initiated by WPAD_Init:

// Functions called from WPAD_Init
WPAD_Init
BTE_Init
physbusif_init
__usb_open
__issue_bulkread
__readbulkdataCB

// Infinite async WPAD loop handled by __readbulkdataCB
__issue_bulkread
USB_ReadBlkMsgAsync(__readbulkdataCB)
__usb_interrupt_bulk_message
IOS_IoctlvAsync(__usbv0_messageCB)

Now, I need to find precisely what makes Dolphin too fast:

• It can be specific instruction timing (for instance, mtspr/mfspr used in epilog/prolog from the exception handler)
• The interrupt timing
• Something else?

I hardware tested the interrupt timing and Dolphin's timing is really close to what the hardware does. Unless there are special cases where its timing can be delayed/canceled (still have to hwtest that), I doubt that's the root cause.

I'll investigate more to see if I can find anything interesting.

I think I have all pieces of the puzzle, now.

Dolphin point of view¶

1. Syobon Action boots up and its main function calls some functions that will produce interrupts later on:

• WPAD_Init
• ASND_Init's AUDIO_StartDMA

2. The game is stuck on a floating-point instruction with FPU disabled (lazy FP context switch) at

80052644 stfdu f14, 0x0008 (r3)

3. It raises an FPU unavailable exception and its handler re-enable FP.

4. However, while resuming at 80052644 the FP instruction isn't processed as the AI interrupt occurs

The one generated by AUDIO_StartDMA

5. It goes through the IRQ handler

• Then, the IRQ dispatcher
• Said dispatcher that calls the audio's DMA callback

6. The Audio DMA callback

• calls AUDIO_StartDMA
• exits early as static vs32 global_pause = 1
• Indeed, the game's ogg_player_thread's ASND_Pause(0) hasn't been called yet

7. Upon exiting the IRQ handler, FP is disabled again

8. Execution resumes at 80052644

80052644 stfdu f14, 0x0008 (r3)
and raises (see 3.) FPU unavailable exception

9. Rinse and repeat from 3.

Summary¶

Unless I did something wrong, here is why the game can't start properly:

• The execution is stuck on a floating point instruction.
• The AI interrupt is the only one processed.
• The FP exception handler takes enough time for the next AI interrupt to be generated.
• It seems more like an execution timing issue than an audio timing issue.

What I tried¶

I created a bunch of hardware tests to check various cases such as audio/interrupt timing and FP exception.
Based on them, I think:

• Dolphin's DMA timing should be good enough
• It seems to happen on real hardware but with another timing (I can't check where it's stuck, though)
  • I used AUDIO_StartDMA's AI interrupt,
  • I forced FP exception in a loop with something like this:

float volatile dummy = 1.0f;

for (u32 i = 0; i < 5; i += 1)
{
    // Trigger FPU unavailable exception
    _CPU_FPR_Disable();
    dummy *= 2.0f;
}

I exhausted most of the things I could think of. I might, at a later point, try to improve MMIO timings to be closer to real hardware. Delaying the audio interrupts (or using CPU clock overriding) allows the FP instructions to be executed properly.