I've made a similar post on PCSX2's side before this.
For convenience sake, I think there should be a change on either side (or both) to make the formats match exactly. That would allow for situations like saving a game on your PS2 game booted off of SMB, then picking the game back up on computer via PCSX2.
As can be seen from their side of the issue, there is some debate on what the differences are (whether it's just padded data or if it's ECC data). It would be great if there could be some cross-pollination to figure out the easiest way for the divide to be bridged.
Just use MCR on your PC to convert the save game stored on SMB.
If you're picking up playing from SMB on your PC that shouldn't be a problem.
I'm also interested in how often your realistically come across this problem?
That would be fine for occasional use but my goal is to make it possible to do it often and seamlessly. Like play on my PS2 before a trip or something quit and then the save propagates to my laptop for me to play later, or vice-versa.
The only thing (that I currently see) preventing a pick up and play setup like this is the slight incompatibilities between the save formats.
PCSX2's format is slightly different. It also records the ECC data, which makes each sector larger. Unless the developer(s) change the design of VMC, this difference between the sector size of the device hosting the image and the PCSX2 VMC page sizes will make the reading and writing process complicated.
What's stopping us from adding ECC data to our VMC format? This is something I never understood, but it's exactly the reason why applications such as MCR and MyMC exist in the first place. Every one of these developers at one point got frustrated enough at the incompatibility between OPL and PCSX2 VMC files that they took it upon themselves to become a middle man ........ while muttering through clenched teeth that they're should be any middle men! LOL
It's highly inefficient ... ;-)
It's the same reason. Neither do we need that data. On the other hand, PCSX2 emulates the hardware, so it has to emulate the data that the real hardware would store too.
To understand how adding this data will make things very awkward for VMC, you need to do some math. The page with ECC data is 528 bytes, while the sector size of most devices out there is 512. You can only read data in units of 512, at addresses in multiples of 512. Hence reading and writing in multiples of 528 bytes to a device that can only do the same in multiples of 512 bytes, is simply an unnecessary challenge.
Sounds like it might be easier to add a bit of code on PCSX2's side that automatically adds the ECC data when loading an OPL VMC file to memory and discards it when saving.
Actually, after SP193 explained everything, it would be easier for PCSX2's developers to add a tickbox to its memory card manager that enables/disables saving the ECC data entirely.
Please echo all of this over at the PCSX issue https://github.com/PCSX2/pcsx2/issues/2959 @Nerdy314159265
Maybe an export/import function to this format will do.
If I am not mistaken, LaunchELF also uses the same VMC format as OPL does. So it would be doing everybody a favour, rather than just users of OPL.
Export/import functions aren't really efficient since then you gotta write code for all the formats you want to support with the function (i.e. *.MAX, *.CBS, *.PSU) like the MyMC and MCR did. And with NAND-based memory card for the PS2 are become very scarce, that's the only real benefit of keeping the ECC data. Having virtual memory cards to swap between OPL and PCSX2 don't need ECC data, so even my suggested tickbox is a bit behind the times. KrossX has the right idea with a "convert on load and convert on save" approach all as a background process - no GUI code or user intervention required.
I echoed this over to the guys in PCSX2. They asked for a few OPL memory cards that are full with saves. I don't have any on hand and it'll take me awhile to make. So I thought I'd ask if any of you had some lying around.
Hahah, I'd have to look! Back when I had an 250GB drive, space was limited so I'd have genre based VMCs (i.e. fighting, rpgs, action, etc.) but now with a 500GB drive, I might of deleted those VMCs since I can afford to give every game its own dedicated VMC ...
Update Yup, I still got 'em but they're probably not full of saves. Also need to make sure they're not corrupt. I'm in the process of switching employers (and moving from day shift to overnights) so I won't have time to investigate this until Sunday. :(
That's okay. I don't think there is any particular rush. I'll see if about making some when I get the chance, but I'm not sure exactly how long (or how many games) it'd take to fill one up.
Don't have time to test these but here's link ...
http://www.filedropper.com/oplvmcarchive
The README should explain everything. The VMC with the most saves is the RPGS - it's about half full. Any issues downloading this, let me know below and I'll see what I can do.
You can mount PCSX2 memory cards on uLE...
olders versions of PCSX2 could read OPL VMCs but you had to rename them to .ps2 now this method isnt valid with newer versions.
I think that's quite possible and/maybe not even so much work, but we have very few people in the PS2-Scene, which also means that very few (people/Devs) can or will contribute the code for that kind of feature...
Btw.: When did the change occur, that PCSX2 could not 'understand' the VMC-File?
Most helpful comment
It's the same reason. Neither do we need that data. On the other hand, PCSX2 emulates the hardware, so it has to emulate the data that the real hardware would store too.
To understand how adding this data will make things very awkward for VMC, you need to do some math. The page with ECC data is 528 bytes, while the sector size of most devices out there is 512. You can only read data in units of 512, at addresses in multiples of 512. Hence reading and writing in multiples of 528 bytes to a device that can only do the same in multiples of 512 bytes, is simply an unnecessary challenge.