Emulator

Just did some retesting with Maxplay in 5.0-6004, which is likely of interest.

With Dual Core just a single "FIFO is overflowed by GatherPipe ! CPU thread is too fast!" error occurs. With Single Core the error now happens numerous times, until a separate Unknown Opcode error occurs. The top part of the first screen then starts to show and when Dolphin hangs without further error, only showing the top 20% or so of the screen.

This was impacted by 5.0-15579 (https://github.com/dolphin-emu/dolphin/pull/1024); in single-core, the large number of error popups still appear (tested via MaxPlay, Max Drive Pro, and Action Replay Max), but the titles boot after them instead of hanging on a black screen. I haven't done extensive testing with regards to stability ingame though.

I assume the pull request linked to should be https://github.com/dolphin-emu/dolphin/pull/10244

There doesn't appear to be a build for 5.0-15579 though

SD Media Launcher (JP) hangs, and I looked into this a bit. It seems like Datel just messed up.

The hang is due to GXDrawDone not being implemented correctly. Here's Datel's implementation (800104a0 in SD Media Launcher):

void GX_DrawDone(void)
{
  int iVar1;
  undefined4 uVar2;

  uVar2 = _CPU_ISR_Disable();
  write_volatile_1(wgPipe,0x61);
  write_volatile_4(wgPipe,0x45000002);
  GX_Flush();
  _CPU_ISR_Disable(uVar2);
  write_volatile_4(_gxfinished,0);
  do {
    iVar1 = read_volatile_4(_gxfinished);
  } while (iVar1 == 0);
  return;
}

Compare the implementation from Super Mario Sunshine:

void gx::GXDrawDone(void)
{
  undefined4 uVar1;
  
  uVar1 = os::OSDisableInterrupts();
  write_volatile_1(wgPipe._0_1_,0x61);
  write_volatile_4(wgPipe,0x45000002);
  GXFlush();
  DrawDone = '\0';
  os::OSRestoreInterrupts(uVar1);
  uVar1 = os::OSDisableInterrupts();
  while (DrawDone == '\0') {
    os::OSSleepThread(&FinishQueue);
  }
  os::OSRestoreInterrupts(uVar1);
  return;
}

_gxfinished is supposed to be set to 0, and then set to 1 by an interrupt. However, Datel enables interrupts before setting _gxfinished to 0, so it's possible for the interrupt trigger, setting _gxfinished to 1, and then _gxfinished gets set to 0 by GX_DrawDone and the loop never terminates. This is what the timing hack attempted to fix - if it takes longer for the interrupt to trigger, then it's likely that it'll never hang. (The value we currently use, 500, is still too fast.) The following memory patch works:

$SD Media Launcher (JP) GXDrawDone patch
0x800104E4:dword:0x3D20800C:0x480094B9
0x800104E8:dword:0x38000000:0x3D20800C
0x800104EC:dword:0x3D60800C:0x38000000
0x800104F0:dword:0x9009BC94:0x3D60800C
0x800104F4:dword:0x480094A9:0x9009BC94

There's a second bug that causes the "FIFO is overflowed by GatherPipe" messages: GXInitFifoPtrs (called by GXInit) is also wrong. Here's Datel's version:

void GX_InitFifoPtrs(gxfifo *fifo,undefined *rd_ptr,undefined *wt_ptr)
{
  _CPU_ISR_Disable();
  fifo->rd_ptr = (uint)rd_ptr;
  fifo->wt_ptr = (uint)wt_ptr;
  fifo->rdwt_dst = (int)wt_ptr - (int)rd_ptr;
  if ((int)wt_ptr - (int)rd_ptr == 0) { // should be < 0
    fifo->rdwt_dst = fifo->size; // should be += size
  }
  _CPU_ISR_Disable();
  return;
}

while Super Mario Sunshine uses:

void gx::GXInitFifoPtrs(gxfifo *fifo,undefined *rd_ptr,undefined *wt_ptr)
{
  os::OSDisableInterrupts();
  fifo->rd_ptr = (uint)rd_ptr;
  fifo->wt_ptr = (uint)wt_ptr;
  fifo->rdwt_dst = (int)wt_ptr - (int)rd_ptr;
  if ((int)fifo->rdwt_dst < 0) {
    fifo->rdwt_dst = fifo->rdwt_dst + fifo->size;
  }
  os::OSRestoreInterrupts();
  return;
}

GXInitFifoPtrs is called with rd_ptr == wt_ptr, so this ends up making rdwt_dst be size (0x40000), which generally messes things up (I still don't fully understand how it's supposed to work, though). This seems to result in 0x40000 bytes of additional graphics data that needs to be decoded, all of which is just whatever junk is already in memory. (For SD Media Launcher, this is all 0xA8 bytes, which completely hangs things as this corresponds to an impossibly large GX_DRAW_LINES.)

If the fifo->rdwt_dst assignment instruction at 80014ef4 is nopped out, then no "FIFO is overflowed by GatherPipe" or unknown opcode messages are logged. Note that a per-frame patch doesn't work for this, as the code is called before any frame gets rendered.

Both of these probably apply to all Datel titles, but the code is located at different places in each title, so it'd require writing the same patch a bunch of times.

(Libogc's GX_InitFifoPtrs also seems to incorrectly set rd_ptr to rdwt_dst + size, but that won't happen with rd_ptr == wt_ptr, so it probably isn't relevant here.)