PS3 [PSP Launchers] Problems and Research
- Thread starter shodan2k
- Start date
sandungas
Developer
This looks like a good idea, or better said, an smart dirty trick to bypass partially the biggest problem we have at this point XDHopefully you are right. I did boot rebug toolbox for FTP
Well, i have an idea for title, so we can have it work all the time regardless of length. What we do is put in long title like XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX in param.sfo , then we patch in the title of game, and put spaces after it to keep length. If its longer than XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX then it gets cut off.
Lets calculate it accuratelly, the TITLE have a max lenght of 0x80 (128 bytes), in the PARAM.SFO structure it can be seen all that space is reserved (filled with zeroes), and at top of the SFO structure it tells how much bytes of it are used by the string
This are the values named param_max_len and param_len in wiki:
https://www.psdevwiki.com/ps3/PARAM.SFO#TITLE
Inside the database it can be seen there are some areas where the TITLE is repeted several times consecutivelly (next to some values that changes frequently, are consecutive, and seems to be timestamps), this areas doesnt stores the zeroes (are only storing the bytes indicated by param_len)
So initially if we want to make the title longer we should rebuild all that areas... and this should increase his sizes... so the whole database file structure should be "updated". And at this point this is imposible to achieve
So your suggestion seems to be the only way to do it at this point, we need to perform the first installation using a TITLE containing some (dummy) spaces at the end
So we are doing some kind of "reservation" in the database structure to use longer TITLE names later at the time we update it manually
next question is how many we should "reserve" ?
In my oppinion, reserving the max (128 characters) is "failproof" but is excesive because the text line (partially invisible most at right) is going to be scrolling horizontally at all times
So... i guess we should use the max allowed before that scrolling animation starts
Lets say... if the scrolling animation starts with strings longer or equal than 17... then we should "reserve" 16 bytes for it
In other words... we should avoid this scrolling animation
And incase the original game title is longer than that size... ouch, we are fucked, this damned naruto and dragon ball games with hypermassive titles, grrr
Exactly. I dont like that scrolling text either.
Bit off topic but anyway, Another way to display more info about an application is a PIC1.PNG that changes to show info. This does not need to be updated in database as its loaded fresh every time.
Here is an example of me using it to display a fake info line below the title on XMB. This could be used to display emulator settings in use, and more info such as info about the game even, if these can be generated by the manager? Even if they cant be generated, there could be a PIC1.PNG to match every param.sfo, with some extra info provided, i think this "feature" should be used more on all packages. It can even be multi language with different PIC1s.
see version in corner too, its cool because you can place text anywhere on the screen
sandungas
Developer
Hehe, nice trick, using PIC1.PNG to display some info about the actual "boot mode" used by the game could be handy, and incase the complete collection of combinations of this "boot modes" is not much big (lets say 5 or 6) then it can be made with pre-made images like in your screenshotExactly. I dont like that scrolling text either.
Bit off topic but anyway, Another way to display more info about an application is a PIC1.PNG that changes to show info. This does not need to be updated in database as its loaded fresh every time.
Here is an example of me using it to display a fake info line below the title on XMB. This could be used to display emulator settings in use, and more info such as info about the game even, if these can be generated by the manager? Even if they cant be generated, there could be a PIC1.PNG to match every param.sfo, with some extra info provided, i think this "feature" should be used more on all packages. It can even be multi language with different PIC1s.
see version in corner too, its cool because you can place text anywhere on the screen
View attachment 16166
Im not sure if the PSP games uses the PIC1.PNG though... in this case the official PIC1.PNG image can be ignored when updating the "PSP launcher" installation... is a bit bummer but this solves the problem
About what you mentioned before of using an icon of an UMD disc... i was thinking in this too, but we cant make the same that does the XMB with other game types
In other gae types you see the icon of the disc while is "out of focus", and when you move the cursor on top of it it changes to the real ICON0.PNG of the game
We cant make that "swap", so we need to choose one... and obviouslly the real ICON0.PNG of the game wins
The UMD icon could be displayed at other place, dunno, something like what you said as part of the PIC1.PNG... but this kind of design is not going to look like "official" style, so no sure, but initially i dont like it much
Btw, can you upload the 2 PARAM.SFOs you used when you made that backup of the hdd databases you uploaded before ?
Im looking at the area where is needed to apply the patch for the CATEGORY, and the info around it
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
0000AAE0 50 53 50 4D 36 36 38 32 30 00 00 00 00 PSPM66820....
0000AAF0 00 00 00 00 00 00 00 00 00 00 3F 00 00 00 01 00 ..........?.....
0000AB00 00 00 00 30 31 2E 30 30 00 00 00 00 00 00 00 00 ...01.00........
0000AB10 00 00 01 30 33 2E 31 30 30 30 00 4D 4E ...03.1000.MNTITLE_ID = lenght 0x10 ?
unknown = lenght 0x4 ? (and value 0x00000000 in this example)
RESOLUTION = lenght 0x4 ? (and value 0x0000003F in this example for all video modes enabled)
SOUND_FORMAT = lenght 0x4 ? (and value 0x00000001 in this example for LPCM 2.0 audio)
unknown = lenght 0x4 ? (and value 0x00000000 in this example)
APP_VER = lenght 0x8 ? (or VERSION)
unknown = lenght 0x4 ? (and value 0x00000000 in this example)
BOOTABLE = lenght 0x4 ? (and value 0x00000001 in this example)
PS3_SYSTEM_VER = lenght 0x8 (this one is for sure lenght 8)
CATEGORY = lenght 0x4 ?
Is important to identify that unknowns in between, because the search pattern depends of them, incase this unknown areas in between grows or squeezes in lenght then he search pattern would fail
I dont think are going to change in lenght though, but it could be good to idetify them, initially doesnt looks much chalenging... most of it around that area are values copyed from the original PARAM.SFO... so is just a matter of making some tests and comparing the samples to see where is stored each value
And btw... the CATEGORY only appears 1 time in the database, so we are sure this is the area where the patch needs to be applyed, and only applyed 1 time with lenght 2 bytes... im just being a bit picky and curious to find what is around it :P
Last edited:
I am 90% sure these are the 2 i used. Files move quick on my PC with all the different things i am at, so i cant be 100% sure.
EDIT: ok, i see they are different sizes, not good. ok i will check again.
EDIT: actually, i think i dont have the 2 of them anymore, i edited the one, and used that, so the other one is lost, i can redo experiment, or you can do it, its easy enough.
*removed files
EDIT: ok, i see they are different sizes, not good. ok i will check again.
EDIT: actually, i think i dont have the 2 of them anymore, i edited the one, and used that, so the other one is lost, i can redo experiment, or you can do it, its easy enough.
*removed files
Last edited:
sandungas
Developer
Ohh almost forgot, managunz includes the source code of imagemagick
https://en.wikipedia.org/wiki/ImageMagick
https://www.imagemagick.org/
Is like an image editor working inside managunz, with it you can do a looot of things to images, like scaling, rotating, cropping, adding effects, color changes, and i think one of the features is you can create images from text fonts. so yes, i guess managunz could generate that custom PIC1.PNG images dinamically with the texts about the modes used by the actual "PSP launcher"
Also, one of the libraries from PS3DK2 can generate small images for every character of a .ttf font, this is what managunz and irisman does internally, then other function displays every small image (for every character) aligned displayed as normal text, but are images
So dunno, but initially it seems there are 2 ways to achieve it... and i think using imagemagick is the easyest
The cool thing of imagemagick is you can install it in PC to make all the needed test to achieve the kind of image you want... and when you have the exact command with all the settings very well defined you can prepare a function in managunz to use this same settings you found in PC
I never did any of this though... and maybe some details of what im mentioning are not exactly like this and i made some mistake, but overall is a bit like this as far i now
https://en.wikipedia.org/wiki/ImageMagick
https://www.imagemagick.org/
Is like an image editor working inside managunz, with it you can do a looot of things to images, like scaling, rotating, cropping, adding effects, color changes, and i think one of the features is you can create images from text fonts. so yes, i guess managunz could generate that custom PIC1.PNG images dinamically with the texts about the modes used by the actual "PSP launcher"
Also, one of the libraries from PS3DK2 can generate small images for every character of a .ttf font, this is what managunz and irisman does internally, then other function displays every small image (for every character) aligned displayed as normal text, but are images
So dunno, but initially it seems there are 2 ways to achieve it... and i think using imagemagick is the easyest
The cool thing of imagemagick is you can install it in PC to make all the needed test to achieve the kind of image you want... and when you have the exact command with all the settings very well defined you can prepare a function in managunz to use this same settings you found in PC
I never did any of this though... and maybe some details of what im mentioning are not exactly like this and i made some mistake, but overall is a bit like this as far i now
Last edited:
Yes, probably easier and maybe more practical is just one to match each param.sfo. that gets swapped. If managunz could overlay some info about the game onto them, that would be cool, but far from essential, Like game title ID, and size etc.
I have tested, and both minis , and remasters allow for PIC1.PNG. So thats a plus.
sandungas
Developer
I been looking at the hdd database structure and adding some notes in my previous posts, im going to quote myself incase someone have missed it, this is what i have by now
There are 3 unkown areas of 4 bytes lenght, and im pretty sure one of them is the ATTRIBUTE, this is another thing easy to confirm by looking at other app in the database that could be using a PARAM.SFO with some value inside ATTRIBUTE
This are the next "easy" things that can be identifyed in this area without much work, there is no need to make much tests just look at other stuff indexed in the database and compare with the PARAM.SFO
The bigest difference in this area with the original PARAM.SFO is the endinaness
In the database some of this values are stored in big endian (from left to right), and inside the PARAM.SFO are in little endian (right to left), but the values and his lenght are the same
The value marked as APP_VER (or VERSION) is a bit doubtful because both uses to be always 01.00 and in this example i guess both was 01.00 so not sure... but it seems only one of them is stored in the database
There are 3 unkown areas of 4 bytes lenght, and im pretty sure one of them is the ATTRIBUTE, this is another thing easy to confirm by looking at other app in the database that could be using a PARAM.SFO with some value inside ATTRIBUTE
This are the next "easy" things that can be identifyed in this area without much work, there is no need to make much tests just look at other stuff indexed in the database and compare with the PARAM.SFO
The bigest difference in this area with the original PARAM.SFO is the endinaness
In the database some of this values are stored in big endian (from left to right), and inside the PARAM.SFO are in little endian (right to left), but the values and his lenght are the same
Last edited:
That would easily work if there are no checksums applied.
Checksums would be the only problem but that can be easily fixed if we identify the checksums position and while patching the category we also patch with the corresponding checksum.Not sure if this is all... but if this is all needed to be patched in the database i guess it can be made without needed to process all the database contents (in other words without knowing how the database internal structure works)
Processing the database without knowing his internal structure is a bit dirty, and could be unestable (we are not completly sure at this point), but incase it works it could be handy
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.
sandungas
Developer
We dont know if there is some checksum that affects the area where is needed to patch the 2 bytes of CATEGORY, this idea of the cheksum is something suggested by @Zar and initially i agree that is posible to exist some checksum used for safety/redundancy purposes (not for security) just to verify that the data you are reading from the database is correct
Anyway, as you metioned, if that checksum exists, it also exists the posibility of patching it
Finding where is the checksum is going to be a pita though, it seems by allowing the firmware to update the database "in the official way" there are lot of values that changes
One of the good things we have playing at our favour is the database file is not critical... if at some point is damaged or corrupted, the firmware probably have a "database manteinance plugin" that is going to either fix it... or rebuild a new database entirelly from scratch
So we have a safety web while making experiments
Btw, there seems to be multiple .sprx plugins related with database manteinance, the name of this one looks specially interesting:
mms_maintenance.sprx
And this one:
mms_minimdimp_media_hdd.sprx
Yep we know, we was discussing the fact that using a PARAM.SFO (in the first installation) with a TITLE length of 128 characters (using lot of 0x20 bytes at the end to fill it with spaces up to 128) is going to be "failproof" because this way the database structure is going to reserve them (ready to be modifyed later by non-official ways)
But the problem of doing that is visual... when you display that string in XMB is going to be animated with a horizontal scrolling (the texts moves from right to left)
And most of it (the characters most at right that are spaces) are going to be displayed as empty, so it will look like an error
For the initial tests "to play safe" we could ignore the visual annoyance and do it with the 128
The other intermediate solutions (different than 128) are:
Reserve the max of characters allowed before that scrolling animation starts
This is going to work nice for some homebrews and other uses... like what @Zar was mentioning, he had an option in a previous managunz versions to "update managunz" where the app was downloading a PKG from network, then it was extracting his contents, and then it was overriting the files inside managunz installation path
Overall it was working fine, but the problem is the new version of the PARAM.SFO included a different TITLE (as example: ManaGunZ v1.35)... that "v1.35" was not displayed correctly when exiting back to XMB
Reserve only the amount you need
In the case i was mentioning of managunz (and it at some point we are able to patch the database to change the TITLE) is easy to solve, because we know all the TITLE of all managunz versions (previous and future) are short, the string "ManaGunZ v1.35" needs 14 bytes + the NULL so we could reserve lets say... 16... or 18 or so (trying to not trigger that scrolling animation)
Reserve some, but we are not sure how much
For the "PSP Launcher" we cant solve the problem so easilly though :/
We need to make a TITLE reservation inside the database structure that covers the max lenght of the longest game TITLE officially published for PSP
I wonder if there is some database with all the complete collections of the PSP game catalog (redump.org maybe?)... this would help us to know how much bytes we need to cover all the PSP game catalog
Im guessing we dont need the 128... with 64 should be enought... or even less, but who knows...
Anyway, a dirty way to fix this if at some point the user tryes to boot a PSP game with a masive lenght TITLE then our "custom code" should not copy the TITLE string entirelly into the database
It will look bad, but it should work
------------------------------
Btw, the reason why i think this way of patching the database manually is going to work fine with the CATEGORY (and the others around the area i was using as example in my previous posts) is because by looking at the database file structure it can be seen that area is generated (by the database manteinance service) by doing simple copypastes of data from real PARAM.SFO ---to---> database
The only change made to some values is the endianess swap, but the lenghts are exactly the same in SFO and the dabatase
And all that values are stored a single time... so if we change the value in the database and in the real SFO then we have changed 100% of the info about it
The other info related with the value is his lenght, but we are not changing it... so the PS3 doesnt even realizes what happened... for the "database manteinance" service/plugin is the same stuff before and after
In my oppinion patching the CATEGORY (and most of the other values around it) have a huge probability to work in a simple way
For the TITLE im not so sure, because appears in lot of places, maybe this is going to be more tricky, but im keeping open mind and considering all posibilities, one of the posibilities is simply to forget about the TITLE by now (dont change it when updating the SFO, neither in the database), and focus in the CATEGORY first
Last edited:
I think we should not get too bogged down by thinking about title, its easy solve, there are a few simple solutions, and all of them are better than current situation with no title at all and multiple launchers etc.
- Just reserve maximum amount of letters that doesn't require scrolling in best and simplest imo, if game name is longer than that then it gets cut off. I highly doubt that sony released any PSP titles with scrolling titles , or if they did it will not be a big deal if last few letters are missing on 1 or 2 games
- Just have title say PSP launcher and put game info and icon0 into PIC1.PNG (overlaid). simple and effective, not as good though but maybe simpler to stay out of database apart from category change. We can do anything to PIC1.PNG , full control.
- Patch title properly and dynamically, probably doable, might take while to figure out, but once done probably simple enough.
@sandungas @DeViL303 Eh? I already gave a solution.
1. Test PARAM.SFO with title set to "TEST" and null padded (128-4=124 bytes filled with 00) and:
param_max_len = 128
param_len = 128
2. DB read param_len , and read all the bytes (it does not care about what the hell is in there)
3. XMB read PARAM.SFO/DB, it will read 128 bytes. Since it will try to do the usual crap, (encoding, check control codes 0A etc, ) it will most likely check for null. As soon it hits (right after TEST) it stops. So we only get TEST. This is a very common thing, in many languages having a buffer with a null somewhere and trying to encode it to a string will only get the string up to the null byte.
4. App finds offset of title. It writes new title, exampl, just "SD" It must find start of title,
Write S byte, write D byte and then null 00. Still 128 bytes in there.
To explain step by step:
1. Test PARAM.SFO with title set to "TEST" and null padded (128-4=124 bytes filled with 00) and:
param_max_len = 128
param_len = 128
2. DB read param_len , and read all the bytes (it does not care about what the hell is in there)
3. XMB read PARAM.SFO/DB, it will read 128 bytes. Since it will try to do the usual crap, (encoding, check control codes 0A etc, ) it will most likely check for null. As soon it hits (right after TEST) it stops. So we only get TEST. This is a very common thing, in many languages having a buffer with a null somewhere and trying to encode it to a string will only get the string up to the null byte.
4. App finds offset of title. It writes new title, exampl, just "SD" It must find start of title,
Write S byte, write D byte and then null 00. Still 128 bytes in there.
Nice one. Just tested and that works, put in full title, scrolling, then hex edited it down to not scrolling with all 00.
Sorry i thought you mean add spaces, which still scrolled, obviously you mean 00, which works.
Anyway, i have never seen an official game scroll, so I dont think its an issue.
sandungas
Developer
Good recap, i have to agree, if at some point the whole comcept of managunz "managing" the "PSP launcher" instalaltions works then we are doing a huge progress because is going to be a lot more noob friendly
And one of the critical things we need is to find a safe way to change the CATEGORY in the database
After that (and incase it works) we could worry about making it pretty by trying to change also TITLE in the database or by other means
In my oppinion this is an intermediate compromise that should work fine most of the times for the "PSP Launchers", but anyway, is needed to be used as default for other homebrews or other applications that updates the database by patching it
The example of the "update managunz" function i mentioned is a good candidate for it, zar removed it because the problem of the TITLE that was not updated in the database
I been mentioning that scrolling animation could be around 16 characters but was just a random number, i guess is going to be around 20 or 30 or so
If he reserves that size then is good enought to allow zar to release managunz versions with names like:
"ManaGunZ v1.35"
"ManaGunZ v1.40 beta 2"
"ManaGunZ v4.48.12"
"ManaGunZ v4.48.12 party edition"
Whatever... the only restriction is he needs to remember that he should not release a managunz version with a TITLE exceeding that lenght reserved in the database structure XD
Also, the "custom code" responsible of patching the TITLE in the database should ignore the last characters incase the TITLE of the new PARAM.SFO is longer (this should be made as a prevention to dont break the database structure by mistake)
There are other homebrews that could do the same "update" procedures, using the same lenght for the TITLE in all them, so that lenght could be something generic
Last edited:
sandungas
Developer
In short... you are "faking" the "param_len" of the TITLE in the SFO index table
But im not sure if this is going to work, i think i tryed time ago and was looking bad, not sure
Is not just to fill with zeroes the bytes that appears after the TITLE string
Is needed to change a value at top of the SFO structure... and technically that value is not going to be correct XD
The theory is XMB is going find the end of the string by itself (in some way ignoring the fake "param_len") when the string length is displayed
sandungas
Developer
Wait, im reading your post again, and im thinking this is a proof that works
So... you had a PARAM.SFO "forged" by a standard tool... either it was the official SFO of a game, or made with a PARAM.SFO editor like the one from aldostools
And that SFO had a long TITLE that was scrolling, right ?
Then you hexedited the SFO and replaced some of the characters at the end of the TITLE with zeroes
Copyed it to the PS3
Booted it (to force a database rebuild)
Exit
And the TITLE was not scrolling ?
--------------------------------------
If the test you made was like that i guess is the proof that it works
The first time you boot it with the scrolling string the "param_len" is right... and the second boot is wrong
But XMB bypasses the problem because that string is parsed (and checked for his lenght) several times
--------------------------------------
Is handy from the point if view of the PS3... but now im wondering if the PC tools or SDK tools are going to have some kind of problems with this "non-standard" PARAM.SFOs
Some code could consider is a mistake, and could "fix" it automatically, others maybe doesnt complains or could show some spaces
Off topic slightly: I have another idea, completely different, but as it would use official functions 100% to update the database, i think it might be worth discussing.
The backup manager, could just have 2 launchers pkgs built in (optional extra download just like now) , and it installs them as needed when a game is mounted, depending on options required it chooses the pkg, it would only take a second. So the database gets updated officially and properly. it could also copy a PIC1.PNG to the folder with the game name and icon0 "in" it, the pkgs would not have any PIC1.PNG included, so that would be persistent and not get overwritten by pkg when it installs.
On topic: I will do some proper tests now , hex editing title and category in database directly, my previous test was only hex editing param.sfo then rebuilding database. get back to you soon.
The backup manager, could just have 2 launchers pkgs built in (optional extra download just like now) , and it installs them as needed when a game is mounted, depending on options required it chooses the pkg, it would only take a second. So the database gets updated officially and properly. it could also copy a PIC1.PNG to the folder with the game name and icon0 "in" it, the pkgs would not have any PIC1.PNG included, so that would be persistent and not get overwritten by pkg when it installs.
On topic: I will do some proper tests now , hex editing title and category in database directly, my previous test was only hex editing param.sfo then rebuilding database. get back to you soon.
sandungas
Developer
Managunz can create PKGs from files and stores them in dev_hdd0/packages/ ready to be installed by the user. This feature is used in the "create shorcut PKG" (by now only available for PS3 games by pressing triangle over game icon)
Is what made me initially think in the idea that managunz could do the "PSP launcher" installations + the function to "enable priority" and the experimental "autoinstalls" that made me wonder if he was updating the hdd database manually
Add to it the other ideas we was mentioning before, like creating PIC1.PNG images with info (this could need lot of work i guess, initially zar is not going to like it much, but is something to consider because it seems it could work)
And of course, using the original ICON0.PNG of the game, and a PARAM.SFO edited with the TITLE of the game (using either real lenght, or lenght with the "fake" placeholder to allow to be patched later manually in the database)
Together with the EBOOT.BIN of the launcher selected by the user from a collection of EBOOT.BINs located in managunz installation path (triangle over PSP game icon to select "PSP emulator options", whatever)
At this point i think that "PSP Launcher" PKGs can be customized completly by managunz
The problem is by creating the PKGs in dev_hdd0/packages it requires the user to navigate to the "install packages" icon, and to start the installation manually
Ok, not much important, but if we can solve this is going to be much better
But at this point after all this brainstorming i think we should aim for something better XD
The first installation of that "PSP launcher" needs to be made manually because we cant rebuild the database to add a new entry
But the next times you boot the launcher (when you "mount" other PSP game or change PSP settings inside managunz) is where applyes most of what we have been discussing
In some way you are stepping back to the basic, creating PKGs for every change, but at this point i think zar is going to take a look at the database anyway to see if he can patch the TITLE because if this works it could be used to restore that "autoinstall" feature that was used (and later removed) as something experimental in a few previous managunz versions
Last edited:
So, here is my latest test.
Then i compared files, what i found was, there are a lot of changes when you change the category in a param.sfo editor and then install it, the database changes in lots of places.
So, i then tried just editing the 2 letter with hex editor and replacing database, no change to be seen on XMB.
I then tried pasting whole section for my test app from one database to the other, and it works perfectly, app changes category, without rebuilding database. So i can confirm that we can edit database, and there is no hash check etc.
So that is looking good, but i think database patch will have to be complete section in full.
I have attached both databases and param.sfo used.
- format system
- install rebug toolbox
- install pkg with category as MN
- Dump database
- delete app from xmb
- Install pkg with category as PE (exact same pkg in every other way)
- dump database
- try edit just category in db with hex editor (fail)
- try to paste in full section from other DB (succeed)
Then i compared files, what i found was, there are a lot of changes when you change the category in a param.sfo editor and then install it, the database changes in lots of places.
So, i then tried just editing the 2 letter with hex editor and replacing database, no change to be seen on XMB.
I then tried pasting whole section for my test app from one database to the other, and it works perfectly, app changes category, without rebuilding database. So i can confirm that we can edit database, and there is no hash check etc.
So that is looking good, but i think database patch will have to be complete section in full.
I have attached both databases and param.sfo used.
Last edited:
@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.
I opted for a more simple solution: support both PSP Launchers (Mini and PSP Remasters) with titleid: PSPM66820 & PSPC66820 respectively.
If the option Show PSP Launcher is selected, both launchers now are listed in the PSP category of webMAN MOD with their icons updated.
So now it's very easy to choose the launcher for Mini or the one for PSP Remasters directly from the PSP folder (if both launchers are installed).
Additionally this release now supports auto-play of PSPISO (the option Show PSP Launcher must be marked) .
I included the supported PSP Launchers of Jjkkyu in this release:
SRC + Download: https://github.com/aldostools/webMAN-MOD/releases/tag/1.47.15
I opted for a more simple solution: support both PSP Launchers (Mini and PSP Remasters) with titleid: PSPM66820 & PSPC66820 respectively.
If the option Show PSP Launcher is selected, both launchers now are listed in the PSP category of webMAN MOD with their icons updated.
So now it's very easy to choose the launcher for Mini or the one for PSP Remasters directly from the PSP folder (if both launchers are installed).
Additionally this release now supports auto-play of PSPISO (the option Show PSP Launcher must be marked) .
I included the supported PSP Launchers of Jjkkyu in this release:
SRC + Download: https://github.com/aldostools/webMAN-MOD/releases/tag/1.47.15
Last edited:
Similar threads
-
-
-
PS3 Unable to launch PSP backups: An error occurred
- Started by JukienDukien
- Replies: 0
-
PS3 ps3netsrv streaming encrypted Redump ISO gives error code 80010017 despite correct dkey + iso
- Started by osunnfx
- Replies: 0