ManaGunZ

PS3 ManaGunZ - PS3 Backup Manager by Zar v1.41

@Zar
but what about fselfs? they don't need any flags afaik and most mods are made of fself. this now makes me curious

edit
I will try now some "sys-apps" resigned to fself to see if they will work
 
Last edited:
So if I understand correctly, correct me if I am wrong as I never use those sprx game mods, basically the problem comes from the mod itself. The eboot should check permissions & set them properly if found inadequate before launching the sprx. It does not look like a job that should be done by backup managers..

While what you're saying is definitely true, anyone that uses multiMAN (which is pretty much everyone) would never have experienced this problem. As a developer, I'm sure you will understand that it's near enough impossible to fix something you're unaware of. Who knows, maybe future mods will now implement such checks (I doubt it though).
 
I don't know what are fself, is it the 'launchable' self ? Like ManaGunZ.self ? (the eboot in managunz is used only to boot the self.)

Anyway, I think every executable have these flags, on scetools if you don't define any you'll get the lowest lvl. ( every prx, self, eboot )
 
I don't know what are fself, is it the 'launchable' self ? Like ManaGunZ.self ? (the eboot in managunz is used only to boot the self.)

Anyway, I think every executable have these flags, on scetools if you don't define any you'll get the lowest lvl. ( every prx, self, eboot )
fself=sdk signed elfs or the so called "debug eboots". I think you can even somehow define on scetool flag 8000 for debug. correct me if I am wrong

correct myself, you have to use keyset 8000 for debug. sth like that...

I have to note this as well for my list, to make some fself testings. but I think I already have tried this and not everything will work

not to forget, nice find :)
 
Last edited:
fself=sdk signed elfs or the so called "debug eboots". I think you can even somehow define on scetool flag 8000 for debug. correct me if I am wrong

correct myself, you have to use keyset 8000 for debug. sth like that...

I can't tell you anything, I never looked inside scetools. I'm just a novice user ;)
 
While what you're saying is definitely true, anyone that uses multiMAN (which is pretty much everyone) would never have experienced this problem. As a developer, I'm sure you will understand that it's near enough impossible to fix something you're unaware of. Who knows, maybe future mods will now implement such checks (I doubt it though).
Using Multiman probably only works because deank had to use similar permission fixes back in the days for other reasons & he probably extended the practice to be used by default but if the mod works with multiman, it is only a side effect of other workarounds.
Testing mods with only one backup manager is obviously not enough.

Anyway it is not a criticism, every coder at some point wrote buggy code based on wrong assumptions. Here the mod assumes that the eboot has permissions by default that it does not have unless it uses an appropriate control flag. That kinda stuff happens..
But generally speaking, I still don't think it's up to backup managers to fix problems introduced by mods because of insufficient testing, especially when the issue is easy to fix as we now know, thanks to Zar's testing ;-)
 
Last edited:
@Zar I'm not sure if you're aware of this or not, but there seems to be a minor bug when viewing text files. Sometimes (seemingly) random characters will appear at the end of the file. I'm not sure how to produce this consistently, but the times I've noticed it is when viewing one file after another.
 
  • Like
Reactions: Zar
or just give a higher capability/control flag to the eboot ;)
But this involves resigning it, and i dont think is a good idea to force that resigning for 100% of the games
Personally i consider that kind of changes to the game files something "invasive" (specially if is made in "silent mode" without advising the user about what is happening)

The check to the file permissions of the EBOOT in the way multiman is doing it is fine because that permissions are mostly a "flag" in the filesystem, when we change them we are not modifying the file

@Zar I'm not sure if you're aware of this or not, but there seems to be a minor bug when viewing text files. Sometimes (seemingly) random characters will appear at the end of the file. I'm not sure how to produce this consistently, but the times I've noticed it is when viewing one file after another.
Yes, is a known little bug known since time ago, we even gave it a funny name to talk about it, lol
The problem is the characters that appears at the end of the "text viewer" are random (we dont know where they come), are some kind of "garbage" bytes, and everytime you open a text file the garbage bytes varies...try to open and close the same text several times

Is the kind of bug hard to fix because is not clear at all why it happens, zar was trying to find the problem several times, but no luck yet... and well... considering it doesnt causes major problems is one of that details that was moved to the end of the "to do" list
 
Btw @Zar i just had a little idea related with the IRD checks, is just a visual detail i imagined when i was writing this post https://www.psx-place.com/threads/trouble-ripping-silent-hill-hd-collection.32519/#post-275690

This tool named "PS3 ISO tool rebuilder" is very popular because is promoted in http://jonnysp.bplaced.net/
I use a different tool in PC that allows me to save a .log file of the report, but anyway... there are a couple of visual details i like from this screenshot
ps3-iso-rebuilder_2020-12-31_19-43-57-png.29603


