November 18, 2010 // 12:29 am - After being delayed for several days pending some bugs and features, we're proud to release SynaPS3 - PS3 compatibility, backup and homebrew library with all but 1 intended release feature!

SynaPS3 is a simple library for people using the Sony PS3 Cell SDK, primarily made for making applications universally compatible with payloads, to help extend and improve existing functions for homebrew, and to add new functions.

Documentation for SynaPS3 is on github. Some of the most notable features of SynaPS3 included syscall36 compatibility on ALL PL3 payloads, and syscall35 compatibility on Hermes v3 and Hermes v4 payloads.

To integrate these compatibility fixes it's as simple as opening the source of an existing program, removing the syscall35/syscall36 functions, and including SynaPS3!

SynaPS3 also has functions to help save you time while coding, such as ReadFirmwareVersion, IsBlurayGame, Firmware342Fix, and more.

SynaPS3 is nowhere near where we want it to be yet. This is only the beginning. SynaPS3 aims to become a full library, with PS3 dialogs and full PNG output.

A decent chunk of our code was inspired by Open Manager and we'd like to thank all the coders who worked on it.

A decent chunk of our code was inspired by Open Manager and we'd like to thank all the coders who worked on it. SynaPS3 is released under this license.

The one feature we feel we could have included in this initial SynaPS3 release was GetPayloadCaps(), designed to return payload capabilities. While the functions included in SynaPS3 do check before running functions that may not be supported, GetPayloadCaps() was designed for use in homebrew. We plan to include this in our next update.

You can find SynaPS3 here. We will try and ALWAYS have only stable commits that work up on github. If you find one that isn't stable or something not working, notify us!

Enjoy, and let us know what you think!

- n4ru, methionine_

Finally, in related news PS3 developer Tactik-knife made available PS3 Console Compatibility v2.00 followed by v2.01, v2.50, v3.00, v3.01 and v3.5 with details below, as follows:

Please if you see a mistake, tell me in this post. I hope you will like this.

Changelogs v2.5:

• Translation the application in English
• Fix minor bug

Special thanks to baileyscream for his tutorial in English.

Update #3: Hi guys. Following various remarks elsewhere, I decided to make a small software for all the beginners who want to jailbreak their console.

PS3 Console Compatibility GUI is a small software that allows you, PS3 owners, to know whether their model is compatible with the PS3 jailbreak.

How use it?

Very simply, if you want any informations about console and know if she's compatible or not, you must select your PS3 model and click to "Start", the program tel you all you need to know.

Same for know information about your blue-ray drive (daughterboard, slide and laser).

Credits:

Thanks to psdevwiki.com for all information about different PS3.
Thanks to Zer01one ans Littlebalup for help
Thanks to Littlebalup for this help for development
Thanks to DefaultDNB and this PPC+ for the original idea
Thanks to baileyscream on ps3hax for his tutorial in English.

Changelog v3.0:

• Add section for Blue-ray Drive (daughterboard, laser and slide)
• Save are created on HTML now (TXT before)
• Optimization of code
• Corrections of mistakes in English

Update #4: Hi, After a few month, little update to v3.1 for fix one bug with HTML creation file.

I guess I will continue/restart to work on it, I will try fix the bug about the application running in the background.

Changelog v3.1:

• Fix bug about HTML creation file

Update #5: New update on 3.5. Important update for you American people.

Special thanks to baileyscream and playerkp420 for his tutorial in English and helping for US models.

Update #6: New update, now the application is on version 3.7. I kept the term "jailbreak" I think it's more appropriate, for example for model 2501/2504 who's supported minimal firmware 3.56, we can't downgrade it so we use the no-FSM method, so I don't it's good term if we use "downgradable" ^^

Changelog v3.7:

• Add compatibility for Windows XP
• Fix bug about the process not killing when the application was closed
• Delete the first windows with changelogs, now they're on a new
windows who's name "Changelogs"
• MinVerCheck is now downloaded directly from the application

- minimal syscall35 support for PSGroove1.1/Hermesv1/Hermesv2 (remapping root dirs via Peek/Poke [3.41 only])
- GetPayloadCaps() will be fixed and added.
- GetPayloadType() will be readded as originally intended (was replaced for GetPayloadCaps(), but I suppose it doesn't hurt to have both so backup managers can easier identify.

From my understanding app-designers should make their apps compatible with the official sdk and the given gameOS. If the app runs on unjailbroken debug it has best possible compatibility and should run with most payloads. But than from my point of view there is no or only few need for this library. I am not a coder, so please correct me if I am wrong.

People with dongles that support peek&poke could use some kind of memory patcher right after boot. Haven't seen an app yet which is able to peek for the known patches and pokes them if wanted by user.

You bring up good points. While I strongly agree that pl3 should be the payload everyone uses, I thought of the people with clones as well. Not everyone can buy a new dongle when theirs can't update or flash hexes, and so are stuck on an old unsupported payload.

The no modification without notifying us and updating first rule is so we don't get forks of SynaPS3 outside of our control, we have no problem adding any updates or features requested or code given, it's supposed to be a unified library, hence why we don't want forks. It's not code theft we're afraid of.

Also the fact that if it's modified and released in another program's source people might think we wrote all the code, or they might add their own credits inside and mark it up as they see fit. I prefer a single source.

I appreciate your work and I understand your approach, which seems to be to make the whole payload-mess irrelevant for coders and end-users.

But on the other hand I feel, that this is not going into the right direction because it encourages users and coders to use payloads which are not sufficient for the tasks they intend to do:

We have the PL3 no_unauth_payload on which we are able to use the PS3 close to a debugging station. You can backup and run everything you can on other payloads, but you don't have root access. This shouldnt be some kind of problem because licensed game developers dont have root access to their debugging stations either.

Think about it: An enduser tool on a windows or linux desktop which pokes around in the system area of the memory would be considered malicious. I also already tested some backup manager which corrupted my backup data in a situation where absolutely no altering of the backup data was needed to run the backup. To read the system version from version.txt might look like a fancy feature, but it should be completely unnecessary, because of the simple fact, that even licensed developers seem to have no read access to this file.

From my point of view, sooner or later users will have to fix their permissions in order to be compatible with access rights of normal user level. From my knowing, at this time this could only be done proper with deleting/reformatting everything and clean install on no_unauth.

So what I don't understand is, what is the point in giving users and coders a workaround for staying on insufficient payloads? On no_unauth the user simply can't mess with permissions, because they are restricted.

I am sure that with your additions to the cc-license you follow only good intentions and are not going to enforce them. However, from a legal point of view they maybe pointless. Your licensing is in contradiction to F.1. of the Terms of Service of Github. So what is the point in releasing this stuff there if you don't want a fork?

So please don't get me wrong, just some thoughts on how the 'scene' is developing.

The no modification without notifying us and updating first rule is so we don't get forks of SynaPS3 outside of our control, we have no problem adding any updates or features requested or code given, it's supposed to be a unified library, hence why we don't want forks. It's not code theft we're afraid of.

Also the fact that if it's modified and released in another program's source people might think we wrote all the code, or they might add their own credits inside and mark it up as they see fit. I prefer a single source.