Editing Talk:XMB Layouts

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 23: Line 23:
The way how works the XMB layout references inside rco files has been documented before, but the way how works inside the sprx files has been just an unproven theory since many time ago. This experiment is a sample of how it works, it throws an small ray of light at how the sprx files applyes "patches" over the [[RCOXML Objects]]<br>
The way how works the XMB layout references inside rco files has been documented before, but the way how works inside the sprx files has been just an unproven theory since many time ago. This experiment is a sample of how it works, it throws an small ray of light at how the sprx files applyes "patches" over the [[RCOXML Objects]]<br>


The theory behind this experiment is based on the hipotesys that in between 4.88 and 4.99 there was maaaaany sprx files where the only thing that was updated in them is just a couple of bytes "here and there" that are the references to a line number of the XMB layout files, and the hipotesys that there are many times where the rco is storing the values inside the XMB layouts consecutivelly (so it could happen that the rco and the sprx could store all his values consecutivelly). So for this experiment it was needed to find a guinea pig where both, the sprx and the rco was updated in 4.89, also his function should be something trivial just to be sure sony was not trying to update anything important, and the last consideration was to find the files with the smallest size posible just to simplify the research with hexeditors/IDA... and the winner combos are... eula_hcopy_plugin.sprx (27 KB) / eula_hcopy_plugin.rco (60 KB)... and...  eula_cddb_plugin.sprx (29 KB) / eula_cddb_plugin.rco (125 KB)
The theory behind this experiment is based on the hipotesys that in between 4.88 and 4.99 there was maaaaany sprx files where the only thing that was updated in them is just a couple of bytes "here and there" that are the references to a line number of the XMB layout files, and the hipotesys that there are many times where the rco is storing the values inside the XMB layouts consecutivelly (so it could happen that the rco and the sprx could store all his values consecutivelly). So for this experiment it was needed to find a guinea pig where both, the sprx and the rco was updated in 4.89, also his function should be something trivial just to be sure sony was not trying to update anything important, and the last consideration was to find the files with the smallest size posible just to simplify the research with hexeditors/IDA... and the winner combo is... eula_hcopy_plugin.sprx (27 KB) / eula_hcopy_plugin.rco (60 KB)


The samples below are stripped versions from the main XML file generated by rcomage, where has been left only: the [[RCOXML Objects|RCOXML Object name]] (e.g: <IList>), the unique name (e.g: list_eula_start), and the attribute that difers in between 4.88 and 4.89 (the "overrides", responsibles of loading a value from a line of the XMB layout .txt files)
The samples below are stripped versions from the main XML file generated by rcomage, where has been left only: the [[RCOXML Objects|RCOXML Object name]] (e.g: <IList>), the unique name (e.g: list_eula_start), and the attribute that difers in between 4.88 and 4.89 (the "overrides", responsibles of loading a value from a line of the XMB layout .txt files)
The references to the XMB layouts in the xml file generated by rcomage are in little endian, to convert them to "human readable" needs to be splitted in 2 chunks of 2 bytes each, first chunk is the "grid" and second chunk is the "factor". In this sample it can be seen how all the references to the "grid" was increased in +7 units
In the "human readable" conversion for rco values im adding a +1 because in code the first line of a .txt file is line 0, but in a text editor the first line is 1... so im guessing is also neeed to do this +1 addition in the values from the sprx<br>
XMB layout references in eula_hcopy_plugin.sprx 4.88
offset:0x1C7E = 0x0D3C <--- line number 3389 ?
offset:0x2EFA = 0x0D3C <--- line number 3389 ?
XMB layout references in eula_hcopy_plugin.rco 4.88
0x3f0d0100 <--- line number 3392
0x400d0100 <--- line number 3393
0x410d0100 <--- line number 3394
0x420d0100 <--- line number 3395
0xf7100100 <--- line number 4344
0xf9100100 <--- line number 4346


{{Boxcode|title=eula_hcopy_plugin.rco (4.88)|code=<syntaxhighlight lang="xml">
{{Boxcode|title=eula_hcopy_plugin.rco (4.88)|code=<syntaxhighlight lang="xml">
Line 50: Line 34:
<Button name="button_sync_trophy_no"  positionOverrideX="0xf9100100" positionOverrideY="0x420d0100">
<Button name="button_sync_trophy_no"  positionOverrideX="0xf9100100" positionOverrideY="0x420d0100">
</syntaxhighlight>}}
</syntaxhighlight>}}
XMB layout references in eula_hcopy_plugin.sprx 4.89
offset:0x1C7E = 0x0D43 <--- line number 3396 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
offset:0x2EFA = 0x0D43 <--- line number 3396 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
XMB layout references in eula_hcopy_plugin.rco 4.89
0x460d0100 <--- line number 3399 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
0x470d0100 <--- line number 3400 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
0x480d0100 <--- line number 3401 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
0x490d0100 <--- line number 3402 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
0xfe100100 <--- line number 4351 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
0x110100 <----- line number 4353 (increased in +7 units, as a consequence of the displacement in the XMB layout files)


