PS3 4.89 Update is Live! - Discussions / Details about the firmware update

The story is... when the firmware is compiled it uses some additional tools we dont have, as example when the rco files are compiled (as a whole entity) there is some kind of script that generates the layout.txt files
This process is made sequentially, the resulting order of how the values are stored inside the layout.txt files probably depends of a list that tells which rco goes first and which one goes next and so on...
Also, the layout.txt files are generated in paralell... lets say, the process "opens" several text files and then it starts adding "line 1" (in all them), after that "line 2" (in all them) and so on

What i explained before about how the values for the smaller resolutions are calculated using scale factors is used massivelly in OFW... but is not an strict rule, there are some elements that are adjusted manually
Im going to post the list with the 7 new values for a better understanding of what happened

layout_grid_table_1080.txt
380
50
1280
23
55
218
218

layout_grid_table_720.txt
253
33
853
15
37
145
145

layout_grid_table_480.txt
169
22
569
10
24
97.97 <--- the first 97 belongs to 480p, but the last 97 was supposed to be copyed to layout_grid_table_272.txt
97.97 <--- the first 97 belongs to 480p, but the last 97 was supposed to be copyed to layout_grid_table_272.txt

layout_grid_table_272.txt
169
22
569
10
24
missing <--- the compiler forgot to copy the 97 here, ooops (it added an space instead)
missing <--- the compiler forgot to copy the 97 here, ooops (it added an space instead)

--------------------

As you can see, in between 1080p, 720p, and 480p they was applying scale factors... but in between 480p and 272p they was just "copypasting" the values from 480p to 272p (in other words... in this case the 272p mode uses the same values than 480p mode)

So i was about to suggest to use the 97.97 for the two missing values for the 272p resolution... but then i started thinking in how the compiler works... and that value 97.97 that smells a bit fishy, right ? (i mean, why dont they used 98 ?, it looks a bit retarder to dont round it)

Long story short... the compiler was trying to add a 97 to the 480p file and another 97 to the 272p file... but instead of that it added the value 97 two times consecutivelly to the 480p file (separated by a dot) and it added spaces for 272p
The result is both files of both resolutions was broken, the 272p (for remote play) and 480p (for SD displays)

Im uploading a new version of this 2 files with the final fix

DOWNLOAD ---> https://workupload.com/file/jzpLGzr4DJC
 
Last edited:
sandungas said:
The story is... when the firmware is compiled it uses some additional tools we dont have, as example when the rco files are compiled (as a whole entity) there is some kind of script that generates the layout.txt files
This process is made sequentially, the resulting order of how the values are stored inside the layout.txt files probably depends of a list that tells which rco goes first and which one goes next and so on...
Also, the layout.txt files are generated in paralell... lets say, the process "opens" several text files and then it starts adding "line 1" (in all them), after that "line 2" (in all them) and so on

What i explained before about how the values for the smaller resolutions are calculated using scale factors is used massivelly in OFW... but is not an strict rule, there are some elements that are adjusted manually
Im going to post the list with the 7 new values for a better understanding of what happened

layout_grid_table_1080.txt
380
50
1280
23
55
218
218

layout_grid_table_720.txt
253
33
853
15
37
145
145

layout_grid_table_480.txt
169
22
569
10
24
97.97 <--- the first 97 belongs to 480p, but the last 97 was supposed to be copyed to layout_grid_table_272.txt
97.97 <--- the first 97 belongs to 480p, but the last 97 was supposed to be copyed to layout_grid_table_272.txt

layout_grid_table_272.txt
169
22
569
10
24
missing <--- the compiler forgot to copy the 97 here, ooops (it added an space instead)
missing <--- the compiler forgot to copy the 97 here, ooops (it added an space instead)

--------------------

As you can see, in between 1080p, 720p, and 480p they was applying scale factors... but in between 480p and 272p they was just "copypasting" the values from 480p to 272p (in other words... in this case the 272p mode uses the same values than 480p mode)

So i was about to suggest to use the 97.97 for the two missing values for the 272p resolution... but then i started thinking in how the compiler works... and that value 97.97 that smells a bit fishy, right ? (i mean, why dont they used 98 ?, it looks a bit retarder to dont round it)

Long story short... the compiler was trying to add a 97 to the 480p file and another 97 to the 272p file... but instead of that it added the value 97 two times consecutivelly to the 480p file (separated by a dot) and it added spaces for 272p
The result is both files of both resolutions was broken, the 272p (for remote play) and 480p (for SD displays)

Im uploading a new version of this 2 files with the final fix

DOWNLOAD ---> https://workupload.com/file/jzpLGzr4DJC
Click to expand...
Nicely sussed out, good job ;-)
 
sandungas said:
The story is... when the firmware is compiled it uses some additional tools we dont have, as example when the rco files are compiled (as a whole entity) there is some kind of script that generates the layout.txt files
This process is made sequentially, the resulting order of how the values are stored inside the layout.txt files probably depends of a list that tells which rco goes first and which one goes next and so on...
Also, the layout.txt files are generated in paralell... lets say, the process "opens" several text files and then it starts adding "line 1" (in all them), after that "line 2" (in all them) and so on

What i explained before about how the values for the smaller resolutions are calculated using scale factors is used massivelly in OFW... but is not an strict rule, there are some elements that are adjusted manually
Im going to post the list with the 7 new values for a better understanding of what happened

layout_grid_table_1080.txt
380
50
1280
23
55
218
218

layout_grid_table_720.txt
253
33
853
15
37
145
145

layout_grid_table_480.txt
169
22
569
10
24
97.97 <--- the first 97 belongs to 480p, but the last 97 was supposed to be copyed to layout_grid_table_272.txt
97.97 <--- the first 97 belongs to 480p, but the last 97 was supposed to be copyed to layout_grid_table_272.txt

