Open Nerdy314159265 opened 3 years ago
You can create large i.e 64MiB vmc for general purpose and makes saves backup to PSU in case You stop playing some games. It is hard for me to imagine how such card can be not enough for all owned games or how user could trust vmc in the first place to not making backups of it or data inside. ;)
Anyway. How PCSX2 has solved issue with time stamps and files/dir attributes which existing only in MCFS? Time stamps can be easily clone to target fs but what about attributes?
This is better solution, yet stick to PFS only: https://github.com/ps2homebrew/Open-PS2-Loader/issues/412
You can create large i.e 64MiB vmc for general purpose
Sure you can make big memory cards with VMC but those don't have 100% compatibility (some games have trouble with large cards).
and makes saves backup to PSU in case You stop playing some games.
I don't know what PSU you are talking about but manually making backups "just in case" is tedious and irrelevant to the issue.
It is hard for me to imagine how such card can be not enough for all owned games or how user could trust vmc in the first place to not making backups of it or data inside. ;)
The size of the collection is mostly irrelevant to what I'm suggesting. Also your comments about "trusting vmc" are also not adding to the conversation
Anyway. How PCSX2 has solved issue with time stamps and files/dir attributes which existing only in MCFS? Time stamps can be easily clone to target fs but what about attributes?
This is better solution, yet stick to PFS only: #412
Is the real reason you replied just to point to an issue you care more about? This issue doesn't appear related at all to this one and this comment is unhelpful.
*.psu is a designed container for PS2 saves backups. You can mount VMC in uLE (unofficial LaunchELF) as real Memory Card and export saves to this format. VMC itself was never designed as alternative way to keep saves but as temporary virtual device to eliminate needs of real one (especially that it doesn't have ECC codes). I mentioned about it, to makes Your life easier... For most peoples, it is sufficient to keeps one VMC shared with all games.
No. The real reason is to point that linked issue is very similar and have more sense (yet zero for other devices than internal HDD).
And You didn't answer to my question.
BTW:
Instead of storing the temporary VMC within memory
OPL doesn't store VMC in RAM because there is not enough space for it. OPL emulating MCSIO which handle Memory Card communication.
*.psu is a designed container for PS2 saves backups. You can mount VMC in uLE (unofficial LaunchELF) as real Memory Card and export saves to this format.
Okay, now I know but that's not very useful to me as long as *.psu is not used for OPL, nor PCSX2.
VMC itself was never designed as alternative way to keep saves but as temporary virtual device to eliminate needs of real one
I'm pretty sure that's self-contradictory. Eliminating the need for a real memory card means it's acting as an alternative way to keep saves.
(especially that it doesn't have ECC codes).
Not sure that's true since when I opened issues to get VMC cards cross-compatible between OPL and PCSX2, the crux of the issue IIRC is that PCSX2 discarded ECC data that OPL keeps.
I mentioned about it, to makes Your life easier... For most peoples, it is sufficient to keeps one VMC shared with all games.
I appreciate it but that doesn't make my life easier. A big memory card is a temporary solution in my opinion.
No. The real reason is to point that linked issue is very similar and have more sense
Claiming your issue "has more sense" seems like you are trying to compete.
(yet zero for other devices than internal HDD).
I don't understand what you are trying to convey here. Are you saying that your issue is only for HDDs? If so then it's irrelevant since this is something that would primarily help people storing saves on SMB to make for easier switching between emulation and hardware.
And You didn't answer to my question.
I'm not an expert on the functionality of PCSX2, so I don't have a proper answer. My best guess is that they split off the part of the memory card that stores attributes or embed it as a header on the files themselves but I could be entirely wrong.
OPL doesn't store VMC in RAM because there is not enough space for it. OPL emulating MCSIO which handle Memory Card communication.
I was ~90% sure of that already. That's a random slice from my suggested implementation of the Folder Save format and an attempt to make it clear that I wasn't proposing that the new temporary VMC be stored within memory since I was already aware that OPL is operating on a very tight memory budget.
I thought about making a seperate issue but I think this is a good place for this. Why not have the VMCs generated with the .ps2 extension by default? Every time I wanna import saves to a VMC i have to change the extension to .ps2 for mymc to recgonize it...
I think loading vmc into memory would not be feasible at all I was thinking more of a module for savestate, because then it will just necessarily copy everything being run by EE, IOP and ram into a compressed file like PCSX2 does so much it uses zstd for that in the newer versions. You could add some with some specific format made for ps2, it even uses as base some data compressors like lz0 and lzf that could perform well for this, but I am not sure how complex it would be besides the limitations of ram being stored to read the compressed file and uncompress it in real time as it happens with zso in conjunction with lz4.
Is your feature request related to a problem? Please describe. Managing memory cards, virtual or otherwise, becomes tedious as a game library increases in size. In the case of virtual memory cards, you could create individual cards for each game to prevent running out of space on one for saves but that breaks games that look for other games for content (such as Ratchet and Clank series games looking for saves from previous games in the series). This adds another layer to the complexity of a large library and managing the large number of VMCs that could be created.
Describe the solution you'd like I would like for a Folder Save format for VMC that is compatible with PCSX2.
If I understand correctly, it creates a VMC that, after being written to by a game, will take the save data out of the virtual FAT filesystem and put it in the save folder. When loading a game it will dynamically recreate a VMC by loading in the relevant game folders (probably using a lookup table for games that need to share memory cards).
This effectively creates one memory card that is as large as the drive you are saving to without causing issues with memory card size. It also provides direct access to the save data for editing, modding or sharing.
Describe alternatives you've considered The only alternative I've been able to think of would only work halfway. A user could use PCSX2 to convert a standard VMC into a folder VMC for use with it (slow, usb drive or hdd method) or they could create a script that would detect updates to a standard VMC file and extract the save data.
Either way, these solutions are only half measures and the save data would need to be reconverted back to a standard VMC after using it in PCSX2 or any other editing the user would like to perform.
Also neither method removes the problem of managing large numbers of VMCs (and could even add to it) since you would still need a VMC for each game and each set of games that need to share a card.
I believe there are some automatically generated sets out there that can be found but the ones I've seen had automatic names that didn't correlate to the games that used them, and I was unable to confirm if games that needed to share cards were properly set up to.
Additional context I think OPL should be able to handle this method with some modifications. (Warning I haven't fully grasped the VMC system as it currently stands)
Instead of storing the temporary VMC within memory (which I understand can get pretty tight), a temporary VMC can be auto-generated before launching the game using the same methods PCSX2 does but saving the VMC within the folder and utilizing the current VMC systems in game.
The VMC systems that run in-game would need a little modification so that whenever the VMC is saved to it could flush that data back to the folder to update the main saves.
There would be a chance with this style of handling things for a user to turn off the console while the VMC is being flushed and leave their save in an undefined state. So I suggest adding a small check when OPL scans and mounts the file systems at startup to check the temporary VMC and the folder saves that would result to make sure they aren't in a partial flush or unflushed state. If the folder is newer by more than a small margin (to allow for the delay that a flush would have) then it should be ignored and otherwise probably overwritten. Then the VMC would be deleted or formatted to prepare for the next game load.
On load it would repeat with the same methods PCSX2 would use and pull folder saves back into a temporary VMC before launch.