{{Boxcode|title=eula_hcopy_plugin.rco (4.89)|code=<syntaxhighlight lang="xml">
{{Boxcode|title=eula_hcopy_plugin.rco (4.89)|code=<syntaxhighlight lang="xml">
Line 71: Line 43:
</syntaxhighlight>}}
</syntaxhighlight>}}


XMB layout references in eula_cddb_plugin.sprx 4.88
In total there are 11 attributes updated in between 4.88 and 4.89 in eula_hcopy_plugin.rco but some of them contains the same hex value (for optimization purposes, are references to the same line in the XMB layout files)
offset:0x3E5A = 0x0D3E <--- line number 3391 ?
If we count only the unique values (to get an idea at how much lines this rco is using from the XMB layout files) we have a total of 6 references to the XMB layouts
offset:0x421A = 0x0D3C <--- line number 3389 ?
offset:0x5F66 = 0x0D27 <--- line number 3368 ?
offset:0x5FB6 = 0x0D27 <--- line number 3368 ?
offset:0x6206 = 0x0D26 <--- line number 3367 ?
offset:0x624E = 0x0D26 <--- line number 3367 ?
offset:0x630A = 0x0D26 <--- line number 3367 ?
offset:0x634E = 0x0D26 <--- line number 3367 ?
offset:0x9B92 = 0x0D26 <--- line number 3367 ?
offset:0x9C0A = 0x0D26 <--- line number 3367 ?
offset:0x9C82 = 0x0D26 <--- line number 3367 ?
offset:0xADF2 = 0x0D3C <--- line number 3389 ?


  XMB layout references in eula_cddb_plugin.rco 4.88
  XMB layout references in 4.88
0x280d0100 <--- line number 3369
0x290d0100 <--- line number 3370
0x2a0d0100 <--- line number 3371
0x2b0d0100 <--- line number 3372
0x2c0d0100 <--- line number 3373
0x350d0100 <--- line number 3382
0x360d0100 <--- line number 3383
  0x3f0d0100 <--- line number 3392
  0x3f0d0100 <--- line number 3392
  0x400d0100 <--- line number 3393
  0x400d0100 <--- line number 3393
  0x410d0100 <--- line number 3394
  0x410d0100 <--- line number 3394
  0x420d0100 <--- line number 3395
  0x420d0100 <--- line number 3395
0xf7100100 <--- line number 4344
0xf9100100 <--- line number 4346


{{Boxcode|title=eula_cddb_plugin.rco (4.88)|code=<syntaxhighlight lang="xml">
  XMB layout references in 4.89
<Plane name="plane_eula_licensing_wizard_arrow_back"        positionOverrideX="0x280d0100"                                sizeOverrideX="0x2b0d0100" sizeOverrideY="0x2c0d0100">
<Plane name="plane_eula_licensing_wizard_arrow_shadow_back"                                positionOverrideY="0x2a0d0100" sizeOverrideX="0x2b0d0100" sizeOverrideY="0x2c0d0100">
<Plane name="plane_eula_licensing_wizard_arrow_next"        positionOverrideX="0x290d0100"                                sizeOverrideX="0x2b0d0100" sizeOverrideY="0x2c0d0100">
<Plane name="plane_eula_licensing_wizard_arrow_shadow_next"                                positionOverrideY="0x2a0d0100" sizeOverrideX="0x2b0d0100" sizeOverrideY="0x2c0d0100">
<IList name="licensing_inspection_list"                                                    positionOverrideY="0x3f0d0100" sizeOverrideX="0x400d0100" sizeOverrideY="0x410d0100">
<Text name="licensing_option_choice_title"                                                                                sizeOverrideX="0x350d0100" sizeOverrideY="0x360d0100">
<IList name="list_long_mongon_view"                                                        positionOverrideY="0x3f0d0100" sizeOverrideX="0x400d0100" sizeOverrideY="0x410d0100">
<Button name="button_long_mongon_view"                                                    positionOverrideY="0x420d0100">
</syntaxhighlight>}}
 
XMB layout references in eula_cddb_plugin.sprx 4.89
offset:0x3E5A = 0x0D45 <--- line number 3398 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
offset:0x421A = 0x0D43 <--- line number 3396 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
offset:0x5F66 = 0x0D2E <--- line number 3375 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
offset:0x5FB6 = 0x0D2E <--- line number 3375 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
offset:0x6206 = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
offset:0x624E = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
offset:0x630A = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
offset:0x634E = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
offset:0x9B92 = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
offset:0x9C0A = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
offset:0x9C82 = 0x0D2D <--- line number 3374 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
offset:0xADF2 = 0x0D43 <--- line number 3396 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
 
  XMB layout references in eula_cddb_plugin.rco 4.89
