DVDInterface: Mask upper bits of DIMAR in GC mode

[Pokechu22]

The masking was removed in d3aad1d, based on a Wii hardware test. Based on https://bugs.dolphin-emu.org/issues/12970 the masking should apply in GameCube mode, though. (I have not actually tested this, as I do not have easy access to a GameCube.)

[shuffle2]

might be a little better to store mask into a variable at init so you don't need to check bWii each time

[AdmiralCurtiss]

RegisterMMIO() is called twice on initialization and DirectWrite() is a function call that gets a u32, this isn't a callback. Wouldn't change anything.

[Pokechu22]

It's being computed once when RegisterMMIO is called, and then stored in the object returned by DirectWrite.

I assume that RegisterMMIO gets re-called when changing into GC mode from Wii mode (via MIOS/booting from the system menu), though I'm not sure of that (and I'm not sure whether the masking changes when the Wii is in GC mode or not; it's a pain to boot homebrew in GC mode on a Wii though I could theoretically do it).

[shuffle2]

i just put a breakpoint on DVDInterface.cpp!RegisterMMIO and it doesn't get hit when launching GC disc from disc channel in wii menu, good catch :)

I guess we rely on games only accessing the regs from the expected alias in each mode. But it is still bugged in this case I guess.

[Pokechu22]

I've changed it to have it decide which mask to use based on the alias (0x0C006000 for GameCube and 0x0D006000 for Wii, and the Wii one is only registered in Wii mode).

[AdmiralCurtiss]

Is that correct, did you check if writing to 0x0C006000 on a Wii actually results in a different bitmask compared to writing to 0x0D006000? In fact we actually have four combinations here, depending on whether the masking happens on read or on write...

[Pokechu22]

It's almost certainly not correct (and address 0x0C006000 is almost certainly not exposed in Wii mode - in fact 0x0D006000 is also restricted to IOS only unless you have AHBPROT access (which the homebrew channel normally gives with wiiload)). But it should produce correct results.

I have to assume that the masking occurs in GC mode on Wii, as otherwise you could overwrite the parts of MEM2 where ARAM and more importantly MIOS live using homebrew with cleverly-chosen disc reads. But again I haven't verified it. That masking would also only really make sense if it applies on write (if it applies on read, it would presumably also apply when the value of the register is used internally, which would be equivalent to it applying on write).

[AdmiralCurtiss]

What I mean is, in theory you could write the register through 0x0C006000 and then read it through 0x0D006000 (or the other way around), which would behave differently depending on whether the masking is on read or on write. I suppose it matters little in practice -- I doubt any official software can even do this -- but it would be interesting to know.

[Pokechu22]

To clarify: on real Wii hardware, in Wii mode, I don't think 0x0C006000 normally exists at all, while 0x0D006000 does. In GameCube mode, I don't think 0x0D006000 exists, while 0x0C006000 does. On real Wii hardware, if masking ever applies, it would be applied based on whether GameCube mode is in use, not which address is being used to reach the MMIOs. Using the address is mostly a hack to deal with the way we switch into GameCube mode (and RegisterMMIO not being called again in that case).

(There's also the extra complications of virtual addressing (making it 0xCD006000 outside of IOS) and bit 23 controlling what's exposed to the PPC (see Hollywood/Registers) (making IOS use 0x0d806000). Those aren't relevant here.)