SIO/MCD: hugely improved memcard swapping + reinsertion + Fix per game cards

[refractionpcsx2]

Description of Changes

Hugely improves swapping of memcards and reinserting (especially when loading a savestate).

Rationale behind Changes

Initially I just wanted to fix a bug I introduced with it not loading game specific memcards due to a chicken/egg problem with loading memory cards, I've kinda rewritten some of how that's done and centralised some of the code.

The second problem was one which has plagued PCSX2 since the beginning, reinserting memory cards on "swap". Previously we just ejected it and told the PS2 we were disconnected for 60 reads, and this kinda worked, but it was very unreliable, plus it was very annoying for people loading states as you had to keep retrying until it eventually worked.

The solution turned out to be simple. When the PS2 boots, the terminator for the memcard is set to 0x55, mcman picks this value up as "Uninitialized", then it does it's auth/setup dance and sets the card up. Previously we didn't change this back, so the PS2 didn't realise the card had been ejected, but now we reset it, and it seems to work very well. This means I have set the "reinsert" time to 1 second, so it won't stay ejected for long at all, and this seems to be reliable, and Ratchet & Clank no longer complains, it gracefully reinserts the memcard.

Suggested Testing Steps

⚠️ I recommend using a copy of your memcard for testing! I think it's fine but if it's not it could erase your memcard! ⚠️

Test fast booting games, full booting, going in to the bios then swapping in a disc, all three tests again with a game which has per game memcards which are different to the global ones, lastly try making a savestate in a game which reads the memcards constantly (Ratchet & Clank, or I believe GT4? I could be wrong), then change your memcard and reload that state, it should reinsert gracefully.

And no it will still toast your memcard if you shut down the emu/eject the card while it's saving!

Fixes #9032

[RedPanda4552]

A little bit odd imo to tick down the insert timer in CDVD but probably still serviceable. I echo sten's review and that's about all I have the brain power to work out right now.

[refractionpcsx2]

A little bit odd imo to tick down the insert timer in CDVD but probably still serviceable. I echo sten's review and that's about all I have the brain power to work out right now.

That was intentional to keep the time based in console land, so it's 1 second of "console" time, so even if they have it in fast forward, it's not waiting forever (in console space) waiting for 1 real world second :) That said, depending on timing, it might be less than 1 second.

We might get away with not even having the whole fake eject dance, and just reset the terminator, but I wanted to be a bit safer.

[RedPanda4552]

That was intentional to keep the time based in console land, so it's 1 second of "console" time, so even if they have it in fast forward, it's not waiting forever (in console space) waiting for 1 real world second :) That said, depending on timing, it might be less than 1 second.

We might get away with not even having the whole fake eject dance, and just reset the terminator, but I wanted to be a bit safer.

Fair enough, but I do wonder if Counters.cpp would still be viable since vsyncs scale with speed. Or maybe it doesn't matter.

I would still keep the ejection action even though resetting the terminator might be enough on its own. Of course any time the card is inserted it is going to default it's terminator and we know the IOP module is checking for that. But additionally if we are trying to simulate yanking the card and putting it back in, well, during the ejection time, any commands sent over the rail are going to return dead air for data. So it's probably of no consequence, but imo still a good idea to report the card as missing during the eject so commands can still fail as if there was no device at all. Just resetting the terminator could imply the card was never ejected but just has some kind of reset or fault.

[refractionpcsx2]

Yeah I agree, simulating the card being removed isn't the worst thing, and I don't want to rock the boat too much with it!

As for counters, I'm not sure, the CDVD is controlling the Real Time Clock, which is where I placed it, we could count 60 vsyncs or whatever, but then do we scale that for PAL? it could start getting out of control, I guess :P Another advantage of this way, adding a second on the CDVD is less hot code that the counters/vsync code, which gets called quite a bit, and this would mean adding the loop through all the memcards every frame.

[RedPanda4552]

Fair enough. Rest of the memcard bits seem fine to me.

[refractionpcsx2]

Thanks for checking it :)