PS3 [PSP Launchers] Problems and Research

[sandungas]

@DeViL303 @sandungas Last night I was experimenting with your ideas about modify the database file to set the category PE or MN dynamically, but I concluded that it was impractical due the PSP Launcher doesn't get updated until the system is rebooted.

Is not updated even when using the reload xmb utility after the patching ?

And how much you was patching in the database and the SFO (both at the same time), just the 2 bytes of the CATEGORY ?

 

[kozarovv]

Why you want to patch sfo for launcher?

 

[DeViL303]

Why you want to patch sfo for launcher?

The original idea was so we would not need 4 launchers for best compatibility, as the flags in param.sfo seem to decide more than just the category.

Every game could have its own set of flags this way, all using 1 launcher.

Also if edited from a backup manager application, it would mean the launcher would just appear when required, just like any other mounted game, and it could show icon and title of game. So it was about making psp as seamless as other disc types really.

Of course issue is that if this method was to be used by webman, then xmb reload is required to see param.sfo changes. Leaving a manager like managunz, already reloads the xmb, so it works much better for an application.

 

[kozarovv]

The original idea was so we would not need 4 launchers for best compatibility, as the flags in param.sfo seem to decide more than just the category.

Every game could have its own set of flags this way, all using 1 launcher.

Is first time i hear that sfo decide about psp compatibility. 0_0

 

[DeViL303]

Is first time i hear that sfo decide about psp compatibility. 0_0

Seems to, for a start there is category MN and PE which decide if it runs as mini or remaster, then priority flags seem to have an effect. Also launchers like atreyu187s seem to have different compatibility again due to param.sfo changes.

It's funny that this little 1kb file we use everyday is still not fully understood.

 

[kozarovv]

Seems to, for a start there is category MN and PE which decide if it runs as mini or remaster, then priority flags seem to have an effect. Also launchers like atreyu187s seem to have different compatibility again due to param.sfo changes.

It's funny that this little 1kb file we use everyday is still not fully understood.

Minis or Remaster can be forced (and probably is in current launcher versions) by config command in minis2.edat

BOOT_MODE = %llx       
100010000 = Minis
200010000 = Remaster

Maybe sfo is used when BOOT_MODE param is not detected in config, anyway config have always higher priority here. Afaik @atreyu187 rev launcher have set higher memory layout in minis2.edat, that's why have better compatibility. I doubt you can reach that by sfo edit.

Imo doing that kind of stuff by sfo can make similar mess like when cobra devs created save patch, instead of just select it in minis2.edat. Is one of reason why 90% of reports related to save issues on devwiki are basically useless now, since there is no way to find out that save patch was forced during testing, etc.

 

[DeViL303]

Well this system could swap the edat and too then, that would be easy.

This issue for me is having 4 launchers and I for one can not be arsed testing out all 4 on every game to see if it works.

Any solution that uses just one launcher, and auto configures everything as good as possible, is fine by me. So if there is a better way let's do it.

Also if launcher can be made to only show when game is mounted I think that is bonus, and icon and title be nice too, because why not.

 

[DeViL303]

But yeah, I did not know that config could force category, or I would not have wasted any time on those tests. Oops.

Tbh, I don't even play psp games on ps3 (mostly due to all these issues) so I will just leave further tests to people who care and know more about them.

 

[aldostools]

Is not updated even when using the reload xmb utility after the patching ?

And how much you was patching in the database and the SFO (both at the same time), just the 2 bytes of the CATEGORY ?

I downloaded the database to the PC, patched PE to MN and saved it with another name. Uploaded the PE and MN databases, swapped the database with the one that I wanted. The small icon that say minis or remasters didn't change even after using reload xmb or launching the iso.

Anyway I feel that with the way I implemented it now is easy to select the mode you want to start the game without having to browse all the games category until you find the launcher for minis or remasters.

Also Kozarovv has a good point. I think we should make a database of .edat for PSP like the one for ps2 config, and add support for copy the corresponding mini.edat when the iso is mounted.

 

[sandungas]

Reserve all 128, PARAM.SFO should have param_max_len and param_len to 0x80 and be null padded. The entry bytes will be stored with in database (DB doesn't make checks on strings, endocing, etc it simply copies the bytes). The trick is that when the XMB reads the data from db it will get all the 128 bytes and try to parse it in a string. It should stop at the first null byte since that serves as terminator. All the app has to do is write the bytes of the updated title and a null byte.

I tryed it but doesnt works sadly :/

1) I installed PSP_Remaster_Launcher_Fixed_3D.pkg.651.v2.00.pkg, then i installed Priority_ON_for_PSP_Launcher.pkg.656.v0.01.pkg (both downloaded from brewology, both apps are installed in the same path)
2) I prepared an SFO with both the "max length" and "used lenght" of the TITLE = 0x80
3) Then i used a filemanager to overwrite it
4) Reboot the PS3 into recovery menu and "rebuild database"

