ares64 core: Add basic support for the SC64 SD card interface

[Thar0]

This patch adds optional support for the SC64 flashcart's SD card interface in the N64 Ares64 core, exposing an sd.raw file akin to that of Dolphin Emulator's Virtual SD Card feature.

This has come up as part of discussions for TASVideos supporting the movie format produced by the Ocarina of Time Practice ROM (gz) (glankk/gz#96, https://tasvideos.org/Forum/Topics/25847). The Practice ROM can import and export movies and savestates via the SD card interfaces of supported flashcarts, adding support for such an interface to the emulation core could allow judges and other parties to import submitted movie files for timing in a deterministic, suitably accurate setting. See related discussions for the full background.

Since this change is fully contained in the Ares64 core, if there are concerns with hosting core changes I can also send this upstream to hopefully be incorporated that way if preferred.

There are two loose ends:

• I have not implemented any menu option or similar to enable or disable the SC64 interface, currently it is always on (see cartridge.hpp changes)
• The sd.raw file is expected to be found next to the main executable, the path is not currently configurable.

• I have run any relevant test suites
• I, the commit author, have read the licensing terms for contributors (last updated 2024-06-22) and am compliant

[Morilli]

Have you tested this? I doubt this will work without host and BizInterface changes, considering ares is waterboxed and won't be able to access the file system. If you need extra host files they will need to be passed in on init and stored in the core (see for example how pif.ntsc.rom is handled).

[CasualPokePlayer]

This would firstly be best done initially as being implemented upstream, rather than added here first (although if upstream doesn't want this, then we could end up allowing it here).

sd.raw file is expected to be found next to the main executable

This is not going to work. As said above, ares64 is waterboxed, it cannot access the host filesystem (and even if it could this is not appropriate for a core to do, the core should ideally never access the host disk directly, it should always be going through abstractions in BizHawk, and even the most extreme case of allowing direct access to the host disk would be contained to the "user" folder, although this is again reserved for extreme cases like 3DS).

I'm also a bit skeptical of the claim this is necessarily entirely deterministic. Assuming you're always using the same SD Card image, this is likely perfectly deterministic. However, the devil is in the details with the "same SD Card image." Even if you end up having the same files and the same directories and the same creation dates, you can end up having desyncs against different SD Card images, simply because all the internal filesystem details are not 100% identical (e.g. the order of the files internally is different, since they aren't guaranteed to neccessarily be in any particular order). You will need to also end up making a setup for deterministically making SD Card images (or alternatively have the emulator reconstruct SD Card images to ensure all internal filesystem details are identical (assuming all files and directories are identical anyways)).

[vadosnaprimer]

Sending this to Ares upstream would be ideal.

Regarding determinism, the game syncs while replaying those macros on console, because practice rom relies on certain traits of it that make it possible, so maybe differences in SD card images won't make the macro itself desync? It can handle slight timing differences, which is why final time on console is always a bit different.

[CasualPokePlayer]

I'm not talking about gz movie handling desyncing (that can automatically handle timing variations by design), but rather BizHawk "desyncing" potentially resulting in different final times on emulator depending on how the SD Card was created. The main intent to even replay gz movies on BizHawk in the first place is to have a deterministic final time, which you might not get if the SD Card here is not 100% identical, even with an identical gz movie.

[vadosnaprimer]

Well true, but that would just mean we'd have to pick a time just like GZ users do on console. At this point my goal is just deducing SOME kind of framecount from emulator at all, because from console it can't be obtained.

[YoshiRulz]

Blocking on behalf of CPP (you can't read from the filesystem, you need to use the mechanism provided by Waterbox).
Also check in the new build.

[vadosnaprimer]

Created an SD card image in Dolphin with only the macro present, and got it to replay til the end, so confirming it works. Whether final times are deterministic will take a bit longer to check, but I think this can be merged now and refined later if needed.