Can you add this same colors to the managunz IRD report screen ?
Red is #FF7F50
Green #90EE90
Yellow #FFD700

Also, can you add a special string for the missing PS3UPDAT.PUP ?, i mean... the other game files are reported as "invalid", but the PS3UPDAT.PUP could be reported as "pointless"
Im asking about this because most people deletes the PUP, we know is missing but we dont care because our goal is not to preserve the full integrity of the game files (we just care about the others, but not the PUP), something like this:
If filename = PS3UPDATE && state = notfound (print "pointless")
else if filename != PS3UPDATE && state = notfound (print "missing")

Im suggesting to use the word "pointless" because i cant figure a more technical one, im not native english speaker, if someone have a better idea just tell




Edit:
In plain words... in most/all IRD tools the missing PS3UPDAT.PUP is reported as an error... but this is a bit confusing for newcomers
 
Last edited:
Hmm, im reading again my previous post and im not so sure...
The idea of displaying the files in colors using the same exact colors than the other tool is something i like because is intuitive and some people is used to that colors

But im not sure how coud be the best way to report something special about the missing PUP
The goal of my suggestion was to be able to run an IRD check in a game where the only difference is the missing PUP and inform the user that the game is good, and the PUP file doesnt belongs to the game files, is mostly like an "addon" in the disc but the game doesnt needs it
 
Hmm, im reading again my previous post and im not so sure...
The idea of displaying the files in colors using the same exact colors than the other tool is something i like because is intuitive and some people is used to that colors

But im not sure how coud be the best way to report something special about the missing PUP
The goal of my suggestion was to be able to run an IRD check in a game where the only difference is the missing PUP and inform the user that the game is good, and the PUP file doesnt belongs to the game files, is mostly like an "addon" in the disc but the game doesnt needs it

Maybe at the beginning or end of the file. A message saying something like "PS3UPDAT.PUP was not found. This file is non essential to the functionality of the game."

That's the best I can think of :beguiled:
 
Maybe at the beginning or end of the file. A message saying something like "PS3UPDAT.PUP was not found. This file is non essential to the functionality of the game."

That's the best I can think of :beguiled:
Yeah, something like that, but it needs to be intuitive and short, your sentence is too long :D
It could be nice to find a way to give this info to the user in a single word or a couple, or with colors, but i guess the colors needs a "legend" at bottom to explain with text what means each color
 
About : "Do not resign EBOOT, keep it original' : it's modified EBOOT to load sprx menu, so, it's not the original EBOOT, the creator of the mod must sign correctly his mod EBOOT.
About : "IRD displayed in color" : I don't know yet, right now the result is just txt file, it doesn't support colors
About : "Ignore the presence of PS3UPDATE.PUP", good idea ;)
About : "Garbage characters in txt viewer", as sandungas said it's a PITA since I made this feature :s
 
Last edited:
I just realized about 2 problems in the IRD check screen:

Average speed sometimes is broken
In the progress bar most at top... the value located at the center of the progress bar... sometimes displays 2147483647.1e+07 GB/s (exactly the same for different files)

New filenames incorrect position
The new filenames appear at most top-left corner of the screen (overlapping the "elapsed time" text)... and inmediatly is moved to the correct position
 
And a suggestion...
In the IRD check screen it could be better to display the complete path/filename... right now only displays the filename (not the path)... but the whole width of the screen is available to display the path


---------------------------------------------------
Aaaand something very weird (and partially funny)...
When the IRD check is completed.... and appears the "text viewer" with the results of the check... try this:
1) Scroll down to the bottom of the text
2) Press (and hold) D-pad down
3) Press (and hold) D-pad right (or D-pad left)

This reduces the font size inside the text viewer :D
 
  • Like
Reactions: Zar
Are the 480p patches really the best output options available for the PS2 emulator?
640x512 being the best resolution, then stretched out to whatever with the video mode?
PS3 makes everything to 720p regardless?,
576P isn't possible instead or better like GSM?

I broke down the 480p video mode patch of Primal as follows but it still uses 640x448 as the base resolution unpatched.

// Progressive Scan
patch=1,EE,203E9A2C,extended,3C0500??/00052C00, 00=Progressive, 01=Interlaced
patch=1,EE,203E9A34,extended,3C0600??//00063400, ?? 50=480P
patch=1,EE,203E9A3C,extended,3C0700??//00073C00, 00=Field, 01=Frame

//?????
patch=1,EE,0042C530,extended,000000??// 00=Progressive, 01=Interlaced
patch=1,EE,0042C532,extended,000000??// 02=NTSC, 50=480P
patch=1,EE,0042C534,extended,000000??// 00=Field, 01=Frame : Field Mode
patch=1,EE,0042C53C,extended,000000??/ 05=Interlaced, 08=Progressive

