Fix gamecube games not noticing disc changes

[Pokechu22]

Fixes issue 9019.

The problems:

• Changing a disc reset the drive state completely (which was something I added in 55a88ba). This included the DI registers, meaning interrupts would no longer be sent (so the drive errors that were supposed to be sent in that case just weren't making it anywhere). Now it only resets "internal" properties. I don't know if this is 100% accurate behavior (and I only changed it for disc changes; other places that reset it were not changed)

• Although that allowed games to detect disc errors if they happened on e.g. request stream status, they still didn't care about errors on the read command (which are far more likely). This happened to be because games look at DILENGTH, and if it's 0 they assume the read was successful even if DEINT was fired instead of TCINT. I touched related code in 3110599 but didn't actually think about the error case. Note that YAGCD mentions that DILENGTH can indicate the amount of data left over for transfer, but it isn't explicit about that being used in errors.

  One possible change here is that it might be possible for commands (especially reads) to fail partway through, in which case DILENGTH would maybe be half-updated instead of the current all-or-nothing situation. But all-or-nothing seems sufficient for most games.

• There were some other inaccuracies with drive state behavior, based on attempts at reverse-engineering the drive firmware. There are some old half-archived notes here, which was enough for me to get started (but it's very hard to understand). These changes required a savestate version bump.

  One thing this fixes (when combined with the other changes) is the AudioStream command, which gave the wrong error code in some states, which games wouldn't know what to do with and would then crash.

  A note: at least with Alien Hominid, if a game using DTK is ejected while it is streaming, upon reinsertion it'll start the stream from the beginning again. I tested and confirmed this behavior on console (specifically my Wii).

[Pokechu22]

I've added some new fixes for resetting the drive from the emulated software (both on GameCube and Wii). This allows removal of a hack where the drive would act as if it was spun up when reading the disc ID, even if it shouldn't have been in that state. It also fixes bug 12017 (caused by MaxPlay stopping the motor and then resetting the drive; since the reset wasn't implemented it would error since, well, the motor was stopped).

Note that I have not hardware tested the exact behavior of PI_RESET_CODE. However, code definitely expects that clearing bit 4 resets DI.

Take a look at DVDLowReset (from Scooby-Doo! Mystery Mayhem).

void DVDLowReset(void)
{
  uint uVar1;
  uint reset;
  undefined8 uVar3;
  undefined8 uVar4;
  write_volatile_4(DICVR,2);
  reset = read_volatile_4(PI_RESET_CODE);
  write_volatile_4(PI_RESET_CODE,reset & 0xfffffffb | 1);
  uVar3 = __OSGetSystemTime();
  uVar1 = DAT_800000f8 >> 2;
  do {
    uVar4 = __OSGetSystemTime();
  } while (((int)((ulonglong)uVar4 >> 0x20) -
            ((uint)((uint)uVar4 < (uint)uVar3) + (int)((ulonglong)uVar3 >> 0x20)) ^ 0x80000000) <
           (uint)((uint)uVar4 - (uint)uVar3 < (uVar1 / 0x1e848) * 0xc >> 3) + 0x80000000);
  write_volatile_4(PI_RESET_CODE,reset | 5);
  ResetOccurred = 1;
  uVar3 = __OSGetSystemTime();
  LastResetEnd._0_4_ = (int)((ulonglong)uVar3 >> 0x20);
  LastResetEnd._4_4_ = (int)uVar3;
  return;
}

Datel's implementation is similar, but they use a busy loop (which Ghidra produces something more readable for).

void DVDLowReset(void)
{
  uint reset;
  uint cvr;
  int i;
  write_volatile_4(DICVR,2);
  reset = read_volatile_4(PI_RESET_CODE);
  write_volatile_4(PI_RESET_CODE,reset & 0xfffffffb | 1);
  i = 0;
  do {
    i = i + 1;
  } while (i < 0x80000);
  write_volatile_4(PI_RESET_CODE,reset | 5);
  write_volatile_4(DISR,0x2a);
  cvr = read_volatile_4(DICVR);
  write_volatile_4(DICVR,cvr);
  DAT_802b9ae4 = FUN_8006f8fc();
  DAT_802b9ae0 = DAT_802b9ae4 >> 0x1f;
  DAT_80318ed4 = 1;
  return;
}

I've also marked functions local to DVDInterface as static (as was originally mentioned in #3582). Now's as good a time as any to do that.

[Pokechu22]

I'm less sure that MIOS is even supposed to reset DI in the first place. It does make some writes to PI_RESET_CODE, but I haven't seen it actually write anything other than 7 (there is code that can do it, but I don't think it's live). Of course, if it did write something else, that would be properly emulated because we actually run (the PPC part of) MIOS. I don't see any writes to it from the ARM part of MIOS, nor from BC, but I might be missing them.

I also did a very basic hardware test of listening to the disc drive while launching a GameCube game; it didn't sound like it triggered a reset.

[Pokechu22]

Rebasing to fix conflict with #8733 (i.e. don't change DILENGTH/DIMAR in the case of NoReply and DTK, and also only change it on successful transfers)...

[GitToTheHub]

Great work, thank you!