And the TITLE in the database did not store the bytes reserved by the 0x80
I think what happens is the "database manteinance" plugin caught the error even before the TITLE is stored :/
So i guess the only way to reserve the bytes in the database is by adding some 0x20 bytes after the name in the PARAM.SFO ...not tested but im guessing this should work

-----------------------
Now something interesting i noticed, the TITLE is stored multiple times in the database (32 times in my db)
But i think i know why is made this way partially (and is a bit retarded, hold on to the chair)
Inside a PARAM.SFO can be stored 1 TITLE and 20 TITLE_xx (where the xx represents a language code)
https://www.psdevwiki.com/ps3/PARAM.SFO#TITLE

All this strings are stored together, preceded by a value of 4 bytes lenght, aligned to 4 bytes boundary individually, and all them concatenated, as example (in just showing 3 repetitions in this example):

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000382D0                    0C 20 26 1E 80 50 53 50 20 4C        . &.€PSP L
000382E0  61 75 6E 63 68 65 72 00 00 00 00 0C 20 26 1E 80  auncher..... &.€
000382F0  50 53 50 20 4C 61 75 6E 63 68 65 72 00 00 00 00  PSP Launcher....
00038300  0C 20 26 1E 80 50 53 50 20 4C 61 75 6E 63 68 65  . &.€PSP Launche
00038310  72 00 00 00 00 0C                                r.....

Here the unknown value is 0x0C20261E80 it seems to change if you rebuild database
*The first byte of the unkown value (0x0C) doesnt changes if you rebuild database, it seems to be the lenght of the string
*The other 4... dunno, but probably a timestamp ?

The point is... all this area can be mapped by using: unknown_value + string + padding alignment
repeat that search pattern 21 times and you have the whole area

-------------
After this area appears some shit (that doesnt follows what i explained), in one of the test this area had 0x3B size, in other test 0x5B bytes, no idea what is it, but it has variable size

And then the TITLE repeats another 11 more times
I cant imagine what is the purpose of this "additional" TITLE... but my understanding is are different of what i explained... so maybe is not needed to patch them... dunno

 

[sandungas]

*The first byte of the unkown value (0x0C) doesnt changes if you rebuild database, it seems to be the lenght of the string

Confirmed, see this test made by DeViL303 from his db files he uploaded the other day. In the example im just showing 3 repetitions but this is repeated 21 times consecutivelly:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0003A3D0              89 20 25 C3 68 78 78 78 78 78 78 78      ‰ %Ãhxxxxxxx
0003A3E0  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A3F0  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A400  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A410  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A420  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A430  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A440  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A450  78 78 78 78 78 78 78 78 78 50 4F 57 45 52 4F 50  xxxxxxxxxPOWEROP
0003A460  54 31 00 00 00 00 89 20 25 C3 68 78 78 78 78 78  T1....‰ %Ãhxxxxx
0003A470  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A480  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A490  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A4A0  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A4B0  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A4C0  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A4D0  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A4E0  78 78 78 78 78 78 78 78 78 78 78 50 4F 57 45 52  xxxxxxxxxxxPOWER
0003A4F0  4F 50 54 31 00 00 00 00 89 20 25 C3 68 78 78 78  OPT1....‰ %Ãhxxx
0003A500  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A510  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A520  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A530  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A540  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A550  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A560  78 78 78 78 78 78 78 78 78 78 78 78 78 78 78 78  xxxxxxxxxxxxxxxx
0003A570  78 78 78 78 78 78 78 78 78 78 78 78 78 50 4F 57  xxxxxxxxxxxxxPOW
0003A580  45 52 4F 50 54 31 00 00 00 00                    EROPT1....

The first byte 0x89 is the length of the string (without the NULL termination)
The next 4 bytes 0x2025C368 are unknown (candidate to be a timestamp)
Then it comes the string + the NULL termination
Then the optional padding bytes to align it to a 4 bytes boundary

 

[sandungas]

I downloaded the database to the PC, patched PE to MN and saved it with another name. Uploaded the PE and MN databases, swapped the database with the one that I wanted. The small icon that say minis or remasters didn't change even after using reload xmb or launching the iso.

I think i found why it was not working in your test, long story short... there is another value dependant of the category that is located inmediatly after category, so is needed to patch 8 bytes (4 of the category + the next 4)

Im confident this struct is fine overall, this is what i was able to identify by now in this small area of 0x68 bytes but im pretty sure a few of that "unknowns" could be identifyed easilly, is just in the samples i been looking are not used, but is just a matter to take a look at other samples or build custom PKGs with spyced/frankensteins PARAM.SFO inside to see how hdd database stores the values of them

