Talk:Rcomage: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
 
(4 intermediate revisions by the same user not shown)
Line 13: Line 13:
==official dummy language string pointers not managed by rcomage==
==official dummy language string pointers not managed by rcomage==
Found in '''xmb_plugin_normal.rco''' firmware 1.02 (and probably most others using language text strings, is just in this one is more obvious where the problem happens)
Found in '''xmb_plugin_normal.rco''' firmware 1.02 (and probably most others using language text strings, is just in this one is more obvious where the problem happens)
*xmb_plugin_normal.rco firmware 1.02 original and rebuild at absolute offset 0x50, is indicating the language pointers table starts at absolute offset '''0x7EC''' (position is the same in both, original and rebuild)
**but the size (indicated at offset 0x54) in original is 0x90... and in rebuild 0x78 (after rebuild is smaller, rcomage has "lost" some bytes from it)
The table contains the pointers for every text string for every language, PS3 firmware 1.02 supports up to 10 languages, and every language contains 3 text strings... this makes a total of 30 pointers, every pointer is 4 bytes size, so the whole table of language text pointers should be 120 bytes length (0x78 in hex)... this is what rcomage does
But sony added 6 more pointers to the end of the table (of 4 bytes length each) all filled with zeroes... can be considered padding, but also can be considered "dummy pointers" because belongs to the table of pointers
Now... the question (and the reason why rcomage doesnt adds this pading) is.... '''why sony added that "dummy pointers" ?'''


  illuminati event one, theory one (in the track)
  illuminati event one, theory one (in the track)
Line 26: Line 35:
  <sandungas> someone asked him why the rebuilding was not perfect... and he mentioned some "weird" padding sony did but he could not understand why it happens
  <sandungas> someone asked him why the rebuilding was not perfect... and he mentioned some "weird" padding sony did but he could not understand why it happens
  <sandungas> i think i know why :)
  <sandungas> i think i know why :)
  <sandungas> is a dirty trick, not efficient because adds padding, but assures you the text pointers are aligned properlly
  <sandungas> is a dirty trick, not efficient because adds additionally unneeded padding, but assures you the text pointers are aligned properlly without need to make complex calculations
  <sandungas> something like this...
  <sandungas> something like this...
  <sandungas> if total numer of languages inside .rco is not multiple of 4..... add "dummy" languages until it reaches a multiple of 4
  <sandungas> if total numer of languages inside .rco is not multiple of 4..... add "dummy" languages until it reaches a multiple of 4
*xmb_plugin_normal.rco firmware 1.02 original and rebuild at absolute offset 0x50, is indicating the language pointers table starts at absolute offset 0x7EC
**the size of this same table (indicated at offset 0x54) in original has a size of 0x90... and in rebuild 0x78 (after rebuild is smaller, rcomage has "lost" some bytes from it)
The table contains the pointers for every text string for every language, PS3 firmware 1.02 supports up to 10 languages, and every language contains 3 text strings... this makes a total of 30 pointers, every pointer is 4 bytes size, so the whole table of language text pointers should be 120 bytes length (0x78 in hex)... this is what rcomage does
But sony added 6 more pointers to the end of the table (of 4 bytes length each) all filled with zeroes... can be considered padding, but also can be considered "dummy pointers" because belongs to the table of pointers
Now... the question (and the reason why rcomage doesnt adds this pading) is.... why sony added that "dummy pointers" ?


