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 7: Line 7:
**the files needs to be extracted in "raw" format (if using "rcomage gui" in the DUMP tab uncheck all the checkboxes for GIM, VAG, VSMX)... long story short this is to avoid mistakes with the conversors
**the files needs to be extracted in "raw" format (if using "rcomage gui" in the DUMP tab uncheck all the checkboxes for GIM, VAG, VSMX)... long story short this is to avoid mistakes with the conversors
**the rco TOC (aka what rcomage names "header compression") needs to use the same compression method than the original (if using "rcomage gui" in the COMPILE tab choose the correct "header compression" from NONE, ZLIB, RLZ)
**the rco TOC (aka what rcomage names "header compression") needs to use the same compression method than the original (if using "rcomage gui" in the COMPILE tab choose the correct "header compression" from NONE, ZLIB, RLZ)
***rcomage doesnt keeps a record of this "header compression", so the way to identify it is by opening the original .rco in a hexeditor and check the value stored at absolute offset 0xC. See [[Resource Container (RCO)]]
***rcomage doesnt keeps a record of this compression on the rcoxml used to rebuild the .rco, so the way to identify it is by opening the original .rco in a hexeditor and check the value stored at absolute offset 0xC. See [[Resource Container (RCO)]]


This method is specially usefull with the .rco files that doesnt have "header compression" because is easyer to find the differences in a hexeditor, oldest PS3 firmware .rco's (like the ones in firmware 1.02) are not compressed
This method is specially usefull with the .rco files that doesnt have the TOC compressed because is easyer to find the differences in a hexeditor, oldest PS3 firmware .rco's (like the ones in firmware 1.02) are not compressed


==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)
-----------------------------------------------
<sandungas> just found an "innacuracy" of rcomage when rebuilding files
<sandungas> im not calling it a mistake because it doesnt breaks the format
<sandungas> is an (seems stupid) padding sony adds in the original files.... but rcomage doesnt
<sandungas> the point is maybe is not so stupid and is based on how the contents are mounted in the console ram, aligned to memory blocks and stuff like that
<sandungas> actually, maybe this is dependant of the console (ps3 or psp) because the different ram management, hmmmm
<zecoxao_> you need ZingaBurga
<sandungas> yep :/
<sandungas> and i remember him talking about this
<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> 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> 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
 
*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 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)
**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
***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
 
 
 
 
 
*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


==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"