Resource Container (RCO): Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
 
(46 intermediate revisions by one other user not shown)
Line 1: Line 1:
=Description=
=Description=
The file extension in PSP and PS3 is '''RCO''' that seems to be the acronym of '''R'''esource '''C'''ontainer '''O'''bjet
The file extension in PSP and PS3 is '''RCO''' that seems to be the acronym of '''R'''esource '''C'''ontainer '''O'''bject


The file signature (aka [https://en.wikipedia.org/wiki/Magic_number_(programming) magic number]) from PSP (in little endian) is '''PRF''' that seems to be the acronym of '''P'''laystation '''R'''esource '''F'''ile
The file signature (aka [https://en.wikipedia.org/wiki/Magic_number_(programming) magic number]) from PSP (in little endian) is '''PRF''' that seems to be the acronym of '''P'''laystation '''R'''esource '''F'''ile
Line 8: Line 8:
==Contents==
==Contents==
*RCO contents (See [[Multimedia Formats and Tools]]): <!--and see rcomage miscmap.ini for a list of the supported formats-->
*RCO contents (See [[Multimedia Formats and Tools]]): <!--and see rcomage miscmap.ini for a list of the supported formats-->
Text for all [[Template:XMB_languages|languages]], textures, sounds (for cursor navigation, trophy unlocking, etc...) and models
Text for all [[Template:PlayStation Languages|languages]], textures, sounds (for cursor navigation, trophy unlocking, etc...) and models


{| class="wikitable"
{| class="wikitable"
Line 26: Line 26:
! Toc trees !! Toc compression !! Other Notes
! Toc trees !! Toc compression !! Other Notes
|-
|-
| 0x55 || {{icon content psp|50px}} 0.6.5 || pre-retail || 9 || uncompressed || archaic rco format, header is 16 bytes smaller
! 0x55
| {{cellcolors|#cccccc}} {{icon content psp|50px}} 0.6.5 || pre-retail || 9 || none || archaic rco format, header is 16 bytes smaller
|-
|-
| 0x70 || {{icon content psp|50px}} 1.00 || 2004 / 12 / 12 || 10 || uncompressed ||  
! 0x70
| {{cellcolors|#cccccc}} {{icon content psp|50px}} 1.00 || 2004 / 12 / 12 || 10 || none ||  
|-
|-
| 0x71 || {{icon content psp|50px}} 1.50~2.50 || 2005 / 3 / 24 || 10 || uncompressed || normal toc up to this version
! 0x71
| {{cellcolors|#cccccc}} {{icon content psp|50px}} 1.50~2.50 || 2005 / 3 / 24 || 10 || none ||  
|-
|-
| 0x90 || {{icon content psp|50px}} 2.60 || 2005 / 11 / 29 || 10 || || zlib compressed toc implemented
! 0x90
| {{cellcolors|#cccccc}} {{icon content psp|50px}} 2.60 || 2005 / 11 / 29 || 10 || zlib ||  
|-
|-
| 0x95 || {{icon content psp|50px}} 2.70~2.71 || 2006 / 4 / 25 || 10 || || rlz compressed toc implemented
! 0x93
| {{cellcolors|#888888}} {{icon content ps3|50px}} <abbr title="pre-retail PS3 DECR firmware 0.82.006 probably same version for all 0.82 firmware series">0.82</abbr> || 2006 / 3 / 31 || 10 || none ||  
|-
|-
| 0x96 || {{icon content psp|50px}} 2.80~3.40 || 2006 / 7 / 27 || 10 || || the toc seems to be compressed in parts
! 0x94
| {{cellcolors|#888888}} {{icon content ps3|50px}} <abbr title="pre-retail PS3 DECR firmware 0.83.002 probably same version for all 0.83 firmware series">0.83</abbr> || 2006 / 4 / 19 || 10 || none ||  
|-
|-
| 0x97 || {{icon content ps3|50px}} 1.00~1.54 || 2006 / 11 / 11 || 10 || ||  
! rowspan="2" | 0x95
| {{cellcolors|#cccccc}} {{icon content psp|50px}} 2.70~2.71 || 2006 / 4 / 25 || 10 || rlz ||  
|-
|-
| 0x100 || {{icon content psp|50px}} 3.50~6.61 || 2007 / 5 / 31 || 10 || ||  
| {{cellcolors|#888888}} {{icon content ps3|50px}} <abbr title="pre-retail PS3 DECR firmware 0.84.001 probably same version for all 0.84 firmware series">0.84</abbr> || 2006 / 5 / 19 || 10 || none ||  
|-
|-
| 0x102 || {{icon content ps3|50px}} 1.60~1.70 || 2007 / 3 / 22 || 10 || ||  
! 0x96
| {{cellcolors|#cccccc}} {{icon content psp|50px}} 2.80~3.40 || 2006 / 7 / 27 || 10 || rlz ? || the toc seems to be compressed in parts
|-
|-
| 0x104 || {{icon content ps3|50px}} 1.80~1.82 || 2007 / 5 / 24 || 10 || ||  
! 0x97
| {{cellcolors|#888888}} {{icon content ps3|50px}} <abbr title="pre-retail PS3 DECR firmware 0.85.007 probably same version for all 0.85 firmware series">0.85</abbr>~[[1.54_CEX|1.54]] || 2006 / 11 / 11 || 10 || none ||  
|-
|-
| 0x105 || {{icon content ps3|50px}} 1.90~1.94 || 2007 / 7 / 24 || 10 || ||  
! 0x100
| {{cellcolors|#cccccc}} {{icon content psp|50px}} 3.50~6.61 || 2007 / 5 / 31 || 10 || rlz ? ||  
|-
|-
| 0x106 || {{icon content ps3|50px}} 2.00~2.17 || 2007 / 11 / 8 || 10 || ||  
! 0x102
| {{cellcolors|#888888}} {{icon content ps3|50px}} [[1.60_CEX|1.60]]~[[1.70_CEX|1.70]] || 2007 / 3 / 22 || 10 || ? ||  
|-
|-
| 0x107 || {{icon content ps3|50px}} 2.20~2.80 || 2008 / 3 / 25 || 10 || ||  
! 0x104
| {{cellcolors|#888888}} {{icon content ps3|50px}} [[1.80_CEX|1.80]]~[[1.82_CEX|1.82]] || 2007 / 5 / 24 || 10 || ? ||  
|-
|-
| 0x108 || {{icon content ps3|50px}} 3.00~3.01 || 2009 / 9 / 1 || 10 || ||  
! 0x105
| {{cellcolors|#888888}} {{icon content ps3|50px}} [[1.90_CEX|1.90]]~[[1.94_CEX|1.94]] || 2007 / 7 / 24 || 10 || zlib ||  
|-
|-
| 0x110 || {{icon content ps3|50px}} 3.10~3.74 || 2009 / 11 / 19 || 10 ||  ||  
! 0x106
| {{cellcolors|#888888}} {{icon content ps3|50px}} [[2.00_CEX|2.00]]~[[2.17_CEX|2.17]] || 2007 / 11 / 8 || 10 || zlib ||  
|-
|-
| 0x120 || {{icon content ps3|50px}} 4.00~4.25 || 2011 / 11 / 29 || 10 ||  ||  
! 0x107
| {{cellcolors|#888888}} {{icon content ps3|50px}} [[2.20_CEX|2.20]]~[[2.80_CEX|2.80]] || 2008 / 3 / 25 || 10 || zlib ||  
|-
|-
| 0x130 || {{icon content ps3|50px}} 4.30~4.76 || 2012 / 10 / 24 || 10 ||  ||  
! 0x108
| {{cellcolors|#888888}} {{icon content ps3|50px}} [[3.00_CEX|3.00]]~[[3.01_CEX|3.01]] || 2009 / 9 / 1 || 10 || zlib  ||
|-
! 0x110
| {{cellcolors|#888888}} {{icon content ps3|50px}} [[3.10_CEX|3.10]]~[[3.74_CEX|3.74]] || 2009 / 11 / 19 || 10 || zlib  ||
|-
! 0x120
| {{cellcolors|#888888}} {{icon content ps3|50px}} [[4.00_CEX|4.00]]~[[4.25_CEX|4.25]] || 2011 / 11 / 29 || 10 || zlib  ||
|-
! 0x130
| {{cellcolors|#888888}} {{icon content ps3|50px}} [[4.30_CEX|4.30]]~[[4.83_CEX|4.83]] || 2012 / 10 / 24 || 10 || zlib ||  
|}
|}


Line 68: Line 93:
|-
|-
! Offset !! Length !! Example !! Name !! Notes
! Offset !! Length !! Example !! Name !! Notes
|-{{cellcolors|#000000|#ffffff}}
|-{{cellcolors|#666666|#ffffff}}
| 0x00 || 0x04 || 46 52 50 00 || '''prf_signature''' || In PS3 is "FRP" (big endian). In PSP is "PRF" (little endian)
| 0x00 || 0x04 || 46 52 50 00 || '''prf_signature''' || In PS3 is "FRP" (big endian). In PSP is "PRF" (little endian)
|-{{cellcolors|#000000|#ffffff}}
|-{{cellcolors|#666666|#ffffff}}
| 0x04 || 0x04 || 00 00 00 97 || '''prf_version''' || named ''minFirmwareVer'' in [[Rcomage]], see {{talk}} page
| 0x04 || 0x04 || 00 00 00 97 || '''prf_version''' || See {{talk}} page
|-{{cellcolors|#000000|#ffffff}}
|-{{cellcolors|#666666|#ffffff}}
| 0x08 || 0x04 || <abbr title="Always seems to be 0x00000000">00 00 00 00</abbr> || {{cellcolors|#ff7777}} <abbr title="minor_version ?">''prf_unknown''</abbr> ||  
| 0x08 || 0x04 || <abbr title="Always seems to be 0x00000000">00 00 00 00</abbr> || {{cellcolors|#ff7777}} <abbr title="prf_minor_version ?">''prf_unk''</abbr> ||  
|-{{cellcolors|#000000|#ffffff}}
|-{{cellcolors|#666666|#ffffff}}
| 0x0C || 0x04 || 00 00 00 00 || <abbr title="compress everything except the header and '''dat''' data tables to store files">'''prf_compression'''</abbr> || 0x00=uncompressed, 0x10=ZLIB, 0x20=RLZ<br>It can be combined with ''UMDflag'', see {{talk}} page
| 0x0C || 0x04 || 00 00 00 00 || <abbr title="compress everything except the header and '''dat''' data tables to store files">'''prf_compress'''</abbr> || 0x00=none, 0x10=ZLIB, 0x20=RLZ, see {{talk}} page
|-{{cellcolors|#7777ff}}
|-{{cellcolors|#7777ff}}
| 0x10 || 0x04 || 00 00 00 A4 || '''toc_maintree_absolute_offset''' ||  
| 0x10 || 0x04 || 00 00 00 A4 || '''toc_main_tree_offset''' ||  
|-{{cellcolors|#8888ff}}
|-{{cellcolors|#8888ff}}
| 0x14 || 0x04 || FF FF FF FF || '''toc_scripttree_absolute_offset''' ||  
| 0x14 || 0x04 || FF FF FF FF || '''toc_script_tree_offset''' ||  
|-{{cellcolors|#8888ff}}
|-{{cellcolors|#8888ff}}
| 0x18 || 0x04 || FF FF FF FF || '''toc_languagetree_absolute_offset''' ||  
| 0x18 || 0x04 || FF FF FF FF || '''toc_text_tree_offset''' ||  
|-{{cellcolors|#8888ff}}
|-{{cellcolors|#8888ff}}
| 0x1C || 0x04 || FF FF FF FF || '''toc_soundtree_absolute_offset''' ||  
| 0x1C || 0x04 || FF FF FF FF || '''toc_sound_tree_offset''' ||  
|-{{cellcolors|#8888ff}}
|-{{cellcolors|#8888ff}}
| 0x20 || 0x04 || FF FF FF FF || '''toc_modeltree_absolute_offset''' ||  
| 0x20 || 0x04 || FF FF FF FF || '''toc_model_tree_offset''' ||  
|-{{cellcolors|#8888ff}}
|-{{cellcolors|#8888ff}}
| 0x24 || 0x04 || FF FF FF FF || '''toc_imagetree_absolute_offset''' ||  
| 0x24 || 0x04 || FF FF FF FF || '''toc_image_tree_offset''' ||  
|-{{cellcolors|#8888ff}}
|-{{cellcolors|#8888ff}}
| 0x28 || 0x04 || <abbr title="Always seems to be 0xFFFFFFFF">FF FF FF FF</abbr> || {{cellcolors|#ff7777}} <abbr title="toc_unknowntree_absolute_offset">''toc_unknown''</abbr> ||  
| 0x28 || 0x04 || <abbr title="Always seems to be 0xFFFFFFFF">FF FF FF FF</abbr> || {{cellcolors|#ff7777}} <abbr title="toc_unk_tree_offset ?">''toc_unk''</abbr> ||  
|-{{cellcolors|#8888ff}}
|-{{cellcolors|#8888ff}}
| 0x2C || 0x04 || FF FF FF FF || '''toc_fonttree_absolute_offset''' ||  
| 0x2C || 0x04 || FF FF FF FF || '''toc_font_tree_offset''' ||  
|-{{cellcolors|#8888ff}}
|-{{cellcolors|#8888ff}}
| 0x30 || 0x04 || 00 00 00 CC || '''toc_objecttree_absolute_offset''' ||  
| 0x30 || 0x04 || 00 00 00 CC || '''toc_object_tree_offset''' ||  
|-{{cellcolors|#8888ff}}
|-{{cellcolors|#8888ff}}
| 0x34 || 0x04 || FF FF FF FF || '''toc_animationtree_absolute_offset''' ||  
| 0x34 || 0x04 || FF FF FF FF || '''toc_anim_tree_offset''' ||  
|-{{cellcolors|#66ff66}}
|-{{cellcolors|#66ff66}}
| 0x38 || 0x04 || 00 00 01 D4 || '''str_language_table_absolute_offset''' ||  
| 0x38 || 0x04 || 00 00 01 D4 || '''str_text_table_offset''' ||  
|-{{cellcolors|#66ff66}}
|-{{cellcolors|#66ff66}}
| 0x3C || 0x04 || 00 00 00 00 || '''str_language_table_length''' ||  
| 0x3C || 0x04 || 00 00 00 00 || '''str_text_table_length''' ||  
|-{{cellcolors|#99ff99}}
|-{{cellcolors|#99ff99}}
| 0x40 || 0x04 || 00 00 01 D4 || '''str_label_table_absolute_offset''' ||  
| 0x40 || 0x04 || 00 00 01 D4 || '''str_label_table_offset''' ||  
|-{{cellcolors|#99ff99}}
|-{{cellcolors|#99ff99}}
| 0x44 || 0x04 || 00 00 00 1C || '''str_label_table_length''' ||  
| 0x44 || 0x04 || 00 00 00 1C || '''str_label_table_length''' ||  
|-{{cellcolors|#bbffbb}}
|-{{cellcolors|#bbffbb}}
| 0x48 || 0x04 || 00 00 01 F0 || '''str_event_table_absolute_offset''' ||  
| 0x48 || 0x04 || 00 00 01 F0 || '''str_event_table_offset''' ||  
|-{{cellcolors|#bbffbb}}
|-{{cellcolors|#bbffbb}}
| 0x4C || 0x04 || 00 00 00 04 || '''str_event_table_length''' ||  
| 0x4C || 0x04 || 00 00 00 04 || '''str_event_table_length''' ||  
|-{{cellcolors|#770077}}
|-{{cellcolors|#770077}}
| 0x50 || 0x04 || FF FF FF FF || '''ptr_language_table_absolute_offset''' ||  
| 0x50 || 0x04 || FF FF FF FF || '''ptr_text_table_offset''' ||  
|-{{cellcolors|#770077}}
|-{{cellcolors|#770077}}
| 0x54 || 0x04 || 00 00 00 00 || '''ptr_language_table_length''' ||  
| 0x54 || 0x04 || 00 00 00 00 || '''ptr_text_table_length''' ||  
|-{{cellcolors|#880088}}
|-{{cellcolors|#880088}}
| 0x58 || 0x04 || FF FF FF FF || '''ptr_image_table_absolute_offset''' ||  
| 0x58 || 0x04 || FF FF FF FF || '''ptr_image_table_offset''' ||  
|-{{cellcolors|#880088}}
|-{{cellcolors|#880088}}
| 0x5C || 0x04 || 00 00 00 00 || '''ptr_image_table_length''' ||  
| 0x5C || 0x04 || 00 00 00 00 || '''ptr_image_table_length''' ||  
|-{{cellcolors|#990099}}
|-{{cellcolors|#990099}}
| 0x60 || 0x04 || FF FF FF FF || '''ptr_model_table_absolute_offset''' ||  
| 0x60 || 0x04 || FF FF FF FF || '''ptr_model_table_offset''' ||  
|-{{cellcolors|#990099}}
|-{{cellcolors|#990099}}
| 0x64 || 0x04 || 00 00 00 00 || '''ptr_model_table_length''' ||  
| 0x64 || 0x04 || 00 00 00 00 || '''ptr_model_table_length''' ||  
|-{{cellcolors|#aa00aa}}
|-{{cellcolors|#aa00aa}}
| 0x68 || 0x04 || FF FF FF FF || '''ptr_sound_table_absolute_offset''' ||  
| 0x68 || 0x04 || FF FF FF FF || '''ptr_sound_table_offset''' ||  
|-{{cellcolors|#aa00aa}}
|-{{cellcolors|#aa00aa}}
| 0x6C || 0x04 || 00 00 00 00 || '''ptr_sound_table_length''' ||  
| 0x6C || 0x04 || 00 00 00 00 || '''ptr_sound_table_length''' ||  
|-{{cellcolors|#bb00bb}}
|-{{cellcolors|#bb00bb}}
| 0x70 || 0x04 || 00 00 01 CC || '''ptr_object_table_absolute_offset''' ||  
| 0x70 || 0x04 || 00 00 01 CC || '''ptr_object_table_offset''' ||  
|-{{cellcolors|#bb00bb}}
|-{{cellcolors|#bb00bb}}
| 0x74 || 0x04 || 00 00 00 08 || '''ptr_object_table_length''' ||  
| 0x74 || 0x04 || 00 00 00 08 || '''ptr_object_table_length''' ||  
|-{{cellcolors|#cc00cc}}
|-{{cellcolors|#cc00cc}}
| 0x78 || 0x04 || FF FF FF FF || '''ptr_animation_table_absolute_offset''' ||  
| 0x78 || 0x04 || FF FF FF FF || '''ptr_anim_table_offset''' ||  
|-{{cellcolors|#cc00cc}}
|-{{cellcolors|#cc00cc}}
| 0x7C || 0x04 || 00 00 00 00 || '''ptr_animation_table_length''' ||  
| 0x7C || 0x04 || 00 00 00 00 || '''ptr_anim_table_length''' ||  
|-{{cellcolors|#ccaa88}}
|-{{cellcolors|#ccaa88}}
| 0x80 || 0x04 || FF FF FF FF || '''dat_image_table_absolute_offset''' ||  
| 0x80 || 0x04 || FF FF FF FF || '''dat_image_table_offset''' ||  
|-{{cellcolors|#ccaa88}}
|-{{cellcolors|#ccaa88}}
| 0x84 || 0x04 || 00 00 00 00 || '''dat_image_table_length''' ||  
| 0x84 || 0x04 || 00 00 00 00 || '''dat_image_table_length''' ||  
|-{{cellcolors|#ddbb99}}
|-{{cellcolors|#ddbb99}}
| 0x88 || 0x04 || FF FF FF FF || '''dat_sound_table_absolute_offset''' ||  
| 0x88 || 0x04 || FF FF FF FF || '''dat_sound_table_offset''' ||  
|-{{cellcolors|#ddbb99}}
|-{{cellcolors|#ddbb99}}
| 0x8C || 0x04 || 00 00 00 00 || '''dat_sound_table_length''' ||  
| 0x8C || 0x04 || 00 00 00 00 || '''dat_sound_table_length''' ||  
|-{{cellcolors|#eeccaa}}
|-{{cellcolors|#eeccaa}}
| 0x90 || 0x04 || FF FF FF FF || '''dat_model_table_absolute_offset''' ||  
| 0x90 || 0x04 || FF FF FF FF || '''dat_model_table_offset''' ||  
|-{{cellcolors|#eeccaa}}
|-{{cellcolors|#eeccaa}}
| 0x94 || 0x04 || 00 00 00 00 || '''dat_model_table_length''' ||  
| 0x94 || 0x04 || 00 00 00 00 || '''dat_model_table_length''' ||  
|-{{cellcolors|#ffddbb}}
|-{{cellcolors|#ffddbb}}
| 0x98 || 0x04 || <abbr title="Always seems to be 0xFFFFFFFF">FF FF FF FF</abbr> || {{cellcolors|#ff7777}} <abbr title="dat_unknown_table_absolute_offset">''dat_unknown_1''</abbr> ||
| 0x98 || 0x0C || <abbr title="Always seems to be 0xFFFFFFFF 0xFFFFFFFF 0xFFFFFFFF">FF FF FF FF .. .</abbr> || {{cellcolors|#ff7777}} ''dat_unk'' ||  
|-{{cellcolors|#ffddbb}}
| 0x9C || 0x04 || <abbr title="Always seems to be 0xFFFFFFFF">FF FF FF FF</abbr> || {{cellcolors|#ff7777}} <abbr title="dat_unknown_table_length">''dat_unknown_2''</abbr> ||
|-{{cellcolors|#ffddbb}}
| 0xA0 || 0x04 || <abbr title="Always seems to be 0xFFFFFFFF">FF FF FF FF</abbr> || {{cellcolors|#ff7777}} <abbr title="dat_unknown_table_absolute_offset">''dat_unknown_3''</abbr> ||  
|}
|}
*All offsets in the header are absolute


==TOC==
==TOC==
This area works as an index of all the .rco contents, when the area is compressed there are 12 bytes at the beginning with info about this compression, after it starts the info composed by entries that follows a hierarchy of parent/children/brother, every entry defines an element with its attributes. All this info can be represented as an xml file (this is what rcomage names an [[RCOXML Structure|RCOXML]])
The TOC (table of contents) works as an index of all the .RCO contents, is composed by entries that follows a hierarchy of parent/children/siblings, it can be represented as an .XML file composed by '''elements''' and its '''attributes''' (see [http://www.w3schools.com/xml/xml_tree.asp XML Tree] and  [[RCOXML Coding]])
 
The container structure can be represented as an XML (see [[RCOXML Coding|RCOXML]]), with [[rcomage]] is posible to generate this XML when extracting, and for rebuilding the rco using the XML as a layout


Every entry has an area at beginning that is common for all '''entry_types''', the values that comes after this common area are specific and different for each the '''entry_type'''
===Element===
Every entry starts with an area of 0x28 length that represents an XML '''element''', it specifyes the '''entry_type''', a '''label''' identifyer for this entry (optional) and some info related with the TOC internal structure and its hierarchy relationship with other entries. All offset are relative


{| class="wikitable" style="font-size:small;"
{| class="wikitable" style="font-size:small;"
|+RCO TOC entry common area {{ed right|RCO TOC entry common area}}
|+RCO TOC entry common area {{ed right|RCO TOC entry common area}}
! Offset !! Length !! Data type !! Name !! {{icon content psp|50px}} !! {{icon content ps3|50px}} !! Example (TOC) !! Example (XML) !! Notes
! Offset !! Length !! <abbr title="Data type">Type</abbr> !! Name !! {{icon content psp|50px}} !! {{icon content ps3|50px}} !! Example (TOC) !! Example (XML) !! Notes
|-
|-
| {{RCO TOC entry common area}}
| {{RCO TOC entry common area}}
Line 167: Line 189:
|}
|}


===Attributes===
Attributes are located after the element definition (at entry relative offset 0x28), only exists for the elements that uses attributes, each '''entry_type''' uses different attributes, are explained in detail in other wiki pages
{{RCO TOC entry types}}
{{RCO TOC entry types}}


After the area common for all entries it starts the info specific for each '''entry_type''' explained below
Some of the attributes are a '''reference''' to load other entry
{{RCO TOC reference types}}


*(0x1) MainTree
===Example===
Main tree doesnt uses specific attributes, only uses the default ones explained above that indicates his position at top of the [[RCOXML Structure]] hierarchy and gives it a "label" name<!-- Doesn't have parent, and doesn't have any previous or next "brother", the number of childrens indicates how many of the '''entry_type''' explained below are under it (max number of childrens should be 8 for an .rco containing at least one of each) -->
{{Boxframe1|content='''example placeholder'''
*Example here following the other example of the header at top of the page, using color codes like the examples in {{talk}} page
*With '''MainTree-AnimTree-Animation-Fade''' (because i think is the minimal example that shows how trees are made and the entry_type "fade" that uses "standard" and "specific" attributes)
*And '''MainTree-ObjectTree-Page''' (because the animation needs to be linked to an object by using a reference, otherway rcomage will return an error when trying to compile it)
}}


*(0x2) Script
==Pointer tables==
This is named "ScriptTree" for  simplification purposes, but is not actually a tree, only one [[VSMX]] file can be stored inside an RCO
This area works as an external index of the TOC, stores <abbr title="unlike in TOC table that are relative">absolute</abbr> pointers to all the chiildren of the "tree" TOC entries, is composed by 6 tables in this order:
*'''text_tree_pointer_table'''
*'''image_tree_pointer_table'''
*'''model_tree_pointer_table'''
*'''sound_tree_pointer_table'''
*'''object_tree_pointer_table'''
*'''anim_tree_pointer_table'''


{| class="wikitable"
|-
! Offset !! Length !! Name !! Example !! Notes
|-
| 0x00 || 0x04 || '''file_offset''' ||  || VSMX file offset, relative to the start offset of the vsmx data table (always 0)
|-
| 0x04 || 0x04 || '''file_size''' ||  || VSMX file length
|}


*(0x3) Text
*Every pointer is 0x04 bytes length
"TextTree" could be renamed to LanguageTree, is more intuitive, the point is every entry here is the "parent" of several string texts, but the entry itself is not a text (is the parent of a group of texts), so is better to use a name more abstract like "LanguageTree"
*The other "trees" children that doesnt uses a pointer table are: MainTree (is not needed because its children are the other "trees"), ScriptTree (because doesnt have children), and FontTree because ?????<!--i cant imagine why but there must be a good reason-->
*The existence of this area with pointers seems to be related with the fact that is posible to use a whole file compression (by setting it in the header at offset 0x0C) that compresses the TOC. Also when loading the .RCO file in the RAM of the console probably is "cropped" in parts, the TOC is decompresed and kept in a memory area with the other TOC's from the other RCO files (for fast selective access to the .RCO contents, and for performance) and is posible to read the relative offsets directlly from the TOC's and deprecate the absolute offsets from the pointers tables<!--or something like that, if someone can explain it please help rewriting this-->


For a [[Languages|Language]] first are specified the '''language_id''' and the number of "children" text strings
==String tables==
{| class="wikitable"
This area stores the text strings used by the TOC entries, is composed by 3 tables in this order:
|-
*'''text_string_table''' (to store localized language texts from TextTree entries)
! Offset !! Length !! Name !! Example !! Notes
*'''label_string_table''' (to store the labels of all the entries that uses labels)
|-
*'''event_string_table''' (to store the values of the attributes used by some entries, either "native" or "script" events)
| 0x00 || 0x02 || '''language_id''' ||  || 0x00=Japanese<br>0x01=English (United States)<br>0x02=French<br>0x03=Spanish (Spain)<br>0x04=German<br>0x05=Italian<br>0x06=Dutch<br>0x07=Portuguese (Portugal)<br>0x08=Russian<br>0x09=Korean<br>0x0A=Chinese (Traditional)<br>0x0B=Chinese (Simplified)<br>0x0C=Finnish<br>0x0D=Swedish<br>0x0E=Danish<br>0x0F=Norwegian<br>0x10=Polish<br>0x11=Portuguese (Brazil)<br>0x12=English (United Kingdom)<br>0x13=Turkish
|-
| 0x02 || 0x02 || '''strings_format''' ||  || 0x00=UTF8<br>0x01=UTF16<br>0x02=UTF32
|-
| 0x04 || 0x04 || '''strings_number''' ||  || number of text strings for this '''language_id'''
|}
 
Now for every '''strings_number''' are repeated 12 bytes to define every string that are references to other tables
{| class="wikitable"
|-
! Offset !! Length !! Name !! Example !! Notes
|-
| 0x00 || 0x04 || '''label_offset''' ||  || Offset to label, relative of the label table
|-
| 0x04 || 0x04 || '''string_length''' ||  || Length of the text
|-
| 0x08 || 0x04 || '''string_offset''' ||  || Offset of the text, relative to the text data start address
|}


*(0x4) Image
The values marked in red are optional, the presence of the '''unknown''' specific for PS3 can be deduced based on the "rco version" in the rco header, only exists in PS3 RCO's (PSP doesnt uses it). See [[Talk:Rcomage|rcomage talk page]]. The presence of the other optional value '''file_uncompressed_size''' can be deduced by reading the entry itself


The '''file_compression''' feature adds a compression layer over the file format (pointless for image formats that are nativelly compressed like GIM or JPG)
*Strings are null terminated (ends in 0x00)
*Strings are aligned to 4 bytes boundary (padding at the end of every string when needed)


{| class="wikitable"
==Data tables==
|-
This area stores files that can be compressed individually (or not) as specifyed by the attributes of some entries in the TOC, is composed by 3 tables in this order:
! Offset !! Length !! Name !! Example !! Notes
*'''image_data_table''' (to store the files used by ImageTree entries)
|-
*'''sound_data_table''' (to store the files used by SoundTree entries)
| 0x00 || 0x02 || '''file_format''' ||  || 0x0=PNG<br>0x1=JPEG<br>0x2=TIFF<br>0x3=GIF<br>0x4=BMP<br>0x5=GIM
*'''model_data_table''' (to store the files used by ModelTree entries)
|-
| 0x02 || 0x02 || '''file_compression''' ||  || 0x0=NONE<br>0x1=ZLIB<br>0x2=RLZ
|-
| 0x04 || 0x04 || '''file_size''' ||  || either compressed or uncompressed, this is the final size of the file stored inside the rco
|-
| 0x08 || 0x04 || '''file_offset''' ||  ||
|-
| 0x0C || 0x04 || {{cellcolors|#ff9999}} ''unknown'' ||  || PS3 RCOs seem to have this extra value - probably something to do with planes/frames?? usually 0x1
|-
| 0x10 || 0x04 || {{cellcolors|#9999ff}} '''file_uncompressed_size''' ||  || Optional. Doesn't exist if '''file_compression''' = '''NONE''', for PSP is located 4 bytes before because the previous value doesn't exists
|}


*(0x5) Model
ModelTree uses the same values than ImageTree with a couple of differences, the table is repeated here for comparison purposes


The presence of the '''unknown''' (specific for PS3) is completlly speculative because never has been found a GMO file used on PS3 official firmware, is not even known if PS3 firmware has some function able to manage GMO files
*Files are aligned to 4 bytes boundary (padding at the end of every file when needed)
 
{| class="wikitable"
|-
! Offset !! Length !! Name !! Example !! Notes
|-
| 0x00 || 0x02 || '''file_format''' ||  || 0x0=GMO
|-
| 0x02 || 0x02 || '''file_compression''' ||  || 0x0=NONE<br>0x1=ZLIB<br>0x2=RLZ
|-
| 0x04 || 0x04 || '''file_size''' ||  || either compressed or uncompressed, this is the final size of the file stored inside the rco
|-
| 0x08 || 0x04 || '''file_offset''' ||  || Offset of data relative to the beginning of the image data section
|-
| 0x0C || 0x04 || {{cellcolors|#ff9999}} ''unknown'' ||  || PS3 RCOs seem to have this extra value - probably something to do with planes/frames?? usually 0x1
|-
| 0x10 || 0x04 || {{cellcolors|#9999ff}} '''file_uncompressed_size''' ||  || Optional. Doesn't exist if '''file_compression''' = '''NONE''', for PSP is located 4 bytes before because the previous value doesn't exists
|}
 
*(0x6) Sound
{| class="wikitable"
|-
! Offset !! Length !! Name !! Example !! Notes
|-
| 0x00 || 0x02 || '''file_format''' ||  || <span style="background:#ff9999;">0x0=''unknown''</span><br>0x1=VAG
|-
| 0x02 || 0x02 || '''audio_channels''' ||  || 0x1=MONO<br>0x2=STEREO
|-
| 0x04 || 0x04 || '''file_size''' ||  || either one or two channels, this is the final size of the file stored inside the rco
|-
| 0x08 || 0x04 || '''file_offset''' ||  || Offset of the sound data to the beginning of the sound data section
|-
| 0x0C || 0x04 || '''left_channel_size''' ||  || <!--If '''audio_channels''' = '''MONO''' this is the size of the whole audio file, if '''STEREO''' -->This is the size of left channel file
|-
| 0x10 || 0x04 || '''left_channel_offset''' ||  || Offset of left channel VAG to the beginning of the sound data section
|-
| 0x0C || 0x04 || {{cellcolors|#9999ff}} '''right_channel_size''' ||  || Optional. Only exists if '''audio_channels''' = '''STEREO'''
|-
| 0x10 || 0x04 || {{cellcolors|#9999ff}} '''right_channel_offset''' ||  || Optional. Only exists if '''audio_channels''' = '''STEREO'''
|}
 
*(0x7) Font
*(0x8) Object
*(0x9) Animation
 
==Pointer tables==
 
==String tables==
 
==Data tables==


=RCO compression methods=
=RCO compression methods=
Line 304: Line 251:
|}
|}


=VSH access to RCO contents=
See the [[VSH_Exports#paf "paf" VSH exports]], most of them uses the internal "official" names of lot of stuff related with RCO (i guess there are a lot of names used in this wiki that was taken from rcomage or by deduction that should be replaced by the official names), and can help to understand how the firmware processes and accesses to the internal content of .RCO files (it can help a lot to any tool involved in processing .RCO files to make it most efficient, simple and accurate posible)
*Related with the internal RCO [http://www.w3schools.com/xml/dom_intro.asp | XML DOM structure]
**PAF_Resource_DOMGetNodeChildByID, PAF_Resource_DOMGetNodeChildByPos, PAF_Resource_DOMGetNodeData, PAF_Resource_DOMGetNodeFirstChild, PAF_Resource_DOMGetNodeID, PAF_Resource_DOMGetNodeNext, PAF_Resource_DOMGetNodeType, PAF_Resource_GetPageNodeByID, PAF_Resource_GetWidgetNodeByID, PAF_Resource_ResolveRefNode, PAF_Resource_ResolveRefString, PAF_Resource_ResolveRefWString (It seems some are missing though)
*Related with [[RCOXML Objects]]
**This seems to be the complete list of [[RCOXML Objects]] internal names (It seems some are missing though)
***0x546B3D02 returns "PhWidget", 0x41BBFE5E returns "PhScene", 0x10DEDCC7 returns "PhPlane", 0xE36C18F5 returns "PhPlaneDiv", 0x24A5BD6B returns "PhButton", 0xB7DFCE90 returns "PhText", 0x9207F4 returns "PhScroll", 0xBA6D149A returns "PhLabelPrim", 0xC88CA4B2 returns "PhLevelMeter", 0xE801C345 returns "PhProgress", 0xBF66BF2D returns "PhCheckBox", 0x703117AD returns "PhXmBar", 0x4FF7B8A9 returns "PhXmList", 0xC84FD77B returns "PhXmItem", 0x4C36ABBB returns "PhItemSpin", 0xCA9160F6 returns "PhNumSpin", 0x59A11C82 returns "PhNumSpin", 0xD64EDE7C returns "PhList", 0xF7630798 returns "PhInfoList", 0xA98865F8 returns "PhMenuList", 0x90F4F801 returns "PhCheckBoxList", 0xDDD4ACF6 returns "PhLabelText", 0x545D47A2 returns "PhClock", 0x3806365F returns "PhIPAddr"
**The names of the attributes ordered by groups (there are a lot)
***As example: 0xDEF981C4 _ZN3paf8PhXmList7FocusInEf, 0x814B3D90 _ZN3paf8PhXmList8FocusOutEf this two seems to be the attributes '''FocusOut''' and '''FocusIn''' from the object '''XmList'''


{{File Formats}}
{{File Formats}}
<noinclude>[[Category:Main]]</noinclude>
<noinclude>[[Category:Main]]</noinclude>

Latest revision as of 12:20, 2 February 2022

Description[edit | edit source]

The file extension in PSP and PS3 is RCO that seems to be the acronym of Resource Container Object

The file signature (aka magic number) from PSP (in little endian) is PRF that seems to be the acronym of Playstation Resource File

RCO contents are loaded by other firmware functions as XMBML setting files, and XMB modules (also known as .sprx plugins), see Plugin Interfaces and VSH

Contents[edit | edit source]

Text for all languages, textures, sounds (for cursor navigation, trophy unlocking, etc...) and models

RCO format Embedded code Text Textures Sounds Models Script
Generic RCOXML utf8, utf16, utf32 gim, png, jpg, tif, gif, bmp vag, unknown0x0 gmo PlayStation JavaScript
PS3 specific RCOXML utf16 gim, png, jpg vag n/a n/a

Versions[edit | edit source]

RCO version Firmware Release date RCO format specifications
Toc trees Toc compression Other Notes
0x55 PSP icon 0.6.5 pre-retail 9 none archaic rco format, header is 16 bytes smaller
0x70 PSP icon 1.00 2004 / 12 / 12 10 none
0x71 PSP icon 1.50~2.50 2005 / 3 / 24 10 none
0x90 PSP icon 2.60 2005 / 11 / 29 10 zlib
0x93 PS3 icon 0.82 2006 / 3 / 31 10 none
0x94 PS3 icon 0.83 2006 / 4 / 19 10 none
0x95 PSP icon 2.70~2.71 2006 / 4 / 25 10 rlz
PS3 icon 0.84 2006 / 5 / 19 10 none
0x96 PSP icon 2.80~3.40 2006 / 7 / 27 10 rlz ? the toc seems to be compressed in parts
0x97 PS3 icon 0.85~1.54 2006 / 11 / 11 10 none
0x100 PSP icon 3.50~6.61 2007 / 5 / 31 10 rlz ?
0x102 PS3 icon 1.60~1.70 2007 / 3 / 22 10 ?
0x104 PS3 icon 1.80~1.82 2007 / 5 / 24 10 ?
0x105 PS3 icon 1.90~1.94 2007 / 7 / 24 10 zlib
0x106 PS3 icon 2.00~2.17 2007 / 11 / 8 10 zlib
0x107 PS3 icon 2.20~2.80 2008 / 3 / 25 10 zlib
0x108 PS3 icon 3.00~3.01 2009 / 9 / 1 10 zlib
0x110 PS3 icon 3.10~3.74 2009 / 11 / 19 10 zlib
0x120 PS3 icon 4.00~4.25 2011 / 11 / 29 10 zlib
0x130 PS3 icon 4.30~4.83 2012 / 10 / 24 10 zlib

RCO Structure[edit | edit source]

Based on RCO File Format (outdated) and rcomage source

Header[edit | edit source]

Offset Length Example Name Notes
0x00 0x04 46 52 50 00 prf_signature In PS3 is "FRP" (big endian). In PSP is "PRF" (little endian)
0x04 0x04 00 00 00 97 prf_version See Discussion page
0x08 0x04 00 00 00 00 prf_unk
0x0C 0x04 00 00 00 00 prf_compress 0x00=none, 0x10=ZLIB, 0x20=RLZ, see Discussion page
0x10 0x04 00 00 00 A4 toc_main_tree_offset
0x14 0x04 FF FF FF FF toc_script_tree_offset
0x18 0x04 FF FF FF FF toc_text_tree_offset
0x1C 0x04 FF FF FF FF toc_sound_tree_offset
0x20 0x04 FF FF FF FF toc_model_tree_offset
0x24 0x04 FF FF FF FF toc_image_tree_offset
0x28 0x04 FF FF FF FF toc_unk
0x2C 0x04 FF FF FF FF toc_font_tree_offset
0x30 0x04 00 00 00 CC toc_object_tree_offset
0x34 0x04 FF FF FF FF toc_anim_tree_offset
0x38 0x04 00 00 01 D4 str_text_table_offset
0x3C 0x04 00 00 00 00 str_text_table_length
0x40 0x04 00 00 01 D4 str_label_table_offset
0x44 0x04 00 00 00 1C str_label_table_length
0x48 0x04 00 00 01 F0 str_event_table_offset
0x4C 0x04 00 00 00 04 str_event_table_length
0x50 0x04 FF FF FF FF ptr_text_table_offset
0x54 0x04 00 00 00 00 ptr_text_table_length
0x58 0x04 FF FF FF FF ptr_image_table_offset
0x5C 0x04 00 00 00 00 ptr_image_table_length
0x60 0x04 FF FF FF FF ptr_model_table_offset
0x64 0x04 00 00 00 00 ptr_model_table_length
0x68 0x04 FF FF FF FF ptr_sound_table_offset
0x6C 0x04 00 00 00 00 ptr_sound_table_length
0x70 0x04 00 00 01 CC ptr_object_table_offset
0x74 0x04 00 00 00 08 ptr_object_table_length
0x78 0x04 FF FF FF FF ptr_anim_table_offset
0x7C 0x04 00 00 00 00 ptr_anim_table_length
0x80 0x04 FF FF FF FF dat_image_table_offset
0x84 0x04 00 00 00 00 dat_image_table_length
0x88 0x04 FF FF FF FF dat_sound_table_offset
0x8C 0x04 00 00 00 00 dat_sound_table_length
0x90 0x04 FF FF FF FF dat_model_table_offset
0x94 0x04 00 00 00 00 dat_model_table_length
0x98 0x0C FF FF FF FF .. . dat_unk
  • All offsets in the header are absolute

TOC[edit | edit source]

The TOC (table of contents) works as an index of all the .RCO contents, is composed by entries that follows a hierarchy of parent/children/siblings, it can be represented as an .XML file composed by elements and its attributes (see XML Tree and RCOXML Coding)

Element[edit | edit source]

Every entry starts with an area of 0x28 length that represents an XML element, it specifyes the entry_type, a label identifyer for this entry (optional) and some info related with the TOC internal structure and its hierarchy relationship with other entries. All offset are relative

RCO TOC entry common area
[edit]
Offset Length Type Name PSP icon PS3 icon Example (TOC) Example (XML) Notes
0x00 0x04 int entry_type Yes Yes 01 01 / 00 00 <Element name="label"/> entry_type[2], padding[2]
0x04 0x04 int entry_label_offset Yes Yes 00 00 00 00 label_string_table_offset[4] (optional)
0x08 0x04 int attributes_offset Yes Yes 00 00 00 00 represents XML hierarchy Attributes offset relative to the start of this entry (optional)
0x0C 0x04 int children_offset Yes Yes 00 00 00 28 First children offset relative to the start of this entry (optional)
0x10 0x04 int children_number Yes Yes 00 00 00 00 Number of subentries
0x14 0x04 int next_sibling_offset Yes Yes 00 00 00 00 Next sibling offset relative to the start of this entry (optional)
0x18 0x04 int prev_sibling_offset Yes Yes 00 00 00 00 Previous sibling offset relative to the start of this entry (optional)
0x1C 0x04 int parent_offset Yes Yes 00 00 00 00 This entry offset relative to the start of the parent entry
0x20 0x08 unk toc_entry_unk Yes Yes 00 00 00 00 .. . no XML representation Unknown

Attributes[edit | edit source]

Attributes are located after the element definition (at entry relative offset 0x28), only exists for the elements that uses attributes, each entry_type uses different attributes, are explained in detail in other wiki pages

RCO TOC entry types
[edit]
Second byte
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F
First byte 0x01 unk MainTree
0x02 ScriptTree
0x03 TextTree Text
0x04 ImageTree Image
0x05 ModelTree Model
0x06 SoundTree Sound
0x07 FontTree Font
0x08 ObjectTree Page Plane Button XMenu XMList XList Progress Scroll MList MItem unk XItem Text ModelObject Spin Action ItemSpin Group LList LItem Edit Clock IList IItem Icon UButton unk CheckboxGroup CheckboxItem Meter EditBox
0x09 AnimTree Anim MoveTo Recolour Rotate Resize Fade Delay FireEvent Lock Unlock SlideOut
Supported by PSP icon and PS3 icon Supported by PS3 icon only
  • The entry_types with the suffix Tree (as example MainTree) are special and doesnt uses attributes, MainTree is always located as the first entry, doesn't have a parent, and doesn't have any previous or next "sibling", the maximun number posible of childrens for MainTree is 8 (containing all the other "trees"). The other "trees" (as example imageTree or soundTree) are siblings and are the childrens of "MainTree", Every one of those "trees" contains a variable number of entry_types that are its childrens
  • The attributes of the RCOXML Objects (entry_types starting with 0x08) and RCOXML Animations (entry_types starting with 0x09) can be grouped in standard attributes (used by most entryes of this type) and specific attributes (different for every entry_type). The standard attributes are always located before the specific attributes
  • First two bytes are swapped based on architecture (PSP in little endian, PS3 in big endian). The table shows the values in big endian


Some of the attributes are a reference to load other entry

RCO TOC reference types
[edit]
reference_type pointer Method Loader Loads From Example (XML) Notes
0xFFFF0000 0xFFFFFFFF n/a All Nothing None <Entry reference="nothing"/>
0x04000000 relative event: RCOXML Objects
RCOXML Animations		 Code function Associated .SPRX <Entry event="event:native:/runFuctionX"/>
ScriptTree/Script File inside RCO <Entry event="event:script:/main/runFuctionX"/>
0x04010000 # (0-based) text: RCOXML Objects
XMBML Code		 TextTree/Text Strings inside RCO <Entry text="text:msg_mytext"/>
0x04020000 absolute image: RCOXML Objects
XMBML Code		 ImageTree/Image File inside RCO <Entry image="image:tex_mytexture"/>
0x04030000 absolute model: RCOXML Objects ModelTree/Model File inside RCO <Entry model="model:mymodel"/>
0x04040000 absolute ? sound: ? associated .SPRX SoundTree/Sound File inside RCO <Entry sound="sound:mysound"/> ? speculation
0x04050000 absolute font: RCOXML Objects FontTree/Font File inside RCO ? <Entry font="font:fontstyle_sanserif"/>
0x04060000 absolute ? anim2: ? RCOXML Objects ? AnimTree/Animation ? RCOXML code ? <Entry anim2="anim2:myanimation"/> ? speculation
0x04070000 absolute object2: RCOXML Objects ObjectTree/Object RCOXML code <Entry object2="object2:plane_myplane"/>
0x04080000 absolute anim: RCOXML Animations AnimTree/Animation RCOXML code <Entry anim="anim:myanimation"/>
0x04090000 absolute object: RCOXML Animations ObjectTree/Object RCOXML code <Entry object="object:plane_myplane"/>
  • A reference attribute is composed by two values, the first is the reference_type that indicates the "tree" of the entry that is going to be loaded, and the second is a pointer to a text string with the label of the entry that is going to be loaded
  • The reference_type event doesnt loads an entry from a "tree" though, it runs a code function from either a .sprx (by storing the text native:/ as part of the text string inside the RCO) or from a VSMX script (by storing the text script:/ as part of the text string inside the RCO)
  • First two bytes are swapped based on architecture (PSP in little endian, PS3 in big endian). The table shows the values in big endian


Example[edit | edit source]

example placeholder
  • Example here following the other example of the header at top of the page, using color codes like the examples in Discussion page
  • With MainTree-AnimTree-Animation-Fade (because i think is the minimal example that shows how trees are made and the entry_type "fade" that uses "standard" and "specific" attributes)
  • And MainTree-ObjectTree-Page (because the animation needs to be linked to an object by using a reference, otherway rcomage will return an error when trying to compile it)

Pointer tables[edit | edit source]

This area works as an external index of the TOC, stores absolute pointers to all the chiildren of the "tree" TOC entries, is composed by 6 tables in this order:

  • text_tree_pointer_table
  • image_tree_pointer_table
  • model_tree_pointer_table
  • sound_tree_pointer_table
  • object_tree_pointer_table
  • anim_tree_pointer_table


  • Every pointer is 0x04 bytes length
  • The other "trees" children that doesnt uses a pointer table are: MainTree (is not needed because its children are the other "trees"), ScriptTree (because doesnt have children), and FontTree because ?????
  • The existence of this area with pointers seems to be related with the fact that is posible to use a whole file compression (by setting it in the header at offset 0x0C) that compresses the TOC. Also when loading the .RCO file in the RAM of the console probably is "cropped" in parts, the TOC is decompresed and kept in a memory area with the other TOC's from the other RCO files (for fast selective access to the .RCO contents, and for performance) and is posible to read the relative offsets directlly from the TOC's and deprecate the absolute offsets from the pointers tables

String tables[edit | edit source]

This area stores the text strings used by the TOC entries, is composed by 3 tables in this order:

  • text_string_table (to store localized language texts from TextTree entries)
  • label_string_table (to store the labels of all the entries that uses labels)
  • event_string_table (to store the values of the attributes used by some entries, either "native" or "script" events)


  • Strings are null terminated (ends in 0x00)
  • Strings are aligned to 4 bytes boundary (padding at the end of every string when needed)

Data tables[edit | edit source]

This area stores files that can be compressed individually (or not) as specifyed by the attributes of some entries in the TOC, is composed by 3 tables in this order:

  • image_data_table (to store the files used by ImageTree entries)
  • sound_data_table (to store the files used by SoundTree entries)
  • model_data_table (to store the files used by ModelTree entries)


  • Files are aligned to 4 bytes boundary (padding at the end of every file when needed)

RCO compression methods[edit | edit source]

When the TOC table is compressed at beginning there are 3 values related with the compression (otherway if the table is not compressed this 3 values doesnt exists)

Offset Length Name Example Notes Speculation
0x00 0x04 lenPacked Packed size of all the table sections
0x04 0x04 lenUnpacked Unpacked size of all the table sections
0x08 0x04 lenLongestText length of the longest language's text data (unpacked)
if the compressed area doesn't contains any language text the value is 0

VSH access to RCO contents[edit | edit source]

See the VSH_Exports#paf "paf" VSH exports, most of them uses the internal "official" names of lot of stuff related with RCO (i guess there are a lot of names used in this wiki that was taken from rcomage or by deduction that should be replaced by the official names), and can help to understand how the firmware processes and accesses to the internal content of .RCO files (it can help a lot to any tool involved in processing .RCO files to make it most efficient, simple and accurate posible)

  • Related with the internal RCO | XML DOM structure
    • PAF_Resource_DOMGetNodeChildByID, PAF_Resource_DOMGetNodeChildByPos, PAF_Resource_DOMGetNodeData, PAF_Resource_DOMGetNodeFirstChild, PAF_Resource_DOMGetNodeID, PAF_Resource_DOMGetNodeNext, PAF_Resource_DOMGetNodeType, PAF_Resource_GetPageNodeByID, PAF_Resource_GetWidgetNodeByID, PAF_Resource_ResolveRefNode, PAF_Resource_ResolveRefString, PAF_Resource_ResolveRefWString (It seems some are missing though)
  • Related with RCOXML Objects
    • This seems to be the complete list of RCOXML Objects internal names (It seems some are missing though)
      • 0x546B3D02 returns "PhWidget", 0x41BBFE5E returns "PhScene", 0x10DEDCC7 returns "PhPlane", 0xE36C18F5 returns "PhPlaneDiv", 0x24A5BD6B returns "PhButton", 0xB7DFCE90 returns "PhText", 0x9207F4 returns "PhScroll", 0xBA6D149A returns "PhLabelPrim", 0xC88CA4B2 returns "PhLevelMeter", 0xE801C345 returns "PhProgress", 0xBF66BF2D returns "PhCheckBox", 0x703117AD returns "PhXmBar", 0x4FF7B8A9 returns "PhXmList", 0xC84FD77B returns "PhXmItem", 0x4C36ABBB returns "PhItemSpin", 0xCA9160F6 returns "PhNumSpin", 0x59A11C82 returns "PhNumSpin", 0xD64EDE7C returns "PhList", 0xF7630798 returns "PhInfoList", 0xA98865F8 returns "PhMenuList", 0x90F4F801 returns "PhCheckBoxList", 0xDDD4ACF6 returns "PhLabelText", 0x545D47A2 returns "PhClock", 0x3806365F returns "PhIPAddr"
    • The names of the attributes ordered by groups (there are a lot)
      • As example: 0xDEF981C4 _ZN3paf8PhXmList7FocusInEf, 0x814B3D90 _ZN3paf8PhXmList8FocusOutEf this two seems to be the attributes FocusOut and FocusIn from the object XmList
SCE File Types
Certified File
NPDRM
NPDRM · App Types · ACT.DAT · RIF
PKG
EDAT
RCOXML
CXML
XMBML
XMB Config
DB Config
Databases
System Data
XMB Preload
Licences
 ·
Games/Apps
PS3
Emulators
Web
Unsorted
Retrieved from "http://www.psdevwiki.com/ps3/index.php?title=Resource_Container_(RCO)&oldid=65013"