Talk:PARAM.SFO: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
 
(343 intermediate revisions by 10 users not shown)
Line 1: Line 1:
=Unknown or new parameters=
This page is an index/worklog/notepad with sections referred to the front page. All the sections in this page are things related with PARAM.SFO that are not completely documented, and the final purpose is to move the info when completed to the front page. This also will help to keep the front page free of speculation.


----
==CATEGORY (new content formats)==
*CATEGORY '''VF''' - (HDD content, NOT in game column) ---> '''unknown name''', used as a valid category filter in the XML configuration file for [[XMB-Game | XMB game column]] in path: dev_flash/vsh/resource/explore/xmb/category_game.xml in key="gameDir"
**key="gameDir" is an XMB item that allows to order the contents by "rating" or "timeCreated" the command used contains a list of categories that are excluded using the [[XMBML Functions#Operators| operator "An" = An not equal]] (VF is at the end of the list excluded with '''An+Game:Game.category VF''')
**Similar than MN, 1P?
 
*CATEGORY '''XI''' - '''Confirmed''' ---> '''System File for Extra Content Item''' (or '''eXtra Item''' in short form) Used on blu ray structure?


==Unknown==
*'''Indie games''' New category on PSvita and PSN http://blog.us.playstation.com/2013/06/25/ps-vita-indie-games-category-now-live-on-psn/
This is the first attempt to create an "index" for this page with sections refered to the "front" page that doesnt needs to have the same names but needs to be grouped in some way. All the sections in this page are things related with PARAM.SFO that are not completly documented, and the final purpose is to move the info when completed to the "front" page. This also will help to keep the "front" page free of speculation
Indi games has a specific license, if XMB differences it it will be using ATTRIBUTE flags (similar identification than neogeo and pcengine because has a special license)


===ATTRIBUTE flags===
*'''PlayStation Mobile''' Implemented around 4.21 firmware, asociated with a text string in explore_plugin_full\Text\English.xml (inside explore_plugin_full.rco). See [PS3 and PSVita Cross Functions]
<Text name="msg_applications_psm">Applications (PlayStation®Mobile)</Text>
 
==ATTRIBUTE (flags brainstorming)==
'''XMB In-Game System Chat Voice Disable''' (Flag Nº7) : Value and name description are related to this flag but need to be confirmed from PS3 side / not used on bootable but as patches?.
'''XMB In-Game System Chat Voice Disable''' (Flag Nº7) : Value and name description are related to this flag but need to be confirmed from PS3 side / not used on bootable but as patches?.


Function to disable chat voice utility (xmb/friend/start new chat appear when online is possible) (implemented directly on FW or as flag into param.sfo for short period?) have been used for PlayStation Home after people reported chat voice disturbance.
Function to disable system chat voice utility (xmb/friend/start new chat appear when PSN connected) (implemented directly on FW or game or as flag into param.sfo for short period?) e.g. of this function: PlayStation Home 1.4 after people reported chat voice disturbance(?) , LittleBigPlanet 2.


Kept as flag for convenience (to disable per game through update game and not FW) but can be "system reminiscent" and not working anymore from param.sfo?
Kept as flag for convenience (to disable per game through update game and not FW) but can be "system reminiscent" and not working anymore from param.sfo?


Similar function also is when the game use the recording utility: User is allowed to record his game-play as video (e.g.: Little big planet?) but to avoid the possible copyright issue with his own BGM (and chat voice?
Boot logo Disable ? <-- <span style="text-decoration: line-through;">this is the "license text hidden" flag</span> ? FW max: 2.80 for ps3 fat? on patches?
How to test:


Boot logo Disable ? <-- <span style="text-decoration: line-through;">this is the "license text hidden" flag</span> ? FW max: 2.80 for ps3 fat? on patches?
Some flags may only be effective with some hardwares (PSP/PSVITA/[[Torne| Torne ]]/[[Nasne |Nasne]]...), FW, Games, or Category and/or in a cumulative way and others conditions.


Some flags may only be effective with some hardwares (PSP/PSVITA/[[Torne| Torne ]]/[[Nasne |Nasne]]...), FW, Games, or Category and/or in a cumulative way and others conditions.
'''Unkown flag nº21''' (not tested by myself btw, this is my understanding after decrypting ada hints :P --[[User:Sandungas|Sandungas]] ([[User talk:Sandungas|talk]]) 22:01, 4 February 2014 (EST))
*Previously proposed to be named "XMB In-Game for Software"... but "About This Game Disabled" looks a more intuitive name (note some of the other flags in the third byte of ATTRIBUTE like "Game Purchase Enabled" and "License Logo Disabled" enables/disables an option in side menu). This 3 flags could be grouped together because "About This Game" is another option in side menu, are under the third byte, and there is another unknown flag at his side that could work in a similar way (changing options in side menu)
*When activated, inside the game, and inside XMB In-Game, then trying to boot other content the warning text message is different (it mentions "software" and the variable %1 instead of "game"). In the next examples (copyed from a RCO) the first line is the normal error message and the second one is what appears with this flag enabled
<Text name="msg_need_quit_game_to_operate_ask">To perform this operation, you must quit the game. Do you want to quit the game now?</Text>
<Text name="msg_need_quit_to_operate_ask">To perform this operation, you must quit [%1]. Do you want to quit the software now?</Text>


Please report test/investigation here or on the link forum at the end of this page. 
'''ATTRIBUTE for other CATEGORY's'''
*ATRIBUTE is listed in this table: [[PARAM.SFO#SFO_Requirements_for_HDD_contents]] as valid for CATEGORY '''PP''', added by me here: http://www.psdevwiki.com/ps3/index.php?title=PARAM.SFO&diff=11171&oldid=11166 i guess it was filled with zeroes because i didnt taked note of special values. But the fact that was used there means is posible that exists specific flags for it, is also posible ATTRIBUTE is used in other CATEGORY's i missed of was added later--[[User:Sandungas|Sandungas]] ([[User talk:Sandungas|talk]]) 18:06, 4 February 2014 (EST)


*Examples
===subcategories from X0 to X7===
{| class="wikitable"
{{Boxframe0|content='''Subcategories'''<BR />
|-
X category appear (listed on game_ext_plugin.prx) as HG (sub cat)but with different parameters and need cumulative flag (n22 at least+ 4th byte: half byte)
!  Little Endian !! Big Endian !! Decimal !! Flags (Binary) !! Description || Flag Nº || Notes
The 4th byte is not used as binary (only?) but as Hex value for half byte (right nibble, left nibble is ignored?) to set X category. If the value is 0 or end up with 0, and the X maker flag is set under right SFO X parameters, X0 (PCEngine) is read by the system.
|-
| colspan="7" style="text-align:center; background-color:#DDDDDD;" | '''Discs'''
|-
| 05 17 80 00 || 00 80 17 05 || 8394501 || 00000000 10000000 00010111 00000101 || killzone 3 || 01+03+09+10+11+13+24 || all flags identifyed
|-
| 20 00 02 00 || 00 02 00 20 || 131104 || 00000000 00000010 00000000 00100000 || Dead Space 2 || 06+18 || all flags identifyed
|-
| colspan="7" style="text-align:center; background-color:#DDDDDD;" | '''Patches'''
|-
| 85 00 00 00 || 00 00 00 85 || 133 || 00000000 00000000 00000000 10000101 || Torne v3.52 || 01+03+08 || all flags identifyed (doesnt use any "overwrite" flag)
|}


====subcategories from X0 to X7====
SFO TEST Tool from Deroad can boot and return to XMB even under X category (when MINIS don t and are stuck after being X categorized, error occurred during the start operation (80010006))


X category appear as HG (sub cat)but with different parameters and need cumulative flag (n22 at least+ 4th byte: half byte)
'''Folder position in XMB ordered by format (in fw 3.55 with hand-made PARAM.SFO's):'''
The 4th byte is not used as binary (only?) but as Hexa value for half byte (right nibble, left nibble is ignored?) to set X category. If the value is 0 or end up with 0, and the X maker flag is set under right SFO X parameters, X0 (PCEngine) is read by the system.


SFO TEST Tool from Deroad can boot and return to XMB even under X category (when MINIS don t and are stuck after being X categorized)
Bootable contents installed in game column: [triangle]>[group by]: (works with square too in any item of game column)
*from dev_flash/vsh/resource/explore/xmb/registory.xml


'''Folder position in XMB (in fw 3.55 with hand-made PARAM.SFO's):'''
-format <------------- GameList:GameList.type %xCB_LIST_TYPE_GAME_FORMAT
-tag/album <--------- GameList:GameList.type %xCB_LIST_TYPE_GAME_TAGS
-all <---------------- long list of "conditionals" excluding CATEGORY's that doesnt belongs to XMB game column in the format: '''An+Game:Game.category **'''


By pressing square, group content format position (the 8 X category folders can be displayed at the same time in XMB):
By pressing square, group content format position (the 8 X category folders can be displayed at the same time in XMB):
   
   
*Playstation 3
*Mini icon: {{icon content ps3}} Playstation 3


*minis
*Mini icon: {{icon content pspremaster}} PSP Remaster, on 3.55, Mini icon: not present (-) ,not accessible (with titles inside).
*Mini icon: {{icon content pspminis}} minis


*Playstation 2
*mini icon: {{icon content psp}}PSP (Playstation portable): category PP


*Playstation
*Mini icon: {{icon content ps2}} Playstation 2


*'''X1'''
*mini icon: {{icon content ps1}}Playstation
Mini icon: not present (-)


*'''X1''' Mini icon: not present (-)
Attribute used (01 00 60 01)on EBOOT.PBP SFO for Minis (group content format on PSP: minis)
Attribute used (01 00 60 01)on EBOOT.PBP SFO for Minis (group content format on PSP: minis)
 
*'''X2''' Mini icon: not present (-)
*'''X2'''
Mini icon: not present (-)
 
When Attribute used on EBOOT.PBP SFO on PSP: NEOGEO
When Attribute used on EBOOT.PBP SFO on PSP: NEOGEO
 
*'''X0''' Mini icon:{{icon content pcengine}} '''PCEngine'''
*'''X0'''
Mini icon: '''PCEngine'''
 
Enables X category. Introduced initially as PCEngine.
Enables X category. Introduced initially as PCEngine.


Jul 15, 2009
Jul 15, 2009
Works alone and can be used with any "HG" category content, its not clear what does this flag other than the content has his own "tiny grey icon" with a "PCE" logo and are placed inside his own subfolder when ordering contents (with square button) in the XMB (3.55, 3.41?).
Works alone and can be used with any "HG" category content, its not clear what does this flag other than the content has his own "tiny grey icon" with a "PCE" logo and are placed inside his own sub-folder when ordering contents (with square button) in the XMB (3.55, 3.41?).
Same attributes on PSP
Same attributes on PSP


*'''X3'''
*'''X3''' Mini icon: not present (-) ?
Mini icon: not present (-)


*'''X4'''
*'''X4''' Mini icon:{{icon content neogeo}} '''NEOGEO'''
Mini icon: '''NEOGEO'''


Dec 21, 2010 (Few days after 3.55)
Dec 21, 2010 (Few days after 3.55)
Can be used with any "HG" category content. It has his own "tiny grey icon" with a "NEOGEO" logo and are placed inside his own subfolder when ordering contents (with square button) in the XMB (3.55, 3.41?).
Can be used with any "HG" category content. It has his own "tiny grey icon" with a "NEOGEO" logo and are placed inside his own subfolder when ordering contents (with square button) in the XMB (3.55, 3.41?).


*'''X5 (same for X6 and X7)'''
*'''X5 (same for X6 and X7)''' Mini icon: not present (-)
Mini icon: not present (-)


(X3 might have been used already, X5,X6 and X7 can be not used yet)
(X3 might have been used already, X5,X6 and X7 not used yet?)


====XMB In-game background music compatibility====
Group content order is similar on PSP for the available icons (PS3 folder being PSP and no "PS2"). See [[Talk:Eboot.PBP#Others:_PARAM.SFO_attribut_.28PSP.29]]
'''Attempt to create compatiblity list with XMB In-Game (v2) Background Music feature.'''


XMB In-Game Background Music was implemented in firmware 2.40
Other app with category not implemented yet on 3.55 FW such WT or unknown as VF on 4.21 can also just not "appear" on XMB and not being on the "Unknown" folder as Corrupted/Unsupported data. To access/delete from 3.55 XMB your PSP remaster folder s titles, group content it (not by format).
}}


Please help to improve the list. Note this is not be in corect page (if such list is appropriate) and infos on limitations are mostly speculations (and from SFO point of view) and display of the board should be improve.
*The existence of the weird flags X0 (for PCEngine) and X4 (for NeoGeo) and we called them "subcategories" (refered to the fact that are an extension of HG category) seems to be related with the fact that those emulators are running under the PSP emulator. PC Engine and NeoGeo are part of the PSP firmware


To activate it from SFO, see [[PARAM.SFO#ATTRIBUTE_In_Bootable_content]]
==APP_VER, TARGET_APP_VER, PATCH_FILE, PS3_SYSTEM_VER, VERSION (Patches)==
Lot of things to add here, maybe needs another page, but im not the best one to document how patches works
----


{| class="wikitable sortable"
|-
! Title !! compatibility!! Note
|-
| Atelier Meruru || {{No}}  || (Signed as 3.60)
|-
| Child of Eden  || {{Yes}} || PSN game, SFO edited and updated from PKG.
|-
| Uncharted 1    || {{No}}  || System FW version required 1.94
|-
|}


For better list see:[http://community.us.playstation.com/t5/PlayStation-3/Custom-Soundtrack-Compatible-PS3-PSN-Video-Games/m-p/31099592#U31099592  Custom Soundtrack Compatible list] (without SFO edited?)


Thread related: [http://www.ps3hax.net/showthread.php?t=41220 Here]
When a patch for a game (e.g: a disc game) is installed, the game boots from the "patch installation" folder, XMB loads from this folder his [[Content Information Files]], a new [[PARAM.SFO]], and a new EBOOT.BIN


For [[PARAM.SFO#Replacing_a_PARAM.SFO_manually |replacing PARAM.SFO manullay]]
After one of this installations PS3 loads both PARAM.SFO's (the "original.sfo" one from disc + the new from the "patch.sfo" folder)... some values are taken from the "original.sfo" (e.g: BOOTABLE, RESOLUTION, SOUND_FORMAT... are not present in patches)... and others are taken from the "patch.sfo" (e.g: APP_VER increases in every patch)


*Limitations:
Patches uses a system of "overwrite flag/param_key" that makes the PS3 ignore the "original.sfo" value and use the value from the "patch.sfo"... this can be used in combination with the "standard flags" (one flag indicates the value must be taken from the patch... and the other flag enables the feature)


After editing the SFO, you should not have anymore the XMB message saying "Music content cannot be played during use of this game" but instead "music will start in a while ( please insert exact xmb message). However, the feature might not work correctly (for easy display, the table report it as NO)


*Reasons (speculation):
Conflict with others system utility (E.G.:chat voice), music files or eboot compiled with old SDK or others restrictions (?)


*[[QA_Flagging#Debug_Menu_settings_not_in_Retail.2FCEX_QA | Debug Menu]]:
----
*Million dollars questions in relationship with ATTRIBUTE:
**Why ATTRIBUTE flags for patches (used to overwrite other ATTRIBUTE flags or param_key's) are placed at the third byte of ATTRIBUTE instead of first byte ?. Being an special group under CATEGORY '''GD''' they could be placed anywhere, all the other groups of flags are placed starting from top of the table represented in wiki (matching chronologicall usage/implementation of them), this is the only group of flags that doesnt starts with his first (or oldest) flag with a value of 00000000000000000000000000000001
***Is because the first and second byte of ATTRIBUTE for patches (16 flags) was used before ? (so are reserved and never was used, or used but unknown, or used but only internally) ?
***Is because the overwrite flags for patches needed to be placed in the third byte because every byte is managed by different process ? (third byte is marked in frontpage as "flags for game & software features").
***Is posible every byte is managed in a different level ? (e.g: one for vsh, other for lv2, etc...)
***Other theories ?... This is a good hint of how ATTRIBUTE flags are managed, wich part of the firmware is responsible of managing them, and if are managed as separated bytes
**When a game is booted from a disc and there is a game patch installed for this game in internall hdd, there are 2 SFO's readed (one in the disc, and another in internall hdd)... some areas from the SFO in the disc are ignored and taken from the SFO in internall hdd
***Who is the responsible of loading parts sellectivelly from each of them ?, is just by the presence of the same param_key's in the internall SFO ?. In this case the third byte of ATRIBUTE should be an exception of this rule because the ATTRIBUTE flags in the patch (overwrite flags) uses the third byte, but ATTRIBUTE flags in the disc in third byte are readed too because contains features that are not overwrited (as game purchase enabled, install packages, etc...)
***XMB database stores a copy of all PARAM.SFO's. Is posible the 2 files (SFO from disc, and SFO from his patch) are merged before indexed in database ? (or some of his values, more specifically the resulting of applying the overwrite flags from the patch)
**The process of adding or removing a flag from a previous value of ATTRIBUTE is simply a math operation with numberic values, some of the flags for patches overwrites ATTRIBUTE, but there is one that allows to overwrite Remote Play (an ATTRIBUTE flag) and RESOLUTION, SOUND_FORMAT (param_key's)... The overwriting of param_key's is a different process (not a math calculation) where the new value replaces the old value. What all them has in common is all overwrited data types (math calculations with ATTRIBUTE values or overwriting of RESOLUTION and SOUND_FORMAT) are "integer 4 bytes"
**Why overwrite Remote Play (an ATTRIBUTE flag) and RESOLUTION, SOUND_FORMAT (param_key's) are grouped together ?... This is a bit weird


====Attribute related to FW feature on newest games====
==CONTENT_ID, NP_COMMUNICATION_ID, NPCOMMID (Network and purchase features)==
Needs to be explained in another page


===CATEGORY===
==ACCOUNT_ID, PARAMS, PARAMS2, SAVEDATA_FILE_LIST, SAVEDATA_PARAMS, PADDING (security, integer special data type)==


{| class="wikitable"
All this parameters uses the data type = '''0400''' (in the SFO) named "utf8 Special Mode" in the wiki page (not used in SFX so we dont have an accurate name, consequently this "special mode" is an invented name)... seems to have the particularity of returning a "right" or "wrong" when comparing the value, so it can be said that the difference between the simple "utf8" and "utf8 Special Mode" is only from the point of view of how the system manipulate this data. There is no real explain yet why this data is marked differently and who is the responsible of processing it.
|-
!  {{icontinyphoto}} !! {{icontinymusic}} !! {{icontinyvideo}} !! {{icontinytv}} !! {{icontinygame}} !! {{icontinynetwork}} !! {{icontinypsn}} !! Tiny-Icon !! Standard name !! Source/generated by: !! Notes & Examples
|-
| || || || || VT ? || || || {{iconpsvita}} || '''PSvita''' || .PKG || Not bootable, but can be copyed to a PSvita (not confirmed). Implemented in firmware 4.00
|-
|}


VT - '''Speculation''', refered as "VT" in one his related PS3 packages: NP0001-NPXS10002_00-VTSTORELIVEAREA0.pkg
*If the "scale" used for the second byte follows the proportion of 2^X (e.g. 1, 2, 4, 8, 16, 32, etc...) then we are missing a "04 01" valid data type in the list


'''Others Category from [[XMB_database#Tables| XMB database]]'''
===PARAMS===
This table is a collection of examples of some "rare" savedatas, probably will be needed to erase this section (replaced by a resume in front page) when all areas are identifyed, but by now is usefull to have an overview of how this process works and to find good candidates for tests, feel free to add any other examples you consider interesting ;)


BV (Video, ??????)
The examples in the table are considered rare because most of the other games uses the values: 1,5,1,2,2 (2 last pointers pointing to the same counter slot 2 at 0x0C) or 1,5,1,3,3 (2 last pointers pointing to the same counter slot 3 at 0x10), so dont add this kind of games to the table because are pointless (by now the only identifyed pointers are the values at ffset 0x03 and 0x04 and the interesting examples are when this pointers are different, or when they changes his values to different numbers like 2,3 or 3,2, or any other combination of 2 different numbers, this means the SFO has several counters enabled), also the table doesnt includes the "user/console" areas that starts at offset 0x18 because are identifyed and explained in front page
VF (??????)
WT (??????)----Required System version min 3.70 - HDD contents


*PlayView (on PS3) : http://www.jp.playstation.com/playview/
The table differences 2 types of savedata, one for "profile" and other for standard "savedata", the reason is because are treated different by the system, after the first analysis it looks the profile support more features, it can evolve by changing his type, and it can store the counters from the other savedatas when SFO's are merged (this happens after completing the game)


Speculation: export function (on PSP) for some titles (but final release function have been cancel), category also on PSP & PSVITA. HDD content, FW min around 3.60+
*Notes
**Iris manager (and all his forks) has an hexeditor inside his archive manager, just navigate to the SFO press "X" and scroll down to offset 0x558 (where PARAMS area usually starts), is easy to recognize because always starts with this 1,5,1,2,2 bytes, at the next line are the 4 counters, 4 bytes length each
**To know exactly wich files has been updated inside the savedata folder is needed to look at his timestamps, iris manager doesnt displays timestamps, but you can use the FTP feature to see then from a FTP client running in a PC connected to the PS3, be sure the FTP client doesnt fool you with the timestamps, usually after a disconection/conection the old timestamps are displayed, is needed to "refresh" the files (with F5 in filezilla) or close/open the FTP client again to force it to refresh timestamps
**The system considers the savedata has been updated when the timestamp of the SFO is updated (and consequently the PFD has been updated too). But sometimes the PFD is the only file updated in the folder, in this cases the system doesnt considers the savedata has been updated. The number of times the SFO has been updated is stored in one of the counters inside PARAMS, most games loads and updates the SFO when the game boots (to be able to update his timestamp in XMB and display the last time the game was booted)


RCO used:
{| class="wikitable"
 
|-
Other videos on PS3:
! rowspan=2 | Game Title !! rowspan=2 | Savedata type !! colspan=12 | PARAMS areas (by offset) !! rowspan=2 | Notes
 
|-
*http://www.youtube.com/watch?v=5LIdPOZGoDE
! 0x0 !! 0x01 !! 0x02 !! 0x03 !! 0x04 !! 0x05 !! 0x06 !! 0x07 !! 0x08 !! 0x0C !! 0x10 !! 0x14
 
|-
'''Others: From Deroad HV dumps:'''
| untold legends || || 1 || 1 || 1 || 2 || 2 || 0 || 0 || 0 || 00000000 || 40000000 || 00000000 || 01000000 || old game, after completing the game
 
|-
  /dev_bdvd/PS3_GAME/PARAM.SFO
| venetica || profile || 1 || 1 || 1 || 2 || 3 || 0 || 0 || 0 || 00000000 || 01000000 || 02000000 || 01000000 || old game, after completing the game
/setting/system/licenseArea
|-
/dev_bdvd/PS3_GAME/L00/PARAM.SFO
| yakuza 4 || SYSTEM || 1 || 3 || 1 || 2 || 2 || 0 || 0 || 0 || 00000000 || E1010000 || 00000000 || 01000000 ||
/dev_bdvd/PS3_GAME/L01/PARAM.SFO
|-
/dev_bdvd/PS3_GAME/L02/PARAM.SFO
| yakuza 4 || CLEAR || 1 || 1 || 1 || 2 || 2 || 0 || 0 || 0 || 00000000 || 01000000 || 00000000 || 01000000 || after completing the game, needed to start a game+
/dev_bdvd/PS3_GAME/L03/PARAM.SFO
|-
/dev_bdvd/PS3_GAME/L04/PARAM.SFO
| need for speed most wanted || || 1 || 5 || 1 || 2 || 3 || 0 || 0 || 0 || 00000000 || 7A010000 || 64000000 || 01000000 ||
  /dev_bdvd/PS3_GAME/L05/PARAM.SFO
|-
 
| motogp 13 || || 1 || 5 || 1 || 3 || 3 || 0 || 0 || 0 || 00000000 || 00000000 || 16000000 || 01000000 ||
Also similar path:
|-
 
| tintin || || 1 || 5 || 2 || 2 || 2 || 0 || 0 || 0 || 00000000 || AC010000 || 00000000 || 01000000 ||
/dev_bdvd/PS3_GAME/C00/L00/PARAM.SFO
|-
/dev_bdvd/PS3_GAME/C00/L01/PARAM.SFO
| prince of persia sands of time || || 1 || 5 || 1 || 2 || 2 || 0 || 0 || 0 || 00000000 || FF000000 || 00000000 || 01000000 ||
...
|-
/dev_bdvd/PS3_GAME/C00/L05/PARAM.SFO
| prince of persia sands of time || || 1 || 5 || 2 || 2 || 2 || 0 || 0 || 0 || 00000000 || E6000000 || 00000000 || 01000000 ||
 
|-
 
| the last of us || profile || 1 || 7 || 1 || 3 || 3 || 0 || 0 || 0 || 00000000 || 00000000 || 01000000 || 01000000 || new profile savedata, no previous savedatas
====DISC structures====
|-
XI - '''Confirmed''' ---> '''System File for Extra Content Item''' , related to another disc structure, related with folders EX_GAME & EX_VIDEO ?
| the last of us || profile || 1 || 8 || 1 || 3 || 3 || 0 || 0 || 0 || 00000000 || 00000000 || 02000000 || 01000000 || boot game, quit game (see examples below)
|-
| the last of us || profile || 1 || 7 || 1 || 3 || 3 || 0 || 0 || 0 || 00000000 || 00000000 || 97000000 || 01000000 || after completing the game
|-
| the last of us || save || 1 || 2 || 1 || 3 || 3 || 0 || 0 || 0 || 00000000 || 00000000 || 21000000 || 01000000 || after completing the game
|-
| tomb raider || profile || 1 || 5 || 1 || 3 || 3 || 0 || 0 || 0 || 00000000 || 00000000 || 01000000 || 01000000 || new profile savedata, no previous savedatas
|-
| tomb raider || save || 1 || 5 || 1 || 3 || 3 || 0 || 0 || 0 || 00000000 || 00000000 || 01000000 || 01000000 || new game savedata, no previous savedatas
|-
| tomb raider || profile || 1 || 5 || 1 || 2 || 3 || 0 || 0 || 0 || 00000000 || 91000000 || 14000000 || 01000000 || after completing the game
|}


===Subfolders structures===
*Tests examples
**The last of us ---> http://pastebin.com/raw.php?i=SAiDzjLN (overall save behaviour with the profile, identifying update counter)
***the game loads and updates the profile in every boot (by only updating the SFO timestamp and consequently the PFD), and changes the value at offset 0x01 to 8
***when the user changes some option or forces the save the value at offset 0x01 is changed to 7
***the profile is updated 1 time for every submenu inside "options" (there are 5 submenues under options)
***every time the SFO is updated, the counter at 0x10  increases 1 unit
**tomb raider ------> http://pastebin.com/raw.php?i=S13yrq9R (overall save behaviour with profile and save, update counter, timestamps, failed attempt to increase the game completion counter at offset 0x564)
***every time the game boots, only the PFD is updated (no other file is updated)
***When the savedata is updated all the files inside the folder are updated (included ICON0.PNG timestamp)
***the profile is updated 1 time for every submenu under options, and another time when exiting options (3 submenues + 1 when exiting options for a total of 4 updates)
***the profile is updated 1 time when exiting extras
***every time the SFO is updated, the counter at 0x10  increases 1 unit
***when the game is completed a new counter is added to the profile savedata, and the pointer at offset 0x03 changes to a new counter slot (from slot 3 to slot 2), the new value stored in counter slot 2 is partially unknown but seems to be another counter taken from the SFO of the save used to finish the game


*PS3_GAME/CROSSDIR/DATA000.SIG (FW min 4.20)
==SAVEDATA_LIST_PARAM==
'''Example of SAVEDATA_LIST_PARAM containing the "folder size in sectors" in the gamesaves generated by the game "The Orange Box: BLES00153, BLES00171, BLES00172, BLUS30055"'''
{{Boxframe1|content='''Game Selector Boot Process'''
When the disc boots, the EBOOT.BIN loads APP_CHOOSER.SELF, is a "game selector" and contains 5 games: half life 2, half life 2ep1, half life 2ep2, Portal, and Team fortress 2


used for cross controller function with PS VITA (FW 1.80):
Each of this games has his own .SELF and his own SAVECONTENTPS3 folder (each game uses different [[Content_Information_Files#Saved_Data_Utility_.28PS3.29 | Content Information Files]] when generating his savedata). There is another savedata folder generated/loaded by the selector that is common. In some games (e.g: portal 1) there are several savedata folders to store: the "game settings", "autosave", and "manual save"


http://uk.ign.com/articles/2012/06/05/e3-2012-vitaps3-cross-controller-coming-this-year
All the PARAM.SFO's generated in this savedata folders contains SAVEDATA_LIST_PARAM with a '''param_len''' of 7 bytes, and his values are strings of 6 numbers + a zero (NULL terminated)
}}


(for Cross buy: http://uk.ign.com/articles/2012/08/14/buy-ps3-playstation-all-stars-get-vita-version-for-free
The value stored by this game in SAVEDATA_LIST_PARAM is the "size of the folder on disk". This size is dependant of the filesystem (512 bytes cluster size in UFS2), and how many clusters are taken as the "minimun chunk" (that seems to be 2 clusters)


*HTMLDIR, INSDIR, LICDIR, PKGDIR, SHOPDIR, TRPDIR, USRDIR
Because the writing process standards (and from the point of view of available clusters for the next writing operation) when a single byte is used in a cluster, this whole cluster is considered "not available for next writing process of a new file". This means e.g: that a file with a size 513 bytes uses 2 complete clusters (512 bytes in the first cluster and 1 byte in the second cluster, both clusters are reserved for this file)


===DATA types===
To calculate the number of clusters used by a folder... is needed to calculate the number of clusters used by each file inside the folder, this includes the files that uses a number of clusters that is not even and needs to be "rounded-up". e.g: a file with size 1 byte (that is supposed to fit in 1 cluster) uses 2 clusters because the number "1" is not even. In few words, the number of clusters used by a file needs to be "rounded-up to next even number"


*This save game is a good example because always contains the same values in SAVEDATA_LIST_PARAM (the second one from euro region): BLES00153-PORCONF-0 [[http://www.gamefaqs.com/ps3/934385-the-orange-box/saves Link 1]] [[http://db.gamefaqs.com/console/ps3/save/the_orange_box_eu.zip Link 2]]
{| class="wikitable"
{| class="wikitable"
|-
|-
! Data_Type !! Description !! Used in
! File name !! real file size (in bytes) !! theorical disk size (in clusters) !! cluster round-up to even number !! real disk size (in bytes)
|-
| ICON0.PNG || 12.461 || 12461/512=24,3... = 25 || 25+1= 26 || 26*512= 13.312
|-
| PARAM.PFD || 32.768 || 32768/512= 64 || || 64*512= 32.768
|-
| PARAM.SFO || 2.736 || 2736/512=5,3... = 6 || || 6*512= 3.072
|-
| PIC1.PNG || 89.268 || 89268/512=174,3... = 175 || 175+1= 176 || 176*512= 90.112
|-
| POR-0.CFG || 893 || 893/512=1,7... = 2 || || 2*512= 1.024
|-
| POR-0.CHK || 16 || 16/512=0,03... = 1 || 1+1= 2 || 2*512= 1.024
|-
|-
| 04 00 || style="background-color:#00DDDD;" | utf-8 Special Mode || Data generated by the system: '''Game Saves''' (ACCOUNT_ID, PARAMS, PARAMS2, SAVEDATA_FILE_LIST, SAVEDATA_PARAMS)... and '''Trophies''' (PADDING)
!! colspan="5" | Folder contents total
|-
| || 138.142 || 273 clusters || 276 clusters || '''141312''' (SAVEDATA_LIST_PARAM)
|-
|-
|}
|}
*The process is:
**1.- Divide by the cluster size
**2.- Round-up cluster number (if needed)
**3.- Multiply by the same cluster size (to know the amount of bytes reserved for this clusters)


The '''Data_Type''' = '''0400''' marked as "utf-8 Special Mode" has the particularity of return a "right" or "wrong" when comparing the string with a reference value, so it can be said that the difference between the simple "utf-8" and "utf-8 Special Mode" is only from the point of view of how the system manipulate this data. For more info read the section [[#ACCOUNT_ID|ACCOUNT_ID]].
This can be simplifyed by using 1024 (2 clusters)... because this way there is no need of step 2 (the "round-up")... but i have no idea if naming this "chunk" of 2 clusters a "page"... or why UFS2 filesystem takes them 2 by 2... i prefer to left this example as is, feel free to correct me


If the "scale" used for the second byte follows the proportion of 2^X (e.g. 1, 2, 4, 8, 16, 32, etc...) then we are missing a "04 01" valid data type in the list
Also, there is a simple "trick" that can be used to display the files divided in clusters of the size you want (maybe are others but this is the faster way i found). By formatting a usb pendrive in advanced mode, using the cluster size your need, then moving the folder there (by using FAT32 with 1024 bytes cluster the value reported by your operative system is the same one stored inside SAVE_DATA_LIST)


====Cryptography in "user files" (game saves & trophies)====
*PARAM.PFD relationship ?
ACCOUNT_ID, PADDING, PARAMS, PARAMS2, SAVEDATA_FILE_LIST, SAVEDATA_PARAMS


====PARAM.PFD relationship====
=Other parameters not used in PS3 (only used in other sony consoles)=
The only purpose of this table is to keep a record of them to not confuse with the ones used in PS3


===Firmware 3.56+ features speculation/contents===
{| class="wikitable" style="font-size:x-small"
 
|-
*PSvita Remote play improvements announced for ICO
! rowspan=2 | Parameter !! colspan=3 | Console !! rowspan=2 | Notes
Shehui Yoshida tweeted a picture of Ico HD running on a Playstation Vita ---> ''Sorry to tease you, I was play testing ICO HD Remote Play on PS Vita. We are almost ready with a patch. Beautiful on OLED. More info soon.'' ---> http://www.justpushstart.com/2012/09/remote-play-vita-patch-coming-will-allow-ico-hd-to-be-played/ - https://twitter.com/yosp/status/242529590860451840
|-
 
! PSP !! [http://www.psdevwiki.com/vita/index.php?title=Talk:System_File_Object_%28SFO%29_%28PSF%29 PSV] !! [http://www.psdevwiki.com/ps4/Param.sfo PS4]
*New content found in 4.21 XMB (PlayStation Mobile)
|-
explore_plugin_full\Text\English.xml (inside explore_plugin_full.rco)
| DISC_ID || {{Yes}} || || ||
  <Text name="msg_applications_psm">Applications (PlayStation®Mobile)</Text>
|-
 
| DISC_NUMBER || {{Yes}} || || {{Yes}} ||
*Possible "flags" managed by ATTRIBUTE that enables "features" over 3.55 firmware
|-
**keyboard/mouse support (in one of the patches of game "DUST 514") ---> http://gamescatalyst.com/2012/08/ps3-users-to-make-contact-with-their-pc-neighbours-as-dust-514-migrates-to-eve-onlines-servers/
| DISC_TOTAL || {{Yes}} || || {{Yes}} ||
 
|-
*7.1 virtual surround (in SOUND_FORMAT) sound mode has been announced officially, it will be implemented in the next firmware (aparently version 4.20). This sound mode will need one (or two) new flags for being activated in games
| DISC_VERSION || {{Yes}} || || ||
 
|-
Blu-ray disc movies supports "virtual surround 7.1" time ago, no problem with them, but there are 2 ways to implement this in games:
| DRIVER_PATH || {{Yes}} || || ||
 
|-
-By using the LPCM 7.1 channels and aplying digital filters (this way the old games that contains LPCM 7.1 separated channels can use it by converting this channels to 7.1 virtual surround)
| GAMEDATA_ID || {{Yes}} || || || Used in some PSP UMD games, found in [[game_ext_plugin]].sprx
 
|-
-Or by adding new sound channels in the game files, (actually there is no PS3 game with them)
| HRKGMP_VER || {{Yes}} || || ||
 
|-
This give us one (for the "native" support") or two (another for the dgital filter conversor) flags... there is no point in speculate wich one can be, but seems obvious one of them will be this one:
| REGION || {{Yes}} || || ||
 
|-
 
| USE_USB || {{Yes}} || || ||
{| class="wikitable"
|-{{cellcolors|red}}
| ACCOUNT_ID ||  || {{Yes}} || || Not the same ACCOUNT_ID than PS3... this one for vita has  (fmt:utf8-S, len:0x8, max_len:0x8)
|-
| ATTRIBUTE2 ||  || {{Yes}} || ||
|-
| ATTRIBUTE_MINOR ||  || {{Yes}} || ||
|-
| GC_RO_SIZE || || {{Yes}} || || GameCache ReadOnly Size ?
|-
| GC_RW_SIZE || || {{Yes}} || || GameCache ReadWrite Size ?
|-
| INSTALL_DIR_ADDCONT ||  || {{Yes}} || || Shared Additional Content, fmt:utf-8, max_len:12
|-
| INSTALL_DIR_SAVEDATA ||  || {{Yes}} || || Shared Save Data, fmt:utf-8, max_len:12
|-
| PARENT_DIRECTORY ||  || {{Yes}} || || used in PSvita savedata (fmt:utf8, len:0xB, max_len:0x40)
|-
| PSP2_DISP_VER || || {{Yes}} || || utf-8, max_len:8, example: "00.000"
|-
| PSP2_SYSTEM_VER ||  || {{Yes}} || || int32
|-
| PUBTOOLINFO ||  || {{Yes}} || {{Yes}} ||
|-
| SAVEDATA_MAX_SIZE || || {{Yes}} || || int32
|-
| SAVEDATA_VER ||  || {{Yes}} || || used in PSvita savedata (fmt:utf8, len:0x6, max_len:0x8)
|-
| STITLE ||  || {{Yes}} || || App Short Title, utf-8, len:52
|-
| STITLE_xx ||  || {{Yes}} || ||
|-
| SUPPORT_URI ||  || {{Yes}} || ||
|-
| APP_TYPE ||  ||  || {{Yes}} ||
|-
| CONTENT_VER ||  ||  || {{Yes}} ||
|-
| DISP_LOCATION_x ||  ||  || {{Yes}} ||
|-
| DOWNLOAD_DATA_SIZE ||  ||  || {{Yes}} ||
|-
| FORMAT ||  ||  || {{Yes}} ||
|-
| INSTALL_DIR_SAVEDATA ||  ||  || {{Yes}} ||
|-
| IRO_TAG ||  ||  || {{Yes}} ||
|-
| PROVIDER ||  ||  || {{Yes}} ||
|-
| PROVIDER_xx ||  ||  || {{Yes}} ||
|-
| PUBTOOL_VERSION ||  ||  || {{Yes}} ||
|-
| REMOTE_PLAY_KEY_ASSIGN ||  ||  || {{Yes}} ||
|-
| SERVICE_ID_ADDCONT_ADD_x ||  ||  || {{Yes}} ||
|-
| SYSTEM_ROOT_VER ||  ||  || {{Yes}} ||
|-
| SYSTEM_VER ||  ||  || {{Yes}} ||
|-
| USER_DEFINED_PARAM_x ||  ||  || {{Yes}} ||
|-
| SUB_TITLE_ID || || || ||
|-
| CONTENT_URL ||  || || || URL of content (not parameter but related to link.xml?)
|-
| _PARAM.SFO || ? || || || found in [[game_ext_plugin]].sprx (anti exploit/bug prevention ?)
|-
| __PARAM.SFO || ? || || || found in [[game_ext_plugin]].sprx (anti exploit/bug prevention ?)
|-
| /PARAM.SFO || ? || || || found in [[game_ext_plugin]].sprx (anti exploit/bug prevention ?)
|-
| FOLDER_NAME || || || || found in [[game_ext_plugin]].sprx
|-
|-
!  Little Endian !! Big Endian !! Decimal !! Binary (Flags) !! Description !! Flag Nº !! Requires Flag Nº
| FOLDER_NAME_00 || || || || found in [[game_ext_plugin]].sprx
|-
|-
| 00 04 00 00 || 00 00 04 00 || 1024 || 00000000 00000000 00000100 00000000 || [[http://en.wikipedia.org/wiki/7.1_surround_sound Virtual Surround]] 7.1 || 11 || 02
|}
|}


Expect to see this new flag in the game patches released after 4.20... mostly the games from companyes property of sony (e.g: uncharted, killzone, god of war, etc...). Be aware of it and catch them all !!!
=DISC contents temporal installations (in dev_hdd0/tmp)=
 
'''/dev_hdd0/tmp/disc_install/'''
===Emulators specific parameters/flags===
ANALOG_MODE, ITEM_PRIORITY, & specific values for RESOLUTION


====ITEM_PRIORITY====
=Reserved Folder Names used in HDD or disc contents=
Data_Type: integer
Data_Size_Total: 4 (0x4)
Data_Size_Used: 4 (0x4)
Used by: PS2 Disc Game


Used only in category "2G" for "PS2 game discs" that can be installed in the PS3 internal HDD. Always filled with zeroes in the examples found
==L00 up to L05 (License Area subfolders with restricted .SFO's)==


*Speculation
*From dev_bdvd: ?
Related with features of the PS2 emulator like hardware emulation priority ?
/dev_bdvd/PS3_GAME/L00/PARAM.SFO (up to L05)
Related with PS2 virtual HDD images (IMAGE.DAT) ?
/dev_bdvd/PS3_GAME/C00/L00/PARAM.SFO (up to L05)


====RESOLUTION====
*From dev_hdd0:
Data_Type: uint32_t
  /dev_hdd0/game/ABCD12345/Lxx/PARAM.SFO
Data_Size_Total: 4 bytes
  /dev_hdd0/game/ABCD12345/C01/Lxx/PARAM.SFO ---only working if region setting is L03 country (only other tested: L00 not working)
  Data_Size_Used: 4 bytes
  Used by: HDD Game, PS1 Classics Game, Minis Game, PSP Remasters Game


TV video modes supported by the content.
Speculation: Path used to restrict/use different License in the same region (L03?).


When there are several flags activated the PS3 will use the one with higher quality supported by the TV.
You can quickly check your region area with this sub folder (and inserting content file informations such ICON0). L** path can avoid error some code related to param.sfo/disc.sfo.


{| class="wikitable"
{| class="wikitable"
! Folder name !! License Area !! Regions
|-
|-
!  Little Endian !! Big Endian !! Decimal !! Binary (Flags) !! Description
| L00 || SCEJ || Japan
|-
| 01 00 00 00 || 00 00 00 01 || 1 || 00000000 00000000 00000000 00000001 || 480  (4:3)
|-
| 02 00 00 00 || 00 00 00 02 || 2 || 00000000 00000000 00000000 00000010 || 576  (4:3)
|-
| 04 00 00 00 || 00 00 00 04 || 4 || 00000000 00000000 00000000 00000100 || 720  (16:9)
|-
|-
| 08 00 00 00 || 00 00 00 08 || 8 || 00000000 00000000 00000000 00001000 || 1080 (16:9)
| L01 || SCEA || US (L01), Canada (North America), Mexico (L01), Central America, South America
|-
|-
| 10 00 00 00 || 00 00 00 10 || 16 || 00000000 00000000 00000000 00010000 || 480  (16:9)
| L02 || SCEE || Europe/Middle East/Africa, U.K./Ireland, Australia/New Zealand (Oceania: L02), Russia, Ukraine, India, Central Asia ,
|-
|-
| 20 00 00 00 || 00 00 00 20 || 32 || 00000000 00000000 00000000 00100000 || 576  (16:9)
| L03 || SCEH || Singapore/Malaysia (Southeast Asia)?, Taiwan (L03), Hong Kong (L03)
|-
|-
| colspan="5" style="text-align:center; background-color:#DDDDDD;" | Examples
| L04 || SCEK || Korea (South Korea)
|-
|-
| 3F 00 00 00 || 00 00 00 3F || 63 || 00000000 00000000 00000000 00111111 || All video modes supported
| L05 || SCH  || China
|-
|-
|}
|}


*Note the resolution for originall PS1 disc games can vary (See: [[Emulation#Resolution|Emulation Resolution]]). The RESOLUTION flags used in PARAM.SFO's of "PS1 Classics Game" from PSN seems to be specific and not fixed sizes (e.g: 01 00 00 00). This will need another table if more are found
(Unlinked Note: Button Behavior: for L05 is also O , Oceania is X. Path Pioneer with significant idea about it: Deroad)
 
===Patches===
APP_VER, TARGET_APP_VER, PS3_SYSTEM_VER, VERSION
lot of things to add here, maybe needs another page, but im not the best one to document them


==== PS3_SYSTEM_VER ====
You can load different Lxx folder by using [[QA_Flagging#Debug_Menu_settings_not_in_Retail.2FCEX_QA | Debug Menu Setting Region]] but be alert about your TV setting display video (NTSC/PAL).


This is the flag for what's the minimum firmware a game will run on. It is 0x8 bytes and is only found it Gamedata SFO files, not gamesaves (most of them atleast).  
Here is a collection of folders (from L00 to L10) with icons displaying the different numbers, this way is easy to know which one is used by XMB, to make the test just copy the folders next to USRDIR folder inside the installation folder of any app: '''region subfolders tests.zip (430.22KB)''' http://www.sendspace.com/file/ikvult


[[File:PS3_SYSTEM_VER.png]]
See also: "license area" restrictions used in combination with "parental level" http://www.ps3devwiki.com/wiki/Talk:PARAM.SFO#Lxx:_License_Area


This can be changed to run on other firmwares.
==EX_GAME and EX_VIDEO==


===Purchase content===
*Theory 1:
CONTENT_ID, NP_COMMUNICATION_ID, NPCOMMID
**Belongs to PS3_CONTENT disc substructure (same than THEMEDIR & VIDEODIR)
**StorageMedia:Common.fileName EX_GAME <--- Mounted by XMB in game column using key="seg_add_content_device" see: http://www.ps3devwiki.com/wiki/XMB-Game
**StorageMedia:Common.fileName EX_VIDEO <--- Mounted by XMB in video column using key="seg_add_content_device" see: http://www.ps3devwiki.com/wiki/XMB-Video


*Theory 2:
**EX_GAME & EX_VIDEO requires SFO Category 'XR' and are emerged into PS3_EXTRA! (EX_GAME/EX_VIDEO are actually leftovers?)


==To Do==
==Others==
There are lot of "yes" in the parameters table that in fact are optional "opt". The "yes" means the value is mandatory, so the table is not fully correct, it needs to add a lot more "opt" in the paces of the "yes"


Also... this table represents the values needed for each content ordered by CATEGORY, but there are different contents that shares the same CATEGORY (like the different types of patches, DLC's, and game installations... alll them uses "'''GD'''"
-GE
PS3 DVD / PS2 CD
/dev_bdvd/NORMAL
/dev_bdvd/HYBRID


The "parameter table" cant contain all this different variations, by now i dont see a way to do it
-GP
/dev_bdvd/PHOTODIR
/dev_bdvd/PS3_CONTENT/PHOTODIR
/dev_bdvd/PS3_CONTENT/PHOTODIR/PARAM.SFO


----
-GM
/dev_bdvd/MUSICDIR
/dev_bdvd/PS3_CONTENT/MUSICDIR
/dev_bdvd/PS3_CONTENT/MUSICDIR/PARAM.SFO


==Suggestions==
-GV
/dev_bdvd/VIDEODIR
/dev_bdvd/PS3_CONTENT/VIDEODIR
/dev_bdvd/PS3_CONTENT/VIDEODIR/PARAM.SFO


*About specifics way of using Parameters: License and TITLE_ID can be kept (some homebrew not using the same format) for the psl1ght/homebrew achievement/part (or it s remove to main page as specific example)
-GT
The structure in C also.
/dev_bdvd/THEMEDIR
/dev_bdvd/PS3_CONTENT/THEMEDIR
/dev_bdvd/PS3_CONTENT/THEMEDIR/PARAM.SFO


*Others param.sfo specifics parameters of PSP eboot.PBP (but i prefer not, and add them to the .pbp page or main page), and PSVITA can be here?
=Todo and Suggestions=
*'''Parameters requirements table''' has lot of "yes" that should be "opt" (optional). The "yes" means the value is mandatory, so the table is not fully correct.Also... this table represents the values needed for each content ordered by CATEGORY, but there are different contents that shares the same CATEGORY (like the different types of patches, DLC's, and game installations... alll them uses "'''GD'''". The "parameter table" cant contain all this different variations, by now i dont see a way to do it--[[User:Sandungas|Sandungas]] ([[User talk:Sandungas|talk]]) 12:25, 29 January 2014 (EST)
*The internal structure example for SFO needs to be replaced by a new one with at least 2 parameters, this will make more obvious how are meassured the relative offsets displacements
*Is needed an explain of how the file is loaded in stages by the system, how is indexed, and the method to access single areas to update single values, the rebuilding process, etc... this is complex and i ignore (but i imagine) how is made by the PS3, but the source codes i saw that manages SFO files uses different methods and styles (and probably some others i ignore), by now im not skilled enought to discuss this in the page but an open talk about all this could be interesting --[[User:Sandungas|Sandungas]] ([[User talk:Sandungas|talk]]) 23:41, 15 February 2014 (EST)
*'''Overall page cleanup''' of obsolete or wrong info, grammar corrections, etc...
*'''Link each ID to a subpage''', so they can be centrally managed (some are also listed here: [[IDs_%2B_labels | ID's and labels]]
**The affected sections in front page are: [[PARAM.SFO#CONTENT_ID|CONTENT_ID]], [[PARAM.SFO#NP_COMMUNICATION_ID|NP_COMMUNICATION_ID]], [[PARAM.SFO#NPCOMMID|NPCOMMID]], and [[PARAM.SFO#TITLE_ID|TITLE_ID]], explaining them in the .SFO page (as i did initially) doesnt looks the best solution, but is needed at least a short description of each, now there are specific pages for them (without much descriptions) and the decission of separating all the IDs in pages makes hard to have a overall view of them... the best solution i see is to use the [[IDs_%2B_labels | ID's and labels]] converted to a template an use it repeatedly in SFO page, but the names are not the same used in SFO, also this doesnt solves the short description needed in SFO page (that should be duplicated, and expanded in his specific pages)--[[User:Sandungas|Sandungas]] ([[User talk:Sandungas|talk]]) 12:25, 29 January 2014 (EST)

Latest revision as of 18:00, 13 March 2024

Unknown or new parameters[edit source]

This page is an index/worklog/notepad with sections referred to the front page. All the sections in this page are things related with PARAM.SFO that are not completely documented, and the final purpose is to move the info when completed to the front page. This also will help to keep the front page free of speculation.

CATEGORY (new content formats)[edit source]

  • CATEGORY VF - (HDD content, NOT in game column) ---> unknown name, used as a valid category filter in the XML configuration file for XMB game column in path: dev_flash/vsh/resource/explore/xmb/category_game.xml in key="gameDir"
    • key="gameDir" is an XMB item that allows to order the contents by "rating" or "timeCreated" the command used contains a list of categories that are excluded using the operator "An" = An not equal (VF is at the end of the list excluded with An+Game:Game.category VF)
    • Similar than MN, 1P?
  • CATEGORY XI - Confirmed ---> System File for Extra Content Item (or eXtra Item in short form) Used on blu ray structure?

Indi games has a specific license, if XMB differences it it will be using ATTRIBUTE flags (similar identification than neogeo and pcengine because has a special license)

  • PlayStation Mobile Implemented around 4.21 firmware, asociated with a text string in explore_plugin_full\Text\English.xml (inside explore_plugin_full.rco). See [PS3 and PSVita Cross Functions]
<Text name="msg_applications_psm">Applications (PlayStation®Mobile)</Text>

ATTRIBUTE (flags brainstorming)[edit source]

XMB In-Game System Chat Voice Disable (Flag Nº7) : Value and name description are related to this flag but need to be confirmed from PS3 side / not used on bootable but as patches?.

Function to disable system chat voice utility (xmb/friend/start new chat appear when PSN connected) (implemented directly on FW or game or as flag into param.sfo for short period?) e.g. of this function: PlayStation Home 1.4 after people reported chat voice disturbance(?) , LittleBigPlanet 2.

Kept as flag for convenience (to disable per game through update game and not FW) but can be "system reminiscent" and not working anymore from param.sfo?

Boot logo Disable ? <-- this is the "license text hidden" flag ? FW max: 2.80 for ps3 fat? on patches?

Some flags may only be effective with some hardwares (PSP/PSVITA/ Torne /Nasne...), FW, Games, or Category and/or in a cumulative way and others conditions.

Unkown flag nº21 (not tested by myself btw, this is my understanding after decrypting ada hints :P --Sandungas (talk) 22:01, 4 February 2014 (EST))

  • Previously proposed to be named "XMB In-Game for Software"... but "About This Game Disabled" looks a more intuitive name (note some of the other flags in the third byte of ATTRIBUTE like "Game Purchase Enabled" and "License Logo Disabled" enables/disables an option in side menu). This 3 flags could be grouped together because "About This Game" is another option in side menu, are under the third byte, and there is another unknown flag at his side that could work in a similar way (changing options in side menu)
  • When activated, inside the game, and inside XMB In-Game, then trying to boot other content the warning text message is different (it mentions "software" and the variable %1 instead of "game"). In the next examples (copyed from a RCO) the first line is the normal error message and the second one is what appears with this flag enabled
<Text name="msg_need_quit_game_to_operate_ask">To perform this operation, you must quit the game. Do you want to quit the game now?</Text>
<Text name="msg_need_quit_to_operate_ask">To perform this operation, you must quit [%1]. Do you want to quit the software now?</Text>

ATTRIBUTE for other CATEGORY's

subcategories from X0 to X7[edit source]

Subcategories

X category appear (listed on game_ext_plugin.prx) as HG (sub cat)but with different parameters and need cumulative flag (n22 at least+ 4th byte: half byte) The 4th byte is not used as binary (only?) but as Hex value for half byte (right nibble, left nibble is ignored?) to set X category. If the value is 0 or end up with 0, and the X maker flag is set under right SFO X parameters, X0 (PCEngine) is read by the system.

SFO TEST Tool from Deroad can boot and return to XMB even under X category (when MINIS don t and are stuck after being X categorized, error occurred during the start operation (80010006))

Folder position in XMB ordered by format (in fw 3.55 with hand-made PARAM.SFO's):

Bootable contents installed in game column: [triangle]>[group by]: (works with square too in any item of game column)

*from dev_flash/vsh/resource/explore/xmb/registory.xml
-format <------------- GameList:GameList.type %xCB_LIST_TYPE_GAME_FORMAT
-tag/album <--------- GameList:GameList.type %xCB_LIST_TYPE_GAME_TAGS
-all <---------------- long list of "conditionals" excluding CATEGORY's that doesnt belongs to XMB game column in the format: An+Game:Game.category **

By pressing square, group content format position (the 8 X category folders can be displayed at the same time in XMB):

  • Mini icon: PS3 icon Playstation 3
  • Mini icon: PSP Remaster icon PSP Remaster, on 3.55, Mini icon: not present (-) ,not accessible (with titles inside).
  • Mini icon: PSP Minis icon minis
  • mini icon: PSP iconPSP (Playstation portable): category PP
  • Mini icon: PS2 icon Playstation 2
  • mini icon: PS1 iconPlaystation
  • X1 Mini icon: not present (-)

Attribute used (01 00 60 01)on EBOOT.PBP SFO for Minis (group content format on PSP: minis)

  • X2 Mini icon: not present (-)

When Attribute used on EBOOT.PBP SFO on PSP: NEOGEO

  • X0 Mini icon:PCEngine icon PCEngine

Enables X category. Introduced initially as PCEngine.

Jul 15, 2009 Works alone and can be used with any "HG" category content, its not clear what does this flag other than the content has his own "tiny grey icon" with a "PCE" logo and are placed inside his own sub-folder when ordering contents (with square button) in the XMB (3.55, 3.41?). Same attributes on PSP

  • X3 Mini icon: not present (-) ?
  • X4 Mini icon:NeoGeo icon NEOGEO

Dec 21, 2010 (Few days after 3.55) Can be used with any "HG" category content. It has his own "tiny grey icon" with a "NEOGEO" logo and are placed inside his own subfolder when ordering contents (with square button) in the XMB (3.55, 3.41?).

  • X5 (same for X6 and X7) Mini icon: not present (-)

(X3 might have been used already, X5,X6 and X7 not used yet?)

Group content order is similar on PSP for the available icons (PS3 folder being PSP and no "PS2"). See Talk:Eboot.PBP#Others:_PARAM.SFO_attribut_.28PSP.29

Other app with category not implemented yet on 3.55 FW such WT or unknown as VF on 4.21 can also just not "appear" on XMB and not being on the "Unknown" folder as Corrupted/Unsupported data. To access/delete from 3.55 XMB your PSP remaster folder s titles, group content it (not by format).
  • The existence of the weird flags X0 (for PCEngine) and X4 (for NeoGeo) and we called them "subcategories" (refered to the fact that are an extension of HG category) seems to be related with the fact that those emulators are running under the PSP emulator. PC Engine and NeoGeo are part of the PSP firmware

APP_VER, TARGET_APP_VER, PATCH_FILE, PS3_SYSTEM_VER, VERSION (Patches)[edit source]

Lot of things to add here, maybe needs another page, but im not the best one to document how patches works



When a patch for a game (e.g: a disc game) is installed, the game boots from the "patch installation" folder, XMB loads from this folder his Content Information Files, a new PARAM.SFO, and a new EBOOT.BIN

After one of this installations PS3 loads both PARAM.SFO's (the "original.sfo" one from disc + the new from the "patch.sfo" folder)... some values are taken from the "original.sfo" (e.g: BOOTABLE, RESOLUTION, SOUND_FORMAT... are not present in patches)... and others are taken from the "patch.sfo" (e.g: APP_VER increases in every patch)

Patches uses a system of "overwrite flag/param_key" that makes the PS3 ignore the "original.sfo" value and use the value from the "patch.sfo"... this can be used in combination with the "standard flags" (one flag indicates the value must be taken from the patch... and the other flag enables the feature)



  • Million dollars questions in relationship with ATTRIBUTE:
    • Why ATTRIBUTE flags for patches (used to overwrite other ATTRIBUTE flags or param_key's) are placed at the third byte of ATTRIBUTE instead of first byte ?. Being an special group under CATEGORY GD they could be placed anywhere, all the other groups of flags are placed starting from top of the table represented in wiki (matching chronologicall usage/implementation of them), this is the only group of flags that doesnt starts with his first (or oldest) flag with a value of 00000000000000000000000000000001
      • Is because the first and second byte of ATTRIBUTE for patches (16 flags) was used before ? (so are reserved and never was used, or used but unknown, or used but only internally) ?
      • Is because the overwrite flags for patches needed to be placed in the third byte because every byte is managed by different process ? (third byte is marked in frontpage as "flags for game & software features").
      • Is posible every byte is managed in a different level ? (e.g: one for vsh, other for lv2, etc...)
      • Other theories ?... This is a good hint of how ATTRIBUTE flags are managed, wich part of the firmware is responsible of managing them, and if are managed as separated bytes
    • When a game is booted from a disc and there is a game patch installed for this game in internall hdd, there are 2 SFO's readed (one in the disc, and another in internall hdd)... some areas from the SFO in the disc are ignored and taken from the SFO in internall hdd
      • Who is the responsible of loading parts sellectivelly from each of them ?, is just by the presence of the same param_key's in the internall SFO ?. In this case the third byte of ATRIBUTE should be an exception of this rule because the ATTRIBUTE flags in the patch (overwrite flags) uses the third byte, but ATTRIBUTE flags in the disc in third byte are readed too because contains features that are not overwrited (as game purchase enabled, install packages, etc...)
      • XMB database stores a copy of all PARAM.SFO's. Is posible the 2 files (SFO from disc, and SFO from his patch) are merged before indexed in database ? (or some of his values, more specifically the resulting of applying the overwrite flags from the patch)
    • The process of adding or removing a flag from a previous value of ATTRIBUTE is simply a math operation with numberic values, some of the flags for patches overwrites ATTRIBUTE, but there is one that allows to overwrite Remote Play (an ATTRIBUTE flag) and RESOLUTION, SOUND_FORMAT (param_key's)... The overwriting of param_key's is a different process (not a math calculation) where the new value replaces the old value. What all them has in common is all overwrited data types (math calculations with ATTRIBUTE values or overwriting of RESOLUTION and SOUND_FORMAT) are "integer 4 bytes"
    • Why overwrite Remote Play (an ATTRIBUTE flag) and RESOLUTION, SOUND_FORMAT (param_key's) are grouped together ?... This is a bit weird

CONTENT_ID, NP_COMMUNICATION_ID, NPCOMMID (Network and purchase features)[edit source]

Needs to be explained in another page

ACCOUNT_ID, PARAMS, PARAMS2, SAVEDATA_FILE_LIST, SAVEDATA_PARAMS, PADDING (security, integer special data type)[edit source]

All this parameters uses the data type = 0400 (in the SFO) named "utf8 Special Mode" in the wiki page (not used in SFX so we dont have an accurate name, consequently this "special mode" is an invented name)... seems to have the particularity of returning a "right" or "wrong" when comparing the value, so it can be said that the difference between the simple "utf8" and "utf8 Special Mode" is only from the point of view of how the system manipulate this data. There is no real explain yet why this data is marked differently and who is the responsible of processing it.

  • If the "scale" used for the second byte follows the proportion of 2^X (e.g. 1, 2, 4, 8, 16, 32, etc...) then we are missing a "04 01" valid data type in the list

PARAMS[edit source]

This table is a collection of examples of some "rare" savedatas, probably will be needed to erase this section (replaced by a resume in front page) when all areas are identifyed, but by now is usefull to have an overview of how this process works and to find good candidates for tests, feel free to add any other examples you consider interesting ;)

The examples in the table are considered rare because most of the other games uses the values: 1,5,1,2,2 (2 last pointers pointing to the same counter slot 2 at 0x0C) or 1,5,1,3,3 (2 last pointers pointing to the same counter slot 3 at 0x10), so dont add this kind of games to the table because are pointless (by now the only identifyed pointers are the values at ffset 0x03 and 0x04 and the interesting examples are when this pointers are different, or when they changes his values to different numbers like 2,3 or 3,2, or any other combination of 2 different numbers, this means the SFO has several counters enabled), also the table doesnt includes the "user/console" areas that starts at offset 0x18 because are identifyed and explained in front page

The table differences 2 types of savedata, one for "profile" and other for standard "savedata", the reason is because are treated different by the system, after the first analysis it looks the profile support more features, it can evolve by changing his type, and it can store the counters from the other savedatas when SFO's are merged (this happens after completing the game)

  • Notes
    • Iris manager (and all his forks) has an hexeditor inside his archive manager, just navigate to the SFO press "X" and scroll down to offset 0x558 (where PARAMS area usually starts), is easy to recognize because always starts with this 1,5,1,2,2 bytes, at the next line are the 4 counters, 4 bytes length each
    • To know exactly wich files has been updated inside the savedata folder is needed to look at his timestamps, iris manager doesnt displays timestamps, but you can use the FTP feature to see then from a FTP client running in a PC connected to the PS3, be sure the FTP client doesnt fool you with the timestamps, usually after a disconection/conection the old timestamps are displayed, is needed to "refresh" the files (with F5 in filezilla) or close/open the FTP client again to force it to refresh timestamps
    • The system considers the savedata has been updated when the timestamp of the SFO is updated (and consequently the PFD has been updated too). But sometimes the PFD is the only file updated in the folder, in this cases the system doesnt considers the savedata has been updated. The number of times the SFO has been updated is stored in one of the counters inside PARAMS, most games loads and updates the SFO when the game boots (to be able to update his timestamp in XMB and display the last time the game was booted)
Game Title Savedata type PARAMS areas (by offset) Notes
0x0 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x0C 0x10 0x14
untold legends 1 1 1 2 2 0 0 0 00000000 40000000 00000000 01000000 old game, after completing the game
venetica profile 1 1 1 2 3 0 0 0 00000000 01000000 02000000 01000000 old game, after completing the game
yakuza 4 SYSTEM 1 3 1 2 2 0 0 0 00000000 E1010000 00000000 01000000
yakuza 4 CLEAR 1 1 1 2 2 0 0 0 00000000 01000000 00000000 01000000 after completing the game, needed to start a game+
need for speed most wanted 1 5 1 2 3 0 0 0 00000000 7A010000 64000000 01000000
motogp 13 1 5 1 3 3 0 0 0 00000000 00000000 16000000 01000000
tintin 1 5 2 2 2 0 0 0 00000000 AC010000 00000000 01000000
prince of persia sands of time 1 5 1 2 2 0 0 0 00000000 FF000000 00000000 01000000
prince of persia sands of time 1 5 2 2 2 0 0 0 00000000 E6000000 00000000 01000000
the last of us profile 1 7 1 3 3 0 0 0 00000000 00000000 01000000 01000000 new profile savedata, no previous savedatas
the last of us profile 1 8 1 3 3 0 0 0 00000000 00000000 02000000 01000000 boot game, quit game (see examples below)
the last of us profile 1 7 1 3 3 0 0 0 00000000 00000000 97000000 01000000 after completing the game
the last of us save 1 2 1 3 3 0 0 0 00000000 00000000 21000000 01000000 after completing the game
tomb raider profile 1 5 1 3 3 0 0 0 00000000 00000000 01000000 01000000 new profile savedata, no previous savedatas
tomb raider save 1 5 1 3 3 0 0 0 00000000 00000000 01000000 01000000 new game savedata, no previous savedatas
tomb raider profile 1 5 1 2 3 0 0 0 00000000 91000000 14000000 01000000 after completing the game
  • Tests examples
    • The last of us ---> http://pastebin.com/raw.php?i=SAiDzjLN (overall save behaviour with the profile, identifying update counter)
      • the game loads and updates the profile in every boot (by only updating the SFO timestamp and consequently the PFD), and changes the value at offset 0x01 to 8
      • when the user changes some option or forces the save the value at offset 0x01 is changed to 7
      • the profile is updated 1 time for every submenu inside "options" (there are 5 submenues under options)
      • every time the SFO is updated, the counter at 0x10 increases 1 unit
    • tomb raider ------> http://pastebin.com/raw.php?i=S13yrq9R (overall save behaviour with profile and save, update counter, timestamps, failed attempt to increase the game completion counter at offset 0x564)
      • every time the game boots, only the PFD is updated (no other file is updated)
      • When the savedata is updated all the files inside the folder are updated (included ICON0.PNG timestamp)
      • the profile is updated 1 time for every submenu under options, and another time when exiting options (3 submenues + 1 when exiting options for a total of 4 updates)
      • the profile is updated 1 time when exiting extras
      • every time the SFO is updated, the counter at 0x10 increases 1 unit
      • when the game is completed a new counter is added to the profile savedata, and the pointer at offset 0x03 changes to a new counter slot (from slot 3 to slot 2), the new value stored in counter slot 2 is partially unknown but seems to be another counter taken from the SFO of the save used to finish the game

SAVEDATA_LIST_PARAM[edit source]

Example of SAVEDATA_LIST_PARAM containing the "folder size in sectors" in the gamesaves generated by the game "The Orange Box: BLES00153, BLES00171, BLES00172, BLUS30055"

Game Selector Boot Process

When the disc boots, the EBOOT.BIN loads APP_CHOOSER.SELF, is a "game selector" and contains 5 games: half life 2, half life 2ep1, half life 2ep2, Portal, and Team fortress 2

Each of this games has his own .SELF and his own SAVECONTENTPS3 folder (each game uses different Content Information Files when generating his savedata). There is another savedata folder generated/loaded by the selector that is common. In some games (e.g: portal 1) there are several savedata folders to store: the "game settings", "autosave", and "manual save"

All the PARAM.SFO's generated in this savedata folders contains SAVEDATA_LIST_PARAM with a param_len of 7 bytes, and his values are strings of 6 numbers + a zero (NULL terminated)

The value stored by this game in SAVEDATA_LIST_PARAM is the "size of the folder on disk". This size is dependant of the filesystem (512 bytes cluster size in UFS2), and how many clusters are taken as the "minimun chunk" (that seems to be 2 clusters)

Because the writing process standards (and from the point of view of available clusters for the next writing operation) when a single byte is used in a cluster, this whole cluster is considered "not available for next writing process of a new file". This means e.g: that a file with a size 513 bytes uses 2 complete clusters (512 bytes in the first cluster and 1 byte in the second cluster, both clusters are reserved for this file)

To calculate the number of clusters used by a folder... is needed to calculate the number of clusters used by each file inside the folder, this includes the files that uses a number of clusters that is not even and needs to be "rounded-up". e.g: a file with size 1 byte (that is supposed to fit in 1 cluster) uses 2 clusters because the number "1" is not even. In few words, the number of clusters used by a file needs to be "rounded-up to next even number"

  • This save game is a good example because always contains the same values in SAVEDATA_LIST_PARAM (the second one from euro region): BLES00153-PORCONF-0 [Link 1] [Link 2]
File name real file size (in bytes) theorical disk size (in clusters) cluster round-up to even number real disk size (in bytes)
ICON0.PNG 12.461 12461/512=24,3... = 25 25+1= 26 26*512= 13.312
PARAM.PFD 32.768 32768/512= 64 64*512= 32.768
PARAM.SFO 2.736 2736/512=5,3... = 6 6*512= 3.072
PIC1.PNG 89.268 89268/512=174,3... = 175 175+1= 176 176*512= 90.112
POR-0.CFG 893 893/512=1,7... = 2 2*512= 1.024
POR-0.CHK 16 16/512=0,03... = 1 1+1= 2 2*512= 1.024
Folder contents total
138.142 273 clusters 276 clusters 141312 (SAVEDATA_LIST_PARAM)
  • The process is:
    • 1.- Divide by the cluster size
    • 2.- Round-up cluster number (if needed)
    • 3.- Multiply by the same cluster size (to know the amount of bytes reserved for this clusters)

This can be simplifyed by using 1024 (2 clusters)... because this way there is no need of step 2 (the "round-up")... but i have no idea if naming this "chunk" of 2 clusters a "page"... or why UFS2 filesystem takes them 2 by 2... i prefer to left this example as is, feel free to correct me

Also, there is a simple "trick" that can be used to display the files divided in clusters of the size you want (maybe are others but this is the faster way i found). By formatting a usb pendrive in advanced mode, using the cluster size your need, then moving the folder there (by using FAT32 with 1024 bytes cluster the value reported by your operative system is the same one stored inside SAVE_DATA_LIST)

  • PARAM.PFD relationship ?

Other parameters not used in PS3 (only used in other sony consoles)[edit source]

The only purpose of this table is to keep a record of them to not confuse with the ones used in PS3

Parameter Console Notes
PSP PSV PS4
DISC_ID Yes
DISC_NUMBER Yes Yes
DISC_TOTAL Yes Yes
DISC_VERSION Yes
DRIVER_PATH Yes
GAMEDATA_ID Yes Used in some PSP UMD games, found in game_ext_plugin.sprx
HRKGMP_VER Yes
REGION Yes
USE_USB Yes
ACCOUNT_ID Yes Not the same ACCOUNT_ID than PS3... this one for vita has (fmt:utf8-S, len:0x8, max_len:0x8)
ATTRIBUTE2 Yes
ATTRIBUTE_MINOR Yes
GC_RO_SIZE Yes GameCache ReadOnly Size ?
GC_RW_SIZE Yes GameCache ReadWrite Size ?
INSTALL_DIR_ADDCONT Yes Shared Additional Content, fmt:utf-8, max_len:12
INSTALL_DIR_SAVEDATA Yes Shared Save Data, fmt:utf-8, max_len:12
PARENT_DIRECTORY Yes used in PSvita savedata (fmt:utf8, len:0xB, max_len:0x40)
PSP2_DISP_VER Yes utf-8, max_len:8, example: "00.000"
PSP2_SYSTEM_VER Yes int32
PUBTOOLINFO Yes Yes
SAVEDATA_MAX_SIZE Yes int32
SAVEDATA_VER Yes used in PSvita savedata (fmt:utf8, len:0x6, max_len:0x8)
STITLE Yes App Short Title, utf-8, len:52
STITLE_xx Yes
SUPPORT_URI Yes
APP_TYPE Yes
CONTENT_VER Yes
DISP_LOCATION_x Yes
DOWNLOAD_DATA_SIZE Yes
FORMAT Yes
INSTALL_DIR_SAVEDATA Yes
IRO_TAG Yes
PROVIDER Yes
PROVIDER_xx Yes
PUBTOOL_VERSION Yes
REMOTE_PLAY_KEY_ASSIGN Yes
SERVICE_ID_ADDCONT_ADD_x Yes
SYSTEM_ROOT_VER Yes
SYSTEM_VER Yes
USER_DEFINED_PARAM_x Yes
SUB_TITLE_ID
CONTENT_URL URL of content (not parameter but related to link.xml?)
_PARAM.SFO ? found in game_ext_plugin.sprx (anti exploit/bug prevention ?)
__PARAM.SFO ? found in game_ext_plugin.sprx (anti exploit/bug prevention ?)
/PARAM.SFO ? found in game_ext_plugin.sprx (anti exploit/bug prevention ?)
FOLDER_NAME found in game_ext_plugin.sprx
FOLDER_NAME_00 found in game_ext_plugin.sprx

DISC contents temporal installations (in dev_hdd0/tmp)[edit source]

/dev_hdd0/tmp/disc_install/

Reserved Folder Names used in HDD or disc contents[edit source]

L00 up to L05 (License Area subfolders with restricted .SFO's)[edit source]

  • From dev_bdvd: ?
/dev_bdvd/PS3_GAME/L00/PARAM.SFO (up to L05)
/dev_bdvd/PS3_GAME/C00/L00/PARAM.SFO (up to L05)
  • From dev_hdd0:
/dev_hdd0/game/ABCD12345/Lxx/PARAM.SFO
/dev_hdd0/game/ABCD12345/C01/Lxx/PARAM.SFO ---only working if region setting is L03 country (only other tested: L00 not working)

Speculation: Path used to restrict/use different License in the same region (L03?).

You can quickly check your region area with this sub folder (and inserting content file informations such ICON0). L** path can avoid error some code related to param.sfo/disc.sfo.

Folder name License Area Regions
L00 SCEJ Japan
L01 SCEA US (L01), Canada (North America), Mexico (L01), Central America, South America
L02 SCEE Europe/Middle East/Africa, U.K./Ireland, Australia/New Zealand (Oceania: L02), Russia, Ukraine, India, Central Asia ,
L03 SCEH Singapore/Malaysia (Southeast Asia)?, Taiwan (L03), Hong Kong (L03)
L04 SCEK Korea (South Korea)
L05 SCH China

(Unlinked Note: Button Behavior: for L05 is also O , Oceania is X. Path Pioneer with significant idea about it: Deroad)

You can load different Lxx folder by using Debug Menu Setting Region but be alert about your TV setting display video (NTSC/PAL).

Here is a collection of folders (from L00 to L10) with icons displaying the different numbers, this way is easy to know which one is used by XMB, to make the test just copy the folders next to USRDIR folder inside the installation folder of any app: region subfolders tests.zip (430.22KB) http://www.sendspace.com/file/ikvult

See also: "license area" restrictions used in combination with "parental level" http://www.ps3devwiki.com/wiki/Talk:PARAM.SFO#Lxx:_License_Area

EX_GAME and EX_VIDEO[edit source]

  • Theory 2:
    • EX_GAME & EX_VIDEO requires SFO Category 'XR' and are emerged into PS3_EXTRA! (EX_GAME/EX_VIDEO are actually leftovers?)

Others[edit source]

-GE
PS3 DVD / PS2 CD
/dev_bdvd/NORMAL
/dev_bdvd/HYBRID
-GP
/dev_bdvd/PHOTODIR
/dev_bdvd/PS3_CONTENT/PHOTODIR
/dev_bdvd/PS3_CONTENT/PHOTODIR/PARAM.SFO
-GM
/dev_bdvd/MUSICDIR
/dev_bdvd/PS3_CONTENT/MUSICDIR
/dev_bdvd/PS3_CONTENT/MUSICDIR/PARAM.SFO
-GV
/dev_bdvd/VIDEODIR
/dev_bdvd/PS3_CONTENT/VIDEODIR
/dev_bdvd/PS3_CONTENT/VIDEODIR/PARAM.SFO
-GT
/dev_bdvd/THEMEDIR
/dev_bdvd/PS3_CONTENT/THEMEDIR
/dev_bdvd/PS3_CONTENT/THEMEDIR/PARAM.SFO

Todo and Suggestions[edit source]

  • Parameters requirements table has lot of "yes" that should be "opt" (optional). The "yes" means the value is mandatory, so the table is not fully correct.Also... this table represents the values needed for each content ordered by CATEGORY, but there are different contents that shares the same CATEGORY (like the different types of patches, DLC's, and game installations... alll them uses "GD". The "parameter table" cant contain all this different variations, by now i dont see a way to do it--Sandungas (talk) 12:25, 29 January 2014 (EST)
  • The internal structure example for SFO needs to be replaced by a new one with at least 2 parameters, this will make more obvious how are meassured the relative offsets displacements
  • Is needed an explain of how the file is loaded in stages by the system, how is indexed, and the method to access single areas to update single values, the rebuilding process, etc... this is complex and i ignore (but i imagine) how is made by the PS3, but the source codes i saw that manages SFO files uses different methods and styles (and probably some others i ignore), by now im not skilled enought to discuss this in the page but an open talk about all this could be interesting --Sandungas (talk) 23:41, 15 February 2014 (EST)
  • Overall page cleanup of obsolete or wrong info, grammar corrections, etc...
  • Link each ID to a subpage, so they can be centrally managed (some are also listed here: ID's and labels
    • The affected sections in front page are: CONTENT_ID, NP_COMMUNICATION_ID, NPCOMMID, and TITLE_ID, explaining them in the .SFO page (as i did initially) doesnt looks the best solution, but is needed at least a short description of each, now there are specific pages for them (without much descriptions) and the decission of separating all the IDs in pages makes hard to have a overall view of them... the best solution i see is to use the ID's and labels converted to a template an use it repeatedly in SFO page, but the names are not the same used in SFO, also this doesnt solves the short description needed in SFO page (that should be duplicated, and expanded in his specific pages)--Sandungas (talk) 12:25, 29 January 2014 (EST)