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

LuanTeles said:
Seems a false alert [emoji14]

I thought it worked when the EULA agreement appeared, my bad

yw71SLn.png
Click to expand...
Still, it means it's easy to bring the GUI back. Then if we are lucky, it may only be a matter of tweaking the data transferred to PSN.. Or not.. lol
 
bguerville said:
Still, it means it's easy to bring the GUI back. Then if we are lucky, it may only be a matter of tweaking the data transferred to PSN.. Or not.. lol
Click to expand...

I can set my country, language, birth date and go to the next screen, accept the EULA then next screen again, enter the email, password and go to next one one more time, a lot of network activity happens in this part, but after a while it gives me this error
 
LuanTeles said:
@bguerville i rolled back to 4.88 and the same error, maybe is psn server refusing the connection.
Click to expand...
My guess is with the PS3 4.89 release they are restructuring his network services, for us the network services looks simple, one for online gaming and another for the store, but internally probably everything is splitted in small services using different protocols, located in different "nodes" of the network, etc... and multiplyed by several playstation models... probably is a huge mess
And now it looks they are dropping support for some of that services for PS3 and PSvita

Being optimistic... the good thing is they are going to keep opened the online gaming and the store
I mean... there was many people thinking that sony was going to drop the online completly for PS3 soon... but the update 4.89 is a proof that they doesnt have any intention to do it... at least by now, and probably for a lot more time
Is needed to keep in mind they kept the PS2 online gaming service opened many years after the PS2 stopped production (and im not sure... but probably there is still some PS2 online service alive)
 
LuanTeles said:
Even moving all rcos and layout files from 4.88 to 4.89 will still have bugs

- Impose_plugin: The battery icon is in the right corner of the screen (Edit fixed by basic_plugins.sprx)
- system_plugin: The notification is wider than it should. (Edit fixed by basic_plugins.sprx)
- wboard_plugin: The rss text is blinking. (Edit fixed by basic_plugins.sprx)
- explorer_plugin_full : Throphies are upsidedown (Edit fixed by explore_plugin.sprx)
- osk_plugin: Completely broken. (Edit fixed by osk sprxs)
- webbrowser : The shadow takes up all the screen (Even replacing all rcos + sprxs + layout files, this bug is still there)

Lots of sprx have been modified, video player. save data sprxs, osk (keyboard), all category sprxs, etc. (All of them are smaller) I wonder why.
Click to expand...
Interesting results, you know the sprx files can create rcoxml objects right ? (is like if the sprx is modifying the xml code generated by rcomage)
Lets call this objects LEGO blocks
I think all the problems you had in this experiment is because the new sprx files contains LEGO blocks that are trying to load settings from inside the new layout_grid*.txt files from 4.89 (with the displacement of +7 lines)
You are downgrading the layout.txt files (removing the displacement of +7 lines), so a few of the new sprx cant find the external settings of the LEGO blocks embedded in his internal sprx structure

I guess a lot of the updated sprx has been updated by the same reason, they contains LEGO blocks that required to add +7 units in the values that indicates a line in the layout.txt files

-----------------------------------------
Yesterday i was trying to find which rcoxml objects are loading the new 7 values you mentioned in this post (lines 2580 up to 2586 from the layout_grid_table****.txt files)
https://www.psx-place.com/threads/4...the-firmware-update.37203/page-10#post-332535

If we do the conversion in opposite direction we can deduce which value is stored in the rco or inside the sprx (the responsible to load a line from the layout.txt file), the 7 values from your screenshot needs to be loaded by using:
0x130a0100 or 0x130a0000 (loads the value located at line 2580 of the layout_grid_table****.txt)
0x140a0100 or 0x140a0000 (loads the value located at line 2581 of the layout_grid_table****.txt)
0x150a0100 or 0x150a0000 (loads the value located at line 2582 of the layout_grid_table****.txt)
0x160a0100 or 0x160a0000 (loads the value located at line 2583 of the layout_grid_table****.txt)
0x170a0100 or 0x170a0000 (loads the value located at line 2584 of the layout_grid_table****.txt)
0x180a0100 or 0x180a0000 (loads the value located at line 2585 of the layout_grid_table****.txt)
0x190a0100 or 0x190a0000 (loads the value located at line 2586 of the layout_grid_table****.txt)
The last 2 bytes of the hex, with values 0100 or 0000 are a multiplyer (loaded from the layout_factor_table****.txt files) that represents either an 1 or a 0
You know... if you multiply something by 1 the factor doesnt makes any difference to the "grid" value
Otherway, if is multiplyed by zero is like deleting the "grid" value

Well, i was trying to search for them inside npsignin_plugin.rco and regcam_plugin.rco (the 2 rco files that increases his size most), but in the xml file generated by rcomage are not used
Weird, isnt it ?... i mean... we are 100% sure that values are loaded by "something", and that something are the attributes named:
-positionOverrideX
-positionOverrideY
-positionOverrideZ
-sizeOverrideX
-sizeOverrideY
-sizeOverrideZ
-textOverrideUnk56 <--- this is the font size, remember this talk ? ;)
-textOverrideUnk57
-textOverrideUnk58
-editboxOverrideUnk56 <--- this is the font size, remember this talk ? ;)
-editboxOverrideUnk57
-editboxOverrideUnk58

