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) | ||
Line 44: | Line 44: | ||
**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 | **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 | ***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 | ||
Line 54: | Line 53: | ||
*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)== |