*It needs to be verifyed further in other .rco files but my theory is this: --[[User:Sandungas|Sandungas]] ([[User talk:Sandungas|talk]]) 00:56, 21 September 2016 (UTC)
*It needs to be verifyed further in other .rco files but my theory is this: --[[User:Sandungas|Sandungas]] ([[User talk:Sandungas|talk]]) 00:56, 21 September 2016 (UTC)
**the table of pointers needs to be aligned to 0x10 bytes boundary (from the start of the table itself), but trying to calculate the padding before building the file is a pita (because there can be lot of languages and lot of text strings for every language, is needed to read every text, multiply by language number, then calculate padding, etc... is not efficient)... so they decided to add this "blind alignment prevention". The thing consists in creating the table by cummulating "pointer placeholders" that contains ALWAYS groups of pointers that are a multiple of 4 based in the number of languages stored inside the .rco (this way the number of strings for every language doesnt matters at all, the table will always be aligned to 0x10 bytes)
**the table of pointers needs to be aligned to 0x10 bytes boundary (from the start of the table itself), but trying to calculate the padding before building the file is a pita (because there can be lot of languages and lot of text strings for every language, is needed to read every text, multiply by language number, then calculate padding, etc... is not efficient)... so they decided to add this "blind alignment prevention". The thing consists in creating the table by cummulating "pointer placeholders" that contains ALWAYS groups of pointers that are a multiple of 4 based in the number of languages stored inside the .rco (this way the number of strings for every language doesnt matters at all, the table will always be aligned to 0x10 bytes)
**As example, in the worst scenario posible... if the rco only contains one language, and only one text string for that language... at building time the table of pointers is created with a size of 0x10 bytes (to store 4 pointers for 4 languages minimal)... then the first pointer is filled... and because there are not more pointers to store the other areas are kept filled with zeroes
**As example, in the worst scenario posible... if the rco only contains one language, and only one text string for that language... at building time the table of pointers is created with a size of 0x10 bytes (to store 4 pointers for 4 languages minimal)... then the first pointer is filled... and because there are not more pointers to store the other areas are kept filled with zeroes
**Another example, with 5 languages... the table is created for 8 languages (rounded to the next multiple of 4) so pointers are added to the table in groups of eight
**Another example, with 5 languages... the table is created for 8 languages (rounded to the next multiple of 4) so "pointer placeholders" are added to the table in groups of eight
 
***In the first step the table has room for 8 pointers and is filed with the 5 pointers for the first text string... now is calculated how many "pointer placeholders" are left in the table = 3... so the table is increased in size with 8 "pointer placeholders" more... now the table has 11 available "pointer placeholders" and are filled with the 5 pointers for the second string stored in positions 6 up to 10... now is calculated how many "pointer placeholders" are left in the table = 1... so the table is increased in size with 8 "pointer placeholders" more... and so on
***Note the number of strings doesnt matters (not needed to know, is not a variable in the function), the process is repeated in a loop and the table will always be aligned to 0x10 bytes boundary


*In PS3 xmb_plugin_normal.rco from firmware 1.02 (with 10 languages) the "pointer placeholders" that are cummulated to make the table bigger (needs to be bigger than 10 and a multiple of 4) are added in groups of 12 pointers (chunks of 0x30 bytes). In the original file the table has a size of 0x90 bytes, this means the table has been increased in size 3 times in the .rco building process