layout_grid_table_272.txt
169
22
569
10
24
missing <--- the compiler forgot to copy the 97 here, ooops (it added an space instead)
missing <--- the compiler forgot to copy the 97 here, ooops (it added an space instead)

--------------------

As you can see, in between 1080p, 720p, and 480p they was applying scale factors... but in between 480p and 272p they was just "copypasting" the values from 480p to 272p (in other words... in this case the 272p mode uses the same values than 480p mode)

So i was about to suggest to use the 97.97 for the two missing values for the 272p resolution... but then i started thinking in how the compiler works... and that value 97.97 that smells a bit fishy, right ? (i mean, why dont they used 98 ?, it looks a bit retarder to dont round it)

Long story short... the compiler was trying to add a 97 to the 480p file and another 97 to the 272p file... but instead of that it added the value 97 two times consecutivelly to the 480p file (separated by a dot) and it added spaces for 272p
The result is both files of both resolutions was broken, the 272p (for remote play) and 480p (for SD displays)

Im uploading a new version of this 2 files with the final fix

DOWNLOAD ---> https://workupload.com/file/jzpLGzr4DJC
Click to expand...

Eres un crack! Clever solution!
 
sandungas said:
The story is... when the firmware is compiled it uses some additional tools we dont have, as example when the rco files are compiled (as a whole entity) there is some kind of script that generates the layout.txt files
This process is made sequentially, the resulting order of how the values are stored inside the layout.txt files probably depends of a list that tells which rco goes first and which one goes next and so on...
Also, the layout.txt files are generated in paralell... lets say, the process "opens" several text files and then it starts adding "line 1" (in all them), after that "line 2" (in all them) and so on

What i explained before about how the values for the smaller resolutions are calculated using scale factors is used massivelly in OFW... but is not an strict rule, there are some elements that are adjusted manually
Im going to post the list with the 7 new values for a better understanding of what happened

layout_grid_table_1080.txt
380
50
1280
23
55
218
218

layout_grid_table_720.txt
253
33
853
15
37
145
145

layout_grid_table_480.txt
169
22
569
10
24
97.97 <--- the first 97 belongs to 480p, but the last 97 was supposed to be copyed to layout_grid_table_272.txt
97.97 <--- the first 97 belongs to 480p, but the last 97 was supposed to be copyed to layout_grid_table_272.txt

layout_grid_table_272.txt
169
22
569
10
24
missing <--- the compiler forgot to copy the 97 here, ooops (it added an space instead)
missing <--- the compiler forgot to copy the 97 here, ooops (it added an space instead)

--------------------

As you can see, in between 1080p, 720p, and 480p they was applying scale factors... but in between 480p and 272p they was just "copypasting" the values from 480p to 272p (in other words... in this case the 272p mode uses the same values than 480p mode)

So i was about to suggest to use the 97.97 for the two missing values for the 272p resolution... but then i started thinking in how the compiler works... and that value 97.97 that smells a bit fishy, right ? (i mean, why dont they used 98 ?, it looks a bit retarder to dont round it)

Long story short... the compiler was trying to add a 97 to the 480p file and another 97 to the 272p file... but instead of that it added the value 97 two times consecutivelly to the 480p file (separated by a dot) and it added spaces for 272p
The result is both files of both resolutions was broken, the 272p (for remote play) and 480p (for SD displays)

Im uploading a new version of this 2 files with the final fix

DOWNLOAD ---> https://workupload.com/file/jzpLGzr4DJC
Click to expand...

You are brilliant, all visual bugs have been fixed.

Thank you
 
LuanTeles said:
You are brilliant, all visual bugs have been fixed.

Thank you
Click to expand...
Nice, 480p fix confirmed, but have you tryed 272p (for remote play) too ?
It was @Algol who was reporting 272p broken... i guess we have to wait for his confirmation too

Btw, the other day you discovered an easter egg coincidentially in one of your experiments, have you tryed what i mentioned here ?
https://www.psx-place.com/threads/research-rcomage-psdevwiki-mod.17958/page-4#post-332956
It seems you enabled the glowing effect of a <text> object when you was swapping the layout.txt files in between 4.88 and 4.89... and the only explanation posible for that is because the rco was loading it from the layout.txt files. It seems to be one of the unknown "override" attirbutes at the end of the <text> objects
 
Just registered on the forums to let everyone know please just be patient and wait for the new release!! I didn't, used the 4.89 ps3updatelist.txt workaround for getting online on hen and it screwed Windows. People here are worried about being banned, I'd be more worried about a virus from an unofficial source. Anything that is not official is most likely malware and everyone should wait for the official hybrid firmware and HEN to be released, they know what they're doing. DO NOT download any workarounds and just wait, it's the best advice. Homebrew community is full of rats, watch out for them.
 
If Sony become aware of the bug within there 4.89 Ofw and they bring an update patch to the PS3 hen and hfw process will just have to be repeated
 
@esc0rtd3w i'm seeing here the hen 3.1.0 source, i realized that the pseudo cobra is still 8.1, will it be updated in the future to 8.3? (Fan control, save data converter, act.dat creation and etc)

BTW what is it for? in the xai plugin

<Pair key="title"><String>Set Kernel FW Version To 4.86</String></Pair>
<Pair key="info"><String>Sets Build Date For HEN Detection</String></Pair>

and

<Pair key="title"><String>NoPSN Patch: DEV TEST ONLY</String></Pair>
<Pair key="module_action"><String>nopsn_test</String></Pair>

is this somehow a universal patch?
 
Last edited:
You must log in or register to reply here.

Similar threads

Back
Top