0x2f0d0100 <--- line number 3376 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
0x300d0100 <--- line number 3377 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
0x310d0100 <--- line number 3378 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
0x320d0100 <--- line number 3379 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
0x330d0100 <--- line number 3380 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
0x3c0d0100 <--- line number 3389 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
0x3d0d0100 <--- line number 3390 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
  0x460d0100 <--- line number 3399 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
  0x460d0100 <--- line number 3399 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
  0x470d0100 <--- line number 3400 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
  0x470d0100 <--- line number 3400 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
  0x480d0100 <--- line number 3401 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
  0x480d0100 <--- line number 3401 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
  0x490d0100 <--- line number 3402 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
  0x490d0100 <--- line number 3402 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
0xfe100100 <--- line number 4351 (increased in +7 units, as a consequence of the displacement in the XMB layout files)
0x110100 <----- line number 4353 (increased in +7 units, as a consequence of the displacement in the XMB layout files)


{{Boxcode|title=eula_cddb_plugin.rco (4.89)|code=<syntaxhighlight lang="xml">
The references to the XMB layouts in the xml file generated by rcomage are in little endian, to convert them to "human readable" needs to be splitted in 2 chunks of 2 bytes each, first chunk is the "grid" and second chunk is the "factor". In this sample it can be seen how all the references to the "grid" was increased in +7 units<br>
<Plane name="plane_eula_licensing_wizard_arrow_back"       positionOverrideX="0x2f0d0100"                               sizeOverrideX="0x320d0100" sizeOverrideY="0x330d0100">
In firmware 4.89 this rco is storing 4 values consecutivelly at lines 3399, 3400, 3401, 3402. And additionally is storing another 2 values at lines 4351 and 4353 (not consecutivelly, there is a gap in between them used by something else)
<Plane name="plane_eula_licensing_wizard_arrow_shadow_back"                                positionOverrideY="0x310d0100" sizeOverrideX="0x320d0100" sizeOverrideY="0x330d0100">
<Plane name="plane_eula_licensing_wizard_arrow_next"        positionOverrideX="0x300d0100"                                sizeOverrideX="0x320d0100" sizeOverrideY="0x330d0100">
<Plane name="plane_eula_licensing_wizard_arrow_shadow_next"                                positionOverrideY="0x310d0100" sizeOverrideX="0x320d0100" sizeOverrideY="0x330d0100">
<IList name="licensing_inspection_list"                                                    positionOverrideY="0x460d0100" sizeOverrideX="0x470d0100" sizeOverrideY="0x480d0100">
<Text name="licensing_option_choice_title"                                                                                sizeOverrideX="0x3c0d0100" sizeOverrideY="0x3d0d0100">
<IList name="list_long_mongon_view"                                                        positionOverrideY="0x460d0100" sizeOverrideX="0x470d0100" sizeOverrideY="0x480d0100">
<Button name="button_long_mongon_view"                                                    positionOverrideY="0x490d0100">
</syntaxhighlight>}}


----
----
When comparing the (decrypted) 4.88 and 4.89 versions of eula_hcopy_plugin.sprx there are only 2 bytes that differs (that belongs to 2 values of 2 bytes length each)
XMB layout references in 4.88
offset:0x1C7E = 0x0D3C <--- line number 3389 ?
offset:0x2EFA = 0x0D3C <--- line number 3389 ?


From this behaviour in the order of how the values are stored in the XMB layouts we can deduce that "the sprx stores first" (and the slave rco stores last) but maybe this is just a coincidence and not an strict rule<br>
XMB layout references in 4.89
All the unique 4.89 XMB "grid" layout references above, combined in a single list
offset:0x1C7E = 0x0D43 <--- line number 3396 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
  Line 3374 // Loaded by eula_cddb_plugin.sprx
  offset:0x2EFA = 0x0D43 <--- line number 3396 ? (increased in +7 units, as a consequence of the displacement in the XMB layout files)
Line 3375 // Loaded by eula_cddb_plugin.sprx
Line 3376 // Loaded by eula_cddb_plugin.rco
Line 3377 // Loaded by eula_cddb_plugin.rco
Line 3378 // Loaded by eula_cddb_plugin.rco
Line 3379 // Loaded by eula_cddb_plugin.rco
Line 3380 // Loaded by eula_cddb_plugin.rco
Line 3389 // Loaded by eula_cddb_plugin.rco
Line 3390 // Loaded by eula_cddb_plugin.rco
Line 3396 // Loaded by eula_cddb_plugin.sprx and eula_hcopy_plugin.sprx
Line 3398 // Loaded by eula_cddb_plugin.sprx
Line 3399 // Loaded by eula_cddb_plugin.rco and eula_hcopy_plugin.rco
Line 3400 // Loaded by eula_cddb_plugin.rco and eula_hcopy_plugin.rco
Line 3401 // Loaded by eula_cddb_plugin.rco and eula_hcopy_plugin.rco
Line 3402 // Loaded by eula_cddb_plugin.rco and eula_hcopy_plugin.rco
Line 4351 // Loaded by eula_hcopy_plugin.rco
Line 4353 // Loaded by eula_hcopy_plugin.rco
*eula_net_plugin.rco doesnt contains any reference to the XMB layouts, and eula_net_plugin.sprx contains 10 values located over line 4255 of the XMB grid layout files


