PS3 Apollo save tool (development thread)

Sorry, I'm not sure if this is the right place, but I didn't want to bump an old thread.

I just wanted to ask, I've been trying to manage my PS2 save files from the placeholder, but haven't found anyway to do it since in the xmb doesn't have any MC for PS2 games. I only have a supposed save file for the placeholder, but can't see the save files in it. Looking into it, I found apollo and the PS2 Classic Manager which seems pretty old.
Does Apollo do the job or I'll need the PS2 Classic Manager?
Also, is there any extra step in order to do it? Like create any MC or deleting this ps2 placeholder save data or something?

Thanks in advance!
 
namelessuser said:
Sorry, I'm not sure if this is the right place, but I didn't want to bump an old thread.

I just wanted to ask, I've been trying to manage my PS2 save files from the placeholder, but haven't found anyway to do it since in the xmb doesn't have any MC for PS2 games. I only have a supposed save file for the placeholder, but can't see the save files in it. Looking into it, I found apollo and the PS2 Classic Manager which seems pretty old.
Does Apollo do the job or I'll need the PS2 Classic Manager?
Also, is there any extra step in order to do it? Like create any MC or deleting this ps2 placeholder save data or something?

Thanks in advance!
Click to expand...

I don't know about ps2 classic manager, but if you want to manage PS2 virtual memory cards, you need to use the XMB to create an empty VMC, and then you can overwrite the VM2 file with the one you want to manage.
Keep in mind, you'll need to "refresh" the content of the empty VM2 file so the XMB shows the actual content of the new VM2 file. One way to refresh, is to copy a .PSV save from USB to the VM2 using the XMB. Apollo has a dummy ps2 PSV file available for that.
 
Last edited:
arcadekidflo said:
I have this save for Fifa 19 , is it possible to resign it to free ? I want to use it on another console but i don't have a save from it .
https://www34.zippyshare.com/v/y5mdhM7w/file.html
Click to expand...

do you have Apollo on the other console? then just resign it on the new console.
If not, I think you could copy to USB, then remove both account-id and console-id using Apollo SFO options. This "owner-less" save might be accepted and you might be able to copy/import it to the new console.
 
I removed them but when i tried to copy it from USB to PS3 i get an error that the save got corrupted . Is it possible that you try if this method actually works ?
 
arcadekidflo said:
I removed them but when i tried to copy it from USB to PS3 i get an error that the save got corrupted . Is it possible that you try if this method actually works ?
Click to expand...

if you don't have Apollo on the PS3, then probably the best option is to use Bruteforce savedata on a computer, and prepare the save for the target console.
 
arcadekidflo said:
Bucanero, this is a save from PES 2018 and it works on any PS3 without re-signing https://www36.zippyshare.com/v/s8nirbCi/file.html.
What is different between this one and the one from Fifa , can you check ? Maybe you can create a method to convert a save to free .
Click to expand...

I don't have time so I didn't look, but I'd check the param.sfo to see if there's anything unusual . My bet is that this save has the account-id and the console-ID information zeroed (filled with 0x00)

try to open it with Bruteforce Save data or Apollo and see if you can get any details (account, PSID, etc)
 
SteweEliteModder said:
Would be possible add the option "delete" in the game save menu for delete the game save directly from apollo?
Click to expand...

yes, it could be added. I avoided adding it mostly because I assumed that users would later complain "I clicked here and I don't know what I'm doing and I lost my most precious save-game"

do you want to delete saves on USB or HDD, or both? to delete saves on HDD the database needs to be updated properly, or else you'll end up with a broken save on the XMB.

If you can, open an issue on GitHub with this request so I can track the enhancement for a future version.
 
Hdd, might with delete confirmation message so people can't say "i dunno what was doing" since deleting confirm requires double click for do it...
 
Sorry never mind, called for help too soon. :) I successfully removed the copy protection from Demon's souls so i can back it up. I once lost 100+ hours of progress due to ylod and Demon souls' copy protection. I never tried the game again as i didnt want to risk losing al the progress again. But now I can. :)
Fantastic app!
 
Last edited:
I've been updating Apollo-PS3 to include the latest updates and fixes from the apollo library (new save wizard code support, fixes to some hashes, etc+).

Mostly a maintenance release, but it would be good to have some testing before a release. So if someone wants to test the new version, just let me know. (serious testers only, please.)
 
J'accepte volontiers. Donne-moi un lien s'il te plait via le mail du site.
I gladly accept. Please give me a link via the email of the site.

