3dbrew - User contributions [en]

AM:GetProgramInfoFromCia

2025-09-20T09:54:13Z

PabloMK7:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x04080042]
|-
| 1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 2
| 0x0 (Send-handle translate header)
|-
| 3
| File Handle
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2-7
| [[AMNet:ListTitles|Title Info]]
|}

=Description=
This reads title information from a CIA file opened with [[Filesystem_services|fs:USER]]. Depending on the media type, this will return different title sizes. Official applications use double the title size.

AM:CommitImportProgramsAndUpdateFirmwareAuto

2025-04-17T10:30:35Z

PabloMK7:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x040E00C2]
|-
| 1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 2
| Title count
|-
| 3
| u8, cleanup (0 = no cleanup, 1 = cleanup)
|-
| 4
| ((Title Count * 8) << 4) <nowiki>|</nowiki> 0xA
|-
| 5
| Title IDs Pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
This is the same as [[AMNet:CommitImportTitlesAndUpdateFirmwareAuto]].

AM:CommitImportPrograms

2025-04-17T10:29:48Z

PabloMK7:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x040700C2]
|-
| 1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 2
| Title count
|-
| 3
| u8, cleanup (0 = no cleanup, 1 = cleanup)
|-
| 4
| ((Title Count * 8) << 4) <nowiki>|</nowiki> 0xA
|-
| 5
| Title IDs Pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
The input parameters for this are the same as [[AMNet:InstallTitlesFinish]]. This is an interface for [[Application_Manager_Services_PXI|AMPXI]] command 0x002A00C2. The AMPXI command used here only finalizes the install in the [[Title_Database|database]], the now-unused files under /title for the title(s) are not deleted by this. These files are deleted later.

AMNet:CommitImportTitlesAndUpdateFirmwareAuto

2025-04-17T10:27:55Z

PabloMK7:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x081B00C2]
|-
| 1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 2
| Title Count
|-
| 3
| u8, cleanup (0 = no cleanup, 1 = cleanup)
|-
| 4
| ((Title Count * 8) << 4) <nowiki>|</nowiki> 0xA
|-
| 5
| Title IDs Input Pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
See [[Title_Data_Structure|this]] for how the system finalizes title installation. When AM module handles this command, AM module will use [[Application_Manager_Services_PXI|AMPXI]] command 0x00420142 if a NATIVE_FIRM install is [[AM:UpdateFirmwareAuto|needed]], regardless of whether the NATIVE_FIRM titleID was specified in the input buffer. If the NATIVE_FIRM titleID was specified in the input titleID list and the title-version from [[AMPXI:GetTitleList]] is the latest version, then if the version from [[AMPXI:GetTitleTemporaryInfo]] is newer than the current version [[Application_Manager_Services_PXI|AMPXI]] command 0x00420142 is used. Otherwise when a NATIVE_FIRM install is not needed, [[Application_Manager_Services_PXI|AMPXI]] command 0x002A00C2 is used instead.

AMNet:CommitImportTitles

2025-04-17T10:27:13Z

PabloMK7:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x080900C2]
|-
| 1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 2
| Title count
|-
| 3
| u8, cleanup (0 = no cleanup, 1 = cleanup)
|-
| 4
| ((Title Count * 8) << 4) <nowiki>|</nowiki> 0xA
|-
| 5
| Title IDs Pointer
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
See [[Title_Data_Structure|this]] for how the system finalizes title installation.

GPU/Internal Registers

2025-03-17T11:32:27Z

PabloMK7:

[[Category:GPU]]

== Overview ==

GPU internal registers are written to through GPU commands. They are used to control the GPU's behavior, that is to say tell it to draw stuff and how we want it drawn.

Each command is at least 8 bytes wide. The first word is the command parameter and the second word constitutes the command header. Optionally, more parameter words may follow (potentially including a padding word to align commands to multiples of 8 bytes).

In the simplest case, a command is exactly 8 bytes wide. You can think of such a command as writing the parameter word to an internal register (the index of which is given in the command header). The more general case where more than one parameter word is given is equivalent to multiple simple commands (one for each parameter word). If consecutive writing mode is enabled in the command header, the current command index will be incremented after each parameter write. Otherwise, the parameters will be consecutively written to the same register.

For example, the sequence "0xAAAAAAAA 0x802F011C 0xBBBBBBBB 0xCCCCCCCC" is equivalent to a call to commands 0xF011C with parameter 0xAAAAAAAA, 0xF011D with parameter 0xBBBBBBBB and 0xF011E with parameter 0xCCCCCCCC. If consecutive writing mode were disabled, the command would be equivalent to three consecutive calls to 0xF011C (once with parameter 0xAAAAAAAA, once with 0xBBBBBBBB, and finally with 0xCCCCCCCC).

Invalid GPU command parameters including NaN floats can cause the GPU to hang, which then causes the GSP module to hang as well.

The size of GPU command buffers must be 0x10-byte aligned; the lower 3 bits of the size are cleared. A common pitfall is having the finalization command (write to register 0x0010) not executed because it was the last 8 bytes of a non-0x10 byte aligned command buffer, and having the GPU hang as a result.

=== Command Header ===
{| class="wikitable" border="1"
! Bit
! Description
|-
| 0-15
| Command ID
|-
| 16-19
| Parameter mask
|-
| 20-27
| Number of extra parameters (may be zero)
|-
| 28-30
| Unused
|-
| 31
| Consecutive writing mode
|}

=== Parameter masking ===

Using a value other than 0xF, parts of a word in internal GPU memory can be updated without touching the other bits of it. For example, setting bit 16 to zero indicates that the least significant byte of the parameter will not be overwritten, setting bit 17 to zero indicates that the parameter's second LSB will not be overwritten, etc. This means that for instance commands 0x00010107 and 0x00020107 refer to the same thing but write different parts of the parameter.

=== Types ===

There are three main types of registers :
* configuration registers, which directly map to various rendering properties (for example: [[#GPUREG_FACECULLING_CONFIG|GPUREG_FACECULLING_CONFIG]])
* data transfer registers, which can be seen as FIFOs that let us send sequential chunks of data to the GPU, such as shader code or 1D samplers (for example: [[#GPUREG_SH_CODETRANSFER_DATA|GPUREG_GSH_CODETRANSFER_DATA]])
* action triggering registers, which tell the GPU to do something, like draw a primitive (for example: [[#GPUREG_DRAWARRAYS|GPUREG_DRAWARRAYS]])

=== Aliases ===

It is possible for multiple register (sequential) IDs to correspond to the same register. This is done to leverage the consecutive writing mode for GPU commands, which makes it possible for a single command to write data to multiple sequential register IDs. For example, register IDs 02C1 through 02C8 all correspond to [[#GPUREG_VSH_FLOATUNIFORM_DATAi|GPUREG_VSH_FLOATUNIFORM_DATA''i'']] so that a consecutively writing command based at 02C0 will write its first parameter to [[#GPUREG_VSH_FLOATUNIFORM_INDEX|GPUREG_VSH_FLOATUNIFORM_INDEX]] and ever subsequent ones to [[#GPUREG_VSH_FLOATUNIFORM_DATAi|GPUREG_VSH_FLOATUNIFORM_DATA''i'']]

=== Data Types ===

{| class="wikitable" border="1"
! Name
! Description
|-
| signed
| Signed integer
|-
| unsigned
| Unsigned integer
|-
| floatX.Y.Z
| Floating-point number with X sign bits, Y exponent bits, and Z mantissa bits
|-
| fixedX.Y.Z
| Fixed-point number with X sign bits, Y integer bits, and Z fractional bits
|}

== Register list ==

=== Miscellaneous registers (0x000-0x03F) ===

{| class="wikitable" border="1"
! Register ID
! Register name
! Notes
! Official Name
|-
| 0000
| [[#GPUREG_0000|GPUREG_0000]]
|
|
|-
| 0001
| [[#GPUREG_0001|GPUREG_0001]]
|
|
|-
| 0002
| [[#GPUREG_0002|GPUREG_0002]]
|
|
|-
| 0003
| [[#GPUREG_0003|GPUREG_0003]]
|
|
|-
| 0004
| [[#GPUREG_0004|GPUREG_0004]]
|
|
|-
| 0005
| [[#GPUREG_0005|GPUREG_0005]]
|
|
|-
| 0006
| [[#GPUREG_0006|GPUREG_0006]]
|
|
|-
| 0007
| [[#GPUREG_0007|GPUREG_0007]]
|
|
|-
| 0008
| [[#GPUREG_0008|GPUREG_0008]]
|
|
|-
| 0009
| [[#GPUREG_0009|GPUREG_0009]]
|
|
|-
| 000A
| [[#GPUREG_000A|GPUREG_000A]]
|
|
|-
| 000B
| [[#GPUREG_000B|GPUREG_000B]]
|
|
|-
| 000C
| [[#GPUREG_000C|GPUREG_000C]]
|
|
|-
| 000D
| [[#GPUREG_000D|GPUREG_000D]]
|
|
|-
| 000E
| [[#GPUREG_000E|GPUREG_000E]]
|
|
|-
| 000F
| [[#GPUREG_000F|GPUREG_000F]]
|
|
|-
| 0010
| [[#GPUREG_FINALIZE|GPUREG_FINALIZE]]
|
|PICA_REG_INTERRUPT
|-
| 0011
| [[#GPUREG_0011|GPUREG_0011]]
|
|
|-
| 0012
| [[#GPUREG_0012|GPUREG_0012]]
|
|
|-
| 0013
| [[#GPUREG_0013|GPUREG_0013]]
|
|
|-
| 0014
| [[#GPUREG_0014|GPUREG_0014]]
|
|
|-
| 0015
| [[#GPUREG_0015|GPUREG_0015]]
|
|
|-
| 0016
| [[#GPUREG_0016|GPUREG_0016]]
|
|
|-
| 0017
| [[#GPUREG_0017|GPUREG_0017]]
|
|
|-
| 0018
| [[#GPUREG_0018|GPUREG_0018]]
|
|
|-
| 0019
| [[#GPUREG_0019|GPUREG_0019]]
|
|
|-
| 001A
| [[#GPUREG_001A|GPUREG_001A]]
|
|
|-
| 001B
| [[#GPUREG_001B|GPUREG_001B]]
|
|
|-
| 001C
| [[#GPUREG_001C|GPUREG_001C]]
|
|
|-
| 001D
| [[#GPUREG_001D|GPUREG_001D]]
|
|
|-
| 001E
| [[#GPUREG_001E|GPUREG_001E]]
|
|
|-
| 001F
| [[#GPUREG_001F|GPUREG_001F]]
|
|
|-
| 0020
| [[#GPUREG_0020|GPUREG_0020]]
|
|
|-
| 0021
| [[#GPUREG_0021|GPUREG_0021]]
|
|
|-
| 0022
| [[#GPUREG_0022|GPUREG_0022]]
|
|
|-
| 0023
| [[#GPUREG_0023|GPUREG_0023]]
|
|
|-
| 0024
| [[#GPUREG_0024|GPUREG_0024]]
|
|
|-
| 0025
| [[#GPUREG_0025|GPUREG_0025]]
|
|
|-
| 0026
| [[#GPUREG_0026|GPUREG_0026]]
|
|
|-
| 0027
| [[#GPUREG_0027|GPUREG_0027]]
|
|
|-
| 0028
| [[#GPUREG_0028|GPUREG_0028]]
|
|
|-
| 0029
| [[#GPUREG_0029|GPUREG_0029]]
|
|
|-
| 002A
| [[#GPUREG_002A|GPUREG_002A]]
|
|
|-
| 002B
| [[#GPUREG_002B|GPUREG_002B]]
|
|
|-
| 002C
| [[#GPUREG_002C|GPUREG_002C]]
|
|
|-
| 002D
| [[#GPUREG_002D|GPUREG_002D]]
|
|
|-
| 002E
| [[#GPUREG_002E|GPUREG_002E]]
|
|
|-
| 002F
| [[#GPUREG_002F|GPUREG_002F]]
|
|
|-
| 0030
| [[#GPUREG_0030|GPUREG_0030]]
|
|
|-
| 0031
| [[#GPUREG_0031|GPUREG_0031]]
|
|
|-
| 0032
| [[#GPUREG_0032|GPUREG_0032]]
|
|
|-
| 0033
| [[#GPUREG_0033|GPUREG_0033]]
|
|
|-
| 0034
| [[#GPUREG_0034|GPUREG_0034]]
|
|
|-
| 0035
| [[#GPUREG_0035|GPUREG_0035]]
|
|
|-
| 0036
| [[#GPUREG_0036|GPUREG_0036]]
|
|
|-
| 0037
| [[#GPUREG_0037|GPUREG_0037]]
|
|
|-
| 0038
| [[#GPUREG_0038|GPUREG_0038]]
|
|
|-
| 0039
| [[#GPUREG_0039|GPUREG_0039]]
|
|
|-
| 003A
| [[#GPUREG_003A|GPUREG_003A]]
|
|
|-
| 003B
| [[#GPUREG_003B|GPUREG_003B]]
|
|
|-
| 003C
| [[#GPUREG_003C|GPUREG_003C]]
|
|
|-
| 003D
| [[#GPUREG_003D|GPUREG_003D]]
|
|
|-
| 003E
| [[#GPUREG_003E|GPUREG_003E]]
|
|
|-
| 003F
| [[#GPUREG_003F|GPUREG_003F]]
|
|
|}

=== Rasterizer registers (0x040-0x07F) ===

{| class="wikitable" border="1"
! Register ID
! Register name
! Notes
! Official Name
|-
| 0040
| [[#GPUREG_FACECULLING_CONFIG|GPUREG_FACECULLING_CONFIG]]
|
|PICA_REG_CULL_FACE
|-
| 0041
| [[#GPUREG_VIEWPORT_WIDTH|GPUREG_VIEWPORT_WIDTH]]
|
|PICA_REG_VIEWPORT_WIDTH1
|-
| 0042
| [[#GPUREG_VIEWPORT_INVW|GPUREG_VIEWPORT_INVW]]
|
|PICA_REG_VIEWPORT_WIDTH2
|-
| 0043
| [[#GPUREG_VIEWPORT_HEIGHT|GPUREG_VIEWPORT_HEIGHT]]
|
|PICA_REG_VIEWPORT_HEIGHT1
|-
| 0044
| [[#GPUREG_VIEWPORT_INVH|GPUREG_VIEWPORT_INVH]]
|
|PICA_REG_VIEWPORT_HEIGHT2
|-
| 0045
| [[#GPUREG_0045|GPUREG_0045]]
|
|
|-
| 0046
| [[#GPUREG_0046|GPUREG_0046]]
|
|
|-
| 0047
| [[#GPUREG_FRAGOP_CLIP|GPUREG_FRAGOP_CLIP]]
|?
|PICA_REG_FRAGOP_CLIP
|-
| 0048
| [[#GPUREG_FRAGOP_CLIP_DATAi|GPUREG_FRAGOP_CLIP_DATA0]]
|?
|PICA_REG_FRAGOP_CLIP_DATA1
|-
| 0049
| [[#GPUREG_FRAGOP_CLIP_DATAi|GPUREG_FRAGOP_CLIP_DATA1]]
|?
|PICA_REG_FRAGOP_CLIP_DATA2
|-
| 004A
| [[#GPUREG_FRAGOP_CLIP_DATAi|GPUREG_FRAGOP_CLIP_DATA2]]
|?
|PICA_REG_FRAGOP_CLIP_DATA3
|-
| 004B
| [[#GPUREG_FRAGOP_CLIP_DATAi|GPUREG_FRAGOP_CLIP_DATA3]]
|?
|PICA_REG_FRAGOP_CLIP_DATA4
|-
| 004C
| [[#GPUREG_004C|GPUREG_004C]]
|
|
|-
| 004D
| [[#GPUREG_DEPTHMAP_SCALE|GPUREG_DEPTHMAP_SCALE]]
| As f24
|PICA_REG_FRAGOP_WSCALE_DATA1
|-
| 004E
| [[#GPUREG_DEPTHMAP_OFFSET|GPUREG_DEPTHMAP_OFFSET]]
| As f24
|PICA_REG_FRAGOP_WSCALE_DATA2
|-
| 004F
| [[#GPUREG_SH_OUTMAP_TOTAL|GPUREG_SH_OUTMAP_TOTAL]]
|
|PICA_REG_GS_OUT_REG_NUM0 / PICA_REG_VS_OUT_REG_NUM0
|-
| 0050
| [[#GPUREG_SH_OUTMAP_Oi|GPUREG_SH_OUTMAP_O0]]
|
|PICA_REG_GS_OUT_ATTR0 / PICA_REG_VS_OUT_ATTR0
|-
| 0051
| [[#GPUREG_SH_OUTMAP_Oi|GPUREG_SH_OUTMAP_O1]]
|
|PICA_REG_GS_OUT_ATTR1 / PICA_REG_VS_OUT_ATTR1
|-
| 0052
| [[#GPUREG_SH_OUTMAP_Oi|GPUREG_SH_OUTMAP_O2]]
|
|PICA_REG_GS_OUT_ATTR2 / PICA_REG_VS_OUT_ATTR2
|-
| 0053
| [[#GPUREG_SH_OUTMAP_Oi|GPUREG_SH_OUTMAP_O3]]
|
|PICA_REG_GS_OUT_ATTR3 / PICA_REG_VS_OUT_ATTR3
|-
| 0054
| [[#GPUREG_SH_OUTMAP_Oi|GPUREG_SH_OUTMAP_O4]]
|
|PICA_REG_GS_OUT_ATTR4 / PICA_REG_VS_OUT_ATTR4
|-
| 0055
| [[#GPUREG_SH_OUTMAP_Oi|GPUREG_SH_OUTMAP_O5]]
|
|PICA_REG_GS_OUT_ATTR5 / PICA_REG_VS_OUT_ATTR5
|-
| 0056
| [[#GPUREG_SH_OUTMAP_Oi|GPUREG_SH_OUTMAP_O6]]
|
|PICA_REG_GS_OUT_ATTR6 / PICA_REG_VS_OUT_ATTR6
|-
| 0057
| [[#GPUREG_0057|GPUREG_0057]]
|
|
|-
| 0058
| [[#GPUREG_0058|GPUREG_0058]]
|
|
|-
| 0059
| [[#GPUREG_0059|GPUREG_0059]]
|
|
|-
| 005A
| [[#GPUREG_005A|GPUREG_005A]]
|
|
|-
| 005B
| [[#GPUREG_005B|GPUREG_005B]]
|
|
|-
| 005C
| [[#GPUREG_005C|GPUREG_005C]]
|
|
|-
| 005D
| [[#GPUREG_005D|GPUREG_005D]]
|
|
|-
| 005E
| [[#GPUREG_005E|GPUREG_005E]]
|
|
|-
| 005F
| [[#GPUREG_005F|GPUREG_005F]]
|
|
|-
| 0060
| [[#GPUREG_0060|GPUREG_0060]]
|
|
|-
| 0061
| [[#GPUREG_EARLYDEPTH_FUNC|GPUREG_EARLYDEPTH_FUNC]]
|?
|PICA_REG_EARLY_DEPTH_FUNC
|-
| 0062
| [[#GPUREG_EARLYDEPTH_TEST1|GPUREG_EARLYDEPTH_TEST1]]
|?
|PICA_REG_EARLY_DEPTH_TEST1
|-
| 0063
| [[#GPUREG_EARLYDEPTH_CLEAR|GPUREG_EARLYDEPTH_CLEAR]]
|
|PICA_REG_EARLY_DEPTH_CLEAR
|-
| 0064
| [[#GPUREG_SH_OUTATTR_MODE|GPUREG_SH_OUTATTR_MODE]]
|?
|PICA_REG_GS_OUT_ATTR_MODE / PICA_REG_VS_OUT_ATTR_MODE
|-
| 0065
| [[#GPUREG_SCISSORTEST_MODE|GPUREG_SCISSORTEST_MODE]]
|
|PICA_REG_SCISSOR
|-
| 0066
| [[#GPUREG_SCISSORTEST_POS|GPUREG_SCISSORTEST_POS]]
|
|PICA_REG_SCISSOR_XY
|-
| 0067
| [[#GPUREG_SCISSORTEST_DIM|GPUREG_SCISSORTEST_DIM]]
|
|PICA_REG_SCISSOR_SIZE
|-
| 0068
| [[#GPUREG_VIEWPORT_XY|GPUREG_VIEWPORT_XY]]
|
|PICA_REG_VIEWPORT_XY
|-
| 0069
| [[#GPUREG_0069|GPUREG_0069]]
|
|
|-
| 006A
| [[#GPUREG_EARLYDEPTH_DATA|GPUREG_EARLYDEPTH_DATA]]
|
|PICA_REG_EARLY_DEPTH_DATA
|-
| 006B
| [[#GPUREG_006B|GPUREG_006B]]
|
|
|-
| 006C
| [[#GPUREG_006C|GPUREG_006C]]
|
|
|-
| 006D
| [[#GPUREG_DEPTHMAP_ENABLE|GPUREG_DEPTHMAP_ENABLE]]
|?
|PICA_REG_FRAGOP_WSCALE
|-
| 006E
| [[#GPUREG_RENDERBUF_DIM|GPUREG_RENDERBUF_DIM]]
|?
|PICA_REG_RENDER_BUF_RESOLUTION1
|-
| 006F
| [[#GPUREG_SH_OUTATTR_CLOCK|GPUREG_SH_OUTATTR_CLOCK]]
|?
|PICA_REG_GS_OUT_ATTR_CLK / PICA_REG_VS_OUT_ATTR_CLK
|-
| 0070
| [[#GPUREG_0070|GPUREG_0070]]
|
|
|-
| 0071
| [[#GPUREG_0071|GPUREG_0071]]
|
|
|-
| 0072
| [[#GPUREG_0072|GPUREG_0072]]
|
|
|-
| 0073
| [[#GPUREG_0073|GPUREG_0073]]
|
|
|-
| 0074
| [[#GPUREG_0074|GPUREG_0074]]
|
|
|-
| 0075
| [[#GPUREG_0075|GPUREG_0075]]
|
|
|-
| 0076
| [[#GPUREG_0076|GPUREG_0076]]
|
|
|-
| 0077
| [[#GPUREG_0077|GPUREG_0077]]
|
|
|-
| 0078
| [[#GPUREG_0078|GPUREG_0078]]
|
|
|-
| 0079
| [[#GPUREG_0079|GPUREG_0079]]
|
|
|-
| 007A
| [[#GPUREG_007A|GPUREG_007A]]
|
|
|-
| 007B
| [[#GPUREG_007B|GPUREG_007B]]
|
|
|-
| 007C
| [[#GPUREG_007C|GPUREG_007C]]
|
|
|-
| 007D
| [[#GPUREG_007D|GPUREG_007D]]
|
|
|-
| 007E
| [[#GPUREG_007E|GPUREG_007E]]
|
|
|-
| 007F
| [[#GPUREG_007F|GPUREG_007F]]
|
|
|}

=== Texturing registers (0x080-0x0FF) ===

{| class="wikitable" border="1"
! Register ID
! Register name
! Notes
! Official Name
|-
| 0080
| [[#GPUREG_TEXUNIT_CONFIG|GPUREG_TEXUNIT_CONFIG]]
|
|PICA_REG_TEXTURE_FUNC
|-
| 0081
| [[#GPUREG_TEXUNITi_BORDER_COLOR|GPUREG_TEXUNIT0_BORDER_COLOR]]
|
|PICA_REG_TEXTURE0_BORDER_COLOR
|-
| 0082
| [[#GPUREG_TEXUNITi_DIM|GPUREG_TEXUNIT0_DIM]]
|
|PICA_REG_TEXTURE0_SIZE
|-
| 0083
| [[#GPUREG_TEXUNITi_PARAM|GPUREG_TEXUNIT0_PARAM]]
|
|PICA_REG_TEXTURE0_WRAP_FILTER
|-
| 0084
| [[#GPUREG_TEXUNITi_LOD|GPUREG_TEXUNIT0_LOD]]
|?
|PICA_REG_TEXTURE0_LOD
|-
| 0085
| [[#GPUREG_TEXUNITi_ADDRi|GPUREG_TEXUNIT0_ADDR1]]
|
|PICA_REG_TEXTURE0_ADDR1
|-
| 0086
| [[#GPUREG_TEXUNITi_ADDRi|GPUREG_TEXUNIT0_ADDR2]]
|
|PICA_REG_TEXTURE0_ADDR2
|-
| 0087
| [[#GPUREG_TEXUNITi_ADDRi|GPUREG_TEXUNIT0_ADDR3]]
|
|PICA_REG_TEXTURE0_ADDR3
|-
| 0088
| [[#GPUREG_TEXUNITi_ADDRi|GPUREG_TEXUNIT0_ADDR4]]
|
|PICA_REG_TEXTURE0_ADDR4
|-
| 0089
| [[#GPUREG_TEXUNITi_ADDRi|GPUREG_TEXUNIT0_ADDR5]]
|
|PICA_REG_TEXTURE0_ADDR5
|-
| 008A
| [[#GPUREG_TEXUNITi_ADDRi|GPUREG_TEXUNIT0_ADDR6]]
|
|PICA_REG_TEXTURE0_ADDR6
|-
| 008B
| [[#GPUREG_TEXUNITi_SHADOW|GPUREG_TEXUNIT0_SHADOW]]
|?
|PICA_REG_TEXTURE0_SHADOW
|-
| 008C
| [[#GPUREG_008C|GPUREG_008C]]
|
|
|-
| 008D
| [[#GPUREG_008D|GPUREG_008D]]
|
|
|-
| 008E
| [[#GPUREG_TEXUNITi_TYPE|GPUREG_TEXUNIT0_TYPE]]
|?
|PICA_REG_TEXTURE0_FORMAT
|-
| 008F
| [[#GPUREG_LIGHTING_ENABLE0|GPUREG_LIGHTING_ENABLE0]]
|?
|PICA_REG_FRAG_LIGHT_EN0
|-
| 0090
| [[#GPUREG_0090|GPUREG_0090]]
|
|
|-
| 0091
| [[#GPUREG_TEXUNITi_BORDER_COLOR|GPUREG_TEXUNIT1_BORDER_COLOR]]
|
|PICA_REG_TEXTURE1_BORDER_COLOR
|-
| 0092
| [[#GPUREG_TEXUNITi_DIM|GPUREG_TEXUNIT1_DIM]]
|
|PICA_REG_TEXTURE1_SIZE
|-
| 0093
| [[#GPUREG_TEXUNITi_PARAM|GPUREG_TEXUNIT1_PARAM]]
|
|PICA_REG_TEXTURE1_WRAP_FILTER
|-
| 0094
| [[#GPUREG_TEXUNITi_LOD|GPUREG_TEXUNIT1_LOD]]
|?
|PICA_REG_TEXTURE1_LOD
|-
| 0095
| [[#GPUREG_TEXUNITi_ADDRi|GPUREG_TEXUNIT1_ADDR]]
|
|PICA_REG_TEXTURE1_ADDR
|-
| 0096
| [[#GPUREG_TEXUNITi_TYPE|GPUREG_TEXUNIT1_TYPE]]
|
|PICA_REG_TEXTURE1_FORMAT
|-
| 0097
| [[#GPUREG_0097|GPUREG_0097]]
|
|
|-
| 0098
| [[#GPUREG_0098|GPUREG_0098]]
|
|
|-
| 0099
| [[#GPUREG_TEXUNITi_BORDER_COLOR|GPUREG_TEXUNIT2_BORDER_COLOR]]
|
|PICA_REG_TEXTURE2_BORDER_COLOR
|-
| 009A
| [[#GPUREG_TEXUNITi_DIM|GPUREG_TEXUNIT2_DIM]]
|
|PICA_REG_TEXTURE2_SIZE
|-
| 009B
| [[#GPUREG_TEXUNITi_PARAM|GPUREG_TEXUNIT2_PARAM]]
|
|PICA_REG_TEXTURE2_WRAP_FILTER
|-
| 009C
| [[#GPUREG_TEXUNITi_LOD|GPUREG_TEXUNIT2_LOD]]
|?
|PICA_REG_TEXTURE2_LOD
|-
| 009D
| [[#GPUREG_TEXUNITi_ADDRi|GPUREG_TEXUNIT2_ADDR]]
|
|PICA_REG_TEXTURE2_ADDR
|-
| 009E
| [[#GPUREG_TEXUNITi_TYPE|GPUREG_TEXUNIT2_TYPE]]
|
|PICA_REG_TEXTURE2_FORMAT
|-
| 009F
| [[#GPUREG_009F|GPUREG_009F]]
|
|
|-
| 00A0
| [[#GPUREG_00A0|GPUREG_00A0]]
|
|
|-
| 00A1
| [[#GPUREG_00A1|GPUREG_00A1]]
|
|
|-
| 00A2
| [[#GPUREG_00A2|GPUREG_00A2]]
|
|
|-
| 00A3
| [[#GPUREG_00A3|GPUREG_00A3]]
|
|
|-
| 00A4
| [[#GPUREG_00A4|GPUREG_00A4]]
|
|
|-
| 00A5
| [[#GPUREG_00A5|GPUREG_00A5]]
|
|
|-
| 00A6
| [[#GPUREG_00A6|GPUREG_00A6]]
|
|
|-
| 00A7
| [[#GPUREG_00A7|GPUREG_00A7]]
|
|
|-
| 00A8
| [[#GPUREG_TEXUNIT3_PROCTEX0|GPUREG_TEXUNIT3_PROCTEX0]]
|?
|PICA_REG_TEXTURE3_PROCTEX0
|-
| 00A9
| [[#GPUREG_TEXUNIT3_PROCTEX1|GPUREG_TEXUNIT3_PROCTEX1]]
|?
|PICA_REG_TEXTURE3_PROCTEX1
|-
| 00AA
| [[#GPUREG_TEXUNIT3_PROCTEX2|GPUREG_TEXUNIT3_PROCTEX2]]
|?
|PICA_REG_TEXTURE3_PROCTEX2
|-
| 00AB
| [[#GPUREG_TEXUNIT3_PROCTEX3|GPUREG_TEXUNIT3_PROCTEX3]]
|?
|PICA_REG_TEXTURE3_PROCTEX3
|-
| 00AC
| [[#GPUREG_TEXUNIT3_PROCTEX4|GPUREG_TEXUNIT3_PROCTEX4]]
|?
|PICA_REG_TEXTURE3_PROCTEX4
|-
| 00AD
| [[#GPUREG_TEXUNIT3_PROCTEX5|GPUREG_TEXUNIT3_PROCTEX5]]
|?
|PICA_REG_TEXTURE3_PROCTEX5
|-
| 00AE
| [[#GPUREG_00AE|GPUREG_00AE]]
|
|
|-
| 00AF
| [[#GPUREG_PROCTEX_LUT|GPUREG_PROCTEX_LUT]]
|?
|PICA_REG_PROCTEX_LUT
|-
| 00B0
| [[#GPUREG_PROCTEX_LUT_DATAi|GPUREG_PROCTEX_LUT_DATA0]]
| ?
|PICA_REG_PROCTEX_LUT_DATA0
|-
| 00B1
| [[#GPUREG_PROCTEX_LUT_DATAi|GPUREG_PROCTEX_LUT_DATA1]]
| ?
|PICA_REG_PROCTEX_LUT_DATA1
|-
| 00B2
| [[#GPUREG_PROCTEX_LUT_DATAi|GPUREG_PROCTEX_LUT_DATA2]]
| ?
|PICA_REG_PROCTEX_LUT_DATA2
|-
| 00B3
| [[#GPUREG_PROCTEX_LUT_DATAi|GPUREG_PROCTEX_LUT_DATA3]]
| ?
|PICA_REG_PROCTEX_LUT_DATA3
|-
| 00B4
| [[#GPUREG_PROCTEX_LUT_DATAi|GPUREG_PROCTEX_LUT_DATA4]]
| ?
|PICA_REG_PROCTEX_LUT_DATA4
|-
| 00B5
| [[#GPUREG_PROCTEX_LUT_DATAi|GPUREG_PROCTEX_LUT_DATA5]]
| ?
|PICA_REG_PROCTEX_LUT_DATA5
|-
| 00B6
| [[#GPUREG_PROCTEX_LUT_DATAi|GPUREG_PROCTEX_LUT_DATA6]]
| ?
|PICA_REG_PROCTEX_LUT_DATA6
|-
| 00B7
| [[#GPUREG_PROCTEX_LUT_DATAi|GPUREG_PROCTEX_LUT_DATA7]]
| ?
|PICA_REG_PROCTEX_LUT_DATA7
|-
| 00B8
| [[#GPUREG_00B8|GPUREG_00B8]]
|
|
|-
| 00B9
| [[#GPUREG_00B9|GPUREG_00B9]]
|
|
|-
| 00BA
| [[#GPUREG_00BA|GPUREG_00BA]]
|
|
|-
| 00BB
| [[#GPUREG_00BB|GPUREG_00BB]]
|
|
|-
| 00BC
| [[#GPUREG_00BC|GPUREG_00BC]]
|
|
|-
| 00BD
| [[#GPUREG_00BD|GPUREG_00BD]]
|
|
|-
| 00BE
| [[#GPUREG_00BE|GPUREG_00BE]]
|
|
|-
| 00BF
| [[#GPUREG_00BF|GPUREG_00BF]]
|
|
|-
| 00C0
| [[#GPUREG_TEXENVi_SOURCE|GPUREG_TEXENV0_SOURCE]]
|
|PICA_REG_TEX_ENV_0
|-
| 00C1
| [[#GPUREG_TEXENVi_OPERAND|GPUREG_TEXENV0_OPERAND]]
|
|PICA_REG_TEX_ENV_0_OPERAND
|-
| 00C2
| [[#GPUREG_TEXENVi_COMBINER|GPUREG_TEXENV0_COMBINER]]
|
|PICA_REG_TEX_ENV_0_COMBINE
|-
| 00C3
| [[#GPUREG_TEXENVi_COLOR|GPUREG_TEXENV0_COLOR]]
|
|PICA_REG_TEX_ENV_0_COLOR
|-
| 00C4
| [[#GPUREG_TEXENVi_SCALE|GPUREG_TEXENV0_SCALE]]
|
|PICA_REG_TEX_ENV_0_SCALE
|-
| 00C5
| [[#GPUREG_00C5|GPUREG_00C5]]
|
|
|-
| 00C6
| [[#GPUREG_00C6|GPUREG_00C6]]
|
|
|-
| 00C7
| [[#GPUREG_00C7|GPUREG_00C7]]
|
|
|-
| 00C8
| [[#GPUREG_TEXENVi_SOURCE|GPUREG_TEXENV1_SOURCE]]
|
|PICA_REG_TEX_ENV_1
|-
| 00C9
| [[#GPUREG_TEXENVi_OPERAND|GPUREG_TEXENV1_OPERAND]]
|
|PICA_REG_TEX_ENV_1_OPERAND
|-
| 00CA
| [[#GPUREG_TEXENVi_COMBINER|GPUREG_TEXENV1_COMBINER]]
|
|PICA_REG_TEX_ENV_1_COMBINE
|-
| 00CB
| [[#GPUREG_TEXENVi_COLOR|GPUREG_TEXENV1_COLOR]]
|
|PICA_REG_TEX_ENV_1_COLOR
|-
| 00CC
| [[#GPUREG_TEXENVi_SCALE|GPUREG_TEXENV1_SCALE]]
|
|PICA_REG_TEX_ENV_1_SCALE
|-
| 00CD
| [[#GPUREG_00CD|GPUREG_00CD]]
|
|
|-
| 00CE
| [[#GPUREG_00CE|GPUREG_00CE]]
|
|
|-
| 00CF
| [[#GPUREG_00CF|GPUREG_00CF]]
|
|
|-
| 00D0
| [[#GPUREG_TEXENVi_SOURCE|GPUREG_TEXENV2_SOURCE]]
|
|PICA_REG_TEX_ENV_2
|-
| 00D1
| [[#GPUREG_TEXENVi_OPERAND|GPUREG_TEXENV2_OPERAND]]
|
|PICA_REG_TEX_ENV_2_OPERAND
|-
| 00D2
| [[#GPUREG_TEXENVi_COMBINER|GPUREG_TEXENV2_COMBINER]]
|
|PICA_REG_TEX_ENV_2_COMBINE
|-
| 00D3
| [[#GPUREG_TEXENVi_COLOR|GPUREG_TEXENV2_COLOR]]
|
|PICA_REG_TEX_ENV_2_COLOR
|-
| 00D4
| [[#GPUREG_TEXENVi_SCALE|GPUREG_TEXENV2_SCALE]]
|
|PICA_REG_TEX_ENV_2_SCALE
|-
| 00D5
| [[#GPUREG_00D5|GPUREG_00D5]]
|
|
|-
| 00D6
| [[#GPUREG_00D6|GPUREG_00D6]]
|
|
|-
| 00D7
| [[#GPUREG_00D7|GPUREG_00D7]]
|
|
|-
| 00D8
| [[#GPUREG_TEXENVi_SOURCE|GPUREG_TEXENV3_SOURCE]]
|
|PICA_REG_TEX_ENV_3
|-
| 00D9
| [[#GPUREG_TEXENVi_OPERAND|GPUREG_TEXENV3_OPERAND]]
|
|PICA_REG_TEX_ENV_3_OPERAND
|-
| 00DA
| [[#GPUREG_TEXENVi_COMBINER|GPUREG_TEXENV3_COMBINER]]
|
|PICA_REG_TEX_ENV_3_COMBINE
|-
| 00DB
| [[#GPUREG_TEXENVi_COLOR|GPUREG_TEXENV3_COLOR]]
|
|PICA_REG_TEX_ENV_3_COLOR
|-
| 00DC
| [[#GPUREG_TEXENVi_SCALE|GPUREG_TEXENV3_SCALE]]
|
|PICA_REG_TEX_ENV_3_SCALE
|-
| 00DD
| [[#GPUREG_00DD|GPUREG_00DD]]
|
|
|-
| 00DE
| [[#GPUREG_00DE|GPUREG_00DE]]
|
|
|-
| 00DF
| [[#GPUREG_00DF|GPUREG_00DF]]
|
|
|-
| 00E0
| [[#GPUREG_TEXENV_UPDATE_BUFFER|GPUREG_TEXENV_UPDATE_BUFFER]]
|?
|PICA_REG_GAS_FOG_MODE / PICA_REG_TEX_ENV_BUF_INPUT
|-
| 00E1
| [[#GPUREG_FOG_COLOR|GPUREG_FOG_COLOR]]
|?
|PICA_REG_FOG_COLOR
|-
| 00E2
| [[#GPUREG_00E2|GPUREG_00E2]]
|
|
|-
| 00E3
| [[#GPUREG_00E3|GPUREG_00E3]]
|
|
|-
| 00E4
| [[#GPUREG_GAS_ATTENUATION|GPUREG_GAS_ATTENUATION]]
|?
|PICA_REG_GAS_ATTENUATION
|-
| 00E5
| [[#GPUREG_GAS_ACCMAX|GPUREG_GAS_ACCMAX]]
|?
|PICA_REG_GAS_ACCMAX
|-
| 00E6
| [[#GPUREG_FOG_LUT_INDEX|GPUREG_FOG_LUT_INDEX]]
|?
|PICA_REG_FOG_LUT_INDEX
|-
| 00E7
| [[#GPUREG_00E7|GPUREG_00E7]]
|
|
|-
| 00E8
| [[#GPUREG_FOG_LUT_DATAi|GPUREG_FOG_LUT_DATA0]]
|?
|PICA_REG_FOG_LUT_DATA0
|-
| 00E9
| [[#GPUREG_FOG_LUT_DATAi|GPUREG_FOG_LUT_DATA1]]
|?
|PICA_REG_FOG_LUT_DATA1
|-
| 00EA
| [[#GPUREG_FOG_LUT_DATAi|GPUREG_FOG_LUT_DATA2]]
|?
|PICA_REG_FOG_LUT_DATA2
|-
| 00EB
| [[#GPUREG_FOG_LUT_DATAi|GPUREG_FOG_LUT_DATA3]]
|?
|PICA_REG_FOG_LUT_DATA3
|-
| 00EC
| [[#GPUREG_FOG_LUT_DATAi|GPUREG_FOG_LUT_DATA4]]
|?
|PICA_REG_FOG_LUT_DATA4
|-
| 00ED
| [[#GPUREG_FOG_LUT_DATAi|GPUREG_FOG_LUT_DATA5]]
|?
|PICA_REG_FOG_LUT_DATA5
|-
| 00EE
| [[#GPUREG_FOG_LUT_DATAi|GPUREG_FOG_LUT_DATA6]]
|?
|PICA_REG_FOG_LUT_DATA6
|-
| 00EF
| [[#GPUREG_FOG_LUT_DATAi|GPUREG_FOG_LUT_DATA7]]
|?
|PICA_REG_FOG_LUT_DATA7
|-
| 00F0
| [[#GPUREG_TEXENVi_SOURCE|GPUREG_TEXENV4_SOURCE]]
|
|PICA_REG_TEX_ENV_4
|-
| 00F1
| [[#GPUREG_TEXENVi_OPERAND|GPUREG_TEXENV4_OPERAND]]
|
|PICA_REG_TEX_ENV_4_OPERAND
|-
| 00F2
| [[#GPUREG_TEXENVi_COMBINER|GPUREG_TEXENV4_COMBINER]]
|
|PICA_REG_TEX_ENV_4_COMBINE
|-
| 00F3
| [[#GPUREG_TEXENVi_COLOR|GPUREG_TEXENV4_COLOR]]
|
|PICA_REG_TEX_ENV_4_COLOR
|-
| 00F4
| [[#GPUREG_TEXENVi_SCALE|GPUREG_TEXENV4_SCALE]]
|
|PICA_REG_TEX_ENV_4_SCALE
|-
| 00F5
| [[#GPUREG_00F5|GPUREG_00F5]]
|
|
|-
| 00F6
| [[#GPUREG_00F6|GPUREG_00F6]]
|
|
|-
| 00F7
| [[#GPUREG_00F7|GPUREG_00F7]]
|
|
|-
| 00F8
| [[#GPUREG_TEXENVi_SOURCE|GPUREG_TEXENV5_SOURCE]]
|
|PICA_REG_TEX_ENV_5
|-
| 00F9
| [[#GPUREG_TEXENVi_OPERAND|GPUREG_TEXENV5_OPERAND]]
|
|PICA_REG_TEX_ENV_5_OPERAND
|-
| 00FA
| [[#GPUREG_TEXENVi_COMBINER|GPUREG_TEXENV5_COMBINER]]
|
|PICA_REG_TEX_ENV_5_COMBINE
|-
| 00FB
| [[#GPUREG_TEXENVi_COLOR|GPUREG_TEXENV5_COLOR]]
|
|PICA_REG_TEX_ENV_5_COLOR
|-
| 00FC
| [[#GPUREG_TEXENVi_SCALE|GPUREG_TEXENV5_SCALE]]
|
|PICA_REG_TEX_ENV_5_SCALE
|-
| 00FD
| [[#GPUREG_TEXENV_BUFFER_COLOR|GPUREG_TEXENV_BUFFER_COLOR]]
|?
|PICA_REG_TEX_ENV_BUF_COLOR
|-
| 00FE
| [[#GPUREG_00FE|GPUREG_00FE]]
|
|
|-
| 00FF
| [[#GPUREG_00FF|GPUREG_00FF]]
|
|
|}

=== Framebuffer registers (0x100-0x13F) ===

{| class="wikitable" border="1"
! Register ID
! Register name
! Notes
! Official Name
|-
| 0100
| [[#GPUREG_COLOR_OPERATION|GPUREG_COLOR_OPERATION]]
|
|PICA_REG_COLOR_OPERATION
|-
| 0101
| [[#GPUREG_BLEND_FUNC|GPUREG_BLEND_FUNC]]
|
|PICA_REG_BLEND_FUNC
|-
| 0102
| [[#GPUREG_LOGIC_OP|GPUREG_LOGIC_OP]]
|
|PICA_REG_LOGIC_OP
|-
| 0103
| [[#GPUREG_BLEND_COLOR|GPUREG_BLEND_COLOR]]
|
|PICA_REG_BLEND_COLOR
|-
| 0104
| [[#GPUREG_FRAGOP_ALPHA_TEST|GPUREG_FRAGOP_ALPHA_TEST]]
|
|PICA_REG_FRAGOP_ALPHA_TEST
|-
| 0105
| [[#GPUREG_STENCIL_TEST|GPUREG_STENCIL_TEST]]
|
|PICA_REG_STENCIL_TEST
|-
| 0106
| [[#GPUREG_STENCIL_OP|GPUREG_STENCIL_OP]]
|
|PICA_REG_STENCIL_OP
|-
| 0107
| [[#GPUREG_DEPTH_COLOR_MASK|GPUREG_DEPTH_COLOR_MASK]]
|
|PICA_REG_DEPTH_COLOR_MASK
|-
| 0108
| [[#GPUREG_0108|GPUREG_0108]]
|
|
|-
| 0109
| [[#GPUREG_0109|GPUREG_0109]]
|
|
|-
| 010A
| [[#GPUREG_010A|GPUREG_010A]]
|
|
|-
| 010B
| [[#GPUREG_010B|GPUREG_010B]]
|
|
|-
| 010C
| [[#GPUREG_010C|GPUREG_010C]]
|
|
|-
| 010D
| [[#GPUREG_010D|GPUREG_010D]]
|
|
|-
| 010E
| [[#GPUREG_010E|GPUREG_010E]]
|
|
|-
| 010F
| [[#GPUREG_010F|GPUREG_010F]]
|
|
|-
| 0110
| [[#GPUREG_FRAMEBUFFER_INVALIDATE|GPUREG_FRAMEBUFFER_INVALIDATE]]
|
|PICA_REG_COLOR_BUFFER_CLEAR0
|-
| 0111
| [[#GPUREG_FRAMEBUFFER_FLUSH|GPUREG_FRAMEBUFFER_FLUSH]]
|
|PICA_REG_COLOR_BUFFER_CLEAR1
|-
| 0112
| [[#GPUREG_COLORBUFFER_READ|GPUREG_COLORBUFFER_READ]]
|
|PICA_REG_COLOR_BUFFER_READ
|-
| 0113
| [[#GPUREG_COLORBUFFER_WRITE|GPUREG_COLORBUFFER_WRITE]]
|
|PICA_REG_COLOR_BUFFER_WRITE
|-
| 0114
| [[#GPUREG_DEPTHBUFFER_READ|GPUREG_DEPTHBUFFER_READ]]
|
|PICA_REG_DEPTH_STENCIL_READ
|-
| 0115
| [[#GPUREG_DEPTHBUFFER_WRITE|GPUREG_DEPTHBUFFER_WRITE]]
|
|PICA_REG_DEPTH_STENCIL_WRITE
|-
| 0116
| [[#GPUREG_DEPTHBUFFER_FORMAT|GPUREG_DEPTHBUFFER_FORMAT]]
|
|PICA_REG_RENDER_BUF_DEPTH_MODE
|-
| 0117
| [[#GPUREG_COLORBUFFER_FORMAT|GPUREG_COLORBUFFER_FORMAT]]
|
|PICA_REG_RENDER_BUF_COLOR_MODE
|-
| 0118
| [[#GPUREG_EARLYDEPTH_TEST2|GPUREG_EARLYDEPTH_TEST2]]
|?
|PICA_REG_EARLY_DEPTH_TEST2
|-
| 0119
| [[#GPUREG_0119|GPUREG_0119]]
|
|
|-
| 011A
| [[#GPUREG_011A|GPUREG_011A]]
|
|
|-
| 011B
| [[#GPUREG_FRAMEBUFFER_BLOCK32|GPUREG_FRAMEBUFFER_BLOCK32]]
|
|PICA_REG_RENDER_BLOCK_FORMAT
|-
| 011C
| [[#GPUREG_DEPTHBUFFER_LOC|GPUREG_DEPTHBUFFER_LOC]]
|
|PICA_REG_RENDER_BUF_DEPTH_ADDR
|-
| 011D
| [[#GPUREG_COLORBUFFER_LOC|GPUREG_COLORBUFFER_LOC]]
|
|PICA_REG_RENDER_BUF_COLOR_ADDR
|-
| 011E
| [[#GPUREG_FRAMEBUFFER_DIM|GPUREG_FRAMEBUFFER_DIM]]
|
|PICA_REG_RENDER_BUF_RESOLUTION0
|-
| 011F
| [[#GPUREG_011F|GPUREG_011F]]
|
|
|-
| 0120
| [[#GPUREG_GAS_LIGHT_XY|GPUREG_GAS_LIGHT_XY]]
|?
|PICA_REG_GAS_LIGHT_XY
|-
| 0121
| [[#GPUREG_GAS_LIGHT_Z|GPUREG_GAS_LIGHT_Z]]
|?
|PICA_REG_GAS_LIGHT_Z
|-
| 0122
| [[#GPUREG_GAS_LIGHT_Z_COLOR|GPUREG_GAS_LIGHT_Z_COLOR]]
|?
|PICA_REG_GAS_LIGHT_Z_COLOR
|-
| 0123
| [[#GPUREG_GAS_LUT_INDEX|GPUREG_GAS_LUT_INDEX]]
|?
|PICA_REG_GAS_LUT_INDEX
|-
| 0124
| [[#GPUREG_GAS_LUT_DATA|GPUREG_GAS_LUT_DATA]]
|?
|PICA_REG_GAS_LUT_DATA
|-
| 0125
| [[#GPUREG_0125|GPUREG_0125]]
|
|
|-
| 0126
| [[#GPUREG_GAS_DELTAZ_DEPTH|GPUREG_GAS_DELTAZ_DEPTH]]
|?
|PICA_REG_GAS_DELTAZ_DEPTH
|-
| 0127
| [[#GPUREG_0127|GPUREG_0127]]
|
|
|-
| 0128
| [[#GPUREG_0128|GPUREG_0128]]
|
|
|-
| 0129
| [[#GPUREG_0129|GPUREG_0129]]
|
|
|-
| 012A
| [[#GPUREG_012A|GPUREG_012A]]
|
|
|-
| 012B
| [[#GPUREG_012B|GPUREG_012B]]
|
|
|-
| 012C
| [[#GPUREG_012C|GPUREG_012C]]
|
|
|-
| 012D
| [[#GPUREG_012D|GPUREG_012D]]
|
|
|-
| 012E
| [[#GPUREG_012E|GPUREG_012E]]
|
|
|-
| 012F
| [[#GPUREG_012F|GPUREG_012F]]
|
|
|-
| 0130
| [[#GPUREG_FRAGOP_SHADOW|GPUREG_FRAGOP_SHADOW]]
|?
|PICA_REG_FRAGOP_SHADOW
|-
| 0131
| [[#GPUREG_0131|GPUREG_0131]]
|
|
|-
| 0132
| [[#GPUREG_0132|GPUREG_0132]]
|
|
|-
| 0133
| [[#GPUREG_0133|GPUREG_0133]]
|
|
|-
| 0134
| [[#GPUREG_0134|GPUREG_0134]]
|
|
|-
| 0135
| [[#GPUREG_0135|GPUREG_0135]]
|
|
|-
| 0136
| [[#GPUREG_0136|GPUREG_0136]]
|
|
|-
| 0137
| [[#GPUREG_0137|GPUREG_0137]]
|
|
|-
| 0138
| [[#GPUREG_0138|GPUREG_0138]]
|
|
|-
| 0139
| [[#GPUREG_0139|GPUREG_0139]]
|
|
|-
| 013A
| [[#GPUREG_013A|GPUREG_013A]]
|
|
|-
| 013B
| [[#GPUREG_013B|GPUREG_013B]]
|
|
|-
| 013C
| [[#GPUREG_013C|GPUREG_013C]]
|
|
|-
| 013D
| [[#GPUREG_013D|GPUREG_013D]]
|
|
|-
| 013E
| [[#GPUREG_013E|GPUREG_013E]]
|
|
|-
| 013F
| [[#GPUREG_013F|GPUREG_013F]]
|
|
|}

=== Fragment lighting registers (0x140-0x1FF) ===

{| class="wikitable" border="1"
! Register ID
! Register name
! Notes
! Official Name
|-
| 0140
| [[#GPUREG_LIGHTi_SPECULAR0|GPUREG_LIGHT0_SPECULAR0]]
|?
|PICA_REG_FRAG_LIGHT0_SPECULAR0 / PICA_REG_FRAG_LIGHT_START
|-
| 0141
| [[#GPUREG_LIGHTi_SPECULAR1|GPUREG_LIGHT0_SPECULAR1]]
|?
|PICA_REG_FRAG_LIGHT0_SPECULAR1
|-
| 0142
| [[#GPUREG_LIGHTi_DIFFUSE|GPUREG_LIGHT0_DIFFUSE]]
|?
|PICA_REG_FRAG_LIGHT0_DIFFUSE
|-
| 0143
| [[#GPUREG_LIGHTi_AMBIENT|GPUREG_LIGHT0_AMBIENT]]
|?
|PICA_REG_FRAG_LIGHT0_AMBIENT
|-
| 0144
| [[#GPUREG_LIGHTi_XY|GPUREG_LIGHT0_XY]]
|?
|PICA_REG_FRAG_LIGHT0_POSITION_XY
|-
| 0145
| [[#GPUREG_LIGHTi_Z|GPUREG_LIGHT0_Z]]
|?
|PICA_REG_FRAG_LIGHT0_POSITION_Z
|-
| 0146
| [[#GPUREG_LIGHTi_SPOTDIR_XY|GPUREG_LIGHT0_SPOTDIR_XY]]
|?
|PICA_REG_FRAG_LIGHT0_SPOT_XY
|-
| 0147
| [[#GPUREG_LIGHTi_SPOTDIR_Z|GPUREG_LIGHT0_SPOTDIR_Z]]
|?
|PICA_REG_FRAG_LIGHT0_SPOT_Z
|-
| 0148
| [[#GPUREG_0148|GPUREG_0148]]
|
|
|-
| 0149
| [[#GPUREG_LIGHTi_CONFIG|GPUREG_LIGHT0_CONFIG]]
|
|PICA_REG_FRAG_LIGHT0_TYPE
|-
| 014A
| [[#GPUREG_LIGHTi_ATTENUATION_BIAS|GPUREG_LIGHT0_ATTENUATION_BIAS]]
|?
|PICA_REG_FRAG_LIGHT0_DIST_ATTN_BIAS
|-
| 014B
| [[#GPUREG_LIGHTi_ATTENUATION_SCALE|GPUREG_LIGHT0_ATTENUATION_SCALE]]
|?
|PICA_REG_FRAG_LIGHT0_DIST_ATTN_SCALE
|-
| 014C
| [[#GPUREG_014C|GPUREG_014C]]
|
|
|-
| 014D
| [[#GPUREG_014D|GPUREG_014D]]
|
|
|-
| 014E
| [[#GPUREG_014E|GPUREG_014E]]
|
|
|-
| 014F
| [[#GPUREG_014F|GPUREG_014F]]
|
|
|-
| 0150
| [[#GPUREG_LIGHTi_SPECULAR0|GPUREG_LIGHT1_SPECULAR0]]
|?
|PICA_REG_FRAG_LIGHT1_SPECULAR0
|-
| 0151
| [[#GPUREG_LIGHTi_SPECULAR1|GPUREG_LIGHT1_SPECULAR1]]
|?
|PICA_REG_FRAG_LIGHT1_SPECULAR1
|-
| 0152
| [[#GPUREG_LIGHTi_DIFFUSE|GPUREG_LIGHT1_DIFFUSE]]
|?
|PICA_REG_FRAG_LIGHT1_DIFFUSE
|-
| 0153
| [[#GPUREG_LIGHTi_AMBIENT|GPUREG_LIGHT1_AMBIENT]]
|?
|PICA_REG_FRAG_LIGHT1_AMBIENT
|-
| 0154
| [[#GPUREG_LIGHTi_XY|GPUREG_LIGHT1_XY]]
|?
|PICA_REG_FRAG_LIGHT1_POSITION_XY
|-
| 0155
| [[#GPUREG_LIGHTi_Z|GPUREG_LIGHT1_Z]]
|?
|PICA_REG_FRAG_LIGHT1_POSITION_Z
|-
| 0156
| [[#GPUREG_LIGHTi_SPOTDIR_XY|GPUREG_LIGHT1_SPOTDIR_XY]]
|?
|PICA_REG_FRAG_LIGHT1_SPOT_XY
|-
| 0157
| [[#GPUREG_LIGHTi_SPOTDIR_Z|GPUREG_LIGHT1_SPOTDIR_Z]]
|?
|PICA_REG_FRAG_LIGHT1_SPOT_Z
|-
| 0158
| [[#GPUREG_0158|GPUREG_0158]]
|
|
|-
| 0159
| [[#GPUREG_LIGHTi_CONFIG|GPUREG_LIGHT1_CONFIG]]
|?
|PICA_REG_FRAG_LIGHT1_TYPE
|-
| 015A
| [[#GPUREG_LIGHTi_ATTENUATION_BIAS|GPUREG_LIGHT1_ATTENUATION_BIAS]]
|?
|PICA_REG_FRAG_LIGHT1_DIST_ATTN_BIAS
|-
| 015B
| [[#GPUREG_LIGHTi_ATTENUATION_SCALE|GPUREG_LIGHT1_ATTENUATION_SCALE]]
|?
|PICA_REG_FRAG_LIGHT1_DIST_ATTN_SCALE
|-
| 015C
| [[#GPUREG_015C|GPUREG_015C]]
|
|
|-
| 015D
| [[#GPUREG_015D|GPUREG_015D]]
|
|
|-
| 015E
| [[#GPUREG_015E|GPUREG_015E]]
|
|
|-
| 015F
| [[#GPUREG_015F|GPUREG_015F]]
|
|
|-
| 0160
| [[#GPUREG_LIGHTi_SPECULAR0|GPUREG_LIGHT2_SPECULAR0]]
|?
|PICA_REG_FRAG_LIGHT2_SPECULAR0
|-
| 0161
| [[#GPUREG_LIGHTi_SPECULAR1|GPUREG_LIGHT2_SPECULAR1]]
|?
|PICA_REG_FRAG_LIGHT2_SPECULAR1
|-
| 0162
| [[#GPUREG_LIGHTi_DIFFUSE|GPUREG_LIGHT2_DIFFUSE]]
|?
|PICA_REG_FRAG_LIGHT2_DIFFUSE
|-
| 0163
| [[#GPUREG_LIGHTi_AMBIENT|GPUREG_LIGHT2_AMBIENT]]
|?
|PICA_REG_FRAG_LIGHT2_AMBIENT
|-
| 0164
| [[#GPUREG_LIGHTi_XY|GPUREG_LIGHT2_XY]]
|?
|PICA_REG_FRAG_LIGHT2_POSITION_XY
|-
| 0165
| [[#GPUREG_LIGHTi_Z|GPUREG_LIGHT2_Z]]
|?
|PICA_REG_FRAG_LIGHT2_POSITION_Z
|-
| 0166
| [[#GPUREG_LIGHTi_SPOTDIR_XY|GPUREG_LIGHT2_SPOTDIR_XY]]
|?
|PICA_REG_FRAG_LIGHT2_SPOT_XY
|-
| 0167
| [[#GPUREG_LIGHTi_SPOTDIR_Z|GPUREG_LIGHT2_SPOTDIR_Z]]
|?
|PICA_REG_FRAG_LIGHT2_SPOT_Z
|-
| 0168
| [[#GPUREG_0168|GPUREG_0168]]
|
|
|-
| 0169
| [[#GPUREG_LIGHTi_CONFIG|GPUREG_LIGHT2_CONFIG]]
|?
|PICA_REG_FRAG_LIGHT2_TYPE
|-
| 016A
| [[#GPUREG_LIGHTi_ATTENUATION_BIAS|GPUREG_LIGHT2_ATTENUATION_BIAS]]
|?
|PICA_REG_FRAG_LIGHT2_DIST_ATTN_BIAS
|-
| 016B
| [[#GPUREG_LIGHTi_ATTENUATION_SCALE|GPUREG_LIGHT2_ATTENUATION_SCALE]]
|?
|PICA_REG_FRAG_LIGHT2_DIST_ATTN_SCALE
|-
| 016C
| [[#GPUREG_016C|GPUREG_016C]]
|
|
|-
| 016D
| [[#GPUREG_016D|GPUREG_016D]]
|
|
|-
| 016E
| [[#GPUREG_016E|GPUREG_016E]]
|
|
|-
| 016F
| [[#GPUREG_016F|GPUREG_016F]]
|
|
|-
| 0170
| [[#GPUREG_LIGHTi_SPECULAR0|GPUREG_LIGHT3_SPECULAR0]]
|?
|PICA_REG_FRAG_LIGHT3_SPECULAR0
|-
| 0171
| [[#GPUREG_LIGHTi_SPECULAR1|GPUREG_LIGHT3_SPECULAR1]]
|?
|PICA_REG_FRAG_LIGHT3_SPECULAR1
|-
| 0172
| [[#GPUREG_LIGHTi_DIFFUSE|GPUREG_LIGHT3_DIFFUSE]]
|?
|PICA_REG_FRAG_LIGHT3_DIFFUSE
|-
| 0173
| [[#GPUREG_LIGHTi_AMBIENT|GPUREG_LIGHT3_AMBIENT]]
|?
|PICA_REG_FRAG_LIGHT3_AMBIENT
|-
| 0174
| [[#GPUREG_LIGHTi_XY|GPUREG_LIGHT3_XY]]
|?
|PICA_REG_FRAG_LIGHT3_POSITION_XY
|-
| 0175
| [[#GPUREG_LIGHTi_Z|GPUREG_LIGHT3_Z]]
|?
|PICA_REG_FRAG_LIGHT3_POSITION_Z
|-
| 0176
| [[#GPUREG_LIGHTi_SPOTDIR_XY|GPUREG_LIGHT3_SPOTDIR_XY]]
|?
|PICA_REG_FRAG_LIGHT3_SPOT_XY
|-
| 0177
| [[#GPUREG_LIGHTi_SPOTDIR_Z|GPUREG_LIGHT3_SPOTDIR_Z]]
|?
|PICA_REG_FRAG_LIGHT3_SPOT_Z
|-
| 0178
| [[#GPUREG_0178|GPUREG_0178]]
|
|
|-
| 0179
| [[#GPUREG_LIGHTi_CONFIG|GPUREG_LIGHT3_CONFIG]]
|?
|PICA_REG_FRAG_LIGHT3_TYPE
|-
| 017A
| [[#GPUREG_LIGHTi_ATTENUATION_BIAS|GPUREG_LIGHT3_ATTENUATION_BIAS]]
|?
|PICA_REG_FRAG_LIGHT3_DIST_ATTN_BIAS
|-
| 017B
| [[#GPUREG_LIGHTi_ATTENUATION_SCALE|GPUREG_LIGHT3_ATTENUATION_SCALE]]
|?
|PICA_REG_FRAG_LIGHT3_DIST_ATTN_SCALE
|-
| 017C
| [[#GPUREG_017C|GPUREG_017C]]
|
|
|-
| 017D
| [[#GPUREG_017D|GPUREG_017D]]
|
|
|-
| 017E
| [[#GPUREG_017E|GPUREG_017E]]
|
|
|-
| 017F
| [[#GPUREG_017F|GPUREG_017F]]
|
|
|-
| 0180
| [[#GPUREG_LIGHTi_SPECULAR0|GPUREG_LIGHT4_SPECULAR0]]
|?
|PICA_REG_FRAG_LIGHT4_SPECULAR0
|-
| 0181
| [[#GPUREG_LIGHTi_SPECULAR1|GPUREG_LIGHT4_SPECULAR1]]
|?
|PICA_REG_FRAG_LIGHT4_SPECULAR1
|-
| 0182
| [[#GPUREG_LIGHTi_DIFFUSE|GPUREG_LIGHT4_DIFFUSE]]
|?
|PICA_REG_FRAG_LIGHT4_DIFFUSE
|-
| 0183
| [[#GPUREG_LIGHTi_AMBIENT|GPUREG_LIGHT4_AMBIENT]]
|?
|PICA_REG_FRAG_LIGHT4_AMBIENT
|-
| 0184
| [[#GPUREG_LIGHTi_XY|GPUREG_LIGHT4_XY]]
|?
|PICA_REG_FRAG_LIGHT4_POSITION_XY
|-
| 0185
| [[#GPUREG_LIGHTi_Z|GPUREG_LIGHT4_Z]]
|?
|PICA_REG_FRAG_LIGHT4_POSITION_Z
|-
| 0186
| [[#GPUREG_LIGHTi_SPOTDIR_XY|GPUREG_LIGHT4_SPOTDIR_XY]]
|?
|PICA_REG_FRAG_LIGHT4_SPOT_XY
|-
| 0187
| [[#GPUREG_LIGHTi_SPOTDIR_Z|GPUREG_LIGHT4_SPOTDIR_Z]]
|?
|PICA_REG_FRAG_LIGHT4_SPOT_Z
|-
| 0188
| [[#GPUREG_0188|GPUREG_0188]]
|
|
|-
| 0189
| [[#GPUREG_LIGHTi_CONFIG|GPUREG_LIGHT4_CONFIG]]
|?
|PICA_REG_FRAG_LIGHT4_TYPE
|-
| 018A
| [[#GPUREG_LIGHTi_ATTENUATION_BIAS|GPUREG_LIGHT4_ATTENUATION_BIAS]]
|?
|PICA_REG_FRAG_LIGHT4_DIST_ATTN_BIAS
|-
| 018B
| [[#GPUREG_LIGHTi_ATTENUATION_SCALE|GPUREG_LIGHT4_ATTENUATION_SCALE]]
|?
|PICA_REG_FRAG_LIGHT4_DIST_ATTN_SCALE
|-
| 018C
| [[#GPUREG_018C|GPUREG_018C]]
|
|
|-
| 018D
| [[#GPUREG_018D|GPUREG_018D]]
|
|
|-
| 018E
| [[#GPUREG_018E|GPUREG_018E]]
|
|
|-
| 018F
| [[#GPUREG_018F|GPUREG_018F]]
|
|
|-
| 0190
| [[#GPUREG_LIGHTi_SPECULAR0|GPUREG_LIGHT5_SPECULAR0]]
|?
|PICA_REG_FRAG_LIGHT5_SPECULAR0
|-
| 0191
| [[#GPUREG_LIGHTi_SPECULAR1|GPUREG_LIGHT5_SPECULAR1]]
|?
|PICA_REG_FRAG_LIGHT5_SPECULAR1
|-
| 0192
| [[#GPUREG_LIGHTi_DIFFUSE|GPUREG_LIGHT5_DIFFUSE]]
|?
|PICA_REG_FRAG_LIGHT5_DIFFUSE
|-
| 0193
| [[#GPUREG_LIGHTi_AMBIENT|GPUREG_LIGHT5_AMBIENT]]
|?
|PICA_REG_FRAG_LIGHT5_AMBIENT
|-
| 0194
| [[#GPUREG_LIGHTi_XY|GPUREG_LIGHT5_XY]]
|?
|PICA_REG_FRAG_LIGHT5_POSITION_XY
|-
| 0195
| [[#GPUREG_LIGHTi_Z|GPUREG_LIGHT5_Z]]
|?
|PICA_REG_FRAG_LIGHT5_POSITION_Z
|-
| 0196
| [[#GPUREG_LIGHTi_SPOTDIR_XY|GPUREG_LIGHT5_SPOTDIR_XY]]
|?
|PICA_REG_FRAG_LIGHT5_SPOT_XY
|-
| 0197
| [[#GPUREG_LIGHTi_SPOTDIR_Z|GPUREG_LIGHT5_SPOTDIR_Z]]
|?
|PICA_REG_FRAG_LIGHT5_SPOT_Z
|-
| 0198
| [[#GPUREG_0198|GPUREG_0198]]
|
|
|-
| 0199
| [[#GPUREG_LIGHTi_CONFIG|GPUREG_LIGHT5_CONFIG]]
|?
|PICA_REG_FRAG_LIGHT5_TYPE
|-
| 019A
| [[#GPUREG_LIGHTi_ATTENUATION_BIAS|GPUREG_LIGHT5_ATTENUATION_BIAS]]
|
|PICA_REG_FRAG_LIGHT5_DIST_ATTN_BIAS
|-
| 019B
| [[#GPUREG_LIGHTi_ATTENUATION_SCALE|GPUREG_LIGHT5_ATTENUATION_SCALE]]
|
|PICA_REG_FRAG_LIGHT5_DIST_ATTN_SCALE
|-
| 019C
| [[#GPUREG_019C|GPUREG_019C]]
|
|
|-
| 019D
| [[#GPUREG_019D|GPUREG_019D]]
|
|
|-
| 019E
| [[#GPUREG_019E|GPUREG_019E]]
|
|
|-
| 019F
| [[#GPUREG_019F|GPUREG_019F]]
|
|
|-
| 01A0
| [[#GPUREG_LIGHTi_SPECULAR0|GPUREG_LIGHT6_SPECULAR0]]
|?
|PICA_REG_FRAG_LIGHT6_SPECULAR0
|-
| 01A1
| [[#GPUREG_LIGHTi_SPECULAR1|GPUREG_LIGHT6_SPECULAR1]]
|?
|PICA_REG_FRAG_LIGHT6_SPECULAR1
|-
| 01A2
| [[#GPUREG_LIGHTi_DIFFUSE|GPUREG_LIGHT6_DIFFUSE]]
|
|PICA_REG_FRAG_LIGHT6_DIFFUSE
|-
| 01A3
| [[#GPUREG_LIGHTi_AMBIENT|GPUREG_LIGHT6_AMBIENT]]
|
|PICA_REG_FRAG_LIGHT6_AMBIENT
|-
| 01A4
| [[#GPUREG_LIGHTi_XY|GPUREG_LIGHT6_XY]]
|
|PICA_REG_FRAG_LIGHT6_POSITION_XY
|-
| 01A5
| [[#GPUREG_LIGHTi_Z|GPUREG_LIGHT6_Z]]
|
|PICA_REG_FRAG_LIGHT6_POSITION_Z
|-
| 01A6
| [[#GPUREG_LIGHTi_SPOTDIR_XY|GPUREG_LIGHT6_SPOTDIR_XY]]
|?
|PICA_REG_FRAG_LIGHT6_SPOT_XY
|-
| 01A7
| [[#GPUREG_LIGHTi_SPOTDIR_Z|GPUREG_LIGHT6_SPOTDIR_Z]]
|?
|PICA_REG_FRAG_LIGHT6_SPOT_Z
|-
| 01A8
| [[#GPUREG_01A8|GPUREG_01A8]]
|
|
|-
| 01A9
| [[#GPUREG_LIGHTi_CONFIG|GPUREG_LIGHT6_CONFIG]]
|?
|PICA_REG_FRAG_LIGHT6_TYPE
|-
| 01AA
| [[#GPUREG_LIGHTi_ATTENUATION_BIAS|GPUREG_LIGHT6_ATTENUATION_BIAS]]
|
|PICA_REG_FRAG_LIGHT6_DIST_ATTN_BIAS
|-
| 01AB
| [[#GPUREG_LIGHTi_ATTENUATION_SCALE|GPUREG_LIGHT6_ATTENUATION_SCALE]]
|
|PICA_REG_FRAG_LIGHT6_DIST_ATTN_SCALE
|-
| 01AC
| [[#GPUREG_01AC|GPUREG_01AC]]
|
|
|-
| 01AD
| [[#GPUREG_01AD|GPUREG_01AD]]
|
|
|-
| 01AE
| [[#GPUREG_01AE|GPUREG_01AE]]
|
|
|-
| 01AF
| [[#GPUREG_01AF|GPUREG_01AF]]
|
|
|-
| 01B0
| [[#GPUREG_LIGHTi_SPECULAR0|GPUREG_LIGHT7_SPECULAR0]]
|?
|PICA_REG_FRAG_LIGHT7_SPECULAR0
|-
| 01B1
| [[#GPUREG_LIGHTi_SPECULAR1|GPUREG_LIGHT7_SPECULAR1]]
|?
|PICA_REG_FRAG_LIGHT7_SPECULAR1
|-
| 01B2
| [[#GPUREG_LIGHTi_DIFFUSE|GPUREG_LIGHT7_DIFFUSE]]
|?
|PICA_REG_FRAG_LIGHT7_DIFFUSE
|-
| 01B3
| [[#GPUREG_LIGHTi_AMBIENT|GPUREG_LIGHT7_AMBIENT]]
|?
|PICA_REG_FRAG_LIGHT7_AMBIENT
|-
| 01B4
| [[#GPUREG_LIGHTi_XY|GPUREG_LIGHT7_XY]]
|?
|PICA_REG_FRAG_LIGHT7_POSITION_XY
|-
| 01B5
| [[#GPUREG_LIGHTi_Z|GPUREG_LIGHT7_Z]]
|?
|PICA_REG_FRAG_LIGHT7_POSITION_Z
|-
| 01B6
| [[#GPUREG_LIGHTi_SPOTDIR_XY|GPUREG_LIGHT7_SPOTDIR_XY]]
|?
|PICA_REG_FRAG_LIGHT7_SPOT_XY
|-
| 01B7
| [[#GPUREG_LIGHTi_SPOTDIR_Z|GPUREG_LIGHT7_SPOTDIR_Z]]
|?
|PICA_REG_FRAG_LIGHT7_SPOT_Z
|-
| 01B8
| [[#GPUREG_01B8|GPUREG_01B8]]
|
|
|-
| 01B9
| [[#GPUREG_LIGHTi_CONFIG|GPUREG_LIGHT7_CONFIG]]
|?
|PICA_REG_FRAG_LIGHT7_TYPE
|-
| 01BA
| [[#GPUREG_LIGHTi_ATTENUATION_BIAS|GPUREG_LIGHT7_ATTENUATION_BIAS]]
|
|PICA_REG_FRAG_LIGHT7_DIST_ATTN_BIAS
|-
| 01BB
| [[#GPUREG_LIGHTi_ATTENUATION_SCALE|GPUREG_LIGHT7_ATTENUATION_SCALE]]
|
|PICA_REG_FRAG_LIGHT7_DIST_ATTN_SCALE
|-
| 01BC
| [[#GPUREG_01BC|GPUREG_01BC]]
|
|
|-
| 01BD
| [[#GPUREG_01BD|GPUREG_01BD]]
|
|
|-
| 01BE
| [[#GPUREG_01BE|GPUREG_01BE]]
|
|
|-
| 01BF
| [[#GPUREG_01BF|GPUREG_01BF]]
|
|
|-
| 01C0
| [[#GPUREG_LIGHTING_AMBIENT|GPUREG_LIGHTING_AMBIENT]]
|?
|PICA_REG_FRAG_LIGHT_AMBIENT
|-
| 01C1
| [[#GPUREG_01C1|GPUREG_01C1]]
|
|
|-
| 01C2
| [[#GPUREG_LIGHTING_NUM_LIGHTS|GPUREG_LIGHTING_NUM_LIGHTS]]
|?
|PICA_REG_FRAG_LIGHT_SRC_NUM
|-
| 01C3
| [[#GPUREG_LIGHTING_CONFIG0|GPUREG_LIGHTING_CONFIG0]]
|?
|PICA_REG_FRAG_LIGHT_FUNC_MODE0
|-
| 01C4
| [[#GPUREG_LIGHTING_CONFIG1|GPUREG_LIGHTING_CONFIG1]]
|?
|PICA_REG_FRAG_LIGHT_FUNC_MODE1
|-
| 01C5
| [[#GPUREG_LIGHTING_LUT_INDEX|GPUREG_LIGHTING_LUT_INDEX]]
|?
|PICA_REG_FRAG_LIGHT_LUT
|-
| 01C6
| [[#GPUREG_LIGHTING_ENABLE1|GPUREG_LIGHTING_ENABLE1]]
|?
|PICA_REG_FRAG_LIGHT_EN1
|-
| 01C7
| [[#GPUREG_01C7|GPUREG_01C7]]
|
|
|-
| 01C8
| [[#GPUREG_LIGHTING_LUT_DATAi|GPUREG_LIGHTING_LUT_DATA0]]
|?
|PICA_REG_FRAG_LIGHT_LUT_DATA0
|-
| 01C9
| [[#GPUREG_LIGHTING_LUT_DATAi|GPUREG_LIGHTING_LUT_DATA1]]
|?
|PICA_REG_FRAG_LIGHT_LUT_DATA1
|-
| 01CA
| [[#GPUREG_LIGHTING_LUT_DATAi|GPUREG_LIGHTING_LUT_DATA2]]
|?
|PICA_REG_FRAG_LIGHT_LUT_DATA2
|-
| 01CB
| [[#GPUREG_LIGHTING_LUT_DATAi|GPUREG_LIGHTING_LUT_DATA3]]
|?
|PICA_REG_FRAG_LIGHT_LUT_DATA3
|-
| 01CC
| [[#GPUREG_LIGHTING_LUT_DATAi|GPUREG_LIGHTING_LUT_DATA4]]
|?
|PICA_REG_FRAG_LIGHT_LUT_DATA4
|-
| 01CD
| [[#GPUREG_LIGHTING_LUT_DATAi|GPUREG_LIGHTING_LUT_DATA5]]
|?
|PICA_REG_FRAG_LIGHT_LUT_DATA5
|-
| 01CE
| [[#GPUREG_LIGHTING_LUT_DATAi|GPUREG_LIGHTING_LUT_DATA6]]
|?
|PICA_REG_FRAG_LIGHT_LUT_DATA6
|-
| 01CF
| [[#GPUREG_LIGHTING_LUT_DATAi|GPUREG_LIGHTING_LUT_DATA7]]
|?
|PICA_REG_FRAG_LIGHT_LUT_DATA7
|-
| 01D0
| [[#GPUREG_LIGHTING_LUTINPUT_ABS|GPUREG_LIGHTING_LUTINPUT_ABS]]
|?
|PICA_REG_FRAG_LIGHT_ABSLUTINPUT
|-
| 01D1
| [[#GPUREG_LIGHTING_LUTINPUT_SELECT|GPUREG_LIGHTING_LUTINPUT_SELECT]]
|?
|PICA_REG_FRAG_LIGHT_LUTINPUT
|-
| 01D2
| [[#GPUREG_LIGHTING_LUTINPUT_SCALE|GPUREG_LIGHTING_LUTINPUT_SCALE]]
|?
|PICA_REG_FRAG_LIGHT_LUTSCALE
|-
| 01D3
| [[#GPUREG_01D3|GPUREG_01D3]]
|
|
|-
| 01D4
| [[#GPUREG_01D4|GPUREG_01D4]]
|
|
|-
| 01D5
| [[#GPUREG_01D5|GPUREG_01D5]]
|
|
|-
| 01D6
| [[#GPUREG_01D6|GPUREG_01D6]]
|
|
|-
| 01D7
| [[#GPUREG_01D7|GPUREG_01D7]]
|
|
|-
| 01D8
| [[#GPUREG_01D8|GPUREG_01D8]]
|
|
|-
| 01D9
| [[#GPUREG_LIGHTING_LIGHT_PERMUTATION|GPUREG_LIGHTING_LIGHT_PERMUTATION]]
|?
|PICA_REG_FRAG_LIGHT_SRC_EN_ID
|-
| 01DA
| [[#GPUREG_01DA|GPUREG_01DA]]
|
|
|-
| 01DB
| [[#GPUREG_01DB|GPUREG_01DB]]
|
|
|-
| 01DC
| [[#GPUREG_01DC|GPUREG_01DC]]
|
|
|-
| 01DD
| [[#GPUREG_01DD|GPUREG_01DD]]
|
|
|-
| 01DE
| [[#GPUREG_01DE|GPUREG_01DE]]
|
|
|-
| 01DF
| [[#GPUREG_01DF|GPUREG_01DF]]
|
|
|-
| 01E0
| [[#GPUREG_01E0|GPUREG_01E0]]
|
|
|-
| 01E1
| [[#GPUREG_01E1|GPUREG_01E1]]
|
|
|-
| 01E2
| [[#GPUREG_01E2|GPUREG_01E2]]
|
|
|-
| 01E3
| [[#GPUREG_01E3|GPUREG_01E3]]
|
|
|-
| 01E4
| [[#GPUREG_01E4|GPUREG_01E4]]
|
|
|-
| 01E5
| [[#GPUREG_01E5|GPUREG_01E5]]
|
|
|-
| 01E6
| [[#GPUREG_01E6|GPUREG_01E6]]
|
|
|-
| 01E7
| [[#GPUREG_01E7|GPUREG_01E7]]
|
|
|-
| 01E8
| [[#GPUREG_01E8|GPUREG_01E8]]
|
|
|-
| 01E9
| [[#GPUREG_01E9|GPUREG_01E9]]
|
|
|-
| 01EA
| [[#GPUREG_01EA|GPUREG_01EA]]
|
|
|-
| 01EB
| [[#GPUREG_01EB|GPUREG_01EB]]
|
|
|-
| 01EC
| [[#GPUREG_01EC|GPUREG_01EC]]
|
|
|-
| 01ED
| [[#GPUREG_01ED|GPUREG_01ED]]
|
|
|-
| 01EE
| [[#GPUREG_01EE|GPUREG_01EE]]
|
|
|-
| 01EF
| [[#GPUREG_01EF|GPUREG_01EF]]
|
|
|-
| 01F0
| [[#GPUREG_01F0|GPUREG_01F0]]
|
|
|-
| 01F1
| [[#GPUREG_01F1|GPUREG_01F1]]
|
|
|-
| 01F2
| [[#GPUREG_01F2|GPUREG_01F2]]
|
|
|-
| 01F3
| [[#GPUREG_01F3|GPUREG_01F3]]
|
|
|-
| 01F4
| [[#GPUREG_01F4|GPUREG_01F4]]
|
|
|-
| 01F5
| [[#GPUREG_01F5|GPUREG_01F5]]
|
|
|-
| 01F6
| [[#GPUREG_01F6|GPUREG_01F6]]
|
|
|-
| 01F7
| [[#GPUREG_01F7|GPUREG_01F7]]
|
|
|-
| 01F8
| [[#GPUREG_01F8|GPUREG_01F8]]
|
|
|-
| 01F9
| [[#GPUREG_01F9|GPUREG_01F9]]
|
|
|-
| 01FA
| [[#GPUREG_01FA|GPUREG_01FA]]
|
|
|-
| 01FB
| [[#GPUREG_01FB|GPUREG_01FB]]
|
|
|-
| 01FC
| [[#GPUREG_01FC|GPUREG_01FC]]
|
|
|-
| 01FD
| [[#GPUREG_01FD|GPUREG_01FD]]
|
|
|-
| 01FE
| [[#GPUREG_01FE|GPUREG_01FE]]
|
|
|-
| 01FF
| [[#GPUREG_01FF|GPUREG_01FF]]
|
|
|}

=== Geometry pipeline registers (0x200-0x27F) ===

{| class="wikitable" border="1"
! Register ID
! Register name
! Notes
! Official Name
|-
| 0200
| [[#GPUREG_ATTRIBBUFFERS_LOC|GPUREG_ATTRIBBUFFERS_LOC]]
|
|PICA_REG_VTX_ATTR_ARRAYS_BASE_ADDR
|-
| 0201
| [[#GPUREG_ATTRIBBUFFERS_FORMAT_LOW|GPUREG_ATTRIBBUFFERS_FORMAT_LOW]]
|
|PICA_REG_VTX_ATTR_ARRAYS0
|-
| 0202
| [[#GPUREG_ATTRIBBUFFERS_FORMAT_HIGH|GPUREG_ATTRIBBUFFERS_FORMAT_HIGH]]
|
|PICA_REG_VTX_ATTR_ARRAYS1
|-
| 0203
| [[#GPUREG_ATTRIBBUFFERi_OFFSET|GPUREG_ATTRIBBUFFER0_OFFSET]]
|
|PICA_REG_LOAD_ARRAY0_ATTR_OFFSET
|-
| 0204
| [[#GPUREG_ATTRIBBUFFERi_CONFIG1|GPUREG_ATTRIBBUFFER0_CONFIG1]]
|
|PICA_REG_LOAD_ARRAY0_ELEMENT0
|-
| 0205
| [[#GPUREG_ATTRIBBUFFERi_CONFIG2|GPUREG_ATTRIBBUFFER0_CONFIG2]]
|
|PICA_REG_LOAD_ARRAY0_ELEMENT1
|-
| 0206
| [[#GPUREG_ATTRIBBUFFERi_OFFSET|GPUREG_ATTRIBBUFFER1_OFFSET]]
|
|
|-
| 0207
| [[#GPUREG_ATTRIBBUFFERi_CONFIG1|GPUREG_ATTRIBBUFFER1_CONFIG1]]
|
|
|-
| 0208
| [[#GPUREG_ATTRIBBUFFERi_CONFIG2|GPUREG_ATTRIBBUFFER1_CONFIG2]]
|
|
|-
| 0209
| [[#GPUREG_ATTRIBBUFFERi_OFFSET|GPUREG_ATTRIBBUFFER2_OFFSET]]
|
|
|-
| 020A
| [[#GPUREG_ATTRIBBUFFERi_CONFIG1|GPUREG_ATTRIBBUFFER2_CONFIG1]]
|
|
|-
| 020B
| [[#GPUREG_ATTRIBBUFFERi_CONFIG2|GPUREG_ATTRIBBUFFER2_CONFIG2]]
|
|
|-
| 020C
| [[#GPUREG_ATTRIBBUFFERi_OFFSET|GPUREG_ATTRIBBUFFER3_OFFSET]]
|
|
|-
| 020D
| [[#GPUREG_ATTRIBBUFFERi_CONFIG1|GPUREG_ATTRIBBUFFER3_CONFIG1]]
|
|
|-
| 020E
| [[#GPUREG_ATTRIBBUFFERi_CONFIG2|GPUREG_ATTRIBBUFFER3_CONFIG2]]
|
|
|-
| 020F
| [[#GPUREG_ATTRIBBUFFERi_OFFSET|GPUREG_ATTRIBBUFFER4_OFFSET]]
|
|
|-
| 0210
| [[#GPUREG_ATTRIBBUFFERi_CONFIG1|GPUREG_ATTRIBBUFFER4_CONFIG1]]
|
|
|-
| 0211
| [[#GPUREG_ATTRIBBUFFERi_CONFIG2|GPUREG_ATTRIBBUFFER4_CONFIG2]]
|
|
|-
| 0212
| [[#GPUREG_ATTRIBBUFFERi_OFFSET|GPUREG_ATTRIBBUFFER5_OFFSET]]
|
|
|-
| 0213
| [[#GPUREG_ATTRIBBUFFERi_CONFIG1|GPUREG_ATTRIBBUFFER5_CONFIG1]]
|
|
|-
| 0214
| [[#GPUREG_ATTRIBBUFFERi_CONFIG2|GPUREG_ATTRIBBUFFER5_CONFIG2]]
|
|
|-
| 0215
| [[#GPUREG_ATTRIBBUFFERi_OFFSET|GPUREG_ATTRIBBUFFER6_OFFSET]]
|
|
|-
| 0216
| [[#GPUREG_ATTRIBBUFFERi_CONFIG1|GPUREG_ATTRIBBUFFER6_CONFIG1]]
|
|
|-
| 0217
| [[#GPUREG_ATTRIBBUFFERi_CONFIG2|GPUREG_ATTRIBBUFFER6_CONFIG2]]
|
|
|-
| 0218
| [[#GPUREG_ATTRIBBUFFERi_OFFSET|GPUREG_ATTRIBBUFFER7_OFFSET]]
|
|
|-
| 0219
| [[#GPUREG_ATTRIBBUFFERi_CONFIG1|GPUREG_ATTRIBBUFFER7_CONFIG1]]
|
|
|-
| 021A
| [[#GPUREG_ATTRIBBUFFERi_CONFIG2|GPUREG_ATTRIBBUFFER7_CONFIG2]]
|
|
|-
| 021B
| [[#GPUREG_ATTRIBBUFFERi_OFFSET|GPUREG_ATTRIBBUFFER8_OFFSET]]
|
|
|-
| 021C
| [[#GPUREG_ATTRIBBUFFERi_CONFIG1|GPUREG_ATTRIBBUFFER8_CONFIG1]]
|
|
|-
| 021D
| [[#GPUREG_ATTRIBBUFFERi_CONFIG2|GPUREG_ATTRIBBUFFER8_CONFIG2]]
|
|
|-
| 021E
| [[#GPUREG_ATTRIBBUFFERi_OFFSET|GPUREG_ATTRIBBUFFER9_OFFSET]]
|
|
|-
| 021F
| [[#GPUREG_ATTRIBBUFFERi_CONFIG1|GPUREG_ATTRIBBUFFER9_CONFIG1]]
|
|
|-
| 0220
| [[#GPUREG_ATTRIBBUFFERi_CONFIG2|GPUREG_ATTRIBBUFFER9_CONFIG2]]
|
|
|-
| 0221
| [[#GPUREG_ATTRIBBUFFERi_OFFSET|GPUREG_ATTRIBBUFFER10_OFFSET]]
|
|
|-
| 0222
| [[#GPUREG_ATTRIBBUFFERi_CONFIG1|GPUREG_ATTRIBBUFFER10_CONFIG1]]
|
|
|-
| 0223
| [[#GPUREG_ATTRIBBUFFERi_CONFIG2|GPUREG_ATTRIBBUFFER10_CONFIG2]]
|
|
|-
| 0224
| [[#GPUREG_ATTRIBBUFFERi_OFFSET|GPUREG_ATTRIBBUFFER11_OFFSET]]
|
|
|-
| 0225
| [[#GPUREG_ATTRIBBUFFERi_CONFIG1|GPUREG_ATTRIBBUFFER11_CONFIG1]]
|
|
|-
| 0226
| [[#GPUREG_ATTRIBBUFFERi_CONFIG2|GPUREG_ATTRIBBUFFER11_CONFIG2]]
|
|
|-
| 0227
| [[#GPUREG_INDEXBUFFER_CONFIG|GPUREG_INDEXBUFFER_CONFIG]]
|
|PICA_REG_INDEX_ARRAY_ADDR_OFFSET
|-
| 0228
| [[#GPUREG_NUMVERTICES|GPUREG_NUMVERTICES]]
|
|PICA_REG_DRAW_VERTEX_NUM
|-
| 0229
| [[#GPUREG_GEOSTAGE_CONFIG|GPUREG_GEOSTAGE_CONFIG]]
| ?
|PICA_REG_DRAW_MODE0
|-
| 022A
| [[#GPUREG_VERTEX_OFFSET|GPUREG_VERTEX_OFFSET]]
|
|PICA_REG_DRAW_VERTEX_OFFSET
|-
| 022B
| [[#GPUREG_022B|GPUREG_022B]]
|
|
|-
| 022C
| [[#GPUREG_022C|GPUREG_022C]]
|
|
|-
| 022D
| [[#GPUREG_POST_VERTEX_CACHE_NUM|GPUREG_POST_VERTEX_CACHE_NUM]]
|
|PICA_REG_POST_VERTEX_CACHE_NUM
|-
| 022E
| [[#GPUREG_DRAWARRAYS|GPUREG_DRAWARRAYS]]
|
|PICA_REG_START_DRAW_ARRAY
|-
| 022F
| [[#GPUREG_DRAWELEMENTS|GPUREG_DRAWELEMENTS]]
|
|PICA_REG_START_DRAW_ELEMENT
|-
| 0230
| [[#GPUREG_0230|GPUREG_0230]]
|
|
|-
| 0231
| [[#GPUREG_VTX_FUNC|GPUREG_VTX_FUNC]]
|?
|PICA_REG_VTX_FUNC
|-
| 0232
| [[#GPUREG_FIXEDATTRIB_INDEX|GPUREG_FIXEDATTRIB_INDEX]]
|?
|PICA_REG_VS_FIXED_ATTR
|-
| 0233
| [[#GPUREG_FIXEDATTRIB_DATAi|GPUREG_FIXEDATTRIB_DATA0]]
|?
|PICA_REG_VS_FIXED_ATTR_DATA0
|-
| 0234
| [[#GPUREG_FIXEDATTRIB_DATAi|GPUREG_FIXEDATTRIB_DATA1]]
|?
|PICA_REG_VS_FIXED_ATTR_DATA1
|-
| 0235
| [[#GPUREG_FIXEDATTRIB_DATAi|GPUREG_FIXEDATTRIB_DATA2]]
|?
|PICA_REG_VS_FIXED_ATTR_DATA2
|-
| 0236
| [[#GPUREG_0236|GPUREG_0236]]
|
|
|-
| 0237
| [[#GPUREG_0237|GPUREG_0237]]
|
|
|-
| 0238
| [[#GPUREG_CMDBUF_SIZE0|GPUREG_CMDBUF_SIZE0]]
|
|PICA_REG_COMMAND_BUF_SIZE_CH0
|-
| 0239
| [[#GPUREG_CMDBUF_SIZE1|GPUREG_CMDBUF_SIZE1]]
|
|PICA_REG_COMMAND_BUF_SIZE_CH1
|-
| 023A
| [[#GPUREG_CMDBUF_ADDR0|GPUREG_CMDBUF_ADDR0]]
|
|PICA_REG_COMMAND_BUF_ADDR_CH0
|-
| 023B
| [[#GPUREG_CMDBUF_ADDR1|GPUREG_CMDBUF_ADDR1]]
|
|PICA_REG_COMMAND_BUF_ADDR_CH1
|-
| 023C
| [[#GPUREG_CMDBUF_JUMP0|GPUREG_CMDBUF_JUMP0]]
|
|PICA_REG_COMMAND_BUF_KICK_CH0
|-
| 023D
| [[#GPUREG_CMDBUF_JUMP1|GPUREG_CMDBUF_JUMP1]]
|
|PICA_REG_COMMAND_BUF_KICK_CH1
|-
| 023E
| [[#GPUREG_023E|GPUREG_023E]]
|
|
|-
| 023F
| [[#GPUREG_023F|GPUREG_023F]]
|
|
|-
| 0240
| [[#GPUREG_0240|GPUREG_0240]]
|
|
|-
| 0241
| [[#GPUREG_0241|GPUREG_0241]]
|
|
|-
| 0242
| [[#GPUREG_VSH_NUM_ATTR|GPUREG_VSH_NUM_ATTR]]
|?
|PICA_REG_VS_ATTR_NUM1
|-
| 0243
| [[#GPUREG_0243|GPUREG_0243]]
|
|
|-
| 0244
| [[#GPUREG_VSH_COM_MODE|GPUREG_VSH_COM_MODE]]
|?
|PICA_REG_VS_COM_MODE
|-
| 0245
| [[#GPUREG_START_DRAW_FUNC0|GPUREG_START_DRAW_FUNC0]]
|?
|PICA_REG_START_DRAW_FUNC0
|-
| 0246
| [[#GPUREG_0246|GPUREG_0246]]
|
|
|-
| 0247
| [[#GPUREG_0247|GPUREG_0247]]
|
|
|-
| 0248
| [[#GPUREG_0248|GPUREG_0248]]
|
|
|-
| 0249
| [[#GPUREG_0249|GPUREG_0249]]
|
|
|-
| 024A
| [[#GPUREG_VSH_OUTMAP_TOTAL1|GPUREG_VSH_OUTMAP_TOTAL1]]
|?
|PICA_REG_VS_OUT_REG_NUM1
|-
| 024B
| [[#GPUREG_024B|GPUREG_024B]]
|
|
|-
| 024C
| [[#GPUREG_024C|GPUREG_024C]]
|
|
|-
| 024D
| [[#GPUREG_024D|GPUREG_024D]]
|
|
|-
| 024E
| [[#GPUREG_024E|GPUREG_024E]]
|
|
|-
| 024F
| [[#GPUREG_024F|GPUREG_024F]]
|
|
|-
| 0250
| [[#GPUREG_0250|GPUREG_0250]]
|
|
|-
| 0251
| [[#GPUREG_VSH_OUTMAP_TOTAL2|GPUREG_VSH_OUTMAP_TOTAL2]]
|?
|PICA_REG_VS_OUT_REG_NUM2
|-
| 0252
| [[#GPUREG_GSH_MISC0|GPUREG_GSH_MISC0]]
|?
|PICA_REG_GS_MISC_REG0
|-
| 0253
| [[#GPUREG_GEOSTAGE_CONFIG2|GPUREG_GEOSTAGE_CONFIG2]]
|?
|PICA_REG_DRAW_MODE1
|-
| 0254
| [[#GPUREG_GSH_MISC1|GPUREG_GSH_MISC1]]
|?
|PICA_REG_GS_MISC_REG1
|-
| 0255
| [[#GPUREG_0255|GPUREG_0255]]
|
|
|-
| 0256
| [[#GPUREG_0256|GPUREG_0256]]
|
|
|-
| 0257
| [[#GPUREG_0257|GPUREG_0257]]
|
|
|-
| 0258
| [[#GPUREG_0258|GPUREG_0258]]
|
|
|-
| 0259
| [[#GPUREG_0259|GPUREG_0259]]
|
|
|-
| 025A
| [[#GPUREG_025A|GPUREG_025A]]
|
|
|-
| 025B
| [[#GPUREG_025B|GPUREG_025B]]
|
|
|-
| 025C
| [[#GPUREG_025C|GPUREG_025C]]
|
|
|-
| 025D
| [[#GPUREG_025D|GPUREG_025D]]
|
|
|-
| 025E
| [[#GPUREG_PRIMITIVE_CONFIG|GPUREG_PRIMITIVE_CONFIG]]
| ?
|PICA_REG_GS_OUT_REG_NUM3 / PICA_REG_DRAW_MODE2 / PICA_REG_VS_OUT_REG_NUM3
|-
| 025F
| [[#GPUREG_RESTART_PRIMITIVE|GPUREG_RESTART_PRIMITIVE]]
|?
|PICA_REG_START_DRAW_FUNC1
|-
| 0260
| [[#GPUREG_0260|GPUREG_0260]]
|
|
|-
| 0261
| [[#GPUREG_0261|GPUREG_0261]]
|
|
|-
| 0262
| [[#GPUREG_0262|GPUREG_0262]]
|
|
|-
| 0263
| [[#GPUREG_0263|GPUREG_0263]]
|
|
|-
| 0264
| [[#GPUREG_0264|GPUREG_0264]]
|
|
|-
| 0265
| [[#GPUREG_0265|GPUREG_0265]]
|
|
|-
| 0266
| [[#GPUREG_0266|GPUREG_0266]]
|
|
|-
| 0267
| [[#GPUREG_0267|GPUREG_0267]]
|
|
|-
| 0268
| [[#GPUREG_0268|GPUREG_0268]]
|
|
|-
| 0269
| [[#GPUREG_0269|GPUREG_0269]]
|
|
|-
| 026A
| [[#GPUREG_026A|GPUREG_026A]]
|
|
|-
| 026B
| [[#GPUREG_026B|GPUREG_026B]]
|
|
|-
| 026C
| [[#GPUREG_026C|GPUREG_026C]]
|
|
|-
| 026D
| [[#GPUREG_026D|GPUREG_026D]]
|
|
|-
| 026E
| [[#GPUREG_026E|GPUREG_026E]]
|
|
|-
| 026F
| [[#GPUREG_026F|GPUREG_026F]]
|
|
|-
| 0270
| [[#GPUREG_0270|GPUREG_0270]]
|
|
|-
| 0271
| [[#GPUREG_0271|GPUREG_0271]]
|
|
|-
| 0272
| [[#GPUREG_0272|GPUREG_0272]]
|
|
|-
| 0273
| [[#GPUREG_0273|GPUREG_0273]]
|
|
|-
| 0274
| [[#GPUREG_0274|GPUREG_0274]]
|
|
|-
| 0275
| [[#GPUREG_0275|GPUREG_0275]]
|
|
|-
| 0276
| [[#GPUREG_0276|GPUREG_0276]]
|
|
|-
| 0277
| [[#GPUREG_0277|GPUREG_0277]]
|
|
|-
| 0278
| [[#GPUREG_0278|GPUREG_0278]]
|
|
|-
| 0279
| [[#GPUREG_0279|GPUREG_0279]]
|
|
|-
| 027A
| [[#GPUREG_027A|GPUREG_027A]]
|
|
|-
| 027B
| [[#GPUREG_027B|GPUREG_027B]]
|
|
|-
| 027C
| [[#GPUREG_027C|GPUREG_027C]]
|
|
|-
| 027D
| [[#GPUREG_027D|GPUREG_027D]]
|
|
|-
| 027E
| [[#GPUREG_027E|GPUREG_027E]]
|
|
|-
| 027F
| [[#GPUREG_027F|GPUREG_027F]]
|
|
|}

=== Shader registers (0x280-0x2DF) ===

{| class="wikitable" border="1"
! Register ID
! Register name
! Notes
! Official Name
|-
! colspan=4 | Geometry shader
|-
| 0280
| [[#GPUREG_SH_BOOLUNIFORM|GPUREG_GSH_BOOLUNIFORM]]
|
|PICA_REG_GS_BOOL
|-
| 0281
| [[#GPUREG_SH_INTUNIFORM_Ii|GPUREG_GSH_INTUNIFORM_I0]]
|
|PICA_REG_GS_INT0
|-
| 0282
| [[#GPUREG_SH_INTUNIFORM_Ii|GPUREG_GSH_INTUNIFORM_I1]]
|
|PICA_REG_GS_INT1
|-
| 0283
| [[#GPUREG_SH_INTUNIFORM_Ii|GPUREG_GSH_INTUNIFORM_I2]]
|
|PICA_REG_GS_INT2
|-
| 0284
| [[#GPUREG_SH_INTUNIFORM_Ii|GPUREG_GSH_INTUNIFORM_I3]]
|
|PICA_REG_GS_INT3
|-
| 0285
| [[#GPUREG_0285|GPUREG_0285]]
|
|
|-
| 0286
| [[#GPUREG_0286|GPUREG_0286]]
|
|
|-
| 0287
| [[#GPUREG_0287|GPUREG_0287]]
|
|
|-
| 0288
| [[#GPUREG_0288|GPUREG_0288]]
|
|
|-
| 0289
| [[#GPUREG_SH_INPUTBUFFER_CONFIG|GPUREG_GSH_INPUTBUFFER_CONFIG]]
|
|PICA_REG_GS_ATTR_NUM
|-
| 028A
| [[#GPUREG_SH_ENTRYPOINT|GPUREG_GSH_ENTRYPOINT]]
|
|PICA_REG_GS_START_ADDR
|-
| 028B
| [[#GPUREG_SH_ATTRIBUTES_PERMUTATION_LOW|GPUREG_GSH_ATTRIBUTES_PERMUTATION_LOW]]
|
|PICA_REG_GS_ATTR_IN_REG_MAP0
|-
| 028C
| [[#GPUREG_SH_ATTRIBUTES_PERMUTATION_HIGH|GPUREG_GSH_ATTRIBUTES_PERMUTATION_HIGH]]
|
|PICA_REG_GS_ATTR_IN_REG_MAP1
|-
| 028D
| [[#GPUREG_SH_OUTMAP_MASK|GPUREG_GSH_OUTMAP_MASK]]
|
|PICA_REG_GS_OUT_REG_MASK
|-
| 028E
| [[#GPUREG_028E|GPUREG_028E]]
|
|
|-
| 028F
| [[#GPUREG_SH_CODETRANSFER_END|GPUREG_GSH_CODETRANSFER_END]]
|
|PICA_REG_GS_PROG_RENEWAL_END
|-
| 0290
| [[#GPUREG_SH_FLOATUNIFORM_INDEX|GPUREG_GSH_FLOATUNIFORM_INDEX]]
|
|PICA_REG_GS_FLOAT_ADDR
|-
| 0291
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_GSH_FLOATUNIFORM_DATA0]]
|
|PICA_REG_GS_FLOAT_DATA0
|-
| 0292
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_GSH_FLOATUNIFORM_DATA1]]
|
|PICA_REG_GS_FLOAT_DATA1
|-
| 0293
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_GSH_FLOATUNIFORM_DATA2]]
|
|PICA_REG_GS_FLOAT_DATA2
|-
| 0294
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_GSH_FLOATUNIFORM_DATA3]]
|
|PICA_REG_GS_FLOAT_DATA3
|-
| 0295
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_GSH_FLOATUNIFORM_DATA4]]
|
|PICA_REG_GS_FLOAT_DATA4
|-
| 0296
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_GSH_FLOATUNIFORM_DATA5]]
|
|PICA_REG_GS_FLOAT_DATA5
|-
| 0297
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_GSH_FLOATUNIFORM_DATA6]]
|
|PICA_REG_GS_FLOAT_DATA6
|-
| 0298
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_GSH_FLOATUNIFORM_DATA7]]
|
|PICA_REG_GS_FLOAT_DATA7
|-
| 0299
| [[#GPUREG_0299|GPUREG_0299]]
|
|
|-
| 029A
| [[#GPUREG_029A|GPUREG_029A]]
|
|
|-
| 029B
| [[#GPUREG_SH_CODETRANSFER_INDEX|GPUREG_GSH_CODETRANSFER_INDEX]]
| ?
|PICA_REG_GS_PROG_ADDR
|-
| 029C
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_GSH_CODETRANSFER_DATA0]]
|
|PICA_REG_GS_PROG_DATA0
|-
| 029D
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_GSH_CODETRANSFER_DATA1]]
|
|PICA_REG_GS_PROG_DATA1
|-
| 029E
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_GSH_CODETRANSFER_DATA2]]
|
|PICA_REG_GS_PROG_DATA2
|-
| 029F
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_GSH_CODETRANSFER_DATA3]]
|
|PICA_REG_GS_PROG_DATA3
|-
| 02A0
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_GSH_CODETRANSFER_DATA4]]
|
|PICA_REG_GS_PROG_DATA4
|-
| 02A1
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_GSH_CODETRANSFER_DATA5]]
|
|PICA_REG_GS_PROG_DATA5
|-
| 02A2
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_GSH_CODETRANSFER_DATA6]]
|
|PICA_REG_GS_PROG_DATA6
|-
| 02A3
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_GSH_CODETRANSFER_DATA7]]
|
|PICA_REG_GS_PROG_DATA7
|-
| 02A4
| [[#GPUREG_02A4|GPUREG_02A4]]
|
|
|-
| 02A5
| [[#GPUREG_SH_OPDESCS_INDEX|GPUREG_GSH_OPDESCS_INDEX]]
|
|PICA_REG_GS_PROG_SWIZZLE_ADDR
|-
| 02A6
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_GSH_OPDESCS_DATA0]]
|
|PICA_REG_GS_PROG_SWIZZLE_DATA0
|-
| 02A7
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_GSH_OPDESCS_DATA1]]
|
|PICA_REG_GS_PROG_SWIZZLE_DATA1
|-
| 02A8
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_GSH_OPDESCS_DATA2]]
|
|PICA_REG_GS_PROG_SWIZZLE_DATA2
|-
| 02A9
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_GSH_OPDESCS_DATA3]]
|
|PICA_REG_GS_PROG_SWIZZLE_DATA3
|-
| 02AA
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_GSH_OPDESCS_DATA4]]
|
|PICA_REG_GS_PROG_SWIZZLE_DATA4
|-
| 02AB
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_GSH_OPDESCS_DATA5]]
|
|PICA_REG_GS_PROG_SWIZZLE_DATA5
|-
| 02AC
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_GSH_OPDESCS_DATA6]]
|
|PICA_REG_GS_PROG_SWIZZLE_DATA6
|-
| 02AD
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_GSH_OPDESCS_DATA7]]
|
|PICA_REG_GS_PROG_SWIZZLE_DATA7
|-
| 02AE
| [[#GPUREG_02AE|GPUREG_02AE]]
|
|
|-
| 02AF
| [[#GPUREG_02AF|GPUREG_02AF]]
|
|
|-
! colspan=4 | Vertex shader
|-
| 02B0
| [[#GPUREG_SH_BOOLUNIFORM|GPUREG_VSH_BOOLUNIFORM]]
|
|PICA_REG_VS_BOOL
|-
| 02B1
| [[#GPUREG_SH_INTUNIFORM_Ii|GPUREG_VSH_INTUNIFORM_I0]]
|
|PICA_REG_VS_INT0
|-
| 02B2
| [[#GPUREG_SH_INTUNIFORM_Ii|GPUREG_VSH_INTUNIFORM_I1]]
|
|PICA_REG_VS_INT1
|-
| 02B3
| [[#GPUREG_SH_INTUNIFORM_Ii|GPUREG_VSH_INTUNIFORM_I2]]
|
|PICA_REG_VS_INT2
|-
| 02B4
| [[#GPUREG_SH_INTUNIFORM_Ii|GPUREG_VSH_INTUNIFORM_I3]]
|
|PICA_REG_VS_INT3
|-
| 02B5
| [[#GPUREG_02B5|GPUREG_02B5]]
|
|
|-
| 02B6
| [[#GPUREG_02B6|GPUREG_02B6]]
|
|
|-
| 02B7
| [[#GPUREG_02B7|GPUREG_02B7]]
|
|
|-
| 02B8
| [[#GPUREG_02B8|GPUREG_02B8]]
|
|
|-
| 02B9
| [[#GPUREG_SH_INPUTBUFFER_CONFIG|GPUREG_VSH_INPUTBUFFER_CONFIG]]
|
|PICA_REG_VS_ATTR_NUM0
|-
| 02BA
| [[#GPUREG_SH_ENTRYPOINT|GPUREG_VSH_ENTRYPOINT]]
|
|PICA_REG_VS_START_ADDR
|-
| 02BB
| [[#GPUREG_SH_ATTRIBUTES_PERMUTATION_LOW|GPUREG_VSH_ATTRIBUTES_PERMUTATION_LOW]]
|
|PICA_REG_VS_ATTR_IN_REG_MAP0
|-
| 02BC
| [[#GPUREG_SH_ATTRIBUTES_PERMUTATION_HIGH|GPUREG_VSH_ATTRIBUTES_PERMUTATION_HIGH]]
|
|PICA_REG_VS_ATTR_IN_REG_MAP1
|-
| 02BD
| [[#GPUREG_SH_OUTMAP_MASK|GPUREG_VSH_OUTMAP_MASK]]
|
|PICA_REG_VS_OUT_REG_MASK
|-
| 02BE
| [[#GPUREG_02BE|GPUREG_02BE]]
|
|
|-
| 02BF
| [[#GPUREG_SH_CODETRANSFER_END|GPUREG_VSH_CODETRANSFER_END]]
|
|PICA_REG_VS_PROG_RENEWAL_END
|-
| 02C0
| [[#GPUREG_SH_FLOATUNIFORM_INDEX|GPUREG_VSH_FLOATUNIFORM_INDEX]]
|
|PICA_REG_VS_FLOAT_ADDR
|-
| 02C1
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_VSH_FLOATUNIFORM_DATA0]]
|
|PICA_REG_VS_FLOAT_DATA0
|-
| 02C2
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_VSH_FLOATUNIFORM_DATA1]]
|
|PICA_REG_VS_FLOAT_DATA1
|-
| 02C3
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_VSH_FLOATUNIFORM_DATA2]]
|
|PICA_REG_VS_FLOAT_DATA2
|-
| 02C4
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_VSH_FLOATUNIFORM_DATA3]]
|
|PICA_REG_VS_FLOAT_DATA3
|-
| 02C5
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_VSH_FLOATUNIFORM_DATA4]]
|
|PICA_REG_VS_FLOAT_DATA4
|-
| 02C6
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_VSH_FLOATUNIFORM_DATA5]]
|
|PICA_REG_VS_FLOAT_DATA5
|-
| 02C7
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_VSH_FLOATUNIFORM_DATA6]]
|
|PICA_REG_VS_FLOAT_DATA6
|-
| 02C8
| [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_VSH_FLOATUNIFORM_DATA7]]
|
|PICA_REG_VS_FLOAT_DATA7
|-
| 02C9
| [[#GPUREG_02C9|GPUREG_02C9]]
|
|
|-
| 02CA
| [[#GPUREG_02CA|GPUREG_02CA]]
|
|
|-
| 02CB
| [[#GPUREG_SH_CODETRANSFER_INDEX|GPUREG_VSH_CODETRANSFER_INDEX]]
| ?
|PICA_REG_VS_PROG_ADDR
|-
| 02CC
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_VSH_CODETRANSFER_DATA0]]
|
|PICA_REG_VS_PROG_DATA0
|-
| 02CD
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_VSH_CODETRANSFER_DATA1]]
|
|PICA_REG_VS_PROG_DATA1
|-
| 02CE
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_VSH_CODETRANSFER_DATA2]]
|
|PICA_REG_VS_PROG_DATA2
|-
| 02CF
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_VSH_CODETRANSFER_DATA3]]
|
|PICA_REG_VS_PROG_DATA3
|-
| 02D0
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_VSH_CODETRANSFER_DATA4]]
|
|PICA_REG_VS_PROG_DATA4
|-
| 02D1
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_VSH_CODETRANSFER_DATA5]]
|
|PICA_REG_VS_PROG_DATA5
|-
| 02D2
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_VSH_CODETRANSFER_DATA6]]
|
|PICA_REG_VS_PROG_DATA6
|-
| 02D3
| [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_VSH_CODETRANSFER_DATA7]]
|
|PICA_REG_VS_PROG_DATA7
|-
| 02D4
| [[#GPUREG_02D4|GPUREG_02D4]]
|
|
|-
| 02D5
| [[#GPUREG_SH_OPDESCS_INDEX|GPUREG_VSH_OPDESCS_INDEX]]
| ?
|PICA_REG_VS_PROG_SWIZZLE_ADDR
|-
| 02D6
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_VSH_OPDESCS_DATA0]]
|
|PICA_REG_VS_PROG_SWIZZLE_DATA0
|-
| 02D7
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_VSH_OPDESCS_DATA1]]
|
|PICA_REG_VS_PROG_SWIZZLE_DATA1
|-
| 02D8
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_VSH_OPDESCS_DATA2]]
|
|PICA_REG_VS_PROG_SWIZZLE_DATA2
|-
| 02D9
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_VSH_OPDESCS_DATA3]]
|
|PICA_REG_VS_PROG_SWIZZLE_DATA3
|-
| 02DA
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_VSH_OPDESCS_DATA4]]
|
|PICA_REG_VS_PROG_SWIZZLE_DATA4
|-
| 02DB
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_VSH_OPDESCS_DATA5]]
|
|PICA_REG_VS_PROG_SWIZZLE_DATA5
|-
| 02DC
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_VSH_OPDESCS_DATA6]]
|
|PICA_REG_VS_PROG_SWIZZLE_DATA6
|-
| 02DD
| [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_VSH_OPDESCS_DATA7]]
|
|PICA_REG_VS_PROG_SWIZZLE_DATA7
|-
| 02DE
| [[#GPUREG_02DE|GPUREG_02DE]]
|
|
|-
| 02DF
| [[#GPUREG_02DF|GPUREG_02DF]]
|
|
|}

=== Unknown registers (0x2E0-0x2FF) ===

{| class="wikitable" border="1"
! Register ID
! Register name
! Notes
! Official Name
|-
| 02E0
| [[#GPUREG_02E0|GPUREG_02E0]]
|
|
|-
| 02E1
| [[#GPUREG_02E1|GPUREG_02E1]]
|
|
|-
| 02E2
| [[#GPUREG_02E2|GPUREG_02E2]]
|
|
|-
| 02E3
| [[#GPUREG_02E3|GPUREG_02E3]]
|
|
|-
| 02E4
| [[#GPUREG_02E4|GPUREG_02E4]]
|
|
|-
| 02E5
| [[#GPUREG_02E5|GPUREG_02E5]]
|
|
|-
| 02E6
| [[#GPUREG_02E6|GPUREG_02E6]]
|
|
|-
| 02E7
| [[#GPUREG_02E7|GPUREG_02E7]]
|
|
|-
| 02E8
| [[#GPUREG_02E8|GPUREG_02E8]]
|
|
|-
| 02E9
| [[#GPUREG_02E9|GPUREG_02E9]]
|
|
|-
| 02EA
| [[#GPUREG_02EA|GPUREG_02EA]]
|
|
|-
| 02EB
| [[#GPUREG_02EB|GPUREG_02EB]]
|
|
|-
| 02EC
| [[#GPUREG_02EC|GPUREG_02EC]]
|
|
|-
| 02ED
| [[#GPUREG_02ED|GPUREG_02ED]]
|
|
|-
| 02EE
| [[#GPUREG_02EE|GPUREG_02EE]]
|
|
|-
| 02EF
| [[#GPUREG_02EF|GPUREG_02EF]]
|
|
|-
| 02F0
| [[#GPUREG_02F0|GPUREG_02F0]]
|
|
|-
| 02F1
| [[#GPUREG_02F1|GPUREG_02F1]]
|
|
|-
| 02F2
| [[#GPUREG_02F2|GPUREG_02F2]]
|
|
|-
| 02F3
| [[#GPUREG_02F3|GPUREG_02F3]]
|
|
|-
| 02F4
| [[#GPUREG_02F4|GPUREG_02F4]]
|
|
|-
| 02F5
| [[#GPUREG_02F5|GPUREG_02F5]]
|
|
|-
| 02F6
| [[#GPUREG_02F6|GPUREG_02F6]]
|
|
|-
| 02F7
| [[#GPUREG_02F7|GPUREG_02F7]]
|
|
|-
| 02F8
| [[#GPUREG_02F8|GPUREG_02F8]]
|
|
|-
| 02F9
| [[#GPUREG_02F9|GPUREG_02F9]]
|
|
|-
| 02FA
| [[#GPUREG_02FA|GPUREG_02FA]]
|
|
|-
| 02FB
| [[#GPUREG_02FB|GPUREG_02FB]]
|
|
|-
| 02FC
| [[#GPUREG_02FC|GPUREG_02FC]]
|
|
|-
| 02FD
| [[#GPUREG_02FD|GPUREG_02FD]]
|
|
|-
| 02FE
| [[#GPUREG_02FE|GPUREG_02FE]]
|
|
|-
| 02FF
| [[#GPUREG_02FF|GPUREG_02FF]]
|
|
|}

== Miscellaneous registers ==

=== GPUREG_FINALIZE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| unsigned, Trigger P3D Interrupt (0 = idle, non-zero = trigger)
|}

Writing to this register seems to signal the GPU to stop processing GPU commands from the current buffer; any command following a write to this register will be ignored. The value written to this register does not appear to matter, although 0x12345678 is the value typically written by commercial software.
Failure to write to this register in any command buffer will result in the GPU hanging.

== Rasterizer registers ==

=== GPUREG_FACECULLING_CONFIG ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| unsigned, Culling mode
|}

This register is used to configure the face culling mode.

Culling mode values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| None
|-
| 1
| Front Face (Counter Clockwise)
|-
| 2
| Back Face (Counter Clockwise)
|}

=== GPUREG_VIEWPORT_WIDTH ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-23
| float1.7.16, width / 2
|}

This register is used to configure the viewport width, along with GPUREG_VIEWPORT_INVW.

=== GPUREG_VIEWPORT_INVW ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 1-31
| float1.7.23, 2 / width
|}

This register is used to configure the viewport width, along with GPUREG_VIEWPORT_WIDTH.

=== GPUREG_VIEWPORT_HEIGHT ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-23
| float1.7.16, height / 2
|}

This register is used to configure the viewport height, along with GPUREG_VIEWPORT_INVH.

=== GPUREG_VIEWPORT_INVH ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 1-31
| float1.7.23, 2 / height
|}

This register is used to configure the viewport height, along with GPUREG_VIEWPORT_HEIGHT.

=== GPUREG_FRAGOP_CLIP ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Enabled (0 = disabled, 1 = enabled)
|}

This register is used to enable clipping planes.

=== GPUREG_FRAGOP_CLIP_DATA''i'' ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-23
| float1.7.16, Clipping plane coefficient ''i''
|}

This register is used to configure clipping plane coefficients.

=== GPUREG_DEPTHMAP_SCALE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-23
| float1.7.16, Near - Far
|}

This register is used to configure the depth range scale.

=== GPUREG_DEPTHMAP_OFFSET ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-23
| float1.7.16, Near + Polygon Offset
|}

This register is used to configure the depth range bias.

=== GPUREG_SH_OUTMAP_TOTAL ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-2
| unsigned, Number of following attributes
|}

This register is used to configure the total shader output map attributes.

=== GPUREG_SH_OUTMAP_O''i'' ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-4
| unsigned, Semantic for the x component of the register.
|-
| 8-12
| unsigned, Semantic for the y component of the register.
|-
| 16-20
| unsigned, Semantic for the z component of the register.
|-
| 24-28
| unsigned, Semantic for the w component of the register.
|}

These registers map components of the corresponding vertex shader output register to specific fixed-function semantics.

Semantics that have not been mapped to a component of an output register have a value of 1

Semantic values:

{| class="wikitable" border="1"
! Value
! Semantic
! Description
|-
| 0x00
| position.x
| rowspan="4" | Vertex Position
|-
| 0x01
| position.y
|-
| 0x02
| position.z
|-
| 0x03
| position.w
|-
| 0x04
| normquat.x
| rowspan="4" | Quaternion specifying the normal/tangent frame (for fragment lighting)
|-
| 0x05
| normquat.y
|-
| 0x06
| normquat.z
|-
| 0x07
| normquat.w
|-
| 0x08
| color.r
| rowspan="4" | Vertex color
|-
| 0x09
| color.g
|-
| 0x0A
| color.b
|-
| 0x0B
| color.a
|-
| 0x0C
| texcoord0.u
| rowspan="2" | Texture coordinates for texture 0
|-
| 0x0D
| texcoord0.v
|-
| 0x0E
| texcoord1.u
| rowspan="2" | Texture coordinates for texture 1
|-
| 0x0F
| texcoord1.v
|-
| 0x10
| texcoord0.w
|

|-
| 0x12
| view.x
| rowspan="3" | View vector (for fragment lighting)
|-
| 0x13
| view.y
|-
| 0x14
| view.z

|-
| 0x16
| texcoord2.u
| rowspan="2" | Texture coordinates for texture 2
|-
| 0x17
| texcoord2.v

|-
| 0x1F
| Unused component
| Should be set for unused components of the output register
|}

=== GPUREG_EARLYDEPTH_FUNC ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| unsigned, Early depth function
|}

This register configures the early depth test function.

Early depth function values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| >=
|-
| 1
| >
|-
| 2
| <=
|-
| 3
| <
|}

=== GPUREG_EARLYDEPTH_TEST1 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Enabled (0 = disabled, 1 = enabled)
|}

This register sets whether the early depth test is enabled.

=== GPUREG_EARLYDEPTH_CLEAR ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Trigger (0 = idle, 1 = clear)
|}

This register triggers clearing the early depth data.

=== GPUREG_SH_OUTATTR_MODE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Use texture coordinates (0 = don't use, 1 = use)
|}

This register is used to configure the shader output attribute mode.

=== GPUREG_SCISSORTEST_MODE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| unsigned, Enabled (0 = disabled, 3 = enabled)
|}

This register is used to enable scissor testing.

=== GPUREG_SCISSORTEST_POS ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-9
| unsigned, X1
|-
| 16-25
| unsigned, Y1
|}

This register is used to configure the scissor test start position.

=== GPUREG_SCISSORTEST_DIM ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-9
| unsigned, X2
|-
| 16-25
| unsigned, Y2
|}

This register is used to configure the scissor test end position.

=== GPUREG_VIEWPORT_XY ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-9
| signed, X
|-
| 16-25
| signed, Y
|}

This register is used to configure the viewport position.

=== GPUREG_EARLYDEPTH_DATA ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-23
| unsigned, Clear value
|}

This register is used to configure the early depth clear value.

=== GPUREG_DEPTHMAP_ENABLE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Enabled (0 = disabled, 1 = enabled)
|}

This register is used to enable depth range.

=== GPUREG_RENDERBUF_DIM ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-10
| unsigned, Width
|-
| 12-21
| unsigned, Height - 1
|-
| 24
| 0x1
|}

This register is used to configure the output framebuffer dimensions.

=== GPUREG_SH_OUTATTR_CLOCK ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, 'position.z' present (0 = absent, 1 = present)
|-
| 1
| unsigned, 'color' component present (0 = absent, 1 = present)
|-
| 8
| unsigned, 'texcoord0' component present (0 = absent, 1 = present)
|-
| 9
| unsigned, 'texcoord1' component present (0 = absent, 1 = present)
|-
| 10
| unsigned, 'texcoord2' component present (0 = absent, 1 = present)
|-
| 16
| unsigned, 'texcoord0.w' present (0 = absent, 1 = present)
|-
| 24
| unsigned, 'normquat' or 'view' component present (0 = absent, 1 = present)
|}

This register controls the clock supply to parts relating to certain attributes.

== Texturing registers ==

=== GPUREG_TEXUNIT_CONFIG ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Texture 0 enabled (0 = disabled, 1 = enabled)
|-
| 1
| unsigned, Texture 1 enabled (0 = disabled, 1 = enabled)
|-
| 2
| unsigned, Texture 2 enabled (0 = disabled, 1 = enabled)
|-
| 3
| 0x0
|-
| 8-9
| unsigned, Texture 3 coordinates
|-
| 10
| unsigned, Texture 3 enabled (0 = disabled, 1 = enabled)
|-
| 12
| 0x1
|-
| 13
| unsigned, Texture 2 coordinates
|-
| 16
| unsigned, Clear texture cache (0 = don't clear, 1 = clear)
|-
| 17-31
| 0x0
|}

This register is used to enable texture units.

Texture 3 coordinates values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Texture 0
|-
| 1
| Texture 1
|-
| 2
| Texture 2
|}

Texture 2 coordinates values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Texture 2
|-
| 1
| Texture 1
|}

=== GPUREG_TEXUNIT''i''_BORDER_COLOR ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Red
|-
| 8-15
| unsigned, Green
|-
| 16-23
| unsigned, Blue
|-
| 24-31
| unsigned, Alpha
|}

This register is used to set a texture unit's border color.

=== GPUREG_TEXUNIT''i''_DIM ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-10
| unsigned, Height
|-
| 16-26
| unsigned, Width
|}

This register is used to set a texture unit's dimensions.

=== GPUREG_TEXUNIT''i''_PARAM ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 1
| unsigned, Magnification filter
|-
| 2
| unsigned, Minification filter
|-
| 4-5
| unsigned, ETC1 (0 = not ETC1, 2 = ETC1) note: still 0 for ETC1A4
|-
| 8-10
| unsigned, Wrap T
|-
| 12-14
| unsigned, Wrap S
|-
| 16-17
| 0x0
|-
| 20
| unsigned, Shadow (Texture 0 only, 0 = not shadow, 1 = shadow)
|-
| 24
| unsigned, Mipmap filter
|-
| 28-30
| unsigned, Type (Texture 0 only)
|}

This register is used to set a texture unit's extra parameters.

Filter values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Nearest
|-
| 1
| Linear
|}

Wrap values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Clamp to edge
|-
| 1
| Clamp to border
|-
| 2
| Repeat
|-
| 3
| Mirrored repeat
|}

Type values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| 2D
|-
| 1
| Cube map
|-
| 2
| Shadow 2D
|-
| 3
| Projection
|-
| 4
| Shadow cube
|-
| 5
| Disabled
|}

=== GPUREG_TEXUNIT''i''_LOD ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-12
| fixed1.4.8, Bias
|-
| 16-19
| unsigned, Max Level
|-
| 24-27
| unsigned, Min Level
|}

This register is used to configure a texture unit's level of detail.

=== GPUREG_TEXUNIT''i''_ADDR''i'' ===

First ADDR register:
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-27
| unsigned, Texture physical address >> 3
|}

Subsequent ADDR registers:
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-21
| unsigned, Texture physical address >> 3 (upper 6 bits reused from first ADDR register)
|}

This register is used to set a texture unit's physical address(es) in memory. Individual texels in a texture are laid out in memory as a [http://en.wikipedia.org/wiki/Z-order_curve Z-order curve]. Mipmap data is stored directly following the main texture data.

If the texture is a cube:

{| class="wikitable" border="1"
! Register
! Description
|-
| ADDR1
| Positive X
|-
| ADDR2
| Negative X
|-
| ADDR3
| Positive Y
|-
| ADDR4
| Negative Y
|-
| ADDR5
| Positive Z
|-
| ADDR6
| Negative Z
|}

Otherwise, ADDR(1) points to a 2D texture, and the rest are empty.

=== GPUREG_TEXUNIT''i''_SHADOW ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Perspective (0 = perspective, 1 = not perspective)
|-
| 1-23
| fixed0.0.24, Z bias (upper 23 bits)
|}

This register is used to set a texture unit's shadow texture properties.

=== GPUREG_TEXUNIT''i''_TYPE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, Format
|}

This register is used to set a texture unit's data format.

Format values:

{| class="wikitable" border="1"
! Value
! Description
! GL Format
! GL Data Type
|-
| 0x0
| RGBA8888
| GL_RGBA
| GL_UNSIGNED_BYTE
|-
| 0x1
| RGB888
| GL_RGB
| GL_UNSIGNED_BYTE
|-
| 0x2
| RGBA5551
| GL_RGBA
| GL_UNSIGNED_SHORT_5_5_5_1
|-
| 0x3
| RGB565
| GL_RGB
| GL_UNSIGNED_SHORT_5_6_5
|-
| 0x4
| RGBA4444
| GL_RGBA
| GL_UNSIGNED_SHORT_4_4_4_4
|-
| 0x5
| IA8
| GL_LUMINANCE_ALPHA
| GL_UNSIGNED_BYTE
|-
| 0x6
| HILO8
|
|
|-
| 0x7
| I8
| GL_LUMINANCE
| GL_UNSIGNED_BYTE
|-
| 0x8
| A8
| GL_ALPHA
| GL_UNSIGNED_BYTE
|-
| 0x9
| IA44
| GL_LUMINANCE_ALPHA
| GL_UNSIGNED_BYTE_4_4_EXT
|-
| 0xA
| I4
|
|
|-
| 0xB
| A4
| GL_ALPHA
| GL_UNSIGNED_NIBBLE_EXT
|-
| 0xC
| ETC1
| GL_ETC1_RGB8_OES
|
|-
| 0xD
| ETC1A4
|
|
|}

=== GPUREG_LIGHTING_ENABLE0 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Enabled (0 = disabled, 1 = enabled)
|}

This register is used to enable lighting.

=== GPUREG_TEXUNIT3_PROCTEX0 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-2
| unsigned, U-direction clamp
|-
| 3-5
| unsigned, V-direction clamp
|-
| 6-9
| unsigned, RGB mapping function
|-
| 10-13
| unsigned, Alpha mapping function
|-
| 14
| unsigned, Handle alpha separately (0 = don't separate, 1 = separate)
|-
| 15
| unsigned, Noise enabled (0 = disabled, 1 = enabled)
|-
| 16-17
| unsigned, U-direction shift
|-
| 18-19
| unsigned, V-direction shift
|-
| 20-27
| float1.5.10, Texture bias (lower 8 bits)
|}

This register is used to configure the procedural texture unit.

Clamp values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Clamp to zero
|-
| 1
| Clamp to edge
|-
| 2
| Symmetrical repeat
|-
| 3
| Mirrored repeat
|-
| 4
| Pulse
|}

Mapping function values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| U
|-
| 1
| U²
|-
| 2
| V
|-
| 3
| V²
|-
| 4
| (U + V) / 2
|-
| 5
| (U² + V²) / 2
|-
| 6
| sqrt(U² + V²)
|-
| 7
| Minimum
|-
| 8
| Maximum
|-
| 9
| Rmax
|}

Shift values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| None
|-
| 1
| Odd
|-
| 2
| Even
|}

=== GPUREG_TEXUNIT3_PROCTEX1 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-15
| fixed1.3.12, U-direction noise amplitude
|-
| 16-31
| float1.5.10, U-direction noise phase
|}

This register is used to configure the procedural texture unit's U-direction noise amplitude/phase.

=== GPUREG_TEXUNIT3_PROCTEX2 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-15
| fixed1.3.12, V-direction noise amplitude
|-
| 16-31
| float1.5.10, V-direction noise phase
|}

This register is used to configure the procedural texture unit's V-direction noise amplitude/phase.

=== GPUREG_TEXUNIT3_PROCTEX3 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-15
| float1.5.10, U-direction noise frequency
|-
| 16-31
| float1.5.10, V-direction noise frequency
|}

This register is used to configure the procedural texture unit's U-direction and V-direction noise frequency.

=== GPUREG_TEXUNIT3_PROCTEX4 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-2
| unsigned, Minification filter
|-
| 3-6
| Min LOD (usually 0)
|-
| 7-10
| Max LOD (usually 6)
|-
| 11-18
| unsigned, Texture width
|-
| 19-26
| float1.5.10, Texture bias (upper 8 bits)
|}

This register is used to configure the procedural texture unit.

Minification filter values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Nearest
|-
| 1
| Linear
|-
| 2
| Nearest, Mipmap Nearest
|-
| 3
| Linear, Mipmap Nearest
|-
| 4
| Nearest, Mipmap Linear
|-
| 5
| Linear, Mipmap Linear
|}

=== GPUREG_TEXUNIT3_PROCTEX5 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Texture offset (Mipmap level 0 / base level)
|-
| 8-15
| unsigned, mipmap level 1 offset (usually 0x80)
|-
| 16-23
| unsigned, mipmap level 2 offset (usually 0xC0)
|-
| 24-31
| unsigned, mipmap level 3 offset (usually 0xE0)
|}

This register is used to set the procedural texture unit's offset. Mipmap level 4-7 seems to be hardcoded at offset 0xF0, 0xF8, 0xFC and 0xFE .

=== GPUREG_PROCTEX_LUT ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Index
|-
| 8-11
| unsigned, Reference table
|}

This register is used to set which look-up table to write to, with GPUREG_PROCTEX_LUT_DATA''i'', at what index.

Reference table values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Noise table
|-
| 2
| RGB mapping function table
|-
| 3
| Alpha mapping function table
|-
| 4
| Color table
|-
| 5
| Color difference table
|}

=== GPUREG_PROCTEX_LUT_DATA''i'' ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| LUT data
|}

These registers behave as a FIFO queue. Each write to these registers writes the provided value to the table selected with GPUREG_PROCTEX_LUT, starting at the selected index.

==== Noise Table ====

128 elements:
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-11
| fixed0.0.12, Value
|-
| 12-23
| fixed0.0.12 with two's complement ( [0.5,1.0) mapped to [-1.0,0) ), Difference from next element
|}

==== RGB Mapping Function Table ====

128 elements:
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-11
| fixed0.0.12, Value
|-
| 12-23
| fixed0.0.12 with two's complement, Difference from next element
|}

==== Alpha Mapping Function Table ====

128 elements:
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-11
| fixed0.0.12, Value
|-
| 12-23
| fixed0.0.12 with two's complement, Difference from next element
|}

==== Color Table ====

256 elements:
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Red
|-
| 8-15
| unsigned, Green
|-
| 16-23
| unsigned, Blue
|-
| 24-31
| unsigned, Alpha
|}

==== Color Difference Table ====

256 elements:
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| signed, Half of red difference between current and next color table elements
|-
| 8-15
| signed, Half of green difference between current and next color table elements
|-
| 16-23
| signed, Half of blue difference between current and next color table elements
|-
| 24-31
| signed, Half of alpha difference between current and next color table elements
|}

=== GPUREG_TEXENV''i''_SOURCE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, RGB source 0
|-
| 4-7
| unsigned, RGB source 1
|-
| 8-11
| unsigned, RGB source 2
|-
| 16-19
| unsigned, Alpha source 0
|-
| 20-23
| unsigned, Alpha source 1
|-
| 24-27
| unsigned, Alpha source 2
|}

This register configures a texture combiner's sources.

Source values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Primary color
|-
| 1
| Fragment primary color
|-
| 2
| Fragment secondary color
|-
| 3
| Texture 0
|-
| 4
| Texture 1
|-
| 5
| Texture 2
|-
| 6
| Texture 3
|-
| 13
| Previous buffer
|-
| 14
| Constant (from GPUREG_TEXENV''i''_COLOR)
|-
| 15
| Previous
|}

Using Previous (15) as a source in the first TEV stage returns the value of source 3. If source 3 has Previous it returns zero. Previous buffer (13) always returns zero.

=== GPUREG_TEXENV''i''_OPERAND ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, RGB operand 0
|-
| 4-7
| unsigned, RGB operand 1
|-
| 8-11
| unsigned, RGB operand 2
|-
| 12-14
| unsigned, Alpha operand 0
|-
| 16-18
| unsigned, Alpha operand 1
|-
| 20-22
| unsigned, Alpha operand 2
|}

This register configures a texture combiner's operands.

RGB operand values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Source color
|-
| 1
| One minus source color
|-
| 2
| Source alpha
|-
| 3
| One minus source alpha
|-
| 4
| Source red
|-
| 5
| One minus source red
|-
| 8
| Source green
|-
| 9
| One minus source green
|-
| 12
| Source blue
|-
| 13
| One minus source blue
|}

Alpha operand values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Source alpha
|-
| 1
| One minus source alpha
|-
| 2
| Source red
|-
| 3
| One minus source red
|-
| 4
| Source green
|-
| 5
| One minus source green
|-
| 6
| Source blue
|-
| 7
| One minus source blue
|}

=== GPUREG_TEXENV''i''_COMBINER ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, RGB combine
|-
| 16-19
| unsigned, Alpha combine
|}

This register configures a texture combiner's combine mode.

Combine values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Replace
|-
| 1
| Modulate
|-
| 2
| Add
|-
| 3
| Add signed
|-
| 4
| Interpolate
|-
| 5
| Subtract
|-
| 6
| Dot3 RGB
|-
| 7
| Dot3 RGBA
|-
| 8
| Multiply then add
|-
| 9
| Add then multiply
|}

=== GPUREG_TEXENV''i''_COLOR ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Red
|-
| 8-15
| unsigned, Green
|-
| 16-23
| unsigned, Blue
|-
| 24-31
| unsigned, Alpha
|}

This register configures a texture combiner's constant color.

=== GPUREG_TEXENV''i''_SCALE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| unsigned, RGB scale
|-
| 16-17
| unsigned, Alpha scale
|}

This register configures a texture combiner's scale value.

Scale values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| 1x
|-
| 1
| 2x
|-
| 2
| 4x
|}

=== GPUREG_TEXENV_UPDATE_BUFFER ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-2
| unsigned, Fog mode
|-
| 3
| unsigned, Shading density source
|-
| 8
| unsigned, TexEnv 1 RGB buffer input
|-
| 9
| unsigned, TexEnv 2 RGB buffer input
|-
| 10
| unsigned, TexEnv 3 RGB buffer input
|-
| 11
| unsigned, TexEnv 4 RGB buffer input
|-
| 12
| unsigned, TexEnv 1 alpha buffer input
|-
| 13
| unsigned, TexEnv 2 alpha buffer input
|-
| 14
| unsigned, TexEnv 3 alpha buffer input
|-
| 15
| unsigned, TexEnv 4 alpha buffer input
|-
| 16
| unsigned, Z flip (0 = don't flip, 1 = flip)
|-
| 24-25
| 0x0
|}

This register is shared between the gas/fog mode configuration and texture combiner buffer inputs. Texture combiner buffer inputs are typically written with a mask of 0x2, and the gas/fog mode configuration is typically written with a mask of 0x5.

Fog mode values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Disabled
|-
| 5
| Fog
|-
| 7
| Gas
|}

Shading density source values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Plain density
|-
| 1
| Depth density
|}

Buffer input values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Previous buffer
|-
| 1
| Previous
|}

=== GPUREG_FOG_COLOR ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Red
|-
| 8-15
| unsigned, Green
|-
| 16-23
| unsigned, Blue
|}

This register is used to configure the color of fog.

=== GPUREG_GAS_ATTENUATION ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-15
| float1.5.10, Gas density attenuation
|}

This register is used to configure the gas density attenuation.

=== GPUREG_GAS_ACCMAX ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-15
| float1.5.10, Gas maximum density accumulation
|}

This register is used to configure the gas maximum density accumulation.

=== GPUREG_FOG_LUT_INDEX ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-15
| unsigned, Index
|}

This register is used to set what index to write to with GPUREG_FOG_LUT_DATA''i''.

=== GPUREG_FOG_LUT_DATA''i'' ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-23
| LUT data
|}

These registers behave as a FIFO queue. Each write to these registers writes the provided value to the fog look-up table, starting at the index selected with GPUREG_FOG_LUT_INDEX.

==== Fog Look-Up Table ====

128 elements:
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-12
| fixed1.1.11, Difference from next element
|-
| 13-23
| fixed0.0.11, Value
|}

=== GPUREG_TEXENV_BUFFER_COLOR ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Red
|-
| 8-15
| unsigned, Green
|-
| 16-23
| unsigned, Blue
|-
| 24-31
| unsigned, Alpha
|}

This register is used to configure the texture combiner buffer color.

== Framebuffer registers ==

=== GPUREG_COLOR_OPERATION ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| unsigned, Fragment operation mode
|-
| 8
| unsigned, Blend mode
|-
| 16-25
| 0x0E4
|}

This register is used to configure the fragment operation mode and whether to use logic ops or blending.

Fragment operation mode values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Default
|-
| 1
| Gas
|-
| 3
| Shadow
|}

Blend mode values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Logic op
|-
| 1
| Blend
|}

=== GPUREG_BLEND_FUNC ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-2
| unsigned, RGB equation
|-
| 8-10
| unsigned, Alpha equation
|-
| 16-19
| unsigned, RGB source function
|-
| 20-23
| unsigned, RGB destination function
|-
| 24-27
| unsigned, Alpha source function
|-
| 28-31
| unsigned, Alpha destination function
|}

This register is used to configure the blending function.

'''Equation values:'''

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Add
|-
| 1
| Subtract
|-
| 2
| Reverse subtract
|-
| 3
| Minimum
|-
| 4
| Maximum
|}

Blend equations 5, 6, 7 appear to behave the same as blend equation 0 (Add)

'''Function values:'''

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Zero
|-
| 1
| One
|-
| 2
| Source color
|-
| 3
| One minus source color
|-
| 4
| Destination color
|-
| 5
| One minus destination color
|-
| 6
| Source alpha
|-
| 7
| One minus source alpha
|-
| 8
| Destination alpha
|-
| 9
| One minus destination alpha
|-
| 10
| Constant color
|-
| 11
| One minus constant color
|-
| 12
| Constant alpha
|-
| 13
| One minus constant alpha
|-
| 14
| Source alpha saturate
|}

=== GPUREG_LOGIC_OP ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, Logic op
|}

This register is used to configure the logic op.

Logic op values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Clear
|-
| 1
| AND
|-
| 2
| Reverse AND
|-
| 3
| Copy
|-
| 4
| Set
|-
| 5
| Inverted copy
|-
| 6
| Noop
|-
| 7
| Invert
|-
| 8
| NAND
|-
| 9
| OR
|-
| 10
| NOR
|-
| 11
| XOR
|-
| 12
| Equivalent
|-
| 13
| Inverted AND
|-
| 14
| Reverse OR
|-
| 15
| Inverted OR
|}

=== GPUREG_BLEND_COLOR ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Red
|-
| 8-15
| unsigned, Green
|-
| 16-23
| unsigned, Blue
|-
| 24-31
| unsigned, Alpha
|}

This register is used to configure the blending color.

=== GPUREG_FRAGOP_ALPHA_TEST ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Enabled (0 = disabled, 1 = enabled)
|-
| 4-6
| unsigned, Function
|-
| 8-15
| unsigned, Reference value
|}

This register is used to configure alpha testing.

Function values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Never
|-
| 1
| Always
|-
| 2
| Equal
|-
| 3
| Not equal
|-
| 4
| Less than
|-
| 5
| Less than or equal
|-
| 6
| Greater than
|-
| 7
| Greater than or equal
|}

=== GPUREG_STENCIL_TEST ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Enabled (0 = disabled, 1 = enabled)
|-
| 4-6
| unsigned, Function
|-
| 8-15
| unsigned, Buffer mask
|-
| 16-23
| signed, Reference value
|-
| 24-31
| unsigned, Mask
|}

This register is used to configure stencil testing.

Function values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Never
|-
| 1
| Always
|-
| 2
| Equal
|-
| 3
| Not equal
|-
| 4
| Less than
|-
| 5
| Less than or equal
|-
| 6
| Greater than
|-
| 7
| Greater than or equal
|}

=== GPUREG_STENCIL_OP ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-2
| unsigned, Fail operation
|-
| 4-6
| unsigned, Z-fail operation
|-
| 8-10
| unsigned, Z-pass operation
|}

This register is used to configure stencil result operations.

Operation values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Keep
|-
| 1
| Zero
|-
| 2
| Replace
|-
| 3
| Increment
|-
| 4
| Decrement
|-
| 5
| Invert
|-
| 6
| Increment and wrap
|-
| 7
| Decrement and wrap
|}

=== GPUREG_DEPTH_COLOR_MASK ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Depth test enabled (0 = disabled, 1 = enabled)
|-
| 4-6
| unsigned, Depth function
|-
| 8
| unsigned, Red write enabled (0 = disabled, 1 = enabled)
|-
| 9
| unsigned, Green write enabled (0 = disabled, 1 = enabled)
|-
| 10
| unsigned, Blue write enabled (0 = disabled, 1 = enabled)
|-
| 11
| unsigned, Alpha write enabled (0 = disabled, 1 = enabled)
|-
| 12
| unsigned, Depth write enabled (0 = disabled, 1 = enabled)
|}

This register is used to depth testing and framebuffer write masking.

Note that setting the "Depth test enabled" bit to 0 will ''not'' also disable depth writes. It will instead behave as if the depth function were set to "Always". To completely disable depth-related operations both the depth test and depth write bits must be disabled.

Depth function values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Never
|-
| 1
| Always
|-
| 2
| Equal
|-
| 3
| Not equal
|-
| 4
| Less than
|-
| 5
| Less than or equal
|-
| 6
| Greater than
|-
| 7
| Greater than or equal
|}

=== GPUREG_FRAMEBUFFER_INVALIDATE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Trigger (0 = idle, 1 = invalidate)
|-
| 1-31
| 0x0
|}

Writing 1 to this register invalidates the framebuffer cache. This should be done when changing the framebuffer or when it is cleared before rendering. Note that it does '''not''' flush the cache, so it should always be preceded by a write to GPUREG_FRAMEBUFFER_FLUSH.

=== GPUREG_FRAMEBUFFER_FLUSH ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Trigger (0 = idle, 1 = flush)
|-
| 1-31
| 0x0
|}

Writing 1 to this register flushes the framebuffer cache to memory. This should be done after rendering before changing the framebuffer or using rendering results.

=== GPUREG_COLORBUFFER_READ ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, Allow read (0 = disable, 0xF = enable)
|}

This register configures read access from the color buffer.

=== GPUREG_COLORBUFFER_WRITE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, Allow write (0 = disable, 0xF = enable)
|}

This register configures write access to the color buffer.

=== GPUREG_DEPTHBUFFER_READ ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Allow stencil read (0 = disable, 1 = enable)
|-
| 1
| unsigned, Allow depth read (0 = disable, 1 = enable)
|}

This register configures read access from the depth and stencil buffers.

=== GPUREG_DEPTHBUFFER_WRITE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Allow stencil write (0 = disable, 1 = enable)
|-
| 1
| unsigned, Allow depth write (0 = disable, 1 = enable)
|}

This register configures write access to the depth and stencil buffers.

=== GPUREG_DEPTHBUFFER_FORMAT ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| unsigned, Format
|}

This register configures the depth buffer data format.

Format values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| 16-bit depth
|-
| 2
| 24-bit depth
|-
| 3
| 24-bit depth + 8-bit stencil
|}

=== GPUREG_COLORBUFFER_FORMAT ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| unsigned, Pixel size
|-
| 16-18
| unsigned, Format
|}

This register configures the color buffer data format. Color components are laid out in reverse byte order in memory, with the most significant bits used first.

Pixel size values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| 16-bit color
|-
| 2
| 32-bit color
|}

Format values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| RGBA8/Gas
|-
| 2
| RGB5A1
|-
| 3
| RGB565
|-
| 4
| RGBA4
|}

=== GPUREG_EARLYDEPTH_TEST2 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Enabled (0 = disabled, 1 = enabled)
|}

This register enables the early depth test.

=== GPUREG_FRAMEBUFFER_BLOCK32 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Render block mode
|}

This register configures the framebuffer block mode. To untile the color buffer when using the 32x32 block format, use bit 16 of the [[GPU/External_Registers#Transfer_Engine|display transfer flags]]. It is unknown if there are any advantages to using the 32x32 format.

Render block mode values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| 8x8 blocks
|-
| 1
| 32x32 blocks
|}

=== GPUREG_DEPTHBUFFER_LOC ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-27
| unsigned, Depth buffer physical address >> 3
|}

This register configures the depth buffer physical address.

=== GPUREG_COLORBUFFER_LOC ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-27
| unsigned, Color buffer physical address >> 3
|}

This register configures the color buffer physical address.

=== GPUREG_FRAMEBUFFER_DIM ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-10
| unsigned, Width
|-
| 12-21
| unsigned, Height - 1
|-
| 24
| unsigned, Vertical flip? (0 = enable, 1 = disable)
|}

This register configures the framebuffer dimensions.

=== GPUREG_GAS_LIGHT_XY ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Planar shading minimum intensity
|-
| 8-15
| unsigned, Planar shading maximum intensity
|-
| 16-23
| unsigned, Planar shading density attenuation
|}

This register configures gas light planar shading.

=== GPUREG_GAS_LIGHT_Z ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, View shading minimum intensity
|-
| 8-15
| unsigned, View shading maximum intensity
|-
| 16-23
| unsigned, View shading density attenuation
|}

This register configures gas light view shading.

=== GPUREG_GAS_LIGHT_Z_COLOR ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, View shading effect in line-of-sight direction
|-
| 8
| Gas color LUT input
|}

This register configures gas light shading in the line-of-sight direction, and the input to the gas color LUT.

Color LUT input values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Gas density
|-
| 1
| Light factor
|}

=== GPUREG_GAS_LUT_INDEX ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-15
| unsigned, Index
|}

This register is used to set what index to write to with GPUREG_GAS_LUT_DATA''i''.

=== GPUREG_GAS_LUT_DATA ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| LUT data
|}

These registers behave as a FIFO queue. Each write to these registers writes the provided value to the gas look-up table, starting at the index selected with GPUREG_GAS_LUT_INDEX.

==== Gas Look-Up Table ====

16 elements:

First 8 elements:
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| signed, Red
|-
| 8-15
| signed, Green
|-
| 16-23
| signed, Blue
|}

Last 8 elements:
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Red
|-
| 8-15
| unsigned, Green
|-
| 16-23
| unsigned, Blue
|}

=== GPUREG_GAS_DELTAZ_DEPTH ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-23
| fixed0.16.8, Depth direction attenuation proportion
|-
| 24-25
| unsigned, Depth function
|}

This register is used to configure the gas depth direction attenuation proportion, as well as the gas depth function.

Gas depth function values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Never
|-
| 1
| Always
|-
| 2
| Greater than/Greater than or equal
|-
| 3
| Less than/Less than or equal/Equal/Not equal
|}

=== GPUREG_FRAGOP_SHADOW ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-15
| float1.5.10, Sum of penumbra scale and penumbra bias
|-
| 16-31
| float1.5.10, Penumbra scale with reversed sign
|}

This register is used to configure shadow properties.

== Fragment lighting registers ==

=== GPUREG_LIGHT''i''_SPECULAR0 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Blue
|-
| 10-17
| unsigned, Green
|-
| 20-27
| unsigned, Red
|}

These registers contain the specular0 color of the corresponding light. Usually set to material_specular0*lightX_specular0.

=== GPUREG_LIGHT''i''_SPECULAR1 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Blue
|-
| 10-17
| unsigned, Green
|-
| 20-27
| unsigned, Red
|}

These registers contain the specular1 color of the corresponding light. Usually set to material_specular1*lightX_specular1.

=== GPUREG_LIGHT''i''_DIFFUSE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Blue
|-
| 10-17
| unsigned, Green
|-
| 20-27
| unsigned, Red
|}

These registers contain the diffuse color of the corresponding light. Usually set to material_diffuse*lightX_diffuse.

=== GPUREG_LIGHT''i''_AMBIENT ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Blue
|-
| 10-17
| unsigned, Green
|-
| 20-27
| unsigned, Red
|}

These registers contain the ambient color of the corresponding light. Usually set to material_ambient*lightX_ambient.

=== GPUREG_LIGHT''i''_XY ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-15
| float1.5.10, X coordinate
|-
| 16-31
| float1.5.10, Y coordinate
|}

These registers (along with GPUREG_LIGHT''i''_Z) represent the light position (for a positional light) or the light direction vector (for a directional light) of the corresponding light.

=== GPUREG_LIGHT''i''_Z ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-15
| float1.5.10, Z coordinate
|}

These registers (along with GPUREG_LIGHT''i''_XY) represent the light position (for a positional light) or the light direction vector (for a directional light) of the corresponding light.

=== GPUREG_LIGHT''i''_SPOTDIR_XY ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-12
| fixed1.1.11, X coordinate (negated)
|-
| 16-28
| fixed1.1.11, Y coordinate (negated)
|}

These registers (along with GPUREG_LIGHT''i''_SPOTDIR_Z) represent the spot direction (unitary) vector of the corresponding light.

=== GPUREG_LIGHT''i''_SPOTDIR_Z ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-12
| fixed1.1.11, Z coordinate (negated)
|}

These registers (along with GPUREG_LIGHT''i''_SPOTDIR_XY) represent the spot direction (unitary) vector of the corresponding light.

=== GPUREG_LIGHT''i''_CONFIG ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Light type (0 = positional light, 1 = directional light)
|-
| 1
| unsigned, Two side diffuse (0 = one side, 1 = both sides)
|-
| 2
| unsigned, Use geometric factor 0 (0 = don't use, 1 = use)
|-
| 3
| unsigned, Use geometric factor 1 (0 = don't use, 1 = use)
|}

This register configures a light's properties.

=== GPUREG_LIGHT''i''_ATTENUATION_BIAS ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-19
| float1.7.12, Distance attenuation bias
|}

These registers contain the distance attenuation bias value of the corresponding light. The attenuation factor is DA(clip(bias + scale*distance, 0.0, 1.0)).

=== GPUREG_LIGHT''i''_ATTENUATION_SCALE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-19
| float1.7.12, Distance attenuation scale
|}

These registers contain the distance attenuation scale value of the corresponding light. The attenuation factor is DA(clip(bias + scale*distance, 0.0, 1.0)).

=== GPUREG_LIGHTING_AMBIENT ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Blue
|-
| 10-17
| unsigned, Green
|-
| 20-27
| unsigned, Red
|}

This register contains the initial value of the fragment primary color before the partial colors that correspond to each enabled light are added. Usually set to material_emission + material_ambient*scene_ambient.

=== GPUREG_LIGHTING_NUM_LIGHTS ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-2
| unsigned, Number of active lights - 1
|}

This register configures the number of active lights.

=== GPUREG_LIGHTING_CONFIG0 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Shadow factor enabled (0 = disabled, 1 = enabled) (usually accompanied by bit 16, 17, or 18)
|-
| 2-3
| unsigned, Fresnel selector
|-
| 4-7
| unsigned, Light environment configuration
|-
| 8-11
| 0x4
|-
| 16
| unsigned, Apply shadow attenuation to primary color (0 = don't apply, 1 = apply)
|-
| 17
| unsigned, Apply shadow attenuation to secondary color (0 = don't apply, 1 = apply)
|-
| 18
| unsigned, Invert shadow attenuation (0 = don't invert, 1 = invert)
|-
| 19
| unsigned, Apply shadow attenuation to alpha component (0 = don't apply, 1 = apply)
|-
| 22-23
| unsigned, Bump map texture unit
|-
| 24-25
| unsigned, Shadow map texture unit
|-
| 27
| unsigned, Clamp highlights (0 = disabled, 1 = enabled)
|-
| 28-29
| unsigned, Bump mode
|-
| 30
| unsigned, Recalculate bump vectors (0 = enabled, 1 = disabled) (usually set to 1 when bump mode is not 0)
|-
| 31
| 0x1
|}

This register configures the light environment.

Fresnel selector values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| None
|-
| 1
| Primary alpha
|-
| 2
| Secondary alpha
|-
| 3
| Primary and secondary alpha
|}

The light environment configuration controls which LUTs are available for use. If a LUT is not available in the selected configuration, its value will always read a constant 1.0 regardless of the enable state in GPUREG_LIGHTING_CONFIG1. If RR is enabled but not RG or RB, the output of RR is used for the three components; Red, Green and Blue.

Light environment configuration values:

{| class="wikitable" border="1"
! Value
! Description
! Available LUTs
|-
| 0
| Configuration 0
| D0, RR, SP, DA
|-
| 1
| Configuration 1
| FR, RR, SP, DA
|-
| 2
| Configuration 2
| D0, D1, RR, DA
|-
| 3
| Configuration 3
| D0, D1, FR, DA
|-
| 4
| Configuration 4
| All except for FR
|-
| 5
| Configuration 5
| All except for D1
|-
| 6
| Configuration 6
| All except for RB and RG
|-
| 8
| Configuration 7
| All
|}

Bump mode values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Not used
|-
| 1
| Use as bump map
|-
| 2
| Use as tangent map
|}

=== GPUREG_LIGHTING_CONFIG1 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Fragment light source 0 shadows disabled (0 = enabled, 1 = disabled)
|-
| 1
| unsigned, Fragment light source 1 shadows disabled (0 = enabled, 1 = disabled)
|-
| 2
| unsigned, Fragment light source 2 shadows disabled (0 = enabled, 1 = disabled)
|-
| 3
| unsigned, Fragment light source 3 shadows disabled (0 = enabled, 1 = disabled)
|-
| 4
| unsigned, Fragment light source 4 shadows disabled (0 = enabled, 1 = disabled)
|-
| 5
| unsigned, Fragment light source 5 shadows disabled (0 = enabled, 1 = disabled)
|-
| 6
| unsigned, Fragment light source 6 shadows disabled (0 = enabled, 1 = disabled)
|-
| 7
| unsigned, Fragment light source 7 shadows disabled (0 = enabled, 1 = disabled)
|-
| 8
| unsigned, Fragment light source 0 spot light disabled (0 = enabled, 1 = disabled)
|-
| 9
| unsigned, Fragment light source 1 spot light disabled (0 = enabled, 1 = disabled)
|-
| 10
| unsigned, Fragment light source 2 spot light disabled (0 = enabled, 1 = disabled)
|-
| 11
| unsigned, Fragment light source 3 spot light disabled (0 = enabled, 1 = disabled)
|-
| 12
| unsigned, Fragment light source 4 spot light disabled (0 = enabled, 1 = disabled)
|-
| 13
| unsigned, Fragment light source 5 spot light disabled (0 = enabled, 1 = disabled)
|-
| 14
| unsigned, Fragment light source 6 spot light disabled (0 = enabled, 1 = disabled)
|-
| 15
| unsigned, Fragment light source 7 spot light disabled (0 = enabled, 1 = disabled)
|-
| 16
| unsigned, Term 0 distribution component D0 LUT disabled (0 = enabled, 1 = disabled)
|-
| 17
| unsigned, Term 1 distribution component D1 LUT disabled (0 = enabled, 1 = disabled)
|-
| 18
| 0x1
|-
| 19
| unsigned, Fresnel FR LUT disabled (0 = enabled, 1 = disabled)
|-
| 20
| unsigned, Term 1 reflection component RB LUT disabled (0 = enabled, 1 = disabled)
|-
| 21
| unsigned, Term 1 reflection component RG LUT disabled (0 = enabled, 1 = disabled)
|-
| 22
| unsigned, Term 1 reflection component RR LUT disabled (0 = enabled, 1 = disabled)
|-
| 24
| unsigned, Fragment light source 0 distance attenuation disabled (0 = enabled, 1 = disabled)
|-
| 25
| unsigned, Fragment light source 1 distance attenuation disabled (0 = enabled, 1 = disabled)
|-
| 26
| unsigned, Fragment light source 2 distance attenuation disabled (0 = enabled, 1 = disabled)
|-
| 27
| unsigned, Fragment light source 3 distance attenuation disabled (0 = enabled, 1 = disabled)
|-
| 28
| unsigned, Fragment light source 4 distance attenuation disabled (0 = enabled, 1 = disabled)
|-
| 29
| unsigned, Fragment light source 5 distance attenuation disabled (0 = enabled, 1 = disabled)
|-
| 30
| unsigned, Fragment light source 6 distance attenuation disabled (0 = enabled, 1 = disabled)
|-
| 31
| unsigned, Fragment light source 7 distance attenuation disabled (0 = enabled, 1 = disabled)
|}

This register is used to disable various aspects of the light environment.

=== GPUREG_LIGHTING_LUT_INDEX ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Starting index
|-
| 8-12
| unsigned, Look-up table
|}

This register controls which LUT and what offset into it the GPUREG_LIGHTING_LUT_DATA''i'' register writes to.

Lookup table values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| D0
|-
| 1
| D1
|-
| 3
| FR
|-
| 4
| RB
|-
| 5
| RG
|-
| 6
| RR
|-
| 8-15
| SP0-7
|-
| 16-23
| DA0-7
|}

=== GPUREG_LIGHTING_ENABLE1 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Disabled (0 = enabled, 1 = disabled)
|}

This register is set to 1 when fragment lighting is disabled, and to 0 when it is enabled.

=== GPUREG_LIGHTING_LUT_DATA''i'' ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-23
| LUT data
|}

Lighting LUT data is written here.

A LUT contains data for the input domain [-1.0, 1.0], which is indexed using a signed 8-bit number [-128, 127]. Therefore a LUT contains 256 entries. The index of a value is (int)(x/127.0f) & 0xFF.

DA: The input domain is [0.0, 1.0], and the index is an unsigned 8-bit number [0, 255] instead.

Format of an entry:

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-11
| fixed0.0.12, Entry value
|-
| 12-23
| fixed1.0.11, Absolute value of the difference between the next entry and this entry, used to implement linear interpolation
|}

=== GPUREG_LIGHTING_LUTINPUT_ABS ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 1
| unsigned, abs() flag for the input of D0 (0 = enabled, 1 = disabled)
|-
| 5
| unsigned, abs() flag for the input of D1 (0 = enabled, 1 = disabled)
|-
| 9
| unsigned, abs() flag for the input of SP (0 = enabled, 1 = disabled)
|-
| 13
| unsigned, abs() flag for the input of FR (0 = enabled, 1 = disabled)
|-
| 17
| unsigned, abs() flag for the input of RB (0 = enabled, 1 = disabled)
|-
| 21
| unsigned, abs() flag for the input of RG (0 = enabled, 1 = disabled)
|-
| 25
| unsigned, abs() flag for the input of RR (0 = enabled, 1 = disabled)
|}

This register controls whether the absolute value of the input is taken before using a LUT.

=== GPUREG_LIGHTING_LUTINPUT_SELECT ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-2
| unsigned, Input selector for D0
|-
| 4-6
| unsigned, Input selector for D1
|-
| 8-10
| unsigned, Input selector for SP
|-
| 12-14
| unsigned, Input selector for FR
|-
| 16-18
| unsigned, Input selector for RB
|-
| 20-22
| unsigned, Input selector for RG
|-
| 24-26
| unsigned, Input selector for RR
|}

This register selects the input from LUTs.

Input selector values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| N·H
|-
| 1
| V·H
|-
| 2
| N·V
|-
| 3
| L·N
|-
| 4
| -L·P (aka Spotlight aka SP)
|-
| 5
| cos φ (aka CP)
|}

=== GPUREG_LIGHTING_LUTINPUT_SCALE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-2
| unsigned, Scaler selector for D0
|-
| 4-6
| unsigned, Scaler selector for D1
|-
| 8-10
| unsigned, Scaler selector for SP
|-
| 12-14
| unsigned, Scaler selector for FR
|-
| 16-18
| unsigned, Scaler selector for RB
|-
| 20-22
| unsigned, Scaler selector for RG
|-
| 24-26
| unsigned, Scaler selector for RR
|}

This register controls the scaling that is applied to the output of a LUT.

Scaler selector values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| 1x
|-
| 1
| 2x
|-
| 2
| 4x
|-
| 3
| 8x
|-
| 6
| 0.25x
|-
| 7
| 0.5x
|}

=== GPUREG_LIGHTING_LIGHT_PERMUTATION ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-2
| unsigned, ID of the 1st enabled light
|-
| 4-6
| unsigned, ID of the 2nd enabled light
|-
| 8-10
| unsigned, ID of the 3rd enabled light
|-
| 12-14
| unsigned, ID of the 4th enabled light
|-
| 16-18
| unsigned, ID of the 5th enabled light
|-
| 20-22
| unsigned, ID of the 6th enabled light
|-
| 24-26
| unsigned, ID of the 7th enabled light
|-
| 28-30
| unsigned, ID of the 8th enabled light
|}

This register sets the IDs of enabled light sources.

== Geometry pipeline registers ==

=== GPUREG_ATTRIBBUFFERS_LOC ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 1-28
| unsigned, Vertex arrays base address
|}

This register sets the base address of all vertex arrays.

=== GPUREG_ATTRIBBUFFERS_FORMAT_LOW ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| unsigned, Vertex attribute 0 type
|-
| 2-3
| unsigned, Vertex attribute 0 size
|-
| 4-5
| unsigned, Vertex attribute 1 type
|-
| 6-7
| unsigned, Vertex attribute 1 size
|-
| 8-9
| unsigned, Vertex attribute 2 type
|-
| 10-11
| unsigned, Vertex attribute 2 size
|-
| 12-13
| unsigned, Vertex attribute 3 type
|-
| 14-15
| unsigned, Vertex attribute 3 size
|-
| 16-17
| unsigned, Vertex attribute 4 type
|-
| 18-19
| unsigned, Vertex attribute 4 size
|-
| 20-21
| unsigned, Vertex attribute 5 type
|-
| 22-23
| unsigned, Vertex attribute 5 size
|-
| 24-25
| unsigned, Vertex attribute 6 type
|-
| 26-27
| unsigned, Vertex attribute 6 size
|-
| 28-29
| unsigned, Vertex attribute 7 type
|-
| 30-31
| unsigned, Vertex attribute 7 size
|}

This register configures the types and sizes of the first 8 vertex attributes.

Vertex attribute type values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Byte
|-
| 1
| Unsigned byte
|-
| 2
| Short
|-
| 3
| Float
|}

Vertex attribute size values:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| 8 bits
|-
| 1
| 16 bits
|-
| 2
| 24 bits
|-
| 3
| 32 bits
|}

=== GPUREG_ATTRIBBUFFERS_FORMAT_HIGH ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| unsigned, Vertex attribute 8 type
|-
| 2-3
| unsigned, Vertex attribute 8 size
|-
| 4-5
| unsigned, Vertex attribute 9 type
|-
| 6-7
| unsigned, Vertex attribute 9 size
|-
| 8-9
| unsigned, Vertex attribute 10 type
|-
| 10-11
| unsigned, Vertex attribute 10 size
|-
| 12-13
| unsigned, Vertex attribute 11 type
|-
| 14-15
| unsigned, Vertex attribute 11 size
|-
| 16-27
| unsigned, Fixed vertex attribute mask
|-
| 28-31
| unsigned, Total vertex attribute count - 1
|}

This register configures the types and sizes of the last 4 vertex attributes, along with the attribute mask and the total attribute count.

See GPUREG_ATTRIBBUFFERS_FORMAT_LOW for vertex attribute type and size values.

=== GPUREG_ATTRIBBUFFER''i''_OFFSET ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-27
| unsigned, Offset from base vertex arrays address
|}

This register configures the offset of a vertex array from the base vertex arrays address.

=== GPUREG_ATTRIBBUFFER''i''_CONFIG1 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, Component 1
|-
| 4-7
| unsigned, Component 2
|-
| 8-11
| unsigned, Component 3
|-
| 12-15
| unsigned, Component 4
|-
| 16-19
| unsigned, Component 5
|-
| 20-23
| unsigned, Component 6
|-
| 24-27
| unsigned, Component 7
|-
| 28-31
| unsigned, Component 8
|}

This register configures the first 8 component types of a vertex array.

Component values:

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

=== GPUREG_ATTRIBBUFFER''i''_CONFIG2 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, Component 9
|-
| 4-7
| unsigned, Component 10
|-
| 8-11
| unsigned, Component 11
|-
| 12-15
| unsigned, Component 12
|-
| 16-23
| unsigned, Bytes per vertex
|-
| 28-31
| unsigned, Total number of components
|}

This register configures the last 4 component types of a vertex array, along with the bytes per vertex and the total number of components.

See GPUREG_ATTRIBBUFFER''i''_CONFIG1 for component values.

=== GPUREG_INDEXBUFFER_CONFIG ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-27
| unsigned, Offset from base vertex arrays address
|-
| 31
| Index type (0 = unsigned byte, 1 = unsigned short or drawing arrays)
|}

This register configures the index array used when drawing elements.

=== GPUREG_NUMVERTICES ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| unsigned, Number of vertices to render
|}

This register sets the number of vertices to render.

=== GPUREG_GEOSTAGE_CONFIG ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| unsigned, Geometry shader in use (0 = not in use, 2 = in use)
|-
| 8
| unsigned, Drawing triangle elements (0 = not, 1 = drawing triangle elements)
|-
| 9
| 0x0
|-
| 31
| unsigned, Use reserved geometry shader subdivision (0 = don't use, 1 = use)
|}

This register configures the geometry stage of the GPU pipeline.

When using vertex buffers and drawing elements in triangles mode, bit 8 is set to 1, else it is set to 0.

=== GPUREG_VERTEX_OFFSET ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| unsigned, Starting vertex offset
|}

This register sets the offset of the first vertex in an array to render.

=== GPUREG_POST_VERTEX_CACHE_NUM ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Number of entries in the post-vertex cache (usually 0x4 or 0x84)
|}

This register configures the post-vertex cache.

=== GPUREG_DRAWARRAYS ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| unsigned, Trigger (0 = idle, non-zero = draw arrays)
|}

This register triggers drawing vertex arrays.

=== GPUREG_DRAWELEMENTS ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| unsigned, Trigger (0 = idle, non-zero = draw elements)
|}

This register triggers drawing vertex array elements.

=== GPUREG_VTX_FUNC ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| unsigned, Trigger (0 = idle, non-zero = clear post-vertex cache)
|}

This register triggers clearing the post-vertex cache.

=== GPUREG_FIXEDATTRIB_INDEX ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, Fixed attribute index (0-11, 0xF = immediate-mode submission)
|}

This register selects the index of the fixed attribute to be input with GPUREG_FIXEDATTRIB_DATA''i''. See [[GPU/Fixed Vertex Attributes]] and [[GPU/Immediate-Mode Vertex Submission]] for usage info.

=== GPUREG_FIXEDATTRIB_DATA''i'' ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| colspan="2" | '''DATA0:'''
|-
| 0-7
| float1.7.16, Vertex attribute element 3 (Z) (bits 16-23)
|-
| 8-31
| float1.7.16, Vertex attribute element 4 (W)
|-
| colspan="2" | '''DATA1:'''
|-
| 0-15
| float1.7.16, Vertex attribute element 2 (Y) (bits 8-23)
|-
| 16-31
| float1.7.16, Vertex attribute element 3 (Z) (bits 0-15)
|-
| colspan="2" | '''DATA2:'''
|-
| 0-23
| float1.7.16, Vertex attribute element 1 (X)
|-
| 24-31
| float1.7.16, Vertex attribute element 2 (Y) (bits 0-7)
|}

Accepts four 24-bit floating-point values that make up a vertex attribute. Stored in the fixed attribute currently specified with GPUREG_FIXEDATTRIB_INDEX. If immediate-mode vertex submission is enabled (by writing 0xF to the index register) then vertex data is input here directly.

=== GPUREG_CMDBUF_SIZE0 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-20
| unsigned, Size of command buffer 0 >> 3
|}

This register sets the size of the first command buffer.

=== GPUREG_CMDBUF_SIZE1 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-20
| unsigned, Size of command buffer 1 >> 3
|}

This register sets the size of the second command buffer.

=== GPUREG_CMDBUF_ADDR0 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-28
| unsigned, Physical address of command buffer 0 >> 3
|}

This register sets the physical address of the first command buffer.

=== GPUREG_CMDBUF_ADDR1 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-28
| unsigned, Physical address of command buffer 1 >> 3
|}

This register sets the physical address of the second command buffer.

=== GPUREG_CMDBUF_JUMP0 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| unsigned, Trigger (0 = idle, non-zero = execute command buffer 0)
|}

This register triggers a jump to the first command buffer.

=== GPUREG_CMDBUF_JUMP1 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| unsigned, Trigger (0 = idle, non-zero = execute command buffer 1)
|}

This register triggers a jump to the second command buffer.

=== GPUREG_VSH_NUM_ATTR ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, Number of vertex shader input attributes - 1
|}

This register sets the number of vertex shader input attributes.

=== GPUREG_VSH_COM_MODE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Geometry shader configuration enabled (0 = disabled, 1 = enabled)
|}

This register sets whether to use the geometry shader configuration or reuse the vertex shader configuration for the geometry shader shading unit.
When disabled and the geometry unit is not in use, as configured by GPUREG_GEOSTAGE_CONFIG, uniforms, outmap mask, program code and swizzle data are propagated to the geometry shader unit.

=== GPUREG_START_DRAW_FUNC0 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Mode (0 = drawing, 1 = configuration)
|-
| 1-7
| 0x0
|}

This register is related to drawing. When the mode value is set to 1, rendering is not performed properly. When set to 0, changes to the vertex shader configuration registers are not applied correctly. Because of this, it is usually initialized to 1, set to 0 immediately before triggering a draw, and set back to 1 immediately after triggering a draw.

=== GPUREG_VSH_OUTMAP_TOTAL1 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, Number of vertex shader output map registers - 1
|}

This register sets the number of vertex shader output map registers.

=== GPUREG_VSH_OUTMAP_TOTAL2 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, Number of vertex shader output map registers - 1
|}

This register sets the number of vertex shader output map registers.

=== GPUREG_GSH_MISC0 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| unsigned, Misc data (0x00000001 = Reserved geometry shader subdivision in use, 0x01004302 = Particle system in use, 0 otherwise)
|}

This register configures miscellaneous geometry shader properties.

=== GPUREG_GEOSTAGE_CONFIG2 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Function indicator (with vertex buffers: 0 = draw elements, 1 = draw arrays, without: 0 = not inputting, 1 = inputting vertex attribute data)
|-
| 8
| unsigned, Drawing triangle elements (0 = not, 1 = drawing triangle elements)
|}

This register configures the geometry stage of the GPU pipeline.

When using vertex buffers, bit 0 is set to 1 before drawing arrays, and cleared to 0 immediately after. When using immediate mode to directly input vertex attribute data, bit 0 is set to 1 before inputting vertex attribute data, and cleared to 0 immediately after. While bit 0 is set to 1, some register writes outside of the 0x200-0x254 and 0x280-0x2DF ranges may be processed incorrectly.

When using vertex buffers and drawing elements in triangles mode, bit 8 is set to 1, else it is set to 0.

=== GPUREG_GSH_MISC1 ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-4
| unsigned, Reserved geometry shader subdivision type (2 = Loop, 3 = Catmull-Clark)
|}

This register configures the type of reserved geometry shader subdivision in use. The value is ignored when a subdivision is not in use.

=== GPUREG_PRIMITIVE_CONFIG ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, Number of vertex shader output map registers - 1
|-
| 8-9
| unsigned, Primitive mode
|}

This register configures primitive drawing.

Primitive mode value:

{| class="wikitable" border="1"
! Value
! Description
|-
| 0
| Triangles
|-
| 1
| Triangle strip
|-
| 2
| Triangle fan
|-
| 3
| Geometry primitive
|}

=== GPUREG_RESTART_PRIMITIVE ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Trigger (0 = idle, 1 = reset primitive)
|-
| 1-31
| 0x0
|}

This register triggers resetting primitive drawing.

== Shader registers ==

=== GPUREG_''SH''_BOOLUNIFORM ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Boolean register b0 value (0 = false, 1 = true)
|-
| 1
| unsigned, Boolean register b1 value (0 = false, 1 = true)
|-
| 2
| unsigned, Boolean register b2 value (0 = false, 1 = true)
|-
| 3
| unsigned, Boolean register b3 value (0 = false, 1 = true)
|-
| 4
| unsigned, Boolean register b4 value (0 = false, 1 = true)
|-
| 5
| unsigned, Boolean register b5 value (0 = false, 1 = true)
|-
| 6
| unsigned, Boolean register b6 value (0 = false, 1 = true)
|-
| 7
| unsigned, Boolean register b7 value (0 = false, 1 = true)
|-
| 8
| unsigned, Boolean register b8 value (0 = false, 1 = true)
|-
| 9
| unsigned, Boolean register b9 value (0 = false, 1 = true)
|-
| 10
| unsigned, Boolean register b10 value (0 = false, 1 = true)
|-
| 11
| unsigned, Boolean register b11 value (0 = false, 1 = true)
|-
| 12
| unsigned, Boolean register b12 value (0 = false, 1 = true)
|-
| 13
| unsigned, Boolean register b13 value (0 = false, 1 = true)
|-
| 14
| unsigned, Boolean register b14 value (0 = false, 1 = true)
|-
| 15
| unsigned, Boolean register b15 value (0 = false, 1 = true)
|-
| 16-31
| 0x7FFF
|}

This register is used to set a shader unit's boolean registers.

=== GPUREG_''SH''_INTUNIFORM_I''i'' ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Integer register i''i'' X value
|-
| 8-15
| unsigned, Integer register i''i'' Y value
|-
| 16-23
| unsigned, Integer register i''i'' Z value
|-
| 24-31
| unsigned, Integer register i''i'' W value
|}

These registers are used to set a shader unit's integer registers.

=== GPUREG_''SH''_INPUTBUFFER_CONFIG ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, Input vertex attributes - 1
|-
| 8-15
| unsigned, Use reserved geometry shader subdivision (0 = don't use, 1 = use) (always 0 for vertex shaders)
|-
| 16-23
| 0x0
|-
| 24-31
| unsigned, Use geometry shader (0x8 = use, 0xA0 = don't use) (always 0xA0 for vertex shaders)
|}

This register is used to configure a shader unit's input buffer.

=== GPUREG_''SH''_ENTRYPOINT ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-15
| unsigned, Code entry point offset, in 32-bit words
|-
| 16-31
| 0x7FFF
|}

This register sets a shader unit's code entry point.

For geometry shaders, this sets the entry point for the single shader unit which can be dedicated to running geometry shaders, regardless of the current geometry stage mode. This is means that while this register is normally used to set the geometry shader entry point, it can also be used to set this single shader unit to run from a different entry point than the other three, even when running a vertex shader.

For vertex shaders, this sets the entry point for the shader units set to vertex shader mode. Depending on the current geometry stage mode this can include either all 4 shader units or just 3 of them.

=== GPUREG_''SH''_ATTRIBUTES_PERMUTATION_LOW ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, Vertex attribute 0 input register index
|-
| 4-7
| unsigned, Vertex attribute 1 input register index
|-
| 8-11
| unsigned, Vertex attribute 2 input register index
|-
| 12-15
| unsigned, Vertex attribute 3 input register index
|-
| 16-19
| unsigned, Vertex attribute 4 input register index
|-
| 20-23
| unsigned, Vertex attribute 5 input register index
|-
| 24-27
| unsigned, Vertex attribute 6 input register index
|-
| 28-31
| unsigned, Vertex attribute 7 input register index
|}

This register sets the shader unit input register index which will correspond to each attribute contained by the input buffer (which in the case of geometry shaders is the vertex shader output buffer) for the first 8 attributes. For example, having bits 0-3 set to 5 means that, in the shader program, v5 will contain the input buffer's 1st attribute.

=== GPUREG_''SH''_ATTRIBUTES_PERMUTATION_HIGH ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| unsigned, Vertex attribute 8 input register index
|-
| 4-7
| unsigned, Vertex attribute 9 input register index
|-
| 8-11
| unsigned, Vertex attribute 10 input register index
|-
| 12-15
| unsigned, Vertex attribute 11 input register index
|-
| 16-19
| unsigned, Vertex attribute 12 input register index
|-
| 20-23
| unsigned, Vertex attribute 13 input register index
|-
| 24-27
| unsigned, Vertex attribute 14 input register index
|-
| 28-31
| unsigned, Vertex attribute 15 input register index
|}

This register sets the shader unit input register index which will correspond to each attribute contained by the input buffer (which in the case of geometry shaders is the vertex shader output buffer) for attributes 8 through 15. For example, having bits 0-3 set to 5 means that, in the shader program, v5 will contain the input buffer's 9th attribute.

=== GPUREG_''SH''_OUTMAP_MASK ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| unsigned, Output register o0 enabled (0 = disabled, 1 = enabled)
|-
| 1
| unsigned, Output register o1 enabled (0 = disabled, 1 = enabled)
|-
| 2
| unsigned, Output register o2 enabled (0 = disabled, 1 = enabled)
|-
| 3
| unsigned, Output register o3 enabled (0 = disabled, 1 = enabled)
|-
| 4
| unsigned, Output register o4 enabled (0 = disabled, 1 = enabled)
|-
| 5
| unsigned, Output register o5 enabled (0 = disabled, 1 = enabled)
|-
| 6
| unsigned, Output register o6 enabled (0 = disabled, 1 = enabled)
|-
| 7
| unsigned, Output register o7 enabled (0 = disabled, 1 = enabled) (vertex shader only)
|-
| 8
| unsigned, Output register o8 enabled (0 = disabled, 1 = enabled) (vertex shader only)
|-
| 9
| unsigned, Output register o9 enabled (0 = disabled, 1 = enabled) (vertex shader only)
|-
| 10
| unsigned, Output register o10 enabled (0 = disabled, 1 = enabled) (vertex shader only)
|-
| 11
| unsigned, Output register o11 enabled (0 = disabled, 1 = enabled) (vertex shader only)
|-
| 12
| unsigned, Output register o12 enabled (0 = disabled, 1 = enabled) (vertex shader only)
|-
| 13
| unsigned, Output register o13 enabled (0 = disabled, 1 = enabled) (vertex shader only)
|-
| 14
| unsigned, Output register o14 enabled (0 = disabled, 1 = enabled) (vertex shader only)
|-
| 15
| unsigned, Output register o15 enabled (0 = disabled, 1 = enabled) (vertex shader only)
|-
| 16-31
| 0x0
|}

This register toggles a shader unit's output registers.

=== GPUREG_''SH''_CODETRANSFER_END ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| unsigned, Signal transfer end (0 = idle, non-zero = signal)
|}

This register's value should be set to 1 in order to finalize the transfer of shader code.

=== GPUREG_''SH''_FLOATUNIFORM_INDEX ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| unsigned, Target floating-point register index (range 0-95, where 0 = c0 and 95 = c95)
|-
| 31
| unsigned, Transfer mode (0 = float1.7.16, 1 = float1.8.23)
|}

This register sets the shader unit's target floating-point register and transfer mode for the data transfer system. As such it is typically used right before [[#GPUREG_SH_FLOATUNIFORM_DATAi|GPUREG_''SH''_FLOATUNIFORM_DATA''i'']], though writing to one register does not make writing to the other mandatory.

=== GPUREG_''SH''_FLOATUNIFORM_DATA''i'' ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| Floating-point register component data
|}

This register is used to set the components of a shader unit's floating-point registers, each having 4 components. The data format which should be written to it depends on the transfer mode set with [[#GPUREG_SH_FLOATUNIFORM_INDEX|GPUREG_''SH''_FLOATUNIFORM_INDEX]]. This register functions as a FIFO queue: after each time a 4-component uniform register is successfully set, the target register index is incremented, meaning that groups of uniforms with contiguous register IDs can be set with only one initial write to [[#GPUREG_SH_FLOATUNIFORM_INDEX|GPUREG_''SH''_FLOATUNIFORM_INDEX]].

* In the case of float24 transfer mode, data should be sent by writing three words which are the concatenation of the float24 value of the uniform register's 4 components, in the reverse order. Assuming each letter corresponds to 4 bits, the format becomes:
** first word : ZZWWWWWW
** second word : YYYYZZZZ
** third word : XXXXXXYY
* In the case of float32 transfer mode, data should be sent by writing four words which are each the float32 value of the uniform register's 4 components, in the reverse order.

=== GPUREG_''SH''_CODETRANSFER_INDEX ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-11
| unsigned, Target shader code offset
|}

This register is used to set the offset at which upcoming shader code data transferred through [[#GPUREG_SH_CODETRANSFER_DATAi|GPUREG_''SH''_CODETRANSFER_DATA''i'']] should be written.

=== GPUREG_''SH''_CODETRANSFER_DATA''i'' ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| unsigned, Shader instruction data
|}

This register is used to transfer shader code data. This register behaves as a FIFO queue: each write to this register writes the provided value to the GPU shader code memory bank at the offset initially set by [[#GPUREG_SH_CODETRANSFER_INDEX|GPUREG_''SH''_CODETRANSFER_INDEX]]. The offset in question is incremented after each write to this register.

=== GPUREG_''SH''_OPDESCS_INDEX ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-11
| unsigned, Target shader operand descriptor offset
|}

This register is used to set the offset at which upcoming shader operand descriptor data transferred through [[#GPUREG_SH_OPDESCS_DATAi|GPUREG_''SH''_OPDESCS_DATA''i'']] should be written.

=== GPUREG_''SH''_OPDESCS_DATA''i'' ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| unsigned, Shader operand descriptor data
|}

This register is used to transfer shader operand descriptor data. This register behaves as a FIFO queue: each write to this register writes the provided value to the GPU shader operand descriptor memory bank at the offset initially set by [[#GPUREG_SH_OPDESCS_INDEX|GPUREG_''SH''_OPDESCS_INDEX]]. The offset in question is incremented after each write to this register.

FS:GetNumSeeds

2024-11-27T09:46:37Z

PabloMK7: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x087D0000] |} =Response= {| class="wikitable" border="1" |- ! Index Word !..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x087D0000]
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2
| Number of seeds
|}

=Description=
Gets the amount of seeds from the seed DB.

Filesystem services

2024-11-27T09:45:31Z

PabloMK7:

= Services =
{{Anchor|FS}}{{Anchor|FSUSER}}{{Anchor|fs:USER}}
== Filesystem service "fs:USER" ==
You can at most have 32 FS archive handles.

{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! scope="col" width="400" | Required [[NCCH/Extended_Header|exheader]] access info bitmask
|-
| 0x000100C6
|?
| [[FS:Dummy1|Dummy1]]
| None
|-
| 0x040100C4
|?
| [[FS:Control|Control]]
| None
|-
| 0x08010002
|?
| [[FS:Initialize|Initialize]]
| None
|-
| 0x080201C2
|?
| [[FS:OpenFile|OpenFile]]
| None
|-
| 0x08030204
|?
| [[FS:OpenFileDirectly|OpenFileDirectly]]
| None
|-
| 0x08040142
|?
| [[FS:DeleteFile|DeleteFile]]
| None
|-
| 0x08050244
|?
| [[FS:RenameFile|RenameFile]]
| None
|-
| 0x08060142
|?
| [[FS:DeleteDirectory|DeleteDirectory]]
| None
|-
| 0x08070142
|?
| [[FS:DeleteDirectoryRecursively|DeleteDirectoryRecursively]]
| None
|-
| 0x08080202
|?
| [[FS:CreateFile|CreateFile]]
| None
|-
| 0x08090182
|?
| [[FS:CreateDirectory|CreateDirectory]]
| None
|-
| 0x080A0244
|?
| [[FS:RenameDirectory|RenameDirectory]]
| None
|-
| 0x080B0102
|?
| [[FS:OpenDirectory|OpenDirectory]]
| None
|-
| 0x080C00C2
|?
| [[FS:OpenArchive|OpenArchive]]
| Each archive ID code has separate access info bitmasks, if it has any
|-
| 0x080D0144
|?
| [[FS:ControlArchive|ControlArchive]]
| None
|-
| 0x080E0080
|?
| [[FS:CloseArchive|CloseArchive]]
| None
|-
| 0x080F0180
|?
| [[FS:Obsoleted_2_0_FormatThisUserSaveData|Obsoleted_2_0_FormatThisUserSaveData]]
| None
|-
| 0x08100200
|?
| [[FS:Obsoleted_3_0_CreateSystemSaveData|Obsoleted_3_0_CreateSystemSaveData]]
| 0x4, for when the input saveID doesn't match the exheader saveID
|-
| 0x08110040
|?
| [[FS:Obsoleted_3_0_DeleteSystemSaveData|Obsoleted_3_0_DeleteSystemSaveData]]
| 0x1004, for when the input saveID doesn't match the exheader saveID
|-
| 0x08120080
|?
| [[FS:GetFreeBytes|GetFreeBytes]]
| None
|-
| 0x08130000
|?
| [[FS:GetCardType|GetCardType]]
| 0x1017
|-
| 0x08140000
|?
| [[FS:GetSdmcArchiveResource|GetSdmcArchiveResource]]
| None
|-
| 0x08150000
|?
| [[FS:GetNandArchiveResource|GetNandArchiveResource]]
| 0x1007
|-
| 0x08160000
|?
| [[FS:GetSdmcFatfsError|GetSdmcFatfsError]]
| 0x2
|-
| 0x08170000
|?
| [[FS:IsSdmcDetected|IsSdmcDetected]]
| None
|-
| 0x08180000
|?
| [[FS:IsSdmcWritable|IsSdmcWritable]]
| None
|-
| 0x08190042
|?
| [[FS:GetSdmcCid|GetSdmcCid]]
| 0x2
|-
| 0x081A0042
|?
| [[FS:GetNandCid|GetNandCid]]
| 0x2
|-
| 0x081B0000
|?
| [[FS:GetSdmcSpeedInfo|GetSdmcSpeedInfo]]
| 0x2
|-
| 0x081C0000
|?
| [[FS:GetNandSpeedInfo|GetNandSpeedInfo]]
| 0x2
|-
| 0x081D0042
|?
| [[FS:GetSdmcLog|GetSdmcLog]]
| 0x2
|-
| 0x081E0042
|?
| [[FS:GetNandLog|GetNandLog]]
| 0x2
|-
| 0x081F0000
|?
| [[FS:ClearSdmcLog|ClearSdmcLog]]
| 0x2
|-
| 0x08200000
|?
| [[FS:ClearNandLog|ClearNandLog]]
| 0x2
|-
| 0x08210000
|?
| [[FS:CardSlotIsInserted|CardSlotIsInserted]]
| 0x1017
|-
| 0x08220000
|?
| [[FS:CardSlotPowerOn|CardSlotPowerOn]]
| 0x2
|-
| 0x08230000
|?
| [[FS:CardSlotPowerOff|CardSlotPowerOff]]
| 0x2
|-
| 0x08240000
|?
| [[FS:CardSlotGetCardIFPowerStatus|CardSlotGetCardIFPowerStatus]]
| 0x2
|-
| 0x08250040
|?
| [[FS:CardNorDirectCommand|CardNorDirectCommand]]
| 0x2
|-
| 0x08260080
|?
| [[FS:CardNorDirectCommandWithAddress|CardNorDirectCommandWithAddress]]
| 0x2
|-
| 0x08270082
|?
| [[FS:CardNorDirectRead|CardNorDirectRead]]
| 0x2
|-
| 0x082800C2
|?
| [[FS:CardNorDirectReadWithAddress|CardNorDirectReadWithAddress]]
| 0x2
|-
| 0x08290082
|?
| [[FS:CardNorDirectWrite|CardNorDirectWrite]]
| 0x2
|-
| 0x082A00C2
|?
| [[FS:CardNorDirectWriteWithAddress|CardNorDirectWriteWithAddress]]
| 0x2
|-
| 0x082B00C2
|?
| [[FS:CardNorDirectRead_4xIO|CardNorDirectRead_4xIO]]
| 0x2
|-
| 0x082C0082
|?
| [[FS:CardNorDirectCpuWriteWithoutVerify|CardNorDirectCpuWriteWithoutVerify]]
| 0x2
|-
| 0x082D0040
|?
| [[FS:CardNorDirectSectorEraseWithoutVerify|CardNorDirectSectorEraseWithoutVerify]]
| 0x2
|-
| 0x082E0040
|?
| [[FS:GetProductInfo|GetProductInfo]]
| 0x1005
|-
| 0x082F0040
|?
| [[FS:GetProgramLaunchInfo|GetProgramLaunchInfo]]
| 0x1005
|-
| 0x08300182
|?
| [[FS:Obsoleted_3_0_CreateExtSaveData|Obsoleted_3_0_CreateExtSaveData]]
| 0xC, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08310180
|?
| [[FS:Obsoleted_3_0_CreateSharedExtSaveData|Obsoleted_3_0_CreateSharedExtSaveData]]
| 0x1005
|-
| 0x08320102
|?
| [[FS:Obsoleted_3_0_ReadExtSaveDataIcon|Obsoleted_3_0_ReadExtSaveDataIcon]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08330082
|?
| [[FS:Obsoleted_3_0_EnumerateExtSaveData|Obsoleted_3_0_EnumerateExtSaveData]]
| 0x1005
|-
| 0x08340082
|?
| [[FS:Obsoleted_3_0_EnumerateSharedExtSaveData|Obsoleted_3_0_EnumerateSharedExtSaveData]]
| 0x1005
|-
| 0x08350080
|?
| [[FS:Obsoleted_3_0_DeleteExtSaveData|Obsoleted_3_0_DeleteExtSaveData]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08360080
|?
| [[FS:Obsoleted_3_0_DeleteSharedExtSaveData|Obsoleted_3_0_DeleteSharedExtSaveData]]
| 0x1005
|-
| 0x08370040
|?
| [[FS:SetCardSpiBaudRate|SetCardSpiBaudRate]]
| 0x2
|-
| 0x08380040
|?
| [[FS:SetCardSpiBusMode|SetCardSpiBusMode]]
| 0x2
|-
| 0x08390000
|?
| [[FS:SendInitializeInfoTo9|SendInitializeInfoTo9]]
| None
|-
| 0x083A0100
|?
| [[FS:GetSpecialContentIndex|GetSpecialContentIndex]]
| 0x1005
|-
| 0x083B00C2
|?
| [[FS:GetLegacyRomHeader|GetLegacyRomHeader]]
| 0x1015
|-
| 0x083C00C2
|?
| [[FS:GetLegacyBannerData|GetLegacyBannerData]]
| 0x1015
|-
| 0x083D0100
|?
| [[FS:CheckAuthorityToAccessExtSaveData|CheckAuthorityToAccessExtSaveData]]
| 0x44
|-
| 0x083E00C2
|?
| [[FS:QueryTotalQuotaSize|QueryTotalQuotaSize]]
| None
|-
| 0x083F00C0
|?
| [[FS:Obsoleted_3_0_GetExtDataBlockSize|Obsoleted_3_0_GetExtDataBlockSize]]
| None
|-
| 0x08400040
|?
| [[FS:AbnegateAccessRight|AbnegateAccessRight]]
|?
|-
| 0x08410000
|?
| [[FS:DeleteSdmcRoot|DeleteSdmcRoot]]
| 0x1005
|-
| 0x08420040
|?
| [[FS:DeleteAllExtSaveDataOnNand|DeleteAllExtSaveDataOnNand]]
| 0x1005
|-
| 0x08430000
|?
| [[FS:InitializeCtrFileSystem|InitializeCtrFileSystem]]
| None
|-
| 0x08440000
|?
| [[FS:CreateSeed|CreateSeed]]
| 0x2
|-
| 0x084500C2
|?
| [[FS:GetFormatInfo|GetFormatInfo]]
|?
|-
| 0x08460102
|?
| [[FS:GetLegacyRomHeader2|GetLegacyRomHeader2]]
| 0x1015
|-
| 0x08470180
|?
| [[FS:Obsoleted_2_0_FormatCtrCardUserSaveData|Obsoleted_2_0_FormatCtrCardUserSaveData]]
| 0x6
|-
| 0x08480042
|?
| [[FS:GetSdmcCtrRootPath|GetSdmcCtrRootPath]]
| 0x100D
|-
| 0x08490040
|?
| [[FS:GetArchiveResource|GetArchiveResource]]
|?
|-
| 0x084A0002
|?
| [[FS:ExportIntegrityVerificationSeed|ExportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084B0002
|?
| [[FS:ImportIntegrityVerificationSeed|ImportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084C0242
|?
| [[FS:FormatSaveData|FormatSaveData]]
| 0x6, in some cases this write isn't needed however
|-
| 0x084D0102
|?
| [[FS:GetLegacySubBannerData|GetLegacySubBannerData]]
| 0x1015
|-
| 0x084E0342
|?
| [[FS:UpdateSha256Context|UpdateSha256Context]]
| 0x5
|-
| 0x084F0102
|?
| [[FS:ReadSpecialFile|ReadSpecialFile]]
| None
|-
| 0x08500040
|?
| [[FS:GetSpecialFileSize|GetSpecialFileSize]]
| None
|-
| 0x08510242
| [[3.0.0-5]]
| [[FS:CreateExtSaveData|CreateExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0xC
|-
| 0x08520100
| [[3.0.0-5]]
| [[FS:DeleteExtSaveData|DeleteExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0x10100D
|-
| 0x08530142
| [[3.0.0-5]]
| [[FS:ReadExtSaveDataIcon|ReadExtSaveDataIcon]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x085400C0
| [[3.0.0-5]]
| [[FS:GetExtDataBlockSize|GetExtDataBlockSize]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x08550102
| [[3.0.0-5]]
| [[FS:EnumerateExtSaveData|EnumerateExtSaveData]]
| 0x101005
|-
| 0x08560240
| [[3.0.0-5]]
| [[FS:CreateSystemSaveData|CreateSystemSaveData]]
| 0x4 (this doesn't apply in certain cases, however)
|-
| 0x08570080
| [[3.0.0-5]]
| [[FS:DeleteSystemSaveData|DeleteSystemSaveData]]
| 0x1004 (this doesn't apply in certain cases, however)
|-
| 0x08580000
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsSource|StartDeviceMoveAsSource]]
| 0x2004
|-
| 0x08590200
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsDestination|StartDeviceMoveAsDestination]]
| 0x2004
|-
| 0x085A00C0
| [[3.0.0-5]]
| [[FS:SetArchivePriority|SetArchivePriority]]
| None
|-
| 0x085B0080
| [[3.0.0-5]]
| [[FS:GetArchivePriority|GetArchivePriority]]
| None
|-
| 0x085C00C0
| [[3.0.0-5]]
| [[FS:SetCtrCardLatencyParameter|SetCtrCardLatencyParameter]]
| 0xE
|-
| 0x085D01C0
| [[3.0.0-5]]
| [[FS:SetFsCompatibilityInfo|SetFsCompatibilityInfo]]
| 0x100001
|-
| 0x085E0040
| [[3.0.0-5]]
| [[FS:ResetCardCompatibilityParameter|ResetCardCompatibilityParameter]]
| 0xE
|-
| 0x085F0040
| [[3.0.0-5]]
| [[FS:SwitchCleanupInvalidSaveData|SwitchCleanupInvalidSaveData]]
| 0x12004
|-
| 0x08600042
| [[3.0.0-5]]
| [[FS:EnumerateSystemSaveData|EnumerateSystemSaveData]]
| 0x2004
|-
| 0x08610042
| [[3.0.0-5]]
| [[FS:InitializeWithSdkVersion|InitializeWithSdkVersion]]
| None
|-
| 0x08620040
| [[3.0.0-5]]
| [[FS:SetPriority|SetPriority]]
| None
|-
| 0x08630000
| [[3.0.0-5]]
| [[FS:GetPriority|GetPriority]]
| None
|-
| 0x08640000
| [[3.0.0-5]]
| [[FS:Obsoleted_4_0_GetNandInfo|Obsoleted_4_0_GetNandInfo]]
| Stubbed, this returns an error
|-
| 0x08650140
| [[4.0.0-7]]
| [[FS:SetSaveDataSecureValue|SetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086600C0
| [[4.0.0-7]]
| [[FS:GetSaveDataSecureValue|GetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086700C4
| [[4.0.0-7]]
| [[FS:ControlSecureSave|ControlSecureSave]]
| 0x121004
|-
| 0x08680000
| [[4.0.0-7]]
| [[FS:GetMediaType|GetMediaType]]
| None
|-
| 0x08690000
| [[4.0.0-7]]
| [[FS:Obsoleted_4_0_GetNandEraseCount|Obsoleted_4_0_GetNandEraseCount]]
| Stubbed, this returns an error.
|-
| 0x086A0082
| [[4.0.0-7]]
| [[FS:ReadNandReport|ReadNandReport]]
| None
|-
| 0x086B00C2
|?
|SetOtherSaveDataSecureValue
| 00121004
|-
| 0x086C00C2
|?
|GetOtherSaveDataSecureValue
| 00121004
|-
| 0x086D0040
|?
|?
| 00020004
|-
| 0x086E00C0
|Related to Secure Value? Used in Pokemon Sun/Moon.
|SetThisSaveDataSecureValue
|None?
|-
| 0x086F0040
|Related to Secure Value? Used in Pokemon Sun/Moon.
|GetThisSaveDataSecureValue
| 0xE
|-
| 0x087000C2
|?
|?
|None?
|-
| 0x08710100
|?
|?
| 0xC
|-
| 0x087201C0
|?
|?
| 00080004
|-
| 0x087300C0
|?
|?
| 00080004
|-
| 0x08740000
|?
|?
| 00080004
|-
| 0x08750140
|?
|?
|None?
|-
| 0x087600C0
|?
|?
|None?
|-
| 0x08770100
|?
|?
|?
|-
| 0x087800C0
|?
|?
|?
|-
| 0x087900C2
| ?
| Same as GetLegacyBannerData, except for the last parameter this passes u8 value 0x1 instead of 0x0, for the FSPXI command.
| 0x00101015
|-
| 0x087A0180
| [[9.6.0-24|9.6.0-X]]
| [[FS:AddSeed|AddSeed]]
| 0x00200000
|-
| 0x087B0080
| [[9.6.0-24|9.6.0-X]]
| [[FS:GetSeed|GetSeed]]
| 0x00200000
|-
| 0x087C0080
| [[9.6.0-24|9.6.0-X]]
| [[FS:DeleteSeed|DeleteSeed]]
| 0x00200000
|-
| 0x087D0000
| [[9.6.0-24|9.6.0-X]]
| [[FS:GetNumSeeds|GetNumSeeds]]
| 0x00200000
|-
| 0x087E0042
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>. Writes a list of titleIDs to the outbuf, this is for titles with content-lock-seed(s) stored in SEEDDB. (u32 total_titleids_probably, ((Size<<4) <nowiki>|</nowiki> 12), outbufptr)
| 0x00200000
|-
| 0x087F....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x0880....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x8810080
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0882....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x08830000
| [[9.6.0-24|9.6.0-X]]
| Writes an output value to cmdreply[2].
| 0x00200000
|-
| 0x08840042
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0885....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x088600C0
| [[11.1.0-34|11.1.0-X]]
| [[FS:CheckUpdatedDat|CheckUpdatedDat]]
| 0x00080000
|}

Note: The question marks from Dummy1 to GetSpecialFileSize on the "available since system version" field are mainly there because I think that most of these are necessary for the main system to function, so theoretically that would mean that since the creation of the 3DS these were available, or since launch if that makes more sense. But because of the peculiar nature of some of the functions, they will remain question marks until they can be confirmed 100%.

When access rights are required for a command, at least one of the bits in the process access info specified in the above table for the command must be set. Error 0xD9004676 is returned when a process attempts to use a command which it doesn't have access rights for the command. The exheader access info field is all zero's for most applications. Note that the permissions listed in the above table is for system-version v2.x, therefore permission bit(s) added with newer FIRM may be missing from this.

Each session for fs:USER has separate permissions, initially these are set to all zero's for new fs:USER sessions. The permissions/etc for fs:USER sessions are initialized via [[FS:Initialize]](loaded from the user process exheader).

{{Anchor|FSLDR}}{{Anchor|fs:LDR}}
== Filesystem service "fs:LDR" ==
This service is identical to fs:USER, except [[FS:OpenArchive]] archive 0x2345678E can only be accessed with fs:LDR.

{{Anchor|FSReg}}{{Anchor|FSREG}}{{Anchor|fs:REG}}
== ProgramRegistry service "fs:REG" ==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| [[FSReg:Dummy1|Dummy1]]
|-
| 0x040103C0
| [[FSReg:Register|Register]]
|-
| 0x04020040
| [[FSReg:Unregister|Unregister]]
|-
| 0x040300C0
| [[FSReg:GetProgramInfo|GetProgramInfo]]
|-
| 0x04040100
| [[FSReg:LoadProgram|LoadProgram]]
|-
| 0x04050080
| [[FSReg:UnloadProgram|UnloadProgram]]
|-
| 0x04060080
| [[FSReg:CheckHostLoadId|CheckHostLoadId]]
|}

Only two sessions can be opened for this service at a time, hence no other processes can use this due to [[Process_Manager_Services|pm-module]] and [[Loader_Services|loader]] using this.

=File and directory access=
==Files==
File session handles obtained via [[FS:OpenFile]] and [[FS:OpenFileDirectly]] can be used to access files through a service-like interface, despite not being an actual service registered using [[SRV:RegisterService]]. To use this service-like interface, simply call the SendSyncRequest SVC with a file session handle, using the IPC buffer in thread-local storage for parameters and responses, just like you would with a proper service.

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| [[FSFile:Dummy1|Dummy1]]
|-
| 0x040100C4
| [[FSFile:Control|Control]]
|-
| 0x08010100
| [[FSFile:OpenSubFile|OpenSubFile]]
|-
| 0x080200C2
| [[FSFile:Read|Read]]
|-
| 0x08030102
| [[FSFile:Write|Write]]
|-
| 0x08040000
| [[FSFile:GetSize|GetSize]]
|-
| 0x08050080
| [[FSFile:SetSize|SetSize]]
|-
| 0x08060000
| [[FSFile:GetAttributes|GetAttributes]]
|-
| 0x08070040
| [[FSFile:SetAttributes|SetAttributes]]
|-
| 0x08080000
| [[FSFile:Close|Close]]
|-
| 0x08090000
| [[FSFile:Flush|Flush]]
|-
| 0x080A0040
| [[FSFile:SetPriority|SetPriority]]
|-
| 0x080B0000
| [[FSFile:GetPriority|GetPriority]]
|-
| 0x080C0000
| [[FSFile:OpenLinkFile|OpenLinkFile]]
|-
| 0x0C010100
| [[FSFile:GetAvailable|GetAvailable]]
|}

==Directories==
Directory session handles obtained via [[FS:OpenDirectory]] are usable via a service-like interface, following the exact same procedure described above for file sessions.
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x000100C6
| [[1.0.0-0]]
| [[FSDir:Dummy1|Dummy1]]
|-
| 0x040100C4
| [[1.0.0-0]]
| [[FSDir:Control|Control]]
|-
| 0x08010042
| [[1.0.0-0]]
| [[FSDir:Read|Read]]
|-
| 0x08020000
| [[1.0.0-0]]
| [[FSDir:Close|Close]]
|-
| 0x08030040
| ?
| [[FSDir:SetPriority|SetPriority]]
|-
| 0x08040000
| ?
| [[FSDir:GetPriority|GetPriority]]
|}

= Archives =
{| class="wikitable" border="1"
|-
! ArchiveId
! Description
! Accessible via [[Filesystem_services|FS]]
! Accessible via [[Filesystem_services_PXI|FSPXI]]
! Only accessible by Process9 internally
! Requires binary [[FS:OpenFile|Lowpath]]
! Required exheader FS access info bitmask
|-
| 0x00000003
| SelfNCCH (including [[#RomFS|RomFS]])
| Yes
| No
| No
| No
| None
|-
| 0x00000004
| SaveData (the saveID/mediatype for this is loaded from data originally from the user process' exheader)
| Yes
| No
| No
| No
| None
|-
| 0x00000006
| ExtSaveData
| Yes
| No
| No
| Yes
| 0x100D, when the input extdataID isn't listed in the exheader.
|-
| 0x00000007
| Shared ExtSaveData
| Yes
| No
| No
| Yes
| None
|-
| 0x00000008
| SystemSaveData
| Yes
| No
| No
| Yes
| 0x4, when the input saveID doesn't match the exheader system-saveID.
|-
| 0x00000009
| SDMC
| Yes
| Yes
| No
| No
| 0x8E
|-
| 0x0000000A
| SDMC Write-Only
| Yes
| No
| No
| No
| 0x808E
|-
| 0x12345678
| ExtSaveData for BOSS
| Yes
| No
| No
| Yes
| 0x44
|-
| 0x12345679
| CARD SPI FS
| Yes
| Yes
| No
| No
| 0x16
|-
| 0x1234567B
| ExtSaveData, and ExtSaveData for BOSS
| No
| Yes
| No
| Yes
|
|-
| 0x1234567C
| SystemSaveData
| No
| Yes
| No
| Yes
|
|-
| 0x1234567D
| NAND RW
| Yes
| Yes
| No
| No
| 0x800
|-
| 0x1234567E
| NAND RO
| Yes
| Yes
| No
| No
| 0x200
|-
| 0x1234567F
| NAND RO Write FS
| No
| Yes
| No
| No
| ?
|-
| 0x12345680
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x12345681
| Unknown. Accessed by FS service.
| ?
| ?
| No
| ?
| ?
|-
| 0x12345682
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x2345678A
| Used for accessing general NCCH data. With FSPXI this also allows savedata access.
| Yes
| Yes
| No
| Yes
| 0x1005
|-
| 0x2345678B
| ?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678C
| Used internally to access [[Title_Database|/dbs]] files?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678D
| ?
| No
| No
| Yes
| No
|
|-
| 0x2345678E
| FSPXI: Similar to archive 0x2345678A. For fs:LDR(used by the "loader" FIRM ARM11-process), only ExeFS. Not accessible with fs:USER.
| Yes
| Yes
| No
| Yes
| None, see description.
|-
| 0x567890AB
| NAND CTR FS
| No
| Yes
| No
| No
| ?
|-
| 0x567890AC
| TWL PHOTO
| Yes
| Yes
| No
| No
| ?
|-
| 0x567890AD
| TWLS (DSi Sound stores recordings here). This is mapped to the FAT12 image stored in the file at [[Twln/shared2/0000]].
| No
| Yes
| No
| No
| ?
|-
| 0x567890AE
| NAND TWL FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890AF
| NAND W FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890B0
| ?
| No
| Yes
| No
| No
|
|-
| 0x567890B1
| Gamecard SaveData (for check). This is a wrapper for UserSaveDataForCheck: the OpenArchive code for that is called with archive-lowpath TID=0/mediatype=2(gamecard).
| Yes
| No
| No
| No
| 0x6
|-
| 0x567890B2
| UserSaveData (for check). This is the same as the regular SaveData archive, except with this the savedata ID and mediatype is loaded from the input archive lowpath.
| Yes
| No
| No
| Yes
| 0x6
|-
| 0x567890B4
| Similar to 0x567890B2 but can only access Accessible Save specified in [[NCCH/Extended_Header#Storage_Info|exheader]]?
| Yes
| No
| No
| Yes
| ?
|}

Archives listed as not requiring a binary lowpath, use lowpath type [[FS:OpenFile|empty]].

The above permission bitmasks are from v2.x, see the above Services section for how these are handled.

Archives CTR NAND, NAND RO Write FS, TWL NAND, NAND W FS, and CARD SPI FS require the corresponding process exheader access control mount flag to be set, in the exheader for any of the currently running ARM11 processes, for [[Filesystem_services_PXI|FSPXI]]. The access rights checked by [[Filesystem services|FS]] module for archive mounting with fs:USER, are stored in the process' exheader accessinfo.

The CARDSPI archive allows access to the gamecard CARD1 raw savedata flash(aka "cardspi:/" in [[FIRM|Process9]]), the file lowpath must be WCHAR "/". The "NAND W FS" archive allows access to the raw NAND image(aka "wnand:/" in Process9), the file lowpath must be WCHAR "/".

= Filenames and Paths =
{{Anchor|PathType}} PathType:
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| -1
| Returned internally by Process9, when errors occur it seems(in particular when no nul-terminator was found in the input path). The data ptr is set to NULL.
|-
| 0x0
| INVALID - Specifies an invalid path
|-
| 0x1
| EMPTY - Specifies an empty path
|-
| 0x2
| BINARY - Non-text based path. Meaning is per-archive
|-
| 0x3
| ASCII - Text-based path with 7-bit ASCII characters padded to 8-bits each (signed char)
|-
| 0x4
| UTF16 - Text-based path with UTF-16 characters
|}

In IPC requests, sizes of ASCII and UTF16 paths must include space for the null-terminator.

== Binary LowPath ==
The format of the data that a binary LowPath points to is custom per archive.

=== SelfNCCH File Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Type:
* 0x0: RomFS
* 0x1: error 0xD9004676
* 0x2: ExeFS
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module crashes on this
* 0x5: Update RomFS?
|-
| 1-2
| File name for ExeFS ("icon"/"banner"/"logo"). ".code" is not allowed
|}

Note that ExeFS files only support reading from offset=0 and with size=file_size.

=== SystemSaveData Archive Path Data Format ===
==== FS ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be zero for NAND)
|-
| 1
| saveid
|}
The file/directory lowpath is a text lowpath in the [[Savegames|savegame]] filesystem.

==== FSPXI ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| u8 [[Mediatypes|Mediatype]] (must be zero for NAND)
|}
The file lowpath is a binary lowpath containing the u64 saveid, however the high word of the saveid is always zero. The mounted file is the cleartext savegame image. Up to 32 SystemSaveData image files can be opened under a single mounted FSPXI archive.

=== UserSaveDataForCheck Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be non-zero)
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
The file/directory lowpath for this FS archive is a text path in the [[Savegames|savegame]] filesystem.

=== 0x567890B4 Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| <code><nowiki>Lower_word_saveid >> 8</nowiki></code> ?
|-
| 2
| Unknown. Game calculate this using formula <code><nowiki>0xFFFFFF00 | unknown_b</nowiki></code>
|}

=== ExtSaveData Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
For FS, the file/directory lowpath is a text path in the [[extdata]] filesystem. For FSPXI, the file lowpath is a text path relative to the "/extdata/<ExtdataIDHigh>/<ExtdataIDLow>" directory on SD/NAND, for the cleartext extdata image to mount.

=== 0x2345678A Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Lower word programID
|-
| 1
| Upper word programID
|-
| 2
| ([[Mediatypes|Mediatype]] & 0xFF) | (uninitialized_data? & 0xFFFFFF00)
|-
| 3
| Number of something? Hardcoded per-archive, 0 for ExeFS, 200 for area:, 100 for rate:, 40 for eula:, etc.
|}

File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| 0 for NCCH data, 1 for savedata. The latter is only valid for FSPXI. Value 2 is allowed via archive 0x3, it's unknown what this is.
|-
| 1
| TMD content index / NCSD partition index.
|-
| 2
| Type: 0=romfs(0 for non-NCCH as well), 1=exefs ".code"(?), 2=exefs "icon"/"banner"/"logo", 3=unknown, 4=unknown, 5=unknown.
|-
| 3-4
| Filename for ExeFS.
|}

The 0x14-byte lowpath is all-zero for accessing the title's main RomFS.

=== [[RomFS]] ===

Archives 0x3 and 0x2345678E both allow for accessing the [[RomFS#Level_3_Format|level-3 IVFC images]] for RomFS access. The main CXI RomFS is accessible via an all-zero 0xc-byte binary file-lowpath. The update RomFS can be accessed with the first u32 in the binary file-lowpath being set to 0x5. The user must handle parsing the filesystem used in the exposed image itself.

With FSPXI the returned data for RomFS is the entire RomFS section from the NCCH, starting at the IVFC header.

The 0x3 archive is an interface for the 0x2345678E archive with the current process programID+mediatype. The file lowpath is 3-words. These words are written to 0x2345678E-archive file_lowpath+0, with the rest of that lowpath set to all-zero(lowpath is different from archive 0x2345678A). File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| See above. The only values which FS-module doesn't allow to be used here are:
* 0x1: Error 0xE0E046BE.
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module executes svcBreak when using this.
|-
| 1-2
| See above. Not validated by FS-module.
|}

=SEEDDB=
With [[9.6.0-24|9.6.0-X]] new [[System_SaveData]] with saveID 0001000F was added, this seems to be handled by FS-module itself, probably via the new service-cmds added to fsuser. [[Home Menu]] and [[NIM_Services|NIM]] module have access to those commands.

The SEEDDB savedata contains the title-unique seed-data used for the new [[NCCH]] keyY generation added with FIRM [[9.6.0-24|9.6.0-X]].

= Common Types =
== MediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| NAND
|-
| 1
| SD
|-
| 2
| Game Card
|}

== SystemMediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| CTR NAND
|-
| 1
| TWL NAND
|-
| 2
| SD
|-
| 3
| TWL Photo
|}

== OpenFlags ==
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0
| Read
|-
| 1
| Write
|-
| 2
| Create
|}

== Attributes ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Is Directory
|-
| 0x1
| 0x1
| Is Hidden
|-
| 0x2
| 0x1
| Is Archive
|-
| 0x3
| 0x1
| Is Read-Only
|}

== WriteOption ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Flush
|-
| 0x1
| 0x1
| Update Time Stamp
|-
| 0x2
| 0x1
| Reserved
|-
| 0x3
| 0x1
| Reserved
|}

== DirectoryEntry ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x20C
| UTF-16 Entry Name
|-
| 0x20C
| 0xA
| 8.3 short filename name
|-
| 0x216
| 0x4
| 8.3 short filename extension
|-
| 0x21A
| 0x1
| Always 1
|-
| 0x21B
| 0x1
| Reserved
|-
| 0x21C
| 0x4
| [[Filesystem_services#Attributes|Attributes]]
|-
| 0x220
| 0x8
| Entry Size
|}

== ArchiveResource ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Sector byte-size
|-
| 0x4
| 0x4
| Cluster byte-size
|-
| 0x8
| 0x4
| Partition capacity in clusters
|-
| 0xC
| 0x4
| Available free space in clusters
|}

== ProgramInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| Program ID
|-
| 0x8
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x9
| 0x7
| Padding
|}

== ProductInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Product Code
|-
| 0x10
| 0x2
| Company Code
|-
| 0x12
| 0x2
| Remaster Version
|}

== IntegrityVerificationSeed ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| AES-CBC MAC over a SHA256 hash, which hashes the first 0x110-bytes of the cleartext SEED.
|-
| 0x10
| 0x120
| The [[nand/private/movable.sed]], encrypted with AES-CBC using the above MAC for the counter.
|}

== ExtSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x8
| Save ID
|-
| 0xC
| 0x4
| Reserved
|}

== SystemSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x4
| Save ID
|}

== SecureValueSlot ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1000
| SD Application
|}

== CardSpiBaudRate ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 512KHz
|-
| 0x1
| 1MHz
|-
| 0x2
| 2MHz
|-
| 0x3
| 4MHz
|-
| 0x4
| 8MHz
|-
| 0x5
| 16MHz
|}

== CardSpiBusMode ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 1-bit
|-
| 0x1
| 4-bit
|}

== SpecialContentType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1
| Update
|-
| 0x2
| Manual
|-
| 0x3
| DLP Child
|}

== DeviceMoveContext ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| IVs
|-
| 0x10
| 0x10
| Encrypt Parameter
|}

=Errors=
See [[Filesystem_services_PXI]].

[[Category:Services]]

FS:DeleteSeed

2024-11-27T09:44:32Z

PabloMK7: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x087C0080] |- | 1-2 | u64, Title ID |} =Response= {| class="wikitable" border..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x087C0080]
|-
| 1-2
| u64, Title ID
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
Deletes the seed from the seed DB for the specified title. If the seed does not exist, it returns 0xC8804464

Filesystem services

2024-11-27T09:43:31Z

PabloMK7:

= Services =
{{Anchor|FS}}{{Anchor|FSUSER}}{{Anchor|fs:USER}}
== Filesystem service "fs:USER" ==
You can at most have 32 FS archive handles.

{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! scope="col" width="400" | Required [[NCCH/Extended_Header|exheader]] access info bitmask
|-
| 0x000100C6
|?
| [[FS:Dummy1|Dummy1]]
| None
|-
| 0x040100C4
|?
| [[FS:Control|Control]]
| None
|-
| 0x08010002
|?
| [[FS:Initialize|Initialize]]
| None
|-
| 0x080201C2
|?
| [[FS:OpenFile|OpenFile]]
| None
|-
| 0x08030204
|?
| [[FS:OpenFileDirectly|OpenFileDirectly]]
| None
|-
| 0x08040142
|?
| [[FS:DeleteFile|DeleteFile]]
| None
|-
| 0x08050244
|?
| [[FS:RenameFile|RenameFile]]
| None
|-
| 0x08060142
|?
| [[FS:DeleteDirectory|DeleteDirectory]]
| None
|-
| 0x08070142
|?
| [[FS:DeleteDirectoryRecursively|DeleteDirectoryRecursively]]
| None
|-
| 0x08080202
|?
| [[FS:CreateFile|CreateFile]]
| None
|-
| 0x08090182
|?
| [[FS:CreateDirectory|CreateDirectory]]
| None
|-
| 0x080A0244
|?
| [[FS:RenameDirectory|RenameDirectory]]
| None
|-
| 0x080B0102
|?
| [[FS:OpenDirectory|OpenDirectory]]
| None
|-
| 0x080C00C2
|?
| [[FS:OpenArchive|OpenArchive]]
| Each archive ID code has separate access info bitmasks, if it has any
|-
| 0x080D0144
|?
| [[FS:ControlArchive|ControlArchive]]
| None
|-
| 0x080E0080
|?
| [[FS:CloseArchive|CloseArchive]]
| None
|-
| 0x080F0180
|?
| [[FS:Obsoleted_2_0_FormatThisUserSaveData|Obsoleted_2_0_FormatThisUserSaveData]]
| None
|-
| 0x08100200
|?
| [[FS:Obsoleted_3_0_CreateSystemSaveData|Obsoleted_3_0_CreateSystemSaveData]]
| 0x4, for when the input saveID doesn't match the exheader saveID
|-
| 0x08110040
|?
| [[FS:Obsoleted_3_0_DeleteSystemSaveData|Obsoleted_3_0_DeleteSystemSaveData]]
| 0x1004, for when the input saveID doesn't match the exheader saveID
|-
| 0x08120080
|?
| [[FS:GetFreeBytes|GetFreeBytes]]
| None
|-
| 0x08130000
|?
| [[FS:GetCardType|GetCardType]]
| 0x1017
|-
| 0x08140000
|?
| [[FS:GetSdmcArchiveResource|GetSdmcArchiveResource]]
| None
|-
| 0x08150000
|?
| [[FS:GetNandArchiveResource|GetNandArchiveResource]]
| 0x1007
|-
| 0x08160000
|?
| [[FS:GetSdmcFatfsError|GetSdmcFatfsError]]
| 0x2
|-
| 0x08170000
|?
| [[FS:IsSdmcDetected|IsSdmcDetected]]
| None
|-
| 0x08180000
|?
| [[FS:IsSdmcWritable|IsSdmcWritable]]
| None
|-
| 0x08190042
|?
| [[FS:GetSdmcCid|GetSdmcCid]]
| 0x2
|-
| 0x081A0042
|?
| [[FS:GetNandCid|GetNandCid]]
| 0x2
|-
| 0x081B0000
|?
| [[FS:GetSdmcSpeedInfo|GetSdmcSpeedInfo]]
| 0x2
|-
| 0x081C0000
|?
| [[FS:GetNandSpeedInfo|GetNandSpeedInfo]]
| 0x2
|-
| 0x081D0042
|?
| [[FS:GetSdmcLog|GetSdmcLog]]
| 0x2
|-
| 0x081E0042
|?
| [[FS:GetNandLog|GetNandLog]]
| 0x2
|-
| 0x081F0000
|?
| [[FS:ClearSdmcLog|ClearSdmcLog]]
| 0x2
|-
| 0x08200000
|?
| [[FS:ClearNandLog|ClearNandLog]]
| 0x2
|-
| 0x08210000
|?
| [[FS:CardSlotIsInserted|CardSlotIsInserted]]
| 0x1017
|-
| 0x08220000
|?
| [[FS:CardSlotPowerOn|CardSlotPowerOn]]
| 0x2
|-
| 0x08230000
|?
| [[FS:CardSlotPowerOff|CardSlotPowerOff]]
| 0x2
|-
| 0x08240000
|?
| [[FS:CardSlotGetCardIFPowerStatus|CardSlotGetCardIFPowerStatus]]
| 0x2
|-
| 0x08250040
|?
| [[FS:CardNorDirectCommand|CardNorDirectCommand]]
| 0x2
|-
| 0x08260080
|?
| [[FS:CardNorDirectCommandWithAddress|CardNorDirectCommandWithAddress]]
| 0x2
|-
| 0x08270082
|?
| [[FS:CardNorDirectRead|CardNorDirectRead]]
| 0x2
|-
| 0x082800C2
|?
| [[FS:CardNorDirectReadWithAddress|CardNorDirectReadWithAddress]]
| 0x2
|-
| 0x08290082
|?
| [[FS:CardNorDirectWrite|CardNorDirectWrite]]
| 0x2
|-
| 0x082A00C2
|?
| [[FS:CardNorDirectWriteWithAddress|CardNorDirectWriteWithAddress]]
| 0x2
|-
| 0x082B00C2
|?
| [[FS:CardNorDirectRead_4xIO|CardNorDirectRead_4xIO]]
| 0x2
|-
| 0x082C0082
|?
| [[FS:CardNorDirectCpuWriteWithoutVerify|CardNorDirectCpuWriteWithoutVerify]]
| 0x2
|-
| 0x082D0040
|?
| [[FS:CardNorDirectSectorEraseWithoutVerify|CardNorDirectSectorEraseWithoutVerify]]
| 0x2
|-
| 0x082E0040
|?
| [[FS:GetProductInfo|GetProductInfo]]
| 0x1005
|-
| 0x082F0040
|?
| [[FS:GetProgramLaunchInfo|GetProgramLaunchInfo]]
| 0x1005
|-
| 0x08300182
|?
| [[FS:Obsoleted_3_0_CreateExtSaveData|Obsoleted_3_0_CreateExtSaveData]]
| 0xC, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08310180
|?
| [[FS:Obsoleted_3_0_CreateSharedExtSaveData|Obsoleted_3_0_CreateSharedExtSaveData]]
| 0x1005
|-
| 0x08320102
|?
| [[FS:Obsoleted_3_0_ReadExtSaveDataIcon|Obsoleted_3_0_ReadExtSaveDataIcon]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08330082
|?
| [[FS:Obsoleted_3_0_EnumerateExtSaveData|Obsoleted_3_0_EnumerateExtSaveData]]
| 0x1005
|-
| 0x08340082
|?
| [[FS:Obsoleted_3_0_EnumerateSharedExtSaveData|Obsoleted_3_0_EnumerateSharedExtSaveData]]
| 0x1005
|-
| 0x08350080
|?
| [[FS:Obsoleted_3_0_DeleteExtSaveData|Obsoleted_3_0_DeleteExtSaveData]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08360080
|?
| [[FS:Obsoleted_3_0_DeleteSharedExtSaveData|Obsoleted_3_0_DeleteSharedExtSaveData]]
| 0x1005
|-
| 0x08370040
|?
| [[FS:SetCardSpiBaudRate|SetCardSpiBaudRate]]
| 0x2
|-
| 0x08380040
|?
| [[FS:SetCardSpiBusMode|SetCardSpiBusMode]]
| 0x2
|-
| 0x08390000
|?
| [[FS:SendInitializeInfoTo9|SendInitializeInfoTo9]]
| None
|-
| 0x083A0100
|?
| [[FS:GetSpecialContentIndex|GetSpecialContentIndex]]
| 0x1005
|-
| 0x083B00C2
|?
| [[FS:GetLegacyRomHeader|GetLegacyRomHeader]]
| 0x1015
|-
| 0x083C00C2
|?
| [[FS:GetLegacyBannerData|GetLegacyBannerData]]
| 0x1015
|-
| 0x083D0100
|?
| [[FS:CheckAuthorityToAccessExtSaveData|CheckAuthorityToAccessExtSaveData]]
| 0x44
|-
| 0x083E00C2
|?
| [[FS:QueryTotalQuotaSize|QueryTotalQuotaSize]]
| None
|-
| 0x083F00C0
|?
| [[FS:Obsoleted_3_0_GetExtDataBlockSize|Obsoleted_3_0_GetExtDataBlockSize]]
| None
|-
| 0x08400040
|?
| [[FS:AbnegateAccessRight|AbnegateAccessRight]]
|?
|-
| 0x08410000
|?
| [[FS:DeleteSdmcRoot|DeleteSdmcRoot]]
| 0x1005
|-
| 0x08420040
|?
| [[FS:DeleteAllExtSaveDataOnNand|DeleteAllExtSaveDataOnNand]]
| 0x1005
|-
| 0x08430000
|?
| [[FS:InitializeCtrFileSystem|InitializeCtrFileSystem]]
| None
|-
| 0x08440000
|?
| [[FS:CreateSeed|CreateSeed]]
| 0x2
|-
| 0x084500C2
|?
| [[FS:GetFormatInfo|GetFormatInfo]]
|?
|-
| 0x08460102
|?
| [[FS:GetLegacyRomHeader2|GetLegacyRomHeader2]]
| 0x1015
|-
| 0x08470180
|?
| [[FS:Obsoleted_2_0_FormatCtrCardUserSaveData|Obsoleted_2_0_FormatCtrCardUserSaveData]]
| 0x6
|-
| 0x08480042
|?
| [[FS:GetSdmcCtrRootPath|GetSdmcCtrRootPath]]
| 0x100D
|-
| 0x08490040
|?
| [[FS:GetArchiveResource|GetArchiveResource]]
|?
|-
| 0x084A0002
|?
| [[FS:ExportIntegrityVerificationSeed|ExportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084B0002
|?
| [[FS:ImportIntegrityVerificationSeed|ImportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084C0242
|?
| [[FS:FormatSaveData|FormatSaveData]]
| 0x6, in some cases this write isn't needed however
|-
| 0x084D0102
|?
| [[FS:GetLegacySubBannerData|GetLegacySubBannerData]]
| 0x1015
|-
| 0x084E0342
|?
| [[FS:UpdateSha256Context|UpdateSha256Context]]
| 0x5
|-
| 0x084F0102
|?
| [[FS:ReadSpecialFile|ReadSpecialFile]]
| None
|-
| 0x08500040
|?
| [[FS:GetSpecialFileSize|GetSpecialFileSize]]
| None
|-
| 0x08510242
| [[3.0.0-5]]
| [[FS:CreateExtSaveData|CreateExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0xC
|-
| 0x08520100
| [[3.0.0-5]]
| [[FS:DeleteExtSaveData|DeleteExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0x10100D
|-
| 0x08530142
| [[3.0.0-5]]
| [[FS:ReadExtSaveDataIcon|ReadExtSaveDataIcon]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x085400C0
| [[3.0.0-5]]
| [[FS:GetExtDataBlockSize|GetExtDataBlockSize]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x08550102
| [[3.0.0-5]]
| [[FS:EnumerateExtSaveData|EnumerateExtSaveData]]
| 0x101005
|-
| 0x08560240
| [[3.0.0-5]]
| [[FS:CreateSystemSaveData|CreateSystemSaveData]]
| 0x4 (this doesn't apply in certain cases, however)
|-
| 0x08570080
| [[3.0.0-5]]
| [[FS:DeleteSystemSaveData|DeleteSystemSaveData]]
| 0x1004 (this doesn't apply in certain cases, however)
|-
| 0x08580000
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsSource|StartDeviceMoveAsSource]]
| 0x2004
|-
| 0x08590200
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsDestination|StartDeviceMoveAsDestination]]
| 0x2004
|-
| 0x085A00C0
| [[3.0.0-5]]
| [[FS:SetArchivePriority|SetArchivePriority]]
| None
|-
| 0x085B0080
| [[3.0.0-5]]
| [[FS:GetArchivePriority|GetArchivePriority]]
| None
|-
| 0x085C00C0
| [[3.0.0-5]]
| [[FS:SetCtrCardLatencyParameter|SetCtrCardLatencyParameter]]
| 0xE
|-
| 0x085D01C0
| [[3.0.0-5]]
| [[FS:SetFsCompatibilityInfo|SetFsCompatibilityInfo]]
| 0x100001
|-
| 0x085E0040
| [[3.0.0-5]]
| [[FS:ResetCardCompatibilityParameter|ResetCardCompatibilityParameter]]
| 0xE
|-
| 0x085F0040
| [[3.0.0-5]]
| [[FS:SwitchCleanupInvalidSaveData|SwitchCleanupInvalidSaveData]]
| 0x12004
|-
| 0x08600042
| [[3.0.0-5]]
| [[FS:EnumerateSystemSaveData|EnumerateSystemSaveData]]
| 0x2004
|-
| 0x08610042
| [[3.0.0-5]]
| [[FS:InitializeWithSdkVersion|InitializeWithSdkVersion]]
| None
|-
| 0x08620040
| [[3.0.0-5]]
| [[FS:SetPriority|SetPriority]]
| None
|-
| 0x08630000
| [[3.0.0-5]]
| [[FS:GetPriority|GetPriority]]
| None
|-
| 0x08640000
| [[3.0.0-5]]
| [[FS:Obsoleted_4_0_GetNandInfo|Obsoleted_4_0_GetNandInfo]]
| Stubbed, this returns an error
|-
| 0x08650140
| [[4.0.0-7]]
| [[FS:SetSaveDataSecureValue|SetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086600C0
| [[4.0.0-7]]
| [[FS:GetSaveDataSecureValue|GetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086700C4
| [[4.0.0-7]]
| [[FS:ControlSecureSave|ControlSecureSave]]
| 0x121004
|-
| 0x08680000
| [[4.0.0-7]]
| [[FS:GetMediaType|GetMediaType]]
| None
|-
| 0x08690000
| [[4.0.0-7]]
| [[FS:Obsoleted_4_0_GetNandEraseCount|Obsoleted_4_0_GetNandEraseCount]]
| Stubbed, this returns an error.
|-
| 0x086A0082
| [[4.0.0-7]]
| [[FS:ReadNandReport|ReadNandReport]]
| None
|-
| 0x086B00C2
|?
|SetOtherSaveDataSecureValue
| 00121004
|-
| 0x086C00C2
|?
|GetOtherSaveDataSecureValue
| 00121004
|-
| 0x086D0040
|?
|?
| 00020004
|-
| 0x086E00C0
|Related to Secure Value? Used in Pokemon Sun/Moon.
|SetThisSaveDataSecureValue
|None?
|-
| 0x086F0040
|Related to Secure Value? Used in Pokemon Sun/Moon.
|GetThisSaveDataSecureValue
| 0xE
|-
| 0x087000C2
|?
|?
|None?
|-
| 0x08710100
|?
|?
| 0xC
|-
| 0x087201C0
|?
|?
| 00080004
|-
| 0x087300C0
|?
|?
| 00080004
|-
| 0x08740000
|?
|?
| 00080004
|-
| 0x08750140
|?
|?
|None?
|-
| 0x087600C0
|?
|?
|None?
|-
| 0x08770100
|?
|?
|?
|-
| 0x087800C0
|?
|?
|?
|-
| 0x087900C2
| ?
| Same as GetLegacyBannerData, except for the last parameter this passes u8 value 0x1 instead of 0x0, for the FSPXI command.
| 0x00101015
|-
| 0x087A0180
| [[9.6.0-24|9.6.0-X]]
| [[FS:AddSeed|AddSeed]]
| 0x00200000
|-
| 0x087B0080
| [[9.6.0-24|9.6.0-X]]
| [[FS:GetSeed|GetSeed]]
| 0x00200000
|-
| 0x087C0080
| [[9.6.0-24|9.6.0-X]]
| [[FS:DeleteSeed|DeleteSeed]]
| 0x00200000
|-
| 0x087D0000
| [[9.6.0-24|9.6.0-X]]
| GetNumSeeds. Writes the number of seeds to cmdreply[2]
| 0x00200000
|-
| 0x087E0042
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>. Writes a list of titleIDs to the outbuf, this is for titles with content-lock-seed(s) stored in SEEDDB. (u32 total_titleids_probably, ((Size<<4) <nowiki>|</nowiki> 12), outbufptr)
| 0x00200000
|-
| 0x087F....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x0880....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x8810080
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0882....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x08830000
| [[9.6.0-24|9.6.0-X]]
| Writes an output value to cmdreply[2].
| 0x00200000
|-
| 0x08840042
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0885....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x088600C0
| [[11.1.0-34|11.1.0-X]]
| [[FS:CheckUpdatedDat|CheckUpdatedDat]]
| 0x00080000
|}

Note: The question marks from Dummy1 to GetSpecialFileSize on the "available since system version" field are mainly there because I think that most of these are necessary for the main system to function, so theoretically that would mean that since the creation of the 3DS these were available, or since launch if that makes more sense. But because of the peculiar nature of some of the functions, they will remain question marks until they can be confirmed 100%.

When access rights are required for a command, at least one of the bits in the process access info specified in the above table for the command must be set. Error 0xD9004676 is returned when a process attempts to use a command which it doesn't have access rights for the command. The exheader access info field is all zero's for most applications. Note that the permissions listed in the above table is for system-version v2.x, therefore permission bit(s) added with newer FIRM may be missing from this.

Each session for fs:USER has separate permissions, initially these are set to all zero's for new fs:USER sessions. The permissions/etc for fs:USER sessions are initialized via [[FS:Initialize]](loaded from the user process exheader).

{{Anchor|FSLDR}}{{Anchor|fs:LDR}}
== Filesystem service "fs:LDR" ==
This service is identical to fs:USER, except [[FS:OpenArchive]] archive 0x2345678E can only be accessed with fs:LDR.

{{Anchor|FSReg}}{{Anchor|FSREG}}{{Anchor|fs:REG}}
== ProgramRegistry service "fs:REG" ==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| [[FSReg:Dummy1|Dummy1]]
|-
| 0x040103C0
| [[FSReg:Register|Register]]
|-
| 0x04020040
| [[FSReg:Unregister|Unregister]]
|-
| 0x040300C0
| [[FSReg:GetProgramInfo|GetProgramInfo]]
|-
| 0x04040100
| [[FSReg:LoadProgram|LoadProgram]]
|-
| 0x04050080
| [[FSReg:UnloadProgram|UnloadProgram]]
|-
| 0x04060080
| [[FSReg:CheckHostLoadId|CheckHostLoadId]]
|}

Only two sessions can be opened for this service at a time, hence no other processes can use this due to [[Process_Manager_Services|pm-module]] and [[Loader_Services|loader]] using this.

=File and directory access=
==Files==
File session handles obtained via [[FS:OpenFile]] and [[FS:OpenFileDirectly]] can be used to access files through a service-like interface, despite not being an actual service registered using [[SRV:RegisterService]]. To use this service-like interface, simply call the SendSyncRequest SVC with a file session handle, using the IPC buffer in thread-local storage for parameters and responses, just like you would with a proper service.

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| [[FSFile:Dummy1|Dummy1]]
|-
| 0x040100C4
| [[FSFile:Control|Control]]
|-
| 0x08010100
| [[FSFile:OpenSubFile|OpenSubFile]]
|-
| 0x080200C2
| [[FSFile:Read|Read]]
|-
| 0x08030102
| [[FSFile:Write|Write]]
|-
| 0x08040000
| [[FSFile:GetSize|GetSize]]
|-
| 0x08050080
| [[FSFile:SetSize|SetSize]]
|-
| 0x08060000
| [[FSFile:GetAttributes|GetAttributes]]
|-
| 0x08070040
| [[FSFile:SetAttributes|SetAttributes]]
|-
| 0x08080000
| [[FSFile:Close|Close]]
|-
| 0x08090000
| [[FSFile:Flush|Flush]]
|-
| 0x080A0040
| [[FSFile:SetPriority|SetPriority]]
|-
| 0x080B0000
| [[FSFile:GetPriority|GetPriority]]
|-
| 0x080C0000
| [[FSFile:OpenLinkFile|OpenLinkFile]]
|-
| 0x0C010100
| [[FSFile:GetAvailable|GetAvailable]]
|}

==Directories==
Directory session handles obtained via [[FS:OpenDirectory]] are usable via a service-like interface, following the exact same procedure described above for file sessions.
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x000100C6
| [[1.0.0-0]]
| [[FSDir:Dummy1|Dummy1]]
|-
| 0x040100C4
| [[1.0.0-0]]
| [[FSDir:Control|Control]]
|-
| 0x08010042
| [[1.0.0-0]]
| [[FSDir:Read|Read]]
|-
| 0x08020000
| [[1.0.0-0]]
| [[FSDir:Close|Close]]
|-
| 0x08030040
| ?
| [[FSDir:SetPriority|SetPriority]]
|-
| 0x08040000
| ?
| [[FSDir:GetPriority|GetPriority]]
|}

= Archives =
{| class="wikitable" border="1"
|-
! ArchiveId
! Description
! Accessible via [[Filesystem_services|FS]]
! Accessible via [[Filesystem_services_PXI|FSPXI]]
! Only accessible by Process9 internally
! Requires binary [[FS:OpenFile|Lowpath]]
! Required exheader FS access info bitmask
|-
| 0x00000003
| SelfNCCH (including [[#RomFS|RomFS]])
| Yes
| No
| No
| No
| None
|-
| 0x00000004
| SaveData (the saveID/mediatype for this is loaded from data originally from the user process' exheader)
| Yes
| No
| No
| No
| None
|-
| 0x00000006
| ExtSaveData
| Yes
| No
| No
| Yes
| 0x100D, when the input extdataID isn't listed in the exheader.
|-
| 0x00000007
| Shared ExtSaveData
| Yes
| No
| No
| Yes
| None
|-
| 0x00000008
| SystemSaveData
| Yes
| No
| No
| Yes
| 0x4, when the input saveID doesn't match the exheader system-saveID.
|-
| 0x00000009
| SDMC
| Yes
| Yes
| No
| No
| 0x8E
|-
| 0x0000000A
| SDMC Write-Only
| Yes
| No
| No
| No
| 0x808E
|-
| 0x12345678
| ExtSaveData for BOSS
| Yes
| No
| No
| Yes
| 0x44
|-
| 0x12345679
| CARD SPI FS
| Yes
| Yes
| No
| No
| 0x16
|-
| 0x1234567B
| ExtSaveData, and ExtSaveData for BOSS
| No
| Yes
| No
| Yes
|
|-
| 0x1234567C
| SystemSaveData
| No
| Yes
| No
| Yes
|
|-
| 0x1234567D
| NAND RW
| Yes
| Yes
| No
| No
| 0x800
|-
| 0x1234567E
| NAND RO
| Yes
| Yes
| No
| No
| 0x200
|-
| 0x1234567F
| NAND RO Write FS
| No
| Yes
| No
| No
| ?
|-
| 0x12345680
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x12345681
| Unknown. Accessed by FS service.
| ?
| ?
| No
| ?
| ?
|-
| 0x12345682
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x2345678A
| Used for accessing general NCCH data. With FSPXI this also allows savedata access.
| Yes
| Yes
| No
| Yes
| 0x1005
|-
| 0x2345678B
| ?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678C
| Used internally to access [[Title_Database|/dbs]] files?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678D
| ?
| No
| No
| Yes
| No
|
|-
| 0x2345678E
| FSPXI: Similar to archive 0x2345678A. For fs:LDR(used by the "loader" FIRM ARM11-process), only ExeFS. Not accessible with fs:USER.
| Yes
| Yes
| No
| Yes
| None, see description.
|-
| 0x567890AB
| NAND CTR FS
| No
| Yes
| No
| No
| ?
|-
| 0x567890AC
| TWL PHOTO
| Yes
| Yes
| No
| No
| ?
|-
| 0x567890AD
| TWLS (DSi Sound stores recordings here). This is mapped to the FAT12 image stored in the file at [[Twln/shared2/0000]].
| No
| Yes
| No
| No
| ?
|-
| 0x567890AE
| NAND TWL FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890AF
| NAND W FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890B0
| ?
| No
| Yes
| No
| No
|
|-
| 0x567890B1
| Gamecard SaveData (for check). This is a wrapper for UserSaveDataForCheck: the OpenArchive code for that is called with archive-lowpath TID=0/mediatype=2(gamecard).
| Yes
| No
| No
| No
| 0x6
|-
| 0x567890B2
| UserSaveData (for check). This is the same as the regular SaveData archive, except with this the savedata ID and mediatype is loaded from the input archive lowpath.
| Yes
| No
| No
| Yes
| 0x6
|-
| 0x567890B4
| Similar to 0x567890B2 but can only access Accessible Save specified in [[NCCH/Extended_Header#Storage_Info|exheader]]?
| Yes
| No
| No
| Yes
| ?
|}

Archives listed as not requiring a binary lowpath, use lowpath type [[FS:OpenFile|empty]].

The above permission bitmasks are from v2.x, see the above Services section for how these are handled.

Archives CTR NAND, NAND RO Write FS, TWL NAND, NAND W FS, and CARD SPI FS require the corresponding process exheader access control mount flag to be set, in the exheader for any of the currently running ARM11 processes, for [[Filesystem_services_PXI|FSPXI]]. The access rights checked by [[Filesystem services|FS]] module for archive mounting with fs:USER, are stored in the process' exheader accessinfo.

The CARDSPI archive allows access to the gamecard CARD1 raw savedata flash(aka "cardspi:/" in [[FIRM|Process9]]), the file lowpath must be WCHAR "/". The "NAND W FS" archive allows access to the raw NAND image(aka "wnand:/" in Process9), the file lowpath must be WCHAR "/".

= Filenames and Paths =
{{Anchor|PathType}} PathType:
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| -1
| Returned internally by Process9, when errors occur it seems(in particular when no nul-terminator was found in the input path). The data ptr is set to NULL.
|-
| 0x0
| INVALID - Specifies an invalid path
|-
| 0x1
| EMPTY - Specifies an empty path
|-
| 0x2
| BINARY - Non-text based path. Meaning is per-archive
|-
| 0x3
| ASCII - Text-based path with 7-bit ASCII characters padded to 8-bits each (signed char)
|-
| 0x4
| UTF16 - Text-based path with UTF-16 characters
|}

In IPC requests, sizes of ASCII and UTF16 paths must include space for the null-terminator.

== Binary LowPath ==
The format of the data that a binary LowPath points to is custom per archive.

=== SelfNCCH File Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Type:
* 0x0: RomFS
* 0x1: error 0xD9004676
* 0x2: ExeFS
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module crashes on this
* 0x5: Update RomFS?
|-
| 1-2
| File name for ExeFS ("icon"/"banner"/"logo"). ".code" is not allowed
|}

Note that ExeFS files only support reading from offset=0 and with size=file_size.

=== SystemSaveData Archive Path Data Format ===
==== FS ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be zero for NAND)
|-
| 1
| saveid
|}
The file/directory lowpath is a text lowpath in the [[Savegames|savegame]] filesystem.

==== FSPXI ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| u8 [[Mediatypes|Mediatype]] (must be zero for NAND)
|}
The file lowpath is a binary lowpath containing the u64 saveid, however the high word of the saveid is always zero. The mounted file is the cleartext savegame image. Up to 32 SystemSaveData image files can be opened under a single mounted FSPXI archive.

=== UserSaveDataForCheck Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be non-zero)
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
The file/directory lowpath for this FS archive is a text path in the [[Savegames|savegame]] filesystem.

=== 0x567890B4 Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| <code><nowiki>Lower_word_saveid >> 8</nowiki></code> ?
|-
| 2
| Unknown. Game calculate this using formula <code><nowiki>0xFFFFFF00 | unknown_b</nowiki></code>
|}

=== ExtSaveData Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
For FS, the file/directory lowpath is a text path in the [[extdata]] filesystem. For FSPXI, the file lowpath is a text path relative to the "/extdata/<ExtdataIDHigh>/<ExtdataIDLow>" directory on SD/NAND, for the cleartext extdata image to mount.

=== 0x2345678A Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Lower word programID
|-
| 1
| Upper word programID
|-
| 2
| ([[Mediatypes|Mediatype]] & 0xFF) | (uninitialized_data? & 0xFFFFFF00)
|-
| 3
| Number of something? Hardcoded per-archive, 0 for ExeFS, 200 for area:, 100 for rate:, 40 for eula:, etc.
|}

File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| 0 for NCCH data, 1 for savedata. The latter is only valid for FSPXI. Value 2 is allowed via archive 0x3, it's unknown what this is.
|-
| 1
| TMD content index / NCSD partition index.
|-
| 2
| Type: 0=romfs(0 for non-NCCH as well), 1=exefs ".code"(?), 2=exefs "icon"/"banner"/"logo", 3=unknown, 4=unknown, 5=unknown.
|-
| 3-4
| Filename for ExeFS.
|}

The 0x14-byte lowpath is all-zero for accessing the title's main RomFS.

=== [[RomFS]] ===

Archives 0x3 and 0x2345678E both allow for accessing the [[RomFS#Level_3_Format|level-3 IVFC images]] for RomFS access. The main CXI RomFS is accessible via an all-zero 0xc-byte binary file-lowpath. The update RomFS can be accessed with the first u32 in the binary file-lowpath being set to 0x5. The user must handle parsing the filesystem used in the exposed image itself.

With FSPXI the returned data for RomFS is the entire RomFS section from the NCCH, starting at the IVFC header.

The 0x3 archive is an interface for the 0x2345678E archive with the current process programID+mediatype. The file lowpath is 3-words. These words are written to 0x2345678E-archive file_lowpath+0, with the rest of that lowpath set to all-zero(lowpath is different from archive 0x2345678A). File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| See above. The only values which FS-module doesn't allow to be used here are:
* 0x1: Error 0xE0E046BE.
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module executes svcBreak when using this.
|-
| 1-2
| See above. Not validated by FS-module.
|}

=SEEDDB=
With [[9.6.0-24|9.6.0-X]] new [[System_SaveData]] with saveID 0001000F was added, this seems to be handled by FS-module itself, probably via the new service-cmds added to fsuser. [[Home Menu]] and [[NIM_Services|NIM]] module have access to those commands.

The SEEDDB savedata contains the title-unique seed-data used for the new [[NCCH]] keyY generation added with FIRM [[9.6.0-24|9.6.0-X]].

= Common Types =
== MediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| NAND
|-
| 1
| SD
|-
| 2
| Game Card
|}

== SystemMediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| CTR NAND
|-
| 1
| TWL NAND
|-
| 2
| SD
|-
| 3
| TWL Photo
|}

== OpenFlags ==
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0
| Read
|-
| 1
| Write
|-
| 2
| Create
|}

== Attributes ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Is Directory
|-
| 0x1
| 0x1
| Is Hidden
|-
| 0x2
| 0x1
| Is Archive
|-
| 0x3
| 0x1
| Is Read-Only
|}

== WriteOption ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Flush
|-
| 0x1
| 0x1
| Update Time Stamp
|-
| 0x2
| 0x1
| Reserved
|-
| 0x3
| 0x1
| Reserved
|}

== DirectoryEntry ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x20C
| UTF-16 Entry Name
|-
| 0x20C
| 0xA
| 8.3 short filename name
|-
| 0x216
| 0x4
| 8.3 short filename extension
|-
| 0x21A
| 0x1
| Always 1
|-
| 0x21B
| 0x1
| Reserved
|-
| 0x21C
| 0x4
| [[Filesystem_services#Attributes|Attributes]]
|-
| 0x220
| 0x8
| Entry Size
|}

== ArchiveResource ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Sector byte-size
|-
| 0x4
| 0x4
| Cluster byte-size
|-
| 0x8
| 0x4
| Partition capacity in clusters
|-
| 0xC
| 0x4
| Available free space in clusters
|}

== ProgramInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| Program ID
|-
| 0x8
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x9
| 0x7
| Padding
|}

== ProductInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Product Code
|-
| 0x10
| 0x2
| Company Code
|-
| 0x12
| 0x2
| Remaster Version
|}

== IntegrityVerificationSeed ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| AES-CBC MAC over a SHA256 hash, which hashes the first 0x110-bytes of the cleartext SEED.
|-
| 0x10
| 0x120
| The [[nand/private/movable.sed]], encrypted with AES-CBC using the above MAC for the counter.
|}

== ExtSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x8
| Save ID
|-
| 0xC
| 0x4
| Reserved
|}

== SystemSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x4
| Save ID
|}

== SecureValueSlot ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1000
| SD Application
|}

== CardSpiBaudRate ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 512KHz
|-
| 0x1
| 1MHz
|-
| 0x2
| 2MHz
|-
| 0x3
| 4MHz
|-
| 0x4
| 8MHz
|-
| 0x5
| 16MHz
|}

== CardSpiBusMode ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 1-bit
|-
| 0x1
| 4-bit
|}

== SpecialContentType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1
| Update
|-
| 0x2
| Manual
|-
| 0x3
| DLP Child
|}

== DeviceMoveContext ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| IVs
|-
| 0x10
| 0x10
| Encrypt Parameter
|}

=Errors=
See [[Filesystem_services_PXI]].

[[Category:Services]]

Filesystem services

2024-11-27T09:16:36Z

PabloMK7:

= Services =
{{Anchor|FS}}{{Anchor|FSUSER}}{{Anchor|fs:USER}}
== Filesystem service "fs:USER" ==
You can at most have 32 FS archive handles.

{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! scope="col" width="400" | Required [[NCCH/Extended_Header|exheader]] access info bitmask
|-
| 0x000100C6
|?
| [[FS:Dummy1|Dummy1]]
| None
|-
| 0x040100C4
|?
| [[FS:Control|Control]]
| None
|-
| 0x08010002
|?
| [[FS:Initialize|Initialize]]
| None
|-
| 0x080201C2
|?
| [[FS:OpenFile|OpenFile]]
| None
|-
| 0x08030204
|?
| [[FS:OpenFileDirectly|OpenFileDirectly]]
| None
|-
| 0x08040142
|?
| [[FS:DeleteFile|DeleteFile]]
| None
|-
| 0x08050244
|?
| [[FS:RenameFile|RenameFile]]
| None
|-
| 0x08060142
|?
| [[FS:DeleteDirectory|DeleteDirectory]]
| None
|-
| 0x08070142
|?
| [[FS:DeleteDirectoryRecursively|DeleteDirectoryRecursively]]
| None
|-
| 0x08080202
|?
| [[FS:CreateFile|CreateFile]]
| None
|-
| 0x08090182
|?
| [[FS:CreateDirectory|CreateDirectory]]
| None
|-
| 0x080A0244
|?
| [[FS:RenameDirectory|RenameDirectory]]
| None
|-
| 0x080B0102
|?
| [[FS:OpenDirectory|OpenDirectory]]
| None
|-
| 0x080C00C2
|?
| [[FS:OpenArchive|OpenArchive]]
| Each archive ID code has separate access info bitmasks, if it has any
|-
| 0x080D0144
|?
| [[FS:ControlArchive|ControlArchive]]
| None
|-
| 0x080E0080
|?
| [[FS:CloseArchive|CloseArchive]]
| None
|-
| 0x080F0180
|?
| [[FS:Obsoleted_2_0_FormatThisUserSaveData|Obsoleted_2_0_FormatThisUserSaveData]]
| None
|-
| 0x08100200
|?
| [[FS:Obsoleted_3_0_CreateSystemSaveData|Obsoleted_3_0_CreateSystemSaveData]]
| 0x4, for when the input saveID doesn't match the exheader saveID
|-
| 0x08110040
|?
| [[FS:Obsoleted_3_0_DeleteSystemSaveData|Obsoleted_3_0_DeleteSystemSaveData]]
| 0x1004, for when the input saveID doesn't match the exheader saveID
|-
| 0x08120080
|?
| [[FS:GetFreeBytes|GetFreeBytes]]
| None
|-
| 0x08130000
|?
| [[FS:GetCardType|GetCardType]]
| 0x1017
|-
| 0x08140000
|?
| [[FS:GetSdmcArchiveResource|GetSdmcArchiveResource]]
| None
|-
| 0x08150000
|?
| [[FS:GetNandArchiveResource|GetNandArchiveResource]]
| 0x1007
|-
| 0x08160000
|?
| [[FS:GetSdmcFatfsError|GetSdmcFatfsError]]
| 0x2
|-
| 0x08170000
|?
| [[FS:IsSdmcDetected|IsSdmcDetected]]
| None
|-
| 0x08180000
|?
| [[FS:IsSdmcWritable|IsSdmcWritable]]
| None
|-
| 0x08190042
|?
| [[FS:GetSdmcCid|GetSdmcCid]]
| 0x2
|-
| 0x081A0042
|?
| [[FS:GetNandCid|GetNandCid]]
| 0x2
|-
| 0x081B0000
|?
| [[FS:GetSdmcSpeedInfo|GetSdmcSpeedInfo]]
| 0x2
|-
| 0x081C0000
|?
| [[FS:GetNandSpeedInfo|GetNandSpeedInfo]]
| 0x2
|-
| 0x081D0042
|?
| [[FS:GetSdmcLog|GetSdmcLog]]
| 0x2
|-
| 0x081E0042
|?
| [[FS:GetNandLog|GetNandLog]]
| 0x2
|-
| 0x081F0000
|?
| [[FS:ClearSdmcLog|ClearSdmcLog]]
| 0x2
|-
| 0x08200000
|?
| [[FS:ClearNandLog|ClearNandLog]]
| 0x2
|-
| 0x08210000
|?
| [[FS:CardSlotIsInserted|CardSlotIsInserted]]
| 0x1017
|-
| 0x08220000
|?
| [[FS:CardSlotPowerOn|CardSlotPowerOn]]
| 0x2
|-
| 0x08230000
|?
| [[FS:CardSlotPowerOff|CardSlotPowerOff]]
| 0x2
|-
| 0x08240000
|?
| [[FS:CardSlotGetCardIFPowerStatus|CardSlotGetCardIFPowerStatus]]
| 0x2
|-
| 0x08250040
|?
| [[FS:CardNorDirectCommand|CardNorDirectCommand]]
| 0x2
|-
| 0x08260080
|?
| [[FS:CardNorDirectCommandWithAddress|CardNorDirectCommandWithAddress]]
| 0x2
|-
| 0x08270082
|?
| [[FS:CardNorDirectRead|CardNorDirectRead]]
| 0x2
|-
| 0x082800C2
|?
| [[FS:CardNorDirectReadWithAddress|CardNorDirectReadWithAddress]]
| 0x2
|-
| 0x08290082
|?
| [[FS:CardNorDirectWrite|CardNorDirectWrite]]
| 0x2
|-
| 0x082A00C2
|?
| [[FS:CardNorDirectWriteWithAddress|CardNorDirectWriteWithAddress]]
| 0x2
|-
| 0x082B00C2
|?
| [[FS:CardNorDirectRead_4xIO|CardNorDirectRead_4xIO]]
| 0x2
|-
| 0x082C0082
|?
| [[FS:CardNorDirectCpuWriteWithoutVerify|CardNorDirectCpuWriteWithoutVerify]]
| 0x2
|-
| 0x082D0040
|?
| [[FS:CardNorDirectSectorEraseWithoutVerify|CardNorDirectSectorEraseWithoutVerify]]
| 0x2
|-
| 0x082E0040
|?
| [[FS:GetProductInfo|GetProductInfo]]
| 0x1005
|-
| 0x082F0040
|?
| [[FS:GetProgramLaunchInfo|GetProgramLaunchInfo]]
| 0x1005
|-
| 0x08300182
|?
| [[FS:Obsoleted_3_0_CreateExtSaveData|Obsoleted_3_0_CreateExtSaveData]]
| 0xC, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08310180
|?
| [[FS:Obsoleted_3_0_CreateSharedExtSaveData|Obsoleted_3_0_CreateSharedExtSaveData]]
| 0x1005
|-
| 0x08320102
|?
| [[FS:Obsoleted_3_0_ReadExtSaveDataIcon|Obsoleted_3_0_ReadExtSaveDataIcon]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08330082
|?
| [[FS:Obsoleted_3_0_EnumerateExtSaveData|Obsoleted_3_0_EnumerateExtSaveData]]
| 0x1005
|-
| 0x08340082
|?
| [[FS:Obsoleted_3_0_EnumerateSharedExtSaveData|Obsoleted_3_0_EnumerateSharedExtSaveData]]
| 0x1005
|-
| 0x08350080
|?
| [[FS:Obsoleted_3_0_DeleteExtSaveData|Obsoleted_3_0_DeleteExtSaveData]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08360080
|?
| [[FS:Obsoleted_3_0_DeleteSharedExtSaveData|Obsoleted_3_0_DeleteSharedExtSaveData]]
| 0x1005
|-
| 0x08370040
|?
| [[FS:SetCardSpiBaudRate|SetCardSpiBaudRate]]
| 0x2
|-
| 0x08380040
|?
| [[FS:SetCardSpiBusMode|SetCardSpiBusMode]]
| 0x2
|-
| 0x08390000
|?
| [[FS:SendInitializeInfoTo9|SendInitializeInfoTo9]]
| None
|-
| 0x083A0100
|?
| [[FS:GetSpecialContentIndex|GetSpecialContentIndex]]
| 0x1005
|-
| 0x083B00C2
|?
| [[FS:GetLegacyRomHeader|GetLegacyRomHeader]]
| 0x1015
|-
| 0x083C00C2
|?
| [[FS:GetLegacyBannerData|GetLegacyBannerData]]
| 0x1015
|-
| 0x083D0100
|?
| [[FS:CheckAuthorityToAccessExtSaveData|CheckAuthorityToAccessExtSaveData]]
| 0x44
|-
| 0x083E00C2
|?
| [[FS:QueryTotalQuotaSize|QueryTotalQuotaSize]]
| None
|-
| 0x083F00C0
|?
| [[FS:Obsoleted_3_0_GetExtDataBlockSize|Obsoleted_3_0_GetExtDataBlockSize]]
| None
|-
| 0x08400040
|?
| [[FS:AbnegateAccessRight|AbnegateAccessRight]]
|?
|-
| 0x08410000
|?
| [[FS:DeleteSdmcRoot|DeleteSdmcRoot]]
| 0x1005
|-
| 0x08420040
|?
| [[FS:DeleteAllExtSaveDataOnNand|DeleteAllExtSaveDataOnNand]]
| 0x1005
|-
| 0x08430000
|?
| [[FS:InitializeCtrFileSystem|InitializeCtrFileSystem]]
| None
|-
| 0x08440000
|?
| [[FS:CreateSeed|CreateSeed]]
| 0x2
|-
| 0x084500C2
|?
| [[FS:GetFormatInfo|GetFormatInfo]]
|?
|-
| 0x08460102
|?
| [[FS:GetLegacyRomHeader2|GetLegacyRomHeader2]]
| 0x1015
|-
| 0x08470180
|?
| [[FS:Obsoleted_2_0_FormatCtrCardUserSaveData|Obsoleted_2_0_FormatCtrCardUserSaveData]]
| 0x6
|-
| 0x08480042
|?
| [[FS:GetSdmcCtrRootPath|GetSdmcCtrRootPath]]
| 0x100D
|-
| 0x08490040
|?
| [[FS:GetArchiveResource|GetArchiveResource]]
|?
|-
| 0x084A0002
|?
| [[FS:ExportIntegrityVerificationSeed|ExportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084B0002
|?
| [[FS:ImportIntegrityVerificationSeed|ImportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084C0242
|?
| [[FS:FormatSaveData|FormatSaveData]]
| 0x6, in some cases this write isn't needed however
|-
| 0x084D0102
|?
| [[FS:GetLegacySubBannerData|GetLegacySubBannerData]]
| 0x1015
|-
| 0x084E0342
|?
| [[FS:UpdateSha256Context|UpdateSha256Context]]
| 0x5
|-
| 0x084F0102
|?
| [[FS:ReadSpecialFile|ReadSpecialFile]]
| None
|-
| 0x08500040
|?
| [[FS:GetSpecialFileSize|GetSpecialFileSize]]
| None
|-
| 0x08510242
| [[3.0.0-5]]
| [[FS:CreateExtSaveData|CreateExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0xC
|-
| 0x08520100
| [[3.0.0-5]]
| [[FS:DeleteExtSaveData|DeleteExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0x10100D
|-
| 0x08530142
| [[3.0.0-5]]
| [[FS:ReadExtSaveDataIcon|ReadExtSaveDataIcon]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x085400C0
| [[3.0.0-5]]
| [[FS:GetExtDataBlockSize|GetExtDataBlockSize]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x08550102
| [[3.0.0-5]]
| [[FS:EnumerateExtSaveData|EnumerateExtSaveData]]
| 0x101005
|-
| 0x08560240
| [[3.0.0-5]]
| [[FS:CreateSystemSaveData|CreateSystemSaveData]]
| 0x4 (this doesn't apply in certain cases, however)
|-
| 0x08570080
| [[3.0.0-5]]
| [[FS:DeleteSystemSaveData|DeleteSystemSaveData]]
| 0x1004 (this doesn't apply in certain cases, however)
|-
| 0x08580000
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsSource|StartDeviceMoveAsSource]]
| 0x2004
|-
| 0x08590200
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsDestination|StartDeviceMoveAsDestination]]
| 0x2004
|-
| 0x085A00C0
| [[3.0.0-5]]
| [[FS:SetArchivePriority|SetArchivePriority]]
| None
|-
| 0x085B0080
| [[3.0.0-5]]
| [[FS:GetArchivePriority|GetArchivePriority]]
| None
|-
| 0x085C00C0
| [[3.0.0-5]]
| [[FS:SetCtrCardLatencyParameter|SetCtrCardLatencyParameter]]
| 0xE
|-
| 0x085D01C0
| [[3.0.0-5]]
| [[FS:SetFsCompatibilityInfo|SetFsCompatibilityInfo]]
| 0x100001
|-
| 0x085E0040
| [[3.0.0-5]]
| [[FS:ResetCardCompatibilityParameter|ResetCardCompatibilityParameter]]
| 0xE
|-
| 0x085F0040
| [[3.0.0-5]]
| [[FS:SwitchCleanupInvalidSaveData|SwitchCleanupInvalidSaveData]]
| 0x12004
|-
| 0x08600042
| [[3.0.0-5]]
| [[FS:EnumerateSystemSaveData|EnumerateSystemSaveData]]
| 0x2004
|-
| 0x08610042
| [[3.0.0-5]]
| [[FS:InitializeWithSdkVersion|InitializeWithSdkVersion]]
| None
|-
| 0x08620040
| [[3.0.0-5]]
| [[FS:SetPriority|SetPriority]]
| None
|-
| 0x08630000
| [[3.0.0-5]]
| [[FS:GetPriority|GetPriority]]
| None
|-
| 0x08640000
| [[3.0.0-5]]
| [[FS:Obsoleted_4_0_GetNandInfo|Obsoleted_4_0_GetNandInfo]]
| Stubbed, this returns an error
|-
| 0x08650140
| [[4.0.0-7]]
| [[FS:SetSaveDataSecureValue|SetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086600C0
| [[4.0.0-7]]
| [[FS:GetSaveDataSecureValue|GetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086700C4
| [[4.0.0-7]]
| [[FS:ControlSecureSave|ControlSecureSave]]
| 0x121004
|-
| 0x08680000
| [[4.0.0-7]]
| [[FS:GetMediaType|GetMediaType]]
| None
|-
| 0x08690000
| [[4.0.0-7]]
| [[FS:Obsoleted_4_0_GetNandEraseCount|Obsoleted_4_0_GetNandEraseCount]]
| Stubbed, this returns an error.
|-
| 0x086A0082
| [[4.0.0-7]]
| [[FS:ReadNandReport|ReadNandReport]]
| None
|-
| 0x086B00C2
|?
|SetOtherSaveDataSecureValue
| 00121004
|-
| 0x086C00C2
|?
|GetOtherSaveDataSecureValue
| 00121004
|-
| 0x086D0040
|?
|?
| 00020004
|-
| 0x086E00C0
|Related to Secure Value? Used in Pokemon Sun/Moon.
|SetThisSaveDataSecureValue
|None?
|-
| 0x086F0040
|Related to Secure Value? Used in Pokemon Sun/Moon.
|GetThisSaveDataSecureValue
| 0xE
|-
| 0x087000C2
|?
|?
|None?
|-
| 0x08710100
|?
|?
| 0xC
|-
| 0x087201C0
|?
|?
| 00080004
|-
| 0x087300C0
|?
|?
| 00080004
|-
| 0x08740000
|?
|?
| 00080004
|-
| 0x08750140
|?
|?
|None?
|-
| 0x087600C0
|?
|?
|None?
|-
| 0x08770100
|?
|?
|?
|-
| 0x087800C0
|?
|?
|?
|-
| 0x087900C2
| ?
| Same as GetLegacyBannerData, except for the last parameter this passes u8 value 0x1 instead of 0x0, for the FSPXI command.
| 0x00101015
|-
| 0x087A0180
| [[9.6.0-24|9.6.0-X]]
| [[FS:AddSeed|AddSeed]]
| 0x00200000
|-
| 0x087B0080
| [[9.6.0-24|9.6.0-X]]
| [[FS:GetSeed|GetSeed]]
| 0x00200000
|-
| 0x087C....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x087D0000
| [[9.6.0-24|9.6.0-X]]
| GetNumSeeds. Writes the number of seeds to cmdreply[2]
| 0x00200000
|-
| 0x087E0042
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>. Writes a list of titleIDs to the outbuf, this is for titles with content-lock-seed(s) stored in SEEDDB. (u32 total_titleids_probably, ((Size<<4) <nowiki>|</nowiki> 12), outbufptr)
| 0x00200000
|-
| 0x087F....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x0880....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x8810080
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0882....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x08830000
| [[9.6.0-24|9.6.0-X]]
| Writes an output value to cmdreply[2].
| 0x00200000
|-
| 0x08840042
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0885....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x088600C0
| [[11.1.0-34|11.1.0-X]]
| [[FS:CheckUpdatedDat|CheckUpdatedDat]]
| 0x00080000
|}

Note: The question marks from Dummy1 to GetSpecialFileSize on the "available since system version" field are mainly there because I think that most of these are necessary for the main system to function, so theoretically that would mean that since the creation of the 3DS these were available, or since launch if that makes more sense. But because of the peculiar nature of some of the functions, they will remain question marks until they can be confirmed 100%.

When access rights are required for a command, at least one of the bits in the process access info specified in the above table for the command must be set. Error 0xD9004676 is returned when a process attempts to use a command which it doesn't have access rights for the command. The exheader access info field is all zero's for most applications. Note that the permissions listed in the above table is for system-version v2.x, therefore permission bit(s) added with newer FIRM may be missing from this.

Each session for fs:USER has separate permissions, initially these are set to all zero's for new fs:USER sessions. The permissions/etc for fs:USER sessions are initialized via [[FS:Initialize]](loaded from the user process exheader).

{{Anchor|FSLDR}}{{Anchor|fs:LDR}}
== Filesystem service "fs:LDR" ==
This service is identical to fs:USER, except [[FS:OpenArchive]] archive 0x2345678E can only be accessed with fs:LDR.

{{Anchor|FSReg}}{{Anchor|FSREG}}{{Anchor|fs:REG}}
== ProgramRegistry service "fs:REG" ==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| [[FSReg:Dummy1|Dummy1]]
|-
| 0x040103C0
| [[FSReg:Register|Register]]
|-
| 0x04020040
| [[FSReg:Unregister|Unregister]]
|-
| 0x040300C0
| [[FSReg:GetProgramInfo|GetProgramInfo]]
|-
| 0x04040100
| [[FSReg:LoadProgram|LoadProgram]]
|-
| 0x04050080
| [[FSReg:UnloadProgram|UnloadProgram]]
|-
| 0x04060080
| [[FSReg:CheckHostLoadId|CheckHostLoadId]]
|}

Only two sessions can be opened for this service at a time, hence no other processes can use this due to [[Process_Manager_Services|pm-module]] and [[Loader_Services|loader]] using this.

=File and directory access=
==Files==
File session handles obtained via [[FS:OpenFile]] and [[FS:OpenFileDirectly]] can be used to access files through a service-like interface, despite not being an actual service registered using [[SRV:RegisterService]]. To use this service-like interface, simply call the SendSyncRequest SVC with a file session handle, using the IPC buffer in thread-local storage for parameters and responses, just like you would with a proper service.

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| [[FSFile:Dummy1|Dummy1]]
|-
| 0x040100C4
| [[FSFile:Control|Control]]
|-
| 0x08010100
| [[FSFile:OpenSubFile|OpenSubFile]]
|-
| 0x080200C2
| [[FSFile:Read|Read]]
|-
| 0x08030102
| [[FSFile:Write|Write]]
|-
| 0x08040000
| [[FSFile:GetSize|GetSize]]
|-
| 0x08050080
| [[FSFile:SetSize|SetSize]]
|-
| 0x08060000
| [[FSFile:GetAttributes|GetAttributes]]
|-
| 0x08070040
| [[FSFile:SetAttributes|SetAttributes]]
|-
| 0x08080000
| [[FSFile:Close|Close]]
|-
| 0x08090000
| [[FSFile:Flush|Flush]]
|-
| 0x080A0040
| [[FSFile:SetPriority|SetPriority]]
|-
| 0x080B0000
| [[FSFile:GetPriority|GetPriority]]
|-
| 0x080C0000
| [[FSFile:OpenLinkFile|OpenLinkFile]]
|-
| 0x0C010100
| [[FSFile:GetAvailable|GetAvailable]]
|}

==Directories==
Directory session handles obtained via [[FS:OpenDirectory]] are usable via a service-like interface, following the exact same procedure described above for file sessions.
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x000100C6
| [[1.0.0-0]]
| [[FSDir:Dummy1|Dummy1]]
|-
| 0x040100C4
| [[1.0.0-0]]
| [[FSDir:Control|Control]]
|-
| 0x08010042
| [[1.0.0-0]]
| [[FSDir:Read|Read]]
|-
| 0x08020000
| [[1.0.0-0]]
| [[FSDir:Close|Close]]
|-
| 0x08030040
| ?
| [[FSDir:SetPriority|SetPriority]]
|-
| 0x08040000
| ?
| [[FSDir:GetPriority|GetPriority]]
|}

= Archives =
{| class="wikitable" border="1"
|-
! ArchiveId
! Description
! Accessible via [[Filesystem_services|FS]]
! Accessible via [[Filesystem_services_PXI|FSPXI]]
! Only accessible by Process9 internally
! Requires binary [[FS:OpenFile|Lowpath]]
! Required exheader FS access info bitmask
|-
| 0x00000003
| SelfNCCH (including [[#RomFS|RomFS]])
| Yes
| No
| No
| No
| None
|-
| 0x00000004
| SaveData (the saveID/mediatype for this is loaded from data originally from the user process' exheader)
| Yes
| No
| No
| No
| None
|-
| 0x00000006
| ExtSaveData
| Yes
| No
| No
| Yes
| 0x100D, when the input extdataID isn't listed in the exheader.
|-
| 0x00000007
| Shared ExtSaveData
| Yes
| No
| No
| Yes
| None
|-
| 0x00000008
| SystemSaveData
| Yes
| No
| No
| Yes
| 0x4, when the input saveID doesn't match the exheader system-saveID.
|-
| 0x00000009
| SDMC
| Yes
| Yes
| No
| No
| 0x8E
|-
| 0x0000000A
| SDMC Write-Only
| Yes
| No
| No
| No
| 0x808E
|-
| 0x12345678
| ExtSaveData for BOSS
| Yes
| No
| No
| Yes
| 0x44
|-
| 0x12345679
| CARD SPI FS
| Yes
| Yes
| No
| No
| 0x16
|-
| 0x1234567B
| ExtSaveData, and ExtSaveData for BOSS
| No
| Yes
| No
| Yes
|
|-
| 0x1234567C
| SystemSaveData
| No
| Yes
| No
| Yes
|
|-
| 0x1234567D
| NAND RW
| Yes
| Yes
| No
| No
| 0x800
|-
| 0x1234567E
| NAND RO
| Yes
| Yes
| No
| No
| 0x200
|-
| 0x1234567F
| NAND RO Write FS
| No
| Yes
| No
| No
| ?
|-
| 0x12345680
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x12345681
| Unknown. Accessed by FS service.
| ?
| ?
| No
| ?
| ?
|-
| 0x12345682
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x2345678A
| Used for accessing general NCCH data. With FSPXI this also allows savedata access.
| Yes
| Yes
| No
| Yes
| 0x1005
|-
| 0x2345678B
| ?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678C
| Used internally to access [[Title_Database|/dbs]] files?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678D
| ?
| No
| No
| Yes
| No
|
|-
| 0x2345678E
| FSPXI: Similar to archive 0x2345678A. For fs:LDR(used by the "loader" FIRM ARM11-process), only ExeFS. Not accessible with fs:USER.
| Yes
| Yes
| No
| Yes
| None, see description.
|-
| 0x567890AB
| NAND CTR FS
| No
| Yes
| No
| No
| ?
|-
| 0x567890AC
| TWL PHOTO
| Yes
| Yes
| No
| No
| ?
|-
| 0x567890AD
| TWLS (DSi Sound stores recordings here). This is mapped to the FAT12 image stored in the file at [[Twln/shared2/0000]].
| No
| Yes
| No
| No
| ?
|-
| 0x567890AE
| NAND TWL FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890AF
| NAND W FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890B0
| ?
| No
| Yes
| No
| No
|
|-
| 0x567890B1
| Gamecard SaveData (for check). This is a wrapper for UserSaveDataForCheck: the OpenArchive code for that is called with archive-lowpath TID=0/mediatype=2(gamecard).
| Yes
| No
| No
| No
| 0x6
|-
| 0x567890B2
| UserSaveData (for check). This is the same as the regular SaveData archive, except with this the savedata ID and mediatype is loaded from the input archive lowpath.
| Yes
| No
| No
| Yes
| 0x6
|-
| 0x567890B4
| Similar to 0x567890B2 but can only access Accessible Save specified in [[NCCH/Extended_Header#Storage_Info|exheader]]?
| Yes
| No
| No
| Yes
| ?
|}

Archives listed as not requiring a binary lowpath, use lowpath type [[FS:OpenFile|empty]].

The above permission bitmasks are from v2.x, see the above Services section for how these are handled.

Archives CTR NAND, NAND RO Write FS, TWL NAND, NAND W FS, and CARD SPI FS require the corresponding process exheader access control mount flag to be set, in the exheader for any of the currently running ARM11 processes, for [[Filesystem_services_PXI|FSPXI]]. The access rights checked by [[Filesystem services|FS]] module for archive mounting with fs:USER, are stored in the process' exheader accessinfo.

The CARDSPI archive allows access to the gamecard CARD1 raw savedata flash(aka "cardspi:/" in [[FIRM|Process9]]), the file lowpath must be WCHAR "/". The "NAND W FS" archive allows access to the raw NAND image(aka "wnand:/" in Process9), the file lowpath must be WCHAR "/".

= Filenames and Paths =
{{Anchor|PathType}} PathType:
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| -1
| Returned internally by Process9, when errors occur it seems(in particular when no nul-terminator was found in the input path). The data ptr is set to NULL.
|-
| 0x0
| INVALID - Specifies an invalid path
|-
| 0x1
| EMPTY - Specifies an empty path
|-
| 0x2
| BINARY - Non-text based path. Meaning is per-archive
|-
| 0x3
| ASCII - Text-based path with 7-bit ASCII characters padded to 8-bits each (signed char)
|-
| 0x4
| UTF16 - Text-based path with UTF-16 characters
|}

In IPC requests, sizes of ASCII and UTF16 paths must include space for the null-terminator.

== Binary LowPath ==
The format of the data that a binary LowPath points to is custom per archive.

=== SelfNCCH File Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Type:
* 0x0: RomFS
* 0x1: error 0xD9004676
* 0x2: ExeFS
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module crashes on this
* 0x5: Update RomFS?
|-
| 1-2
| File name for ExeFS ("icon"/"banner"/"logo"). ".code" is not allowed
|}

Note that ExeFS files only support reading from offset=0 and with size=file_size.

=== SystemSaveData Archive Path Data Format ===
==== FS ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be zero for NAND)
|-
| 1
| saveid
|}
The file/directory lowpath is a text lowpath in the [[Savegames|savegame]] filesystem.

==== FSPXI ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| u8 [[Mediatypes|Mediatype]] (must be zero for NAND)
|}
The file lowpath is a binary lowpath containing the u64 saveid, however the high word of the saveid is always zero. The mounted file is the cleartext savegame image. Up to 32 SystemSaveData image files can be opened under a single mounted FSPXI archive.

=== UserSaveDataForCheck Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be non-zero)
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
The file/directory lowpath for this FS archive is a text path in the [[Savegames|savegame]] filesystem.

=== 0x567890B4 Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| <code><nowiki>Lower_word_saveid >> 8</nowiki></code> ?
|-
| 2
| Unknown. Game calculate this using formula <code><nowiki>0xFFFFFF00 | unknown_b</nowiki></code>
|}

=== ExtSaveData Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
For FS, the file/directory lowpath is a text path in the [[extdata]] filesystem. For FSPXI, the file lowpath is a text path relative to the "/extdata/<ExtdataIDHigh>/<ExtdataIDLow>" directory on SD/NAND, for the cleartext extdata image to mount.

=== 0x2345678A Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Lower word programID
|-
| 1
| Upper word programID
|-
| 2
| ([[Mediatypes|Mediatype]] & 0xFF) | (uninitialized_data? & 0xFFFFFF00)
|-
| 3
| Number of something? Hardcoded per-archive, 0 for ExeFS, 200 for area:, 100 for rate:, 40 for eula:, etc.
|}

File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| 0 for NCCH data, 1 for savedata. The latter is only valid for FSPXI. Value 2 is allowed via archive 0x3, it's unknown what this is.
|-
| 1
| TMD content index / NCSD partition index.
|-
| 2
| Type: 0=romfs(0 for non-NCCH as well), 1=exefs ".code"(?), 2=exefs "icon"/"banner"/"logo", 3=unknown, 4=unknown, 5=unknown.
|-
| 3-4
| Filename for ExeFS.
|}

The 0x14-byte lowpath is all-zero for accessing the title's main RomFS.

=== [[RomFS]] ===

Archives 0x3 and 0x2345678E both allow for accessing the [[RomFS#Level_3_Format|level-3 IVFC images]] for RomFS access. The main CXI RomFS is accessible via an all-zero 0xc-byte binary file-lowpath. The update RomFS can be accessed with the first u32 in the binary file-lowpath being set to 0x5. The user must handle parsing the filesystem used in the exposed image itself.

With FSPXI the returned data for RomFS is the entire RomFS section from the NCCH, starting at the IVFC header.

The 0x3 archive is an interface for the 0x2345678E archive with the current process programID+mediatype. The file lowpath is 3-words. These words are written to 0x2345678E-archive file_lowpath+0, with the rest of that lowpath set to all-zero(lowpath is different from archive 0x2345678A). File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| See above. The only values which FS-module doesn't allow to be used here are:
* 0x1: Error 0xE0E046BE.
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module executes svcBreak when using this.
|-
| 1-2
| See above. Not validated by FS-module.
|}

=SEEDDB=
With [[9.6.0-24|9.6.0-X]] new [[System_SaveData]] with saveID 0001000F was added, this seems to be handled by FS-module itself, probably via the new service-cmds added to fsuser. [[Home Menu]] and [[NIM_Services|NIM]] module have access to those commands.

The SEEDDB savedata contains the title-unique seed-data used for the new [[NCCH]] keyY generation added with FIRM [[9.6.0-24|9.6.0-X]].

= Common Types =
== MediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| NAND
|-
| 1
| SD
|-
| 2
| Game Card
|}

== SystemMediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| CTR NAND
|-
| 1
| TWL NAND
|-
| 2
| SD
|-
| 3
| TWL Photo
|}

== OpenFlags ==
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0
| Read
|-
| 1
| Write
|-
| 2
| Create
|}

== Attributes ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Is Directory
|-
| 0x1
| 0x1
| Is Hidden
|-
| 0x2
| 0x1
| Is Archive
|-
| 0x3
| 0x1
| Is Read-Only
|}

== WriteOption ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Flush
|-
| 0x1
| 0x1
| Update Time Stamp
|-
| 0x2
| 0x1
| Reserved
|-
| 0x3
| 0x1
| Reserved
|}

== DirectoryEntry ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x20C
| UTF-16 Entry Name
|-
| 0x20C
| 0xA
| 8.3 short filename name
|-
| 0x216
| 0x4
| 8.3 short filename extension
|-
| 0x21A
| 0x1
| Always 1
|-
| 0x21B
| 0x1
| Reserved
|-
| 0x21C
| 0x4
| [[Filesystem_services#Attributes|Attributes]]
|-
| 0x220
| 0x8
| Entry Size
|}

== ArchiveResource ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Sector byte-size
|-
| 0x4
| 0x4
| Cluster byte-size
|-
| 0x8
| 0x4
| Partition capacity in clusters
|-
| 0xC
| 0x4
| Available free space in clusters
|}

== ProgramInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| Program ID
|-
| 0x8
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x9
| 0x7
| Padding
|}

== ProductInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Product Code
|-
| 0x10
| 0x2
| Company Code
|-
| 0x12
| 0x2
| Remaster Version
|}

== IntegrityVerificationSeed ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| AES-CBC MAC over a SHA256 hash, which hashes the first 0x110-bytes of the cleartext SEED.
|-
| 0x10
| 0x120
| The [[nand/private/movable.sed]], encrypted with AES-CBC using the above MAC for the counter.
|}

== ExtSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x8
| Save ID
|-
| 0xC
| 0x4
| Reserved
|}

== SystemSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x4
| Save ID
|}

== SecureValueSlot ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1000
| SD Application
|}

== CardSpiBaudRate ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 512KHz
|-
| 0x1
| 1MHz
|-
| 0x2
| 2MHz
|-
| 0x3
| 4MHz
|-
| 0x4
| 8MHz
|-
| 0x5
| 16MHz
|}

== CardSpiBusMode ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 1-bit
|-
| 0x1
| 4-bit
|}

== SpecialContentType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1
| Update
|-
| 0x2
| Manual
|-
| 0x3
| DLP Child
|}

== DeviceMoveContext ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| IVs
|-
| 0x10
| 0x10
| Encrypt Parameter
|}

=Errors=
See [[Filesystem_services_PXI]].

[[Category:Services]]

FS:GetSeed

2024-11-27T08:59:25Z

PabloMK7: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x087B0080] |- | 1-2 | u64, Title ID |} =Response= {| class="wikitable" border..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x087B0080]
|-
| 1-2
| u64, Title ID
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2-5
| Seed value
|}

=Description=
Gets the seed from the seed DB for the specified title. If the seed does not exist, it returns 0xC8804464

Filesystem services

2024-11-27T08:57:08Z

PabloMK7:

= Services =
{{Anchor|FS}}{{Anchor|FSUSER}}{{Anchor|fs:USER}}
== Filesystem service "fs:USER" ==
You can at most have 32 FS archive handles.

{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! scope="col" width="400" | Required [[NCCH/Extended_Header|exheader]] access info bitmask
|-
| 0x000100C6
|?
| [[FS:Dummy1|Dummy1]]
| None
|-
| 0x040100C4
|?
| [[FS:Control|Control]]
| None
|-
| 0x08010002
|?
| [[FS:Initialize|Initialize]]
| None
|-
| 0x080201C2
|?
| [[FS:OpenFile|OpenFile]]
| None
|-
| 0x08030204
|?
| [[FS:OpenFileDirectly|OpenFileDirectly]]
| None
|-
| 0x08040142
|?
| [[FS:DeleteFile|DeleteFile]]
| None
|-
| 0x08050244
|?
| [[FS:RenameFile|RenameFile]]
| None
|-
| 0x08060142
|?
| [[FS:DeleteDirectory|DeleteDirectory]]
| None
|-
| 0x08070142
|?
| [[FS:DeleteDirectoryRecursively|DeleteDirectoryRecursively]]
| None
|-
| 0x08080202
|?
| [[FS:CreateFile|CreateFile]]
| None
|-
| 0x08090182
|?
| [[FS:CreateDirectory|CreateDirectory]]
| None
|-
| 0x080A0244
|?
| [[FS:RenameDirectory|RenameDirectory]]
| None
|-
| 0x080B0102
|?
| [[FS:OpenDirectory|OpenDirectory]]
| None
|-
| 0x080C00C2
|?
| [[FS:OpenArchive|OpenArchive]]
| Each archive ID code has separate access info bitmasks, if it has any
|-
| 0x080D0144
|?
| [[FS:ControlArchive|ControlArchive]]
| None
|-
| 0x080E0080
|?
| [[FS:CloseArchive|CloseArchive]]
| None
|-
| 0x080F0180
|?
| [[FS:Obsoleted_2_0_FormatThisUserSaveData|Obsoleted_2_0_FormatThisUserSaveData]]
| None
|-
| 0x08100200
|?
| [[FS:Obsoleted_3_0_CreateSystemSaveData|Obsoleted_3_0_CreateSystemSaveData]]
| 0x4, for when the input saveID doesn't match the exheader saveID
|-
| 0x08110040
|?
| [[FS:Obsoleted_3_0_DeleteSystemSaveData|Obsoleted_3_0_DeleteSystemSaveData]]
| 0x1004, for when the input saveID doesn't match the exheader saveID
|-
| 0x08120080
|?
| [[FS:GetFreeBytes|GetFreeBytes]]
| None
|-
| 0x08130000
|?
| [[FS:GetCardType|GetCardType]]
| 0x1017
|-
| 0x08140000
|?
| [[FS:GetSdmcArchiveResource|GetSdmcArchiveResource]]
| None
|-
| 0x08150000
|?
| [[FS:GetNandArchiveResource|GetNandArchiveResource]]
| 0x1007
|-
| 0x08160000
|?
| [[FS:GetSdmcFatfsError|GetSdmcFatfsError]]
| 0x2
|-
| 0x08170000
|?
| [[FS:IsSdmcDetected|IsSdmcDetected]]
| None
|-
| 0x08180000
|?
| [[FS:IsSdmcWritable|IsSdmcWritable]]
| None
|-
| 0x08190042
|?
| [[FS:GetSdmcCid|GetSdmcCid]]
| 0x2
|-
| 0x081A0042
|?
| [[FS:GetNandCid|GetNandCid]]
| 0x2
|-
| 0x081B0000
|?
| [[FS:GetSdmcSpeedInfo|GetSdmcSpeedInfo]]
| 0x2
|-
| 0x081C0000
|?
| [[FS:GetNandSpeedInfo|GetNandSpeedInfo]]
| 0x2
|-
| 0x081D0042
|?
| [[FS:GetSdmcLog|GetSdmcLog]]
| 0x2
|-
| 0x081E0042
|?
| [[FS:GetNandLog|GetNandLog]]
| 0x2
|-
| 0x081F0000
|?
| [[FS:ClearSdmcLog|ClearSdmcLog]]
| 0x2
|-
| 0x08200000
|?
| [[FS:ClearNandLog|ClearNandLog]]
| 0x2
|-
| 0x08210000
|?
| [[FS:CardSlotIsInserted|CardSlotIsInserted]]
| 0x1017
|-
| 0x08220000
|?
| [[FS:CardSlotPowerOn|CardSlotPowerOn]]
| 0x2
|-
| 0x08230000
|?
| [[FS:CardSlotPowerOff|CardSlotPowerOff]]
| 0x2
|-
| 0x08240000
|?
| [[FS:CardSlotGetCardIFPowerStatus|CardSlotGetCardIFPowerStatus]]
| 0x2
|-
| 0x08250040
|?
| [[FS:CardNorDirectCommand|CardNorDirectCommand]]
| 0x2
|-
| 0x08260080
|?
| [[FS:CardNorDirectCommandWithAddress|CardNorDirectCommandWithAddress]]
| 0x2
|-
| 0x08270082
|?
| [[FS:CardNorDirectRead|CardNorDirectRead]]
| 0x2
|-
| 0x082800C2
|?
| [[FS:CardNorDirectReadWithAddress|CardNorDirectReadWithAddress]]
| 0x2
|-
| 0x08290082
|?
| [[FS:CardNorDirectWrite|CardNorDirectWrite]]
| 0x2
|-
| 0x082A00C2
|?
| [[FS:CardNorDirectWriteWithAddress|CardNorDirectWriteWithAddress]]
| 0x2
|-
| 0x082B00C2
|?
| [[FS:CardNorDirectRead_4xIO|CardNorDirectRead_4xIO]]
| 0x2
|-
| 0x082C0082
|?
| [[FS:CardNorDirectCpuWriteWithoutVerify|CardNorDirectCpuWriteWithoutVerify]]
| 0x2
|-
| 0x082D0040
|?
| [[FS:CardNorDirectSectorEraseWithoutVerify|CardNorDirectSectorEraseWithoutVerify]]
| 0x2
|-
| 0x082E0040
|?
| [[FS:GetProductInfo|GetProductInfo]]
| 0x1005
|-
| 0x082F0040
|?
| [[FS:GetProgramLaunchInfo|GetProgramLaunchInfo]]
| 0x1005
|-
| 0x08300182
|?
| [[FS:Obsoleted_3_0_CreateExtSaveData|Obsoleted_3_0_CreateExtSaveData]]
| 0xC, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08310180
|?
| [[FS:Obsoleted_3_0_CreateSharedExtSaveData|Obsoleted_3_0_CreateSharedExtSaveData]]
| 0x1005
|-
| 0x08320102
|?
| [[FS:Obsoleted_3_0_ReadExtSaveDataIcon|Obsoleted_3_0_ReadExtSaveDataIcon]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08330082
|?
| [[FS:Obsoleted_3_0_EnumerateExtSaveData|Obsoleted_3_0_EnumerateExtSaveData]]
| 0x1005
|-
| 0x08340082
|?
| [[FS:Obsoleted_3_0_EnumerateSharedExtSaveData|Obsoleted_3_0_EnumerateSharedExtSaveData]]
| 0x1005
|-
| 0x08350080
|?
| [[FS:Obsoleted_3_0_DeleteExtSaveData|Obsoleted_3_0_DeleteExtSaveData]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08360080
|?
| [[FS:Obsoleted_3_0_DeleteSharedExtSaveData|Obsoleted_3_0_DeleteSharedExtSaveData]]
| 0x1005
|-
| 0x08370040
|?
| [[FS:SetCardSpiBaudRate|SetCardSpiBaudRate]]
| 0x2
|-
| 0x08380040
|?
| [[FS:SetCardSpiBusMode|SetCardSpiBusMode]]
| 0x2
|-
| 0x08390000
|?
| [[FS:SendInitializeInfoTo9|SendInitializeInfoTo9]]
| None
|-
| 0x083A0100
|?
| [[FS:GetSpecialContentIndex|GetSpecialContentIndex]]
| 0x1005
|-
| 0x083B00C2
|?
| [[FS:GetLegacyRomHeader|GetLegacyRomHeader]]
| 0x1015
|-
| 0x083C00C2
|?
| [[FS:GetLegacyBannerData|GetLegacyBannerData]]
| 0x1015
|-
| 0x083D0100
|?
| [[FS:CheckAuthorityToAccessExtSaveData|CheckAuthorityToAccessExtSaveData]]
| 0x44
|-
| 0x083E00C2
|?
| [[FS:QueryTotalQuotaSize|QueryTotalQuotaSize]]
| None
|-
| 0x083F00C0
|?
| [[FS:Obsoleted_3_0_GetExtDataBlockSize|Obsoleted_3_0_GetExtDataBlockSize]]
| None
|-
| 0x08400040
|?
| [[FS:AbnegateAccessRight|AbnegateAccessRight]]
|?
|-
| 0x08410000
|?
| [[FS:DeleteSdmcRoot|DeleteSdmcRoot]]
| 0x1005
|-
| 0x08420040
|?
| [[FS:DeleteAllExtSaveDataOnNand|DeleteAllExtSaveDataOnNand]]
| 0x1005
|-
| 0x08430000
|?
| [[FS:InitializeCtrFileSystem|InitializeCtrFileSystem]]
| None
|-
| 0x08440000
|?
| [[FS:CreateSeed|CreateSeed]]
| 0x2
|-
| 0x084500C2
|?
| [[FS:GetFormatInfo|GetFormatInfo]]
|?
|-
| 0x08460102
|?
| [[FS:GetLegacyRomHeader2|GetLegacyRomHeader2]]
| 0x1015
|-
| 0x08470180
|?
| [[FS:Obsoleted_2_0_FormatCtrCardUserSaveData|Obsoleted_2_0_FormatCtrCardUserSaveData]]
| 0x6
|-
| 0x08480042
|?
| [[FS:GetSdmcCtrRootPath|GetSdmcCtrRootPath]]
| 0x100D
|-
| 0x08490040
|?
| [[FS:GetArchiveResource|GetArchiveResource]]
|?
|-
| 0x084A0002
|?
| [[FS:ExportIntegrityVerificationSeed|ExportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084B0002
|?
| [[FS:ImportIntegrityVerificationSeed|ImportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084C0242
|?
| [[FS:FormatSaveData|FormatSaveData]]
| 0x6, in some cases this write isn't needed however
|-
| 0x084D0102
|?
| [[FS:GetLegacySubBannerData|GetLegacySubBannerData]]
| 0x1015
|-
| 0x084E0342
|?
| [[FS:UpdateSha256Context|UpdateSha256Context]]
| 0x5
|-
| 0x084F0102
|?
| [[FS:ReadSpecialFile|ReadSpecialFile]]
| None
|-
| 0x08500040
|?
| [[FS:GetSpecialFileSize|GetSpecialFileSize]]
| None
|-
| 0x08510242
| [[3.0.0-5]]
| [[FS:CreateExtSaveData|CreateExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0xC
|-
| 0x08520100
| [[3.0.0-5]]
| [[FS:DeleteExtSaveData|DeleteExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0x10100D
|-
| 0x08530142
| [[3.0.0-5]]
| [[FS:ReadExtSaveDataIcon|ReadExtSaveDataIcon]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x085400C0
| [[3.0.0-5]]
| [[FS:GetExtDataBlockSize|GetExtDataBlockSize]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x08550102
| [[3.0.0-5]]
| [[FS:EnumerateExtSaveData|EnumerateExtSaveData]]
| 0x101005
|-
| 0x08560240
| [[3.0.0-5]]
| [[FS:CreateSystemSaveData|CreateSystemSaveData]]
| 0x4 (this doesn't apply in certain cases, however)
|-
| 0x08570080
| [[3.0.0-5]]
| [[FS:DeleteSystemSaveData|DeleteSystemSaveData]]
| 0x1004 (this doesn't apply in certain cases, however)
|-
| 0x08580000
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsSource|StartDeviceMoveAsSource]]
| 0x2004
|-
| 0x08590200
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsDestination|StartDeviceMoveAsDestination]]
| 0x2004
|-
| 0x085A00C0
| [[3.0.0-5]]
| [[FS:SetArchivePriority|SetArchivePriority]]
| None
|-
| 0x085B0080
| [[3.0.0-5]]
| [[FS:GetArchivePriority|GetArchivePriority]]
| None
|-
| 0x085C00C0
| [[3.0.0-5]]
| [[FS:SetCtrCardLatencyParameter|SetCtrCardLatencyParameter]]
| 0xE
|-
| 0x085D01C0
| [[3.0.0-5]]
| [[FS:SetFsCompatibilityInfo|SetFsCompatibilityInfo]]
| 0x100001
|-
| 0x085E0040
| [[3.0.0-5]]
| [[FS:ResetCardCompatibilityParameter|ResetCardCompatibilityParameter]]
| 0xE
|-
| 0x085F0040
| [[3.0.0-5]]
| [[FS:SwitchCleanupInvalidSaveData|SwitchCleanupInvalidSaveData]]
| 0x12004
|-
| 0x08600042
| [[3.0.0-5]]
| [[FS:EnumerateSystemSaveData|EnumerateSystemSaveData]]
| 0x2004
|-
| 0x08610042
| [[3.0.0-5]]
| [[FS:InitializeWithSdkVersion|InitializeWithSdkVersion]]
| None
|-
| 0x08620040
| [[3.0.0-5]]
| [[FS:SetPriority|SetPriority]]
| None
|-
| 0x08630000
| [[3.0.0-5]]
| [[FS:GetPriority|GetPriority]]
| None
|-
| 0x08640000
| [[3.0.0-5]]
| [[FS:Obsoleted_4_0_GetNandInfo|Obsoleted_4_0_GetNandInfo]]
| Stubbed, this returns an error
|-
| 0x08650140
| [[4.0.0-7]]
| [[FS:SetSaveDataSecureValue|SetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086600C0
| [[4.0.0-7]]
| [[FS:GetSaveDataSecureValue|GetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086700C4
| [[4.0.0-7]]
| [[FS:ControlSecureSave|ControlSecureSave]]
| 0x121004
|-
| 0x08680000
| [[4.0.0-7]]
| [[FS:GetMediaType|GetMediaType]]
| None
|-
| 0x08690000
| [[4.0.0-7]]
| [[FS:Obsoleted_4_0_GetNandEraseCount|Obsoleted_4_0_GetNandEraseCount]]
| Stubbed, this returns an error.
|-
| 0x086A0082
| [[4.0.0-7]]
| [[FS:ReadNandReport|ReadNandReport]]
| None
|-
| 0x086B00C2
|?
|SetOtherSaveDataSecureValue
| 00121004
|-
| 0x086C00C2
|?
|GetOtherSaveDataSecureValue
| 00121004
|-
| 0x086D0040
|?
|?
| 00020004
|-
| 0x086E00C0
|Related to Secure Value? Used in Pokemon Sun/Moon.
|SetThisSaveDataSecureValue
|None?
|-
| 0x086F0040
|Related to Secure Value? Used in Pokemon Sun/Moon.
|GetThisSaveDataSecureValue
| 0xE
|-
| 0x087000C2
|?
|?
|None?
|-
| 0x08710100
|?
|?
| 0xC
|-
| 0x087201C0
|?
|?
| 00080004
|-
| 0x087300C0
|?
|?
| 00080004
|-
| 0x08740000
|?
|?
| 00080004
|-
| 0x08750140
|?
|?
|None?
|-
| 0x087600C0
|?
|?
|None?
|-
| 0x08770100
|?
|?
|?
|-
| 0x087800C0
|?
|?
|?
|-
| 0x087900C2
| ?
| Same as GetLegacyBannerData, except for the last parameter this passes u8 value 0x1 instead of 0x0, for the FSPXI command.
| 0x00101015
|-
| 0x087A0180
| [[9.6.0-24|9.6.0-X]]
| [[FS:AddSeed|AddSeed]]
| 0x00200000
|-
| 0x087B0080
| [[9.6.0-24|9.6.0-X]]
| [[FS:GetSeed|GetSeed]]
| 0x00200000
|-
| 0x087C....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x087D0000
| [[9.6.0-24|9.6.0-X]]
| GetNumSeeds. Writes the number of seeds to cmdreply[2]
| 0x00200000
|-
| 0x087E0042
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>. Writes a list of titleIDs to the outbuf, this is for titles with content-lock-seed(s) stored in SEEDDB. (u32 total_titleids_probably, ((Size<<4) <nowiki>|</nowiki> 12), outbufptr)
| 0x00200000
|-
| 0x087F....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x0880....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0881....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0882....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x08830000
| [[9.6.0-24|9.6.0-X]]
| Writes an output value to cmdreply[2].
| 0x00200000
|-
| 0x08840042
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0885....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x088600C0
| [[11.1.0-34|11.1.0-X]]
| [[FS:CheckUpdatedDat|CheckUpdatedDat]]
| 0x00080000
|}

Note: The question marks from Dummy1 to GetSpecialFileSize on the "available since system version" field are mainly there because I think that most of these are necessary for the main system to function, so theoretically that would mean that since the creation of the 3DS these were available, or since launch if that makes more sense. But because of the peculiar nature of some of the functions, they will remain question marks until they can be confirmed 100%.

When access rights are required for a command, at least one of the bits in the process access info specified in the above table for the command must be set. Error 0xD9004676 is returned when a process attempts to use a command which it doesn't have access rights for the command. The exheader access info field is all zero's for most applications. Note that the permissions listed in the above table is for system-version v2.x, therefore permission bit(s) added with newer FIRM may be missing from this.

Each session for fs:USER has separate permissions, initially these are set to all zero's for new fs:USER sessions. The permissions/etc for fs:USER sessions are initialized via [[FS:Initialize]](loaded from the user process exheader).

{{Anchor|FSLDR}}{{Anchor|fs:LDR}}
== Filesystem service "fs:LDR" ==
This service is identical to fs:USER, except [[FS:OpenArchive]] archive 0x2345678E can only be accessed with fs:LDR.

{{Anchor|FSReg}}{{Anchor|FSREG}}{{Anchor|fs:REG}}
== ProgramRegistry service "fs:REG" ==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| [[FSReg:Dummy1|Dummy1]]
|-
| 0x040103C0
| [[FSReg:Register|Register]]
|-
| 0x04020040
| [[FSReg:Unregister|Unregister]]
|-
| 0x040300C0
| [[FSReg:GetProgramInfo|GetProgramInfo]]
|-
| 0x04040100
| [[FSReg:LoadProgram|LoadProgram]]
|-
| 0x04050080
| [[FSReg:UnloadProgram|UnloadProgram]]
|-
| 0x04060080
| [[FSReg:CheckHostLoadId|CheckHostLoadId]]
|}

Only two sessions can be opened for this service at a time, hence no other processes can use this due to [[Process_Manager_Services|pm-module]] and [[Loader_Services|loader]] using this.

=File and directory access=
==Files==
File session handles obtained via [[FS:OpenFile]] and [[FS:OpenFileDirectly]] can be used to access files through a service-like interface, despite not being an actual service registered using [[SRV:RegisterService]]. To use this service-like interface, simply call the SendSyncRequest SVC with a file session handle, using the IPC buffer in thread-local storage for parameters and responses, just like you would with a proper service.

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| [[FSFile:Dummy1|Dummy1]]
|-
| 0x040100C4
| [[FSFile:Control|Control]]
|-
| 0x08010100
| [[FSFile:OpenSubFile|OpenSubFile]]
|-
| 0x080200C2
| [[FSFile:Read|Read]]
|-
| 0x08030102
| [[FSFile:Write|Write]]
|-
| 0x08040000
| [[FSFile:GetSize|GetSize]]
|-
| 0x08050080
| [[FSFile:SetSize|SetSize]]
|-
| 0x08060000
| [[FSFile:GetAttributes|GetAttributes]]
|-
| 0x08070040
| [[FSFile:SetAttributes|SetAttributes]]
|-
| 0x08080000
| [[FSFile:Close|Close]]
|-
| 0x08090000
| [[FSFile:Flush|Flush]]
|-
| 0x080A0040
| [[FSFile:SetPriority|SetPriority]]
|-
| 0x080B0000
| [[FSFile:GetPriority|GetPriority]]
|-
| 0x080C0000
| [[FSFile:OpenLinkFile|OpenLinkFile]]
|-
| 0x0C010100
| [[FSFile:GetAvailable|GetAvailable]]
|}

==Directories==
Directory session handles obtained via [[FS:OpenDirectory]] are usable via a service-like interface, following the exact same procedure described above for file sessions.
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x000100C6
| [[1.0.0-0]]
| [[FSDir:Dummy1|Dummy1]]
|-
| 0x040100C4
| [[1.0.0-0]]
| [[FSDir:Control|Control]]
|-
| 0x08010042
| [[1.0.0-0]]
| [[FSDir:Read|Read]]
|-
| 0x08020000
| [[1.0.0-0]]
| [[FSDir:Close|Close]]
|-
| 0x08030040
| ?
| [[FSDir:SetPriority|SetPriority]]
|-
| 0x08040000
| ?
| [[FSDir:GetPriority|GetPriority]]
|}

= Archives =
{| class="wikitable" border="1"
|-
! ArchiveId
! Description
! Accessible via [[Filesystem_services|FS]]
! Accessible via [[Filesystem_services_PXI|FSPXI]]
! Only accessible by Process9 internally
! Requires binary [[FS:OpenFile|Lowpath]]
! Required exheader FS access info bitmask
|-
| 0x00000003
| SelfNCCH (including [[#RomFS|RomFS]])
| Yes
| No
| No
| No
| None
|-
| 0x00000004
| SaveData (the saveID/mediatype for this is loaded from data originally from the user process' exheader)
| Yes
| No
| No
| No
| None
|-
| 0x00000006
| ExtSaveData
| Yes
| No
| No
| Yes
| 0x100D, when the input extdataID isn't listed in the exheader.
|-
| 0x00000007
| Shared ExtSaveData
| Yes
| No
| No
| Yes
| None
|-
| 0x00000008
| SystemSaveData
| Yes
| No
| No
| Yes
| 0x4, when the input saveID doesn't match the exheader system-saveID.
|-
| 0x00000009
| SDMC
| Yes
| Yes
| No
| No
| 0x8E
|-
| 0x0000000A
| SDMC Write-Only
| Yes
| No
| No
| No
| 0x808E
|-
| 0x12345678
| ExtSaveData for BOSS
| Yes
| No
| No
| Yes
| 0x44
|-
| 0x12345679
| CARD SPI FS
| Yes
| Yes
| No
| No
| 0x16
|-
| 0x1234567B
| ExtSaveData, and ExtSaveData for BOSS
| No
| Yes
| No
| Yes
|
|-
| 0x1234567C
| SystemSaveData
| No
| Yes
| No
| Yes
|
|-
| 0x1234567D
| NAND RW
| Yes
| Yes
| No
| No
| 0x800
|-
| 0x1234567E
| NAND RO
| Yes
| Yes
| No
| No
| 0x200
|-
| 0x1234567F
| NAND RO Write FS
| No
| Yes
| No
| No
| ?
|-
| 0x12345680
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x12345681
| Unknown. Accessed by FS service.
| ?
| ?
| No
| ?
| ?
|-
| 0x12345682
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x2345678A
| Used for accessing general NCCH data. With FSPXI this also allows savedata access.
| Yes
| Yes
| No
| Yes
| 0x1005
|-
| 0x2345678B
| ?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678C
| Used internally to access [[Title_Database|/dbs]] files?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678D
| ?
| No
| No
| Yes
| No
|
|-
| 0x2345678E
| FSPXI: Similar to archive 0x2345678A. For fs:LDR(used by the "loader" FIRM ARM11-process), only ExeFS. Not accessible with fs:USER.
| Yes
| Yes
| No
| Yes
| None, see description.
|-
| 0x567890AB
| NAND CTR FS
| No
| Yes
| No
| No
| ?
|-
| 0x567890AC
| TWL PHOTO
| Yes
| Yes
| No
| No
| ?
|-
| 0x567890AD
| TWLS (DSi Sound stores recordings here). This is mapped to the FAT12 image stored in the file at [[Twln/shared2/0000]].
| No
| Yes
| No
| No
| ?
|-
| 0x567890AE
| NAND TWL FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890AF
| NAND W FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890B0
| ?
| No
| Yes
| No
| No
|
|-
| 0x567890B1
| Gamecard SaveData (for check). This is a wrapper for UserSaveDataForCheck: the OpenArchive code for that is called with archive-lowpath TID=0/mediatype=2(gamecard).
| Yes
| No
| No
| No
| 0x6
|-
| 0x567890B2
| UserSaveData (for check). This is the same as the regular SaveData archive, except with this the savedata ID and mediatype is loaded from the input archive lowpath.
| Yes
| No
| No
| Yes
| 0x6
|-
| 0x567890B4
| Similar to 0x567890B2 but can only access Accessible Save specified in [[NCCH/Extended_Header#Storage_Info|exheader]]?
| Yes
| No
| No
| Yes
| ?
|}

Archives listed as not requiring a binary lowpath, use lowpath type [[FS:OpenFile|empty]].

The above permission bitmasks are from v2.x, see the above Services section for how these are handled.

Archives CTR NAND, NAND RO Write FS, TWL NAND, NAND W FS, and CARD SPI FS require the corresponding process exheader access control mount flag to be set, in the exheader for any of the currently running ARM11 processes, for [[Filesystem_services_PXI|FSPXI]]. The access rights checked by [[Filesystem services|FS]] module for archive mounting with fs:USER, are stored in the process' exheader accessinfo.

The CARDSPI archive allows access to the gamecard CARD1 raw savedata flash(aka "cardspi:/" in [[FIRM|Process9]]), the file lowpath must be WCHAR "/". The "NAND W FS" archive allows access to the raw NAND image(aka "wnand:/" in Process9), the file lowpath must be WCHAR "/".

= Filenames and Paths =
{{Anchor|PathType}} PathType:
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| -1
| Returned internally by Process9, when errors occur it seems(in particular when no nul-terminator was found in the input path). The data ptr is set to NULL.
|-
| 0x0
| INVALID - Specifies an invalid path
|-
| 0x1
| EMPTY - Specifies an empty path
|-
| 0x2
| BINARY - Non-text based path. Meaning is per-archive
|-
| 0x3
| ASCII - Text-based path with 7-bit ASCII characters padded to 8-bits each (signed char)
|-
| 0x4
| UTF16 - Text-based path with UTF-16 characters
|}

In IPC requests, sizes of ASCII and UTF16 paths must include space for the null-terminator.

== Binary LowPath ==
The format of the data that a binary LowPath points to is custom per archive.

=== SelfNCCH File Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Type:
* 0x0: RomFS
* 0x1: error 0xD9004676
* 0x2: ExeFS
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module crashes on this
* 0x5: Update RomFS?
|-
| 1-2
| File name for ExeFS ("icon"/"banner"/"logo"). ".code" is not allowed
|}

Note that ExeFS files only support reading from offset=0 and with size=file_size.

=== SystemSaveData Archive Path Data Format ===
==== FS ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be zero for NAND)
|-
| 1
| saveid
|}
The file/directory lowpath is a text lowpath in the [[Savegames|savegame]] filesystem.

==== FSPXI ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| u8 [[Mediatypes|Mediatype]] (must be zero for NAND)
|}
The file lowpath is a binary lowpath containing the u64 saveid, however the high word of the saveid is always zero. The mounted file is the cleartext savegame image. Up to 32 SystemSaveData image files can be opened under a single mounted FSPXI archive.

=== UserSaveDataForCheck Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be non-zero)
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
The file/directory lowpath for this FS archive is a text path in the [[Savegames|savegame]] filesystem.

=== 0x567890B4 Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| <code><nowiki>Lower_word_saveid >> 8</nowiki></code> ?
|-
| 2
| Unknown. Game calculate this using formula <code><nowiki>0xFFFFFF00 | unknown_b</nowiki></code>
|}

=== ExtSaveData Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
For FS, the file/directory lowpath is a text path in the [[extdata]] filesystem. For FSPXI, the file lowpath is a text path relative to the "/extdata/<ExtdataIDHigh>/<ExtdataIDLow>" directory on SD/NAND, for the cleartext extdata image to mount.

=== 0x2345678A Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Lower word programID
|-
| 1
| Upper word programID
|-
| 2
| ([[Mediatypes|Mediatype]] & 0xFF) | (uninitialized_data? & 0xFFFFFF00)
|-
| 3
| Number of something? Hardcoded per-archive, 0 for ExeFS, 200 for area:, 100 for rate:, 40 for eula:, etc.
|}

File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| 0 for NCCH data, 1 for savedata. The latter is only valid for FSPXI. Value 2 is allowed via archive 0x3, it's unknown what this is.
|-
| 1
| TMD content index / NCSD partition index.
|-
| 2
| Type: 0=romfs(0 for non-NCCH as well), 1=exefs ".code"(?), 2=exefs "icon"/"banner"/"logo", 3=unknown, 4=unknown, 5=unknown.
|-
| 3-4
| Filename for ExeFS.
|}

The 0x14-byte lowpath is all-zero for accessing the title's main RomFS.

=== [[RomFS]] ===

Archives 0x3 and 0x2345678E both allow for accessing the [[RomFS#Level_3_Format|level-3 IVFC images]] for RomFS access. The main CXI RomFS is accessible via an all-zero 0xc-byte binary file-lowpath. The update RomFS can be accessed with the first u32 in the binary file-lowpath being set to 0x5. The user must handle parsing the filesystem used in the exposed image itself.

With FSPXI the returned data for RomFS is the entire RomFS section from the NCCH, starting at the IVFC header.

The 0x3 archive is an interface for the 0x2345678E archive with the current process programID+mediatype. The file lowpath is 3-words. These words are written to 0x2345678E-archive file_lowpath+0, with the rest of that lowpath set to all-zero(lowpath is different from archive 0x2345678A). File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| See above. The only values which FS-module doesn't allow to be used here are:
* 0x1: Error 0xE0E046BE.
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module executes svcBreak when using this.
|-
| 1-2
| See above. Not validated by FS-module.
|}

=SEEDDB=
With [[9.6.0-24|9.6.0-X]] new [[System_SaveData]] with saveID 0001000F was added, this seems to be handled by FS-module itself, probably via the new service-cmds added to fsuser. [[Home Menu]] and [[NIM_Services|NIM]] module have access to those commands.

The SEEDDB savedata contains the title-unique seed-data used for the new [[NCCH]] keyY generation added with FIRM [[9.6.0-24|9.6.0-X]].

= Common Types =
== MediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| NAND
|-
| 1
| SD
|-
| 2
| Game Card
|}

== SystemMediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| CTR NAND
|-
| 1
| TWL NAND
|-
| 2
| SD
|-
| 3
| TWL Photo
|}

== OpenFlags ==
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0
| Read
|-
| 1
| Write
|-
| 2
| Create
|}

== Attributes ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Is Directory
|-
| 0x1
| 0x1
| Is Hidden
|-
| 0x2
| 0x1
| Is Archive
|-
| 0x3
| 0x1
| Is Read-Only
|}

== WriteOption ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Flush
|-
| 0x1
| 0x1
| Update Time Stamp
|-
| 0x2
| 0x1
| Reserved
|-
| 0x3
| 0x1
| Reserved
|}

== DirectoryEntry ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x20C
| UTF-16 Entry Name
|-
| 0x20C
| 0xA
| 8.3 short filename name
|-
| 0x216
| 0x4
| 8.3 short filename extension
|-
| 0x21A
| 0x1
| Always 1
|-
| 0x21B
| 0x1
| Reserved
|-
| 0x21C
| 0x4
| [[Filesystem_services#Attributes|Attributes]]
|-
| 0x220
| 0x8
| Entry Size
|}

== ArchiveResource ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Sector byte-size
|-
| 0x4
| 0x4
| Cluster byte-size
|-
| 0x8
| 0x4
| Partition capacity in clusters
|-
| 0xC
| 0x4
| Available free space in clusters
|}

== ProgramInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| Program ID
|-
| 0x8
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x9
| 0x7
| Padding
|}

== ProductInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Product Code
|-
| 0x10
| 0x2
| Company Code
|-
| 0x12
| 0x2
| Remaster Version
|}

== IntegrityVerificationSeed ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| AES-CBC MAC over a SHA256 hash, which hashes the first 0x110-bytes of the cleartext SEED.
|-
| 0x10
| 0x120
| The [[nand/private/movable.sed]], encrypted with AES-CBC using the above MAC for the counter.
|}

== ExtSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x8
| Save ID
|-
| 0xC
| 0x4
| Reserved
|}

== SystemSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x4
| Save ID
|}

== SecureValueSlot ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1000
| SD Application
|}

== CardSpiBaudRate ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 512KHz
|-
| 0x1
| 1MHz
|-
| 0x2
| 2MHz
|-
| 0x3
| 4MHz
|-
| 0x4
| 8MHz
|-
| 0x5
| 16MHz
|}

== CardSpiBusMode ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 1-bit
|-
| 0x1
| 4-bit
|}

== SpecialContentType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1
| Update
|-
| 0x2
| Manual
|-
| 0x3
| DLP Child
|}

== DeviceMoveContext ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| IVs
|-
| 0x10
| 0x10
| Encrypt Parameter
|}

=Errors=
See [[Filesystem_services_PXI]].

[[Category:Services]]

OTP Registers

2024-11-21T12:18:48Z

PabloMK7: Wrong size fixed

This region (0x10012000-0x10012100) is used as persistent storage on SoC and for passing the TWL console ID around (0x10012100-0x10012108).

== Overview ==

Console-unique keys are derived from here. Access to this region is disabled once the ARM9 writes 0x2 to [[CONFIG|REG_SYSPROT9]].

This is the console-unique data store, including [[CTCert]] etc, that ends up in ITCM at 0x01FFB800. After decryption, the first 0x90-bytes of plaintext are copied to 0x01FFB800 if hash verification passes. Refer to [[Memory_layout#ARM9_ITCM]] for what is contained in the decrypted OTP.

On [[FIRM]] versions prior to [[3.0.0-6|3.0.0-X]], this region was left unprotected. On versions since [[3.0.0-6|3.0.0-X]], this has been fixed, and the region disable is now done by Kernel9 after doing console-unique TWL keyinit, by setting bit 1 of [[CONFIG|REG_SYSPROT9]]. However, with the [[New_3DS]] FIRM ARM9 binary this is now done in the [[FIRM]] ARM9 binary loader, which also uses the 0x10012000 region for New 3DS key generation.

On development units ([[CONFIG|UNITINFO]] != 0) ARM9 uses the first 8-bytes from 0x10012000 for the TWL Console ID. This region doesn't seem to be used by NATIVE_FIRM on retail at all, besides New3DS key-generation in the [[FIRM|ARM9-loader]].

Normally [[Bootloader|Boot9]] will pass plaintext_otp+0x90 to the AES keyinit function, but when hash verification fails it will pass 0x10012000(otp+0) instead.

== Sections ==

{| class="wikitable" border="1"
! Offset
! Size
! Description
|-
| 0x0
| 0x100
| Console-unique data encrypted with AES-CBC. The normalkey and IV are stored in Boot9(retail/devunit have seperate normalkey+IV for this). The last 0x20-bytes of plaintext are a SHA256 hash over the first 0xE0-bytes of plaintext.
|-
| 0x100
| 0x8
| Before writing REG_SYSPROT9 bit1, the ARM9 copies the 8-byte TWL Console ID here. This sets the registers at 0x4004D00 for ARM7.
|}

== Plaintext OTP ==
{| class="wikitable" border="1"
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| This is always 0xDEADB00F.
|-
| 0x4
| 0x4
| This is the u32 DeviceId.
|-
| 0x8
| 0x10
| This is the fall-back keyY used for movable.sed keyY when movable.sed doesn't exist in NAND(the first two words here are used on retail for generating console-unique TWL keydata/etc). This is also used for "LocalFriendCodeSeed", etc.
|-
| 0x18
| 0x1
| OTP version
|-
| 0x19
| 0x1
| This determines if the OTP is for a dev system; it indicates the [[CTCert]] issuer type: 0 = retail "Nintendo CA - G3_NintendoCTR2prod", non-zero = dev "Nintendo CA - G3_NintendoCTR2dev".
|-
| 0x1A
| 0x6
| Manufacturing date (of the SoC?). Usually month(s) before the dates in the logs stored in [[Flash_Filesystem|TWLNAND]]. Each byte is one field: year, month, day, hour, minute, second. Year is encoded as year-1900 so that it fits in one byte. This order matches up with the layout of a <code>struct tm</code>.
|-
| 0x20
| 0x4
| This is the CTCert expiry time as UNIX timestamp, this is specified in big endian if the OTP version is <5.
|-
| 0x24
| 0x20
| This is the CTCert ECDSA privk.
|-
| 0x44
| 0x3C
| This is the CTCert ECDSA signature (sect233r1?/SHA-256).
|-
| 0x80
| 0x10
| This is all-zero.
|-
| 0x90
| 0x50
| Used by Boot9 for generating the console-unique AES [[AES_Registers|keyXs]]. However, due to a bug(?) in Boot9, only the first 0x1C-bytes here actually affect console-unique key generation. The rest of the data is used for hashing, but that output hash only gets overwritten without being used afterwards.

Note that the size passed to the Boot9 keyinit code for console-unique-buffer-size is 0x70, hence this includes the below OTP hash.
|-
| 0xE0
| 0x20
| SHA256 hash over the previous 0xE0-bytes.
|}

ACU:GetWifiStatus

2023-11-14T16:54:54Z

PabloMK7:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x000D0000]
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2
| Output connection type: 0 = none, 1 = Slot 1, 2 = Slot 2, 4 = Slot 3
|}

=Description=
This obtains whether the system is using wifi(Internet/local). When the hardware wifi switch is set to off, or when the system is connecting to the Internet, this returns error-code 0xE0A09D2E.

NIM Services

2023-11-12T11:46:33Z

PabloMK7:

[[Category:Services]]
= NIM updater service "nim:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| [[NIMU:StartNetworkUpdate|StartNetworkUpdate]]
|-
| 0x00020000
| [[NIMU:GetProgress|GetProgress]]
|-
| 0x00030000
| [[NIMU:Cancel|Cancel]]
|-
| 0x00040000
| [[NIMU:CommitSystemTitles|CommitSystemTitles]]
|-
| 0x00050000
| [[NIMU:GetBackgroundEventForMenu|GetBackgroundEventForMenu]]
|-
| 0x00060000
| [[NIMU:GetBackgroundEventForNews|GetBackgroundEventForNews]]
|-
| 0x00070000
| [[NIMU:FormatSaveData|FormatSaveData]]
|-
| 0x00080000
| [[NIMU:GetCustomerSupportCode|GetCustomerSupportCode]]
|-
| 0x00090000
| [[NIMU:IsCommittableAllSystemTitles|IsCommittableAllSystemTitles]]
|-
| 0x000A0000
| [[NIMU:GetBackgroundProgress|GetBackgroundProgress]]
|-
| 0x000B0000
| [[NIMU:GetSavedHash|GetSavedHash]]
|-
| 0x000C0082
| [[NIMU:UnregisterTask|UnregisterTask]]
|-
| 0x000D0080
| [[NIMU:IsRegistered|IsRegistered]]
|-
| 0x000E0080
| [[NIMU:FindTaskInfo|FindTaskInfo]]
|-
| 0x000F0042
| [[NIMU:GetTaskInfos|GetTaskInfos]]
|-
| 0x00100000
| [[NIMU:DeleteUnmanagedContexts|DeleteUnmanagedContexts]]
|-
| 0x00110000
| [[NIMU:UpdateAutoTitleDownloadTasksAsync|UpdateAutoTitleDownloadTasksAsync]]
|-
| 0x00120000
| [[NIMU:StartPendingAutoTitleDownloadTasksAsync|StartPendingAutoTitleDownloadTasksAsync]]
|-
| 0x00130000
| [[NIMU:GetAsyncResult|GetAsyncResult]]
|-
| 0x00140000
| [[NIMU:CancelAsyncCall|CancelAsyncCall]]
|-
| 0x00150000
| [[NIMU:IsPendingAutoTitleDownloadTasks|IsPendingAutoTitleDownloadTasks]]
|-
| 0x00160000
| [[NIMU:GetNumAutoTitleDownloadTasks|GetNumAutoTitleDownloadTasks]]
|-
| 0x00170042
| [[NIMU:GetAutoTitleDownloadTaskInfos|GetAutoTitleDownloadTaskInfos]]
|-
| 0x00180080
| [[NIMU:CancelAutoTitleDownloadTask|CancelAutoTitleDownloadTask]]
|-
| 0x00190002
| [[NIMU:SetAutoDbgDat|SetAutoDbgDat]]
|-
| 0x001A0002
| [[NIMU:GetAutoDbgDat|GetAutoDbgDat]]
|-
| 0x001B0042
| [[NIMU:SetDbgTasks|SetDbgTasks]]
|-
| 0x001C0042
| [[NIMU:GetDbgTasks|GetDbgTasks]]
|-
| 0x001D0000
| [[NIMU:DeleteDbgData|DeleteDbgData]]
|-
| 0x001E0042
| [[NIMU:SetTslXml|SetTslXml]]
|-
| 0x001F0000
| [[NIMU:GetTslXmlSize|GetTslXmlSize]]
|-
| 0x00200042
| [[NIMU:GetTslXml|GetTslXml]]
|-
| 0x00210000
| [[NIMU:DeleteTslXml|DeleteTslXml]]
|-
| 0x00220042
| [[NIMU:SetDtlXml|SetDtlXml]]
|-
| 0x00230000
| [[NIMU:GetDtlXmlSize|GetDtlXmlSize]]
|-
| 0x00240042
| [[NIMU:GetDtlXml|GetDtlXml]]
|-
| 0x00250000
| [[NIMU:UpdateAccountStatus|UpdateAccountStatus]]
|-
| 0x00260180
| [[NIMU:StartTitleDownload|StartTitleDownload]]
|-
| 0x00270000
| [[NIMU:StopTitleDownload|StopTitleDownload]]
|-
| 0x00280000
| [[NIMU:GetTitleDownloadProgress|GetTitleDownloadProgress]]
|-
| 0x00290246
| [[NIMU:RegisterTask|RegisterTask]]
|-
| 0x002A0000
| [[NIMU:IsSystemUpdateAvailable|IsSystemUpdateAvailable]]
|-
| 0x002B0000
| ? (Response: 0 = 0x002B0040, 1 = Result Code)
|-
| 0x002C0000
| [[NIMU:UpdateTickets|UpdateTickets]]
|-
| 0x002D00C0
| [[NIMU:DownloadTitleSeedAsync|DownloadTitleSeedAsync]]
|-
| 0x002E0000
| [[NIMU:DownloadMissingTitleSeedsAsync|DownloadMissingTitleSeedsAsync]]
|-
|}

= NIM shop service "nim:s" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010200
| [[NIMS:StartDownloadSimple|StartDownloadSimple]]
|-
| 0x00020000
| [[NIMS:CancelDownload|CancelDownload]]
|-
| 0x00030000
| [[NIMS:GetProgress|GetProgress]]
|-
| 0x00050082
| [[NIMS:UnregisterTask|UnregisterTask]]
|-
| 0x00060080
| [[NIMS:IsTaskRegistered|IsTaskRegistered]]
|-
| 0x00070080
| GetTaskInfoFromTitleId
|-
| 0x00080042
| GetTaskList
|-
| 0x0009xxxx
| Returns 0xE0C0D3F4, not implemented.
|-
| 0x000A0000
| [[NIMS:CheckSysupdateAvailableSOAP|CheckSysupdateAvailableSOAP]]
|-
| 0x000B0084
| [[NIMS:SetAttribute|SetAttribute]]
|-
| 0x000C0082
| SetAttributeInt32
|-
| 0x000D0082
| Connect
|-
| 0x000E0000
| UnregisterSOAP, aka soap account delete
|-
| 0x000F0042
| SetCountrySOAP, change effective country registry
|-
| 0x00100080
| Returns 0xE0C0D3F4, not implemented, reads for an int64 in IPC.
|-
| 0x001100C4
| Returns 0xE0C0D3F4, not implemented, reads for IPC parameters.
|-
| 0x00120084
| SetExternalAccountSOAP
|-
| 0x00130042
| DeleteExternalAccountSOAP
|-
| 0x00140000
| DeleteSavedCardSOAP
|-
| 0x00150082
| ListCashReplenishAmountsSOAP
|-
| 0x0016020A
| [[NIMS:ListTitles|ListTitles]]
|-
| 0x0017020A
| ListContentSetsExSOAP
|-
| 0x0018020A
| ListItemsSOAP
|-
| 0x0019028C
| ListContentSetGroupsSOAP
|-
| 0x001E0104
| GetTaxesSOAP
|-
| 0x001F0106
| GetTaxLocationSOAP
|-
| 0x00220080
| AccountDeleteTitleETicketsSOAP. The SOAP request is sent only after the ticket for the specified titleID has been successfully deleted.
|-
| 0x00290000
| [[NIMS:AccountCheckBalanceSOAP|AccountCheckBalanceSOAP]]
|-
| 0x002D0042
| [[NIMS:DownloadTickets|DownloadTickets]]
|-
| 0x0036xxxx
| Returns 0xE0C0D3F4, not implemented.
|-
| 0x003C0002
| [[NIMS:RegisterSelf|RegisterSelf]]
|-
| 0x003F0000
| GetInitializeResult. Checks whether nim is properly initialized or not. If it is not, the result code returned is non-zero.
|-
| 0x00420240
| [[NIMS:StartDownload|StartDownload]]
|-
| 0x00550246
| [[NIMS:RegisterTask|RegisterTask]]
|-
| 0x00570082
| [[NIMS:ConnectNoTicketDownload|ConnectNoTicketDownload]]
|-
| 0x005B0000
| DeleteInitAccSavedData
|-
| 0x005C0000
| DeleteAccountSavedData
|-
| 0x005F00C0
| DownloadTitleSeed
|}

= NIM server service "nim:aoc" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00030042
| SetApplicationId
|-
| 0x00040042
| SetTin
|-
| 0x000902D0
| ListContentSetsEx
|-
| 0x00180000
| GetBalance
|-
| 0x001D0000
| GetCustomerSupportCode
|-
| 0x00210000
| Initialize
|-
| 0x00240282
| CalculateContentsRequiredSize
|-
| 0x00250000
| RefreshServerTime
|}

= NIM service "nim:ndm" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| GetDaemonEventHandle
|-
| 0x00020000
| Does nothing, always returns 0
|-
| 0x00030000
| SetDaemonToWorkingState
|-
| 0x00040040
| SetDaemonToSuspendedState
|-
| 0x00050000
| GetDaemonState
|-
|}

= kagiya server =
The nim system module communicates with a server called kagiya (kagiya-ctr.cdn.nintendo.net or kagiya-dev-ctr.cdn.nintendo.net for development units). It provides the 9.6 crypto seed in binary form for any given title ID under (HTTPS) kagiya-ctr.cdn.nintendo.net/title/0x%16llx/ext_key?country=%s, where %16llx is the title ID and %s is a country code as used in the [[EShop|eShop]].

=New3DS=
NIM module only uses [[PTMSYSM:CheckNew3DS|CheckNew3DS]] for determining what heap sizes to use, in two functions. One is for the size of the 0x08000000 vmem heap, the other is probably for some buffer allocated on that heap. The New3DS version of these sizes are 0x1C000-bytes larger than the Old3DS sizes here.

=HTTPS requests=

==Trusted RootCAs==
During startup NIM-module creates two RootCertChains with [[HTTP_Services|HTTPC]]. Both of these only contain the same [[HTTPC:RootCertChainAddDefaultCert|default]] cert with ID 0x3. The first RootCertChain is used with NetUpdateSOAP. Requests such as the "notifications.json" page don't use these RootCertChains(in this case just [[HTTPC:AddDefaultCert|default]] certID 0xB is used).

==SOAP==

===NetUpdateSOAP===
There are exactly 3 types of network SOAP requests used with [https://nus.c.shop.nintendowifi.net/nus/services/NetUpdateSOAP NetUpdateSOAP] by NIM module, described below. This URL contained in NIM module itself is only used with GetSystemTitleHash. The other requests use an identical URL loaded from an ECommerceSOAP response instead.

See also [https://github.com/yellows8/ninupdates here].

====GetSystemUpdate====
Returns the current sysupdate title-listing. This also contains the SystemTitleHash returned by GetSystemTitleHash.

====GetSystemTitleHash====
Returns the current SystemTitleHash for the current sysupdate title-listing.

====GetSystemCommonETicket====
Returns the Base64-encoded cetk for each specified TitleId entry.

This is only used when installing new titles. This means with CDN system-updates, tickets are never installed except when a title is being installed for the first time. For example, a system on the latest system-version that was only ever updated via CDN has the same NATIVE_FIRM ticket installed from the factory.

=Sysupdate checking process=
This section describes the process used when checking whether a sysupdate is required.

First the GetSystemTitleHash SOAP request is done. Then the SystemTitleHash in savedata hash.dat is compared with the received one. If they match and the SystemTitleHash flag is set to value 0x03, it will immediately return that no sysupdate is required. Otherwise it will start the GetSystemUpdate SOAP request handling.

The GetSystemUpdate SOAP request contains a titlelist of all NAND system-titles. For GetSystemUpdate response parsing, it compares each SOAP title_entry with the NAND system titlelist. If a SOAP titleID isn't found in the NAND titlelist, this means NAND is missing a new title and hence a sysupdate is required for installing that title. If a NAND title_entry-version is less than the SOAP title_entry-version, this means the title needs updated and hence a sysupdate is required.

At least one <TitleVersion> entry with valid data in the GetSystemUpdate response is required.

The titleIDs sent in the GetSystemUpdate SOAP request are decimal, while the titleIDs in the response are hex.

=NIM [[System_SaveData]]=
==hash.dat==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x60
| 0x1
| u8 flag used with the SystemTitleHash. 0x01 = latest sysupdate isn't installed as of last SOAP requests, 0x03 = latest sysupdate is installed as of last SOAP requests.
|-
| 0x61
| 0x21
| ASCII hex SystemTitleHash, including NUL-terminator. This is the latest SystemTitleHash which NIM module received from SOAP.
|}

=Types=

==SystemUpdateProgress==

{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x00
| 0x01
| [[#SystemUpdateState|System Update State]]
|-
| 0x01
| 0x03
| Padding
|-
| 0x04
| 0x04
| Last Operation Result Code
|-
| 0x08
| 0x08
| Current Title Downloaded Bytes
|-
| 0x10
| 0x08
| Current Title Total Bytes
|-
| 0x18
| 0x08
| Titles Downloaded
|-
| 0x20
| 0x08
| Titles Total
|}

==SystemUpdateState==

{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| Not Initialized
|-
| 1
| Starting System Update
|-
| 2
| Fetching System Hash and Account Status
|-
| 3
| Installing New Tickets
|-
| 4
| Installing Titles
|-
| 5
| Update Complete
|-
| 6
| Failed - System Updates Disabled (Dev Units Only)
|-
| 7
| ? (Only for background updates)
|-
| 8
| ? (Only for background updates)
|}

==TitleDownloadProgress==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x00
| 0x01
| [[#TitleDownloadState|Title Download State]]
|-
| 0x01
| 0x03
| Padding
|-
| 0x04
| 0x04
| Last Operation Result Code
|-
| 0x08
| 0x08
| Downloaded Bytes
|-
| 0x10
| 0x08
| Total Bytes
|}

==TitleDownloadState==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| Not Initialized
|-
| 1
| Starting Title Download
|-
| 2
| Downloading and Installing TMD
|-
| 3
| Committing TMD
|-
| 4
| Downloading and Installing Contents
|-
| 5
| Contents Installed
|-
| 6
| [[AM:CommitImportPrograms|Committing Titles]]
|-
| 7
| Finished
|-
| 8
| ? (Unknown error regarding title version?)
|-
| 9
| ? (Creating the .ctx file (or error doing so)?)
|-
| 10
| Background Download Failed
|}

==TitleDownloadConfig==

{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x00
| 0x08
| Title ID
|-
| 0x08
| 0x04
| Title version
|-
| 0x0C
| 0x04
| Unknown (always 0?)
|-
| 0x10
| 0x01
| Age Rating (for HOME Menu parental controls)
|-
| 0x11
| 0x01
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x12
| 0x02
| Padding
|-
| 0x14
| 0x04
| Unknown (always 0?)
|}

==BackgroundTitleDownloadConfig==

{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x000
| 0x018
| [[#TitleDownloadConfig|Title Download Config]]
|-
| 0x018
| 0x001
| Unknown
|-
| 0x019
| 0x001
| Unknown
|-
| 0x01A
| 0x006
| Padding
|-
| 0x020
| 0x008
| Requester Title ID
|-
| 0x028
| 0x090
| Title Name (UTF-16)
|-
| 0x0B8
| 0x002
| Title Name Forced NUL Terminator (always 0)
|-
| 0x0BA
| 0x048
| Developer Name (UTF-16)
|-
| 0x102
| 0x002
| Developer Name Forced NUL Terminator (always 0)
|}

==BackgroundTitleDownloadTaskInfo==

{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x000
| 0x104
| [[#BackgroundTitleDownloadConfig|Background Title Download Config]]
|-
| 0x104
| 0x004
| Padding
|-
| 0x108
| 0x018
| [[#TitleDownloadProgress|Title Download Progress]]
|}

==AutoTitleDownloadTaskInfo==

{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x000
| 0x008
| Task ID
|-
| 0x008
| 0x008
| Title ID
|-
| 0x010
| 0x004
| Title Version
|-
| 0x014
| 0x014
| Unknown
|-
| 0x028
| 0x008
| Required Storage Space
|-
| 0x030
| 0x004
| Last Operation Result code
|-
| 0x034
| 0x004
| Last Operation Customer Support Code
|-
| 0x038
| 0x090
| Title Name (UTF-16)
|-
| 0x0C8
| 0x002
| Title Name Forced NUL Terminator (always 0)
|-
| 0x0CA
| 0x048
| Developer Name (UTF-16)
|-
| 0x112
| 0x002
| Developer Name Forced NUL Terminator (always 0)
|-
| 0x114
| 0x024
| Unknown
|}

==InstallationMode==

{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| Initial Installation
|-
| 1
| Unknown
|-
| 2
| Unknown
|-
| 3
| Re-installation
|}

==Autodbg==

Despite this being for debug purposes, it's used in retail if present.

{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x000
| 0x004
| Debug flags
|-
| 0x004
| 0x004
| Number of debug tasks in dbgtasks.dat
|-
| 0x008
| 0x100
| Debug URL dst.xml override
|}

===Autodbg flag bits===

{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0
| Use the tasks stored in dbgtasks.dat
|-
| 1
| Use provided debug dtl.xml URL override
|-
| 2
| Disable the download of dtl.xml
|-
| 3
| Skip connecting to SOAP EC and download ETickets with a false success result during TSL processing
|-
| 4
| Fake assume always ticket is present during TSL task condition processing
|-
| 5
| Skip NPNS notification fetch for auto title downloads with a false success result
|}

=Error Results=

==NIM Results==

{| class="wikitable" border="1"
|-
! Result
! Description
|-
| 0xE0E0D001
| Non-null terminated string on IPC parameter for given length.
|-
| 0xD960D003
| SOAP EC/NUP manager internal error number translation of unhandled values or -4199.
|-
| 0xD960D004
| Unexpected/invalid state enums. (generic)
|-
| 0xC820D005
| Invalid state under one title install manager.
|-
| 0xD8A0D006
| Error state enum value. (generic)
|-
| 0xC920D008
| When content downloading, HTTP Status was not 200 or 206 when connecting, and when status is 206, the Content-Range values failed sanity check.
|-
| 0xC920D009
| Mismatch system title hash with server system title hash.
|-
| 0xC960D00C
| Failed to convert country enum value in CFG save block 0xB0000 to country ISO 3166-1 Alpha-2 code.
|-
| 0xC960D00D
| CFG didn't reply any serial number or dummy serial number "000000000000000" was given.
|-
| 0xC860D00E
| Max total size exceeded for system update pending titles. (128 MiB)
|-
| 0xC880D00F
| *to be filled*
|-
| 0xC8E0D011
| Bad condition, title id for purpose or size under one title install manager.
|-
| 0xC960D012
| Invalid .dat or less than expected size of buffer length read from .dat save files during raw data load.
|-
| 0xC960D013
| Daemon service is suspended.
|-
| 0xC8A0D014
| *to be filled*
|-
| 0xC960D015
| Version mismatch for reinstall condition.
|-
| 0xC960D016
| Used in a few contexts where length does not match expected or the limit. Example, seed data size from HTTP is not 16 bytes.
|-
| 0xC920D017
| SetIVSData will not perform, conditions are not adequate to set IVS. In Service Standby mode or not registered successfully in IAS.
|-
| 0xC920D019
| Certain EC connect flows disallowed to continue while IVS is waiting to be synced from servers. System Transfer has previously occurred and IVS is pending.
|-
| 0xC920D01A
| For nim:s IPC cmd id 0x40, IVS not flagged for synchronization on target console on EC connect after system transfer.
|-
| 0xC960D01B
| Failed to convert language enum value in CFG save block 0xA0002 to language ISO 639-1 code.
|-
| 0xE0E0D01C
| Invalid installation mode for some IPC contexts.
|-
| 0xE0C0D01E
| May be either:
* Trying to set autodbg or dbgtasks with too many tasks on nim:u IPC cmd ids 0x19 and 0x1B, respectively.
* Non debug ENVINFO when calling debug version of get balance nim:s IPC cmd id 0x56.
* A boolean parameter for nim:s IPC cmd id 0x58 was set false.
|-
| 0xD860D020
| May be either:
* Result translation of 0xC860D06E if returned by the early attributes filter handler.
* If the internal Work-only heap fails to initialize with buffer length lesser than 32 bytes. This buffer is given over IPC.
|-
| 0xC860D021
| Task manager has run out of task slots.
|-
| 0xC920D022
| Buffer size too small for ticket length on nim:aoc IPC cmd id 0x1B.
|-
| 0xD880D023
| When Account Id missing for nim:aoc IPC cmd id 0x1B and 0x20 or when Account Id or Token are missing for nim:s IPC cmd id 0x53.
|-
| 0xD860D024
| Failed to initialize Data Heap using buffer given over IPC.
|-
| 0xD920D025
| SOAP reply implied that Service Standby mode is enabled. Certain EC flows cancelled.
|-
| 0xC8A0D026
| May be either:
* Result translation, NIM ran into NPNS result 0xD8A15C06 or NIM result 0xD960D02B.
* System updates pending while trying to SOAP EC connect with ETicket download while processing auto downloads.
|-
| 0xC8A0D027
| This occurs under certain code paths.
<ol>
<li>Result translation of result error from:</li>
<ul><li>HTTP module</li></ul>
<ul><li>SSL module</li></ul>
<ul><li>NIM module if description is between 100 to 299 (inclusive), 200 descriptions to fit the reserved range of the SOAP manager internal error range of -4000 to -4199 </li></ul>
<li>Unexpected HTTP status, followed up also by generating error integer with 54400 + http status, result value used as a 005-xxxx error</li>
</ol>
|-
| 0xD960D028
| Generic XML parsing error. Not related to SOAP XML.
|-
| 0xD960D029
| XML processor stub function called. Not related to SOAP XML.
|-
| 0xD960D02A
| Generic XML data processing error: bad length or insufficient memory. Not related to SOAP XML.
|-
| 0xD960D02B
| Result translation of 0xD960D028.
|-
| 0xD960D02C
| Auto download programmed max task count exceeded trying to add more to list. (64)
|-
| 0xD960D02D
| tsl.xml or tsl.xml.tmp couldn't be opened. FS result translation of description between 100 and 179, inclusive.
|-
| 0xD960D02E
| During tsl.xml task condition check. Still unclear, type of task check
|-
| 0xD960D030
| During tsl.xml task condition check. Ticket missing for title when expected. Will not occur with autodbg flag bit 4 set.
|-
| 0xD960D031
| During tsl.xml task condition check. Title already installed when not overwrite mode.
|-
| 0xD960D032
| During tsl.xml task condition check. Task for title already exists with same or higher version in task.dat.
|-
| 0xD960D033
| During tsl.xml task condition check. Task for title already exists in task.dat.
|-
| 0xD8E0D034
| During tsl.xml task condition check. Unexpected task title type.
|-
| 0xD960D035
| During tsl.xml task condition check. Tsl.xml task will not be processed while max programmed maximum for tasks pending in task.dat is equal or exceeded. (10)
|-
| 0xD960D037
| Failed to load saved dtl.xml with result error of FS with description between 100 and 179, inclusive.
|-
| 0xD960D038
| During tsl.xml task condition check. Not enough space for target SDMC user title.
|-
| 0xD8A0D03A
| No valid NPNS X-Device-Token was available while trying to fetch it from CFG save block 0xF0006.
|-
| 0xD940D03B
| Selected tsl.xml task was cancelled with nim:u IPC cmd id 0x18.
|-
| 0xD960D03C
| Result translation for 0xD960D028 while trying to read XML. Not related to SOAP XML.
|-
| 0xD8A0D03D
| During tsl.xml task condition check. SDMC not inserted or non-writable for SDMC title. (bad media status)
|-
| 0xD960D03E
| During tsl.xml task condition check. Not enough space for target TWL user title.
|-
| 0xD940D03F
| NPNS notification url is not HTTPS.
|-
| 0xD940D040
| NIM ran into NPNS result 0xD8A15C07. Result translation.
|-
| 0xD860D041
| During tsl.xml task condition check. Pending task count of task.dat and installed SDMC user title count exceed programmed max. (300)
|-
| 0xD860D042
| During tsl.xml task condition check. Pending task count of task.dat and installed TWL user title count exceed programmed max. (40)
|-
| 0xD880D043
| HTTP 404 while fetching title crypto seed from kagiya.
|-
| 0xD880D044
| HTTP 503 while fetching title crypto seed from kagiya.
|-
| 0xC960D065
| SOAP EC/NUP manager internal error number translation of value -4001
|-
| 0xE0C0D066
| SOAP EC/NUP manager internal error number translation of value -4002
|-
| 0xE0E0D068
| SOAP EC/NUP manager internal error number translation of value -4004
|-
| 0xC860D069
| SOAP EC/NUP manager internal error number translation of value -4005
|-
| 0xC880D06A
| SOAP EC/NUP manager internal error number translation of value -4006
|-
| 0xC8A0D06B
| SOAP EC/NUP manager internal error number translation of value -4007
|-
| 0xC8A0D06C
| SOAP EC/NUP manager internal error number translation of value -4008
|-
| 0xC860D06E
| SOAP EC/NUP manager internal error number translation of value -4010
|-
| 0xC920D073
| SOAP EC/NUP manager internal error number translation of value -4015
|-
| 0xC900D075
| SOAP EC/NUP manager internal error number translation of value -4017
|-
| 0xC860D076
| SOAP EC/NUP manager internal error number translation of value -4018
|-
| 0xC920D077
| SOAP EC/NUP manager internal error number translation of value -4019
|-
| 0xC900D084
| SOAP EC/NUP manager internal error number translation of value -4032
|-
| 0xC900D085
| SOAP EC/NUP manager internal error number translation of value -4033
|-
| 0xC920D086
| SOAP EC/NUP manager internal error number translation of value -4034
|-
| 0xC920D08A
| SOAP EC/NUP manager internal error number translation of value -4038
|-
| 0xC900D08B
| SOAP EC/NUP manager internal error number translation of value -4039
|-
| 0xC920D08C
| SOAP EC/NUP manager internal error number translation of value -4040
|-
| 0xE0A0D08D
| SOAP EC/NUP manager internal error number translation of value -4041
|-
| 0xC920D08F
| SOAP EC/NUP manager internal error number translation of value -4043
|-
| 0xC920D095
| SOAP EC/NUP manager internal error number translation of value -4049
|-
| 0xE0E0D099
| SOAP EC/NUP manager internal error number translation of value -4053
|-
| 0xC900D09F
| SOAP EC/NUP manager internal error number translation of value -4059
|-
| 0xE100D0A0
| SOAP EC/NUP manager internal error number translation of value -4060
|-
| 0xE100D0A1
| SOAP EC/NUP manager internal error number translation of value -4061
|-
| 0xC920D0A4
| SOAP EC/NUP manager internal error number translation of value -4064
|-
| 0xC920D0A7
| SOAP EC/NUP manager internal error number translation of value -4067
|-
| 0xC920D0A8
| SOAP EC/NUP manager internal error number translation of value -4068
|-
| 0xE0A0D0A9
| SOAP EC/NUP manager internal error number translation of value -4069
|-
| 0xC920D0AD
| SOAP EC/NUP manager internal error number translation of value -4073
|-
| 0xC920D0B1
| SOAP EC/NUP manager internal error number translation of value -4077
|-
| 0xC920D0B3
| SOAP EC/NUP manager internal error number translation of value -4079
|-
| 0xC920D0B5
| SOAP EC/NUP manager internal error number translation of value -4081
|}

==NPNS Results==

NPNS has a module number for results, but no module exists, but can be at least in part found inside NIM.

{| class="wikitable" border="1"
|-
! Result
! Description
|-
| 0xC9215C00
| Result translation, HTTP result 0xD8A0A018.
|-
| 0xD8615C01
| Allocation error, insufficient memory.
|-
| 0xD8A15C02
| HTTP non 2xx, json message processing, default error code switch result error.
|-
| 0xD8A15C03
| JSON processing errors.
|-
| 0xD8A15C04
| Notifications array bigger than expected.
|-
| 0xD8A15C05
| HTTP Empty body response.
|-
| 0xD8A15C06
| HTTP non 2xx, json message processing, error code 1003 given in json body.
|-
| 0xD8A15C07
| HTTP non 2xx, json message processing, error code 1000 given in json body.
|-
| 0xD8A15C08
| HTTP non 2xx, json message processing, error code 1004 given in json body.
|}

==Other Results==

Any other result that is not given by other modules as a response, but found internally in NIM.

{| class="wikitable" border="1"
|-
! Result
! Module value
! Description
|-
| 0xD8600801
| Util (2)
| Encoding errors. In NIM, if error while encoding base64 for X-Authentication-Key or X-Authentication-Data HTTP parameters.
|}

AM:GetDeviceId

2023-11-11T14:07:15Z

PabloMK7:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x000A0000]
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2
| Secondary result code (0 -> Success)
|-
| 3
| Device ID
|}

=Description=
This retrieves the DeviceID, used in SOAP requests. The SOAP DeviceID is a decimal u64, where the lower word is the retrieved DeviceID while the upper word is the [[Titles|platformID]](NIM has that hard-coded to 4 for DeviceId generation, in the code for AM:GetDeviceId). The secondary result code does not seem to follow standard Result code format.

AM:GetDeviceId

2023-11-11T13:54:20Z

PabloMK7:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x000A0000]
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2
| Secondary result code (100 -> Success)
|-
| 3
| Device ID
|}

=Description=
This retrieves the DeviceID, used in SOAP requests. The SOAP DeviceID is a decimal u64, where the lower word is the retrieved DeviceID while the upper word is the [[Titles|platformID]](NIM has that hard-coded to 4 for DeviceId generation, in the code for AM:GetDeviceId).

Config Services

2023-11-11T12:01:44Z

PabloMK7:

[[Category:Services]]

= Config service "cfg:u" =

{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x00010082
|
| [[CfgS:GetConfigInfoBlk2|GetConfigInfoBlk2]]/GetConfig
|-
| 0x00020000
|
| [[Cfg:SecureInfoGetRegion|SecureInfoGetRegion]]/GetRegion
|-
| 0x00030040
|
| [[Cfg:GenHashConsoleUnique|GenHashConsoleUnique]]/GetTransferableId
|-
| 0x00040000
| [[3.0.0-5]]
| [[Cfg:GetRegionCanadaUSA|GetRegionCanadaUSA]]/IsCoppacsSupported
|-
| 0x00050000
| [[5.0.0-11]]
| [[Cfg:GetSystemModel|GetSystemModel]]
|-
| 0x00060000
| [[6.0.0-11]]
| [[Cfg:GetModelNintendo2DS|GetModelNintendo2DS]]
|-
| 0x00070040
| [[7.0.0-13]]
| (u8 val) This writes the input u8 to the first byte in the config-block for blkID [[Config_Savegame|0x00160000]].
|-
| 0x00080080
| [[7.0.0-13]]
| [[Cfg:TranslateCountryInfo|TranslateCountryInfo]]
|-
| 0x00090040
| [[7.0.0-13]]
| [[Cfg:GetCountryCodeString|GetCountryCodeString]]
|-
| 0x000A0040
| [[7.0.0-13]]
| [[Cfg:GetCountryCodeID|GetCountryCodeID]]
|-
| 0x000B0000
| [[9.3.0-21|9.3.0-X]]
| IsFangateSupported
|}

= Config service "cfg:s" =
cfg:s contains all the commands in cfg:u, in addition to the following:

{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x04010082
|
| [[CfgS:GetConfigInfoBlk8|GetConfigInfoBlk8]]
|-
| 0x04020082
|
| [[CfgS:SetConfigInfoBlk4|SetConfigInfoBlk4]]
|-
| 0x04030000
|
| [[Cfg:UpdateConfigNANDSavegame|UpdateConfigNANDSavegame]]
|-
| 0x04040042
|
| [[Cfg:GetLocalFriendCodeSeedData|GetLocalFriendCodeSeedData]]
|-
| 0x04050000
|
| [[CfgS:GetLocalFriendCodeSeed|GetLocalFriendCodeSeed]]
|-
| 0x04060000
|
| [[Cfg:SecureInfoGetRegion|SecureInfoGetRegion]]
|-
| 0x04070000
|
| [[CfgS:SecureInfoGetByte101|SecureInfoGetByte101]]
|-
| 0x04080042
|
| [[CfgS:SecureInfoGetSerialNo|SecureInfoGetSerialNo]]
|-
| 0x04090000
|
| [[Cfg:UpdateConfigBlk00040003|UpdateConfigBlk00040003]]
|-
| 0x040A0000
| ?
| ?
|-
| 0x040B0000
| ?
| ?
|-
| 0x040C0000
| ?
| ?
|-
| 0x040D0040
|
| SetUUIDClockSequence
|-
| 0x040E0000
|
| GetUUIDClockSequence
|-
| 0x040F0000
|
| [[CfgS:ClearParentalControls|ClearParentalControls]]
|}

CfgS command 0x04060000(SecureInfoGetRegion) is used by NIM module to determine the SOAP RegionId, when sending SOAP requests. See [[Nandrw/sys/SecureInfo_A|here]].

= Config service "cfg:i" =
cfg:i contains all the commands in cfg:u and cfg:s, in addition to the following:

{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x08010082
|
| [[CfgS:GetConfigInfoBlk8|GetConfigInfoBlk8]]
|-
| 0x08020082
|
| [[CfgS:SetConfigInfoBlk4|SetConfigInfoBlk4]]
|-
| 0x08030000
|
| [[Cfg:UpdateConfigNANDSavegame|UpdateConfigNANDSavegame]]
|-
| 0x080400C2
|
| [[CfgI:CreateConfigInfoBlk|CreateConfigInfoBlk]]
|-
| 0x08050000
|
| [[CfgI:DeleteConfigNANDSavefile|DeleteConfigNANDSavefile]]
|-
| 0x08060000
|
| [[CfgI:FormatConfig|FormatConfig]]
|-
| 0x08070000
|
| This basically just returns result-code value 0x0, due to code this eventually executes being NOPed out.
|-
| 0x08080000
|
| This updates the config blocks for blkIDs 0x0 and 0x20000. In certain cases this may call the code for [[CfgI:FormatConfig|FormatConfig]].
|-
| 0x08090000
|
| This updates the config block for blkID 0x60000.
|-
| 0x080A0000
|
| ResetAnalogStickCalibrationParam? This updates the config block for blkID 0x00040001.
|-
| 0x080B0082
|
| [[CfgI:SetGetLocalFriendCodeSeedData|SetGetLocalFriendCodeSeedData]]
|-
| 0x080C0042
|
| [[CfgI:SetLocalFriendCodeSeedSignature|SetLocalFriendCodeSeedSignature]]
|-
| 0x080D0000
|
| [[CfgI:DeleteCreateNANDLocalFriendCodeSeed|DeleteCreateNANDLocalFriendCodeSeed]]
|-
| 0x080E0000
|
| [[CfgI:VerifySigLocalFriendCodeSeed|VerifySigLocalFriendCodeSeed]]
|-
| 0x080F0042
|
| [[Cfg:GetLocalFriendCodeSeedData|GetLocalFriendCodeSeedData]]
|-
| 0x08100000
|
| [[CfgS:GetLocalFriendCodeSeed|GetLocalFriendCodeSeed]]
|-
| 0x08110084
|
| [[CfgI:SetSecureInfo|SetSecureInfo]]
|-
| 0x08120000
|
| [[CfgI:DeleteCreateNANDSecureInfo|DeleteCreateNANDSecureInfo]]
|-
| 0x08130000
|
| [[CfgI:VerifySigSecureInfo|VerifySigSecureInfo]]
|-
| 0x08140042
|
| [[CfgI:SecureInfoGetData|SecureInfoGetData]]
|-
| 0x08150042
|
| [[CfgI:SecureInfoGetSignature|SecureInfoGetSignature]]
|-
| 0x08160000
|
| [[Cfg:SecureInfoGetRegion|SecureInfoGetRegion]]
|-
| 0x08170000
|
| [[CfgS:SecureInfoGetByte101|SecureInfoGetByte101]]
|-
| 0x08180042
|
| [[CfgS:SecureInfoGetSerialNo|SecureInfoGetSerialNo]]
|-
| 0x0819....
| ?
| ?
|-
| 0x081A....
| ?
| ?
|-
| 0x081B....
| ?
| ?
|-
| 0x081C....
| ?
| ?
|-
| 0x081D....
| ?
| ?
|-
| 0x081E....
| ?
| ?
|-
| 0x081F....
| ?
| ?
|-
| 0x0820....
| ?
| ?
|}

= Config NVRAM service "cfg:nor" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| [[CfgNor:Initialize|Initialize]]
|-
| 0x00020000
| [[CfgNor:Shutdown|Shutdown]]
|-
| 0x00030040
| (u8 flag) Writes the input flag to state. Uses SPI service command [[SPI_Services|EnableSpiBus]].
|-
| 0x00040000
| Writes the u8 from the state written by 0x00030040 to cmdreply[2].
|-
| 0x00050082
| [[CfgNor:ReadData|ReadData]]
|-
| 0x00060082
| [[CfgNor:WriteData|WriteData]]
|-
| 0x00070000
| This just uses the WREN command.
|-
| 0x00080000
| This just uses the WRDI command.
|-
| 0x00090000
| [[CfgNor:ReadIdentification|ReadIdentification]]
|-
| 0x000A0000
| This waits for the WIP bit in the status register to clear(wait for writing to finish).
|-
| 0x000B0000
| This waits for the WEL bit in the status register to become set(write enabled).
|-
| 0x000C0000
| This writes the value of the WIP bit in the status register to u8 cmdreply[2].
|-
| 0x000D0000
| This writes the value of the WIP bit in the status register to u8 cmdreply[2].
|-
| 0x000E0000
| [[CfgNor:ReadStatusRegister|ReadStatusRegister]]
|-
| 0x000F0082
| [[CfgNor:ReadDataOther|ReadDataOther]]
|-
| 0x00100082
| [[CfgNor:WriteDataOther|WriteDataOther]]
|-
| 0x00110040
| (u32 offset) Uses command WREN then waits for WEL to become enabled. Sends command 0xDB to SPI followed by the specified flash offset.
|-
| 0x00120040
| (u32 offset) Identical to 0x00110040 except this uses SPI-command 0xD8 instead("block erase").
|-
| 0x00130000
| This uses SPI command 0xB9 for "Deep power down".
|-
| 0x00140000
| This uses SPI command 0xAB for "Release from deep power down".
|}
This is an interface for the "SPI::NOR" service, for accessing the Wifi NVRAM/SPI Flash.

Config Services

2023-11-11T12:00:40Z

PabloMK7:

[[Category:Services]]

= Config service "cfg:u" =

{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x00010082
|
| [[CfgS:GetConfigInfoBlk2|GetConfigInfoBlk2]]/GetConfig
|-
| 0x00020000
|
| [[Cfg:SecureInfoGetRegion|SecureInfoGetRegion]]/GetRegion
|-
| 0x00030040
|
| [[Cfg:GenHashConsoleUnique|GenHashConsoleUnique]]/GetTransferableId
|-
| 0x00040000
| [[3.0.0-5]]
| [[Cfg:GetRegionCanadaUSA|GetRegionCanadaUSA]]/IsCoppacsSupported
|-
| 0x00050000
| [[5.0.0-11]]
| [[Cfg:GetSystemModel|GetSystemModel]]
|-
| 0x00060000
| [[6.0.0-11]]
| [[Cfg:GetModelNintendo2DS|GetModelNintendo2DS]]
|-
| 0x00070040
| [[7.0.0-13]]
| (u8 val) This writes the input u8 to the first byte in the config-block for blkID [[Config_Savegame|0x00160000]].
|-
| 0x00080080
| [[7.0.0-13]]
| [[Cfg:TranslateCountryInfo|TranslateCountryInfo]]
|-
| 0x00090040
| [[7.0.0-13]]
| [[Cfg:GetCountryCodeString|GetCountryCodeString]]
|-
| 0x000A0040
| [[7.0.0-13]]
| [[Cfg:GetCountryCodeID|GetCountryCodeID]]
|-
| 0x000B0000
| [[9.3.0-21|9.3.0-X]]
| IsFangateSupported
|}

= Config service "cfg:s" =
cfg:s contains all the commands in cfg:u, in addition to the following:

{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x04010082
|
| [[CfgS:GetConfigInfoBlk8|GetConfigInfoBlk8]]
|-
| 0x04020082
|
| [[CfgS:SetConfigInfoBlk4|SetConfigInfoBlk4]]
|-
| 0x04030000
|
| [[Cfg:UpdateConfigNANDSavegame|UpdateConfigNANDSavegame]]
|-
| 0x04040042
|
| [[Cfg:GetLocalFriendCodeSeedData|GetLocalFriendCodeSeedData]]
|-
| 0x04050000
|
| [[CfgS:GetLocalFriendCodeSeed|GetLocalFriendCodeSeed]]
|-
| 0x04060000
|
| [[Cfg:SecureInfoGetRegion|SecureInfoGetRegion]]
|-
| 0x04070000
|
| [[CfgS:SecureInfoGetByte101|SecureInfoGetByte101]]
|-
| 0x04080042
|
| [[CfgS:SecureInfoGetSerialNo|SecureInfoGetSerialNo]]
|-
| 0x04090000
|
| [[Cfg:UpdateConfigBlk00040003|UpdateConfigBlk00040003]]
|-
| 0x040A0000
| ?
| ?
|-
| 0x040B0000
| ?
| ?
|-
| 0x040C0000
| ?
| ?
|-
| 0x040D0040
|
| SetUUIDClockSequence
|-
| 0x040E0000
|
| SetUUIDClockSequence
|-
| 0x040F0000
|
| [[CfgS:ClearParentalControls|ClearParentalControls]]
|}

CfgS command 0x04060000(SecureInfoGetRegion) is used by NIM module to determine the SOAP RegionId, when sending SOAP requests. See [[Nandrw/sys/SecureInfo_A|here]].

= Config service "cfg:i" =
cfg:i contains all the commands in cfg:u and cfg:s, in addition to the following:

{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x08010082
|
| [[CfgS:GetConfigInfoBlk8|GetConfigInfoBlk8]]
|-
| 0x08020082
|
| [[CfgS:SetConfigInfoBlk4|SetConfigInfoBlk4]]
|-
| 0x08030000
|
| [[Cfg:UpdateConfigNANDSavegame|UpdateConfigNANDSavegame]]
|-
| 0x080400C2
|
| [[CfgI:CreateConfigInfoBlk|CreateConfigInfoBlk]]
|-
| 0x08050000
|
| [[CfgI:DeleteConfigNANDSavefile|DeleteConfigNANDSavefile]]
|-
| 0x08060000
|
| [[CfgI:FormatConfig|FormatConfig]]
|-
| 0x08070000
|
| This basically just returns result-code value 0x0, due to code this eventually executes being NOPed out.
|-
| 0x08080000
|
| This updates the config blocks for blkIDs 0x0 and 0x20000. In certain cases this may call the code for [[CfgI:FormatConfig|FormatConfig]].
|-
| 0x08090000
|
| This updates the config block for blkID 0x60000.
|-
| 0x080A0000
|
| ResetAnalogStickCalibrationParam? This updates the config block for blkID 0x00040001.
|-
| 0x080B0082
|
| [[CfgI:SetGetLocalFriendCodeSeedData|SetGetLocalFriendCodeSeedData]]
|-
| 0x080C0042
|
| [[CfgI:SetLocalFriendCodeSeedSignature|SetLocalFriendCodeSeedSignature]]
|-
| 0x080D0000
|
| [[CfgI:DeleteCreateNANDLocalFriendCodeSeed|DeleteCreateNANDLocalFriendCodeSeed]]
|-
| 0x080E0000
|
| [[CfgI:VerifySigLocalFriendCodeSeed|VerifySigLocalFriendCodeSeed]]
|-
| 0x080F0042
|
| [[Cfg:GetLocalFriendCodeSeedData|GetLocalFriendCodeSeedData]]
|-
| 0x08100000
|
| [[CfgS:GetLocalFriendCodeSeed|GetLocalFriendCodeSeed]]
|-
| 0x08110084
|
| [[CfgI:SetSecureInfo|SetSecureInfo]]
|-
| 0x08120000
|
| [[CfgI:DeleteCreateNANDSecureInfo|DeleteCreateNANDSecureInfo]]
|-
| 0x08130000
|
| [[CfgI:VerifySigSecureInfo|VerifySigSecureInfo]]
|-
| 0x08140042
|
| [[CfgI:SecureInfoGetData|SecureInfoGetData]]
|-
| 0x08150042
|
| [[CfgI:SecureInfoGetSignature|SecureInfoGetSignature]]
|-
| 0x08160000
|
| [[Cfg:SecureInfoGetRegion|SecureInfoGetRegion]]
|-
| 0x08170000
|
| [[CfgS:SecureInfoGetByte101|SecureInfoGetByte101]]
|-
| 0x08180042
|
| [[CfgS:SecureInfoGetSerialNo|SecureInfoGetSerialNo]]
|-
| 0x0819....
| ?
| ?
|-
| 0x081A....
| ?
| ?
|-
| 0x081B....
| ?
| ?
|-
| 0x081C....
| ?
| ?
|-
| 0x081D....
| ?
| ?
|-
| 0x081E....
| ?
| ?
|-
| 0x081F....
| ?
| ?
|-
| 0x0820....
| ?
| ?
|}

= Config NVRAM service "cfg:nor" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010040
| [[CfgNor:Initialize|Initialize]]
|-
| 0x00020000
| [[CfgNor:Shutdown|Shutdown]]
|-
| 0x00030040
| (u8 flag) Writes the input flag to state. Uses SPI service command [[SPI_Services|EnableSpiBus]].
|-
| 0x00040000
| Writes the u8 from the state written by 0x00030040 to cmdreply[2].
|-
| 0x00050082
| [[CfgNor:ReadData|ReadData]]
|-
| 0x00060082
| [[CfgNor:WriteData|WriteData]]
|-
| 0x00070000
| This just uses the WREN command.
|-
| 0x00080000
| This just uses the WRDI command.
|-
| 0x00090000
| [[CfgNor:ReadIdentification|ReadIdentification]]
|-
| 0x000A0000
| This waits for the WIP bit in the status register to clear(wait for writing to finish).
|-
| 0x000B0000
| This waits for the WEL bit in the status register to become set(write enabled).
|-
| 0x000C0000
| This writes the value of the WIP bit in the status register to u8 cmdreply[2].
|-
| 0x000D0000
| This writes the value of the WIP bit in the status register to u8 cmdreply[2].
|-
| 0x000E0000
| [[CfgNor:ReadStatusRegister|ReadStatusRegister]]
|-
| 0x000F0082
| [[CfgNor:ReadDataOther|ReadDataOther]]
|-
| 0x00100082
| [[CfgNor:WriteDataOther|WriteDataOther]]
|-
| 0x00110040
| (u32 offset) Uses command WREN then waits for WEL to become enabled. Sends command 0xDB to SPI followed by the specified flash offset.
|-
| 0x00120040
| (u32 offset) Identical to 0x00110040 except this uses SPI-command 0xD8 instead("block erase").
|-
| 0x00130000
| This uses SPI command 0xB9 for "Deep power down".
|-
| 0x00140000
| This uses SPI command 0xAB for "Release from deep power down".
|}
This is an interface for the "SPI::NOR" service, for accessing the Wifi NVRAM/SPI Flash.

Socket Services

2023-10-30T21:48:56Z

PabloMK7:

[[Category:Services]]
= Socket user service "soc:U" =
{| class="wikitable" border="1"
|-
! Command Header
! Available since system-version
! Description
|-
| 0x00010044
|
| [[SOCU:InitializeSockets|InitializeSockets]]
|-
| 0x000200C2
|
| [[SOCU:socket|socket]]
|-
| 0x00030082
|
| [[SOCU:listen|listen]]
|-
| 0x00040082
|
| [[SOCU:accept|accept]]
|-
| 0x00050084
|
| [[SOCU:bind|bind]]
|-
| 0x00060084
|
| [[SOCU:connect|connect]]
|-
| 0x00070104
|
| [[SOCU:recvfrom_other|recvfrom_other]]
|-
| 0x00080102
|
| [[SOCU:recvfrom|recvfrom]]
|-
| 0x00090106
|
| [[SOCU:sendto_other|sendto_other]]
|-
| 0x000A0106
|
| [[SOCU:sendto|sendto]]
|-
| 0x000B0042
|
| [[SOCU:close|close]]
|-
| 0x000C0082
|
| [[SOCU:shutdown|shutdown]]
|-
| 0x000D0082
|
| [[SOCU:gethostbyname|gethostbyname]]
|-
| 0x000E00C2
|
| [[SOCU:gethostbyaddr|gethostbyaddr]]
|-
| 0x000F0106
|
| [[SOCU:getaddrinfo|getaddrinfo]]
|-
| 0x00100102
|
| [[SOCU:getnameinfo|getnameinfo]]
|-
| 0x00110102
|
| [[SOCU:getsockopt|getsockopt]]
|-
| 0x00120104
|
| [[SOCU:setsockopt|setsockopt]]
|-
| 0x001300C2
|
| [[SOCU:fcntl|fcntl]]
|-
| 0x00140084
|
| [[SOCU:poll|poll]]
|-
| 0x00150042
|
| [[SOCU:sockatmark|sockatmark]]
|-
| 0x00160000
|
| [[SOCU:gethostid|gethostid]]
|-
| 0x00170082
|
| [[SOCU:getsockname|getsockname]]
|-
| 0x00180082
|
| [[SOCU:getpeername|getpeername]]
|-
| 0x00190000
|
| [[SOCU:ShutdownSockets|ShutdownSockets]]
|-
| 0x001A00C0
|
| [[SOCU:GetNetworkOpt|GetNetworkOpt]]
|-
| 0x001B0040
|
| [[SOCU:ICMPSocket|ICMPSocket]]
|-
| 0x001C0104
|
| [[SOCU:ICMPPing|ICMPPing]]
|-
| 0x001D0040
|
| [[SOCU:ICMPCancel|ICMPCancel]]
|-
| 0x001E0040
|
| [[SOCU:ICMPClose|ICMPClose]]
|-
| 0x001F0040
|
| [[SOCU:GetResolverInfo|GetResolverInfo]]
|-
| 0x00200146
|
| [[SOCU:SendToMultiple|SendToMultiple]]
|-
| 0x00210002
|
| [[SOCU:CloseSockets|CloseSockets]]
|-
| 0x00220040
|
| (int sockfd) Might be the inverse of command 0x00230040?
|-
| 0x00230040
|
| [[SOCU:AddGlobalSocket|AddGlobalSocket]]
|-
| 0x100100C0
| ?
| ?
|-
| 0x10030142
| ?
| ?
|-
| 0x10050084
| ?
| ?
|-
| 0x10070102
| ?
| ?
|}

= Socket privileged service "soc:P" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010084
| [[SOCP:InitializeSockets|InitializeSockets]]
|-
| 0x00020000
| [[SOCP:FinalizeSockets|FinalizeSockets]]
|-
| 0x000300C2
| [[SOCP:SetNetworkOpt|SetNetworkOpt]]
|-
| 0x00040040
| [[SOCP:CloseSocketsForProcess|CloseSocketsForProcess]]
|-
| 0x000500C0
|
|-
| 0x00060000
| [[SOCP:gethostid|gethostid]]
|-
| 0x00070000
|
|-
| 0x00080000
|
|-
| 0x00090000
| [[SOCP:StopInitializeSockets|StopInitializeSockets]]
|}

= struct sockaddr =
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Total size of the entire sockaddr buffer.
|-
| 0x1
| 0x1
| u8 sa_family
|-
| 0x2
| sockaddr_totalsize-0x2
| sa_data[]
|}

The total buffer size is 0x8, for family AF_INET value 2. AF_INET6 seems to be value 23, the total sockaddr size for this is 0x1C. The max sockaddr buffer size which the socket module can handle is size 0x1C.

These socket services(and defines/structures) seem to be based on the Wii sockets?

=Socket module errors=
{| class="wikitable" border="1"
|-
! Error
! Description
|-
| 0xC8A0700B
| [[SOCU:InitializeSockets]] returns this when the specified PID was already used with [[SOCU:InitializeSockets]](since the PID was found in SOC module state table).
|-
| 0xD860700A
| [[SOCU:InitializeSockets]] returns this when the PID table is already full(32 processes max).
|}

=Socket module static buffers=

This is the list of the known thread static buffers in use for SOC:u and the commands using those.
{| class="wikitable" border="1"
|-
! buffer ID
! commands
|-
| 0
| bind,connect
|-
| 1
| sendto_other,sendto
|-
| 2
| sendto
|-
| 5-7
| getaddrinfo
|-
| 8
| getnameinfo
|-
| 9
| setsockopt
|-
| 10
| poll
|}

=IPV6=

It seems that Nintendo planned ahead and included IPv6 support to some extent in their code.
Name resolution functions support IPv6 (such as [[SOCU:getnameinfo|getnameinfo]]), but [[SOCU:socket|socket]] doesn't.

The ipv6 sockaddr size is 0x1C and is required for some IPC commands, even when using sockaddr_in which in reality is of size 8.
The sockaddr_in6 struct is the following:

struct in6_addr
{
uint8_t s6_addr[16];
};

struct sockaddr_in6
{
sa_family_t sin6_family;
in_port_t sin6_port;
struct in6_addr sin6_addr;
u32 sin6_flowinfo; // Not confirmed
u32 sin6_scope_id; // Not confirmed
};

3DS Userland Flaws

2023-05-31T04:44:41Z

PabloMK7:

This page lists vulnerabilities / exploits for 3DS applications and applets. Exploiting these initially results in ROP, from that ROP one can then for example try exploiting [[3DS_System_Flaws|system]] flaw(s).

=Non-system applications=
{| class="wikitable" border="1"
|-
! Application name
! Summary
! Description
! Fixed in app/system version
! Last app/system version this flaw was checked for
! Timeframe info related to this was added to wiki
! Timeframe this vuln was discovered
! Vuln discovered by
|-
| Cubic Ninja
| Map-data stack smash
| See [[Ninjhax|here]] regarding Ninjhax.
| None
| App: Initial version. System: [[10.4.0-29]].
| Ninjhax release
| July 2014
| [[User:smea|smea]]
|-
| The Legend of Zelda: Ocarina of Time 3D
| UTF-16 name string buffer overflow via unchecked u8 length field
| The u8 at offset 0x2C in the savefile is the character-length of the UTF-16 string at offset 0x1C. When copying this string, it's essentially a memory-copy with lenval*2, not a string-copy. This can be used to trigger buffer overflows at various locations depending on the string length.
* When value is >=0x6E it crashes when saving the saveslot, this causes a stack-smash however it normally crashes before it returns from the function which had the stack-frame overwritten.
* With value >=0x9A, it crashes via stack-smash in-game once any dialogs are opened(touching buttons on the touch-screen can trigger it too).
* Length value>=0xCD causes a crash while loading the saveslot, via a heap buffer overflow. This buf-overflow overwrites a heap memchunk following the allocated buffer. When the first 16-bits overwriting that heap memchunk is not the memchunk magic-number(0x7373), the mem-alloc code will just return a NULL ptr which later results in a crash. When the magic-number is valid, the mem-alloc code will continue to attempt to parse the memchunk, which may crash depending on the data which overwrote the memchunk. This heap code is separate from the CTRSDK heap code. Exploiting this doesn't seem to be possible: since the heap code actually verifies that the magic-number for the next/prev memchunk ptrs are correct(unlike CTRSDK), it's not possible to change those ptrs to useful arbitrary addresses outside of savedata(like with triggering a write to a c++ object ptr which later is used with a vtable func-call, this is what one would do with CTRSDK heap here).

On March 11, 2015, an exploit using this vuln was released, that one was intended for warez/etc. The following exploit wasn't released before then mainly because doing so would (presumably) result in the vuln being fixed. The following old exploit was released on March 14, 2015: [https://github.com/yellows8/oot3dhax].
| None
| App: Initial version. System: [[10.6.0-31]].
| March 11, 2015
| Around October 22, 2012
| [[User:Yellows8|Yellows8]]
|-
| Super Smash Bros 3DS
| Buffer overflow in local-multiplayer beacon handling.
| See [[smashbroshax|here]].
| App: v1.1.3
| See [[smashbroshax|here]]. System: [[10.3.0-28]].
| Time of exploit release.
| See [[smashbroshax|here]].
| [[User:Yellows8|Yellows8]]
|-
| Pokemon Super Mystery Dungeon
| Heap overflow within linear memory via unchecked save file length
| Pokemon Super Mystery Dungeon uses zlib compression for most of its save files, possibly due to the save files being larger than its predecessor, Gates to Infinity. When a save file is being prepared to be loaded and read from, only a 0x32000 large buffer is allocated for file reading, and a 0x3e800-large buffer for decompression is also allocated before the file is read. However, the game does not limit the size of the file read to this allocation bound, allowing for the file to overflow into the linear memory heap and into the next allocation. Since Pokemon Super Mystery Dungeon stores allocation memchunks directly before the allocation, overwriting the next memchunk with a corrupted one allows for arbitrary writes of linear heap pointers when the next buffer is allocated or arbitrary writes of any pointer within writable memory when the corrupted buffer is freed.
| None
| O3DS: [[11.3.0-36]]. N3DS: [[11.4.0-37]].
| Time of exploit release.
| April 14, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| VVVVVV
| Buffer overflow in XML save file array parsing
| VVVVVV utilizes several XML files (renamed with a .vvv extension) to store level save data, stats and settings. Within these XML files are several tags containing an array of data which, when parsed, is not properly checked to be of proper length for the tag being parsed from. This allows for an overflow of 16-bit array values from the location where the array is parsed. With unlock.vvv, XML data is parsed to the stack, and with level saves the heap. This allows for the pointer where the level save worldmap tag array should be parsed into to be overwritten with a stack address, allowing for ROP from within the XML array parsing function on the next level load.
| App: v1.1
| [[10.7.0-32]].
| Time of exploit release.
| April 25, 2016
| [[User:Shinyquagsire23|Shiny Quagsire]]
|-
| Citizens of Earth
| Save file read stack smash
| Citizens of Earth also uses "XML" files for saves, which are actually entirely binary data (not XML at all) with no checksums. These files are read from the filesystem on to a fixed size stack buffer which leads to an incredibly trivial stack smash. When using the autosave slot for this, the save is parsed when the user selects "continue". When using one of the dedicated save slots (1-3), the save is parsed shortly after the company splash screens fade. Note that the save is read quite high (descending) on the stack - when exploiting this, one would likely need to move SP due to almost instantly overflowing the physical stack.
| None
| [[10.7.0-32]].
| Time of exploit release.
| May 5, 2016
| [[User:Dazzozo|Dazzozo]]
|-
| SmileBASIC 3.x
| Poor parameter validation on "BGSCREEN" command
| The SmileBASIC "BGSCREEN" command's second parameter is not properly validated as being within range. As a result, one can set the screen size to an absurdly large value. This means that the "BGGET" and "BGPUT" commands can then be used on out-of-range values to read and write a significant chunk of the interpreter's address space.
With a series of carefully-designed BGPUT commands, one can build a ROP chain and cause it to be executed.
| App: 3.3.2.
| System: [[11.0.0-33]].
| July 20, 2016
| Around June 26, 2016
| slackerSnail, 12Me12, incvoid
Exploited by MrNbaYoh and [[User:Plutooo|plutoo]].
|-
| SmileBASIC 3.x
| Subscripted TIME$/DATE$ allow write access to DATA/BSS
| Utf-16 characters can be assigned to subscripted TIME$/DATE$ interpreter sysvars which results in write-only access to all of DATA and some BSS in userland.
TIME$[0]/DATE$[0] actually point to somewhere in rodata, and an overly large subscript can be used to write well past it and into the aforementioned areas. Demo [https://github.com/zoogie/smilehax-IIe here.]
| App: 3.6.2 (3.6.0 latest for US/EU, JP appvers. can be downgraded)
| System: [[11.13.0-45]].
| April 2020
| February 2020
| bug publicly documented [https://translate.google.com/translate?sl=auto&tl=en&u=http%3A%2F%2Fsmilebasic.com%2Fdebug%2Farchive%2F here.]
Exploited by Zoogie
|-
| The Legend of Zelda: Tri Force Heroes
| [[3DS_System_Flaws#General.2FCTRSDK|CTRSDK]] CTPK buffer overflow combined with game's usage of SpotPass
| During the very first screen displayed by the game during boot("Loading..."), just seconds after title launch, the game loads CTPK from the [[BOSS_Services|stored]] SpotPass content. Hence, this game could be exploited via the vulnerable CTRSDK CTPK code ''if'' one could get custom SpotPass data into extdata somehow(ctr-httpwn >=v1.2 with bosshaxx allows this).

The code for this runs from a thread separate from the main-thread, with the stack in linearmem heap. This SpotPass handling triggers before the game ever opens the regular savedata archive. The extdata is opened at some point before this: it opens a file for checking if it exists, then immediately closes it.

The two SpotPass URLs for this have always(?) returned HTTP 404 as of November 2016. It appears these were intended for use as textures for additional costumes(and never got used publicly), but this wasn't tested.

This is used by [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh].
| None
| App: v2.1.0
| November 18, 2016
| November 14, 2016
| [[User:Yellows8|Yellows8]]
|-
| Pixel Paint
| Buffer overflow via unchecked extdata file length
| Pixel Paint loads pictures saved by the user from extdatas. The file is read to a fixed size buffer but the file length remains unchecked, so with a large enough file, one can overwrite pointers in memory and gain control of the execution flow.
| None
| App: Initial version. System: [[11.2.0-35]].
| December 27, 2016
| November 5, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Steel Diver : Sub Wars
| Heap overflow / arbitrary memcpy
| Savefile datas are stored as key/value pairs, a large enough string key makes the game overwrite a memcpy source/destination addresses and size arguments. So one can actually memcpy a rop on the stack and gain control of the execution flow.
| None
| System: [[11.2.0-35]].
| December 27, 2016
| Around July 15, 2016
| [[User:Nba_Yoh|MrNbaYoh]], Vegaroxas
|-
| 1001 Spikes
| Buffer overflow via unchecked array-indexes in XML savefile parsing
| The savefiles are stored as renamed .xml files, which contain several tags with attributes like 'array-index="array-value"', where both of these are converted from ASCII strings to integers as signed-int32, and the array-value given blindly written to an array inside a structure using the (unchecked) index given. With several of these attributes, one can overwrite the stack starting from the stored lr of the function that does this parsing, and write a ROP chain there. Testing used the "LevelAttempts" tag which is the last such tag parsed in that function.
| None
| App: v1.2.0 (TMD v2096)
| December 27, 2016
| Around November 2, 2016
| [[User:Riley|Riley]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| Secret base team name heap overflow
| When the player wants to edit the team name, it is copied over the heap, however its length is not verified. So with a large enough team name one can overwrite some pointers and get two arbitrary jumps and then get control of the execution flow.
| None
| App: 1.4. System: [[11.2.0-35]].
| December 30, 2016
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Swapdoodle
| Heap buffer overflow via unchecked size
| The letter file format used by doodlebomb is composed of multiple chunks. Each chunks is described in the header of the file where the name, size and CRC of each chunk are stored. Some chunks are meant to be headers, every header's size should be 0x80, however the length of the STAHED1 chunk remains unchecked and the game memcpy the chunk to a 0x80 byte buffer with the length provided in the file. This way one is able to overwrite some pointers and get control of the execution flow.
| App: > v1.1.1
| App: v1.1.1
| April 24, 2017
| February, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Pokemon Picross
| Arbitrary memcpy via unchecked size
| When reading the savefile, the game handles some lists of buffers that are copied to memory. These buffers should always be 0x14-bytes long but the game uses the size provided in the savefile to copy them. These buffers are copied in some structs and thus with a big enough length value, one can overwrite the next struct which contains a size and a destination address for a memcpy.
| None?
| App: ?
| May 29, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow on .bss section
| When loading a project, the game copies multiple chunks over the BSS section. However the number of chunks to copy is not checked, thus a large amount of chunk result in a buffer overflow. There's multiple way to exploit this flaw to gain an arbitrary memcpy or an arbitrary jump.
| None?
| App: ?
| August 28, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| Buffer overflow via unchecked file size
| When loading a project, the game loads the file to a 0x200000 bytes long buffer. However the size remains unchecked, so with a big enough file one can overflow the buffer and overwrite a thread stack and then achieve ROP.
| None?
| App: ?
| August 29, 2017
| August, 2017
| [[User:Nba_Yoh|MrNbaYoh]], [[User: ChampionLeake|ChampionLeake]]
|-
| Pokemon Omega Ruby/Alpha Sapphire
| PSS data heap/stack overflow
| When launching the game, multiple chunks from the save file are parsed and copied to a large heap buffer. When parsing PSS data (acquaintances, passerby) the game copies each entry to the heap buffer, the number of entries to copy is read from the end of the multiple pss data chunks and is not checked, leading to an overflow. The "PSS data - friends" chunk is vulnerable too, but the overflow occurs on the stack and unfortunately this isn't exploitable because of a 4 bytes uncontrolled value (in each entry) that gets written on sensitive data.
| None
| App: 1.4. System: [[11.6.0]].
| October 1, 2017
| June, 2016
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| RPG Maker Fes/Player
| OOB write
| When handling events in a map, the indices of "buttons" are not checked. This results in an out of bound bit write, one can thus write a rop directly on the stack (bit by bit).
| None?
| App: ?
| August 5, 2018
|
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Unholy Heights
| Buffer overflow via unchecked string size
| The game stores some utf-16 messages in the savefile. Right before the message is the length(u32) for the string, the game uses this size to memcpy the message from the savefile to the stack without checking the length. This allows one to overwrite some function addresses on the stack and form a rop chain.
| None
| App: Initial Version
| September 13, 2018
| August, 2018
| Kartik
|-
| Mononoke Forest
| String Buffer Overflow via unchecked string length
| The game stores plaintext profile names in the savefile. The profile names are strcpy/memcpy to different areas of the game's functions in the stack. Using a large extensive profile name, a user can overwrite some stack-registers and point to stack buffer addresses to eventually gain control of the stack to lead and form a rop-chain.
| None
| App: v1.0.0
| August 14, 2019
| February 8, 2019
| [[User: ChampionLeake|ChampionLeake]] and [[User: Kartik|Kartik]]
|-
| Picross 3D: Round 2
| Out of bounds array access allowing to point to fabricated objects and vtable
| Game only checks save header. With the last interacted save slot index at +0xb270 in the save data unchecked we can achieve a predictable out of bounds access, as well inserting ROP data without detecting save corruption. Game references an object from an array of 3 elements and passes it to a function that will read object pointers and hit a vtable call. With a copy save data left in memory and a properly calculated index, we can point to a fake object position in the save, vtable jump to a stack pivot and start the ROP chain.
| None
| App: Initial version
| September 10, 2020
| August 24, 2020
| [[User: Luigoalma|Luigoalma]] and [[User: Kartik|Kartik]]
|-
| Me and My Pets 3D
| String buffer overflow
| The game stores some strings in the savegame. Using a large enough string, once can overwrite addresses on the stack and form a ropchain.
| None
| App: Initial Version
| June 24, 2022
| June 12, 2022
| [[User: Kartik|Kartik]]
|}

==Flipnote Studio 3D==

{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in app/system version
! Timeframe info related to this was added to wiki
! Flaw discovered by
|-
| KFH frame count overflow
| The KFH frame count field should not be >= 0x3E8, but it wasn't checked and so uncontrolled data were written over pointers, causing an unexploitable crash.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI paper color overflow
| Paper color field (and similar color fields) in KMI chunks was not checked, a too high value caused a jump to an uncontrolled location.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KSN BGM data size overflow
| The size of the BGM data in the KSN chunk was not checked, it was used in a memcpy so with a big enough size one could overwrite a thread stack on linear mem and achieve ROP (notehax v1).
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMC chunk unchecked
| The KMC chunk was not verified at all, the CRC32 and the size were not checked. A big enough size caused an integer overflow and made the game read the file backward.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| KMI layer size unchecked
| The 3 layer size fields in KMI chunks were not checked, leading to some crashes in the editor.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| Bad "queue" implementation
| When a KWZ was parsed, frames were copied in a kind of queue, bounds were not checked obviously, so with the KMI layer size flaw one was able to fill completely the queue, then write past the buffer and overwrite a heap chunk header (notehax v2). This is not possible anymore, the queue cannot be filled because layer sizes are checked. Moreover each time an element is removed from the queue, the whole content is memmoved *facepalm*.
| System: 11.6
| September 20, 2017
| [[User:Nba_Yoh|MrNbaYoh]]
|}

==Useless crashes / applications which were fuzzed==
* Pushmo (3DSWare), QR codes: level name is properly limited to 16 characters, game doesn't crash with a longer name. The only possible crashes are triggered by out-of-bounds array index values, these crashes are not exploitable due to the index value being 8bit.

* [[Pyramids (3DSWare)]], QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.

* [[Pyramids 2 (3DSWare)]], QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.

* [https://github.com/yellows8/mm3d_re The Legend of Zelda: Majora's Mask 3D]

* "The Legend of Zelda: A Link Between Worlds" and "The Legend of Zelda: Tri Force Heroes": these games don't crash at all when the entire save-file(minus constant header data) is overwritten with /dev/random output / 0xFF-bytes. All of the CRC32s were updated for this of course. Note that this refers to the regular save file: Tri Force Heroes can be exploited via BOSS extdata - see above.

* Pokemon Mystery Dungeon: Gates to Infinity has the same unchecked file bounds as Pokemon Super Mystery Dungeon, however since save compression was introduced in Pokemon Super Mystery Dungeon, it only allocates one buffer within the application heap instead of several within the linear heap, resulting in nothing to corrupt or overwrite even if the file's length is extended past its allocation.

* "Kid Icarus: Uprising": Overwriting the entire savedata results in various crashes, nothing useful.

* Savedata/extdata for "Super Smash Bros 3DS": Overwriting the various files stored under savedata/extdata results in useless crashes.

* "StarFox 64 3D": Doesn't crash at all with the entire savedata overwritten.

* "Frogger 3D": Overwriting a savefile with random-data results in *nothing* crashing.

* "Mutant Mudds": Overwriting the savefile with random data results in a crash

* "Worcle Worlds": Overwriting the savefile with 0xFF results in a crash due to an out of bound read

* "Animal Crossing: New Leaf": Creating a QR code from random data results in a valid QR code and a random design. In some very rare cases(which aren't always reproducible?) a crash/etc may occur, but this isn't known to be useful.

* "Angry Birds Star Wars": Strings in the savefile are preceded by their lengths. These strings are never stored on the stack and are memcpy'd into heap memory. If the size is invalid the alloc will fail and thus the memcpy will operate on a nullptr resulting in a useless data abort.

* "Gem Smashers": Overwriting the savefile with random bytes results in useless crashes.

* "Luxor:" Strings/plaintext in the savefile are present and these's no checks. Overwriting the whole save (excluding the header), with /dev/random cause a useless crash.

* "Luv Me Buddies Wonderland:" Doesn't crash at all with the entire savedata overwritten. Overwriting some areas, points to useless nulls

==Crashes needing investigation==
* Disney Infinity crashes when all savedata overwritten with /dev/urandom. No checksums. 0xFF bytes don't cause a crash.

* Football Up Online / Soccer Up Online and Football Up 3D / Soccer Up 3D crash when teamname(UTF-16) length = 0x48 AND 0x20 null bytes are removed after just the name or if teamname length is way longer than 0x48.

=System applications=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| 3DS [[System Settings]] DS profile string stack-smash
| Too long or corrupted strings (01Ah 2 Nickname length in characters 050h 2 Message length in characters) in the NVRAM DS user settings (System Settings->Other Settings->Profile->Nintendo DS Profile) cause it to crash in 3DS-mode due to a stack-smash. The DSi is not vulnerable to this, DSi launcher(menu) and DSi System Settings will reset the NVRAM user-settings if the length field values are too long(same result as when the CRCs are invalid). TWL_FIRM also resets the NVRAM user-settings when the string-length(s) are too long.
| [[7.0.0-13]]
| [[7.0.0-13]]
| 2012
| [[User:Ichfly|Ichfly]]
|-
| 3DS [[System Settings]] stack smash via title strings in [[DSiWare_Exports]]
| DSiWare export banners contain 16 consecutive 0x100 byte, utf-16 game title strings for different languages. Nintendo correctly limits the string's max length by placing a NULL at str[127] before it's copied to the stack. However, they didn't allocate enough space for all 128 wchars (char/wchar type confusion?), so an attacker can craft a valid full-length string that will crash the stack at about str+0xEC. ROP execution can then be obtained from this crash in DSiWare Data Management as demonstrated [https://github.com/zoogie/Bannerbomb3 here].

Interesting note: A line feed wchar (00 0A) at any point in the string before the crash offset will prevent the crash from occurring.
| [[11.17.0-50]]
| [[11.13.0-45]]
| Dec. 2018
| Zoogie
|-
| 3DS SAFE_MODE [https://www.3dbrew.org/wiki/System_Settings#System_Updater System Updater] stack smash from proxy-url string
| During [[Recovery Mode]] and after all 3 wifi slots fail to find an access point for sysupdate, a user is permitted to access the wifi settings mode to make changes. Here, if the proxy-url field string's NULL terminator had been altered beforehand, a stack smash can occur when the user selects Proxy Settings -> Detailed Setup and the corrupted url string is displayed.

This is a difficult crash to control because the url string is converted from ascii to utf-16 between the slot and stack, effectively reducing the available gadgets to 0.4% of the normal amount. It's possible to improvise an "escape" using an eoreq pc w/shift gadget to combine registers and form a jump that can access 1/2 of all available gadgets.

Because this exploit runs *under* SAFE_MODE, it's possible to run safehax with one's choice of k11 and arm9 hax. Prerequisite: a userland exploit with cfg:s/i access to modify the wifi slot. A demonstration can be viewed [https://github.com/zoogie/unSAFE_MODE here].
| None
| [[11.13.0-45]]
| Jan. 2020
| Zoogie
|-
| [[Nintendo 3DS Sound]]
| When a .m4a is loaded, the song name is copied to a 256 byte buffer. When the song name begins with a Unicode BOM marker, it memcpy's the tag using the user-provided length. This gives an arbitrary write which can be used to achieve ROP.
| [[11.4.0-37]]
| [[11.4.0-37]]
| June/July 2016
| [[User:nedwill|nedwill]]
|-
| [[EShop]]
| When creating an audio decoder object for the moflex movie player, if the audio codec is PCM16, the application uses an uninitialized value as a pointer. One can spray the heap to get control of that pointer and achieve ROP.
| None
| [[11.14.0-46]]
| 2020
| [[User:Nba_Yoh|MrNbaYoh]]
|}

=System applets=
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Introduced with version
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| Webkit/web-browser bugs
| spider has had at least three different code-execution exploits. Majority of them are use-after-free issues. See also [[browserhax|here]].
|
|
|
| 2013?
|
| A lot of people.
|-
| Old3DS/New3DS [[Internet_Browser|Browser-version-check]] bypass
| When the browser-version-check code runs where the savedata for it was never initialized(such as when the user used the "Initialize savedata" option), it will use base_timestamp=0 instead of the timestamp loaded from savedata. This is then used with "if(cur_timestamp - base_timestamp >= <24h timestamp>){Run browser-version-check HTTPS request code}".
Hence, if the savedata was just initialized, and if the system datetime is set to before January 2, 2000, the browser-version-check will be skipped. This includes January 1, 2000, 00:00, because that's the epoch(timestamp value 0x0) used with this timestamp.

See [http://yls8.mtheall.com/3dsbrowserhax.php here] for bypass usage instructions.

This was fixed with [[10.7.0-32|10.7.0-32]], see [[Internet_Browser|here]] for details.
| [[10.7.0-32|10.7.0-32]]
|
| [[9.9.0-26|9.9.0-26]]
| February 25, 2016
| November 2, 2015 (Exactly one week after the browser version pages were initially updated server-side)
| [[User:Yellows8|Yellows8]]
|-
| Skater - Bookmark OOB write
| Each bookmark has an id that should not exceed 0x63 (99), however ids are not checked, this results in an OOB write on the stack, but only the value 0x01 can be written.
|
| [[11.6.0-39|11.6.0-39]]
|
| May 21, 2018
| May 20, 2018
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| MicroSD Management - malformed security blob causes stack buffer overflow (mhax)
| The MicroSD Management application's parsing of Windows NTLM security blobs in the SMB/CIFS protocol doesn't verify that the client's specified NT domain name is less than 32 UTF-16 characters. When it's longer, a stack buffer overrun occurs, leading to a ROP chain and complete control of the mcopy application.

The malformed security blob can be sent by an attacker within the SMB_COM_SESSION_SETUP_ANDX (0x73) packet.
| [[11.8.0-41|11.8.0-41]]
| [[11.8.0-41|11.8.0-41]]
| [[9.0.0-20|9.0.0-20]]
| August 12, 2018
| 2018
| smea
|}

==Home Menu==
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Introduced with version
! Timeframe info related to this was added to wiki
! Timeframe this was discovered
! Discovered by
|-
| u8 brightness setting OOB index (menuhax67)
| Config block 0x50001, which contains a u8 brightness setting that indexes a table of u32 addresses, can be set to an out-of-bounds index (it's normally 1-5). Located within cfg block 0x50009, there exists a single controllable u32 that's located within the u8's range. With these set properly, one can eventually redirect a function pointer to an address of their choice. This is triggered after the Home Menu quick launch tab is activated. POC [https://github.com/zoogie/menuhax67 here].
| None
| [[11.13.0-45]]
|
| October 4, 2020
| September, 2020
| Zoogie
|-
| bossbannerhax
| After successfully loading [[Extended_Banner|extended-banner]] data(done when selecting an icon), Home Menu attempts to load "[[CBMD]]" data into a 0x100000-byte heap buffer from the [[BOSS_Services|stored]] SpotPass content. When successful and the magic-number is CBMD, Home Menu then decompresses the exbanner sections into another fixed-size heap buffer, without checking the outsize at all. The main CBMD CGFX code with ExeFS checks the size, but this code doesn't(however this is exbanner "CBMD", not a "normal" CBMD).

Used with menuhax as of v3.2.
| [[11.3.0-36|11.3.0-X]]
|
| [[1.0.0-0|1.0.0-0]]
| November 18, 2016
| December 23, 2014
| [[User:Yellows8|Yellows8]]
|-
| sdiconhax
| This is basically the same as nandiconhax, the vulnerable SD/NAND functions are ''identical'' minus the file-buffer offsets. Exploitation is different due to different heap-buffer location though. Unlike nandiconhax, the icon buffer for SD is located in linearmem(with recent Home Menu versions at least). This is used by [[menuhax]].
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
| July 27, 2016
| October 23, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[System_SaveData|NAND-savedata]] Launcher.dat icons (nandiconhax)
| The homemenu code processing the titleid list @ launcherdat+8 copies those titleIDs to another buffer, where the offset relative to that buffer is calculated using the corresponding s8/s16 entries. Those two values are not range checked at all. Hence, one can use this to write u64(s) with arbitrary values to before/after this allocated output buffer. See [[Home_Menu|here]] regarding Launcher.dat structure.

This can be exploited(with Launcher.dat loading at startup at least) by using a s16 for the icon entry with value 0xFFEC(-20)(and perhaps more icons with similar s16 values to write multiple u64s). The result is that the u64 value is written to outbuf-0xA0, which overwrites object+0(vtable) and object+4(doesn't matter here) for an object that gets used a bit after the vulnerable function triggers. The low 32bits of the u64 can then be set to the address of controlled memory(either outbuf in regular heap or the entire launcherdat buffer in linearmem), for use as a fake vtable in order to get control of PC. From there one can begin ROP via vtable funcptrs to do a stack-pivot(r4=objectaddr at the time the above object gets used).

Originally this vuln could only be triggered via Launcher.dat at Home Menu startup, right after Launcher.dat gets loaded + memory gets allocated, once the file-format version code is finished running. Starting with v9.6 this can be triggered when loading layouts from SD extdata as well. The vuln itself triggers before the layout data is written to Launcher.dat, but it doesn't seem to be possible to overwrite anything which actually gets used before the function which writes Launcher.dat into the layout gets called.

Home Menu has some sort of fail-safe system(or at least on v9.7) when Home Menu crashes due to Launcher.dat(this also applies for other things with Home Menu): after crashing once, Home Menu resets Launcher.dat to a state where it no longer crashes anymore. However, note that any exploits using this which hang/etc without crashing will still brick the system. '''Hence, attempting anything with this on physnand without hw-nand-access isn't really recommended.'''
| [[11.1.0-34|11.1.0-X]]
|
| [[4.0.0-7|4.0.0-X]]
|
| May 14, 2015
| [[User:Yellows8|Yellows8]]
|-
| Theme-data decompression buffer overflow ([[menuhax|themehax]])
| The only func-call size parameter used by the theme decompression function is one for the compressed size, none for the decompressed size. The decompressed-size value from the LZ header is used by this function to check when to stop decompressing, but this function itself has nothing to verify the decompressed_size with. The code calling this function does not check or even use the decompressed size from the header either.

This function is separate from the rest of the Home Menu code: the function used for decompressing themes is *only* used for decompressing themes, nothing else. There's a separate decompression function in Home Menu used for decompressing everything else.

That other decompression function in Home Menu handles decompression size properly(decompressed size check for max buffer size is done by code calling the other function, not in the function itself). Unlike the other function, the theme function supports multiple LZ algorithms, but the one which actually gets used in official themes is the same one supported by the other function anyway.

See also [[menuhax|here]].

With [[10.2.0-28|10.2.0-X]] Home Menu, the only code change was that the following was added right after theme-load and before actual decompression: "if(<get_lzheader_decompressed_size>(compressed_buf) > 0x150000)<exit>;". This fixed the vuln.
| [[10.2.0-28|10.2.0-X]]
| [[10.2.0-28|10.2.0-X]]
| <Old3DS/New3DS version which added initial theme support>
|
| December 22, 2014
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]] independently (~spring 2015)
|-
| Shuffle body-data buffer overflow ([[menuhax|shufflehax]])
| See [[menuhax|here]].
| [[10.6.0-31|10.6.0-X]]
| [[10.6.0-31|10.6.0-X]]
| [[9.3.0-21|9.3.0-X]]
|
| January 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| Extdata file-data loading buffer overflow
| The extdata file-reading code allocates a fixed-size heap buffer for the expected filesize, then reads the filedata into this buffer using the actual FS filesize. Before v5.0 the filesize used here wasn't validated, hence if the filesize is larger than alloc_size a buffer overflow would occur. ''After'' doing the file-read it does validate that the actual_readsize matches the alloc_size, but at this point the buffer overflow has already occurred.

This affected at least the following: SaveData.dat and Cache.dat.

This can be triggered with SaveData.dat by installing a <v4.0 Home Menu version, with Home Menu extdata from >=v4.0 still on SD. When this is done with v2.0 Home Menu, a kernelpanic occurs when processing an AM command(it appears a buffer ptr which is then passed to a command was overwritten with 0x0 - of course other SaveData.dat filesizes may result in different behaviour).
| [[5.0.0-11|5.0.0-X]]
|
| [[2.0.0-2|2.0.0-X]]
| June 9, 2016
| June 9, 2016
| [[User:Yellows8|Yellows8]]
|}

The icon data arrays used with {sd/nand}iconhax were added to SaveData.dat/Launcher.dat with [[4.0.0-7|4.0.0-X]], hence the vulnerable functions were added with that same version.

With <=v4.0 the SaveData.dat buffer is located in the regular heap. It's unknown when exactly it was moved to linearmem, which is where it's located with recent versions. It's located in linearmem for KOR >=v9.6 for example.

The SaveData.dat/Launcher.dat icon vulns were fixed by doing various unsigned >=60/>=360 checks on the loaded values. When these checks fail, it just skips over handling this icon entry. Hence, the original value can't be negative / out-of-bounds any more.

==Useless crashes==
Old3DS system web-browser:
* 2^32 characters long string(''finally'' fixed with v10.6): this is similar to the vulnerability fixed [http://git.chromium.org/gitweb/?p=external/Webkit.git;a=commitdiff;h=ec471f16fbd1f879cb631f9b022fd16acd75f4d4 here], concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vulnerability will cause a memory page permissions fault, since the WebKit code attempts to copy the string text data to the output buffer located in read-only [[CRO0|CRO]] heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is at the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some ''very'' rare cases a thread separate from the string data-copy thread will crash, this might be exploitable. However, this is mostly useless since it rarely crashes this way.

* Trying to directly load a page via the browser "URL" option with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] setup, causes a crash to trigger in oss.cro due to an use-after-free being caught with webkitdebug. This is presumably some sort of realloc() issue in the libcurl version used by the <={v10.2-v10.3} browser. This happens with *every* *single* *page* one tries to load via the "URL" option, but not when loading links on the current page, hence this is probably useless. A different use-after-free with realloc triggers with loading any page at all regardless of method too(libcurl probably).

* This WebKit build has ''a lot'' of crash-trigger bugs that only happen with [https://github.com/yellows8/3ds_browserhax_common webkitdebug] completely setup(addr accesses near 0x0), with ''just'' trying to load any page at all.

11.17.0-50

2023-05-29T18:38:51Z

PabloMK7:

The Old3DS+New3DS 11.17.0-50 system update was released on May 23, 2023 (UTC). This Old3DS update was released for the following regions: USA, EUR, and JPN. This New3DS update was released for the following regions: USA, EUR, and JPN.

Security flaws fixed: yes.

==Change-log==
[https://en-americas-support.nintendo.com/app/answers/detail/a_id/667/kw/system%20update Official] USA change-log:
* Further improvements to overall system stability and other minor adjustments have been made to enhance the user experience.
*

==System Titles==
The following titles were updated: [[CVer]]/[[NVer]], [[System Settings]], [[eShop]], [[Home Menu]] (USA-only), 0004001B00018002 (Web browser Data).

===System Settings===
Mset can now display the full DSiWare export banner string length without corrupting the stack. This fixes a nearly 4 year-old exploit, [https://github.com/zoogie/Bannerbomb3 Bannerbomb3].

The codebin in ExeFs was updated. RomFs only had localization updated, for USA-region this is: "/message_US_LZ.bin".

=== [[eShop]] ===
The codebin in ExeFs was updated. No RomFs changes.

=== [[Home Menu]] ===
The codebin in ExeFs was updated. No RomFs changes.

Code was added to POST a JSON to <code>https://ctr-o2fgs.cdn.nintendo.net/flags</code> with some privacy related settings. This mimics what the european Home Menu had been doing for some time. It's currently unknown if there are any more changes.

=== 0004001B00018002 ===
RomFs changes:
* "/index_US_English.html", "/index_US_French.html", "/index_US_Portuguese.html", "/index_US_Spanish.html" updated
* "/json/message_US_English.json", "/json/message_US_French.json", "/json/message_US_Portuguese.json", "/json/message_US_Spanish.json" updated
* "/version.txt" updated

==See Also==
System update report(s):
* [https://yls8.mtheall.com/ninupdates/reports.php?date=2023-05-23_00-00-33&sys=ctr]
* [https://yls8.mtheall.com/ninupdates/reports.php?date=2023-05-23_00-00-41&sys=ktr]

11.17.0-50

2023-05-29T18:37:58Z

PabloMK7: Added new home menu behaviour

The Old3DS+New3DS 11.17.0-50 system update was released on May 23, 2023 (UTC). This Old3DS update was released for the following regions: USA, EUR, and JPN. This New3DS update was released for the following regions: USA, EUR, and JPN.

Security flaws fixed: yes.

==Change-log==
[https://en-americas-support.nintendo.com/app/answers/detail/a_id/667/kw/system%20update Official] USA change-log:
* Further improvements to overall system stability and other minor adjustments have been made to enhance the user experience.
*

==System Titles==
The following titles were updated: [[CVer]]/[[NVer]], [[System Settings]], [[eShop]], [[Home Menu]] (USA-only), 0004001B00018002 (Web browser Data).

===System Settings===
Mset can now display the full DSiWare export banner string length without corrupting the stack. This fixes a nearly 4 year-old exploit, [https://github.com/zoogie/Bannerbomb3 Bannerbomb3].

The codebin in ExeFs was updated. RomFs only had localization updated, for USA-region this is: "/message_US_LZ.bin".

=== [[eShop]] ===
The codebin in ExeFs was updated. No RomFs changes.

=== [[Home Menu]] ===
The codebin in ExeFs was updated. No RomFs changes.
Some code was added to POST a JSON to <code>https://ctr-o2fgs.cdn.nintendo.net/flags</code> with some privacy related settings. This mimics what the european Home Menu had been doing for some time. It's currently unknown if there are any more changes.

=== 0004001B00018002 ===
RomFs changes:
* "/index_US_English.html", "/index_US_French.html", "/index_US_Portuguese.html", "/index_US_Spanish.html" updated
* "/json/message_US_English.json", "/json/message_US_French.json", "/json/message_US_Portuguese.json", "/json/message_US_Spanish.json" updated
* "/version.txt" updated

==See Also==
System update report(s):
* [https://yls8.mtheall.com/ninupdates/reports.php?date=2023-05-23_00-00-33&sys=ctr]
* [https://yls8.mtheall.com/ninupdates/reports.php?date=2023-05-23_00-00-41&sys=ktr]

NIM Services

2022-07-11T05:05:54Z

PabloMK7: No need to brag about it, people can know it's you from edit history.

[[Category:Services]]
= NIM updater service "nim:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| StartNetworkUpdate
|-
| 0x00020000
| GetProgress ([[NIMU:GetUpdateDownloadProgress|GetUpdateDownloadProgress]])
|-
| 0x00030000
| Cancel
|-
| 0x00040000
| CommitSystemTitles ([[NIMU:FinishTitlesInstall|FinishTitlesInstall]])
|-
| 0x00050000
| GetBackgroundEventForMenu (This obtains an event handle. Home Menu will check whether a system update is available when this event is triggered.)
|-
| 0x00060000
| GetBackgroundEventForNews
|-
| 0x00070000
| FormatSaveData (This deletes and recreates the system save data 0x0001002C (NIM System SaveData))
|-
| 0x00080000
| GetCustomerSupportCode
|-
| 0x00090000
| IsCommittableAllSystemTitles ([[NIMU:CheckSysupdateAvailable|CheckSysupdateAvailable]])
|-
| 0x000A0000
| GetBackgroundProgress (GetState)
|-
| 0x000B0000
| GetSavedHash ([[NIMU:GetSystemTitleHash|GetSystemTitleHash]])
|-
| 0x000C0082
| UnregisterTask
|-
| 0x000D0080
| IsRegistered
|-
| 0x000E0080
| FindTaskInfo
|-
| 0x000F0042
| GetTaskInfos
|-
| 0x00100000
| DeleteUnmanagedContexts
|-
|}

I'm not sure if these commands header exist...
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00110000
| ?
|-
| 0x00130000
| ?
|-
| 0x00140000
| ?
|-
| 0x00150000
| ?
|-
| 0x00170042
| ?
|-
| 0x00180080
| ?
|-
| 0x00250000
| ?
|-
| 0x00260200
| ?
|-
| 0x00270000
| ?
|-
| 0x00280000
| ?
|-
| 0x00290246
| RegisterTask
|-
| 0x002A0000
| ?
|-
| 0x002B0000
| ?
|-
| 0x002C0000
| ?
|-
| 0x002D00C0
| ?
|-
| 0x00480002
| ?
|-
|}

= NIM server service "nim:s" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010200
| [[NIMS:StartDownloadSimple|StartDownloadSimple]]
|-
| 0x00020000
| [[NIMS:CancelDownload|CancelDownload]]
|-
| 0x00030000
| [[NIMS:GetProgress|GetProgress]]
|-
| 0x00050082
| [[NIMS:UnregisterTask|UnregisterTask]]
|-
| 0x00060080
| [[NIMS:IsTaskRegistered|IsTaskRegistered]]
|-
| 0x000A0000
| [[NIMS:CheckSysupdateAvailableSOAP|CheckSysupdateAvailableSOAP]]
|-
| 0x000B0084
| [[NIMS:SetAttribute|SetAttribute]]
|-
| 0x0016020A
| [[NIMS:ListTitles|ListTitles]]
|-
| 0x00220080
| AccountDeleteTitleETicketsSOAP. The SOAP request is sent only after the ticket for the specified titleID has been successfully deleted.
|-
| 0x00290000
| [[NIMS:AccountCheckBalanceSOAP|AccountCheckBalanceSOAP]]
|-
| 0x002D0042
| [[NIMS:DownloadTickets|DownloadTickets]]
|-
| 0x003C0002
| [[NIMS:RegisterSelf|RegisterSelf]]
|-
| 0x003F0000
| GetInitializeResult. Checks whether nim is properly initialized or not. If it is not, the result code returned is non-zero.
|-
| 0x00420240
| [[NIMS:StartDownload|StartDownload]]
|-
| 0x00550246
| [[NIMS:RegisterTask|RegisterTask]]
|-
| 0x00570082
| [[NIMS:ConnectNoTicketDownload|ConnectNoTicketDownload]]
|}

= NIM server service "nim:aoc" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00030042
| SetApplicationId
|-
| 0x00040042
| SetTin
|-
| 0x000902D0
| ListContentSetsEx
|-
| 0x00180000
| GetBalance
|-
| 0x001D0000
| GetCustomerSupportCode
|-
| 0x00210000
| Initialize
|-
| 0x00240282
| CalculateContentsRequiredSize
|-
| 0x00250000
| RefreshServerTime
|}

= NIM service "nim:ndm" =

= kagiya server =
The nim system module communicates with a server called kagiya (kagiya-ctr.cdn.nintendo.net or kagiya-dev-ctr.cdn.nintendo.net for development units). It provides the 9.6 crypto seed in binary form for any given title ID under (HTTPS) kagiya-ctr.cdn.nintendo.net/title/0x%16llx/ext_key?country=%s, where %16llx is the title ID and %s is a country code as used in the [[EShop|eShop]].

=New3DS=
NIM module only uses [[PTMSYSM:CheckNew3DS|CheckNew3DS]] for determining what heap sizes to use, in two functions. One is for the size of the 0x08000000 vmem heap, the other is probably for some buffer allocated on that heap. The New3DS version of these sizes are 0x1C000-bytes larger than the Old3DS sizes here.

=HTTPS requests=

==Trusted RootCAs==
During startup NIM-module creates two RootCertChains with [[HTTP_Services|HTTPC]]. Both of these only contain the same [[HTTPC:RootCertChainAddDefaultCert|default]] cert with ID 0x3. The first RootCertChain is used with NetUpdateSOAP. Requests such as the "notifications.json" page don't use these RootCertChains(in this case just [[HTTPC:AddDefaultCert|default]] certID 0xB is used).

==SOAP==

===NetUpdateSOAP===
There are exactly 3 types of network SOAP requests used with [https://nus.c.shop.nintendowifi.net/nus/services/NetUpdateSOAP NetUpdateSOAP] by NIM module, described below. This URL contained in NIM module itself is only used with GetSystemTitleHash. The other requests use an identical URL loaded from an ECommerceSOAP response instead.

See also [https://github.com/yellows8/ninupdates here].

====GetSystemUpdate====
Returns the current sysupdate title-listing. This also contains the SystemTitleHash returned by GetSystemTitleHash.

====GetSystemTitleHash====
Returns the current SystemTitleHash for the current sysupdate title-listing.

====GetSystemCommonETicket====
Returns the Base64-encoded cetk for each specified TitleId entry.

This is only used when installing new titles. This means with CDN system-updates, tickets are never installed except when a title is being installed for the first time. For example, a system on the latest system-version that was only ever updated via CDN has the same NATIVE_FIRM ticket installed from the factory.

=Sysupdate checking process=
This section describes the process used when checking whether a sysupdate is required.

First the GetSystemTitleHash SOAP request is done. Then the SystemTitleHash in savedata hash.dat is compared with the received one. If they match and the SystemTitleHash flag is set to value 0x03, it will immediately return that no sysupdate is required. Otherwise it will start the GetSystemUpdate SOAP request handling.

The GetSystemUpdate SOAP request contains a titlelist of all NAND system-titles. For GetSystemUpdate response parsing, it compares each SOAP title_entry with the NAND system titlelist. If a SOAP titleID isn't found in the NAND titlelist, this means NAND is missing a new title and hence a sysupdate is required for installing that title. If a NAND title_entry-version is less than the SOAP title_entry-version, this means the title needs updated and hence a sysupdate is required.

At least one <TitleVersion> entry with valid data in the GetSystemUpdate response is required.

The titleIDs sent in the GetSystemUpdate SOAP request are decimal, while the titleIDs in the response are hex.

=NIM [[System_SaveData]]=
==hash.dat==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x60
| 0x1
| u8 flag used with the SystemTitleHash. 0x01 = latest sysupdate isn't installed as of last SOAP requests, 0x03 = latest sysupdate is installed as of last SOAP requests.
|-
| 0x61
| 0x21
| ASCII hex SystemTitleHash, including NUL-terminator. This is the latest SystemTitleHash which NIM module received from SOAP.
|}

=Types=
==InstallationMode==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| Initial installation
|-
| 1
| Unknown
|-
| 2
| Unknown
|-
| 3
| Reinstallation
|}
==DownloadState==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| Not initialized
|-
| 1
| Download initialized
|-
| 2
| Downloading, verifying and installing TMD
|-
| 3
| Initializing save data
|-
| 4
| Downloading and installing contents
|-
| 5
| Waiting before calling [[AM:CommitImportPrograms]]
|-
| 6
| Running [[AM:CommitImportPrograms]]
|-
| 7
| Title installation finished
|-
| 8
| Unknown error regarding title version
|-
| 9
| Creating the .ctx file (or error doing so)?
|-
| 10
| Irrecoverable error encountered
|}
==TitleConfig==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x8
| Title ID
|-
| 0x8
| 0x4
| Title version
|-
| 0xC
| 0x4
| Unknown (always 0)
|-
| 0x10
| 0x1
| Age rating for the HOME Menu parental controls
|-
| 0x11
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x12
| 0x2
| Padding
|-
| 0x14
| 0x4
| Unknown (always 0?)
|}
==TitleProgress==
{| class="wikitable" border="1"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| [[#DownloadState|Download State]]
|-
| 0x4
| 0x4
| Last result code in NIM related to the installation
|-
| 0x8
| 0x8
| Amount of bytes that have been downloaded
|-
| 0x10
| 0x8
| Total bytes that need to be downloaded
|}

Friend Services

2022-07-11T05:04:30Z

PabloMK7: No need to brag about it, people can know it's you from edit history.

[[Category:Services]]
= Friend Service "frd:u" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| [[FRDU:HasLoggedIn|HasLoggedIn]]
|-
| 0x00020000
| [[FRDU:IsOnline|IsOnline]]
|-
| 0x00030002
| [[FRDU:Login|Login]]
|-
| 0x00040000
| [[FRDU:Logout|Logout]]
|-
| 0x00050000
| [[FRDU:GetMyFriendKey|GetMyFriendKey]]
|-
| 0x00060000
| [[FRDU:GetMyPreference|GetMyPreference]]
|-
| 0x00070000
| [[FRDU:GetMyProfile|GetMyProfile]]
|-
| 0x00080000
| [[FRDU:GetMyPresence|GetMyPresence]]
|-
| 0x00090000
| [[FRDU:GetMyScreenName|GetMyScreenName]]
|-
| 0x000A0000
| [[FRDU:GetMyMii|GetMyMii]]
|-
| 0x000B0000
| [[FRDU:GetMyLocalAccountId|GetMyLocalAccountId]]
|-
| 0x000C0000
| [[FRDU:GetMyPlayingGame|GetMyPlayingGame]]
|-
| 0x000D0000
| [[FRDU:GetMyFavoriteGame|GetMyFavoriteGame]]
|-
| 0x000E0000
| [[FRDU:GetMyNcPrincipalId|GetMyNcPrincipalId]]
|-
| 0x000F0000
| [[FRDU:GetMyComment|GetMyComment]]
|-
| 0x00100040
| [[FRDU:GetMyPassword|GetMyPassword]]
|-
| 0x00110080
| [[FRDU:GetFriendKeyList|GetFriendKeyList]]
|-
| 0x00120042
| [[FRDU:GetFriendPresence|GetFriendPresence]]
|-
| 0x00130142
| [[FRDU:GetFriendScreenName|GetFriendScreenName]]
|-
| 0x00140044
| [[FRDU:GetFriendMii|GetFriendMii]]
|-
| 0x00150042
| [[FRDU:GetFriendProfile|GetFriendProfile]]
|-
| 0x00160042
| [[FRDU:GetFriendRelationship|GetFriendRelationship]]
|-
| 0x00170042
| [[FRDU:GetFriendAttributeFlags|GetFriendAttributeFlags]]
|-
| 0x00180044
| [[FRDU:GetFriendPlayingGame|GetFriendPlayingGame]]
|-
| 0x00190042
| [[FRDU:GetFriendFavoriteGame|GetFriendFavoriteGame]]
|-
| 0x001A00C4
| [[FRDU:GetFriendInfo|GetFriendInfo]]
|-
| 0x001B0080
| [[FRDU:IsIncludedInFriendList|IsIncludedInFriendList]]
|-
| 0x001C0042
| [[FRDU:UnscrambleLocalFriendCode|UnscrambleLocalFriendCode]]
|-
| 0x001D0002
| [[FRDU:UpdateGameModeDescription|UpdateGameModeDescription]]
|-
| 0x001E02C2
| [[FRDU:UpdateGameMode|UpdateGameMode]]
|-
| 0x001F0042
| [[FRDU:SendInvitation|SendInvitation]]
|-
| 0x00200002
| [[FRDU:AttachToEventNotification|AttachToEventNotification]]
|-
| 0x00210040
| [[FRDU:SetNotificationMask|SetNotificationMask]]
|-
| 0x00220040
| [[FRDU:GetEventNotification|GetEventNotification]]
|-
| 0x00230000
| [[FRDU:GetLastResponseResult|GetLastResponseResult]]
|-
| 0x00240040
| [[FRDU:PrincipalIdToFriendCode|PrincipalIdToFriendCode]]
|-
| 0x00250080
| [[FRDU:FriendCodeToPrincipalId|FriendCodeToPrincipalId]]
|-
| 0x00260080
| [[FRDU:IsValidFriendCode|IsValidFriendCode]]
|-
| 0x00270040
| [[FRDU:ResultToErrorCode|ResultToErrorCode]]
|-
| 0x00280244
| [[FRDU:RequestGameAuthentication|RequestGameAuthentication]]
|-
| 0x00290000
| [[FRDU:GetGameAuthenticationData|GetGameAuthenticationData]]
|-
| 0x002A0204
| [[FRDU:RequestServiceLocator|RequestServiceLocator]]
|-
| 0x002B0000
| [[FRDU:GetServiceLocatorData|GetServiceLocatorData]]
|-
| 0x002C0002
| [[FRDU:DetectNatProperties|DetectNatProperties]]
|-
| 0x002D0000
| [[FRDU:GetNatProperties|GetNatProperties]]
|-
| 0x002E0000
| [[FRDU:GetServerTimeInterval|GetServerTimeInterval]]
|-
| 0x002F0040
| [[FRDU:AllowHalfAwake|AllowHalfAwake]]
|-
| 0x00300000
| [[FRDU:GetServerTypes|GetServerTypes]]
|-
| 0x00310082
| [[FRDU:GetFriendComment|GetFriendComment]]
|-
| 0x00320042
| [[FRDU:SetClientSdkVersion|SetClientSdkVersion]]
|-
| 0x00330000
| [[FRDU:GetMyApproachContext|GetMyApproachContext]]
|-
| 0x00340046
| [[FRDU:AddFriendWithApproach|AddFriendWithApproach]]
|-
| 0x00350082
| [[FRDU:DecryptApproachContext|DecryptApproachContext]]
|}

= "frd:n" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010000
| GetHandleOfNdmStatusChangedEvent
|-
| 0x00020000
| Resume
|-
| 0x00030040
| SuspendAsync
|-
| 0x00040000
| QueryStatus
|}

= "frd:a" =

This contains a similar (probably the same) command handler from 0x0001.... to 0x002F.... as them in frd:u. In addition, it also contains

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x04050000
| Used in creating the user Mii. No cmdbuff parameters.
|-
| 0x04060042
| [[FRDA:AddFriendOnline|AddFriendOnline]]
|-
| 0x04090100
| [[FRDA:RemoveFriend|RemoveFriend]]
|-
| 0x040B00C0
| UpdatePrefrences
|-
| 0x040C0800
| Used in creating the user Mii. 128-byte struct as cmdbuff parameters.
|}

=HTTPS Requests=

==Trusted RootCAs==
No RootCertChain(s) are used. For the nasc site, friends-module uses [[HTTPC:AddDefaultCert]] with the following certIDs: 0x1, 0x2, and 0x3.

CSND:PlaySoundDirectly

2021-01-22T11:56:31Z

PabloMK7:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00040080]
|-
| 1
| Channel ID (Range [0-3])
|-
| 2
| Priority (Range [0-31])
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
This function plays a sound from the info stored in the CSND shared memory (Offset3). The '''Channel ID''' argument decides which channel the sound will play in (4 channels available). If the specified channel is already playing, the '''Priority''' argument defines the priority of the sound. If the priority is higher, the playing sound will stop and the new one will start playing (smaller value means higher priority). Passing an out of bounds value to the '''Channel ID''' argument makes the CSND module become unstable or crash.

3DS System Flaws

2021-01-22T11:44:27Z

PabloMK7: Found CSND crash.

Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].

=Stale / Rejected Efforts=
* In the early days of 3DS hacking, Neimod was working on a RAM dumping setup for a while. He has de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS's PCB up to a custom RAM dumping setup. He ''has'' published photos showing his setup to be working quite well, with the 3DS successfully booting up, but however, his flickr stream is now private along with most of his work and this method has been unreleased. RAM dumping can be done through homebrew now, making this method obsolete regardless.

==Tips and info==
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). A usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.

SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).

=System flaws=
== Hardware ==
{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| ARM9/ARM11 bootrom vectors point at uninitialized RAM
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM.
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.

This requires *very* *precise* timing for triggering the hardware fault.

It has been exploited by derrek to dump the ARM9 bootrom as of Summer 2015.
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.
| New3DS
| End of February 2014
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently
|-
| Missing AES key clearing
| The hardware AES engine does not clear keys when doing a hard reset/reboot.
| None
| New3DS
| August 2014
| Mathieulh/Others
|-
| No RAM clearing on reboots
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM/VRAM keeps its contents.
| None
| New3DS
| March 2014
| [[User:Derrek|derrek]]
|-
| 32bits of actual console-unique TWLNAND keydata
| On retail the 8-bytes at ARM9 address [[Memory_layout|0x01FFB808]] are XORed with hard-coded data, to generate the TWL console-unique keys, including TWLNAND. On Old3DS the high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).
| None
| New3DS
| 2012?
| [[User:Yellows8|Yellows8]]
|-
| DSi / 3DS-TWL key-generator
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.
This applies to the keyX/keyY too.

This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.
| None
| New3DS
| 2011
| [[User:Yellows8|Yellows8]]
|-
| 3DS key-generator
| The algorithm for generating the normal-keys for keyslots is cryptographically weak. As a result, it is easily susceptible to differential cryptanalysis if the normal-key corresponding to any scrambler-generated keyslot is discovered.

Several such pairs of matching normal-keys and KeyY values were found, leading to deducing the key-generator function.
| None
| New3DS
| February 2015
| [[User:Yellows8|Yellows8]], [[User:Plutooo|plutoo]]
|-
| RSA keyslots don't clear exponent when setting modulus
| The [[RSA_Registers|RSA keyslots]] are set by boot ROM to have four private RSA keys. The exponent value in the RSA registers is write-only and not readable.

However, when setting a keyslot's modulus, the RSA hardware leaves the exponent alone. This allows retrieving the exponent by doing a discrete logarithm of the output.

By setting the modulus to a prime number whose modular multiplicative order is "smooth" (that is, p-1 is divisible by only small prime numbers), discrete logarithms can be calculated quickly using the [[wikipedia:Pohlig-Hellman algorithm|Pohlig-Hellman algorithm]]. If the prime chosen is greater than the modulus, but the same bit size, the discrete logarithm is the private exponent.

This exploit's usefulness is limited: RSA keyslot 0 is only used in current firmware for deriving the 6.x save and 7.x NCCH keys, which were already known, and the other three keyslots are entirely unused. Additionally, with a boot ROM dump, this exploit is moot; these private keys are located in the protected ARM9 boot ROM.
| None
| New3DS
| March 2016
| [[User:Myria|Myria]]
|-
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] allowing acccess to AXIWRAM/FCRAM-BASE-memregion
| [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]] can be configured by anything with access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For example, this is an issue for any sysmodule that gets exploited and has access to this register memory-page(include one that's listed below).

See also "kernelhax via gspwn" below.
| None
| New3DS
| February 7, 2017
| [[User:Yellows8|Yellows8]]
|}

== Boot ROM ==
{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| FIRM partitions known-plaintext
| The [[Flash_Filesystem|FIRM partitions]] are encrypted with AES-CTR without a MAC. Since this works by XOR'ing data with a static (per-console in this case) keystream, one can deduce the keystream of a portion of each FIRM partition if they have the actual FIRM binary stored in it.

This can be paired with many exploits. For example, it allows minor FIRM downgrades (i.e. 10.4 to 9.6 or 9.5 to 9.4, but not 9.6 to 9.5).
However it is most commonly used to install arbitrary FIRMs (usually boot9strap), thanks to sighax.

This can be somewhat addressed by having a FIRM header skip over previously used section offsets, but this would just air-gap newer FIRMs without fixing the core bug. This can also only be done a limited number of times due to the size of FIRM versus the size of the partitions.
| None
| New3DS
|
| Everyone
|-
| Boot9 AES keyinit function issues
| [[Bootloader|Boot9]] seems to have two bugs in the AES key-init function, see [[AES_Registers#AES_key-init|here]].
| None
| BootROM issue.
| 2015
| [[User:Yellows8|Yellows8]]
|-
| New3DS has same boot ROM as Old3DS
| The New3DS has the exact same boot ROM as the Old3DS. This means, among other things, that all the same boot ROM flaws are present. Also, this meant that it is possible to boot Old3DS firmware on New3DS (see "CFG9_SYSPROT9 bit1 not set by Kernel9").
| None
| New3DS
| October 2014
| Everyone
|-
| sighax: Boot9 improper validation of FIRM partition RSA signatures
| The [[Flash_Filesystem|FIRM partitions]] are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5 padding. Boot9, however, improperly validates the padding in three ways:
# Boot9 permits block type 02, meant for encrypted messages, to be used for signatures. Only 01, for signatures, should have been permitted. As a result, when using block type 02, a signature block is not required to have a long string of FF bytes as padding, but rather any nonzero random values suffice.
# Boot9 does not require that the length of the padding fill out the signature block completely. As a result, there is considerable freedom in the layout of a signature.
# Boot9 fails to do bounds checking in its parsing of the DER-encoded hash algorithm type and hash value; the length values given in DER are permitted to point outside the signature block.
Flaw 3 allows the DER encoding to be such that boot9 believes that the signature's hash value is outside the range of the block itself, somewhere on the stack. This can be pointed at the correct hash value it computes. Boot9 then memcmp's the calculated hash against itself, and thinks that the hash is valid.

As a result of the above, we estimate that one in 2<sup>43</sup> (~8.8 trillion) random fake signatures will be considered by Boot9 to be valid. This is well within the range of brute force, particularly with an optimized GPU implementation. An Nvidia GTX 1080 Ti would take about one week to find a match.
| None
| New3DS
| July 2015
| [[User:Derrek|derrek]]
|-
| Boot9 FIRM loading doesn't blacklist memory-mapped I/O
| [[Bootloader|Boot9]]'s FIRM loading blacklists Boot9 data regions, but forgets to do other important regions, including Memory-mapped I/O. Combined with sighax, a malicious FIRM can be used to overwrite:
a) boot9 data-abort handler, coupled with a 4th section that tries to NDMA copy to NULL, causing a data abort

b) boot9 IRQ handler (this has the disadvantage that you must restore the original handler, then call it manually when your payload runs)
| None
| New3DS
| 2015(?)
| [[User:Derrek|derrek]] (2015?), [[User:Normmatt|Normmatt]] and [[User:SciresM|SciresM]] independently (January 2017).
|-
| "superhax": Boot9 FIRM loading blacklist check is flawed
| Boot9 only makes sure the '''start''' and '''end''' address of each section is not covered by a blacklisted region. Thus, it is possible to overwrite blacklisted regions (e.g. ARM9 Exception Vectors) by choosing a FIRM section range that encloses an entire blacklisted region. The vulnerable code looks like this: if(blRegions[i].start <= sectionStart && blRegions[i].end > sectionStart <nowiki>||</nowiki> blRegions[i].start <= sectionEnd && blRegions[i].end > sectionEnd) return false; // failure
The boot9 vector table (0x08000000) contains 6 entries, each 8-bytes wide (0x30 bytes); Only 0x08000000 through 0x08000040 are blacklisted, and boot9 doesn't use the region after the vector table (this is convenient because we can put any payload we want after it and not worry about overwriting chunks of boot9 code)

To exploit this, craft a FIRM section payload that's loaded a few bytes before 0x08000000, add padding to get to 0x08000000 and overwrite the vector table; You could overwrite the data-abort vector and craft a 4th FIRM section that causes a data-abort OR you can just overwrite the IRQ function pointer at 0x08000004 (make sure your payload replaces the original boot9 function pointer); you can point the rest of the vectors to infinite loops since they shouldn't be triggered.
| None
| New3DS
| August 2015
| [[User:Plutoo|plutoo]], [[User:Yellows8|yellows8]]
|}

== ARM9 software ==

=== arm9loader ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Generating the keysector console-unique keys with ITCM+Boot9
| [[Bootloader|Boot9]] decrypts the 0x100-byte [[OTP_Registers|OTP]] using AES-CBC with keydata stored in Boot9. If hash verification is successful, the plaintext of the first 0x90-bytes are copied into [[Memory_layout|ITCM]]. This is the ''exact'' ''same'' region hashed by arm9loader when generating the console-unique keys for decrypting the keysector, except arm9loader uses the raw encrypted OTP.

Therefore, with the OTP keydata+IV from Boot9 you can: encrypt the 0x90-bytes from ITCM, then hash the output to get the console-unique keys for the system's keysector. This can even be done for Old3DS which doesn't have the arm9loader keysector officially.

It's unknown why arm9loader only used the first 0x90-bytes of OTP. Using more data from OTP would've prevented this. Fixing this would require doing exactly that, but that would also mean updating the NAND keysector(which is dangerous).
| See description.
| None
|
| 2015
| January 6, 2017
| [[User:Yellows8|Yellows8]]
|-
| Rearrangable keys in the NAND keystore
| Due to the keystore being encrypted with AES-ECB, one can rearrange blocks and still have the NAND keystore decrypt in a deterministic way.

Using 10.0 FIRM it is possible to rearrange keys such that ARM9 memory is executed. As such using existing ARM9 execution 10.0 FIRM can be written to NAND and a payload written to memory, with the payload to be executed post-K9L using an MCU reboot.
| arm9loaderhax given existing ARM9 code execution
| None
| [[11.3.0-36|11.3.0-X]]
| Early 2016
| 27 September 2016
| Myria, [[User:Dark samus|dark_samus]]; mathieulh (independently); [[User:Plutooo|plutoo]] (independently) + others
|-
| Uncleared OTP hash keydata in console-unique 0x11 key-generation
| Kernel9Loader does not clear the [[SHA_Registers#SHA_HASH|SHA_HASH register]] after use. As a result, the data stored here as K9L hands over to Kernel9 is the hash of [[OTP_Registers|OTP data]] used to seed the [[FIRM#New_3DS_FIRM|console-unique NAND keystore decryption key]] set on keyslot 0x11.

Retrieving this keydata and the [[Flash_Filesystem#0x12C00|NAND keystore]] of the same device allows calculating the decrypted New3DS NAND keystore (non-unique, common to all New3DS units), which contains AES normal keys, also set on keyslot 0x11, which are then used to derive all current [[AES_Registers#Keyslots|New3DS-only AES keyXs]] including the newer batch introduced in [[9.6.0-24#arm9loader|9.6.0-X]]. From there, it is trivial to perform the same key derivation in order to initialize those keys on any system version, and even on Old3DS.

This can be performed by exploiting the "arm9loaderhax" vulnerability to obtain post-K9L code execution after an MCU reboot (the bootrom section-loading fail is not relevant here, this attack was performed without OTP data by brute-forcing keys), and using this to dump the SHA_HASH register. This attack works on any FIRM version shipping a vulnerable version of K9L, whereas OTP dumping required a boot of <[[3.0.0-6|3.0.0-X]].

This attack results in obtaining the entire (0x200-bytes) NAND keystore - it was confirmed at a later date that this keystore is encrypted with the same key (by comparing the decrypted data from multiple units), and therefore using another key in this store will not remedy the issue as all keys are known (i.e. later, unused keys decrypt to the same 0x200-bytes constant with the same OTP hash). Later keys could have been encrypted differently but this is not the case. As a result of this, it is not possible for Nintendo to use K9L again in its current format for its intended purpose, though this was not news from the moment people dumped a New3DS OTP.
| Derivation of all New3DS keys generated via the NAND keystore (0x1B "Secure4" etc.)
| None
| [[11.3.0-36|11.3.0-X]]
| ~April 2015, implemented in May 2015
| 13 January 2016
| [[User:WulfyStylez|WulfyStylez]], [[User:Dazzozo|Dazzozo]], [[User:Shinyquagsire23|shinyquagsire23]] (complimentary + implemented), [[User:Plutooo|plutoo]], Normmatt (discovered independently)
|-
| enhanced-arm9loaderhax
| See the 32c3 3ds talk.
Since this is a combination of a trick with the arm9-bootrom + arm9loaderhax, and since you have to manually write FIRM to the firm0/firm1 NAND partitions, this can't be completely fixed. Any system with existing ARM9 code execution and an OTP/OTP hash dump can exploit this. Additionally, by using the FIRM partition known-plaintext bug and bruteforcing the second entry in the keystore, this can currently be exploited on all New3DS systems without any other prerequisite hacks.
| arm9loaderhax which automatically occurs at hard-boot.
| See arm9loaderhax / description.
| See arm9loaderhax / description.
| Theorized around mid July, 2015. Later implemented+tested by [[User:Plutooo|plutoo]] and [[User:Derrek|derrek]].
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| arm9loaderhax: Missing verification block for the 9.6 keys
| Starting with [[9.6.0-24|9.6.0-X]] a new set of NAND-based keys were introduced. However, no verification block was added to verify that the new key read from NAND is correct. This was technically an issue from [[9.5.0-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|9.6.0-X]] since keyslots 0x15 and 0x16 are generated from different 0x11 keyXs.

Writing an incorrect key to NAND will cause arm9loader to decrypt the ARM9 kernel as garbage and then jump to it.

This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.

This gives very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|save]], and 7.x [[NCCH]] keys. This cannot be used to recover keys initialized by arm9loader itself. This is due to it wiping the area used for its stack during NAND sector decryption and keyslot init.

Due to FIRMs on both Old and New 3DS using the same RSA data, this can be exploited on Old3DS as well, but only if one already has the actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has dumped the OTP area of the Old3DS.
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key, access to uncleared OTP hash keydata
| None
| [[11.3.0-36|11.3.0-X]]
| March 2015
|
| [[User:Plutooo|plutoo]]
|-
| arm9loader runs on Old3DS
| Despite being written only for New3DS, all of arm9loader runs fine on Old3DS. It's not until booting Kernel9 that a New3DS FIRM partition would crash on an Old3DS. As a result, if a bug exists in arm9loader to get control, it can be exploited on Old3DS by writing New3DS FIRM to the FIRM partitions. Thus, arm9loaderhax works on both Old3DS and New3DS.
| arm9loader bugs also compromise Old3DS
| None
| [[11.3.0-36|11.3.0-X]]
| Sometime in 2015
|
| [[User:Plutooo|plutoo]] presumably
|-
| Uncleared New3DS keyslot 0x11
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|9.5.0-X]] by completely clearing keyslot 0x11 immediately after the loader finishes using keyslot 0x11.
This means that any ARM9 code that can execute before the loader clears the keyslot at firmlaunch(including firmlaunch-hax) can get access to the uncleared keyslot 0x11, which then allows one to generate all <=v9.5 New3DS keyXs which are generated by keyslot 0x11.

Therefore, to completely fix this the loader would have to generate more keys using different keyslot 0x11 keydata. This was done with [[9.6.0-24|9.6.0-X]].
| New3DS keyXs generation
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].
|
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)
|
| [[User:Yellows8|Yellows8]]
|}

=== Process9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Public disclosure timeframe
! Discovered by
|-
| Leak of normal-key matching a key-scrambler key
| New 3DS firmware versions [[8.1.0-0 New3DS|8.1.0]] through [[9.2.0-20|9.2.0]] set the encryption key for [[Amiibo]] data using a hardcoded normal-key in Process9. In firmware [[9.3.0-21|9.3.0]], Nintendo "fixed" this by using the key scrambler instead, by calculating the keyY value for keyslot 0x39 that results in the same normal-key, then hardcoding that keyY into Process9.

Nintendo's fix is actually the problem: Nintendo revealed the normal-key matching an unknown keyX and a known keyY. Combined with the key scrambler using an insecure scrambling algorithm (see "Hardware" above), the key scrambler function could be deduced.
| Deducing the keyX for keyslot 0x39 and the key scrambler algorithm
| New 3DS [[9.3.0-21|9.3.0-X]], sort of
| [[10.0.0-27|10.0.0-X]]
| Sometime in 2015 after the hardware key-generator was broken.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| Leak of normal-key matching a key-generator key
| During the 3DS' development (June/July 2010) Nintendo added support installing encrypted content ([[CIA]]). Common-key index1 was intended to be a [[AES|hardware generated key]]. However while they added code to generate the key in hardware, they forgot to remove the normal-key for index1 (used elsewhere, likely old debug code). Nintendo later removed the normal key sometime before the first non-prototype firmware release.

Knowing the keyY and the normal-key for common-key index1, the devkit key-generator algorithm can be deduced (see "Hardware" above). Additionally the remaining devkit common-keys can be generated once the common-key keyX is recovered.

Note that the devkit key-generator was discovered to be the same as the retail key-generator.
| Deducing the keyX for keyslot 0x3D and hardware key-generator algorithm. Generate remaining devkit common-keys.
| pre-[[1.0.0-0|1.0.0-X]]
|
| Shortly after the key-generator was revealed to be flawed at the 32c3 3ds talk
| January 20, 2016
| [[User:Jakcron|jakcron]]
|-
| Factory firmware is vulnerable to sighax
| During the 3DS's development, presumably boot9 was written (including the sighax vulnerability). This vulnerability is also present in factory firmware (and earlier, including 0.11). This was fixed in version 1.0.0-0.
| Deducing the mechanics of the sighax vulnerability in boot9 without having a dump of protected boot9. ARM9 code execution on factory/earlier firmware.
| [[1.0.0-0|1.0.0-X]]
| [[1.0.0-0|1.0.0-X]]
| May 9, 2017
| May 19, 2017
| [[User:SciresM|SciresM]], [[User:Myria|Myria]]
|-
| safecerthax
| O3DS & O2DS SAFE_FIRM is still vulnerable to the PXIAM:ImportCertificates flaw fixed in [[5.0.0-11]] and to SSLoth fixed in [[11.14.0-46]]. It makes it possible to spoof the official NUS update server and remotely trigger the vulnerability in SAFE_FIRM.
| Remote Arm9 code execution in O3DS/O2DS SAFE_FIRM
| None
| [[11.14.0-46|11.14.0-X]]
| 2020
| December 18, 2020
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| twlhax: Corrupted SRL header leads to memory overwrite
| During TWL_FIRM boot, the ARM11 process TwlBg puts launcher.srl, the DSi bootloader, into FCRAM. TWL_FIRM Process9 then parses the [http://dsibrew.org/wiki/NDS_Format SRL header] to place launcher.srl's code where DSi mode can execute it.

DSi-mode memory is in FCRAM, but interleaved. Each byte of DSi-mode memory also exists at some address in 3DS FCRAM space.

Process9 does not validate the RSA signature on launcher.srl, unlike SRLs loaded from cartridge or NAND (DSiWare). A compromised ARM11 can, in a manner similar to firmlaunchhax, send a launcher.srl with a modified SRL header. By setting the SRL header's ARM7/ARM9 load addresses and sizes carefully, accounting for the different memory map and for DSi mode's interleaved memory, it is possible to overwrite part of Process9's stack and take control with a ROP chain.

Fixed in 11.8.0-X by... (fill me in)
| ARM9 code execution (whilst still in 3DS mode)
| [[11.8.0-41|11.8.0-X]]
| [[11.8.0-41|11.8.0-X]]
|
| August 11, 2018
| smea
|-
| agbhax
| This is the same issue as twlhax above. Legacy FIRMs share the same OS code (Arm9-side OS, Arm11 kernel), and therefore, the outdated AGB_FIRM can be tricked into executing the still vulnerable PrepareArm9ForTwl function.
| ARM9 code execution (whilst still in 3DS mode)
| None
| [[11.14.0-46|11.14.0-X]]
|
| December 17, 2020
| Everyone
|-
| safefirmhax
| SAFE_MODE_FIRM is almost never updated(even when NATIVE_FIRM is updated for vuln fixes), this can be noticed by ''just'' checking 3dbrew/ninupdates title-listings.

The fix for firmlaunch-hax was only applied to NATIVE_FIRM in [[9.5.0-22|9.5.0-X]], leaving SAFE_FIRM exploitable. With ARM11-kernel execution, one can trigger FIRM-launch in to SAFE_FIRM, do Kernel9 <=> Kernel11 sync, PXI sync and then repeat the original attack on SAFE_FIRM instead.
| ARM9 code execution
| [[11.3.0-36|11.3.0-X]]
|
| 2012-2013?
| Wiki: January 2, 2017
| Everyone
|-
| safefirmhax 1.1
| Nintendo's original safefirmhax fix was flawed -- they added a global boolean that got set to true whenever a non-sysmodule title got launched (except for a hardcoded repair title id), and panic()'d if that boolean was true to prevent launching safefirm after hax was active. However, because the boolean was initially false after firmlaunch -- With ARM11-kernel execution, one could FIRM-launch into NATIVE_FIRM, and then immediately FIRM-launch again into SAFE_FIRM early in NATIVE_FIRM boot before the boolean got set to true to repeat the safehax attack.

This was fixed by adding additional CFG9_BOOTENV checks to firmlaunch code in 11.4.
| ARM9 code execution
| [[11.4.0-37|11.4.0-X]]
|
| safefirmhax fix
| Wiki: April 10, 2017
| Everyone
|-
| ntrcardhax
| When reading the banner of a NTR title, Process9 relies on a hardware register to know when the banner was fully read.
However that register is shared between the ARM9 and the ARM11.
An attacker with k11 control can so make Process9 believe the banner continues forever and so trigger a buffer overflow.
With a custom banner for a NTR flashcart, this leads to code execution in Process9.

This was fixed by adding bound checks on the read data.
| ARM9 code execution
| [[10.4.0-29|10.4.0-X]]
|
| March 2015
| 32c3 3ds talk (December 27, 2015)
| [[User:Plutooo|plutoo]]
|-
| Title downgrading via [[Application_Manager_Services|AM]]([[Application_Manager_Services_PXI|PXI]])
| When a title is *already* installed, Process9 will compare the installed title-version with the title-version being installed. When the one being installed is older, Process9 would return an error.

However, this can be bypassed by just deleting the title first via the service command(s) for that: with the title removed from the [[Title_Database]], Process9 can't compare the input title-version with anything. Hence, titles can be downgraded this way.

[[11.0.0-33|11.0.0-X]] fixed this for key system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module), by checking the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs.
| Bypassing title version check at installation, which then allows downgrading any title.
| [[11.0.0-33|11.0.0-X]], for key system titles.
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]
| ?
|
| ?
|-
| Anti-downgrade list did not include all system titles initially
| The anti-downgrade list did not include legacy FIRMs until [[11.8.0-41|11.8.0-X]]. Therefore, legacy FIRMs could still be downgraded.
| Downgrading legacy FIRMs; allowing to exploit bugs in older legacy FIRMs (of which at least one exists, see below).
| [[11.8.0-33|11.8.0]]
| [[11.8.0-33|11.8.0]]
| ?
| Wiki: August 5, 2018
| Everyone
|-
| TWL_FIRM cmd-9 unchecked offset
| In [[1.0.0-0|1.0.0-X]]'s TWL_FIRM, cmds 8 and 9 were not stubbed (whereas in the corresponding NATIVE_FIRM, they were).
Command 8 does the Process9 initialisation for NTR carts if an NTR cart is inserted (NTR, not TWL, judged by chipid).

Command 9 takes (u32 offset_read, u32 offset_write, u32 offset_read_end), and basically just copies (offset_read_end - offset_read) bytes starting at (offset_read) of [NTR cart header in arm9mem, NTR secure area in fcram, TWL secure area in fcram], to 0x18001000 + offset_write + offset_read.

offset_write is not checked at all, thus this leads to ARM9 code execution as long as any NTR cart, including flashcarts that would normally be blocked by TWL_FIRM, is inserted.

In [[2.0.0-2|2.0.0-X]] TWL_FIRM, those commands were stubbed out.
| ARM9 code execution
| [[2.0.0-2|2.0.0-X]]
| [[2.0.0-2|2.0.0-X]]
| January 2018
| Wiki: August 5, 2018
| [[User:Riley|Riley]]
|-
| FIRM launch doesn't check target FIRM version
| When executing a FIRM launch, Process9 doesn't validate that the target FIRM isn't an old version. This allows booting an exploitable FIRM from a newer FIRM, if you can get the exploitable FIRM installed. ([[11.0.0-33|11.0.0-X]] now prevents installing old versions of system titles, but this doesn't affect titles already installed.)

This had a use after [[9.6.0-24|9.6.0-X]]: on a compromised 3DS running 9.2.0, you could install the 9.6.0 NATIVE_FIRM to FIRM0/FIRM1, but avoid putting it into the NATIVE_FIRM title. This would boot the 9.2.0 system software but with the 9.6.0 Process9 and Kernel11. With a user-mode exploit in a sufficiently-privileged application (e.g. mset), you could trigger a FIRM launch back to NATIVE_FIRM, which would load the 9.2.0 Process9 and Kernel11.

9.6.0's keyslots 0x15 and 0x16 are unknown to 9.2.0, so 9.2.0 would not clear them. You then could do firmlaunchhax against 9.2.0 to get ARM9 access with keyslots 0x15 and 0x16 set to their proper 9.6.0 values, allowing decrypting 9.6.0's encrypted titles. Once the New3DS keystore was dumped, this became moot.
| Decrypting 9.6.0 NCCH files without dumping New3DS keystore
| None (but now moot)
| [[9.6.0-24|9.6.0-X]]
| March 2015
| August 12, 2018
| [[User:Yellows8|Yellows8]], [[User:Myria|Myria]]
|-
| FAT FS code null-deref
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.

Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:

<pre>...
Starting check/repair pass.
<FilePath0> and
<FilePath1>
share clusters.
Truncating second to 3375104 bytes.
<FilePath1>
File size is 2787392 bytes, cluster chain length is 16384 bytes.
Truncating file to 16384 bytes.
Checking for unused clusters.
Reclaimed 1 unused cluster (16384 bytes).
Checking free cluster summary.
Free cluster summary wrong (1404490 vs. really 1404491)
Auto-correcting.
Starting verification pass.
Checking for unused clusters.
Leaving filesystem unchanged.</pre>
| Useless null-based-read
| None
| [[9.6.0-24|9.6.0-X]]
| July 8-9, 2015
|
| [[User:Yellows8|Yellows8]]
|-
| RSA signature padding checks
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|here]].
The main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM) uses the function used with the above to extract more padding + the actual hash from the additional padding. This isn't really a problem here because there's proper padding check code which is executed prior to this.
|
| None
| [[9.5.0-22|9.5.0-X]]
| March 2015
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ValidateDSiWareSectionMAC]] [[AES_Registers|AES]] keyslot reuse
| When the input DSiWare section index is higher than <max number of DSiWare sections supported by this FIRM>, Process9 uses keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40. The result is that the keyslot is left at whatever was already selected before, since the AES selectkeyslot code will immediately return when keyslot is >=0x40. However, actually exploiting this is difficult: the calculated AESMAC is never returned, this command just compares the calculated AESMAC with the input AESMAC(result-code depends on whether the AESMACs match). It's unknown whether a timing attack would work with this.
This is basically a different form of the pxips9 keyslot vuln, except with AESMAC etc.
| See description.
| None
| [[11.3.0-36|11.3.0-X]]
| March 15, 2015
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| pxips9 [[AES_Registers|AES]] keyslot reuse
| This requires access to the [[Process_Services|ps:ps]]/pxi:ps9 services. One way to get access to this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).
When an invalid key-type value is passed to any of the PS commands, Process9 will try to select keyslot 0x40. That aesengine_setkeyslot() code will then immediately return due to the invalid keyslot value. Since that function doesn't return any errors, Process9 will just continue to do crypto with whatever AES keyslot was selected before the PS command was sent.
| Reusing the previously used keyslot, for crypto with PS.
| None
| [[11.3.0-36|11.3.0-X]]
| Roughly the same time(same day?) as firmlaunch-hax.
| December 29, 2015
| [[User:Yellows8|Yellows8]]
|-
| firmlaunch-hax: FIRM header ToCToU
| This can't be exploited from ARM11 userland.
During [[FIRM]] launch, the only FIRM header the ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used FIRM RSA signature is read to the Process9 stack however). The ARM9 doesn't expect "anything" besides the ARM9 to access this data.
With [[9.5.0-22]] the address of this FIRM header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.
| ARM9 code execution
| [[9.5.0-22]]
|
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.
|
| [[User:Yellows8|Yellows8]]
|-
| Uninitialized data output for (PXI) command replies
| PXI commands for various services(including some [[Filesystem_services_PXI|here]] and many others) can write uninitialized data (like from ARM registers) to the command reply. This happens with stubbed commands, but this can also occur with certain commands when returning an error.
Certain ARM11 service commands have this same issue as well.
|
| None
| [[9.3.0-21|9.3.0-X]]
| ?
|
| [[User:Yellows8|Yellows8]]
|-
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.
|
| None
| [[9.3.0-21|9.3.0-X]]
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ExportDSiWare]] export path
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.
| None
| [[9.5.0-22]]
| April 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[DSiWare_Exports]] [[CTCert]] verification
| Just like DSi originally did, 3DS verifies the APCert for DSiWare on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed with with system-version 1.4.2 by verifying with the actual console-unique cert instead(stored in NAND), while on 3DS it's still not fixed.
On 3DS this is used in conjunction with seedminer to be able to decrypt & modify DSiWare TAD containers and inject them with exploitable DSiWare titles such as sudoku (sudokuhax) and Flipnote JPN (ugopwn)
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.
| None.
| 11.10.0-X
| April 2013
|
| [[User:Yellows8|Yellows8]]
|-
| seedminer: movable.sed keyY vulnerable to brute-force
| Half of the movable.sed keyY's 128 bits are leaked through the [[Nandrw/sys/LocalFriendCodeSeed_B|LFCS]], which is available in userland and below. The LFCS itself also leaks almost half of the remaining bits by following the ratio: u32 keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can be greatly reduced by plotting expected error margins with several keyYs. This results in a final uncertainty of about 2^40, easily within practical brute force range of an average modern PC.
| Knowing the keyY of a given 3ds allows for modification of DSiWare export contents, and chained with several other public vulns, ultimately arm9 execution.
| None.
| 11.8.0-X
| December 2017
| January 2018
| zoogie
|-
| Improper validation of DSiWare title SRLs
| The 3DS does not verify if the actual SRL embedded in the title's directory matches the titleID in the TMD before launching it or importing it from an sd DSiWare export.
| This allows embedding older, exploitable DSiWare titles in completely different, unexploitable DSiWare titles. Since DSiWare has raw NAND RW, this can result in arm9 control through FIRM known-plaintext and sighax attacks.
| None.
| 11.10.0-X
| 2015?
| December 2016
| Everyone
|-
| DSiWare import/export functions allow TWL system titles as arguments
| AM ImportTwlBackup/ExportTwlBackup unnecessarily allow TWL system titles such as DS Download Play to import/export from userland and System Settings -> Data Management (only am:sys is needed for userland). This is difficult to abuse for dsihax injection because no TWL system title has a save file, and any import with a save included will result in FS err C8804464. However, there is at least one dsihax primary that can load a payload from a non-NAND source, and not error if it can't access its public.sav (JPN Flipnote Studio v0).
| When combined with other public vulns, arm9 code execution.
| None.
| 11.10.0-X
| May 2018
| Sept 2018
| zoogie
|-
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|5.0.0-X]] this u8 value wasn't checked, thus out-of-bounds reads could be triggered(which is rather useless in this case).
| Out-of-bounds read for a value which gets written to a register.
| [[5.0.0-11|5.0.0-X]]
|
| 2013?
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] cmdbuf buffer overrun
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable.
| Probably ARM9 code execution
| [[5.0.0-11|5.0.0-11]]
|
| March 2015, original timeframe if any unknown
|
| [[User:Plutooo|plutoo]]/[[User:Yellows8|Yellows8]]/maybe others(?)
|-
| [[Application_Manager_Services_PXI|PXIAM]]:ImportCertificates (See also [[Application_Manager_Services|this]])
| When handling this command, Process9 allocates a 0x2800-byte heap buffer, then copies the 4 FCRAM input buffers to this heap buffer without checking the sizes at all(only the buffers with non-zero sizes are copied). Starting with [[5.0.0-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| May 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[Process_Services_PXI|PS RSA]] commands buffer overflows
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. SignRsaSha256 also has a buf overflow, but this isn't exploitable.
The buffer for this is the buffer for the signature data. With v5.0, the signature buffer was moved to stack, with a check for the signature data size. When the signature data size is too large, Process9 uses [[SVC|svcBreak]].
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| 2012
|
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] pxi_id bad check
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:
* They used it as index to a lookup-table without checking the value at all.
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.
| Maybe ARM9 code execution
| [[3.0.0-5|3.0.0-5]]
|
| March 2015, originally 2012 for the first issue at least
|
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]], maybe others(?)
|}

=== Kernel9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[CONFIG Registers#CFG9_SYSPROT9|CFG9_SYSPROT9]] bit1 not set by Kernel9
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG9_SYSPROT9|CFG9_SYSPROT9]]. This leaves the [[OTP Registers|0x10012000]]-region unprotected (this region should be locked early during boot!). Since it's never locked, you can dump it once you get ARM9 code execution.

From [[3.0.0-5|3.0.0-X]] this was fixed by setting the bit in Kernel9 after poking some registers in that region. On New3DS arm9loader sets this bit instead of Kernel9, which is exploitable through a hardware + software vulnerability (see arm9loaderhax / description).

This flaw resurged when it gained a new practical use: retrieving the OTP data for a New3DS console in order to decrypt the key data used in arm9loader (see enhanced-arm9loaderhax / description). This was performed by downgrading to a vulnerable system version. By accounting for differences in CTR-NAND crypto (0x05 -> 0x04, see partition encryption types [[Flash_Filesystem#NAND_structure|here]]) and using an Old3DS [[NCSD#NCSD_header|NCSD Header]], it is possible to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required OTP data using this flaw.
| Dumping the [[OTP Registers|OTP]] area.
Decrypting New3DS sector 0x96 keyblock.
| [[3.0.0-5|3.0.0-X]]
|
| February 2015
| [[User:Plutooo|plutoo]], Normmatt independently
|}

== ARM11 software ==
=== Kernel11 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[SVC|svcUnbindInterrupt]] double free when irqId = 15
| svcBindInterrupt and svcUnbindInterrupt give special treatment to irqId 15 (FIQ helper): the access control list is bypassed and the provided KInterruptEvent (event or semaphore, via handle) is stored inside a singleton static object after having its refcount increased by 1.

svcUnbindInterrupt assumes that the user-provided handle is what is stored in the singleton and will decref the user-provided KInterruptEvent twice, causing a use-after-free if the attacker didn't actually provide an handle to the same event or semaphore.

This was "fixed" on [[11.14.0-46|11.14.0-X]] by preventing irqId 15 to be bound on retail units altogether (in both functions).
| Arm11 kernel code execution
| [[11.14.0-46|11.14.0-X]] (only on retail units)
| [[11.14.0-46|11.14.0-X]]
| 2019
| [[User:TuxSH|TuxSH]], maybe others
|-
| [[SVC|svcKernelSetState]] op=3 could map the NULL page
| svcKernelSetState op=3 param1=1 maps the firmlaunch parameters page to the user-specified VA.

It had previously no check, allowing the attacker to map data at VA 0.

Starting from [[11.14.0-46|11.14.0-X]], the VA must be in the standard 0x10000000-0x14000000 address range.
| Mapping the NULL page (as RW) to leverage other kernel vulnerabilities
| [[11.14.0-46|11.14.0-X]]
| [[11.14.0-46|11.14.0-X]]
| 2019
| [[User:TuxSH|TuxSH]]
|-
| [[SVC|svcMapProcessMemory]] can map the NULL page
| svcMapProcessMemory's destination VA is unchecked.

By passing a big enough "size" parameter, an attacker can map chunks of data at VA 0 in the destination (caller) process.
| Mapping the NULL page (as RW) to leverage other kernel vulnerabilities
| None
| [[11.14.0-46|11.14.0-X]]
| 2020
| [[User:TuxSH|TuxSH]]
|-
| Resource limit use-after-free
| When assigning a KResourceLimit to a KProcess, the reslimit's refcounter doesn't get incremented. This essentially means all KResourceLimit get freed if pm gets somehow terminated.

It turns out it is possible to ask pm (via ns:s or pm:app) to terminate itself along all other KIPs simply by passing TID 0004000100001000.

Calling [[SVC|svcGetResourceLimit]] afterwards triggers a use-after-free. This is rather difficult to exploit, however: there is one slot left in the reslimit slabheap. An attacker either has to map the NULL page as R(W)X (svcControlProcessMemory vuln fixed on [[11.8.0-41|11.8.0-X]]), or use one of the map-null exploits above while having access to svcCreateResourceLimit (with the only one that is easy enough to use in that context having been fixed on [[11.14.0-46|11.14.0-X]], anyway).
| Arm11 kernel code execution
| None (although near impossible to exploit on [[11.14.0-46|11.14.0-X]])
| [[11.14.0-46|11.14.0-X]]
| 2020
| [[User:TuxSH|TuxSH]]
|-
| [[SVC|svcSetProcessIdealProcessor]] reference count overflow and therefore use-after-free.
| The SVC receive two arguments: handle and idealprocessor. The handle is used to get the KProcess object and the KProcess->refCnt gets incremented,later the function check if the KProcess->mem_type != BASE and if yes, it checks for idealprocessor == 2 or idealprocessor != 3. The problem here is that if you pass the idealprocessor = 3 it won't meet any condition and return the error 0xD9001BEA without decrement the reference count.
It can be abused to overflow the KProcess reference count that will lead to an Use-after-free.
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free.
|
| [[11.6.0-39|11.6.0-X]]
| November 2, 2017
| [[User:st4rk|st4rk]]
|-
| [[SVC|svcGetThreadList]] process reference leak
| When given a valid process handle (including <code>0xFFFF8001</code>), svcGetThreadList forgets to decrement the reference count of the underlying [[KProcess]] instance, after having finished using it.
| Before [[11.2.0-35|11.2.0-X]]: reference count overflow and therefore use-after-free, but this UAF was most likely not exploitable
|
| [[11.3.0-36|11.3.0-X]]
| April 3, 2017
| [[User:TuxSH|TuxSH]]
|-
| kernelhax via gspwn
| Originally the kernel didn't initialize [[CONFIG11_Registers#CFG11_GPUPROT|CFG11_GPUPROT]]. Since it's 0 at hard-boot, this allowed the GPU to access the entire FCRAM + AXIWRAM.
| Entire FCRAM+AXIWRAM R/W.
| [[3.0.0-5|3.0.0-X]]
|
| February 7, 2017
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] partly
|-
| fasthax
| When a KTimer is created in pulse mode, the kernel calls a virtual function to reset the timer each time it pulses. The scheduler is locked for that core to avoid race conditions, but another core can call CloseHandle on the timer and free it, leading to a UAF vtable call.
| See description.
| [[11.3.0-36|11.3.0-X]]
| [[11.3.0-36|11.3.0-X]]
| May 2016
| nedwill
|-
| ipctakeover
| When sending cmdreplies, it does not validate that the src_addr and src_size match the equivalent dst_addr and dst_size. With a modified addr/size specified in a cmdreply for an output buffer, the data-copy for the first/last pages could be used to overwrite data outside of the buffer specified by the original process.

Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".

This can be used to takeover processes where the process is using your service session. Like HTTPC -> BOSS, for bosshaxx above. NIM takeover can be done too(actual stack buffer overflow can trigger), etc.
| See description.
| None
| [[11.3.0-36|11.3.0-X]]
| November 26, 2016
| [[User:Yellows8|Yellows8]]
|-
| Using IPC input buffers as output buffers
| When sending cmdreplies, it does not validate that the cmdreply descriptor type matches the equivalent cmdreq descriptor type. This could be used by an exploited sysmodule to use what was intended as an input-buffer as an output-buffer, and also combine other IPC vuln(s) with this.

Used by ctr-httpwn as of v1.2, for "ipctakeover/bosshaxx".
| See description.
| None
| [[11.3.0-36|11.3.0-X]]
| November 2016
| [[User:Yellows8|Yellows8]]
|-
| [[SVC]] table too small
| The table of function pointers for SVC's only contains entries up to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus, executing SVC7E or SVC7F would make the SVC-handler read after the buffer, and interpret some ARM instructions as function pointers.

However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.
|
| None
| [[11.3.0-36|11.3.0-X]]
| 2012
| Everyone
|-
| [[SVC|svcBackdoor (0x7B)]]
| This backdoor allows executing SVC-mode code at the user-specified code-address. This is used by Process9, using this on the ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying SVC-access-control.
| See description
| [[11.0.0-33|11.0.0-X]] (deleted)
|
|
| Everyone
|-
| veryslowpidhax
| '''This is completely different from the kernelmode-code-execution vuln described in the below separate entry.'''

When updating the kernel global PID counter under [[SVC|svcCreateProcess]] the kernel does not check for wraparound to 0x0(the PID for the very first process). This only matters because [[Services|SM-module]] allows processes with PID value less than <total ARM11 FIRM modules> to access ''all'' services, without checking exheader service-access-control; and because Kernel11 checks for the PID to be 1 (loader) to use the input mem-region value on ControlMemory. This alone does not affect access the [[SVC|SVCs]] access table at all.

Inlined ldrex+strex code is used for updating the above counter. [[11.2.0-35|11.2.0-X]] had changes for similar code, but it was only for dedicated ldrex+strex functions(mainly for kernel objects) and hence this PID code was not affected.

With launching+terminating a sysmodule repeatedly with this via ns:s, it would take weeks to finish(if not at least about a month?).
| Access to all [[Services_API|services]], ControlMemory on any given mem-region.
| None
| [[11.3.0-36|11.3.0-X]]
| 2012 maybe?
|
|-
| slowhax/waithax
| svcWaitSynchronizationN does not decrement the references to valid handles in an array before returning an error when it encounters an invalid handle. This allows one to (slowly) overflow the reference count for a handle object to zero.
| ARM11 kernel-mode code execution
| [[11.2.0-35|11.2.0-X]]
| [[11.2.0-35|11.2.0-X]]
| 2016
| nedwill, [[User:Derrek|derrek]]
|-
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup for loading the FIRM-modules from the FIRM section located in DSP-mem, this never seems to be used after that, however. This is never unmapped either.
|
| None
| [[11.3.0-36|11.3.0-X]]
|
|
|-
| memchunkhax2.1
| Nintendo's fix for memchunkhax2 in [[10.4.0-29|10.4.0-X]] did not fix the GPU case: one may cause the requisite ToCToU race using gspwn, bypassing the new validation.
derrek's original 32c3 presentation for memchunkhax2 commented that a GPU-based attack was possible, but would be difficult. However, memchunkhax2.1 showed that it was possible to do fairly reliably.
| ARM11 kernel code execution
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|11.0.0-X]]
|
| [[User:Derrek|derrek]], aliaspider
|-
| memchunkhax2
| When allocating a block of memory, the "next" pointer of the [[Memory_Management#MemoryBlockHeader|memchunkhdr]] is accessed without being checked after being mapped to userland.
This allows a race condition, where the process can change the next pointer just before it's accessed. By pointing the next pointer to a crafted memchunckhdr in the kernel SlabHeap, some of the SlabHeap is allocated to the calling process, allowing to change vtables of kernel objects.
| ARM11 kernel code execution
| [[10.4.0-29|10.4.0-X]] (partially, see memchunkhax2.1)
| [[10.4.0-29|10.4.0-X]]
|
| [[User:Derrek|derrek]]
|-
| heaphax
| Can change the size of free memchunk structures stored in FCRAM using DMA, which leads to the ability to allocate memory chunks over already-allocated memory. This can be used in the SYSTEM region to allocate RW memory over any part of the NS system module, which is enough to take it over.
| Code execution with access to all of NS's privileges. (including downgrading) Code execution within any applet.
| [[11.0.0-33|11.0.0-X]], via the new [[Memory_Management#MemoryBlockHeader|memchunkhdr]] MAC which prevents modifying memchunkhdr data with DMA.
| [[11.0.0-33|11.0.0-X]]
| April 2015 ?
| smea
|-
| snshax
| Can force creation of Safe NS process into gspwn-able memory, allowing for takeover.
| Code execution with access to all of NS's privileges. (including downgrading)
| [[10.1.0-27|10.1.0-X]]
| [[10.1.0-27|10.1.0-X]]
| April 2015 ?
| smea
|-
| AffinityMask/processorid validation
| With [[10.0.0-27|10.0.0-X]] the following functions were updated: svcGetThreadAffinityMask, svcGetProcessAffinityMask, svcSetProcessAffinityMask, and svcCreateThread. The code changes for all but svcCreateThread are identical.
The original code with the first 3 did the following:
* if(u32_processorcount > ~0x80000001)return 0xe0e01bfd;
* if(s32_processorcount > <total_cores>)return 0xd8e007fd;
The following code replaced the above:
* if(u32_processorcount >= <total_cores+1>)return 0xd8e007fd;
In theory the latter should catch everything that the former did, so it's unknown if this was really a security issue.

The svcCreateThread changes with [[10.0.0-27|10.0.0-X]] definitely did fix a security issue.
* Original code: "if(s32_processorid > <total_cores>)return 0xd8e007fd;"
* New code: "if(s32_processorid >= <total_cores> || s32_processorid <= -4)return 0xd8e007fd;"
This fixed an off-by-one issue: if one would use processorid=total_cores, which isn't actually a valid value, svcCreateThread would accept that value on <[[10.0.0-27|10.0.0-X]]. This results in data being written out-of-bounds(baseaddr = arrayaddr + entrysize*processorid), which has the following result:
* Old3DS: Useless kernel-mode crash due to accessing unmapped memory.
* New3DS: uncontrolled data write into a kernel-mode L1 MMU-table. This isn't really useful: the data can't be controlled, and the data which gets overwritten is all-zero anyway(this isn't anywhere near MMU L1 entries for actually mapped memory).
The previous version also allowed large negative s32_processorid values(negative processorid values are special values not actual procids), but it appears using values like that won't actually do anything(meaning no crash) besides the thread not running / thread not running for a while(besides triggering a kernelpanic with certain s32_processorid value(s)).
| Nothing useful
| [[10.0.0-27|10.0.0-X]]
| [[10.0.0-27|10.0.0-X]]
| svcCreateThread issue: May 31, 2015. The rest: September 8, 2015, via v9.6->v10.0 ARM11-kernel code-diff.
| [[User:Yellows8|Yellows8]]
|-
| memchunkhax
| The kernel originally did not validate the data stored in the FCRAM kernel heap [[Memchunkhdr|memchunk-headers]] for free-memory at all. Exploiting this requires raw R/W access to these memchunk-headers, like physical-memory access with gspwn.

There are ''multiple'' ways to exploit this, but the end-result for most of these is the same: overwrite code in AXIWRAM via the 0xEFF00000/0xDFF00000 kernel virtual-memory mapping.

This was fixed in [[9.3.0-21|9.3.0-X]] by checking that the memchunk(including size, next, and prev ptrs) is located within the currently used heap memory. The kernel may also check that the next/prev ptrs are valid compared to other memchunk-headers basically. When any of these checks fail, kernelpanic() is called.
| When combined with other flaws: ARM11-kernelmode code execution
| [[9.3.0-21|9.3.0-21]]
|
| February 2014
| [[User:Yellows8|Yellows8]]
|-
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|KLinkedListNode]] object at the right time could result in a type-confusion. Pseudo-code:
SlabHeap_free(KLinkedListNode);
KObject *obj = KLinkedListNode->key; // the object there might have changed!
This bug appeared all over the place.
| ARM11-kernelmode code exec maybe
| [[8.0.0-18|8.0.0-18]]
|
| April 2015
| [[User:Derrek|derrek]]
|-
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.
|
| [[6.0.0-11|6.0.0-11]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|svcStartInterProcessDma]]
| For svcStartInterProcessDma, the kernel code had the following flaws:

* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.

* Integer overflows for srcaddr+size and dstaddr+size are now checked(with [[6.0.0-11]]), which were not checked before.

* The kernel now also checks whether the srcaddr/dstaddr (+size) is within userland memory (0x20000000), the kernel now (with [[6.0.0-11]]) returns an error when the address is beyond userland memory. Using an address >=0x20000000 would result in the kernel reading from the process L1 MMU table, beyond the memory allocated for that MMU table(for vaddr->physaddr conversion).
|
| [[6.0.0-11]]
|
| DmaConfig issue: unknown. The rest: 2014
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] independently
|-
| [[SVC|svcControlMemory]] Parameter checks
| For svcControlMemory the parameter check had these two flaws:

* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.

* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).

|
| [[5.0.0-11]]
|
|
| [[User:Plutooo|plutoo]]
|-
| [[RPC_Command_Structure|Command]] request/response buffer overflow
| Originally the kernel did not check the word-values from the command-header. Starting with [[5.0.0-11]], the kernel will trigger a kernelpanic() when the total word-size of the entire command(including the cmd-header) is larger than 0x40-words (0x100-bytes). This allows overwriting threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.

If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|SVC stack allocation overflows]]
|
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun.
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.

This might allow for ARM11 kernel code-execution.

(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Plutooo|plutoo]], [[User:Yellows8|Yellows8]] complementary
|-
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.
|
| [[4.1.0-8]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[RPC_Command_Structure|Command]] input/output buffer permissions
| Originally the ARM11 kernel didn't check memory permissions for the input/output buffers for commands. Starting with [[4.0.0-7]] the ARM11 kernel will trigger a kernelpanic() if the input/output buffers don't have the required memory permissions. For example, this allowed a FSUSER file-read to .text, which therefore allowed ARM11-userland code execution.
|
| [[4.0.0-7]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.
|
| [[4.0.0-7]]
|
| 2012?
| [[User:Yellows8|Yellows8]]
|}

=== [[FIRM]] Sysmodules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[Services|"srv:pm"]] process registration
| Originally any process had access to the port "srv:pm". The PID's used for the (un)registration commands are not checked either. This allowed any process to re-register itself with "srv:pm", and therefore allowed the process to give itself access to any service, bypassing the exheader service-access-control list.

This was fixed in [[7.0.0-13]]: starting with [[7.0.0-13]] "srv:pm" is now a service instead of a globally accessible port. Only processes with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules) have access to it. With [[7.0.0-13]] there can only be one session for "srv:pm" open at a time(this is used by pm module), svcBreak will be executed if more sessions are opened by the processes which can access this.

This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).
| Access to arbitrary services
| [[7.0.0-13]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| FSDIR null-deref
| [[Filesystem_services|FS]]-module may crash in some cases when handling directory reading. The trigger seems to be due to using [[FSDir:Close]] without closing the dir-handle afterwards?(Perhaps this is caused by out-of-memory?) This seems to be useless since it's just a null-deref.
|
| None
| [[9.6.0-24|9.6.0-X]]
| May 19(?)-20, 2015
| [[User:Yellows8|Yellows8]]
|-
| Useless [[SM]] off-by-one write
| After accepting a new session, [[SM]] writes a (handler ID (0 for srv: sessions (max. 64), 1 for the srv:pm one), pointer to session context structure in BSS) pair in a global array. However that array is only 64-entry-big instead of 65 (as it ought to be), and no bound check is done in that regard.

Unfortunately, as of [[11.4.0-37]], the overwritten fields are totally unused after their initialization by <code>__libc_init_array</code>.
| Not currently exploitable
| None
| [[11.4.0-37]]
|
|
|-
| smpwn
| When registering a new service (or "port"), no bound checks are done on the service table. One can simply call RegisterPort repeatedly to overflow that table: it will overflow into the command replay structure.

Combined with a other minor bugs in the sysmodule, it is possible to take over [[SM]] with this nevertheless difficult-to-exploit vulnerability.
| Code execution under [[SM]], etc.
| None
| [[11.14.0-46]]
| July 2017
| [[User:TuxSH|TuxSH]] (independently), presumably ichfly before
|-
| PXI cmdbuf buffer overrun
| Like its Arm9 counterpart, before version [[5.0.0-11|5.0.0-X]], the PXI system module did not check the command sizes. This makes it possible to get ROP under the PXI sysmodule from a pwned Process9.
safecerthax uses it to takeover the Arm11 processor after directly getting remote code execution on the Arm9 side. Though, is useless in classic Arm11 -> Arm9 chains.
| ROP under [[PXI_Services|PXI]]
| probably [[5.0.0-11|5.0.0-X]]
| [[11.14.0-46]]
|
| Everyone
|}

=== Standalone Sysmodules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system-module system-version
! Last system-module system-version this flaw was checked for
! Timeframe this was discovered
! Timeframe this was added to wiki
! Discovered by
|-
| [[CSND_Services|CSND]] sysmodule crash due to out of bounds parameters.
| The CSND command [[CSND:PlaySoundDirectly|PlaySoundDirectly (0x00040080)]] takes a channel ID as the first parameter. Any value outside the range [0-3] makes the system module become unstable or crash due to an out of bounds memory read.
| Out of bounds memory read, probably not exploitable. More research needed.
| None
| [[11.14.0-46]]
| January 2021
| January 22, 2021
| [[User:PabloMK7|PabloMK7]]

|-
| SSLoth: [[SSL_Services|SSL]] sysmodule improper certificate verification
| Initially, the SSL sysmodule missed the R_VERIFY_RES_SIGNATURE entry in the "resource list" provided to the RSA BSAFE library. Consequently, it did not check signatures when validating certificate chains.
| Forge fake certificates, spoof official servers and perform MitM attacks on SSL/TLS connections.
| [[11.14.0-46]]
| [[11.14.0-46]]
| 2020
| December 18, 2020
| [[User:Nba_Yoh|MrNbaYoh]], shutterbug2000 (independently)

|-
| [[CECD_Services|CECD:ndm]] SetNZoneMacFilter (cmd8) stack smashing
| The length of the mac filter is not checked before being copied to a fixed-size buffer on stack.
| ROP under [[CECD_Services|CECD]] sysmodule
| None
| [[11.13.0-45]]
| 2020
| July 20, 2020
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| [[CECD_Services|CECD]] message box access
| CECD allows any process to write to any message box, thus allowing to write Streetpass data to the message box of any title.
| Install exploit for any title having a vulnerability in Streetpass data parsers (see CTRSDK Streetpass parser vulnerability).
| None
| None
| ?
| June 1, 2020
| Everyone?
|-
| [[CECD_Services|CECD]] packet type 0x32/0x34 stack-smashing
| When parsing Streetpass packets of type 0x32 and 0x34, CECD copies a list without checking the number of entries. The packet length is limited to 0x400 bytes, which is not enough to reach the end of the stack frame and overwrite the return address. However, the buffer located just next to the packet buffer is actually filled with data sent just before, hence actually allowing to overwrite the whole stack frame with conrolled data.
| RCE under [[CECD_Services|CECD]]
| [[11.12.0-44]]
| [[11.12.0-44]]
| Summer 2019
| June 1, 2020
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| [[CECD_Services|CECD]] TMP files parser multiple vulnerabilities
| When parsing "TMP_XXX" files, CECD does not check the number of messages contained in the file. This allows to overflow the array of message pointers and message sizes on the stack. Pointers aren't controlled and sizes are limited (one cannot send gigabytes of data...), yet the last message size can be an arbitrary value (the current message pointer goes outside the file buffer and the parsing loop is broken). This allows to overwrite a pointer to a lock object on the stack and decrement an arbitrary value in memory. One can change the TMP file parsing mode to have CECD trying to free all the message buffers after parsing the next TMP file. The parsing mode is usually restored when parsing a new TMP file, but an invalid TMP file allows to make a function returns an error before the mode is restored , the return value is not checked and the parser consider the file valid. The message pointers and sizes arrays are not updated though, this is not a problem since the previous TMP file buffer is reused for the new TMP file in memory. Thus the message pointers actually points to controlled data. This allows to get a bunch of fake heap chunk freed, thus a bunch of unsafe unlink arbitrary writes.
| RCE under [[CECD_Services|CECD]]
| [[11.12.0-44]]
| [[11.12.0-44]]
| Summer 2019
| June 1, 2020
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| [[Config_Services|CFG]]:CreateConfigInfoBlk integer underflow
| When creating a new block it checks the size of the block is <= 0x8000, but it doesn't check that the block size is less than the remaining space. This induces an integer underflow (remaining_space-block_size), the result is then used for another check (buf_start+current_offset+constant <= remaining_space-block_size) and then in a mempcy call (dest = buf_start+(u16)(remaining_space-block_size), size =block_size). This allow for writing past the buffer, however because of the u16 cast in the memcpy call memory has to be mapped from buf_start to buf_start+0x10000 (cannot write backward).
| Theoritically ROP under CFG services, but BSS section is to small (size <= 0x10000) so it only results in a crash.
| None
| [[11.8.0-41]]
| November, 2018
| November 24, 2018
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| [[MP:SendDataFrame]] missing input array index validation
| [[MP:SendDataFrame]] doesn't validate the input index at cmdreq[1], unless the function for flag=non-zero is executed. This is used to calculate the following, without validating the index at all: someptr = stateptr + (index*0x924) + somestateoffset.

After validating some flags from someptr, when input_flag=0 the input buffer data is copied to someptr+someotheroffset+0x14 with the u16 size loaded from someptr+someotheroffset.

With a large input index someptr could be setup to be at a <target address>, for overwriting memory.

This is probably difficult to exploit.
|
| None
| [[8.0.0-18]](MP-sysmodule v2048)
| January 22, 2017
| January 22, 2017
| [[User:Yellows8|Yellows8]]
|-
| [[MP_Services|MP]] cmd1 out-of-bounds handle read
| MP-sysmodule handles the input parameter for cmd1 as a s32. It checks for >=16, but not <0. With <16 it basically does the following(array of entries 4-bytes each): *outhandle = ((Handle*)(stateptr+offsetinstate))[inputindex].

Hence, this can be used to load any handle in MP-sysmodule memory. MP doesn't really have any service handles of interest however(can be obtained from elsewhere too).
| Reading any handle in MP-sysmodule memory.
| None
| [[8.0.0-18]](MP-sysmodule v2048)
| January 21, 2017
| January 22, 2017
| [[User:Yellows8|Yellows8]]
|-
| AM stack/.bss infoleak via [[AM:ReadTwlBackupInfo]]([[AM:ReadTwlBackupInfoEx|Ex]])
| After writing the output-info structure to stack, it then copies that structure to the output buffer ptr using the size from the command. The size is not checked. This could be used to read data from the AM-service-thread stack handling the command + .bss.

'''This was not tested on hardware.'''
| Stack/.bss reading
| None
| [[10.0.0-27]](AM v9217)
| Roughly October 17, 2016
| October 25, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[MVD_Services|MVD]]: Stack buffer overflow with [[MVDSTD:SetupOutputBuffers]].
| The input total_entries is not validated when initially processing the input entry-list. This fixed-size input entry-list is copied to stack from the command request. The loop for processing this initializes a global table, the converted linearmem->physaddrs used there are also copied to stack(0x8-bytes of physaddrs per entry).

If total_entries is too large, MVD-sysmodule will crash due to reading unmapped memory following the stack(0x10000000). Afterwards if the out-of-bounds total_entries is smaller than that, it will crash due accessing address 0x0, hence this useless.
| MVD-sysmodule crash.
| None
| [[9.0.0-20]]
| April 22, 2016 (Tested on the 25th)
| April 25, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|NWM]]: Using CTRSDK heap with UDS sharedmem from the user-process.
| See the HTTP-sysmodule section below.

CTRSDK heap is used with the sharedmem from [[NWMUDS:InitializeWithVersion]]. Buffers are allocated/freed under this heap using [[NWMUDS:Bind]] and [[NWMUDS:Unbind]].

Hence, overwriting sharedmem with gspwn then using [[NWMUDS:Unbind]] results in the usual controlled CTRSDK memchunk-header write, similar to HTTP-sysmodule.

This could be done by creating an UDS network, without any other nodes on the network.

Besides CTRSDK memchunk-headers, there are no addresses stored under this sharedmem.
| ROP under NWM-module.
| None (need to check, but CTRSDK heap code is vulnerable)
| [[9.0.0-20|9.0.0-X]]
| April 10, 2016
| April 16, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds memory access during spectator [[Download_Play|data-frame]] checksum calculation
| DLP doesn't validate the frame_size when receiving spectator data-frames at all, unlike non-spectator data-frames. The actual spectator data-frame parsing code doesn't use that field either. However, the data-frame checksum calculation code called during checksum verification does use the frame_size for loading the size of the framebuf.

Hence, using a large frame_size like 0xFFFF will result in the checksum calculation code reading data out-of-bounds. This isn't really useful, you could trigger a remote local-WLAN DLP-sysmodule crash while a 3DS system is scanning for DLP networks(due to accessing unmapped memory), but that's about all(trying to infoleak with this likely isn't useful either).
| DLP-sysmodule crash, handled by dlplay system-application by a "connection interrupted" error eventually then a fatal-error via ErrDisp.
| None
| [[10.0.0-27|10.0.0-X]]
| April 8, 2016 (Tested on the 10th)
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[DLP_Services|DLP]]: Out-of-bounds output data writing during spectator sysupdate titlelist [[Download_Play|data-frame]] handling
| The total_entries and out_entryindex fields for the titlelist DLP spectator data-frames are not validated. This is parsed during DLP network scanning. Hence, the specified titlelist data can be written out-of-bounds using the specified out_entryindex and total_entries. A crash will occur while reading the input data-frame titlelist if total_entries is larger than 0x27A, due to accessing unmapped memory.

There's not much non-zero data to overwrite following the output buffer(located in sharedmem), any ptrs are located in sharedmem. Overwriting certain ptr(s) are only known to cause a crash when attempting to use the DLP-client shutdown service-command.

There's no known way to exploit the above crash, since the linked-list code involves writes zeros(with a controlled start ptr).
|
| None
| [[10.0.0-27|10.0.0-X]]
| April 8-9, 2016
| April 10, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[IR_Services|IR]]: Stack buffer overflow with custom hardware
| Originally IR sysmodule used the read value from the I2C-IR registers TXLVL and RXLVL without validating them at all. See [[10.6.0-31|here]] for the fix. This is the size used for reading the data-recv FIFO, etc. The output buffer for reading is located on the stack.

This should be exploitable if one could successfully setup the custom hardware for this and if the entire intended sizes actually get read from I2C.
| ROP under IR sysmodule.
| [[10.6.0-31|10.6.0-31]]
|
| February 23, 2016 (Unknown if it was noticed before then)
| February 23, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[HTTP_Services|HTTP]]: Using CTRSDK heap with sharedmem from the user-process.
| The data from httpcAddPostDataAscii and other commands is stored under a CTRSDK heap. That heap is the sharedmem specified by the user-process via the HTTPC Initialize command.
Normally this sharedmem isn't accessible to the user-process once the sysmodule maps it, hence using it is supposed to be "safe".

This isn't the case due to gspwn however. Since CTRSDK heap code is so insecure in general, one can use gspwn to locate the HTTPC sharedmem + read/write it, then trigger a mem-write under the sysmodule. This can then be used to get ROP going under HTTP-sysmodule.

This is exploited by [https://github.com/yellows8/ctr-httpwn/ctr-httpwn ctr-httpwn].
| ROP under HTTP sysmdule.
| None
| [[11.13.0-45|11.13.0-X]]
| Late 2015
| March 22, 2016
| [[User:Yellows8|Yellows8]]
|-
| [[NIM_Services|NIM]]: Downloading old title-versions from eShop
| Multiple NIM service commands(such as [[NIMS:StartDownload]]) use a title-version value specified by the user-process, NIM does not validate that this input version matches the latest version available via SOAP. Therefore, when combined with AM(PXI) [[#Process9|title-downgrading]] via deleting the target eShop title with System Settings Data Management(if the title was already installed), this allows downloading+installing any title-version from eShop ''if'' it's still available from CDN.
The easiest way to exploit this is to just patch the eShop system-application code using these NIM commands(ideally the code which loads the title-version).

Originally this was tested with a debugging-system via modded-FIRM, eventually smea implemented it in HANS for the 32c3 release.
| Downloading old title-versions from eShop
| None
| [[10.0.0-27|10.0.0-X]]
| October 24, 2015 (Unknown when exactly the first eShop title downgrade was actually tested, maybe November)
| January 7, 2016 (Same day Ironfall v1.0 was removed from CDN via the main-CXI files)
| [[User:Yellows8|Yellows8]]
|-
| [[SPI_Services|SPI]] service out-of-bounds write
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.
| Code execution under spi sysmodule; access to [[CONFIG11_Registers|CFG11_GPUPROT]] and ultimately kernel code execution.
| None
| [[11.14.0-46]]
| March 2015
|
| [[User:Plutooo|plutoo]]
|-
| [[NFC_Services|NFC]] module service command buf-overflows
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.

There's no known retail titles which have access to either of these services.
| ROP under NFC module.
| New3DS: None
| New3DS: [[9.5.0-22]]
| December 2014?
|
| [[User:Yellows8|Yellows8]]
|-
| [[News_Services|NEWSS]] service command notificationID validation failure
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> service commands. This is an out-of-bounds array index bug. For example, [[NEWSS:SetNotificationHeader]] could be used to exploit news module: this copies the input data(size is properly checked) to: out = newsdb_savedata+0x10 + (someu32array[notificationID]*0x70).
| ROP under news module.
| None
| [[9.7.0-25|9.7.0-X]]
| December 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWMUDS:DecryptBeaconData]] heap buffer overflow
| input_size = 0x1E * <value the u8 from input_[[NWM_Services|networkstruct]]+0x1D>. Then input_tag0 is copied to a heap buffer. When input_size is larger than 0xFA-bytes, it will then copy input_tag1 to <end_address_of_previous_outbuf>, with size=input_size-0xFA.

This can be triggered by either using this command directly, or by boadcasting a wifi beacon which triggers it while a 3DS system running the target process is in range, when the process is scanning for hosts to connect to. Processes will only pass tag data to this command when the wlancommID and other thing(s) match the values for the process.

There's no known way to actually exploit this for getting ROP under NWM-module, at the time of originally adding this to the wiki. This is because the data which gets copied out-of-bounds *and* actually causes crash(es), can't be controlled it seems(with just broadcasting a beacon at least). It's unknown whether this could be exploited from just using NWMUDS service-cmd(s) directly.
| Without any actual way to exploit this: NWM-module DoS, resulting in process termination(process crash). This breaks *everything* involving wifi comms, a reboot is required to recover from this.
| None
| [[9.0.0-20]]
| ~September 23, 2014(see the [[NWMUDS:DecryptBeaconData]] page history)
| August 3, 2015
| [[User:Yellows8|Yellows8]]
|-
| [[HID_Services|HID]] module shared-mem
| HID module does not validate the index values in [[HID_Shared_Memory|sharedmem]](just changes index to 0 when index == maxval when updating), therefore large values will result in HID module writing HID data to arbitrary addresses.
| ROP under HID module, but this is *very* unlikely to be exploitable since the data written is HID data.
| None
| [[9.3.0-21]]
| 2014?
|
| [[User:Yellows8|Yellows8]]
|-
| gspwn
| GSP module does not validate addresses given to the GPU. This allows a user-mode application/applet to read/write to a large part of physical FCRAM using GPU DMA. From this, you can overwrite the .text segment of the application you're running under, and gain real code-execution from a ROP-chain. Normally applets' .text([[Home Menu]], [[Internet Browser]], etc) is located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).

FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and 0x2D800000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 (0x800000 with New3DS) with the default memory-layout on Old3DS/New3DS. With [[11.3.0-36|11.3.0-X]] the cutoff now varies due to the new [[SVC]] 0x59. The New3DS "normal"(non-APPLICATION) cutoff was changed to 0x2D000000 due to the new [[SVC]] 0x59.
| User-mode code execution.
| None
| [[9.6.0-24|9.6.0-X]]
| Early 2014
|
| smea, [[User:Yellows8|Yellows8]]/others before then
|-
| rohax
| Using gspwn, it is possible to overwrite a loaded [[CRO0]]/[[CRR0]] after its RSA-signature has been validated. Badly validated [[CRO0]] header leads to arbitrary read/write of memory in the ro-process. This gives code-execution in the ro module, who has access to [[SVC|syscalls]] 0x70-0x72, 0x7D.

This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.
| Memory-mapping syscalls.
| [[9.3.0-21]]
| [[9.4.0-21]]
|
|
| smea, [[User:Plutooo|plutoo]] joint effort
|-
| Region free
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application launch that is done directly with [[NS]] without signaling Home Menu to launch the app, will result in region checks being bypassed.
This essentially means launching the gamecard with the [[NS_and_APT_Services|"ns:s"]] service. The main way to exploit this is to trigger a FIRM launch with an application specified, either with a normal FIRM launch or a hardware [[NSS:RebootSystem|reboot]].
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation
| None
| Last tested with [[10.1.0-27|10.1.0-X]].
| June(?) 2014
|
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|NWM]] service-cmd state null-ptr deref
| The NWMUDS service command code loads a ptr from .data, adds an offset to that, then passes that as the state address for the actual command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.
It's unknown whether any NWM services besides NWMUDS have this issue.
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.
| None
| [[9.0.0-20]]
| 2013?
|
| [[User:Yellows8|Yellows8]]
|}

=== General/CTRSDK ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[CECD_Services|CECD]] Streetpass message exheader stack-smashing
| When parsing streetpass messages, "nn::cec::CTR::Message::InputMessage" calls "nn::cec::CTR::Message::SetExHeaderWithoutCalc" for each exheader entry in the input message. The number of entries should not exceed 16 but remains unchecked, leading to a stack-buffer-overflow.
| ROP under any application parsing Streetpass messages
Remote code execution under [[CECD_Services|CECD]]
| [[11.12.0-44]]
|
| 2019
| [[User:Nba_Yoh|MrNbaYoh]]
|-
| [[NWM_Services|UDS]] beacon additional-data buffer overflow
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|networkstruct]]. This was eventually fixed.
This was discovered while doing code RE with an old dlp-module version. It's unknown in what specific CTRSDK version this was fixed, or even what system-version updated titles with a fixed version.

It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).

The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.
| Perhaps ROP, very difficult if possible with anything at all
| ?
|
| September(?) 2014
| [[User:Yellows8|Yellows8]]
|-
| CTPK buffer overflow
| At offset 0x20 in CTPK is an array for each texture, each entry is 0x20-bytes. This contains a wordindex(entry+0x18) for some srcdata relative to CTPK+0, and an u8 wordsize(entry+0x14) for this data. The CTRSDK function handling this doesn't validate the size, when copying srcdata using this size to the output buffer. Applications usually have the output buffer on the stack, hence stack buffer overflow.

While CTPK(*.ctpk) are normally only loaded from RomFS, some application(s) load from elsewhere too.
| ROP under the target application.
| None?
| "[SDK+NINTENDO:CTR_SDK-11_4_0_200_none]"
| November 14, 2016
| [[User:Yellows8|Yellows8]]
|}

CSND:PlaySoundDirectly

2020-12-25T17:30:25Z

PabloMK7: PlaySoundDirectly seems to be used to play sounds directly from bcwav files by copying soem stuff to the shared memory.

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00040080]
|-
| 1
| Unknown
|-
| 2
| Unknown
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
This function plays a sound from the info stored in the CSND shared memory (Offset3).

CSND Services

2020-12-25T17:24:04Z

PabloMK7: PlaySoundDirectly: Plays the sound directly from the info in the CSND shared memory.

[[Category:Services]]

The CSND service talks to the DSP using the DSP FIFO to negotiate what CSND channels are allocated to the DSP, and this seems to be channels 0-7 (usually). The rest are dedicated to CSND services.

= CSND service "csnd:SND" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010140
| [[CSND:Initialize|Initialize]]
|-
| 0x00020000
| [[CSND:Shutdown|Shutdown]]
|-
| 0x00030040
| [[CSND:ExecuteCommands|ExecuteCommands]]
|-
| 0x00040080
| [[CSND:PlaySoundDirectly|PlaySoundDirectly]]
|-
| 0x00050000
| [[CSND:AcquireSoundChannels|AcquireSoundChannels]]
|-
| 0x00060000
| [[CSND:ReleaseSoundChannels|ReleaseSoundChannels]]
|-
| 0x00070000
| [[CSND:AcquireCapUnit|AcquireCapUnit]]
|-
| 0x00080040
| [[CSND:ReleaseCapUnit|ReleaseCapUnit]]
|-
| 0x00090082
| [[CSND:FlushDataCache|FlushDataCache]]
|-
| 0x000A0082
| [[CSND:StoreDataCache|StoreDataCache]]
|-
| 0x000B0082
| [[CSND:InvalidateDataCache|InvalidateDataCache]]
|-
| 0x000C0000
| [[CSND:Reset|Reset]]
|}

A maximum of 4 service sessions can be opened at the same time for this service.

For cache operations addresses must be in 0x14000000-0x1C000000 range. Starting with [[8.0.0-18]] addresses in the range 0x30000000-0x40000000 are also allowed.

This service is normally used for playing [[BCWAV|CWAVs]]. The audio data must be located in the 0x14000000 virtual memory region, since CSND requires the physical address for playing the audio.

BCWAV

2020-12-20T11:38:58Z

PabloMK7: B doesn't stand for Banner, but for Binary (same all of the other NW4C related file formats).

[[Category:File formats]]
This document is about the format of Binary CTR Wave files (BCWAV). The structure is very similar to Microsoft's Wave file.

=== Overview ===

Microsoft's WAV structure is RIFF Header which defines the data inside which is WAVE, then the media player expects a "fmt " chunk and a "data" chunk. Nintendo's format uses a CWAV header (no need for a general structure for media, only wave), which points to an INFO struct (the equivalent to fmt) and a DATA struct (the equivalent to data).

=== Header ===

{| class="wikitable" border="1"
|-
! OFFSET !! SIZE !! DESCRIPTION
|-
| 0x000 || 4 || Magic (CWAV)
|-
| 0x004 || 2 || Endianness (0xFEFF = little, 0xFFFE = big)
|-
| 0x006 || 2 || Header Size (0x40 due to [[#Info Block|Info Block]] alignment)
|-
| 0x008 || 4 || Version (0x02010000)
|-
| 0x00C || 4 || File Size
|-
| 0x010 || 2 || Number of Blocks (2)
|-
| 0x012 || 2 || Reserved
|-
| 0x014 || 12 || [[#Info Block|Info Block]] [[#Sized Reference|Sized Reference]] (Offset relative to start of file)
|-
| 0x020 || 12 || [[#Data Block|Data Block]] [[#Sized Reference|Sized Reference]] (Offset relative to start of file)
|}

=== Block Header ===

{| class="wikitable" border="1"
|-
! OFFSET !! SIZE !! DESCRIPTION
|-
| 0x000 || 4 || Magic
|-
| 0x004 || 4 || Size
|}

==== Block Types ====

{| class="wikitable" border="1"
|-
! MAGIC !! TYPE
|-
| INFO || [[#Info Block|Info Block]]
|-
| DATA || [[#Data Block|Data Block]]
|}

=== Info Block ===

{| class="wikitable" border="1"
|-
! OFFSET !! SIZE !! DESCRIPTION
|-
| 0x000 || 8 || [[#Block Header|Block Header]]
|-
| 0x008 || 1 || [[#Encoding|Encoding]]
|-
| 0x009 || 1 || Loop (0 = don't loop, 1 = loop)
|-
| 0x00A || 2 || Padding
|-
| 0x00C || 4 || Sample Rate
|-
| 0x010 || 4 || Loop Start Frame
|-
| 0x014 || 4 || Loop End Frame
|-
| 0x018 || 4 || Reserved
|-
| 0x01C || X || [[#Channel Info|Channel Info]] [[#Reference Table|Reference Table]]
|-
| X || X || [[#Channel Info|Channel Info]] Entries
|}

If encoding is DSP ADPCM:

{| class="wikitable" border="1"
|-
! OFFSET !! SIZE !! DESCRIPTION
|-
| X || X || [[#DSP ADPCM Info|DSP ADPCM Info]] Entries
|}

If encoding is IMA ADPCM:

{| class="wikitable" border="1"
|-
! OFFSET !! SIZE !! DESCRIPTION
|-
| X || X || [[#IMA ADPCM Info|IMA ADPCM Info]] Entries
|}

The info block is aligned to 0x20 bytes.

==== Encoding ====

{| class="wikitable" border="1"
|-
! VALUE !! DESCRIPTION
|-
| 0 || PCM8
|-
| 1 || PCM16
|-
| 2 || DSP ADPCM
|-
| 3 || IMA ADPCM
|}

==== Channel Info ====

{| class="wikitable" border="1"
|-
! OFFSET !! SIZE !! DESCRIPTION
|-
| 0x000 || 8 || Samples [[#Reference|Reference]] (Offset relative to [[#Data Block|Data Block]] Data field)
|-
| 0x008 || 8 || ADPCM Info [[#Reference|Reference]] (Offset relative to Samples [[#Reference|Reference]] field)
|-
| 0x010 || 4 || Reserved
|}

===== DSP ADPCM Info =====

{| class="wikitable" border="1"
|-
! OFFSET !! SIZE !! DESCRIPTION
|-
| 0x000 || 32 || [[#DSP ADPCM Param|Param]]
|-
| 0x020 || 6 || [[#DSP ADPCM Context|Context]]
|-
| 0x026 || 6 || Loop [[#DSP ADPCM Context|Context]]
|-
| 0x02C || 2 || Padding
|}

====== DSP ADPCM Param ======

{| class="wikitable" border="1"
|-
! OFFSET !! SIZE !! DESCRIPTION
|-
| 0x000 || 32 || 16-bit Coefficients
|}

====== DSP ADPCM Context ======

{| class="wikitable" border="1"
|-
! OFFSET !! SIZE !! DESCRIPTION
|-
| 0x000 || 1 || 4-bit Predictor + 4-bit Scale
|-
| 0x001 || 1 || Reserved
|-
| 0x002 || 2 || Previous Sample
|-
| 0x004 || 2 || Second Previous Sample
|}

===== IMA ADPCM Info =====

{| class="wikitable" border="1"
|-
! OFFSET !! SIZE !! DESCRIPTION
|-
| 0x000 || 4 || [[#IMA ADPCM Context|Context]]
|-
| 0x004 || 4 || Loop [[#IMA ADPCM Context|Context]]
|}

====== IMA ADPCM Context ======

{| class="wikitable" border="1"
|-
! OFFSET !! SIZE !! DESCRIPTION
|-
| 0x000 || 2 || Data
|-
| 0x002 || 1 || Table Index
|-
| 0x003 || 1 || Padding
|}

=== Data Block ===

{| class="wikitable" border="1"
|-
! OFFSET !! SIZE !! DESCRIPTION
|-
| 0x000 || 8 || [[#Block Header|Block Header]]
|-
| 0x008 || [[#Block Header|Block Header]] Size Value - 8 || Data
|}

The data block is aligned to 0x20 bytes, as well as the data field's actual sample data.

=== Reference Table ===

{| class="wikitable" border="1"
|-
! OFFSET !! SIZE !! DESCRIPTION
|-
| 0x000 || 4 || Count
|-
| 0x004 || Count * 8 || [[#Reference|References]] (Offsets relative to Count field)
|}

=== Sized Reference ===

{| class="wikitable" border="1"
|-
! OFFSET !! SIZE !! DESCRIPTION
|-
| 0x000 || 8 || [[#Reference|Reference]]
|-
| 0x008 || 4 || Size
|}

=== Reference ===

{| class="wikitable" border="1"
|-
! OFFSET !! SIZE !! DESCRIPTION
|-
| 0x000 || 2 || Type ID
|-
| 0x002 || 2 || Padding
|-
| 0x004 || 4 || Offset ("null" = 0xFFFFFFFF)
|}

==== Reference Types ====

{| class="wikitable" border="1"
|-
! ID !! TYPE
|-
| 0x0300 || [[#DSP ADPCM Info|DSP ADPCM Info]]
|-
| 0x0301 || [[#IMA ADPCM Info|IMA ADPCM Info]]
|-
| 0x1F00 || [[#Data_Block|Sample Data]]
|-
| 0x7000 || [[#Info Block|Info Block]]
|-
| 0x7001 || [[#Data Block|Data Block]]
|-
| 0x7100 || [[#Channel Info|Channel Info]]
|}

CBMD

2020-12-20T11:33:38Z

PabloMK7: Moved the BCWAV info from the BCWAV page to here. (As it only applies to BCWAVs found in banners.)

[[Category:File formats]]
'''CBMD - CTR Banner Model Data'''

This page describes the format used for banners' models. These are stored in [[NCCH#CXI|CXI]] ExeFS:/banner and optionally in [[extdata]] exbanner.
CBMD is a container file for [[CGFX]] blocks. This is used for banners of titles you see in the home menu. BNR used for the app banners in the CXI/exbanner is the same as CBMD with CWAV at the end.

== CBMD Header ==
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Magic "CBMD"
|-
| 0x4
| 0x4
| Zero
|-
| 0x8
| 0x4
| Offset for common [[CGFX]]
|-
| 0xc
| 0x34
| Optional offsets for region/language specific [[CGFX]]
|-
| 0x40
| 0x44
| Padding?
|-
| 0x84
| 0x4
| [[BCWAV]] offset
|}

The common [[CGFX]] is used if the CGFX offset for the system region/language is zero. Those optional offsets can be used in extdata exbanner, but separate CBMD banner files for each region/language can be used as well.

=== Indexes for CGFX offset array ===
{| class="wikitable"
|-
! Index
! Description
|-
| 0
| EUR-English
|-
| 1
| EUR-French
|-
| 2
| EUR-German
|-
| 3
| EUR-Italian
|-
| 4
| EUR-Spanish
|-
| 5
| EUR-Dutch
|-
| 6
| EUR-Portuguese
|-
| 7
| EUR-Russian
|-
| 8
| JPN-Japanese
|-
| 9
| USA-English
|-
| 10
| USA-French
|-
| 11
| USA-Spanish
|-
| 12
| USA-Portuguese
|}

== CGFX ==

[[CGFX]] are compressed using LZ11. For CXI banner CGFX, the decompressed size must be no larger than 0x80000.

Graphics containers. Contains: 3D Models, Shaders, Objects, Materials, Textures, etc. See [[CGFX]] for more information.

== BCWAV ==

The included [[BCWAV]] total channels must be 2, and the length of the audio must be 3 seconds or less, otherwise the sound will play incorrectly (beeping/clicking) or the model may fail to load.

SARC

2019-07-14T18:19:52Z

PabloMK7:

[[Category:File formats]]
=SARC File Format=
.sarc files are similar to the [[ARC]] format with a slightly different structure.

== File Format ==

=== SARC Header ===

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x00
| 0x04
| Magic Bytes "SARC"
|-
| 0x04
| 0x02
| Header Length
|-
| 0x06
| 0x02
| Byte-order marker (0xFEFF = big, 0xFFFE = little)
|-
| 0x08
| 0x04
| File Length
|-
| 0x0C
| 0x04
| Data Offset (absolute)
|-
| 0x10
| 0x04
| Unknown (always 0x00000100)
|}

=== SFAT Header ===

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x00
| 0x04
| Magic bytes "SFAT"
|-
| 0x04
| 0x02
| Header Length
|-
| 0x06
| 0x02
| Node Count
|-
| 0x08
| 0x04
| Filename Hash Multiplier (usually 0x65)
|}

=== SFAT Node ===

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x00
| 0x04
| Name Hash
|-
| 0x04
| 0x04
| SFNT Filename Offset (relative to SFNT data section)
|-
| 0x08
| 0x04
| File Data Start (relative to SARC data start)
|-
| 0x0C
| 0x04
| File Data End (relative to SARC data end)
|}

==== Node hashing function ====

The node hash is calculated via:

Python:

def calc_hash(name, hash_multiplier):
result = 0

for c in name:
result = ord(c) + (result * hash_multiplier)
# ensure the result is a 32-bit value
result &= 0xFFFFFFFF

return result

C:

uint32_t calc_hash(char *name, int hash_multiplier) {
uint32_t result = 0;

for(int i = 0; i < strlen(name); i++) {
result = name[i] + (result * hash_multiplier)
}

return result;
}

=== SFNT Header ===

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x00
| 0x04
| Magic bytes "SFNT"
|-
| 0x04
| 0x02
| Header Length
|-
| 0x06
| 0x02
| Unknown (padding?)
|}

=== SFNT Data ===

SFNT data immediately follows the SFNT header and consists of NULL-terminated ASCII strings.

=== File Data ===

File data begins after SFNT with 0x100 (256) byte alignment with all subsequent files aligned to 0x80 bytes.

== File Sort Order ==

Files are sorted by their hash in the SFAT table, games require this sorting as they use a binary search algorithm [https://en.wikipedia.org/wiki/Binary_search_algorithm].

= Tools =

[https://github.com/ObsidianX/3dstools] - SARC Extractor/Creator with TAR-like command line flags. Can decompress a .zlib SARC file (4-byte size header + ZLIB data).

Filesystem services

2018-06-10T14:39:55Z

PabloMK7: Added missing names for some commands (again)

[[Category:Services]]

= Services =
== Filesystem service "fs:USER" ==
You can at most have 32 FS archive handles.

{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! scope="col" width="400" | Required [[NCCH/Extended_Header|exheader]] access info bitmask
|-
| 0x000100C6
|?
| [[FS:Dummy1|Dummy1]]
| None
|-
| 0x040100C4
|?
| [[FS:Control|Control]]
| None
|-
| 0x08010002
|?
| [[FS:Initialize|Initialize]]
| None
|-
| 0x080201C2
|?
| [[FS:OpenFile|OpenFile]]
| None
|-
| 0x08030204
|?
| [[FS:OpenFileDirectly|OpenFileDirectly]]
| None
|-
| 0x08040142
|?
| [[FS:DeleteFile|DeleteFile]]
| None
|-
| 0x08050244
|?
| [[FS:RenameFile|RenameFile]]
| None
|-
| 0x08060142
|?
| [[FS:DeleteDirectory|DeleteDirectory]]
| None
|-
| 0x08070142
|?
| [[FS:DeleteDirectoryRecursively|DeleteDirectoryRecursively]]
| None
|-
| 0x08080202
|?
| [[FS:CreateFile|CreateFile]]
| None
|-
| 0x08090182
|?
| [[FS:CreateDirectory|CreateDirectory]]
| None
|-
| 0x080A0244
|?
| [[FS:RenameDirectory|RenameDirectory]]
| None
|-
| 0x080B0102
|?
| [[FS:OpenDirectory|OpenDirectory]]
| None
|-
| 0x080C00C2
|?
| [[FS:OpenArchive|OpenArchive]]
| Each archive ID code has separate access info bitmasks, if it has any
|-
| 0x080D0144
|?
| [[FS:ControlArchive|ControlArchive]]
| None
|-
| 0x080E0080
|?
| [[FS:CloseArchive|CloseArchive]]
| None
|-
| 0x080F0180
|?
| [[FS:Obsoleted_2_0_FormatThisUserSaveData|Obsoleted_2_0_FormatThisUserSaveData]]
| None
|-
| 0x08100200
|?
| [[FS:Obsoleted_3_0_CreateSystemSaveData|Obsoleted_3_0_CreateSystemSaveData]]
| 0x4, for when the input saveID doesn't match the exheader saveID
|-
| 0x08110040
|?
| [[FS:Obsoleted_3_0_DeleteSystemSaveData|Obsoleted_3_0_DeleteSystemSaveData]]
| 0x1004, for when the input saveID doesn't match the exheader saveID
|-
| 0x08120080
|?
| [[FS:GetFreeBytes|GetFreeBytes]]
| None
|-
| 0x08130000
|?
| [[FS:GetCardType|GetCardType]]
| 0x1017
|-
| 0x08140000
|?
| [[FS:GetSdmcArchiveResource|GetSdmcArchiveResource]]
| None
|-
| 0x08150000
|?
| [[FS:GetNandArchiveResource|GetNandArchiveResource]]
| 0x1007
|-
| 0x08160000
|?
| [[FS:GetSdmcFatfsError|GetSdmcFatfsError]]
| 0x2
|-
| 0x08170000
|?
| [[FS:IsSdmcDetected|IsSdmcDetected]]
| None
|-
| 0x08180000
|?
| [[FS:IsSdmcWritable|IsSdmcWritable]]
| None
|-
| 0x08190042
|?
| [[FS:GetSdmcCid|GetSdmcCid]]
| 0x2
|-
| 0x081A0042
|?
| [[FS:GetNandCid|GetNandCid]]
| 0x2
|-
| 0x081B0000
|?
| [[FS:GetSdmcSpeedInfo|GetSdmcSpeedInfo]]
| 0x2
|-
| 0x081C0000
|?
| [[FS:GetNandSpeedInfo|GetNandSpeedInfo]]
| 0x2
|-
| 0x081D0042
|?
| [[FS:GetSdmcLog|GetSdmcLog]]
| 0x2
|-
| 0x081E0042
|?
| [[FS:GetNandLog|GetNandLog]]
| 0x2
|-
| 0x081F0000
|?
| [[FS:ClearSdmcLog|ClearSdmcLog]]
| 0x2
|-
| 0x08200000
|?
| [[FS:ClearNandLog|ClearNandLog]]
| 0x2
|-
| 0x08210000
|?
| [[FS:CardSlotIsInserted|CardSlotIsInserted]]
| 0x1017
|-
| 0x08220000
|?
| [[FS:CardSlotPowerOn|CardSlotPowerOn]]
| 0x2
|-
| 0x08230000
|?
| [[FS:CardSlotPowerOff|CardSlotPowerOff]]
| 0x2
|-
| 0x08240000
|?
| [[FS:CardSlotGetCardIFPowerStatus|CardSlotGetCardIFPowerStatus]]
| 0x2
|-
| 0x08250040
|?
| [[FS:CardNorDirectCommand|CardNorDirectCommand]]
| 0x2
|-
| 0x08260080
|?
| [[FS:CardNorDirectCommandWithAddress|CardNorDirectCommandWithAddress]]
| 0x2
|-
| 0x08270082
|?
| [[FS:CardNorDirectRead|CardNorDirectRead]]
| 0x2
|-
| 0x082800C2
|?
| [[FS:CardNorDirectReadWithAddress|CardNorDirectReadWithAddress]]
| 0x2
|-
| 0x08290082
|?
| [[FS:CardNorDirectWrite|CardNorDirectWrite]]
| 0x2
|-
| 0x082A00C2
|?
| [[FS:CardNorDirectWriteWithAddress|CardNorDirectWriteWithAddress]]
| 0x2
|-
| 0x082B00C2
|?
| [[FS:CardNorDirectRead_4xIO|CardNorDirectRead_4xIO]]
| 0x2
|-
| 0x082C0082
|?
| [[FS:CardNorDirectCpuWriteWithoutVerify|CardNorDirectCpuWriteWithoutVerify]]
| 0x2
|-
| 0x082D0040
|?
| [[FS:CardNorDirectSectorEraseWithoutVerify|CardNorDirectSectorEraseWithoutVerify]]
| 0x2
|-
| 0x082E0040
|?
| [[FS:GetProductInfo|GetProductInfo]]
| 0x1005
|-
| 0x082F0040
|?
| [[FS:GetProgramLaunchInfo|GetProgramLaunchInfo]]
| 0x1005
|-
| 0x08300182
|?
| [[FS:Obsoleted_3_0_CreateExtSaveData|Obsoleted_3_0_CreateExtSaveData]]
| 0xC, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08310180
|?
| [[FS:Obsoleted_3_0_CreateSharedExtSaveData|Obsoleted_3_0_CreateSharedExtSaveData]]
| 0x1005
|-
| 0x08320102
|?
| [[FS:Obsoleted_3_0_ReadExtSaveDataIcon|Obsoleted_3_0_ReadExtSaveDataIcon]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08330082
|?
| [[FS:Obsoleted_3_0_EnumerateExtSaveData|Obsoleted_3_0_EnumerateExtSaveData]]
| 0x1005
|-
| 0x08340082
|?
| [[FS:Obsoleted_3_0_EnumerateSharedExtSaveData|Obsoleted_3_0_EnumerateSharedExtSaveData]]
| 0x1005
|-
| 0x08350080
|?
| [[FS:Obsoleted_3_0_DeleteExtSaveData|Obsoleted_3_0_DeleteExtSaveData]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08360080
|?
| [[FS:Obsoleted_3_0_DeleteSharedExtSaveData|Obsoleted_3_0_DeleteSharedExtSaveData]]
| 0x1005
|-
| 0x08370040
|?
| [[FS:SetCardSpiBaudRate|SetCardSpiBaudRate]]
| 0x2
|-
| 0x08380040
|?
| [[FS:SetCardSpiBusMode|SetCardSpiBusMode]]
| 0x2
|-
| 0x08390000
|?
| [[FS:SendInitializeInfoTo9|SendInitializeInfoTo9]]
| None
|-
| 0x083A0100
|?
| [[FS:GetSpecialContentIndex|GetSpecialContentIndex]]
| 0x1005
|-
| 0x083B00C2
|?
| [[FS:GetLegacyRomHeader|GetLegacyRomHeader]]
| 0x1015
|-
| 0x083C00C2
|?
| [[FS:GetLegacyBannerData|GetLegacyBannerData]]
| 0x1015
|-
| 0x083D0100
|?
| [[FS:CheckAuthorityToAccessExtSaveData|CheckAuthorityToAccessExtSaveData]]
| 0x44
|-
| 0x083E00C2
|?
| [[FS:QueryTotalQuotaSize|QueryTotalQuotaSize]]
| None
|-
| 0x083F00C0
|?
| [[FS:Obsoleted_3_0_GetExtDataBlockSize|Obsoleted_3_0_GetExtDataBlockSize]]
| None
|-
| 0x08400040
|?
| [[FS:AbnegateAccessRight|AbnegateAccessRight]]
|?
|-
| 0x08410000
|?
| [[FS:DeleteSdmcRoot|DeleteSdmcRoot]]
| 0x1005
|-
| 0x08420040
|?
| [[FS:DeleteAllExtSaveDataOnNand|DeleteAllExtSaveDataOnNand]]
| 0x1005
|-
| 0x08430000
|?
| [[FS:InitializeCtrFileSystem|InitializeCtrFileSystem]]
| None
|-
| 0x08440000
|?
| [[FS:CreateSeed|CreateSeed]]
| 0x2
|-
| 0x084500C2
|?
| [[FS:GetFormatInfo|GetFormatInfo]]
|?
|-
| 0x08460102
|?
| [[FS:GetLegacyRomHeader2|GetLegacyRomHeader2]]
| 0x1015
|-
| 0x08470180
|?
| [[FS:Obsoleted_2_0_FormatCtrCardUserSaveData|Obsoleted_2_0_FormatCtrCardUserSaveData]]
| 0x6
|-
| 0x08480042
|?
| [[FS:GetSdmcCtrRootPath|GetSdmcCtrRootPath]]
| 0x100D
|-
| 0x08490040
|?
| [[FS:GetArchiveResource|GetArchiveResource]]
|?
|-
| 0x084A0002
|?
| [[FS:ExportIntegrityVerificationSeed|ExportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084B0002
|?
| [[FS:ImportIntegrityVerificationSeed|ImportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084C0242
|?
| [[FS:FormatSaveData|FormatSaveData]]
| 0x6, in some cases this write isn't needed however
|-
| 0x084D0102
|?
| [[FS:GetLegacySubBannerData|GetLegacySubBannerData]]
| 0x1015
|-
| 0x084E0342
|?
| [[FS:UpdateSha256Context|UpdateSha256Context]]
| 0x5
|-
| 0x084F0102
|?
| [[FS:ReadSpecialFile|ReadSpecialFile]]
| None
|-
| 0x08500040
|?
| [[FS:GetSpecialFileSize|GetSpecialFileSize]]
| None
|-
| 0x08510242
| [[3.0.0-5]]
| [[FS:CreateExtSaveData|CreateExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0xC
|-
| 0x08520100
| [[3.0.0-5]]
| [[FS:DeleteExtSaveData|DeleteExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0x10100D
|-
| 0x08530142
| [[3.0.0-5]]
| [[FS:ReadExtSaveDataIcon|ReadExtSaveDataIcon]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x085400C0
| [[3.0.0-5]]
| [[FS:GetExtDataBlockSize|GetExtDataBlockSize]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x08550102
| [[3.0.0-5]]
| [[FS:EnumerateExtSaveData|EnumerateExtSaveData]]
| 0x101005
|-
| 0x08560240
| [[3.0.0-5]]
| [[FS:CreateSystemSaveData|CreateSystemSaveData]]
| 0x4 (this doesn't apply in certain cases, however)
|-
| 0x08570080
| [[3.0.0-5]]
| [[FS:DeleteSystemSaveData|DeleteSystemSaveData]]
| 0x1004 (this doesn't apply in certain cases, however)
|-
| 0x08580000
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsSource|StartDeviceMoveAsSource]]
| 0x2004
|-
| 0x08590200
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsDestination|StartDeviceMoveAsDestination]]
| 0x2004
|-
| 0x085A00C0
| [[3.0.0-5]]
| [[FS:SetArchivePriority|SetArchivePriority]]
| None
|-
| 0x085B0080
| [[3.0.0-5]]
| [[FS:GetArchivePriority|GetArchivePriority]]
| None
|-
| 0x085C00C0
| [[3.0.0-5]]
| [[FS:SetCtrCardLatencyParameter|SetCtrCardLatencyParameter]]
| 0xE
|-
| 0x085D01C0
| [[3.0.0-5]]
| [[FS:SetFsCompatibilityInfo|SetFsCompatibilityInfo]]
| 0x100001
|-
| 0x085E0040
| [[3.0.0-5]]
| [[FS:ResetCardCompatibilityParameter|ResetCardCompatibilityParameter]]
| 0xE
|-
| 0x085F0040
| [[3.0.0-5]]
| [[FS:SwitchCleanupInvalidSaveData|SwitchCleanupInvalidSaveData]]
| 0x12004
|-
| 0x08600042
| [[3.0.0-5]]
| [[FS:EnumerateSystemSaveData|EnumerateSystemSaveData]]
| 0x2004
|-
| 0x08610042
| [[3.0.0-5]]
| [[FS:InitializeWithSdkVersion|InitializeWithSdkVersion]]
| None
|-
| 0x08620040
| [[3.0.0-5]]
| [[FS:SetPriority|SetPriority]]
| None
|-
| 0x08630000
| [[3.0.0-5]]
| [[FS:GetPriority|GetPriority]]
| None
|-
| 0x08640000
| [[3.0.0-5]]
| [[FS:Obsoleted_4_0_GetNandInfo|Obsoleted_4_0_GetNandInfo]]
| Stubbed, this returns an error
|-
| 0x08650140
| [[4.0.0-7]]
| [[FS:SetSaveDataSecureValue|SetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086600C0
| [[4.0.0-7]]
| [[FS:GetSaveDataSecureValue|GetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086700C4
| [[4.0.0-7]]
| [[FS:ControlSecureSave|ControlSecureSave]]
| 0x121004
|-
| 0x08680000
| [[4.0.0-7]]
| [[FS:GetMediaType|GetMediaType]]
| None
|-
| 0x08690000
| [[4.0.0-7]]
| [[FS:Obsoleted_4_0_GetNandEraseCount|Obsoleted_4_0_GetNandEraseCount]]
| Stubbed, this returns an error.
|-
| 0x086A0082
| [[4.0.0-7]]
| [[FS:ReadNandReport|ReadNandReport]]
| None
|-
| 0x086B00C2
|?
|SetOtherSaveDataSecureValue
| 00121004
|-
| 0x086C00C2
|?
|GetOtherSaveDataSecureValue
| 00121004
|-
| 0x086D0040
|?
|?
| 00020004
|-
| 0x086E00C0
|Related to Secure Value? Used in Pokemon Sun/Moon.
|SetThisSaveDataSecureValue
|None?
|-
| 0x086F0040
|Related to Secure Value? Used in Pokemon Sun/Moon.
|GetThisSaveDataSecureValue
| 0xE
|-
| 0x087000C2
|?
|?
|None?
|-
| 0x08710100
|?
|?
| 0xC
|-
| 0x087201C0
|?
|?
| 00080004
|-
| 0x087300C0
|?
|?
| 00080004
|-
| 0x08740000
|?
|?
| 00080004
|-
| 0x08750140
|?
|?
|None?
|-
| 0x087600C0
|?
|?
|None?
|-
| 0x08770100
|?
|?
|?
|-
| 0x087800C0
|?
|?
|?
|-
| 0x087900C2
| ?
| Same as GetLegacyBannerData, except for the last parameter this passes u8 value 0x1 instead of 0x0, for the FSPXI command.
| 0x00101015
|-
| 0x087A0180
| [[9.6.0-24|9.6.0-X]]
| [[FS:AddSeed|AddSeed]]
| 0x00200000
|-
| 0x087B....
| [[9.6.0-24|9.6.0-X]]
| Wrapper for the code internally used for command <0x087A....>.
| 0x00200000
|-
| 0x087C....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x087D0000
| [[9.6.0-24|9.6.0-X]]
| GetNumSeeds. Writes the number of seeds to cmdreply[2]
| 0x00200000
|-
| 0x087E0042
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>. Writes a list of titleIDs to the outbuf, this is for titles with content-lock-seed(s) stored in SEEDDB. (u32 total_titleids_probably, ((Size<<4) <nowiki>|</nowiki> 12), outbufptr)
| 0x00200000
|-
| 0x087F....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x0880....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0881....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0882....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x08830000
| [[9.6.0-24|9.6.0-X]]
| Writes an output value to cmdreply[2].
| 0x00200000
|-
| 0x08840042
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0885....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x088600C0
| [[11.1.0-34|11.1.0-X]]
| [[FS:CheckUpdatedDat|CheckUpdatedDat]]
| 0x00080000
|}

Note: The question marks from Dummy1 to GetSpecialFileSize on the "available since system version" field are mainly there because I think that most of these are necessary for the main system to function, so theoretically that would mean that since the creation of the 3DS these were available, or since launch if that makes more sense. But because of the peculiar nature of some of the functions, they will remain question marks until they can be confirmed 100%.

When access rights are required for a command, at least one of the bits in the process access info specified in the above table for the command must be set. Error 0xD9004676 is returned when a process attempts to use a command which it doesn't have access rights for the command. The exheader access info field is all zero's for most applications. Note that the permissions listed in the above table is for system-version v2.x, therefore permission bit(s) added with newer FIRM may be missing from this.

Each session for fs:USER has separate permissions, initially these are set to all zero's for new fs:USER sessions. The permissions/etc for fs:USER sessions are initialized via [[FS:Initialize]](loaded from the user process exheader).

== Filesystem service "fs:LDR" ==
This service is identical to fs:USER, except [[FS:OpenArchive]] archive 0x2345678E can only be accessed with fs:LDR.

== ProgramRegistry service "fs:REG" ==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| [[FSReg:Dummy1|Dummy1]]
|-
| 0x040103C0
| [[FSReg:Register|Register]]
|-
| 0x04020040
| [[FSReg:Unregister|Unregister]]
|-
| 0x040300C0
| [[FSReg:GetProgramInfo|GetProgramInfo]]
|-
| 0x04040100
| [[FSReg:LoadProgram|LoadProgram]]
|-
| 0x04050080
| [[FSReg:UnloadProgram|UnloadProgram]]
|-
| 0x04060080
| [[FSReg:CheckHostLoadId|CheckHostLoadId]]
|}

Only two sessions can be opened for this service at a time, hence no other processes can use this due to [[Process_Manager_Services|pm-module]] and [[Loader_Services|loader]] using this.

=File and directory access=
==Files==
File session handles obtained via [[FS:OpenFile]] et al can be used to access files through a service-like interface, despite not being an actual service registered using [[SRV:RegisterService]].

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| [[FSFile:Dummy1|Dummy1]]
|-
| 0x040100C4
| [[FSFile:Control|Control]]
|-
| 0x08010100
| [[FSFile:OpenSubFile|OpenSubFile]]
|-
| 0x080200C2
| [[FSFile:Read|Read]]
|-
| 0x08030102
| [[FSFile:Write|Write]]
|-
| 0x08040000
| [[FSFile:GetSize|GetSize]]
|-
| 0x08050080
| [[FSFile:SetSize|SetSize]]
|-
| 0x08060000
| [[FSFile:GetAttributes|GetAttributes]]
|-
| 0x08070040
| [[FSFile:SetAttributes|SetAttributes]]
|-
| 0x08080000
| [[FSFile:Close|Close]]
|-
| 0x08090000
| [[FSFile:Flush|Flush]]
|-
| 0x080A0040
| [[FSFile:SetPriority|SetPriority]]
|-
| 0x080B0000
| [[FSFile:GetPriority|GetPriority]]
|-
| 0x080C0000
| [[FSFile:OpenLinkFile|OpenLinkFile]]
|-
| 0x0C010100
| [[FSFile:GetAvailable|GetAvailable]]
|}

==Directories==
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x000100C6
| [[1.0.0-0]]
| [[FSDir:Dummy1|Dummy1]]
|-
| 0x040100C4
| [[1.0.0-0]]
| [[FSDir:Control|Control]]
|-
| 0x08010042
| [[1.0.0-0]]
| [[FSDir:Read|Read]]
|-
| 0x08020000
| [[1.0.0-0]]
| [[FSDir:Close|Close]]
|-
| 0x08030040
| ?
| [[FSDir:SetPriority|SetPriority]]
|-
| 0x08040000
| ?
| [[FSDir:GetPriority|GetPriority]]
|}

= Archives =
{| class="wikitable" border="1"
|-
! ArchiveId
! Description
! Accessible via [[Filesystem_services|FS]]
! Accessible via [[Filesystem_services_PXI|FSPXI]]
! Only accessible by Process9 internally
! Requires binary [[FS:OpenFile|Lowpath]]
! Required exheader FS access info bitmask
|-
| 0x00000003
| SelfNCCH (including [[#RomFS|RomFS]])
| Yes
| No
| No
| No
| None
|-
| 0x00000004
| SaveData (the saveID/mediatype for this is loaded from data originally from the user process' exheader)
| Yes
| No
| No
| No
| None
|-
| 0x00000006
| ExtSaveData
| Yes
| No
| No
| Yes
| 0x100D, when the input extdataID isn't listed in the exheader.
|-
| 0x00000007
| Shared ExtSaveData
| Yes
| No
| No
| Yes
| None
|-
| 0x00000008
| SystemSaveData
| Yes
| No
| No
| Yes
| 0x4, when the input saveID doesn't match the exheader system-saveID.
|-
| 0x00000009
| SDMC
| Yes
| Yes
| No
| No
| 0x8E
|-
| 0x0000000A
| SDMC Write-Only
| Yes
| No
| No
| No
| 0x808E
|-
| 0x12345678
| ExtSaveData for BOSS
| Yes
| No
| No
| Yes
| 0x44
|-
| 0x12345679
| CARD SPI FS
| Yes
| Yes
| No
| No
| 0x16
|-
| 0x1234567B
| ExtSaveData, and ExtSaveData for BOSS
| No
| Yes
| No
| Yes
|
|-
| 0x1234567C
| SystemSaveData
| No
| Yes
| No
| Yes
|
|-
| 0x1234567D
| NAND RW
| Yes
| Yes
| No
| No
| 0x800
|-
| 0x1234567E
| NAND RO
| Yes
| Yes
| No
| No
| 0x200
|-
| 0x1234567F
| NAND RO Write FS
| No
| Yes
| No
| No
| ?
|-
| 0x12345680
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x12345681
| Unknown. Accessed by FS service.
| ?
| ?
| No
| ?
| ?
|-
| 0x12345682
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x2345678A
| Used for accessing general NCCH data. With FSPXI this also allows savedata access.
| Yes
| Yes
| No
| Yes
| 0x1005
|-
| 0x2345678B
| ?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678C
| Used internally to access [[Title_Database|/dbs]] files?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678D
| ?
| No
| No
| Yes
| No
|
|-
| 0x2345678E
| FSPXI: Similar to archive 0x2345678A. For fs:LDR(used by the "loader" FIRM ARM11-process), only ExeFS. Not accessible with fs:USER.
| Yes
| Yes
| No
| Yes
| None, see description.
|-
| 0x567890AB
| NAND CTR FS
| No
| Yes
| No
| No
| ?
|-
| 0x567890AC
| TWL PHOTO
| Yes
| Yes
| No
| No
| ?
|-
| 0x567890AD
| TWLS (DSi Sound stores recordings here). This is mapped to the FAT12 image stored in the file at [[Twln/shared2/0000]].
| No
| Yes
| No
| No
| ?
|-
| 0x567890AE
| NAND TWL FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890AF
| NAND W FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890B0
| ?
| No
| Yes
| No
| No
|
|-
| 0x567890B1
| Gamecard SaveData (for check). This is a wrapper for UserSaveDataForCheck: the OpenArchive code for that is called with archive-lowpath TID=0/mediatype=2(gamecard).
| Yes
| No
| No
| No
| 0x6
|-
| 0x567890B2
| UserSaveData (for check). This is the same as the regular SaveData archive, except with this the savedata ID and mediatype is loaded from the input archive lowpath.
| Yes
| No
| No
| Yes
| 0x6
|-
| 0x567890B4
| Similar to 0x567890B2 but can only access Accessible Save specified in [[NCCH/Extended_Header#Storage_Info|exheader]]?
| Yes
| No
| No
| Yes
| ?
|}

Archives listed as not requiring a binary lowpath, use lowpath type [[FS:OpenFile|empty]].

The above permission bitmasks are from v2.x, see the above Services section for how these are handled.

Archives CTR NAND, NAND RO Write FS, TWL NAND, NAND W FS, and CARD SPI FS require the corresponding process exheader access control mount flag to be set, in the exheader for any of the currently running ARM11 processes, for [[Filesystem_services_PXI|FSPXI]]. The access rights checked by [[Filesystem services|FS]] module for archive mounting with fs:USER, are stored in the process' exheader accessinfo.

The CARDSPI archive allows access to the gamecard CARD1 raw savedata flash(aka "cardspi:/" in [[FIRM|Process9]]), the file lowpath must be WCHAR "/". The "NAND W FS" archive allows access to the raw NAND image(aka "wnand:/" in Process9), the file lowpath must be WCHAR "/".

= Filenames and Paths =
PathType:
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| -1
| Returned internally by Process9, when errors occur it seems(in particular when no nul-terminator was found in the input path). The data ptr is set to NULL.
|-
| 0x0
| INVALID - Specifies an invalid path
|-
| 0x1
| EMPTY - Specifies an empty path
|-
| 0x2
| BINARY - Non-text based path. Meaning is per-archive
|-
| 0x3
| ASCII - Text-based path with 7-bit ASCII characters padded to 8-bits each (signed char)
|-
| 0x4
| UTF16 - Text-based path with UTF-16 characters
|}

In IPC requests, sizes of ASCII and UTF16 paths must include space for the null-terminator.

== Binary LowPath ==
The format of the data that a binary LowPath points to is custom per archive.

=== SelfNCCH File Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Type:
* 0x0: RomFS
* 0x1: error 0xD9004676
* 0x2: ExeFS
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module crashes on this
* 0x5: Update RomFS?
|-
| 1-2
| File name for ExeFS ("icon"/"banner"/"logo"). ".code" is not allowed
|}

Note that ExeFS files only support reading from offset=0 and with size=file_size.

=== SystemSaveData Archive Path Data Format ===
==== FS ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be zero for NAND)
|-
| 1
| saveid
|}
The file/directory lowpath is a text lowpath in the [[Savegames|savegame]] filesystem.

==== FSPXI ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| u8 [[Mediatypes|Mediatype]] (must be zero for NAND)
|}
The file lowpath is a binary lowpath containing the u64 saveid, however the high word of the saveid is always zero. The mounted file is the cleartext savegame image. Up to 32 SystemSaveData image files can be opened under a single mounted FSPXI archive.

=== UserSaveDataForCheck Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be non-zero)
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
The file/directory lowpath for this FS archive is a text path in the [[Savegames|savegame]] filesystem.

=== 0x567890B4 Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| <code><nowiki>Lower_word_saveid >> 8</nowiki></code> ?
|-
| 2
| Unknown. Game calculate this using formula <code><nowiki>0xFFFFFF00 | unknown_b</nowiki></code>
|}

=== ExtSaveData Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
For FS, the file/directory lowpath is a text path in the [[extdata]] filesystem. For FSPXI, the file lowpath is a text path relative to the "/extdata/<ExtdataIDHigh>/<ExtdataIDLow>" directory on SD/NAND, for the cleartext extdata image to mount.

=== 0x2345678A Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Lower word programID
|-
| 1
| Upper word programID
|-
| 2
| ([[Mediatypes|Mediatype]] & 0xFF) | (uninitialized_data? & 0xFFFFFF00)
|-
| 3
| Number of something? Hardcoded per-archive, 0 for ExeFS, 200 for area:, 100 for rate:, 40 for eula:, etc.
|}

File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| 0 for NCCH data, 1 for savedata. The latter is only valid for FSPXI. Value 2 is allowed via archive 0x3, it's unknown what this is.
|-
| 1
| TMD content index / NCSD partition index.
|-
| 2
| Type: 0=romfs(0 for non-NCCH as well), 1=exefs ".code"(?), 2=exefs "icon"/"banner"/"logo", 3=unknown, 4=unknown, 5=unknown.
|-
| 3-4
| Filename for ExeFS.
|}

The 0x14-byte lowpath is all-zero for accessing the title's main RomFS.

=== [[RomFS]] ===

Archives 0x3 and 0x2345678E both allow for accessing the [[RomFS#Level_3_Format|level-3 IVFC images]] for RomFS access. The main CXI RomFS is accessible via an all-zero 0xc-byte binary file-lowpath. The update RomFS can be accessed with the first u32 in the binary file-lowpath being set to 0x5. The user must handle parsing the filesystem used in the exposed image itself.

With FSPXI the returned data for RomFS is the entire RomFS section from the NCCH, starting at the IVFC header.

The 0x3 archive is an interface for the 0x2345678E archive with the current process programID+mediatype. The file lowpath is 3-words. These words are written to 0x2345678E-archive file_lowpath+0, with the rest of that lowpath set to all-zero(lowpath is different from archive 0x2345678A). File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| See above. The only values which FS-module doesn't allow to be used here are:
* 0x1: Error 0xE0E046BE.
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module executes svcBreak when using this.
|-
| 1-2
| See above. Not validated by FS-module.
|}

=SEEDDB=
With [[9.6.0-24|9.6.0-X]] new [[System_SaveData]] with saveID 0001000F was added, this seems to be handled by FS-module itself, probably via the new service-cmds added to fsuser. [[Home Menu]] and [[NIM_Services|NIM]] module have access to those commands.

The SEEDDB savedata contains the title-unique seed-data used for the new [[NCCH]] keyY generation added with FIRM [[9.6.0-24|9.6.0-X]].

= Common Types =
== MediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| NAND
|-
| 1
| SD
|-
| 2
| Game Card
|}

== SystemMediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| CTR NAND
|-
| 1
| TWL NAND
|-
| 2
| SD
|-
| 3
| TWL Photo
|}

== OpenFlags ==
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0
| Read
|-
| 1
| Write
|-
| 2
| Create
|}

== Attributes ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Is Directory
|-
| 0x1
| 0x1
| Is Hidden
|-
| 0x2
| 0x1
| Is Archive
|-
| 0x3
| 0x1
| Is Read-Only
|}

== WriteOption ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Flush
|-
| 0x1
| 0x1
| Update Time Stamp
|-
| 0x2
| 0x1
| Reserved
|-
| 0x3
| 0x1
| Reserved
|}

== DirectoryEntry ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x20C
| UTF-16 Entry Name
|-
| 0x20C
| 0xA
| 8.3 short filename name
|-
| 0x216
| 0x4
| 8.3 short filename extension
|-
| 0x21A
| 0x1
| Always 1
|-
| 0x21B
| 0x1
| Reserved
|-
| 0x21C
| 0x4
| [[Filesystem_services#Attributes|Attributes]]
|-
| 0x220
| 0x8
| Entry Size
|}

== ArchiveResource ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Sector byte-size
|-
| 0x4
| 0x4
| Cluster byte-size
|-
| 0x8
| 0x4
| Partition capacity in clusters
|-
| 0xC
| 0x4
| Available free space in clusters
|}

== ProgramInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| Program ID
|-
| 0x8
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x9
| 0x7
| Padding
|}

== ProductInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Product Code
|-
| 0x10
| 0x2
| Company Code
|-
| 0x12
| 0x2
| Remaster Version
|}

== IntegrityVerificationSeed ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| AES-CBC MAC over a SHA256 hash, which hashes the first 0x110-bytes of the cleartext SEED.
|-
| 0x10
| 0x120
| The [[nand/private/movable.sed]], encrypted with AES-CTR using the above MAC for the counter.
|}

== ExtSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x8
| Save ID
|-
| 0xC
| 0x4
| Reserved
|}

== SystemSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x4
| Save ID
|}

== SecureValueSlot ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1000
| SD Application
|}

== CardSpiBaudRate ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 512KHz
|-
| 0x1
| 1MHz
|-
| 0x2
| 2MHz
|-
| 0x3
| 4MHz
|-
| 0x4
| 8MHz
|-
| 0x5
| 16MHz
|}

== CardSpiBusMode ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 1-bit
|-
| 0x1
| 4-bit
|}

== SpecialContentType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1
| Update
|-
| 0x2
| Manual
|-
| 0x3
| DLP Child
|}

== DeviceMoveContext ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| IVs
|-
| 0x10
| 0x10
| Encrypt Parameter
|}

=Errors=
See [[Filesystem_services_PXI]].

Filesystem services

2018-06-10T14:37:35Z

PabloMK7: Added missing names for some commands

[[Category:Services]]

= Services =
== Filesystem service "fs:USER" ==
You can at most have 32 FS archive handles.

{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
! scope="col" width="400" | Required [[NCCH/Extended_Header|exheader]] access info bitmask
|-
| 0x000100C6
|?
| [[FS:Dummy1|Dummy1]]
| None
|-
| 0x040100C4
|?
| [[FS:Control|Control]]
| None
|-
| 0x08010002
|?
| [[FS:Initialize|Initialize]]
| None
|-
| 0x080201C2
|?
| [[FS:OpenFile|OpenFile]]
| None
|-
| 0x08030204
|?
| [[FS:OpenFileDirectly|OpenFileDirectly]]
| None
|-
| 0x08040142
|?
| [[FS:DeleteFile|DeleteFile]]
| None
|-
| 0x08050244
|?
| [[FS:RenameFile|RenameFile]]
| None
|-
| 0x08060142
|?
| [[FS:DeleteDirectory|DeleteDirectory]]
| None
|-
| 0x08070142
|?
| [[FS:DeleteDirectoryRecursively|DeleteDirectoryRecursively]]
| None
|-
| 0x08080202
|?
| [[FS:CreateFile|CreateFile]]
| None
|-
| 0x08090182
|?
| [[FS:CreateDirectory|CreateDirectory]]
| None
|-
| 0x080A0244
|?
| [[FS:RenameDirectory|RenameDirectory]]
| None
|-
| 0x080B0102
|?
| [[FS:OpenDirectory|OpenDirectory]]
| None
|-
| 0x080C00C2
|?
| [[FS:OpenArchive|OpenArchive]]
| Each archive ID code has separate access info bitmasks, if it has any
|-
| 0x080D0144
|?
| [[FS:ControlArchive|ControlArchive]]
| None
|-
| 0x080E0080
|?
| [[FS:CloseArchive|CloseArchive]]
| None
|-
| 0x080F0180
|?
| [[FS:Obsoleted_2_0_FormatThisUserSaveData|Obsoleted_2_0_FormatThisUserSaveData]]
| None
|-
| 0x08100200
|?
| [[FS:Obsoleted_3_0_CreateSystemSaveData|Obsoleted_3_0_CreateSystemSaveData]]
| 0x4, for when the input saveID doesn't match the exheader saveID
|-
| 0x08110040
|?
| [[FS:Obsoleted_3_0_DeleteSystemSaveData|Obsoleted_3_0_DeleteSystemSaveData]]
| 0x1004, for when the input saveID doesn't match the exheader saveID
|-
| 0x08120080
|?
| [[FS:GetFreeBytes|GetFreeBytes]]
| None
|-
| 0x08130000
|?
| [[FS:GetCardType|GetCardType]]
| 0x1017
|-
| 0x08140000
|?
| [[FS:GetSdmcArchiveResource|GetSdmcArchiveResource]]
| None
|-
| 0x08150000
|?
| [[FS:GetNandArchiveResource|GetNandArchiveResource]]
| 0x1007
|-
| 0x08160000
|?
| [[FS:GetSdmcFatfsError|GetSdmcFatfsError]]
| 0x2
|-
| 0x08170000
|?
| [[FS:IsSdmcDetected|IsSdmcDetected]]
| None
|-
| 0x08180000
|?
| [[FS:IsSdmcWritable|IsSdmcWritable]]
| None
|-
| 0x08190042
|?
| [[FS:GetSdmcCid|GetSdmcCid]]
| 0x2
|-
| 0x081A0042
|?
| [[FS:GetNandCid|GetNandCid]]
| 0x2
|-
| 0x081B0000
|?
| [[FS:GetSdmcSpeedInfo|GetSdmcSpeedInfo]]
| 0x2
|-
| 0x081C0000
|?
| [[FS:GetNandSpeedInfo|GetNandSpeedInfo]]
| 0x2
|-
| 0x081D0042
|?
| [[FS:GetSdmcLog|GetSdmcLog]]
| 0x2
|-
| 0x081E0042
|?
| [[FS:GetNandLog|GetNandLog]]
| 0x2
|-
| 0x081F0000
|?
| [[FS:ClearSdmcLog|ClearSdmcLog]]
| 0x2
|-
| 0x08200000
|?
| [[FS:ClearNandLog|ClearNandLog]]
| 0x2
|-
| 0x08210000
|?
| [[FS:CardSlotIsInserted|CardSlotIsInserted]]
| 0x1017
|-
| 0x08220000
|?
| [[FS:CardSlotPowerOn|CardSlotPowerOn]]
| 0x2
|-
| 0x08230000
|?
| [[FS:CardSlotPowerOff|CardSlotPowerOff]]
| 0x2
|-
| 0x08240000
|?
| [[FS:CardSlotGetCardIFPowerStatus|CardSlotGetCardIFPowerStatus]]
| 0x2
|-
| 0x08250040
|?
| [[FS:CardNorDirectCommand|CardNorDirectCommand]]
| 0x2
|-
| 0x08260080
|?
| [[FS:CardNorDirectCommandWithAddress|CardNorDirectCommandWithAddress]]
| 0x2
|-
| 0x08270082
|?
| [[FS:CardNorDirectRead|CardNorDirectRead]]
| 0x2
|-
| 0x082800C2
|?
| [[FS:CardNorDirectReadWithAddress|CardNorDirectReadWithAddress]]
| 0x2
|-
| 0x08290082
|?
| [[FS:CardNorDirectWrite|CardNorDirectWrite]]
| 0x2
|-
| 0x082A00C2
|?
| [[FS:CardNorDirectWriteWithAddress|CardNorDirectWriteWithAddress]]
| 0x2
|-
| 0x082B00C2
|?
| [[FS:CardNorDirectRead_4xIO|CardNorDirectRead_4xIO]]
| 0x2
|-
| 0x082C0082
|?
| [[FS:CardNorDirectCpuWriteWithoutVerify|CardNorDirectCpuWriteWithoutVerify]]
| 0x2
|-
| 0x082D0040
|?
| [[FS:CardNorDirectSectorEraseWithoutVerify|CardNorDirectSectorEraseWithoutVerify]]
| 0x2
|-
| 0x082E0040
|?
| [[FS:GetProductInfo|GetProductInfo]]
| 0x1005
|-
| 0x082F0040
|?
| [[FS:GetProgramLaunchInfo|GetProgramLaunchInfo]]
| 0x1005
|-
| 0x08300182
|?
| [[FS:Obsoleted_3_0_CreateExtSaveData|Obsoleted_3_0_CreateExtSaveData]]
| 0xC, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08310180
|?
| [[FS:Obsoleted_3_0_CreateSharedExtSaveData|Obsoleted_3_0_CreateSharedExtSaveData]]
| 0x1005
|-
| 0x08320102
|?
| [[FS:Obsoleted_3_0_ReadExtSaveDataIcon|Obsoleted_3_0_ReadExtSaveDataIcon]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08330082
|?
| [[FS:Obsoleted_3_0_EnumerateExtSaveData|Obsoleted_3_0_EnumerateExtSaveData]]
| 0x1005
|-
| 0x08340082
|?
| [[FS:Obsoleted_3_0_EnumerateSharedExtSaveData|Obsoleted_3_0_EnumerateSharedExtSaveData]]
| 0x1005
|-
| 0x08350080
|?
| [[FS:Obsoleted_3_0_DeleteExtSaveData|Obsoleted_3_0_DeleteExtSaveData]]
| 0x100D, for when the input extdataID doesn't match the exheader extdataID
|-
| 0x08360080
|?
| [[FS:Obsoleted_3_0_DeleteSharedExtSaveData|Obsoleted_3_0_DeleteSharedExtSaveData]]
| 0x1005
|-
| 0x08370040
|?
| [[FS:SetCardSpiBaudRate|SetCardSpiBaudRate]]
| 0x2
|-
| 0x08380040
|?
| [[FS:SetCardSpiBusMode|SetCardSpiBusMode]]
| 0x2
|-
| 0x08390000
|?
| [[FS:SendInitializeInfoTo9|SendInitializeInfoTo9]]
| None
|-
| 0x083A0100
|?
| [[FS:GetSpecialContentIndex|GetSpecialContentIndex]]
| 0x1005
|-
| 0x083B00C2
|?
| [[FS:GetLegacyRomHeader|GetLegacyRomHeader]]
| 0x1015
|-
| 0x083C00C2
|?
| [[FS:GetLegacyBannerData|GetLegacyBannerData]]
| 0x1015
|-
| 0x083D0100
|?
| [[FS:CheckAuthorityToAccessExtSaveData|CheckAuthorityToAccessExtSaveData]]
| 0x44
|-
| 0x083E00C2
|?
| [[FS:QueryTotalQuotaSize|QueryTotalQuotaSize]]
| None
|-
| 0x083F00C0
|?
| [[FS:Obsoleted_3_0_GetExtDataBlockSize|Obsoleted_3_0_GetExtDataBlockSize]]
| None
|-
| 0x08400040
|?
| [[FS:AbnegateAccessRight|AbnegateAccessRight]]
|?
|-
| 0x08410000
|?
| [[FS:DeleteSdmcRoot|DeleteSdmcRoot]]
| 0x1005
|-
| 0x08420040
|?
| [[FS:DeleteAllExtSaveDataOnNand|DeleteAllExtSaveDataOnNand]]
| 0x1005
|-
| 0x08430000
|?
| [[FS:InitializeCtrFileSystem|InitializeCtrFileSystem]]
| None
|-
| 0x08440000
|?
| [[FS:CreateSeed|CreateSeed]]
| 0x2
|-
| 0x084500C2
|?
| [[FS:GetFormatInfo|GetFormatInfo]]
|?
|-
| 0x08460102
|?
| [[FS:GetLegacyRomHeader2|GetLegacyRomHeader2]]
| 0x1015
|-
| 0x08470180
|?
| [[FS:Obsoleted_2_0_FormatCtrCardUserSaveData|Obsoleted_2_0_FormatCtrCardUserSaveData]]
| 0x6
|-
| 0x08480042
|?
| [[FS:GetSdmcCtrRootPath|GetSdmcCtrRootPath]]
| 0x100D
|-
| 0x08490040
|?
| [[FS:GetArchiveResource|GetArchiveResource]]
|?
|-
| 0x084A0002
|?
| [[FS:ExportIntegrityVerificationSeed|ExportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084B0002
|?
| [[FS:ImportIntegrityVerificationSeed|ImportIntegrityVerificationSeed]]
| 0x4000
|-
| 0x084C0242
|?
| [[FS:FormatSaveData|FormatSaveData]]
| 0x6, in some cases this write isn't needed however
|-
| 0x084D0102
|?
| [[FS:GetLegacySubBannerData|GetLegacySubBannerData]]
| 0x1015
|-
| 0x084E0342
|?
| [[FS:UpdateSha256Context|UpdateSha256Context]]
| 0x5
|-
| 0x084F0102
|?
| [[FS:ReadSpecialFile|ReadSpecialFile]]
| None
|-
| 0x08500040
|?
| [[FS:GetSpecialFileSize|GetSpecialFileSize]]
| None
|-
| 0x08510242
| [[3.0.0-5]]
| [[FS:CreateExtSaveData|CreateExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0xC
|-
| 0x08520100
| [[3.0.0-5]]
| [[FS:DeleteExtSaveData|DeleteExtSaveData]]
| Shared extdata: 0x101005. Regular extdata in certain cases: 0x10100D
|-
| 0x08530142
| [[3.0.0-5]]
| [[FS:ReadExtSaveDataIcon|ReadExtSaveDataIcon]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x085400C0
| [[3.0.0-5]]
| [[FS:GetExtDataBlockSize|GetExtDataBlockSize]]
| 0x10100D (this doesn't apply in certain cases, however)
|-
| 0x08550102
| [[3.0.0-5]]
| [[FS:EnumerateExtSaveData|EnumerateExtSaveData]]
| 0x101005
|-
| 0x08560240
| [[3.0.0-5]]
| [[FS:CreateSystemSaveData|CreateSystemSaveData]]
| 0x4 (this doesn't apply in certain cases, however)
|-
| 0x08570080
| [[3.0.0-5]]
| [[FS:DeleteSystemSaveData|DeleteSystemSaveData]]
| 0x1004 (this doesn't apply in certain cases, however)
|-
| 0x08580000
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsSource|StartDeviceMoveAsSource]]
| 0x2004
|-
| 0x08590200
| [[3.0.0-5]]
| [[FS:StartDeviceMoveAsDestination|StartDeviceMoveAsDestination]]
| 0x2004
|-
| 0x085A00C0
| [[3.0.0-5]]
| [[FS:SetArchivePriority|SetArchivePriority]]
| None
|-
| 0x085B0080
| [[3.0.0-5]]
| [[FS:GetArchivePriority|GetArchivePriority]]
| None
|-
| 0x085C00C0
| [[3.0.0-5]]
| [[FS:SetCtrCardLatencyParameter|SetCtrCardLatencyParameter]]
| 0xE
|-
| 0x085D01C0
| [[3.0.0-5]]
| [[FS:SetFsCompatibilityInfo|SetFsCompatibilityInfo]]
| 0x100001
|-
| 0x085E0040
| [[3.0.0-5]]
| [[FS:ResetCardCompatibilityParameter|ResetCardCompatibilityParameter]]
| 0xE
|-
| 0x085F0040
| [[3.0.0-5]]
| [[FS:SwitchCleanupInvalidSaveData|SwitchCleanupInvalidSaveData]]
| 0x12004
|-
| 0x08600042
| [[3.0.0-5]]
| [[FS:EnumerateSystemSaveData|EnumerateSystemSaveData]]
| 0x2004
|-
| 0x08610042
| [[3.0.0-5]]
| [[FS:InitializeWithSdkVersion|InitializeWithSdkVersion]]
| None
|-
| 0x08620040
| [[3.0.0-5]]
| [[FS:SetPriority|SetPriority]]
| None
|-
| 0x08630000
| [[3.0.0-5]]
| [[FS:GetPriority|GetPriority]]
| None
|-
| 0x08640000
| [[3.0.0-5]]
| [[FS:Obsoleted_4_0_GetNandInfo|Obsoleted_4_0_GetNandInfo]]
| Stubbed, this returns an error
|-
| 0x08650140
| [[4.0.0-7]]
| [[FS:SetSaveDataSecureValue|SetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086600C0
| [[4.0.0-7]]
| [[FS:GetSaveDataSecureValue|GetSaveDataSecureValue]]
| 0x121004 (in certain cases this doesn't apply, however)
|-
| 0x086700C4
| [[4.0.0-7]]
| [[FS:ControlSecureSave|ControlSecureSave]]
| 0x121004
|-
| 0x08680000
| [[4.0.0-7]]
| [[FS:GetMediaType|GetMediaType]]
| None
|-
| 0x08690000
| [[4.0.0-7]]
| [[FS:Obsoleted_4_0_GetNandEraseCount|Obsoleted_4_0_GetNandEraseCount]]
| Stubbed, this returns an error.
|-
| 0x086A0082
| [[4.0.0-7]]
| [[FS:ReadNandReport|ReadNandReport]]
| None
|-
| 0x086B00C2
|?
|?
| 00121004
|-
| 0x086C00C2
|?
|?
| 00121004
|-
| 0x086D0040
|?
|?
| 00020004
|-
| 0x086E00C0
|Related to Secure Value? Used in Pokemon Sun/Moon.
|SetThisSaveDataSecureValue
|None?
|-
| 0x086F0040
|Related to Secure Value? Used in Pokemon Sun/Moon.
|GetThisSaveDataSecureValue
| 0xE
|-
| 0x087000C2
|?
|?
|None?
|-
| 0x08710100
|?
|?
| 0xC
|-
| 0x087201C0
|?
|?
| 00080004
|-
| 0x087300C0
|?
|?
| 00080004
|-
| 0x08740000
|?
|?
| 00080004
|-
| 0x08750140
|?
|?
|None?
|-
| 0x087600C0
|?
|?
|None?
|-
| 0x08770100
|?
|?
|?
|-
| 0x087800C0
|?
|?
|?
|-
| 0x087900C2
| ?
| Same as GetLegacyBannerData, except for the last parameter this passes u8 value 0x1 instead of 0x0, for the FSPXI command.
| 0x00101015
|-
| 0x087A0180
| [[9.6.0-24|9.6.0-X]]
| [[FS:AddSeed|AddSeed]]
| 0x00200000
|-
| 0x087B....
| [[9.6.0-24|9.6.0-X]]
| Wrapper for the code internally used for command <0x087A....>.
| 0x00200000
|-
| 0x087C....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x087D0000
| [[9.6.0-24|9.6.0-X]]
| GetNumSeeds. Writes the number of seeds to cmdreply[2]
| 0x00200000
|-
| 0x087E0042
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>. Writes a list of titleIDs to the outbuf, this is for titles with content-lock-seed(s) stored in SEEDDB. (u32 total_titleids_probably, ((Size<<4) <nowiki>|</nowiki> 12), outbufptr)
| 0x00200000
|-
| 0x087F....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x0880....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0881....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0882....
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x08830000
| [[9.6.0-24|9.6.0-X]]
| Writes an output value to cmdreply[2].
| 0x00200000
|-
| 0x08840042
| [[9.6.0-24|9.6.0-X]]
| Eventually calls same code as command <0x087A....>.
| 0x00200000
|-
| 0x0885....
| [[9.6.0-24|9.6.0-X]]
| ?
| 0x00200000
|-
| 0x088600C0
| [[11.1.0-34|11.1.0-X]]
| [[FS:CheckUpdatedDat|CheckUpdatedDat]]
| 0x00080000
|}

Note: The question marks from Dummy1 to GetSpecialFileSize on the "available since system version" field are mainly there because I think that most of these are necessary for the main system to function, so theoretically that would mean that since the creation of the 3DS these were available, or since launch if that makes more sense. But because of the peculiar nature of some of the functions, they will remain question marks until they can be confirmed 100%.

When access rights are required for a command, at least one of the bits in the process access info specified in the above table for the command must be set. Error 0xD9004676 is returned when a process attempts to use a command which it doesn't have access rights for the command. The exheader access info field is all zero's for most applications. Note that the permissions listed in the above table is for system-version v2.x, therefore permission bit(s) added with newer FIRM may be missing from this.

Each session for fs:USER has separate permissions, initially these are set to all zero's for new fs:USER sessions. The permissions/etc for fs:USER sessions are initialized via [[FS:Initialize]](loaded from the user process exheader).

== Filesystem service "fs:LDR" ==
This service is identical to fs:USER, except [[FS:OpenArchive]] archive 0x2345678E can only be accessed with fs:LDR.

== ProgramRegistry service "fs:REG" ==
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| [[FSReg:Dummy1|Dummy1]]
|-
| 0x040103C0
| [[FSReg:Register|Register]]
|-
| 0x04020040
| [[FSReg:Unregister|Unregister]]
|-
| 0x040300C0
| [[FSReg:GetProgramInfo|GetProgramInfo]]
|-
| 0x04040100
| [[FSReg:LoadProgram|LoadProgram]]
|-
| 0x04050080
| [[FSReg:UnloadProgram|UnloadProgram]]
|-
| 0x04060080
| [[FSReg:CheckHostLoadId|CheckHostLoadId]]
|}

Only two sessions can be opened for this service at a time, hence no other processes can use this due to [[Process_Manager_Services|pm-module]] and [[Loader_Services|loader]] using this.

=File and directory access=
==Files==
File session handles obtained via [[FS:OpenFile]] et al can be used to access files through a service-like interface, despite not being an actual service registered using [[SRV:RegisterService]].

{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x000100C6
| [[FSFile:Dummy1|Dummy1]]
|-
| 0x040100C4
| [[FSFile:Control|Control]]
|-
| 0x08010100
| [[FSFile:OpenSubFile|OpenSubFile]]
|-
| 0x080200C2
| [[FSFile:Read|Read]]
|-
| 0x08030102
| [[FSFile:Write|Write]]
|-
| 0x08040000
| [[FSFile:GetSize|GetSize]]
|-
| 0x08050080
| [[FSFile:SetSize|SetSize]]
|-
| 0x08060000
| [[FSFile:GetAttributes|GetAttributes]]
|-
| 0x08070040
| [[FSFile:SetAttributes|SetAttributes]]
|-
| 0x08080000
| [[FSFile:Close|Close]]
|-
| 0x08090000
| [[FSFile:Flush|Flush]]
|-
| 0x080A0040
| [[FSFile:SetPriority|SetPriority]]
|-
| 0x080B0000
| [[FSFile:GetPriority|GetPriority]]
|-
| 0x080C0000
| [[FSFile:OpenLinkFile|OpenLinkFile]]
|-
| 0x0C010100
| [[FSFile:GetAvailable|GetAvailable]]
|}

==Directories==
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x000100C6
| [[1.0.0-0]]
| [[FSDir:Dummy1|Dummy1]]
|-
| 0x040100C4
| [[1.0.0-0]]
| [[FSDir:Control|Control]]
|-
| 0x08010042
| [[1.0.0-0]]
| [[FSDir:Read|Read]]
|-
| 0x08020000
| [[1.0.0-0]]
| [[FSDir:Close|Close]]
|-
| 0x08030040
| ?
| [[FSDir:SetPriority|SetPriority]]
|-
| 0x08040000
| ?
| [[FSDir:GetPriority|GetPriority]]
|}

= Archives =
{| class="wikitable" border="1"
|-
! ArchiveId
! Description
! Accessible via [[Filesystem_services|FS]]
! Accessible via [[Filesystem_services_PXI|FSPXI]]
! Only accessible by Process9 internally
! Requires binary [[FS:OpenFile|Lowpath]]
! Required exheader FS access info bitmask
|-
| 0x00000003
| SelfNCCH (including [[#RomFS|RomFS]])
| Yes
| No
| No
| No
| None
|-
| 0x00000004
| SaveData (the saveID/mediatype for this is loaded from data originally from the user process' exheader)
| Yes
| No
| No
| No
| None
|-
| 0x00000006
| ExtSaveData
| Yes
| No
| No
| Yes
| 0x100D, when the input extdataID isn't listed in the exheader.
|-
| 0x00000007
| Shared ExtSaveData
| Yes
| No
| No
| Yes
| None
|-
| 0x00000008
| SystemSaveData
| Yes
| No
| No
| Yes
| 0x4, when the input saveID doesn't match the exheader system-saveID.
|-
| 0x00000009
| SDMC
| Yes
| Yes
| No
| No
| 0x8E
|-
| 0x0000000A
| SDMC Write-Only
| Yes
| No
| No
| No
| 0x808E
|-
| 0x12345678
| ExtSaveData for BOSS
| Yes
| No
| No
| Yes
| 0x44
|-
| 0x12345679
| CARD SPI FS
| Yes
| Yes
| No
| No
| 0x16
|-
| 0x1234567B
| ExtSaveData, and ExtSaveData for BOSS
| No
| Yes
| No
| Yes
|
|-
| 0x1234567C
| SystemSaveData
| No
| Yes
| No
| Yes
|
|-
| 0x1234567D
| NAND RW
| Yes
| Yes
| No
| No
| 0x800
|-
| 0x1234567E
| NAND RO
| Yes
| Yes
| No
| No
| 0x200
|-
| 0x1234567F
| NAND RO Write FS
| No
| Yes
| No
| No
| ?
|-
| 0x12345680
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x12345681
| Unknown. Accessed by FS service.
| ?
| ?
| No
| ?
| ?
|-
| 0x12345682
| Unknown. There's code for this in spider v9.9, but that code isn't actually used.
| Yes
| ?
| No
| Yes
| ?
|-
| 0x2345678A
| Used for accessing general NCCH data. With FSPXI this also allows savedata access.
| Yes
| Yes
| No
| Yes
| 0x1005
|-
| 0x2345678B
| ?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678C
| Used internally to access [[Title_Database|/dbs]] files?
| No
| No
| Yes
| Yes
|
|-
| 0x2345678D
| ?
| No
| No
| Yes
| No
|
|-
| 0x2345678E
| FSPXI: Similar to archive 0x2345678A. For fs:LDR(used by the "loader" FIRM ARM11-process), only ExeFS. Not accessible with fs:USER.
| Yes
| Yes
| No
| Yes
| None, see description.
|-
| 0x567890AB
| NAND CTR FS
| No
| Yes
| No
| No
| ?
|-
| 0x567890AC
| TWL PHOTO
| Yes
| Yes
| No
| No
| ?
|-
| 0x567890AD
| TWLS (DSi Sound stores recordings here). This is mapped to the FAT12 image stored in the file at [[Twln/shared2/0000]].
| No
| Yes
| No
| No
| ?
|-
| 0x567890AE
| NAND TWL FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890AF
| NAND W FS
| Yes
| Yes
| No
| No
| 0x100
|-
| 0x567890B0
| ?
| No
| Yes
| No
| No
|
|-
| 0x567890B1
| Gamecard SaveData (for check). This is a wrapper for UserSaveDataForCheck: the OpenArchive code for that is called with archive-lowpath TID=0/mediatype=2(gamecard).
| Yes
| No
| No
| No
| 0x6
|-
| 0x567890B2
| UserSaveData (for check). This is the same as the regular SaveData archive, except with this the savedata ID and mediatype is loaded from the input archive lowpath.
| Yes
| No
| No
| Yes
| 0x6
|-
| 0x567890B4
| Similar to 0x567890B2 but can only access Accessible Save specified in [[NCCH/Extended_Header#Storage_Info|exheader]]?
| Yes
| No
| No
| Yes
| ?
|}

Archives listed as not requiring a binary lowpath, use lowpath type [[FS:OpenFile|empty]].

The above permission bitmasks are from v2.x, see the above Services section for how these are handled.

Archives CTR NAND, NAND RO Write FS, TWL NAND, NAND W FS, and CARD SPI FS require the corresponding process exheader access control mount flag to be set, in the exheader for any of the currently running ARM11 processes, for [[Filesystem_services_PXI|FSPXI]]. The access rights checked by [[Filesystem services|FS]] module for archive mounting with fs:USER, are stored in the process' exheader accessinfo.

The CARDSPI archive allows access to the gamecard CARD1 raw savedata flash(aka "cardspi:/" in [[FIRM|Process9]]), the file lowpath must be WCHAR "/". The "NAND W FS" archive allows access to the raw NAND image(aka "wnand:/" in Process9), the file lowpath must be WCHAR "/".

= Filenames and Paths =
PathType:
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| -1
| Returned internally by Process9, when errors occur it seems(in particular when no nul-terminator was found in the input path). The data ptr is set to NULL.
|-
| 0x0
| INVALID - Specifies an invalid path
|-
| 0x1
| EMPTY - Specifies an empty path
|-
| 0x2
| BINARY - Non-text based path. Meaning is per-archive
|-
| 0x3
| ASCII - Text-based path with 7-bit ASCII characters padded to 8-bits each (signed char)
|-
| 0x4
| UTF16 - Text-based path with UTF-16 characters
|}

In IPC requests, sizes of ASCII and UTF16 paths must include space for the null-terminator.

== Binary LowPath ==
The format of the data that a binary LowPath points to is custom per archive.

=== SelfNCCH File Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Type:
* 0x0: RomFS
* 0x1: error 0xD9004676
* 0x2: ExeFS
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module crashes on this
* 0x5: Update RomFS?
|-
| 1-2
| File name for ExeFS ("icon"/"banner"/"logo"). ".code" is not allowed
|}

Note that ExeFS files only support reading from offset=0 and with size=file_size.

=== SystemSaveData Archive Path Data Format ===
==== FS ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be zero for NAND)
|-
| 1
| saveid
|}
The file/directory lowpath is a text lowpath in the [[Savegames|savegame]] filesystem.

==== FSPXI ====
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| u8 [[Mediatypes|Mediatype]] (must be zero for NAND)
|}
The file lowpath is a binary lowpath containing the u64 saveid, however the high word of the saveid is always zero. The mounted file is the cleartext savegame image. Up to 32 SystemSaveData image files can be opened under a single mounted FSPXI archive.

=== UserSaveDataForCheck Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]] (must be non-zero)
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
The file/directory lowpath for this FS archive is a text path in the [[Savegames|savegame]] filesystem.

=== 0x567890B4 Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| <code><nowiki>Lower_word_saveid >> 8</nowiki></code> ?
|-
| 2
| Unknown. Game calculate this using formula <code><nowiki>0xFFFFFF00 | unknown_b</nowiki></code>
|}

=== ExtSaveData Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| [[Mediatypes|Mediatype]]
|-
| 1
| Lower word saveid
|-
| 2
| Upper word saveid
|}
For FS, the file/directory lowpath is a text path in the [[extdata]] filesystem. For FSPXI, the file lowpath is a text path relative to the "/extdata/<ExtdataIDHigh>/<ExtdataIDLow>" directory on SD/NAND, for the cleartext extdata image to mount.

=== 0x2345678A Archive Path Data Format ===
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| Lower word programID
|-
| 1
| Upper word programID
|-
| 2
| ([[Mediatypes|Mediatype]] & 0xFF) | (uninitialized_data? & 0xFFFFFF00)
|-
| 3
| Number of something? Hardcoded per-archive, 0 for ExeFS, 200 for area:, 100 for rate:, 40 for eula:, etc.
|}

File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| 0 for NCCH data, 1 for savedata. The latter is only valid for FSPXI. Value 2 is allowed via archive 0x3, it's unknown what this is.
|-
| 1
| TMD content index / NCSD partition index.
|-
| 2
| Type: 0=romfs(0 for non-NCCH as well), 1=exefs ".code"(?), 2=exefs "icon"/"banner"/"logo", 3=unknown, 4=unknown, 5=unknown.
|-
| 3-4
| Filename for ExeFS.
|}

The 0x14-byte lowpath is all-zero for accessing the title's main RomFS.

=== [[RomFS]] ===

Archives 0x3 and 0x2345678E both allow for accessing the [[RomFS#Level_3_Format|level-3 IVFC images]] for RomFS access. The main CXI RomFS is accessible via an all-zero 0xc-byte binary file-lowpath. The update RomFS can be accessed with the first u32 in the binary file-lowpath being set to 0x5. The user must handle parsing the filesystem used in the exposed image itself.

With FSPXI the returned data for RomFS is the entire RomFS section from the NCCH, starting at the IVFC header.

The 0x3 archive is an interface for the 0x2345678E archive with the current process programID+mediatype. The file lowpath is 3-words. These words are written to 0x2345678E-archive file_lowpath+0, with the rest of that lowpath set to all-zero(lowpath is different from archive 0x2345678A). File lowpath:
{| class="wikitable" border="1"
|-
! Index word
! Description
|-
| 0
| See above. The only values which FS-module doesn't allow to be used here are:
* 0x1: Error 0xE0E046BE.
* 0x3: Error 0xE0E046BE.
* 0x4: FS-module executes svcBreak when using this.
|-
| 1-2
| See above. Not validated by FS-module.
|}

=SEEDDB=
With [[9.6.0-24|9.6.0-X]] new [[System_SaveData]] with saveID 0001000F was added, this seems to be handled by FS-module itself, probably via the new service-cmds added to fsuser. [[Home Menu]] and [[NIM_Services|NIM]] module have access to those commands.

The SEEDDB savedata contains the title-unique seed-data used for the new [[NCCH]] keyY generation added with FIRM [[9.6.0-24|9.6.0-X]].

= Common Types =
== MediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| NAND
|-
| 1
| SD
|-
| 2
| Game Card
|}

== SystemMediaType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| CTR NAND
|-
| 1
| TWL NAND
|-
| 2
| SD
|-
| 3
| TWL Photo
|}

== OpenFlags ==
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0
| Read
|-
| 1
| Write
|-
| 2
| Create
|}

== Attributes ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Is Directory
|-
| 0x1
| 0x1
| Is Hidden
|-
| 0x2
| 0x1
| Is Archive
|-
| 0x3
| 0x1
| Is Read-Only
|}

== WriteOption ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Flush
|-
| 0x1
| 0x1
| Update Time Stamp
|-
| 0x2
| 0x1
| Reserved
|-
| 0x3
| 0x1
| Reserved
|}

== DirectoryEntry ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x20C
| UTF-16 Entry Name
|-
| 0x20C
| 0xA
| 8.3 short filename name
|-
| 0x216
| 0x4
| 8.3 short filename extension
|-
| 0x21A
| 0x1
| Always 1
|-
| 0x21B
| 0x1
| Reserved
|-
| 0x21C
| 0x4
| [[Filesystem_services#Attributes|Attributes]]
|-
| 0x220
| 0x8
| Entry Size
|}

== ArchiveResource ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Sector byte-size
|-
| 0x4
| 0x4
| Cluster byte-size
|-
| 0x8
| 0x4
| Partition capacity in clusters
|-
| 0xC
| 0x4
| Available free space in clusters
|}

== ProgramInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| Program ID
|-
| 0x8
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x9
| 0x7
| Padding
|}

== ProductInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| Product Code
|-
| 0x10
| 0x2
| Company Code
|-
| 0x12
| 0x2
| Remaster Version
|}

== IntegrityVerificationSeed ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| AES-CBC MAC over a SHA256 hash, which hashes the first 0x110-bytes of the cleartext SEED.
|-
| 0x10
| 0x120
| The [[nand/private/movable.sed]], encrypted with AES-CTR using the above MAC for the counter.
|}

== ExtSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x8
| Save ID
|-
| 0xC
| 0x4
| Reserved
|}

== SystemSaveDataInfo ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| [[Filesystem_services#MediaType|Media Type]]
|-
| 0x1
| 0x1
| Unknown
|-
| 0x2
| 0x2
| Reserved
|-
| 0x4
| 0x4
| Save ID
|}

== SecureValueSlot ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1000
| SD Application
|}

== CardSpiBaudRate ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 512KHz
|-
| 0x1
| 1MHz
|-
| 0x2
| 2MHz
|-
| 0x3
| 4MHz
|-
| 0x4
| 8MHz
|-
| 0x5
| 16MHz
|}

== CardSpiBusMode ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x0
| 1-bit
|-
| 0x1
| 4-bit
|}

== SpecialContentType ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x1
| Update
|-
| 0x2
| Manual
|-
| 0x3
| DLP Child
|}

== DeviceMoveContext ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x10
| IVs
|-
| 0x10
| 0x10
| Encrypt Parameter
|}

=Errors=
See [[Filesystem_services_PXI]].

MCURTC:SetInfoLEDPattern

2017-10-07T09:42:46Z

PabloMK7:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x003B0640]
|-
| 1
| Animation
|-
| 2-9
| u8[32] Red pattern
|-
| 10-17
| u8[32] Green pattern
|-
| 18-25
| u8[32] Blue pattern
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
This is used for controlling(including blinking) the notification LED. MCU module uses [[I2C_Services|I2C]] service command 0x001100C2 to write the input 0x64-bytes to MCU [[I2C]] register 0x2D.

=Animation=
{| class="wikitable" border="1"
|-
! u8 delay
! u8 smoothing
! u8 loop_delay
! u8 ???
|-
| ''delay = seconds * 0x10''

Since this data is represented in a u8, the precision is 1/16th of a second (0x01) and the maximum delay time is 15.9375 seconds (0xFF).

If set to 0x00, only the first value of the pattern is played. (?)
| The lower the value is, the less smoothing is applied to the pattern. Here is a visual approximation of how the smoothing works: [https://i.imgur.com/ZxdPbIw.png Smooth function.]
| ''loop_delay = seconds * 0x10''
Since this data is represented in a u8, the precision is 1/16th of a second (0x01) and the maximum delay time is 15.875 seconds (0xFE).

If set to 0x00, there is no loop delay.

If set to 0xFF, the pattern is played only once.
| ???
|}

Talk:MCURTC:SetInfoLEDPattern

2017-10-07T09:39:00Z

PabloMK7: Created page with "Had to use an external link for the smooth function image as the "upload file" option of the wiki seems to be broken. ~~~~"

Had to use an external link for the smooth function image as the "upload file" option of the wiki seems to be broken. [[User:PabloMK7|PabloMK7]] ([[User talk:PabloMK7|talk]]) 13:38, 7 October 2017 (CEST)

MCURTC:SetInfoLEDPattern

2017-10-07T09:37:13Z

PabloMK7: Added more information to the animation fields.

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x003B0640]
|-
| 1
| Animation
|-
| 2-9
| u8[32] Red pattern
|-
| 10-17
| u8[32] Green pattern
|-
| 18-25
| u8[32] Blue pattern
|}

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|}

=Description=
This is used for controlling(including blinking) the notification LED. MCU module uses [[I2C_Services|I2C]] service command 0x001100C2 to write the input 0x64-bytes to MCU [[I2C]] register 0x2D.

=Animation=
{| class="wikitable" border="1"
|-
! u8 delay
! u8 smoothing
! u8 loop_delay
! u8 ???
|-
| ''delay = seconds * 0x10''

Since this data is represented in a u8, the precision is 1/16th of a second (0x01) and the maximum delay time is 15.9375 seconds (0xFF).

If set to 0x00, only the first value of the pattern is played. (?)
| The lower the value is, the less smoothing is applied to the pattern. Here is a visual approximation of how the smoothing works: [https://i.imgur.com/ZxdPbIw.png Smooth function.]

| ''loop_delay = seconds * 0x10''
Since this data is represented in a u8, the precision is 1/16th of a second (0x01) and the maximum delay time is 15.875 seconds (0xFE).

If set to 0x00, there is no loop delay.

If set to 0xFF, the pattern is played only once.
| ???
|}