Editing Talk:Rcomage
Jump to navigation
Jump to search
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) | ||
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 | <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 | ||
*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 | |||
**the size of this same table (indicated at offset 0x54) in original has a size of 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" ? | |||
*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) | *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) | **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 | **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 | **Another example, with 5 languages... the table is created for 8 languages (rounded to the next multiple of 4) so pointers are added to the table in groups of eight | ||
Line 54: | Line 52: | ||
*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 | *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) | **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 0x55 (used by PSP firmware 0.6.5)== | ==RCO format version 0x55 (used by PSP firmware 0.6.5)== |