Algol "le papy".
 
@aldostools , I guess it's not a big deal, but I'm thinking about changing how the "COMPRESS" and "DECOMPRESS" BSD commands work.
It will be a breaking change with BSD, but I wanted to hear your feedback :)

right now, the syntax is:
Code: 
[unpack file]
Decompress <filename-to-unpack.ext>

and BSD runs the offzip tool and unpacks all the zip files that can find inside "filename-to-unpack.ext".
All Files are extracted as "~extracted\hex-address.dat"

and I feel it would make more sense if it was:

Code: 
:filename-to-unpack.ext

[unpack file]
Decompress <hex-address to unzip from "filename-to-unpack.ext" defined above>

[example]
decompress 0x00001A50

this way you only unpack what you really need, instead of dumping all the files that you can find. This will also simplify the compression later, when you only replace the Zip data for that address, instead of replacing everything that you dumped with offzip.

And another adjustment that I was thinking, for cases where the zip-data address could change, to have the option to specify a relative number for a file to get decompressed. For example:

Code: 
:filename-to-unpack.ext

[example]
decompress (3)

This means: decompress the 3rd zipped file that you find inside "filename-to-unpack.ext". Note: the value (d) is always in decimal.

I know it's not a high priority but I think it could be an improvement. It would also require that I re-write all the PS3 patch codes that use this command because it's a breaking change.

Happy to hear your comments about this, to get the best solution. :D
thanks for all! cheers
 
bucanero said:
@aldostools , I guess it's not a big deal, but I'm thinking about changing how the "COMPRESS" and "DECOMPRESS" BSD commands work.
It will be a breaking change with BSD, but I wanted to hear your feedback :)

right now, the syntax is:
Code: 
[unpack file]
Decompress <filename-to-unpack.ext>

and BSD runs the offzip tool and unpacks all the zip files that can find inside "filename-to-unpack.ext".
All Files are extracted as "~extracted\hex-address.dat"

and I feel it would make more sense if it was:

Code: 
:filename-to-unpack.ext

[unpack file]
Decompress <hex-address to unzip from "filename-to-unpack.ext" defined above>

[example]
decompress 0x00001A50

this way you only unpack what you really need, instead of dumping all the files that you can find. This will also simplify the compression later, when you only replace the Zip data for that address, instead of replacing everything that you dumped with offzip.

And another adjustment that I was thinking, for cases where the zip-data address could change, to have the option to specify a relative number for a file to get decompressed. For example:

Code: 
:filename-to-unpack.ext

[example]
decompress (3)

This means: decompress the 3rd zipped file that you find inside "filename-to-unpack.ext". Note: the value (d) is always in decimal.

I know it's not a high priority but I think it could be an improvement. It would also require that I re-write all the PS3 patch codes that use this command because it's a breaking change.

Happy to hear your comments about this, to get the best solution. :D
thanks for all! cheers
Click to expand...

Hello @bucanero
Sorry for the late reply. I didn't see this post earlier.

I'm not sure how that new syntax would improve the process, but if you believe that it is necessary do all the changes that you consider.

If it is just cosmetic, I would prefer to skip the change to don't cause backward compatibility issues.

If you can make the changes keeping support for the original syntax and adding new optional parameters would better.
 
long time since I posted here, as I went with other developments, but now I'm updating a few things to the original Apollo (PS3)

just for future reference, (and for @Berion peace of mind :) ), I was looking into tiny3d, and found the way to avoid the weird image distortion, and getting the right aspect ratio. Please note, when using 2D, you'll still be using the weird virtual coordinates, but the final image should be ok as long as you adjust coordinates to that virtual reference.

While digging in the tiny3d.h header and samples, I found the tiny3d_UserViewport() function. That's the method to use and get rid of the wrong aspect ratio. Use it like this:

Code: 
tiny3d_Init(1024*1024);
tiny3d_UserViewport(1, 0, 0, // 2D position
   (float) ((Video_Resolution.width) / 848.0), // 2D scale
   (float) ((Video_Resolution.height) / 512.0),
   (((float) Video_Resolution.width) / 1920.0f), // 3D scale
   (((float) Video_Resolution.height) / 1080.0f));

Perhaps this was already known, but it took me about 3 years to discover and figure it out hahaha
Now I hope it's useful to other devs using tiny3d :D
cheers!
 
You must log in or register to reply here.

Similar threads

Back
Top