Emulator Issues #7841
closed
Folder support for virtual SD cards
Added by Stevoisiak over 9 years ago.
Updated almost 7 years ago.
Issue type:
Feature request
Relates to performance:
No
Relates to maintainability:
No
Description
Loading files from a virtual SD card currently only supports loading from an sd.raw file. This means that users need dedicated image editing software to add files to an SD card, similar to how a Memory Card Manager was needed to edit GameCube save files. This makes it difficult to run popular mods such as Project M without pirating a pre-made ISO.
Users should be able to load files from an "SD" folder, in the same way they can load game saves from a folder.
I once asked for this, but there were like a thousand reasons why it wouldn't work.
I think might be complicated. When something on a Wii uses the sd card, it uses low level functions and its own FAT32 driver. If you wanted to emulate this with a folder, you'd have to emulate a full FAT32 file system, complete with sectors, file postitions and whatnot.
At least that's what i would expect, i could be wrong.
- Status changed from New to Accepted
- Relates to usability set to Yes
It's not a completely insane idea, but there's a few less-than-trivial implementation details that need to be figured out:
-How would you get around differences in filesystem limitations, e.g. case-sensitivity? This isn't as simple as GCI folders, where you just consider .gci files.
-How would you warn the user about stuff like >4 GB files or two files with the same name in different case?
-Is it even easy/possible to HLE SD card accesses? It's likely that this is done at least partially through Starlet, but if the PPC side has block-level access instead of file-level access, Dolphin would likely still need to create a FAT32 filesystem in RAM or something for this to work.
-Who's gonna do all the work on this? :P
The Citra guys actually discussed this sometime in the last few weeks, and IIRC they just went with the sd.raw approach since it didn't require nearly as much effort to implement (and they're too early in development to give much of a fuck about ease-of-use). Plus, hey, if you rename it to sd.img, on OS X you can just double-click to mount it and the OS/file manager solve all the above issues for you.
Another idea: for stuff like Project M, why not treat this more like hi-res textures and just have a folder in ./Load/ where you can toss in files that replace those on the game disc? It'd be identical to Riivolution (AFAIK, I've never used it myself), but it'd also bypass the SD card clusterfuck entirely.
The thing you sad about replacement files doesn't actually work for some stuff in Project M.
Some of the stuff we do actually using SD card file load functions in Brawl, on files that don't actually exist on the disc. As a result, the only way to run this content properly is to use a virtual SD card in dolphin, or create a "dolphin build" of PM that has said features reworked to use files off a modified disc. (Either ISO or extracted)
Would it be possible to simulate those load functions using Action Replay or Gecko Codes?
I'm not sure I understand what you're asking so ill explain it here.
The basis of Project M is the file patch code, a Gecko code that uses the SD file loading routines the game provides to force the game to check for any file it loads from the DVD on the SD card, allowing us to replace most files.
In addition to that, there are some features that we have implemented that use the SD file loading routines directly, so they don't fall back to the DVD when the file is missing. The custom sound banks we added are an example of this.
Although its possible to build the sound banks into an ISO, it requires additional work, and makes Project M on dolphin a bit more complicated than just "download the files that work on Wii and they work on dolphin". I can try to get someone from the team to elaborate on the process that people currently have to go through to get PM netplay working on dolphin, im a little out of touch with it
- Status changed from Accepted to Won't fix
SD cards are exposed at the block level, not filesystem, which makes this tricky to implement.
Additionally, they can contain any arbitrary filesystem and number of partitions, unlike GameCube memory cards, so it wouldn't really be sane to have this.
Ah yes, and this won't ever work when the SD host controller gets LLEd (for Starlet LLE for example). I'd like to reduce the list of things that would only work with HLE and prevent it from growing.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by