Resource Container (RCO)

Description

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

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

• RCO contents (See Multimedia Formats and Tools):

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

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

RCO Structure

Based on RCO File Format (outdated) and rcomage source

Header

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=uncompressed, 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

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

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

Offset	Length	Type	Name			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

After the common area (at entry relative offset 0x28) appears the attributes, the attributes are different for every entry_type and are explained in detail in other wiki pages, see the links in the table below

The entry_types wich name contains the word 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

An special mention is needed to the RCOXML Objects (entry_types starting with 0x08) and RCOXML Animations (entry_types starting with 0x09) where the attributes 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

RCO TOC entry types

		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 and																											Supported by 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, are 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)

RCO TOC reference types

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

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)

String tables

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)

Pointer tables

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

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:

• 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

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