Make card harmless when plugged in ps2 mode into ps1

[max-las]

A single sd2psXtd card can easily hold both the PS1 and PS2 saves of an avid player. Therefore one could be tempted to use the same card on their PS1 and PS2 consoles. But currently there is a risk: if the card is set to PS2 mode for use on a PS2, and then later plugged into a PS1 (or worse, PS1 multitap) while still in PS2 mode, it can damage the console or the multitap.

That is because a PS2 memory card has to act push-pull to keep up with PS2 clock. Meanwhile on a PS1 the controller and the memory card share the same bus. As long as both memory card and controller act open drain, everything is fine. But if the memory card starts pushing high, then each time the controller pulls low there is a short. And that happens constantly in response to the console constantly polling the controller.

This PR attempts to mitigate this risk by initializing the involved pins as open drain or Hi-Z, and switching them to push-pull only when the host has been confirmed to be a PS2. This is asserted by watching for the 0x11 subcommand, which should be first subcommand a PS2 emits towards a newly inserted memory card, whereas a PS1 should theoretically never emit that byte as a memory card subcommand. I have tested this on my own PS2 and SuperStation One (I do not own a genuine PS1) and can confirm the PS2 is properly and exclusively detected.

With that, players won't have to worry anymore about which state they left the card in the last time they played. If they forgot it's in PS2 mode and insert it into a PS1 / PS1 multitap, it should be fine.

It's not foolproof, though. At least two edge cases where the pins can still be driven high under a PS1:

• Some PS1 homebrew emits 0x11 memory card subcommand, which trigger PS2 detection
• The card is booted under a PS2 then moved to a PS1 while still being powered on. Possible using a USB-C cable, unlikely to happen by accident.

Therefore I haven't completely removed the warnings in the README and GUI, but I made them less alarming.

I'm looking forward for your feedbacks

[bbsan2k]

This is also a good fix. The only problem I see:
The 0x11 command now seems to be answered by 0xFF instead of 0x2B when first being issued. This should not be breaking the communication since there will be 4 re-tries, although it is not optimal.
Have you tried if this does still work wit FMCB images?

Also: Please retarget to develop, since main is only intended for releases.

[max-las]

Right. I've updated the logic to properly respond to 0x11, and tested with FMCB 1.966 image: it works

[bbsan2k]

Thank you 😊