struct Game {
     uint64_t   SFO_unk_01;         // doubtful length // broken ?
     uint64_t   SFO_unk_02;         // doubtful length
     uint64_t   SFO_unk_03;         // doubtful length
     uint32_t   PARENTAL_LEVEL;     //
     char       TITLE_ID[16];       // something weird for SD category, not char data type (maybe 2 references to the offsets of his "owner" ?)
     uint32_t   SFO_unk_06;         // values found 0 (Game:Game.subTitle ?, or Game:Game.subTitleId ?)
     uint32_t   RESOLUTION;         // 0 for GD
     uint32_t   SOUND_FORMAT;       // 0 for GD
     uint32_t   SFO_unk_09;         // values found 0 (Game:Game.xmbApps ?) XMB_APPS ?
     char       VERSION[8];         //
     uint32_t   SFO_unk_11;         // values found 0 (Game:Game.region ?) REGION_DENY ?
     uint32_t   BOOTABLE;           // 0 for GD
     char       PS3_SYSTEM_VER[8];  // something weird for GD category (maybe a reference to the offset of his "owner" ?)
     char       CATEGORY[4];        //
     uint32_t   CATEGORY2;          // 1000 = HG, 1300 = PE, 1500 = MN, 6000 = CB, GD (Game:Game.gameCategory ?)
     uint32_t   SFO_unk_16;         // values found 0 in HG, MN, PE, but used by SD (Game:Game.timeModified ? *:Common.timeModified ? )
     uint32_t   SFO_unk_17;         // values found 0 in HG, MN, PE, but used by SD (*:Common.timeCreated ? )
     uint32_t   ATTRIBUTE;          // 0 for GD. SAVEDATA_LIST_PARAM for SD
};

The value i mentioned that is needed to change together with the CATEGORY is the one i named CATEGORY2, this seems to be the only value in this area that is not generated by a direct "copypaste" of the info from SFO--->to database
But after looking at the values stored in it, it seems it can be deduced directly if you know the CATEGORY
In other words... by knowing the CATEGORY we know the CATEGORY2
The value needs to be converted to decimal, this is obvious when you do the conversion because is always a rounded number
Actually, it seems to represent some kind of "subidentifyer" for the standard categories we are used and know lot of time ago... this is just something new that is veeeeery related with them but at this point im not going to risk in giving an explain of what it does (i have some theories though)
Anyway, the values i know for sure are this:

HG = 1000
PE = 1300
MN = 1500
CB and GD = 6000

Im pretty sure there are more individual identifyers for the "PS1 classics" and "PS2 classics" categories, but at this point i dont have any sample of them to take a look at which values uses everyone of them, if someone finds it, please advise me
Initially, it seems this value is different for the categories that appears under XMB "game" column (and this is why i think it could be the Game:Game.gameCategory)
At this point i think the value 6000 i found used by category CB and GD is used by all other non-game categories, not complely sure about this though

To continue researching about how this value works there are loooot of candidate categories, are all the ones that appears in this table in wiki (initially we only care about the second table for categories used in hdd contents)
https://www.psdevwiki.com/ps3/PARAM.SFO#CATEGORY


------------------------------------
Returning back to the experiments lab...
The search/replace patterns to change the category in the hdd database needs to be 8 bytes lenght
The 4 bytes at left are the CATEGORY (just text), and the 4 bytes at right is the CATEGORY2 (the value in hex that needs to be converted to decimal to make it "human readable")

PSP Remasters (category PE)
50 45 00 00 00 00 05 14

PSP Minis (category MN)
4D 4E 00 00 00 00 05 DC

 

[kozarovv]

Also seems there are dedicated functions for reloading items, categories, etc. in explore_category_game plugin, maybe we can use them for reloading sfo manually.

0xEDDD4 - aReloadItem       # "reload_item"
0xEDDD8 - stru_F4E90        # sub_2CBF8

0xEDDDC - aReloadItemMrid   # "reload_item_mrid"
0xEDDE0 - stru_F4E88        # sub_2CB54

0xEDDE4 - aReloadCategory   # "reload_category"
0xEDDE8 - stru_F4E80        # sub_2CAB0

0xEDDEC - aReloadCategory_0 # "reload_category_items"
0xEDDF0 - stru_F4E78        # sub_2CA0C

0xEDDF4 - aReloadCategory_1 # "reload_category_segment"
0xEDDF8 - stru_F4E70        # sub_2C968

0xEDDFC - aReloadSegmentF_0 # "reload_segment_focused"
0xEDE00 - stru_F4E60        # sub_2C820

0xEDE04 - aReloadSegmentI   # "reload_segment_index"
0xEDE08 - stru_F4E58        # sub_2C77C

