3dbrew - User contributions [en]

Mysteries

2018-05-03T15:43:17Z

Qyriad:

The following is a list of mysteries.

== General ==
* What is the CTR abbreviation?
: C may stand for Chiheisen ("horizon" in Japanese, the O3DS's codename being "Project Horizon").
:: Not true, Horizon refers to the OS.
: CTR stands for Citrus.

== Hardware ==
=== Why are there two CTRCARD controllers? ===
'''Background:''' Also [http://problemkaputt.de/twl-core.jpg DSi SoC pinout] shows evidence of dual NTRCARD controllers on the final DSi SoC. (This was a [http://i.imgur.com/0kJlbEw.png planned feature] of the DSi before being axed later in development)

=== Why are there two EMMC controllers? ===
'''Theory:''' At some point during 3DS hardware development there was an idea to split up CTR and TWL nand into two different chips.
=== Is there a JTAG? ===
=== Is there more than one revision of the bootrom? ===
'''Background:''' Bootrom visible portion has been dumped on the entire 3DS Family (3DS, 3DSXL, 2DS, New3DS, New3DSXL, New2DSXL), and even a prototype board from April(?) 2010. All matching exactly.

=== What is the EMMC controller @ 0x10100000 doing? ===
'''Background:''' There's dead code in NWM referencing it.
=== Why did they put NTRCARD accessible from ARM11? ===
'''Theory:''' At some point during 3DS hardware development there was a concept where ARM11 ran a menu with DS(i) icons while ARM9 was in TWL mode.

=== Is there a secret message embedded in the 3DS keyscrambler constant? ===
'''Background:''' TWL key scrambler constant was "Nintendo Co., Ltd" in Japanese ("任天堂株式会社"), UTF-16LE encoded, with byte order mark. The 3DS key scrambler constant, by comparison, is random-looking.

=== What is the PDN abbreviation? ===
: Power distribution network

=== How does Nintendo reflash bricked systems? ===
Before trying to boot from NAND, the bootrom checks to see if a key combination (Start + Select + X) is being held, and whether the shell is closed. If so, it tries to boot from an inserted NTR (Nintendo DS) cartridge.
This allows to execute a FIRM that is probably used by Nintendo to reflash the system.

== Software ==
=== What was the problem in "initial program loader" that was mentioned in an FCC filing by Nintendo for 2DS? ===
'''Background:''' http://www.neogaf.com/forum/showthread.php?t=814624&page=1
=== What did SVC 0x74 in the ARM11 kernel do before it got stubbed? ===
=== What is the PTM abbreviation? ===
: Power/time management

=== Why is the DTCM not used anywhere except bootrom? ===
'''Background:''' Bootrom is known to use part of DTCM as state, memsetting it to 0 when it's done. After that, it is never used again.
=== How is CTRAging launched during factory setup? ===
'''Background:''' No TestMenu version is capable of launching CTRAging directly: O3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and the TWL/AGB test apps; N3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and System Settings.

'''Theory:''' NtrBoot another time
=== Why are there 4 stubbed syscalls named SendSyncRequest1-4? ===
=== Is there a deterministic formula for calculating the Movable.sed KeyY high u64? ===
'''Background:''' We know now that the high 4 bytes of KeyY can be reliably estimated to be 1/5th of the LocalFriendCodeSeed (low 8 bytes of KeyY), which is close enough to brute force. However, the actual value is usually about 0-4000 units off the actual high u32 of the KeyY (called msed3 in the seedminer implementation). Could there possibly be a deterministic formula given this 1/5 ratio is so close to the correct value? It's difficult to imagine this is just a coincidence.

NCCH

2018-02-21T21:55:56Z

Qyriad: Clarify what NCCH stands for

[[Category:File formats]]
The following text tries to document the structure of the NCCH (Nintendo Content Container Header) container format. This format is used to store the content of any installed [[Titles|title]].

== Overview ==
There are two known NCCH container specializations used on the 3DS, "executable" and "non-executable", officially known as CXI and CFA, respectively.

=== CXI ===

The CXI (CTR Executable Image) specialization of the NCCH container contains executable code, which runs on a single ARM11 core.

The CXI format is structured in the following order:
* first a NCCH header,
* followed by an [[NCCH/Extended Header|extended header]],
* followed by an access descriptor,
* followed by an '''optional''' plain binary region,
* followed by an '''optional''' executable filesystem ([[ExeFS]]) - (contains ARM11 code, Home menu [[SMDH|icn]]/bnr and [[Logo|logo]]),
* and finally followed by an '''optional''' read-only filesystem ([[RomFS]]) - (Used for external file storage).

The extended header contains additional information regarding access control.
The plain binary region is an area specifically stored in plaintext, mostly containing SDK library strings for identification.

=== CFA ===

The CFA (CTR File Archive) specialization of the NCCH container is not executable, but is used in conjunction with CXI files, e.g. the DLP Child Container and the Electronic Manual. (There is a system update NCCH which follows this format, but is used by the 3DS rather than the Application NCCH, and only works when embedded in the [[CCI]] format because the nVer is kept in the header of retail [[CCI]] files instead of the application NCCH). There are CFA files which exist alone in a title, but these are just [[Title list|System Data Archive]] titles and are found only in the [[Flash Filesystem#CTR partition|NAND]].

CFA files are structured in the following order:
* first a NCCH header,
* followed by an '''optional''' executable filesystem ([[ExeFS]]) (same as in CXI, except no ARM11 code)
* followed by an '''optional''' read-only filesystem ([[RomFS]])

== Container File Format ==

=== Encryption ===
The extended header, the [[ExeFS]], and the [[RomFS]] are encrypted using [https://github.com/3dshax/ctr/blob/master/ctrtool/ncch.c 128-bit AES CTR] unless the NoCrypto flag is set in ncchflag[7]. There are different sets of encryption parameters in use, as over the time new system updates introduced more sophisticated means of encryption. Generally, the decryption key is generated using the [[AES|AES Engine]] key generator by selecting a particular key slot (see below), the keyX of which is usually set by the bootrom and keyY of which was originally set to the first 0x10 bytes of the NCCH signature.

'''NOTE: For a full understanding of the steps involved in decryption, consult the [https://github.com/Relys/Project_CTR ctrtool] and [https://github.com/archshift/Decrypt9 Decrypt9] source code instead.'''.

Starting with [[9.6.0-24|9.6.0-X]] Process9, there is a different method of generating the NCCH keyY which is enabled by setting the bitmask 0x20 in ncchflag[7]: The keyY will be set to a SHA256 hash generated with the 0x20 bytes of data constituted by the old-method-keyY and a unique content lock seed (each of which are 0x10 bytes wide), where seeds for downloaded titles that use the new crypto are stored in [[Filesystem_services#SEEDDB|SEEDDB]] (nand:/data/<console-unique>/sysdata/0001000f/00000000). The decryption is transparent to ARM11 userland: When FSUSER OpenFile is used with a NCCH archive which uses this crypto, the FS-module will add the seed-data from SEEDDB to the end of the file lowpath used for [[FSPXI:OpenFile]], using which Process9 then gets the hash for calculating the NCCH keyY. It has been observed that this new keyY generation is only used for [[RomFS]] and for [[ExeFS]] sections other than "icon" and "banner" (the same sections which would be used for the additional NCCH keyslots, however this keyY generation can be used without any additional NCCH keyslot). Not applying the encryption to "icon" and "banner" was presumably done to support pre-loading of games from the eShop (i.e. being able to download and install titles without being able to start them until official release).

If a certain NCCH flag is set, a fixed AES key is used. There are two fixed keys, one for titles which have the system category bit set (SystemFixedKey), and one for the rest ("zeros" key). These are debug keys, as they aren't nomally supported on retail systems.

As of [[7.0.0-13|7.0.0-X]] the system supports a new encryption method for secure-crypto (when ncchflag[3] != 0). Where a second key is generated using the same keyY but with another [[AES|keyslot]]. The second key is used to crypt the [[RomFS]] and [[ExeFS]] files which don't have filenames "icon" or "banner" (i.e. ".code" and ".firm"). While everything else is crypted with the original key. Note the CTR used is the same for both keys. This makes titles "recognizable" but not "launchable" on systems which don't support this method or the keyslot used.

See below for the secondary keyslots used in NCCH crypto(as mentioned above). As of [[9.6.0-24|9.6.0-X]], Old3DS Process9 will *only* use secondary-keyslot 0x25 when ncchflag[3] is non-zero.
{| class="wikitable" border="1"
|-
! ncchflag[3]
! FW Introduced
! Old3DS
! [[AES#Keyslot|AES Keyslots]]
! Notes
|-
| 0x01
| [[7.0.0-13|7.0.0-X]]
| style="background: #ccffbb" | Yes
| 0x25
| This keyslot is [[Savegames|initialized]] by the 6.0 gamecard savegame keyY init function during boot, using a different portion of the [[Savegames|final]] hash (this keyslot is separate from the one used for the 6.0 save crypto).
|-
| 0x0A
| [[9.3.0-21|9.3.0-X]]
| style="background: #ffccbb" | No
| 0x18
| This keyslot is initialized by [[FIRM#New_3DS_FIRM|arm9loader]] on New3DS starting with [[8.1.0-0_New3DS]], but only [[9.3.0-21|9.3.0-X]] and later know how to use it with ncchflag[3].
|-
| 0x0B
| [[9.6.0-24|9.6.0-X]]
| style="background: #ffccbb" | No
| 0x1B
| [[9.6.0-24|9.6.0-X]]'s [[FIRM#New_3DS_FIRM|arm9loader]] changed the contents of keyslots 0x19-0x1F; 9.6.0-X was the first time they were officially used, so this is not a breaking change (there is no content that would use the old versions of those keys).
|}

=== Format ===

Currently, only [[ExeFS]]:/.code can be compressed (with a LZ77 variant). A flag in the [[NCCH/Extended Header#System Info|exheader]] determines if this is the case.

On retail for SD applications, exheader_systeminfoflags.flag bit1 must be set.

Retail CFAs use the default NCCH product code "CTR-P-CTAP", while retail title/gamecard CXIs use NCCH product code "CTR-X-XXXX". This product code is the NCCH [[Serials|serial code]]. The region-locking info checked by home menu is stored in the [[SMDH#BNR Region|icon]].

All of the hashes stored in this NCCH header are over the cleartext data. The ExeFS/RomFS superblock starts at offset 0x0 in the ExeFS/RomFS, and the size is specified by the hash region fields. Nintendo's NCCH validation code seems to have the size of this region fixed to 0x200 bytes (for ExeFS at least).

As of [[5.0.0-11]] the application [[ExeFS]]:/logo can be loaded from the plaintext region between the access descriptor and the plain region, all applications built since [[5.0.0-11]] store the logo here. The size of this logo is always 0x2000-bytes.

The plain region mainly contains tags for each SDK library used when building the CXI. The version used for the "FIRMWARE" tag is the kernel/FIRM [[Configuration_Memory|version]], this version can also be stored in the exheader "kernel release version" ARM11 kernel descriptor field. As of [[2.2.0-X]] the NATIVE_FIRM kernels check the CXI exheader "kernel release version" field, if it is stored in the CXI exheader. If the kernel/FIRM version specified by this field is higher than the version of the running NATIVE_FIRM, the kernel will return error-code 0xD9001413.

=== NCCH Header ===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000
| 0x100
| RSA-2048 signature of the NCCH header, using SHA-256.
|-
| 0x100
| 4
| Magic ID, always 'NCCH'
|-
| 0x104
| 4
| Content size, in media units (1 media unit = 0x200 bytes)
|-
| 0x108
| 8
| Partition ID
|-
| 0x110
| 2
| Maker code
|-
| 0x112
| 2
| Version
|-
| 0x114
| 4
| When ncchflag[7] = 0x20 starting with FIRM [[9.6.0-24|9.6.0-X]], this is compared with the first output u32 from a SHA256 hash. The data used for that hash is 0x18-bytes: <0x10-long title-unique content lock seed> <programID from NCCH+0x118>. This hash is only used for verification of the content lock seed, and is not the actual keyY.
|-
| 0x118
| 8
| Program ID
|-
| 0x120
| 0x10
| Reserved
|-
| 0x130
| 0x20
| Logo Region SHA-256 hash. (For applications built with SDK 5+) (Supported from firmware: [[5.0.0-11]])
|-
| 0x150
| 0x10
| Product code
|-
| 0x160
| 0x20
| Extended header SHA-256 hash (SHA256 of 2x Alignment Size, beginning at 0x0 of ExHeader)
|-
| 0x180
| 4
| Extended header size, in bytes
|-
| 0x184
| 4
| Reserved
|-
| 0x188
| 8
| Flags (See Below)
|-
| 0x190
| 4
| Plain region offset, in media units
|-
| 0x194
| 4
| Plain region size, in media units
|-
| 0x198
| 4
| Logo Region offset, in media units (For applications built with SDK 5+) (Supported from firmware: [[5.0.0-11]])
|-
| 0x19c
| 4
| Logo Region size, in media units (For applications built with SDK 5+) (Supported from firmware: [[5.0.0-11]])
|-
| 0x1A0
| 4
| ExeFS offset, in media units
|-
| 0x1A4
| 4
| ExeFS size, in media units
|-
| 0x1A8
| 4
| ExeFS hash region size, in media units
|-
| 0x1AC
| 4
| Reserved
|-
| 0x1B0
| 4
| RomFS offset, in media units
|-
| 0x1B4
| 4
| RomFS size, in media units
|-
| 0x1B8
| 4
| RomFS hash region size, in media units
|-
| 0x1BC
| 4
| Reserved
|-
| 0x1C0
| 0x20
| ExeFS superblock SHA-256 hash - (SHA-256 hash, starting at 0x0 of the ExeFS over the number of media units specified in the ExeFS hash region size)
|-
| 0x1E0
| 0x20
| RomFS superblock SHA-256 hash - (SHA-256 hash, starting at 0x0 of the RomFS over the number of media units specified in the RomFS hash region size)
|}

Given offsets are based on the start of the file.

=== NCCH Flags ===
{| class="wikitable" border="1"
|-
! INDEX
! DESCRIPTION
|-
| 3
| Crypto Method: When this is non-zero, a NCCH crypto method using two keyslots is used(see above).
|-
| 4
| Content Platform: 1 = CTR, 2 = snake (New 3DS).
|-
| 5
| Content Type Bit-masks: Data = 0x1, Executable = 0x2, SystemUpdate = 0x4, Manual = 0x8, Child = (0x4<nowiki>|</nowiki>0x8), Trial = 0x10. When 'Data' is set, but not 'Executable', NCCH is a CFA. Otherwise when 'Executable' is set, NCCH is a CXI.
|-
| 6
| Content Unit Size i.e. u32 ContentUnitSize = 0x200*2^flags[6];
|-
| 7
| Bit-masks: FixedCryptoKey = 0x1, NoMountRomFs = 0x2, NoCrypto = 0x4, using a new keyY generator = 0x20(starting with FIRM [[9.6.0-24|9.6.0-X]]).
|}
CXIs NCCH header signature is verified using the RSA public key stored in the accessdesc,(which follows the exheader) while CFAs NCCH header is verified with a fixed RSA public key.

==== NCCH header example for Lego Starwars III ====
Signature: 720FF8F83F2A1E998322A026D1434165
ED19642ABC1CB2722135AA202BEAD60A
80BCD21C768C597B8268FEF2C64EA710
4C9BA5E12CFFBD1D0C619F4EF7B42CA7
DD8482CB4EB26720AD66CDA57ABCBCFB
D63268A6E2896A59B3B744E39E45B88A
ABB4C0980ACC6210818DCE6DAC838A10
95D0F66B352474D4B3DA4B333F49912D
29AF7EA58BC8C890B18C70B7D540A9FB
EBE24A5312055617D3353B28C3EB1D17
61021BEFF6AD22C384835B40BD44DFAD
981F6350F9458B17BCB5F768C92ABC93
2BCE9888855A8998F4CDE40C9543514A
C57B84EB75A680E7C742632614620D1D
A253284DF3DC01091EB3800C36FD62EE
BA15340F1FD498FAB67C0302E9CDA397
Magic: NCCH
Content size: 0x1cfef400
Partition id: 0004000000038c00
Maker code: 3436 ("46")
Version: 0002
Program id: 0004000000038c00
Temp flag: 00
Product code: CTR-P-ALGP
Extended header hash: 0C27E3C1DE7B2AE2D3114F32A4EEBF46
9AFD0CF352C11D4984C2A9F1D2144C63
Extended header size: 00000400
Flags: 0000030100000000
Plain region offset: 0x00004a00
Plain region size: 0x00000200
ExeFS offset: 0x00004c00
ExeFS size: 0x00143800
ExeFS hash region size: 0x00000200
RomFS offset: 0x00148400
RomFS size: 0x1ceab000
RomFS hash region size: 0x00000200
ExeFS Superblock Hash: 130C042615F647C4C63225EA9E67F8A2
7B15246B88FBC7A927257B84977B787B
RomFS Superblock Hash: A65BEE1060BB6A6821BBCEC600035B7E
64FB6EACA7F0960CFB1F5A37087728F7
Note: Offsets and sizes in media units have been converted to byte sizes.

==== Plain region example for Lego Starwars III ====
0004a00: 5b 53 44 4b 2b 4e 49 4e 54 45 4e 44 4f 3a 43 54 [SDK+NINTENDO:CT [SDK+NINTENDO:CTR_SDK-0_14_23_200_none]
0004a10: 52 5f 53 44 4b 2d 30 5f 31 34 5f 32 33 5f 32 30 R_SDK-0_14_23_20
0004a20: 30 5f 6e 6f 6e 65 5d 00 5b 53 44 4b 2b 4e 49 4e 0_none].[SDK+NIN [SDK+NINTENDO:Firmware-02_27]
0004a30: 54 45 4e 44 4f 3a 46 69 72 6d 77 61 72 65 2d 30 TENDO:Firmware-0
0004a40: 32 5f 32 37 5d 00 5b 53 44 4b 2b 4d 6f 62 69 63 2_27].[SDK+Mobic [SDK+Mobiclip:Deblocker_1_0_2]
0004a50: 6c 69 70 3a 44 65 62 6c 6f 63 6b 65 72 5f 31 5f lip:Deblocker_1_
0004a60: 30 5f 32 5d 00 5b 53 44 4b 2b 4d 6f 62 69 63 6c 0_2].[SDK+Mobicl [SDK+Mobiclip:ImaAdpcmDec_1_0_0]
0004a70: 69 70 3a 49 6d 61 41 64 70 63 6d 44 65 63 5f 31 ip:ImaAdpcmDec_1
0004a80: 5f 30 5f 30 5d 00 5b 53 44 4b 2b 4d 6f 62 69 63 _0_0].[SDK+Mobic [SDK+Mobiclip:MobiclipDec_1_0_1]
0004a90: 6c 69 70 3a 4d 6f 62 69 63 6c 69 70 44 65 63 5f lip:MobiclipDec_
0004aa0: 31 5f 30 5f 31 5d 00 5b 53 44 4b 2b 4d 6f 62 69 1_0_1].[SDK+Mobi [SDK+Mobiclip:MoflexDemuxer_1_0_2]
0004ab0: 63 6c 69 70 3a 4d 6f 66 6c 65 78 44 65 6d 75 78 clip:MoflexDemux
0004ac0: 65 72 5f 31 5f 30 5f 32 5d 00 00 00 00 00 00 00 er_1_0_2].......
0004ad0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0004ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

==== Example dependency list from the extended header ====
00850 41 50 54 3A 55 00 00 00 24 68 69 6F 46 49 4F 00 APT:U...$hioFIO.
00860 24 68 6F 73 74 69 6F 30 24 68 6F 73 74 69 6F 31 $hostio0$hostio1
00870 61 63 3A 75 00 00 00 00 62 6F 73 73 3A 55 00 00 ac:u....boss:U..
00880 63 61 6D 3A 75 00 00 00 63 65 63 64 3A 75 00 00 cam:u...cecd:u..
00890 63 66 67 3A 75 00 00 00 64 6C 70 3A 46 4B 43 4C cfg:u...dlp:FKCL
008A0 64 6C 70 3A 53 52 56 52 64 73 70 3A 3A 44 53 50 dlp:SRVRdsp::DSP
008B0 66 72 64 3A 75 00 00 00 66 73 3A 55 53 45 52 00 frd:u...fs:USER.
008C0 67 73 70 3A 3A 47 70 75 68 69 64 3A 55 53 45 52 gsp::Gpuhid:USER
008D0 68 74 74 70 3A 43 00 00 6D 69 63 3A 75 00 00 00 http:C..mic:u...
008E0 6E 64 6D 3A 75 00 00 00 6E 65 77 73 3A 75 00 00 ndm:u...<nowiki>news:u..</nowiki>
008F0 6E 77 6D 3A 3A 55 44 53 70 74 6D 3A 75 00 00 00 nwm::UDSptm:u...
00900 70 78 69 3A 64 65 76 00 73 6F 63 3A 55 00 00 00 pxi:dev.soc:U...
00910 73 73 6C 3A 43 00 00 00 79 32 72 3A 75 00 00 00 ssl:C...y2r:u...
00920 69 72 3A 55 53 45 52 00 6C 64 72 3A 72 6F 00 00 ir:USER.ldr:ro..
00930 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00940 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00950 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00960 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
... ...
009D0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
009E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
009F0 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 02 . .............

== Tools ==

[https://github.com/profi200/Project_CTR/tree/master/ctrtool ctrtool] - (CMD)(Windows/Linux) Parsing and decrypting (debug only) NCCH files

GPU/External Registers

2018-01-12T06:49:09Z

Qyriad: /* Map */ Clarify address mappings

This page describes the address range accessible from the ARM11, used to configure the basic GPU functionality. For information about the internal registers used for 3D rendering, see [[GPU/Internal Registers]].

== Map ==
Address mappings for the external registers. GSPGPU:WriteHWRegs takes these addresses relative to 0x1EB00000.
{| class="wikitable" border="1"
! User VA
! PA
! Length
! Name
! Comments
|-
| 0x1EF00004
| 0x10400004
| 4
| ?
|
|-
| 0x1EF00010
| 0x10400010
| 16
| [[#Memory Fill|Memory Fill1]] "PSC0"
| GX command 2
|-
| 0x1EF00020
| 0x10400020
| 16
| [[#Memory Fill|Memory Fill2]] "PSC1"
| GX command 2
|-
| 0x1EF00030
| 0x10400030
| 4
| ?
|
|-
| 0x1EF00034
| 0x10400034
| 4
| GPU Busy
| Bit31 = cmd-list busy, bit27 = PSC0 busy, bit26 = PSC1 busy.
|-
| 0x1EF00050
| 0x10400050
| 4
| ?
| Writes 0x22221200 on GPU init.
|-
| 0x1EF00054
| 0x10400054
| 4
| ?
| Writes 0xFF2 on GPU init.
|-
| 0x1EF000C0
| 0x104000C0
| 4
| Backlight control
| Writes 0x0 to allow backlights to turn off, 0x20000000 to force them always on.
|-
| 0x1EF00400
| 0x10400400
| 0x100
| [[#LCD Source Framebuffer Setup|Framebuffer Setup]] "PDC0" (top screen)
|
|-
| 0x1EF00500
| 0x10400500
| 0x100
| [[#LCD Source Framebuffer Setup|Framebuffer Setup]] "PDC1" (bottom)
|
|-
| 0x1EF00C00
| 0x10400C00
| ?
| [[#Transfer_Engine|Transfer Engine]] "DMA"
|
|-
| 0x1EF01000
| 0x10401000
| 0x4
| ?
| Writes 0 on GPU init and before the Command List is used
|-
| 0x1EF01080
| 0x10401080
| 0x4
| ?
| Writes 0x12345678 on GPU init.
|-
| 0x1EF010C0
| 0x104010C0
| 0x4
| ?
| Writes 0xFFFFFFF0 on GPU init.
|-
| 0x1EF010D0
| 0x104010D0
| 0x4
| ?
| Writes 1 on GPU init.
|-
| 0x1EF014??
| 0x104014??
| 0x14
| "PPF" ?
|
|-
| 0x1EF018E0
| 0x104018E0
| 0x14
| [[#Command_List|Command List]] "P3D"
|
|}

== Memory Fill ==
{| class="wikitable" border="1"
! User VA
! Description
|-
| 0x1EF000X0
| Buffer start physaddr >> 3
|-
| 0x1EF000X4
| Buffer end physaddr >> 3
|-
| 0x1EF000X8
| Fill value
|-
| 0x1EF000XC
| Control. bit0: start/busy, bit1: finished, bit8-9: fill-width (0=16bit, 1=3=24bit, 2=32bit)
|}

Memory fills are used to initialize buffers in memory with a given value, similar to memset. A memory fill is triggered by setting bit0 in the control register. Doing so aborts any running memory fills on that filling unit. Upon completion, the hardware unsets bit0 and sets bit1 and fires interrupt PSC0.

These registers are used by [[GSP Shared Memory#GX SetMemoryFill|GX SetMemoryFill]].

== LCD Source Framebuffer Setup ==
{| class="wikitable" border="1"
! Offset
! Length
! Name
! Comments
|-
| 0x00
| 4
| Pixel timer (not pixel clock)
| Higher values are slower, min. 0x1C1, bitmask 0xFFF
|-
| 0x04
| 4
| HDispStart(?)
| Values 0xD1-0x1C1 inclusive are valid (except 2DS bottom screen)
min. 0xD1, bitmask 0xFFF
|-
| 0x08
| 4
| ?
| must be >= REG#0x00
|-
| 0x0C
| 4
| ?
| must be >= REG#0x08
|-
| 0x10
| 4
| VAdjustGranule(?) or VBackPorch(?)

or
VAdjust(2DS bottom screen)

Seems to offset pixels relative to someting

(last row of pixels blitted increases by this amount;

setting this to lower than 2 will kill the screen timing)
| Finetune vertical pixel offset(blur screen), 0x1C2 max = half pixel

or (2DS)
offset the bottom screen (0 to kill top screen, 0x1C2 max on bottom screen)
|-
| 0x14
| 4
| HStartMin(?) (poor 2DS emulation)
| if this value is bigger than some value then it'll trim the first (value - this value) pixels from every line

default value is 0xCF
|-
| 0x18
| 4
| ???
| should be < REG#0x10
|-
| 0x20
| 4
| HFrontPorch(?)
| ??? the screen gets vertically offset with wrap-around
horizontal timing gets messed up
|-
| 0x24
| 4
| HSync timer?
|
|-
| 0x28
| 4
| VDispStart(?) or VFrontPorch
|
|-
| 0x30
| 4
| VTotal
| Total amount of vertical scanlines
|-
| 0x34
| 4
| VDisp(?)
| Total amonut of vertical scanlines displayed (only for top screen it seems like)
|-
| 0x44
| 4
| ???
| similar functionality to 0x10
|-
| 0x4C
| 4
| Overscan filler color
|
|-
| 0x50
| 4
| Horizontal position counter
| read-only
|-
| 0x54
| 4
| Horizontal scanline (HBlank) counter
| read-only
|-
| 0x5C
| 4
| ???
| low u16: framebuffer width
high u16: framebuffer height??? (seems to be unused)
|-
| 0x60
| 4
| ???
| low u16: timing data(?)
high u16: framebuffer total width (amount of pixels blitted regardless of framebuffer width)
|-
| 0x64
| 4
| ???
| low u16: unknown
high u16: framebuffer total height (amount of scanlines blitted regardless of framebuffer height)
|-
| 0x68
| 4
| Framebuffer A first address
| For top screen, this is the left eye 3D framebuffer.
|-
| 0x6C
| 4
| Framebuffer A second address
| For top screen, this is the left eye 3D framebuffer.
|-
| 0x70
| 4
| Framebuffer format
| Bit0-15: framebuffer format, bit16-31: unknown
|-
| 0x78
| 4
| Framebuffer select
| Bit0: which framebuffer to display, bit1-7: unknown
|-
| 0x80
| 4
| Color lookup table index select
| 8bits, write-only
|-
| 0x84
| 4
| Color lookup table indexed element
| Contains the value of the color lookup table indexed by the above register, 24bits, RGB8 (0x00BBGGRR)
Accessing this register will increase the index register by one
|-
| 0x90
| 4
| Framebuffer stride
| Distance in bytes between the start of two framebuffer rows (must be a multiple of 8).
|-
| 0x94
| 4
| Framebuffer B first address
| For top screen, this is the right eye 3D framebuffer. Unused for bottom screen.
|-
| 0x98
| 4
| Framebuffer B second address
| For top screen, this is the right eye 3D framebuffer. Unused for bottom screen.
|}

=== Framebuffer format ===
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 2-0
| Color format
|-
| 3
| ?
|-
| 4
| Unused?
|-
| 5
| Enable parallax barrier (i.e. 3D).
|-
| 6
| 1 = main screen, 0 = sub screen. However if bit5 is set, this bit is cleared.
|-
| 7
| ?
|-
| 9-8
| Value 1 = unknown: get rid of rainbow strip on top of screen, 3 = unknown: black screen.
|-
| 15-10
| Unused?
|}

GSP module only allows the LCD stereoscopy to be enabled when bit5=1 and bit6=0 here. When GSP module updates this register, GSP module will automatically disable the stereoscopy if those bits are not set for enabling stereoscopy.

=== Framebuffer color formats ===
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| GL_RGBA8_OES
|-
| 1
| GL_RGB8_OES
|-
| 2
| GL_RGB565_OES
|-
| 3
| GL_RGB5_A1_OES
|-
| 4
| GL_RGBA4_OES
|}
Color components are laid out in reverse byte order, with the most significant bits used first (i.e. non-24-bit pixels are stored as a little-endian values). For instance, a raw data stream of two GL_RGB565_OES pixels looks like GGGBBBBB RRRRRGGG GGGBBBBB RRRRRGGG.

== Transfer Engine ==
{| class="wikitable" border="1"
! Register address
! Description
|-
| 0x1EF00C00
| Input physical address >> 3
|-
| 0x1EF00C04
| Output physical address >> 3
|-
| 0x1EF00C08
| DisplayTransfer output width (bits 0-15) and height (bits 16-31).
|-
| 0x1EF00C0C
| DisplayTransfer input width and height.
|-
| 0x1EF00C10
| Transfer flags. (See below)
|-
| 0x1EF00C14
| GSP module writes value 0 here prior to writing to 0x1EF00C18, for cmd3.
|-
| 0x1EF00C18
| Setting bit0 starts the transfer. Upon completion, bit0 is unset and bit8 is set.
|-
| 0x1EF00C1C
| ?
|-
| 0x1EF00C20
| TextureCopy total amount of data to copy, in bytes.
|-
| 0x1EF00C24
| TextureCopy input line width (bits 0-15) and gap (bits 16-31), in 16 byte units.
|-
| 0x1EF00C28
| TextureCopy output line width and gap.
|}

These registers are used by [[GSP_Shared_Memory|GX command]] 3 and 4. For cmd4, *0x1EF00C18 |= 1 is used instead of just writing value 1. The DisplayTransfer registers are only used if bit 3 of the flags is unset and ignored otherwise. The TextureCopy registers are likewise only used if bit 3 is set, and ignored otherwise.

==== Flags Register - 0x1EF00C10 ====
{| class="wikitable" border="1"
! Bit
! Description
|-
| 0
| When set, the framebuffer data is flipped vertically.
|-
| 1
| When set, the input framebuffer is treated as linear and converted to tiled in the output, converts tiled->linear when unset.
|-
| 2
| This bit is required when the output width is less than the input width for the hardware to properly crop the lines, otherwise the output will be mis-aligned.
|-
| 3
| Uses a TextureCopy mode transfer. See below for details.
|-
| 4
| Not writable
|-
| 5
| Don't perform tiled-linear conversion. Incompatible with bit 1, so only tiled-tiled transfers can be done, not linear-linear.
|-
| 7-6
| Not writable
|-
| 10-8
| Input framebuffer color format, value0 and value1 are the same as the [[GPU Registers#Framebuffer_color_formats|LCD Source Framebuffer Formats]] (usually zero)
|-
| 11
| Not writable
|-
| 14-12
| Output framebuffer color format
|-
| 15
| Not writable
|-
| 16
| Use 32x32 block tiling mode, instead of the usual 8x8 one. Output dimensions must be multiples of 32, even if cropping with bit 2 set above.
|-
| 17-23
| Not writable
|-
| 24-25
| Scale down the input image using a box filter. 0 = No downscale, 1 = 2x1 downscale. 2 = 2x2 downscale, 3 = invalid
|-
| 31-26
| Not writable
|}

=== TextureCopy ===

When bit 3 of the control register is set, the hardware performs a TextureCopy-mode transfer. In this mode, all other bits of the control register (except for bit 2, which still needs to be set correctly) and the regular dimension registers are ignored, and no format conversions are done. Instead, it performs a raw data copy from the source to the destination, but with a configurable gap between lines. The total amount of bytes to copy is specified in the size register, and the hardware loops reading lines from the input and writing them to the output until this amount is copied. The "gap" specified in the input/output dimension register is the number of chunks to skip after each "width" chunks of the input/output, and is NOT counted towards the total size of the transfer.

By correctly calculating the input and output gap sizes it is possible to use this functionality to copy arbitrary sub-rectangles between differently-sized framebuffers or textures, which is one of its main uses over a regular no-conversion DisplayTransfer. When copying tiled textures/framebuffers it's important to remember that the contents of a tile are laid out sequentially in memory, and so this should be taken into account when calculating the transfer parameters.

Specifying invalid/junk values for the TextureCopy dimensions can result in the GPU hanging while attempting to process this TextureCopy.

== Command List ==
{| class="wikitable" border="1"
! Register address
! Description
|-
| 0x1EF018E0
| Buffer size in bytes >> 3
|-
| 0x1EF018E8
| Buffer physical address >> 3
|-
| 0x1EF018F0
| Setting bit0 to 1 enables processing GPU command execution. Upon completion, bit0 seems to be reset to 0.
|}

These 3 registers are used by [[GSP_Shared_Memory|GX command]] 1. This is used for [[GPU/Internal_Registers|GPU commands]].

== Framebuffers ==
These LCD framebuffers normally contain the last rendered frames from the GPU. The framebuffers are drawn from left-to-right, instead of top-to-bottom.(Thus the beginning of the framebuffer is drawn starting at the left side of the screen)

Both of the 3D screen left/right framebuffers are displayed regardless of the 3D slider's state, however when the 3D slider is set to "off" the 3D effect is disabled. Normally when the 3D slider's state is set to "off" the left/right framebuffer addresses are set to the same physical address. When the 3D effect is disabled and the left/right framebuffers are set to separate addresses, the LCD seems to alternate between displaying the left/right framebuffer each frame.

==== Init Values from nngxInitialize for Top Screen ====
* 0x1EF00400 = 0x1C2
* 0x1EF00404 = 0xD1
* 0x1EF00408 = 0x1C1
* 0x1EF0040C = 0x1C1
* 0x1EF00410 = 0
* 0x1EF00414 = 0xCF
* 0x1EF00418 = 0xD1
* 0x1EF0041C = 0x1C501C1
* 0x1EF00420 = 0x10000
* 0x1EF00424 = 0x19D
* 0x1EF00428 = 2
* 0x1EF0042C = 0x1C2
* 0x1EF00430 = 0x1C2
* 0x1EF00434 = 0x1C2
* 0x1EF00438 = 1
* 0x1EF0043C = 2
* 0x1EF00440 = 0x1960192
* 0x1EF00444 = 0
* 0x1EF00448 = 0
* 0x1EF0045C = 0x19000F0
* 0x1EF00460 = 0x1c100d1
* 0x1EF00464 = 0x1920002
* 0x1EF00470 = 0x80340
* 0x1EF0049C = 0

==== More Init Values from nngxInitialize for Top Screen ====
* 0x1EF00468 = 0x18300000, later changed by GSP module when updating state, framebuffer
* 0x1EF0046C = 0x18300000, later changed by GSP module when updating state, framebuffer
* 0x1EF00494 = 0x18300000
* 0x1EF00498 = 0x18300000
* 0x1EF00478 = 1, doesn't stay 1, read as 0
* 0x1EF00474 = 0x10501

[[Category:GPU]]

SMDH

2017-06-19T13:35:39Z

Qyriad: /* Icon graphics */ Notes that Nintendo stores pixel data in word-order

This page describes the format of the icon stored at [[NCCH#CXI|CXI]] ExeFS:/icon and [[CIA]] icons.
The size of icons is 0x36c0 bytes. The CXI icon is displayed by [[Home Menu]] and [[System Settings]](3DS Software Management), while [[CIA#Meta|CIA icons]] are dummies and not yet utilised by Dev 3DS' (as of rev 47586).

== Format ==

{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x00
| 0x04
| Magic 'SMDH'
|-
| 0x04
| 0x02
| Version
|-
| 0x06
| 0x02
| Reserved
|-
| 0x8
| 0x2000
| 16 application titles structs, each 0x200 bytes
|-
| 0x2008
| 0x30
| Application Settings
|-
| 0x2038
| 0x8
| Reserved
|-
| 0x2040
| 0x1680
| Icon graphics
|}

== Application Titles ==

{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x00
| 0x80
| Short Description
|-
| 0x80
| 0x100
| Long Description
|-
| 0x180
| 0x80
| Publisher
|}

All encoded in UTF-16.
There are 16 app title structs(currently only 12 are used), each one for separate languages.

The languages by order of appearance:

* 1st: Japanese title name
* 2nd: English title name
* 3rd: French title name
* 4th: German title name
* 5th: Italian title name
* 6th: Spanish title name
* 7th: Simplified Chinese title name
* 8th: Korean title name
* 9th: Dutch title name
* 10th: Portuguese title name
* 11th: Russian title name
* 12th: Traditional Chinese title name

== Application Settings ==

Most of these flags are only used by the [[Home Menu]]. All of these are represented in SMDH files in little endian. But when documented below, the tables represent values in big endian.

{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x2008
| 0x10
| Region Specific Game Ratings (For use with Parental Controls)
|-
| 0x2018
| 0x4
| Region Lockout
|-
| 0x201C
| 0xC
| Match Maker IDs (Online Play)
|-
| 0x2028
| 0x4
| Flags
|-
| 0x202C
| 0x2
| EULA Version
|-
| 0x202E
| 0x2
| Reserved
|-
| 0x2030
| 0x4
| 'Optimal Animation Default Frame' (for BNR)
|-
| 0x2034
| 0x4
| CEC (StreetPass) ID (So the Home Menu knows which application icon to show the 'Green' CEC notification for)
|}

=== Region Specific Game Age Ratings ===

These flags tell the 3DS the 'Age Rating' of the software for the below regions:

{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x2008
| 0x1
| CERO (Japan)
|-
| 0x2009
| 0x1
| ESRB (USA)
|-
| 0x200A
| 0x1
| Reserved
|-
| 0x200B
| 0x1
| USK (German)
|-
| 0x200C
| 0x1
| PEGI GEN (Europe)
|-
| 0x200D
| 0x1
| Reserved
|-
| 0x200E
| 0x1
| PEGI PRT (Portugal)
|-
| 0x200F
| 0x1
| PEGI BBFC (England)
|-
| 0x2010
| 0x1
| COB (Australia)
|-
| 0x2011
| 0x1
| GRB (South Korea)
|-
| 0x2012
| 0x1
| CGSRR (Taiwan)
|-
| 0x2013
| 0x1
| Reserved
|-
| 0x2014
| 0x1
| Reserved
|-
| 0x2015
| 0x1
| Reserved
|-
| 0x2016
| 0x1
| Reserved
|-
| 0x2017
| 0x1
| Reserved
|}

Active ratings have a bitmask of 0x80, and inactive ratings have no bitmask at all. Ratings without the 0x80 bitmask are ignored. 0x40 bitmask indicates Rating Pending. 0x20 bitmask indicates No Age Restriction.
Age limits are set by adding the minimal age to 0x80 (for example, limiting to 12 years and up would give a bitmask of 0x8C)

=== Region Lockout ===

This u32 flag is what the Home Menu uses to determine the [[Home Menu#Region Lockout|Region Lockout]] of a title.

{| class="wikitable" border="1"
|-
! REGION
! BITMASK
|-
| Japan
| 0x01
|-
| North America
| 0x02
|-
| Europe
| 0x04
|-
| Australia
| 0x08
|-
| China
| 0x10
|-
| Korea
| 0x20
|-
| Taiwan
| 0x40
|}

Regions are 'included' in region lock by setting their bitmask value. Nintendo defines region free as 0x7fffffff. Early in the 3DS' development, Nintendo grouped the Australian and Europe markets together. Nintendo defines market Europe as having the combined bitmasks of Europe and Australia. No 3DS' which check the Australia bitmask have been seen (Australia uses the European 3DS model).

=== Match Maker IDs ===

These IDs are an application's online gaming IDs.

{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x201C
| 0x4
| Match Maker ID
|-
| 0x2020
| 0x8
| Match Maker BIT ID
|}

=== Flags ===
The u32 is used for storing flags as bit-masks.

{| class="wikitable" border="1"
|-
! FLAG
! BITMASK VALUE
|-
| Visibility Flag (Required for visibility on the Home Menu)
| 0x0001
|-
| [[Home Menu#Auto-Boot_Function|Auto-boot]] this gamecard title
| 0x0002
|-
| Allow use of 3D? (For use with parental Controls. An application can use the 3D affect, even when this flag isn't set)
| 0x0004
|-
| Require accepting CTR EULA before being launched by Home (see below)
| 0x0008
|-
| Autosave on exit? (see below)
| 0x0010
|-
| Uses an [[Extended Banner]]?
| 0x0020
|-
| [[SMDH#Region Specific Game Age Ratings|Region game rating]] required
| 0x0040
|-
| Uses save data? (see below)
| 0x0080
|-
| Application usage is to be recorded. If this is not set, it causes the application's usage to be omitted from the Home Menu's [[Home_Menu#Cache.dat & CacheD.dat|icon cache]], as well as in [[????????|other places]].
| 0x0100
|-
| Disables [[SD Savedata Backups]] for this title. This is in addition to [[NS CFA|the blacklist]].
| 0x0400
|-
| New 3DS exclusive title. Shows an error if used on Old 3DS.
| 0x1000
|}

====Effect of SaveData and AutoSave====

These options have no effect on the performance of the application itself: they're used to select an appropriate warning when closing an application from [[Home Menu|Home]].

* Both off: "Closing software" (no warning if quitting directly with X)
* SaveData: "Do you want to close [...]? (Unsaved data will be lost.)"
* AutoSave: ?
* Both on: "Saving data and closing software..." (no warning if quitting directly with X)

=== EULA Version ===
This is the EULA version which is checked when the Accept EULA flag is set, the version is compared to one stored in the 3DS. If the SMDH version is greater, then the user will be prompted to accept the EULA.

{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x202C
| 0x01
| EULA Version Minor
|-
| 0x202D
| 0x01
| EULA Version Major
|}

=== 'Optimal Animation Default Frame' (for BNR) ===

This is a float, indicating the preferred (or 'most representative') frame for the banner animation.

=== CEC (StreetPass) ID ===

This u32 represents the application CEC ID. This is likely loaded by applications for use with the CEC services as well.

== Icon graphics ==

At offset 0x2040, there are two icons:
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x2040
| 0x480
| Small - 24x24 (shown on top screen when pausing the app)
|-
| 0x24C0
| 0x1200
| Large - 48x48 icon (the general icon)
|}

Both of the icons are encoded in RGB565 meaning 16bpp. Although both icons are known to be RGB565, developers have the option of encoding icons (and banners) with the following encodings :

* RGBA8
* RGB8
* RGBA5551
* RGB565
* RGBA4
* LA8
* HILO8
* L8
* A8
* LA4
* L4
* ETC1
* ETC1A4

This does not necessarily mean the other encodings will be used, it is just that those are the options when compiling. Like we've seen with Super Mario 3D Land Nintendo has changed save file encryption, and likewise they can encode icons and banners differently ''should they choose to''. Currently we've seen just RGB565 so don't be fooled if an icon doesn't show up right! It is probably one of these formats above. Although we will probably not see other formats used for a while it's nice to know they have an opportunity to change. Also note that it seems Nintendo stores each pixel in [https://en.wikipedia.org/wiki/RGBA_color_space word-order], so the actual order of order of each color channel in memory will depend on the endianness.

The data is encoded in tiles (starting from size 8x8, continuing recursively).

If the buffer is like this:

{| class="wikitable" border="1"
|-
! 0
! 1
! 2
! 3
! 4
! 5
! 6
! 7
! 8
! 9
! 10
! 11
! 12
! 13
! 14
! 15
! 16
|-
|}

Then the image would look like this:

{| class="wikitable" border="1"
|-
! x=0
! x=1
! x=2
! x=3
! x=4
|-
| 0
| 1
| 4
| 5
| 16
|-
| 2
| 3
| 6
| 7
| ...
|-
| 8
| 9
| 12
| 13
|-
| 10
| 11
| 14
| 15
|-
|}

== Tools ==

[[CiTRUS]] - (GUI)(Windows Only) Generating ICN files

[[3DSExplorer]] - (GUI)(Windows Only) Parsing ICN files

CGFX

2017-05-30T02:09:41Z

Qyriad: /* Links */ Fixed broken link with Wayback Machine

CGFX is a container format used to store graphics resources. It can contain 3D models, textures and animation data.

== CGFX ==

CGFX header :
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Magic "CGFX"
|-
| 0x4
| 0x2
| Byte order mark: FFFE (little endian) or FEFF (big endian)
|-
| 0x6
| 0x2
| CGFX header size
|-
| 0x8
| 0x4
| Version ?
|-
| 0xC
| 0x4
| File size (bytes)
|-
| 0x10
| 0x4
| Number of entries
|}

A typical CGFX file contains two main entries, beginning directly after the CGFX header: DATA and IMAG.

== DATA ==

DATA contains a list of DICT references.

DATA header (for N = 0..15) :
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Magic "DATA"
|-
| 0x4
| 0x4
| DATA Size (in bytes)
|-
| 0x8 +(N*8)
| 0x4
| Number of entries in DICT N
|-
| 0xC +(N*8)
| 0x4
| Offset (self-relative) to DICT N
|}

The DATA header contains the entry counts and offsets for each DICT entry. The number of entries can vary (probably based on the version?), but are always in the following order. Any unused entries are zeroed.

Typical entries:
{| class="wikitable"
|-
! N
! Type
|-
| 0
| Models
|-
| 1
| Textures
|-
| 2
| LUTS (Material/Color/Shader look-up tables?)
|-
| 3
| Unknown
|-
| 4
| Unknown
|-
| 5
| Cameras
|-
| 6
| Lights
|-
| 7
| Fog
|-
| 8
| Environments
|-
| 9
| Skeleton animations
|-
| 10
| Texture animations
|-
| 11
| Unknown animations
|-
| 12
| Unknown
|-
| 13
| Unknown
|-
| 14
| Unknown
|-
| 15
| Unknown
|}

== DICT ==

DICTs are generic structures used to store values (and associate them to a key ?). A DICT header is 0x1C bytes long.

DICT header :
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Magic "DICT"
|-
| 0x4
| 0x4
| DICT size (in bytes)
|-
| 0x8
| 0x4
| Number of entries
|-
| 0xC
| 0x10
| ?
|}

DICT entry:
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| ?
|-
| 0x4
| 0x2
| ?
|-
| 0x6
| 0x2
| ?
|-
| 0x8
| 0x4
| Offset (self-relative) to symbol
|-
| 0xC
| 0x4
| Offset (self-relative) to object
|}

== CMDL ==

CMDL is used to describe a 3D model.

CMDL Header :
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Flags (bit 7: hasSkeletonSobj)
|-
| 0x4
| 0x4
| Magic "CMDL"
|-
| 0x8
| 0x4
| ?
|-
| 0xC
| 0x4
| Offset (self-relative) to model name
|-
| 0x10
| 0x18
| ?
|-
| 0x28
| 0x4
| Number of entries in Animation Types DICT
|-
| 0x2C
| 0x4
| Offset (self-relative) to Animation Types DICT
|-
| 0x30
| 0xC
| Global scale vector (3 floats : x, y, z)
|-
| 0x3C
| 0x18
| ?
|-
| 0x54
| 0x30
| Matrix 1
|-
| 0x84
| 0x30
| Matrix 2
|-
| 0xB4
| 0x4
| Number of Vertex Info SOBJ entries
|-
| 0xB8
| 0x4
| Offset (self-relative) to Vertex Info SOBJ list
|-
| 0xBC
| 0x4
| Number of MTOB DICT entries
|-
| 0xC0
| 0x4
| Offset (self-relative) to MTOB DICT
|-
| 0xC4
| 0x4
| Number of Vertex Info SOBJ entries
|-
| 0xC8
| 0x4
| Offset (self-relative) to Vertex Info SOBJ list
|-
| 0xCC
| 0x4
| Number of Unknown DICT entries
|-
| 0xD0
| 0x4
| Offset (self-relative) to Unknown DICT
|-
| 0xD4
| 0xC
| ?
|-
| 0xE0
| 0x4
| Skeleton Info SOBJ offset (self-relative) [only present if flag bit 7 is set]
|-
| 0xB8+[0xB8]
| 0x4*N
| Vertex Info SOBJ self-relative offset list
|}

A CMDL section refers to outside data; it can not be considered separately from the rest of the CGFX file.
The second DICT in the CMDL section contains offsets to MTOB objects.

== SOBJ ==

SOBJ structures can be used to describe 3D objects that are part of the model. If such is the case then they will follow this structure :

{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Flags (bit 4: model; bit 1: skeleton)
|-
| 0x4
| 0x4
| Magic "SOBJ"
|-
| 0x8
| 0x4
| ?
|-
| 0xC
| 0x4
| Unknown symbol offset (self-relative)
|-
| 0x10
| 0xC
| ?
|-
| 0x1C
| 0x4
| Offset (self-relative) to Unknown1 (appears to hold array of floats) ?
|-
| 0x20
| 0xC
| Mesh position offset (X/Y/Z floats)
|-
| 0x2C
| 0x4
| Face groups count
|-
| 0x30
| 0x4
| Offset (self-relative) to face groups offset array
|-
| 0x34
| 0x4
| ?
|-
| 0x38
| 0x4
| Vertex groups count
|-
| 0x3C
| 0x4
| Offset (self-relative) to vertex groups offset array
|-
| 0x40
| 0x4
| Unknown offset (self-relative) ?
|}

Face groups:

{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Bone groups count
|-
| 0x4
| 0x4
| Offset (self-relative) to UInt32 bone group IDs array
|-
| 0x8
| 0x4
| ?
|-
| 0xC
| 0x4
| Unknown2 count
|-
| 0x10
| 0x4
| Offset (self-relative) to Unknown2 offset array
|}

Unknown2:

{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Face group descriptor count
|-
| 0x4
| 0x4
| Offset (self-relative) to face array descriptors offset array
|-
| 0x8
| 0x4
| Unknown3 count
|-
| 0xC
| 0x4
| Offset (self-relative) to UInt32 Unknown3 array
|-
| 0x10
| 0x8
| ?
|}

Face array descriptor:

{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Flags (bit 1: vertex index format: 0=byte, 1=short)
|-
| 0x4
| 0x4
| ?
|-
| 0x8
| 0x4
| Vertex index array size (in bytes)
|-
| 0xC
| 0x4
| Offset (self-relative) to vertex index array
|}

Vertex groups come in a number of different formats. Typically the first vertex group entry is of format 0x40000002 and contains the actual vertex array.

Vertex group format 0x40000002:

{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Flags (0x40000002)
|-
| 0x4
| 0x4
| ?
|-
| 0x8
| 0x4
| ?
|-
| 0xC
| 0x4
| ?
|-
| 0x10
| 0x4
| ?
|-
| 0x14
| 0x4
| Vertex array size (in bytes)
|-
| 0x18
| 0x4
| Offset (self-relative) to vertex array
|-
| 0x1C
| 0x4
| ?
|-
| 0x20
| 0x4
| ?
|-
| 0x24
| 0x4
| Vertex stride/size in bytes (see below)
|-
| 0x28
| 0x4
| Unknown3 count
|-
| 0x2C
| 0x4
| Offset (self-relative) to component declaration offset array
|}

Each mesh's primary vertex group contains an array of vertex component declaration objects, defining the order and parameters for each of a vertex's components.

Vertex component declaration:

{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Flags (0x40000001)
|-
| 0x4
| 0x4
| Vertex component type (see below)
|-
| 0x8
| 0x4
| ?
|-
| 0xC
| 0x4
| ?
|-
| 0x10
| 0x4
| ?
|-
| 0x14
| 0x4
| ?
|-
| 0x18
| 0x4
| ?
|-
| 0x1C
| 0x4
| ?
|-
| 0x20
| 0x4
| ?
|-
| 0x24
| 0x1
| Component data type (see below)
|-
| 0x25
| 0x1
| ?
|-
| 0x26
| 0x1
| ?
|-
| 0x27
| 0x1
| ?
|-
| 0x28
| 0x4
| Number of values in this component (e.g. XYZ->3, UV->2)
|-
| 0x2C
| 0x4
| Multiplier for this component's values (float)
|-
| 0x30
| 0x4
| Position of this component within vertex stride
|}

Vertex formats with bone data support multiple bone assignment. In this case, the sum of all bone weights is 0x64.

Vertex component types:

{| class="wikitable"
|-
! Value
! Type
|-
| 0x00
| Position
|-
| 0x01
| Normal
|-
| 0x02
| ? (unobserved)
|-
| 0x03
| Color
|-
| 0x04
| UV0
|-
| 0x05
| UV1
|-
| 0x06
| ? (unobserved, possibly UV2)
|-
| 0x07
| Weight
|-
| 0x08
| Index
|}

Vertex component data types:

{| class="wikitable"
|-
! Value
! Type
|-
| 0x00
| sbyte
|-
| 0x01
| byte
|-
| 0x02
| short
|-
| 0x03
| ? (unobserved, possibly ushort)
|-
| 0x04
| ? (unobserved, possibly int)
|-
| 0x05
| ? (unobserved, possibly uint)
|-
| 0x06
| float
|}

Vertex components are stored as one of the above data types, and the vertex component declaration contains a multiplier that adapts the values to the float version which the game will use.
For example, color RGBA values are stored as bytes, and the multiplier converts them from 0-255 to 0-1.0, and position components using short values are normalized via the multiplier to take advantage of the entire short value range.

== TXOB ==

TXOBs are contained within MTOBs. They can describe textures; if such is the case, then their structure is as follows :

{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Flags
|-
| 0x4
| 0x4
| Magic "TXOB"
|-
| 0x8
| 0x8
| ?
|-
| 0xC
| 0x4
| Offset (self-relative) to symbol
|-
| 0x18
| 0x4
| Texture height
|-
| 0x1C
| 0x4
| Texture width
|-
| 0x28
| 0x4
| Mipmap levels
|-
| 0x34
| 0x4
| Texture format ID (see table below)
|-
| 0x3C
| 0x4
| Texture height (?)
|-
| 0x40
| 0x4
| Texture width (?)
|-
| 0x44
| 0x4
| Texture data size
|-
| 0x48
| 0x4
| Texture data offset (self-relative)
|}

{| class="wikitable"
|-
! Texture format ID
! Description
|-
|0x0
|RGBA8
|-
|0x1
|RGB8
|-
|0x2
|RGBA5551
|-
|0x3
|RGB565
|-
|0x4
|RGBA4
|-
|0x5
|LA8
|-
|0x6
|HILO8
|-
|0x7
|L8
|-
|0x8
|A8
|-
|0x9
|LA4
|-
|0xA
|L4
|-
|0xB
|A4 ?
|-
|0xC
|ETC1 (see notes below)
|-
|0xD
|ETC1A4 ?
|}

Every texture format has its texture data divided into 8x8 tiles. See [[SMDH#Icon_graphics|SMDH]] for more information.
ETC1 is a compressed texture format which compresses blocks of 4x4 pixels into u64s. These u64 are traditionally stored in big endian; however, nintendo's implementation stores them in little endian. ETC1 textures are stored in 8x8 tiles; decompressed 4x4 therefore have to be organized accordingly. See [https://gist.github.com/smealum/8897237] for implementation example.

== LUTS ==

Appears to contain color lookup tables possibly for use with shaders.

LUTS Header:
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Magic "LUTS"
|-
| 0x4
| 0x2
| Seems to adhere to powers of 2 (width/height/flags?)
|-
| 0x6
| 0x2
| Seems to adhere to powers of 2 (width/height/flags?)
|-
| 0x8
| 0x4
| ?
|-
| 0xC
| 0x8
| all zeroes ?
|-
| 0x14
| 0x4
| ?
|-
| 0x18
| 0x4
| Offset to DICT (self-relative) ?
|}
All observed instances have an otherwise unreferenced DICT section immediately afterward (the last LUTS value being a 0x4, which may describe the relative position of that DICT), which appears to describe material specularity.

== Skeleton data ==

Skeleton data is stored in an array. Each entry is 0xE0 bytes in length and organized this way :

{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Offset (self relative) to name symbol
|-
| 0x4
| 0x4
| ?
|-
| 0x8
| 0x4
| Joint ID
|-
| 0xC
| 0x4
| Parent joint ID
|-
| 0x10
| 0x4
| Signed offset (self-relative) to parent joint
|-
| 0x2C
| 0xC
| Angle vector (floats, x, y, z)
|-
| 0x38
| 0xC
| Position vector (floats, x, y, z)
|-
| 0x44
| 0x30
| Transformation matrix (4x3)
|-
| 0x74
| 0x30
| Identity matrix ? (4x3)
|}

Each entry stores the joint transformation data twice; once as angle/position vectors and once as a transformation matrix. Each entry also stores a second matrix which appears to always be identity. (?)

== CANM ==

CANMs are used to store skeletal animation data.

== Links ==
* Another CGFX Format Description (Archived Page): [https://web.archive.org/web/20150511211029/http://florian.nouwt.com/wiki/index.php/CGFX_(File_Format) http://florian.nouwt.com/wiki/index.php/CGFX_(File_Format)]

[[Category:File formats]]