=VSH exports=
In the "human readable" conversion for rco values im adding a +1 because in code the first line of a .txt file is line 0, but in a text editor the first line is 1... so im guessing is also neeed to do this +1 addition in the values from the sprx<br>
*This exports seems to be used to get the position and sizes located in the "XMB layouts" .txt files
The 2 bytes updated in this sprx for 4.89 are the references to the XMB layouts, and both are a references to the same line number of the XMB layouts, so this sprx only stores a single value in the XMB layouts (located 3 lines before the values stored by the associated rco)<br>
**paf::PhWidget::GetLayoutPos(int &, int &, int &, vec4 &)const
From this behaviour in the order of how the values are stored in the XMB layouts we can deduce that "the sprx stores first" (and the slave rco stores last) but maybe this is just a coincidence and not an strict rule
**paf::PhWidget::GetLayoutPosValue(void)
**paf::PhWidget::GetLayoutSize(int &, int &, int &, vec4 &)const
**paf::PhWidget::GetLayoutSizeValue(void)
*This ones to set them
**paf::PhWidget::SetLayoutPos(int, int, int, vec4)
**paf::PhWidget::SetLayoutSize(int, int, int, vec4)
*And this ones to redraw them
**paf::PhWidget::UpdateLayoutPos(void)
**paf::PhWidget::UpdateLayoutSize(void)
 
=Video Output Settings=
https://manuals.playstation.net/document/en/ps3/current/settings/videooutput.html
 
The screen at step 7 of the "PlayStation 3 User's Guide" shows all this posible strings (copyed from inside sysconf_plugin.rco)
<source lang="xml">
<Text name="msg_480p">480p</Text>
<Text name="msg_576p">576p</Text>
<Text name="msg_720p">720p</Text>
<Text name="msg_1080i">1080i</Text>
<Text name="msg_1080p">1080p</Text>
<Text name="msg_720p_3d">720p (3D)</Text>
<Text name="msg_1080i_3d">1080i (3D)</Text>
<Text name="msg_1080p_3d">1080p (3D)</Text>
<Text name="msg_720p_dual_view">720p (SimulView™)</Text>
<Text name="msg_sd_ntsc">Standard (NTSC)</Text>
<Text name="msg_sd_pal">Standard (PAL)</Text>
<Text name="msg_select_all_resolution">Select all resolutions that are supported by your TV.</Text>
</source>
The description "Standard (NTSC)" and "Standard (PAL)" coud be confusing for someone (me included), but this paragraph from the user's guide indicates '''Standard (NTSC) is 480i''', and '''Standard (PAL) is 576i'''
The video resolution is selected in order of priority as follows: 1080p > 1080i > 720p > 480p/576p > Standard (NTSC:480i/PAL:576i).
So for clarification purposes this strings from inside sysconf_plugin.rco could be customized as:
<source lang="xml">
<Text name="msg_sd_ntsc">480i (Standard NTSC)</Text>
<Text name="msg_sd_pal">576i (Standard PAL)</Text>
</source>
 
==Coldboot script logic==
Inside the coldboot.raf there is a [[Coldboot.raf#Script | script]] that detects the current display resolution, and based on it applyes some transformations (scale and position) to the coldboot logos. In it can be seen how the PS3 XMB groups the ED and SD resolutions together<br>
The other video modes with a width different than 720 pixels doesnt falls into this "if-else" statements
 
*The screen resolution detection logic starts with the statement <code>if (System.resolution->0 == 720)</code>. It seems this includes all this video modes:
**576p and 576i (4:3 aspect ratio) '''720'''x576 (PAL anamorphic)
**480p and 480i (3:2 aspect ratio) '''720'''×480 (NTSC anamorphic)
*After that, the next logic stament is <code>if (camera.aspect == 4.0 / 3.0)</code>, this includes only:
**576p and 576i ('''4:3''' aspect ratio) '''720'''x576 (PAL anamorphic)
*Else is:
**480p and 480i ('''3:2''' aspect ratio) '''720'''×480 (NTSC anamorphic)
Please note that all contributions to PS3 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS3 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)

Template used on this page: