Editing Talk:Rcomage

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 13: Line 13:
==official dummy language string pointers not managed by rcomage==
==official dummy language string pointers not managed by rcomage==
Found in '''xmb_plugin_normal.rco''' firmware 1.02 (and probably most others using language text strings, is just in this one is more obvious where the problem happens)
Found in '''xmb_plugin_normal.rco''' firmware 1.02 (and probably most others using language text strings, is just in this one is more obvious where the problem happens)
*xmb_plugin_normal.rco firmware 1.02 original and rebuild at absolute offset 0x50, is indicating the language pointers table starts at absolute offset '''0x7EC''' (position is the same in both, original and rebuild)
**but the size (indicated at offset 0x54) in original is 0x90... and in rebuild 0x78 (after rebuild is smaller, rcomage has "lost" some bytes from it)
The table contains the pointers for every text string for every language, PS3 firmware 1.02 supports up to 10 languages, and every language contains 3 text strings... this makes a total of 30 pointers, every pointer is 4 bytes size, so the whole table of language text pointers should be 120 bytes length (0x78 in hex)... this is what rcomage does
But sony added 6 more pointers to the end of the table (of 4 bytes length each) all filled with zeroes... can be considered padding, but also can be considered "dummy pointers" because belongs to the table of pointers
Now... the question (and the reason why rcomage doesnt adds this pading) is.... '''why sony added that "dummy pointers" ?'''


  illuminati event one, theory one (in the track)
  illuminati event one, theory one (in the track)
Line 35: Line 26:
  <sandungas> someone asked him why the rebuilding was not perfect... and he mentioned some "weird" padding sony did but he could not understand why it happens
  <sandungas> someone asked him why the rebuilding was not perfect... and he mentioned some "weird" padding sony did but he could not understand why it happens
  <sandungas> i think i know why :)
  <sandungas> i think i know why :)
  <sandungas> is a dirty trick, not efficient because adds additionally unneeded padding, but assures you the text pointers are aligned properlly without need to make complex calculations
  <sandungas> is a dirty trick, not efficient because adds padding, but assures you the text pointers are aligned properlly
  <sandungas> something like this...
  <sandungas> something like this...
  <sandungas> if total numer of languages inside .rco is not multiple of 4..... add "dummy" languages until it reaches a multiple of 4
  <sandungas> if total numer of languages inside .rco is not multiple of 4..... add "dummy" languages until it reaches a multiple of 4


*It needs to be verifyed further in other .rco files but my theory is this: --[[User:Sandungas|Sandungas]] ([[User talk:Sandungas|talk]]) 00:56, 21 September 2016 (UTC)
*original and rebuild at offset 0x50, language pointers table starts at absolute offset 0x7EC
**the table of pointers needs to be aligned to 0x10 bytes boundary (from the start of the table itself), but trying to calculate the padding before building the file is a pita (because there can be lot of languages and lot of text strings for every language, is needed to read every text, multiply by language number, then calculate padding, etc... is not efficient)... so they decided to add this "blind alignment prevention". The thing consists in creating the table by cummulating "pointer placeholders" that contains ALWAYS groups of pointers that are a multiple of 4 based in the number of languages stored inside the .rco (this way the number of strings for every language doesnt matters at all, the table will always be aligned to 0x10 bytes)
**this same table in original has a size of 0x90... and in rebuild 0x78
**As example, in the worst scenario posible... if the rco only contains one language, and only one text string for that language... at building time the table of pointers is created with a size of 0x10 bytes (to store 4 pointers for 4 languages minimal)... then the first pointer is filled... and because there are not more pointers to store the other areas are kept filled with zeroes
 
**Another example, with 5 languages... the table is created for 8 languages (rounded to the next multiple of 4) so "pointer placeholders" are added to the table in groups of eight
The original table contains the pointers for every text string sotred for every language, PS3 firmware 1.02 supported 10 languages... and every language contains 3 text strings... this makes a total of 30 pointers, every pointer is 4 bytes size, so the whole table of pointers should be 120 bytes (0x78 in hex)... this is what rcomage does
***In the first step the table has room for 8 pointers and is filed with the 5 pointers for the first text string... now is calculated how many "pointer placeholders" are left in the table = 3... so the table is increased in size with 8 "pointer placeholders" more... now the table has 11 available "pointer placeholders" and are filled with the 5 pointers for the second string stored in positions 6 up to 10... now is calculated how many "pointer placeholders" are left in the table = 1... so the table is increased in size with 8 "pointer placeholders" more... and so on
***Note the number of strings doesnt matters (not needed to know, is not a variable in the function), the process is repeated in a loop and the table will always be aligned to 0x10 bytes boundary


*In PS3 xmb_plugin_normal.rco from firmware 1.02 (with 10 languages) the "pointer placeholders" that are cummulated to make the table bigger (needs to be bigger than 10 and a multiple of 4) are added in groups of 12 pointers (chunks of 0x30 bytes). In the original file the table has a size of 0x90 bytes, this means the table has been increased in size 3 times in the .rco building process
But sony added 6 more pointers to the end of the table (of 4 bytes length each) for a total of 24 bytes filled with zeroes... can be considered padding, but also can be considered "dummy pointers" because belongs to the table of pointers


Now... the question (and the reason why rcomage doesnt adds this pading) is.... why sony added that "dummy pointers" ?
*It needs to be verifyed further in other .rco files but my theory is this: --[[User:Sandungas|Sandungas]] ([[User talk:Sandungas|talk]]) 00:56, 21 September 2016 (UTC)
**the table of pointers needs to be aligned to 0x10 bytes boundary (from the start of the table itself), but trying to calculating the padding before building the file is a pita (because there can be lot of languages and lot of text strings fro every language, is needed to read every text, multiply by language number, then calculate padding, etc... not efficient)... so they decided to add this "blind alignment prevention". The thing consists in creating an area to store the pointers that contains ALWAYS groups of pointers that are a multiple of 4 based in the number of languages stored inside the .rco (this way the number of strings for every language doesnt matters at all, the table will always be aligned to 0x10 bytes)
**As example, in the worst scenario posible... if the rco only contains one language, and only one text string for that language... at building time the table of pointers is created with a size of 0x10 bytes (to store 4 pointers for 4 languages minimal)... then the first pointer is filled... and because there are not more strings to store the other areas are kept filled with zeroes
**Another example, with 5 languages... the table is created for 8 languages (rounded to the next multiple of 4 languages)








*There are other innacuracies when rebuilding this file... not sure if are related with text strings too though... are hard to see where is the problem because the areas are displaced by the problem explained above
**as example... the last event in the "events table" in original is '''native:/Bar::onCursorMove''' (seems to be stored in a different order)


==RCO format version 0x93 (used by PS3 firmware 082.006)==
There is a problem with the "Image" entries (located under "ImageTree") on the TOC. At the time sony "ported" the RCO format from PSP-to-PS3 it was added an additional value for "Image" (usually a 0x1 and his purpose is still unknown). This additional value was added at pre-retail DECR 085 series (rco_version 0x97). More info here: [[RCOXML_Images#Image]]


The firmwares affected are all PS3 pre-retail 082, 083, and 084 series


Fix for rcomage: if endianess = big and rco_version < 0x97 this value doesnt exists
*There are other innacuracies when rebuilding this file... not sure if are related with text strings too though... are hard to see where is the problem because the areas are displaced by the problem explained above


==RCO format version 0x55 (used by PSP firmware 0.6.5)==
==RCO format version 0x55 (used by PSP firmware 0.6.5)==
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:

Retrieved from "http://www.psdevwiki.com/ps3/Talk:Rcomage"