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 1: Line 1:
=rcomage innacuracies, mistakes, bugs, or unsupported rco specifications=
==Rebuild verification==
There is an easy way to verify if the building methods used by rcomage are exactlly like the ones used officially by sony, it basically consists in rebuilding an official rco, the hashes of the original and rebuilt .rco should match exactlly... in other words, after the rebuild the .rco file should be exactlly like the original
*Requirements for this to work
**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)
***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)]]
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
==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)
*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)==
PSP firmware 0.6.5 uses a primitive version of the rco format, this is an example of the rco header (first 0x94 bytes) of '''system_plugin.rco''', most notable change is the header is smaller (so is missing some areas for features that was not implemented yet). I dont plan to look for all the changes but this little example hopefully will show what areas are missing to have an overall idea of the order of how features was implemented in the rco format. This version of the rco format is not compatible with rcomage... <strike>but it should by deleting the "unknowns" in the definitions of the source code (lines 51 and 76 of rcofile.h) then compile it (not tested, other errors can happen but this should work)</strike> the idea doesnt works, compiler returns other errors http://paste.ubuntu.com/23207840/
Original header (remember PSP uses little endian so some bytes are swapped)
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000  00 50 52 46 55 00 00 00 00 00 00 00 00 00 00 00  .PRFU...........
00000010  94 00 00 00 FF FF FF FF 7C 0A 00 00 34 08 00 00  ”...ÿÿÿÿ|...4...
00000020  FF FF FF FF BC 00 00 00 FF FF FF FF 7C 0B 00 00  ÿÿÿÿ¼...ÿÿÿÿ|...
00000030  FF FF FF FF E0 0C 00 00 68 00 00 00 48 0D 00 00  ÿÿÿÿà...h...H...
00000040  9C 04 00 00 E4 11 00 00 04 00 00 00 F0 0B 00 00  œ...ä.......ð...
00000050  28 00 00 00 18 0C 00 00 94 00 00 00 FF FF FF FF  (.......”...ÿÿÿÿ
00000060  00 00 00 00 AC 0C 00 00 2C 00 00 00 D8 0C 00 00  ....¬...,...Ø...
00000070  08 00 00 00 FF FF FF FF 00 00 00 00 E8 11 00 00  ....ÿÿÿÿ....è...
00000080  40 DF 01 00 28 F1 01 00 F0 58 02 00 FF FF FF FF  @ß..(ñ..ðX..ÿÿÿÿ
00000090  00 00 00 00                                      ....
{| class="wikitable" style="font-size:x-small;"
|-
! Areas !! Offset !! Length !! Example !! Name !! Notes
|-
| rowspan="43" | Header
|-{{cellcolors|#666666|#ffffff}}
| 0x00 || 0x04 || PRF || '''magic''' || PRF in little endian
|-{{cellcolors|#666666|#ffffff}}
| 0x04 || 0x04 || 55 00 00 00 || '''version''' || 0x55 = one of the firmwares for PSP
|-{{cellcolors|#666666|#ffffff}}
| 0x08 || 0x04 || 00 00 00 00 || ''unknown'' ||
|-{{cellcolors|#666666|#ffffff}}
| 0x0C || 0x04 || 00 00 00 00 || '''compress_header''' || 0x00 = uncompressed
|-{{cellcolors|lightgrey}}
| colspan="5" |
|-
| 0x10 || 0x04 || 94 00 00 00 || '''toc_maintree_absolute_offset''' || MainTree at absolute offset 0x94
|-
| 0x14 || 0x04 || FF FF FF FF || '''toc_scripttree_absolute_offset''' ||
|-
| 0x18 || 0x04 || 7C 0A 00 00 || '''toc_languagetree_absolute_offset''' || TextTree at absolute offset 0xA7C
|-
| 0x1C || 0x04 || 34 08 00 00 || '''toc_soundtree_absolute_offset''' || SoundTree at absolute offset 0x834
|-
| 0x20 || 0x04 || FF FF FF FF || '''toc_modeltree_absolute_offset''' ||
|-
| 0x24 || 0x04 || BC 00 00 00 || '''toc_imagetree_absolute_offset''' || ImageTree at absolute offset 0xBC
|-
| 0x28 || 0x04 || FF FF FF FF || {{cellcolors|#ff7777}} ''toc_unknowntree_absolute_offset'' or '''toc_fonttree_absolute_offset'''||
|-
| 0x2C || 0x04 || 7C 0B 00 00 || '''toc_objecttree_absolute_offset''' || ObjectTree at absolute offset 0xB7C
|-
| 0x30 || 0x04 || FF FF FF FF || '''toc_animationtree_absolute_offset''' ||
|-{{cellcolors|lightgrey}}
| colspan="5" |
|-
| 0x34 || 0x04 || E0 0C 00 00 || '''strings_texts_absolute_offset''' || strings texts table at absolute offset 0xCE0
|-
| 0x38 || 0x04 || 68 00 00 00 || '''strings_texts_length''' || strings texts table size 0x68
|-
| 0x3C || 0x04 || 48 0D 00 00 || '''strings_labels_absolute_offset''' || strings labels table at absolute offset 0xD48
|-
| 0x40 || 0x04 || 9C 04 00 00 || '''strings_labels_length''' || strings labels size 0x49C
|-
| 0x44 || 0x04 || E4 11 00 00 || '''strings_events_absolute_offset''' || strings events table at absolute offset 0x11E4
|-
| 0x48 || 0x04 || 04 00 00 00 || '''strings_events_length''' || strings events size 0x4
|-{{cellcolors|lightgrey}}
| colspan="5" |
|-
| 0x4C || 0x04 || F0 0B 00 00 || '''text_pointer_table_offset''' ||
|-
| 0x50 || 0x04 || 28 00 00 00 || '''text_pointer_table_length''' ||
|-
| 0x54 || 0x04 || 18 0C 00 00 || '''image_pointer_table_offset''' ||
|-
| 0x58 || 0x04 || 94 00 00 00 || '''image_pointer_table_length''' ||
|-
| 0x5C || 0x04 || FF FF FF FF || '''model_pointer_table_offset''' ||
|-
| 0x60 || 0x04 || 00 00 00 00 || '''model_pointer_table_length''' ||
|-
| 0x64 || 0x04 || AC 0C 00 00 || '''sound_pointer_table_offset''' ||
|-
| 0x68 || 0x04 || 2C 00 00 00 || '''sound_pointer_table_length''' ||
|-
| 0x6C || 0x04 || D8 0C 00 00 || '''object_pointer_table_offset''' ||
|-
| 0x70 || 0x04 || 08 00 00 00 || '''object_pointer_table_length''' ||
|-
| 0x74 || 0x04 || FF FF FF FF || '''anim_pointer_table_offset''' ||
|-
| 0x78 || 0x04 || 00 00 00 00 || '''anim_pointer_table_length''' ||
|-{{cellcolors|lightgrey}}
| colspan="5" |
|-
| 0x7C || 0x04 || E8 11 00 00 || '''image_data_section_offset''' ||
|-
| 0x80 || 0x04 || 40 DF 01 00 || '''image_data_section_length''' ||
|-
| 0x84 || 0x04 || 28 F1 01 00 || '''sound_data_section_offset''' ||
|-
| 0x88 || 0x04 || F0 58 02 00 || '''sound_data_section_length''' ||
|-
| 0x8C || 0x04 || FF FF FF FF || '''model_data_section_offset''' ||
|-
| 0x90 || 0x04 || 00 00 00 00 || '''model_data_section_length''' ||
|-{{cellcolors|#ff7777}}
| colspan="5" | 12 bytes of unknowns 0xFF's was added here for newer versions of the rco format
|}


=Missing descriptors in rcomage current version (1.1.1)=
=Missing descriptors in rcomage current version (1.1.1)=
Line 434: Line 264:
**unknownRef37="event:native:/OnPushIlistBtDeviceManager"
**unknownRef37="event:native:/OnPushIlistBtDeviceManager"
**<IItem name="iitem_address_setting" unknown1="0x0" textDefault="text:msg_ipaddress_setting" textError="text:msg_auto"></IItem>
**<IItem name="iitem_address_setting" unknown1="0x0" textDefault="text:msg_ipaddress_setting" textError="text:msg_auto"></IItem>
=Other descriptors, not in setting files (seem to be hardcoded)=
==UMDFlag==
This attribute was named UMDFlag unofficially because it was found used in the .rco files contained inside PSP UMD discs only
The name seems not accurate enought (because PS3 cant read UMD discs) so maybe is something more generic like "disc media", though never has been found a PS3 disc containing .rco's and the '''HYBRID_FLAG''' used in the bluray contents descriptor file [[PS3_DISC.SFB]] for "music bluray" and "photo bluray" are completlly speculative
*Speculation. Maybe is::
**0 = system rco
**1 = external rco (disc media, etc)
==minFirmwareVer==
This is a very important unknown. See: [[Talk:Resource_Container_%28RCO%29]]
==unknownByte==
In the xml representation of the .rco structure... every image inside the imagetree uses an unknown attribute named '''unknownByte'''. Is an attribute related with the image format and is equal to 0 in most of the PS3 images (very rarelly used)
*After searching in ALL the images contained inside ALL .rco files from firmware 4.76... there is a total of 72 images using '''unknownByte="1"''' (and 3098 images using '''unknownByte="0"''' for a total of 3170 images inside .rco's)
**7 images inside [[eula_net_plugin]].rco
**34 images inside [[newstore_plugin]].rco
**29 images inside [[regcam_plugin]].rco
**2 images inside [[system_plugin]].rco
from [[system_plugin]].rco
{{Boxcode|content=<syntaxhighlight lang="xml">
<Image name="tex_optionmenu_bg" src=".\RCO 476 ofw\system_plugin\Images\tex_optionmenu_bg.gim" format="gim" compression="zlib" unknownByte="1" />
<Image name="tex_optionmenu_base" src=".\RCO 476 ofw\system_plugin\Images\tex_optionmenu_base.gim" format="gim" compression="zlib" unknownByte="1" />
</syntaxhighlight>}}
*The 2 .gim files found using '''unknownByte="1"''' has some things in common:
**The size of both .gim file is exactlly 452KB (463.232 bytes)
**The resolution of both images in pixels is 512x206
**The first 0x80 bytes of the header in both is exactlly the same (see example below)
unknownByte .gim header example
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000  2E 47 49 4D 31 2E 30 30 00 50 53 50 00 00 00 00  .GIM1.00.PSP....
00000010  00 02 00 00 00 07 11 70 00 00 00 10 00 00 00 10  .......p........
00000020  00 03 00 00 00 07 11 60 00 00 00 10 00 00 00 10  .......`........
00000030  00 04 00 00 00 07 11 50 00 07 11 50 00 00 00 10  .......P...P....
00000040  00 30 00 00 00 03 00 00 02 18 00 D8 00 20 00 10  .0.........Ø. ..
00000050  00 01 00 02 00 00 00 00 00 00 00 30 00 00 00 40  ...........0...@
00000060  00 07 11 40 00 00 00 00 00 01 00 01 00 03 00 01  ...@............
00000070  00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
Is not specific for .GIM image format because other image formats uses it too, here are a couple of examples from newstore_plugin.rco where is used with .JPG and .PNG
{{Boxcode|content=<syntaxhighlight lang="xml">
<Image name="BackGround" src=".\RCO 476 ofw\newstore_plugin\Images\BackGround.jpg" format="jpg" compression="uncompressed" unknownByte="1" />
<Image name="ScrollButtonRich" src=".\RCO 476 ofw mod 5\newstore_plugin\Images\ScrollButtonRich.png" format="png" compression="uncompressed" unknownByte="1" />
</syntaxhighlight>}}
Is specific for PS3 (not used on PSP) as can be seen in the comments of the source code of rcomage [https://github.com/zingaburga/RCOMage/blob/master/src/rcofile.h here] in line number 188
PS3 RCOs seem to have this extra element - probably something to do with planes/frames??
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"