Emulator

Yeah, it looks like the game is crashing now.

Have never played in enough to determine, but there was also an older crash issue with this title on the wiki...
"After completion of the third scam there is an error that causes a crash in which you cannot move on to the fourth scam."

Reported as also effecting Scooby-Doo! Night of 100 Frights, refer:
https://forums.dolphin-emu.org/Thread-gc-scooby-doo-night-of-100-frights?pid=468139#pid468139

Though Scooby-Doo! Night of 100 Frights is apparently working at least through 5.0-4607, so if this started in 5.0-2431 the Scooby-Doo! crash may be a different issue.

I thought they originally both broke the first time on the same version?

I think I just bought Scooby Doo in my last pile of shovelware so maybe I can actually report back.

Just chiming in to inform that this issue is still present :(

And yeah, a workaround is to set CPU override to like 6% for the loading, and then disable it.

This might be dcache issues...

I fixed this issue on my machine by deleting every trace of the emulator from my computer and reinstalling it. Including registry entries.

I think I've found the root cause of this... it looks like a timing issue.

The game uses asynchronous I/O with double buffering to read from the DVD and upload the data ARAM:

void __fastcall read_complete_callback2_80121BC0(int currrent_chunk_size)
{
  void *current_chunk; // r30
  int aram_destination; // r31
  arq_manager *v4; // r3
  arq_manager *v5; // r0
  arq_request *arq_request; // r3
  unsigned int next_read_size; // r31
  int file_offset; // [sp+8h] [-18h]

  DCFlushRange(buffer2_803D352C, 0x8000);
  current_chunk = buffer2_803D352C;
  aram_destination = aram_base_803D3530 + aram_bytes_copied_803D628C;
  if ( !arq_request_manager_803D3968 )
  {
    v4 = (arq_manager *)new_800D643C(0x382Cu);
    v5 = v4;
    if ( v4 )
      v5 = init_arq_manager_801188C0(v4);
    arq_request_manager_803D3968 = v5;
  }
  arq_request = allocate_arq_request_8011A178(arq_request_manager_803D3968, 0);
  if ( !arq_request )
    while ( 1 ) { }
  ARQPostRequest_80155944(
    arq_request,
    arq_request,
    0,
    1,
    current_chunk,
    aram_destination,
    currrent_chunk_size,
    arq_complete_callback_80121E08);
  file_offset = 0;
  tell_8010393C(&current_file_803D6290, &file_offset);
  next_read_size = ((file_length_803D6294 + 31) & 0xFFFFFFE0) - file_offset;
  if ( chunk_size_803D9710 < next_read_size )
    next_read_size = chunk_size_803D9710;
  if ( next_read_size )
  {
    sub_80102D2C(&dword_8038AAEC, current_file_803D6290);
    read_from_dvd_async_8010368C(
      &current_file_803D6290,
      buffer1_803D3528,
      next_read_size,
      // identical to this function but with buffer1 and buffer2 swapped
      read_complete_callback1_80121BC0);
  }
}

Each time a chunk is uploaded to ARAM it counts up the number of bytes written until the whole file has been uploaded, then sets a global flag indicating this asynchronous file load is complete:

void __fastcall arq_complete_callback_80121E08(arq_request *req)
{
  arq_request *self; // r31
  arq_manager *allocation; // r3
  arq_manager *manager; // r0

  aram_bytes_copied_803D628C += req->dword18;
  if ( aram_bytes_copied_803D628C == file_length_803D6294 )
    aram_upload_complete_803D6298 = 1;
  self = req->self;
  if ( !arq_request_manager_803D3968 )
  {
    allocation = (arq_manager *)new_800D643C(0x382Cu);
    manager = allocation;
    if ( allocation )
      manager = init_arq_manager_801188C0(allocation);
    arq_request_manager_803D3968 = manager;
  }
  self->owner_id = 0;
}

However (without the 6% CPU override hack) "aram_upload_complete_803D6298" never gets set, causing the load to hang. Looking in the debugger, I see that "arq_complete_callback_80121E08" is called the correct number of times. It should add 0x8000 bytes every time, except for the final chunk, which is 0x1160 bytes, but under the debugger it appears to add 0x1160 instead of the second-last value as well.

This is partially explained by "allocate_arq_request_8011A178" returning the same structure every time, because of the 0 argument passed in both "read_complete_callback" functions:

arq_request *__fastcall allocate_arq_request(arq_manager *manager, int owner_id)
{
  arq_manager *v2; // r6
  int i;

  for (i = 0; i < 20; i++)
  {
    if ( manager->requests[i].owner_id == 0 )
    {
      manager->requests[i].owner_id = owner_id;
      return &manager->requests[i];
    }
  }
  return 0;
}

Because of this, I believe the hang will occur if the final 0x1160 byte DVD read completes before the prior 0x8000 byte ARAM upload completes. Unfortunately, I have no idea if DVD reads are too fast or ARAM upload is too slow, so I haven't tried to fix it.

I took a closer look at the current (5.0-12245) emulated timings:

• First, the 0x8000 byte ARAM DMA begins
• 4us later (1914 ticks), the 0x1160 byte DVD read begins
• 433us later (210227 ticks), the DVD read completes
• 81us later (39763 ticks), the ARAM DMA ends

The ARAM DMA duration is 518us (251904 ticks), and the disc read duration is 432us (210227 ticks).

So, at the moment, we're off by a minimum of 81us. It'd work if this disc read were ~20% slower, or this ARAM DMA were ~15% faster (or they met in the middle somehow), but it's not immediately clear what's happening that causes a deviation from the prior hardware measurements. (Could multiple DMAs at the same time cause contention or something?)

I think current ARAM DMA timing is from around 2014 (http://dolp.in/pr1012), and DVD timing is from around 2017 (http://dolp.in/pr4829 - which led to this issue).

My hunch is that the startup latency for reading data out of the DVD controller's cache hasn't been measured in much detail. (I'm assuming that the read in question is cached, since less than 1 ms is very fast.) Right now the startup latency for this is set to the same constant as the startup latency of every other command, including simple ones like "report status". This is just a guess from my side, so I'm not sure that something is wrong with it, but I think it would be a good place to start looking.

(I should probably do so myself at some point, but I haven't been succeeded in bothering to make hardware tests at any point yet...)