patch=1,EE,0048840C,extended,000000??// 50=480P
patch=1,EE,00488623,extended,000000??// 00=Interlaced , 01=Progressive
----------------------------------------------------------------

case 0x2:
mode = "NTSC 640x448 @ 59.940 (59.82)"; gsSetVideoMode(GS_VideoMode::NTSC); break;

case 0x1:
case 0x3:
mode = "PAL 640x512 @ 50.000 (49.76)"; gsSetVideoMode(GS_VideoMode::PAL); break;

case 0x1A: mode = "VESA 640x480 @ 59.940"; gsSetVideoMode(GS_VideoMode::VESA); break;
case 0x1B: mode = "VESA 640x480 @ 72.809"; gsSetVideoMode(GS_VideoMode::VESA); break;
case 0x1C: mode = "VESA 640x480 @ 75.000"; gsSetVideoMode(GS_VideoMode::VESA); break;
case 0x1D: mode = "VESA 640x480 @ 85.008"; gsSetVideoMode(GS_VideoMode::VESA); break;

case 0x2A: mode = "VESA 800x600 @ 56.250"; gsSetVideoMode(GS_VideoMode::VESA); break;
case 0x2B: mode = "VESA 800x600 @ 60.317"; gsSetVideoMode(GS_VideoMode::VESA); break;
case 0x2C: mode = "VESA 800x600 @ 72.188"; gsSetVideoMode(GS_VideoMode::VESA); break;
case 0x2D: mode = "VESA 800x600 @ 75.000"; gsSetVideoMode(GS_VideoMode::VESA); break;
case 0x2E: mode = "VESA 800x600 @ 85.061"; gsSetVideoMode(GS_VideoMode::VESA); break;

case 0x3B: mode = "VESA 1024x768 @ 60.004"; gsSetVideoMode(GS_VideoMode::VESA); break;
case 0x3C: mode = "VESA 1024x768 @ 70.069"; gsSetVideoMode(GS_VideoMode::VESA); break;
case 0x3D: mode = "VESA 1024x768 @ 75.029"; gsSetVideoMode(GS_VideoMode::VESA); break;
case 0x3E: mode = "VESA 1024x768 @ 84.997"; gsSetVideoMode(GS_VideoMode::VESA); break;

case 0x4A: mode = "VESA 1280x1024 @ 63.981"; gsSetVideoMode(GS_VideoMode::VESA); break;
case 0x4B: mode = "VESA 1280x1024 @ 79.976"; gsSetVideoMode(GS_VideoMode::VESA); break;

case 0x50: mode = "SDTV 720x480 @ 59.94"; gsSetVideoMode(GS_VideoMode::SDTV_480P); break;
case 0x51: mode = "HDTV 1920x1080 @ 60.00"; gsSetVideoMode(GS_VideoMode::HDTV_1080I); break;
case 0x52: mode = "HDTV 1280x720 @ ??.???"; gsSetVideoMode(GS_VideoMode::HDTV_720P); break;
case 0x53: mode = "SDTV 768x576 @ ??.???"; gsSetVideoMode(GS_VideoMode::SDTV_576P); break;
case 0x54: mode = "HDTV 1920x1080 @ ??.???"; gsSetVideoMode(GS_VideoMode::HDTV_1080P); break;

case 0x72: mode = "DVD NTSC 640x448 @ ??.???"; gsSetVideoMode(GS_VideoMode DVD_NTSC); break;
case 0x73: mode = "DVD PAL 720x480 @ ??.???"; gsSetVideoMode(GS_VideoMode DVD_PAL); break;
 
Last edited:
In the widescreens patches thread in official pcsx2 forums ive seen people doing patches for "superwidescreen" monitors (with 21:9 aspect ratio), because they are playing in PC, and that monitors with 21:9 aspect ratio are popular for PC

So i guess that is posible to use any values, they have some tutorials that explains how to find this values for any game, seems to be the kind of thing that is tricky for a newcomer, but after you got the idea of how it works is relativelly easy to do it with any game... because mostly it requires patience and lot of test-error
 
In the widescreens patches thread in official pcsx2 forums ive seen people doing patches for "superwidescreen" monitors (with 21:9 aspect ratio), because they are playing in PC, and that monitors with 21:9 aspect ratio are popular for PC

So i guess that is posible to use any values, they have some tutorials that explains how to find this values for any game, seems to be the kind of thing that is tricky for a newcomer, but after you got the idea of how it works is relativelly easy to do it with any game... because mostly it requires patience and lot of test-error

How difficult would it be to add a group of multiple values to select from for one address into the pnach based system?
since the values are already known, with a label set for each selectable value.
Something like PEC/CEP's drop down menu for ePSXe.
 
Back
Top