0xEDE0C - aReloadList       # "reload_list"
0xEDE10 - stru_F4E68        # sub_2C8C4

0xEDE14 - aExecApp          # "exec_app"
0xEDE18 - stru_F4E50        # sub_2C6D8

0xEDE1C - aExecPush         # "exec_push"
0xEDE20 - stru_F4E48        # sub_2C634

 

[bazzarre]

hi all,
i have a superslim and a slim,both 4.84hfw and hen 2.3.1 enabled.both have been working fine until last week.
for both,i'm using ManaGunz_v.1.35-J to launch psp and ps3 iso's.unfortunately the superslim no longer launches psp games,black screen,hard reset required as previously mentioned in this thread.im using this placeholder on both consoles:PSP_Remaster_Launcher_Fixed
the game im testing is final fantasy 3 although other games that worked with this setup no longer work but are still fine on the slim.also,this game no longer works as a .pkg but did previous to this problem.
i have reformatted the hard drive,reinstalled 4.84 OFW,reinstalled 4.84 HFW and reinstalled HEN 2.3.1 but still have this problem with the superslim.i even copied the placeholder folder in"games" from my slim to my superslim and still nothing.
the point where things changed was when i installed "PS2emu fix" from this site but i have reformatted since then so i dont think this is the problem,just giving you all as much info as i can.

just wanted to say many thanks to all you devs here,you've done (and are still doing)a fantasic job and i'm REALLY enjoying my ps3 again!

 

[sandungas]

Have you installed ever the other PKG named "Priority_ON_for_PSP_Launcher" ?
Im asking because thats one of the things i found weird while looking at all this launchers/placeholders

That PKG doesnt changes the priority ONLY... it does more things, and technically it "should not" be applyed over the other PSP launchers (but the fact is sometimes it solves the problem as mentioned in the first posts of the thread by several people)

 

[bazzarre]

Have you installed ever the other PKG named "Priority_ON_for_PSP_Launcher" ?
Im asking because thats one of the things i found weird while looking at all this launchers/placeholders

That PKG doesnt changes the priority ONLY... it does more things, and technically it "should not" be applyed over the other PSP launchers (but the fact is sometimes it solves the problem as mentioned in the first posts of the thread by several people)

yes i have but only since this problem arose and only on the superslim.im leaving the slim "as is" because it may be possible to solve if the files from both can be compared by someone more adept than myself! originally,both consoles were running all the psp isos and .pkgs i put in.ive just tried installing the same game 'ole han stylee by signing the .pkg and installing from the playstation content folder.installs fine as always but black screen and hard shutdown required when started. its as tho the superslim has lost the ability to emulate psp completely.

 

[bazzarre]

ok,since my last post ive resolved the problem.reinstalled 4.84 hfw and reinstalled hen 2.3.1.managunz mounts fine,placeholder launches game fine.
something worthy of note tho,i noticed that when i mounted ff3 and it wouldnt start,the tiny icon to the left of the placeholder said
"psp minis".now that things are working again the tiny icon says "psp remasters" when ff3 is mounted.
i dont know if this helps in your work for an AIO placeholder but just thought i'd mention it. my problem was clearly not the placeholder considering the method i used to fix things.clearly i'd knackered something along the way.

 

[sandungas]

If i remember right... is because the "Priority_ON_for_PSP_Launcher" PKG changes the category in between "psp minis" and "psp remasters"

So, the name of it is misleading... everybody thinks that is going to change the priority only, but it changes the category too (and by changing the category it changes the compatibility of the emulator because you are botting the game with different settings)

 

[bazzarre]

I know that there's definately a difference when converting to .pkg,ff3 works fine if you check minis when converting,no joy when remaster is checked.Crisis Core works fine when you check remaster.Haven't tried a.pkg this time round tho (who cares? my girlfriend is speaking to me again now shes back on ff3) but i would imagine it would be fine. Sorry if this is obvious but is this .pkg issue the same as having to use certain placeholders for certain games?

 

[sandungas]

The mess is even bigger, because inside the PSP placeholders there is a file that works pretty much the same than the CONFIG files used by the PS2 emulators

Inside them there are commands... and every command does some things... the available list of commands is very long (and there are some unknowns)... and whoever did that "PSP Placeholders" did choose a few commands, then prepared a config for it with his commands and since that point the PSP Placeholder is going to use always the same commands for all the games

The result of this is... the game compatibility is hitted hard... there is going to be a massive number of games that doesnt works fine because are not using a correct config (the emulator is trying to boot them with weird settings, not intended for this game)
I was taking a lok at all this trying to understand what is happening, but all i know is we have a huge mess

https://www.psdevwiki.com/ps3/PSP_Emulation#Emulator_Settings