Line 52: Line 54:
*There are other innacuracies when rebuilding this file... not sure if are related with text strings too though... are hard to see where is the problem because the areas are displaced by the problem explained above
*There are other innacuracies when rebuilding this file... not sure if are related with text strings too though... are hard to see where is the problem because the areas are displaced by the problem explained above
**as example... the last event in the "events table" in original is '''native:/Bar::onCursorMove''' (seems to be stored in a different order)
**as example... the last event in the "events table" in original is '''native:/Bar::onCursorMove''' (seems to be stored in a different order)
==RCO format version 0x93 (used by PS3 firmware 082.006)==
There is a problem with the "Image" entries (located under "ImageTree") on the TOC. At the time sony "ported" the RCO format from PSP-to-PS3 it was added an additional value for "Image" (usually a 0x1 and his purpose is still unknown). This additional value was added at pre-retail DECR 085 series (rco_version 0x97). More info here: [[RCOXML_Images#Image]]
The firmwares affected are all PS3 pre-retail 082, 083, and 084 series
Fix for rcomage: if endianess = big and rco_version < 0x97 this value doesnt exists


==RCO format version 0x55 (used by PSP firmware 0.6.5)==
==RCO format version 0x55 (used by PSP firmware 0.6.5)==

Latest revision as of 01:28, 7 April 2018

rcomage innacuracies, mistakes, bugs, or unsupported rco specifications[edit source]

Rebuild verification[edit source]

There is an easy way to verify if the building methods used by rcomage are exactlly like the ones used officially by sony, it basically consists in rebuilding an official rco, the hashes of the original and rebuilt .rco should match exactlly... in other words, after the rebuild the .rco file should be exactlly like the original

  • Requirements for this to work
    • the files needs to be extracted in "raw" format (if using "rcomage gui" in the DUMP tab uncheck all the checkboxes for GIM, VAG, VSMX)... long story short this is to avoid mistakes with the conversors
    • the rco TOC (aka what rcomage names "header compression") needs to use the same compression method than the original (if using "rcomage gui" in the COMPILE tab choose the correct "header compression" from NONE, ZLIB, RLZ)
      • rcomage doesnt keeps a record of this "header compression", so the way to identify it is by opening the original .rco in a hexeditor and check the value stored at absolute offset 0xC. See Resource Container (RCO)

This method is specially usefull with the .rco files that doesnt have "header compression" because is easyer to find the differences in a hexeditor, oldest PS3 firmware .rco's (like the ones in firmware 1.02) are not compressed

official dummy language string pointers not managed by rcomage[edit source]

Found in xmb_plugin_normal.rco firmware 1.02 (and probably most others using language text strings, is just in this one is more obvious where the problem happens)

  • xmb_plugin_normal.rco firmware 1.02 original and rebuild at absolute offset 0x50, is indicating the language pointers table starts at absolute offset 0x7EC (position is the same in both, original and rebuild)
    • but the size (indicated at offset 0x54) in original is 0x90... and in rebuild 0x78 (after rebuild is smaller, rcomage has "lost" some bytes from it)

The table contains the pointers for every text string for every language, PS3 firmware 1.02 supports up to 10 languages, and every language contains 3 text strings... this makes a total of 30 pointers, every pointer is 4 bytes size, so the whole table of language text pointers should be 120 bytes length (0x78 in hex)... this is what rcomage does

But sony added 6 more pointers to the end of the table (of 4 bytes length each) all filled with zeroes... can be considered padding, but also can be considered "dummy pointers" because belongs to the table of pointers

Now... the question (and the reason why rcomage doesnt adds this pading) is.... why sony added that "dummy pointers" ?

illuminati event one, theory one (in the track)
-----------------------------------------------
<sandungas> just found an "innacuracy" of rcomage when rebuilding files
<sandungas> im not calling it a mistake because it doesnt breaks the format
<sandungas> is an (seems stupid) padding sony adds in the original files.... but rcomage doesnt
<sandungas> the point is maybe is not so stupid and is based on how the contents are mounted in the console ram, aligned to memory blocks and stuff like that
<sandungas> actually, maybe this is dependant of the console (ps3 or psp) because the different ram management, hmmmm
<zecoxao_> you need ZingaBurga
<sandungas> yep :/
<sandungas> and i remember him talking about this
<sandungas> someone asked him why the rebuilding was not perfect... and he mentioned some "weird" padding sony did but he could not understand why it happens
<sandungas> i think i know why :)
<sandungas> is a dirty trick, not efficient because adds additionally unneeded padding, but assures you the text pointers are aligned properlly without need to make complex calculations
<sandungas> something like this...
<sandungas> if total numer of languages inside .rco is not multiple of 4..... add "dummy" languages until it reaches a multiple of 4
  • It needs to be verifyed further in other .rco files but my theory is this: --Sandungas (talk) 00:56, 21 September 2016 (UTC)
    • the table of pointers needs to be aligned to 0x10 bytes boundary (from the start of the table itself), but trying to calculate the padding before building the file is a pita (because there can be lot of languages and lot of text strings for every language, is needed to read every text, multiply by language number, then calculate padding, etc... is not efficient)... so they decided to add this "blind alignment prevention". The thing consists in creating the table by cummulating "pointer placeholders" that contains ALWAYS groups of pointers that are a multiple of 4 based in the number of languages stored inside the .rco (this way the number of strings for every language doesnt matters at all, the table will always be aligned to 0x10 bytes)
    • As example, in the worst scenario posible... if the rco only contains one language, and only one text string for that language... at building time the table of pointers is created with a size of 0x10 bytes (to store 4 pointers for 4 languages minimal)... then the first pointer is filled... and because there are not more pointers to store the other areas are kept filled with zeroes
    • Another example, with 5 languages... the table is created for 8 languages (rounded to the next multiple of 4) so "pointer placeholders" are added to the table in groups of eight
      • In the first step the table has room for 8 pointers and is filed with the 5 pointers for the first text string... now is calculated how many "pointer placeholders" are left in the table = 3... so the table is increased in size with 8 "pointer placeholders" more... now the table has 11 available "pointer placeholders" and are filled with the 5 pointers for the second string stored in positions 6 up to 10... now is calculated how many "pointer placeholders" are left in the table = 1... so the table is increased in size with 8 "pointer placeholders" more... and so on
      • Note the number of strings doesnt matters (not needed to know, is not a variable in the function), the process is repeated in a loop and the table will always be aligned to 0x10 bytes boundary
  • In PS3 xmb_plugin_normal.rco from firmware 1.02 (with 10 languages) the "pointer placeholders" that are cummulated to make the table bigger (needs to be bigger than 10 and a multiple of 4) are added in groups of 12 pointers (chunks of 0x30 bytes). In the original file the table has a size of 0x90 bytes, this means the table has been increased in size 3 times in the .rco building process



  • There are other innacuracies when rebuilding this file... not sure if are related with text strings too though... are hard to see where is the problem because the areas are displaced by the problem explained above
    • as example... the last event in the "events table" in original is native:/Bar::onCursorMove (seems to be stored in a different order)

RCO format version 0x93 (used by PS3 firmware 082.006)[edit source]

There is a problem with the "Image" entries (located under "ImageTree") on the TOC. At the time sony "ported" the RCO format from PSP-to-PS3 it was added an additional value for "Image" (usually a 0x1 and his purpose is still unknown). This additional value was added at pre-retail DECR 085 series (rco_version 0x97). More info here: RCOXML_Images#Image

The firmwares affected are all PS3 pre-retail 082, 083, and 084 series

Fix for rcomage: if endianess = big and rco_version < 0x97 this value doesnt exists

RCO format version 0x55 (used by PSP firmware 0.6.5)[edit source]

PSP firmware 0.6.5 uses a primitive version of the rco format, this is an example of the rco header (first 0x94 bytes) of system_plugin.rco, most notable change is the header is smaller (so is missing some areas for features that was not implemented yet). I dont plan to look for all the changes but this little example hopefully will show what areas are missing to have an overall idea of the order of how features was implemented in the rco format. This version of the rco format is not compatible with rcomage... but it should by deleting the "unknowns" in the definitions of the source code (lines 51 and 76 of rcofile.h) then compile it (not tested, other errors can happen but this should work) the idea doesnt works, compiler returns other errors http://paste.ubuntu.com/23207840/

Original header (remember PSP uses little endian so some bytes are swapped)

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  00 50 52 46 55 00 00 00 00 00 00 00 00 00 00 00  .PRFU...........
00000010  94 00 00 00 FF FF FF FF 7C 0A 00 00 34 08 00 00  ”...ÿÿÿÿ|...4...
00000020  FF FF FF FF BC 00 00 00 FF FF FF FF 7C 0B 00 00  ÿÿÿÿ¼...ÿÿÿÿ|...
00000030  FF FF FF FF E0 0C 00 00 68 00 00 00 48 0D 00 00  ÿÿÿÿà...h...H...
00000040  9C 04 00 00 E4 11 00 00 04 00 00 00 F0 0B 00 00  œ...ä.......ð...
00000050  28 00 00 00 18 0C 00 00 94 00 00 00 FF FF FF FF  (.......”...ÿÿÿÿ
00000060  00 00 00 00 AC 0C 00 00 2C 00 00 00 D8 0C 00 00  ....¬...,...Ø...
00000070  08 00 00 00 FF FF FF FF 00 00 00 00 E8 11 00 00  ....ÿÿÿÿ....è...
00000080  40 DF 01 00 28 F1 01 00 F0 58 02 00 FF FF FF FF  @ß..(ñ..ðX..ÿÿÿÿ
00000090  00 00 00 00                                      ....
Areas Offset Length Example Name Notes
Header
0x00 0x04 PRF magic PRF in little endian
0x04 0x04 55 00 00 00 version 0x55 = one of the firmwares for PSP
0x08 0x04 00 00 00 00 unknown
0x0C 0x04 00 00 00 00 compress_header 0x00 = uncompressed
0x10 0x04 94 00 00 00 toc_maintree_absolute_offset MainTree at absolute offset 0x94
0x14 0x04 FF FF FF FF toc_scripttree_absolute_offset
0x18 0x04 7C 0A 00 00 toc_languagetree_absolute_offset TextTree at absolute offset 0xA7C
0x1C 0x04 34 08 00 00 toc_soundtree_absolute_offset SoundTree at absolute offset 0x834
0x20 0x04 FF FF FF FF toc_modeltree_absolute_offset
0x24 0x04 BC 00 00 00 toc_imagetree_absolute_offset ImageTree at absolute offset 0xBC
0x28 0x04 FF FF FF FF toc_unknowntree_absolute_offset or toc_fonttree_absolute_offset
0x2C 0x04 7C 0B 00 00 toc_objecttree_absolute_offset ObjectTree at absolute offset 0xB7C
0x30 0x04 FF FF FF FF toc_animationtree_absolute_offset
0x34 0x04 E0 0C 00 00 strings_texts_absolute_offset strings texts table at absolute offset 0xCE0
0x38 0x04 68 00 00 00 strings_texts_length strings texts table size 0x68
0x3C 0x04 48 0D 00 00 strings_labels_absolute_offset strings labels table at absolute offset 0xD48
0x40 0x04 9C 04 00 00 strings_labels_length strings labels size 0x49C
0x44 0x04 E4 11 00 00 strings_events_absolute_offset strings events table at absolute offset 0x11E4
0x48 0x04 04 00 00 00 strings_events_length strings events size 0x4
0x4C 0x04 F0 0B 00 00 text_pointer_table_offset
0x50 0x04 28 00 00 00 text_pointer_table_length
0x54 0x04 18 0C 00 00 image_pointer_table_offset
0x58 0x04 94 00 00 00 image_pointer_table_length
0x5C 0x04 FF FF FF FF model_pointer_table_offset
0x60 0x04 00 00 00 00 model_pointer_table_length
0x64 0x04 AC 0C 00 00 sound_pointer_table_offset
0x68 0x04 2C 00 00 00 sound_pointer_table_length
0x6C 0x04 D8 0C 00 00 object_pointer_table_offset
0x70 0x04 08 00 00 00 object_pointer_table_length
0x74 0x04 FF FF FF FF anim_pointer_table_offset
0x78 0x04 00 00 00 00 anim_pointer_table_length
0x7C 0x04 E8 11 00 00 image_data_section_offset
0x80 0x04 40 DF 01 00 image_data_section_length
0x84 0x04 28 F1 01 00 sound_data_section_offset
0x88 0x04 F0 58 02 00 sound_data_section_length
0x8C 0x04 FF FF FF FF model_data_section_offset
0x90 0x04 00 00 00 00 model_data_section_length
12 bytes of unknowns 0xFF's was added here for newer versions of the rco format

Missing descriptors in rcomage current version (1.1.1)[edit source]

miscmap.ini[edit source]

  • See Languages
    • unknown0x10.xml is Polish
    • unknown0x11.xml is Portuguese (Brazil)
    • unknown0x12.xml is English (Great Britain)
    • unknown0x13.xml is Turkish
  • The languages are listed in the file miscmap.ini... you can add the unknowns by yourself to the languages table, example:
[languages]
00_Japanese       ; ja
01_English_US     ; en
02_French         ; fr
03_Spanish        ; es
04_German         ; de
05_Italian        ; it
06_Dutch          ; nl
07_Portuguese_PT  ; pt
08_Russian        ; ru
09_Korean         ; ko
10_Chinese_T      ; ch
11_Chinese_S      ; zh
12_Finnish        ; fi
13_Swedish        ; sv
14_Danish         ; da
15_Norwegian      ; no
16_Polish         ; pl
17_Portuguese_BR  ; br
18_English_GB     ; gb
19_Turkish        ; tr
  • changes
    • Added the 4 unknown languages (Polish, Portuguese_BR, English_GB, Turkish)
    • Added "two-digit" language code before name, and language variant after name
    • Changed names for variants of English_US/GB, Portuguese_PT/BR, and Chinese_T/S
    • Changed commented languages to "two-letter" language code, from explore_plugin.sprx
    • Fixed "Portugese" typo

tagmap.ini[edit source]

This file defines the names of the tags used in the XML descriptor at the root of the .rco

Only 2 unknowns:

[Object]
ObjUnknown0xB
ObjUnknown0x1B

animattribdef-ps3.ini[edit source]

This file defines the names of the animation attributes used in the XML descriptor at the root of the .rco

Only 5 unknowns. It seems that unknownInt5, unknownInt6, unknown7 has been implemented with rco 2.0 format specifically for PS3 (not supported in PSP). The others for lock/unlock existed before in rco 1.0 format (supported in PSP)

[MoveTo]
unknownInt5 = int
unknownInt6 = int
unknown7 = unk

[Lock]
unknownInt0 = int

[Unlock]
unknownInt0 = int

objattribdef-ps3.ini[edit source]

This file defines the names of the object attributes used in the XML descriptor at the root of the .rco

onInit, onPush, buttonPush, btnClick, onButton, onLoad... sometimes are used as a generic "run" command and can replace any of the other events (as example on some menues of xmb settings column when moving right is taken as a push) so is hard to identify the official name that are replacing. For this reason the list here keeps some counters of how many times have been found in official firmware. The counters works as a justification of why some names has been changed based in the number of times used

onPanelCommand seems to be an special event that can replace some of the standard events (used as a Button attribute)

Standard object attributes[edit source]

; -- BEGIN STANDARD POSITION DEFINITION --
onLoad           onInit <---------- used 5485 times in 4.76 firmware, most with "OnInit" or "nothing"
; -- END STANDARD POSITION DEFINITION --

Specific object attributes[edit source]

[Page]
onInit        <------------- used 625 times in firmware 4.76. Around 607 onInit, 18 onOpen
onContextMenu onContext <--- better to use a more generic name because "onContext" is used in several other objects and is technically the same event for all them

[Button]
image2         focus
unknownRef29   text
unknownEvent31 onPush   <---- used 292 times in firmware 4.76. Around 258 onPush, 24 buttonPush, 5 btnClick, 3 onButton, 2 onCancel
unknownEvent33 onFocusIn
unknownEvent35 onFocusOut
unknownEvent37 onFocusLeft
unknownEvent39 onFocusRight
unknownEvent41 onFocusUp
unknownEvent43 onFocusDown
unknownEvent45 onContext

[XMenu]
onEnter        onPush <---- used 2 times in firmware 4.76. Both onPush
unknownEvent28 onCursorMove
onLabelLoad    onScrollIn <---- official name
unknownRef32   onScrollOut

[XMList]
unknownRef3    text

[XList]
onMove        onCursorMove <---- official name (is the same, but this way matches with the others)

[Progress]
unknownRef25   image
unknownRef27   image2 <------ shadow image ?

[MList]
unknownRef33 onPush
unknownRef35 onCursorMove
unknownRef37 onFocusIn
unknownRef39 onFocusOut
unknownRef41 onFocusLeft
unknownRef43 onFocusRight
unknownRef45 onFocusUp
unknownRef47 onFocusDown
unknownRef49 onScrollIn
unknownRef51 onScrollOut

[MItem]
unknownRef4  altText2

[Spin]
unknownEvent29  onDecide
unknownEvent31  onCancel
unknownEvent33  onRollIn

[Action]
unknownRef0     text

[ItemSpin]
unknownEvent33  onDecide
unknownEvent35  onCancel
unknownRef41    onFocusIn
unknownRef43    onFocusOut
unknownRef45    onFocusLeft
unknownRef47    onFocusRight

[LList]
unknownEvent40  OnScrollIn

[Edit]
unknownEvent31  onDecide
unknownRef33    onCancel
unknownEvent39  onFocusLeft
unknownEvent41  onFocusRight
unknownObject43 object1
unknownObject45 object2

[Clock]
unknownText25   text
unknownText27   altText
unknownEvent33  onDecide
unknownEvent35  onCancel
unknownEvent41  onFocusLeft
unknownEvent43  onFocusRight
unknownEvent49  onTickClock 

[IList]
unknownEvent29  onFocusLeft
unknownRef31    onFocusRight
unknownRef35    onFocusDown
unknownRef37    onPush <------------ found used this way (and only 1 time in firmware 4.76), but it seems OnPush is used here as a generic event

[IItem]
textDefault    text
textError      altText  <---- because is not an error strictlly

[UButton]
onLeft         onFocusLeft  <----- official name
onRight        onFocusRight  <---- official name
onUp           onFocusUp  <------- official name
onDown         onFocusDown  <----- official name

[CheckboxGroup]
unknownRef33    onPush      <---- used 23 times in 4.76 firmware, 17 onPush, the others "nothing"
unknownRef35    onCursorMove
unknownRef37    onFocusIn
unknownRef39    onFocusOut
unknownRef41    onFocusLeft
unknownRef43    onFocusRight
unknownRef45    onFocusUp
unknownRef47    onFocusDown
unknownRef49    onScrollIn

[CheckboxItem]
unknownRef1     text

[EditBox]
unknownRef59   image
unknownRef61   image2
unknownRef63   onPush      <---- used 74 times in 4.76 firmware, 62 onPush, 1 onBtnClick, 11 "nothing"
unknownRef65   onFocusIn
unknownRef67   onFocusOut
unknownRef69   onFocusLeft
unknownRef71   onFocusRight
unknownRef73   onFocusUp
unknownRef75   onFocusDown
  • Examples:
    • onInit="event:native:/OnListPageOpen"
    • onInit="event:native:/OnContentsSelectPageOpen"
    • onInit="event:native:/OnModeSelectPageOpen"
    • onInit="event:native:/onInit_page_Wizard"
    • unknownRef3="text:msg_game"
    • unknownRef33="event:native:/OnPushMlistID"
    • unknownRef33="event:native:/Menu::cbPush"
    • unknownRef37="event:native:/OnFocusInMlistID"
    • unknownRef41="event:native:/Menu::cbFocusLeft"
    • unknownRef47="event:native:/Menu::cbFocusDown"
    • unknownRef49="event:native:/OnScrollInMlistID"
    • unknownRef49="event:native:/Menu::cbScrollIn"
    • unknownRef51="event:native:/Menu::cbScrollOut"
    • onLoad="event:native:/Bar::onInit"
    • onLoad="event:native:/onInit_ilist_NetworkInfomationList"
    • onEnter="event:native:/Bar::onPush"
    • unknownEvent28="event:native:/Bar::onCursorMove"
    • onLabelLoad="event:native:/Bar::onScrollIn"
    • unknownRef32="event:native:/Bar::onScrollOut"
    • image="image:tex_button" shadow="image:tex_button_shadow" image2="image:tex_button_focus" unknownRef29="text:msg_ok"
    • unknownEvent31="event:native:/XaiController::onPanelCommand"
    • unknownEvent37="event:native:/XaiController::onPanelCommand"
    • unknownEvent39="event:native:/XaiController::onPanelCommand"
    • shadowX="4" shadowY="-5" shadowPerspective="0" shadowRed="0.25" shadowGreen="0.25" shadowBlue="0.25" shadowAlpha="1" unknown48="0x0" unknown49="0x0" unknown50="0x0" unknownFloat51="1" unknownFloat52="1" unknownFloat53="1" unknownFloat54="1"
    • unknownRef63="event:native:/onPush_button_NetworkDhcpHostSetting"
    • unknownRef69="event:native:/onFocusLeft_button_NetworkAccounSetting" unknownRef71="event:native:/onFocusRight_button_NetworkAccounSetting" unknownRef73="event:native:/onFocusUp_button_NetworkAccounSettingPassword"
    • unknownRef75="event:native:/onFocusDown_button_NetworkAccounSettingUserId"
    • unknownEvent31="event:native:/onDecide_ipaddr_NetworkAddressSetIpaddress"
    • unknownRef33="event:native:/onCancel_ipaddr_NetworkAddrSetting"
    • unknownEvent31="event:native:/onDecide_ipaddr_NetworkAddressSetNetmask"
    • unknownRef33="event:native:/onCancel_ipaddr_NetworkAddrSetting"
    • unknownEvent39="event:native:/onFocusLeft_ipaddr_NetworkAddrSetting"
    • unknownEvent41="event:native:/onFocusRight_ipaddr_NetworkAddrSetting"
    • unknownObject43="object2:ipaddr_network_address_setting_ipaddress"
    • unknownObject45="object2:ipaddr_network_address_setting_defaultrooter"
    • unknownRef29="text:msg_agree"
    • unknownEvent31="event:native:/cbPush"
    • unknownEvent37="event:native:/cbFocusLeft" unknownEvent39="event:native:/cbFocusRight" unknownEvent41="event:native:/cbFocusUp" unknownEvent43="event:native:/cbFocusDown"
    • unknownEvent31="event:native:/OnControlPanelButtonPush" unknownEvent33="event:native:/OnControlPanelButtonFocusIn" unknownEvent35="event:native:/OnControlPanelButtonFocusOut" unknownEvent37="event:native:/OnControlPanelButtonFocusLeft" unknownEvent39="event:native:/OnControlPanelButtonFocusRight" unknownEvent41="event:native:/OnControlPanelButtonFocusUp" unknownEvent43="event:native:/OnControlPanelButtonFocusDown"
    • unknownRef33="event:native:/ctl_list_cbPush" unknownRef35="nothing" unknownRef37="nothing" unknownRef39="nothing" unknownRef41="nothing" unknownRef43="event:native:/ctl_list_cbFocusRight" unknownRef45="event:native:/ctl_list_cbFocusUp" unknownRef47="nothing" unknownRef49="event:native:/ctl_list_cbScrollIn" unknownRef51="event:native:/ctl_list_cbScrollOut"
    • unknownRef59="image:avc2_main_back_paper" unknownRef61="image:avc2_main_back_paper" unknownRef63="event:native:/cbPush"
    • unknownRef33="event:native:/Menu::cbPush" unknownRef35="event:native:/Menu::cbCursorMove" unknownRef37="nothing" unknownRef39="event:native:/Menu::cbFocusOut"
    • unknownEvent43="event:native:/VideoEditorUpload::ServiceSelect::OnFocusDownButton1" unknownEvent45="event:native:/VideoEditorUpload::ServiceSelect::OnContextMenuButton1"
    • unknownRef63="event:native:/OnCreatePageEditBtnClick" unknownRef65="event:native:/OnCreatePageEditBtnFocusIn"
    • unknownRef65="event:native:/DialogController::onEditBottonFocusIn" unknownRef67="event:native:/DialogController::onEditBottonFocusOut"
    • unknownEvent29="event:native:/OnDecideISpinDeviceConfigCameraSetting" unknownEvent31="event:native:/OnCancelISpinDeviceConfigCameraSetting" unknownEvent33="event:native:/OnRollInISpinDeviceConfigCameraSetting"
    • unknownRef33="event:native:/OnPushClistRegPSVitaConfig" unknownRef35="nothing" unknownRef37="event:native:/OnFocusInClistRegPSVitaConfig" unknownRef39="event:native:/OnFocusOutClistRegPSVitaConfig" unknownRef41="nothing" unknownRef43="nothing" unknownRef45="nothing" unknownRef47="event:native:/OnFocusDownClistRegPSVitaConfig" unknownRef49="event:native:/OnScrollInClistRegPSVitaConfig"
    • unknownRef33="event:native:/OnPushCheckBoxList" unknownRef35="event:native:/OnCursorMoveCheckBoxList" unknownRef37="nothing" unknownRef39="nothing" unknownRef41="nothing" unknownRef43="nothing" unknownRef45="event:native:/OnFocusUpCheckBoxList" unknownRef47="event:native:/OnFocusDownCheckBoxList"
    • unknownRef41="event:native:/OnFocusLeftClistAudioOutputConfig" unknownRef43="event:native:/OnFocusRightClistAudioOutputConfig"
    • unknownEvent33="event:native:/OnTitleJumpSpinDecide" unknownEvent35="event:native:/OnTitleJumpSpinCancel" unknownRef37="nothing" unknownRef39="nothing" unknownRef41="event:native:/OnTitleJumpButtonFocusIn" unknownRef43="event:native:/OnTitleJumpButtonFocusOut"
    • unknownRef45="event:native:/OnFocusLeftNumSpinWizardEventHandler" unknownRef47="event:native:/OnFocusRightNumSpinWizardEventHandler"
    • unknownEvent29="event:native:/EulaLicensingWizard::onFocusLeft" unknownRef31="event:native:/EulaLicensingWizard::onFocusRight"
    • unknownRef35="event:native:/ConsoleAutoPowerOffPage::OnFocusDownIlist"
    • unknownEvent33="event:native:/OnDecideClockFirstConfig" unknownEvent35="event:native:/OnCancelClockFirstConfig" unknownRef37="nothing" unknownRef39="nothing" unknownEvent41="event:native:/OnFocusLeftFirstConfig" unknownEvent43="event:native:/OnFocusRightFirstConfig" unknownRef45="nothing" unknownRef47="nothing" unknownEvent49="event:native:/OnTickClockFirstConfig"
    • <Action name="item_audio_device_config_volume_off" unknownRef0="text:msg_off"></Action>
    • unknownRef1="text:msg_update_auto_off_ps3_after_update"
    • unknownRef3="text:msg_game"
    • unknownRef25="image:tex_progress_bar" unknownRef27="image:tex_progress_bar_in"
    • <MItem name="item_network_accesspoint_list" text="text:msg_none" altText="text:msg_none" unknownRef4="text:msg_none"></MItem>
    • unknownEvent40="event:native:/OnScrollInListEdyViewer"
    • unknownText25="text:msg_am" unknownText27="text:msg_pm"
    • unknownRef37="event:native:/OnPushIlistBtDeviceManager"
    • <IItem name="iitem_address_setting" unknown1="0x0" textDefault="text:msg_ipaddress_setting" textError="text:msg_auto"></IItem>