Maybe there are others labeled as unkown in the "rcomage psdevwiki mod" from this list... but my point is... what sony did to all this values is to add +7 units for 4.89. Either in the LEGO blocks of the rco files... or in the LEGO blocks "embedded" inside the sprx files

I cant find them inside the rco files from 4.89, so im guessing are in the sprx files
The amount of "updated code" is minor (just a couple of bytes here and there)... but we cant change them in the sprx files :/
 
Last edited:
Md Hesam said:
I think 1month need for new HFW 4.89
Click to expand...
Just to keep everyone posted.

HFW and HEN are both essentially ready, esc0 is testing thoroughly and is waiting for new icons for a new XMB entry.
There's also that rco issue that he is testing further.

Evilnat's CFW should be released in coming days afaik.
The PS3 Toolset and the pyPS3tools are also ready to deploy, patiently waiting for Nat's release.

No ETAs, please don't ask.
 
LuanTeles said:
@esc0rtd3w if you have time, can you please add support for https in HEN? at least to support the version.bin hosted at github
Click to expand...
I doubt he will consider your suggestion in this release.
A big overhaul is on the cards for the HEN installer anyway, we will look into SSL support then, it's always good to have, moreover it might become necessary anyway if ever we decided to consolidate hosting.
 
LuanTeles said:
Just not to break the mention on my previous post by editing it

@esc0rtd3w

In addition to SSL support, I would also like to suggest the automatic icon swap feature and upgrade the mappath using @aldostools code, it uses less memory ( i had problems using the current map path method)
Click to expand...
Keep in mind that without explicitly providing a custom cert to the source, ONLY the SSL root certificates provided through the system trusted store will be supported, basically the same SSL support level as the PS3 browser.
 
Yamaha said:
Im just wondering homebrews like Apollo save tool or Artemis cheat need update? Because this new firmware seems troublesome
Click to expand...
There is no official release yet. The team is working to deliver something perfect. Wait until everything is ready. Regarding homebrews, they should all be working 100% after official release of a HFW 4.89 + new HEN.
 
LuanTeles said:
Just not to break the mention on my previous post by editing it

@esc0rtd3w

In addition to SSL support, I would also like to suggest the automatic icon swap feature and upgrade the mappath using @aldostools code, it uses less memory ( i had problems using the current map path method)
Click to expand...
In reference to the icon/xml swap, I tried playing with that a bit more, but had mixed success. I think we should add that to a future release, after 3.1.0 is released, because the BINS have already been mostly tested, and we just have to iron out the RCO issues associated with replaced ones from previous versions. I also want to test each FW version again (4.84 - 4.89), and at this stage, it would only further delay the current 4.89 supported release.

If you want to help test that feature, you can contact me through PM and we can get it ready for an incremental release later.
 
esc0rtd3w said:
In reference to the icon/xml swap, I tried playing with that a bit more, but had mixed success. I think we should add that to a future release, after 3.1.0 is released, because the BINS have already been mostly tested, and we just have to iron out the RCO issues associated with replaced ones from previous versions. I also want to test each FW version again (4.84 - 4.89), and at this stage, it would only further delay the current 4.89 supported release.

If you want to help test that feature, you can contact me through PM and we can get it ready for an incremental release later.
Click to expand...

I downloaded the new hen and realized that you put the hen_disabled and hen_enable in the vsh/resource/explore/icon folder, you can keep the hen_disabled in that folder but the hen_enable.png you must put it in the vsh/resource/AAA folder. (the only flash folder that worked for me)

It works 100%, i've been using this for months
OTQBTLG.png


79RyXeU.png



Once @bguerville explained why maping flash to flash files doesn't work, i can't remember now, its something related to cobra open_path that needs to be improved, but the AAA folder does the trick
 
Last edited:
LuanTeles said:
I downloaded the new hen and realized that you put the hen_disabled and hen_enable in the vsh/resource/explore/icon folder, you can keep the hen_disabled in that folder but the hen_enable.png you can must put it in the vsh/resource/AAA folder. (the only flash folder that worked for me)
Click to expand...
Those files have actually been there for a while. The hen_disabled.png was just never used in releases. We only use the hen_enable.png, which is also the file it looks for when determining if HEN is installed. That part may be changed later, with the other obvious candidate being /dev_flash/hen/PS3HEN.BIN being the file it looks for instead.

Interesting about the AAA folder. I never knew what it was even for, or paid attention.

LuanTeles said:
Once @bguerville explained why it doesn't work, i can't remember now, its something related to cobra open_path that needs to be improved, but the AAA folder does the trick
Click to expand...
hmmm, i will have to pick his brain later on this matter lol :)
 
You must log in or register to reply here.

Similar threads

Back
Top