3dbrew - User contributions [en]

Hardware

2017-02-16T01:36:53Z

Smea: /* Specifications */

This page lists and describes the hardware found inside the Nintendo 3DS. Many of these parts are custom made and are expanded upon here or in other pages.

== Common hardware ==
{| class="wikitable"
! Type !! Description
|-
| ARM11 Processor Core || Old3DS: [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/index.html ARM11 2x MPCore & 2x VFPv2 Co-Processor] 268MHz (268,111,856.0 ± 2-32 Hz, i.e. exactly twice the clock rate of the ARM9).

New3DS: 4x MPCore, 4x VFPv2, able to run up to 804MHz (see below). It also has an optional 2MB L2 cache.
|-
| ARM9 Processor Core || [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0201d/index.html ARM946] 134MHz (134,055,927.9 ± 2-32 Hz),
|-
| GPU || [http://en.wikipedia.org/wiki/PICA200 DMP PICA] 268MHz,
|-
| VRAM || 6 MB within SoC.
|-
| Top screen || 800x240, with only 400 usable pixels per eye per line.
|-
| Bottom screen || 320x240, with resistive touch overlay.
|-
| DSP || [https://twitter.com/CEVADSP/status/177172880918986752 CEVA TeakLite]. 134Mhz. 24ch 32728Hz sampling rates.
|}

New3DS exclusives are able to clock the CPU at 804MHz, but this appears to be limited to the currently running application/app cores. Timed by running svcGetSystemTick on either side of a long idle loop to stay in the current process context. svcGetSystemTick uses a tick counter running at 268MHz in this mode.

On New3DS: when Home Menu is active, the system runs at 804MHz. For everything else, it's 268MHz, except when the app(let) has the required flag set. See [[NCCH/Extended_Header|here]] and [[PDN_Registers|here]] for details, regarding clock-rate and cache.

For New3DS-only there are multiple clock-rate multiplier values available in [[PDN_Registers|hardware]], but since the relevant code is only implemented in the New3DS ARM11-kernel, the only non-normal clock-rate available with official kernel code is 3x.

== Specifications ==
{| class="wikitable"
! Type !! 3DS !! 3DSXL !! 2DS !! N3DS !! N3DSXL
|-
| SoC || CPU CTR (1048 0H)
CPU CTR (1214 32)
|| CPU CTR A (1226 60)
CPU CTR (1037 21)
|| CPU CTR B (??) || CPU LGR A (1444 86) || CPU LGR A (1446 17)
|-
| FCRAM || [http://www.fujitsu.com/downloads/MICRO/fma/pdf/MB81EDS516545_e511463.pdf 2x64MB Fujitsu MB82M8080-07L] || Fujitsu MB82DBS16641 || Fujitsu MB82DBS1664 || ?? || Fujitsu MB82MK9A9A
|-
| Top Screen || 3.53 in, 3D || 4.88 in, 3D || 3.53 in(?) cropped from a single panel || 3.88 in, 3D || 4.88 in, 3D
|-
| Bottom Screen || 3.00 in || 4.18 in || 3.00 in(?) cropped from a single panel || 3.33 in || 4.18 in
|-
| Storage ||colspan="3"| Toshiba THGBM2G3P1FBAI8 1GB ||colspan="2"| Samsung KLM4G1YEQC 4GB (in 1.3GiB SLC mode)
Toshiba THGBMBG4P1KBAIT 2GB (MLC, approx. 1.8GiB usable)
|-
| Speaker, Microphone, Circlepad, Touch controller || TI PAIC3010B 0AA37DW || ?? || ?? || TI AIC3010B 39C4ETW || TI AIC3010D 48C01JW
|-
| Gyroscope || [http://dl-web.dropbox.com/u/20520664/references/PS-ITG-3200-00-01.4.pdf Invensense ITG-3270 MEMS Gyroscope] || ?? || ?? || ?? || ??
|-
| Accelerometer || ST Micro 2048 33DH X1MAQ Accelerometer Model LIS331DH || ?? || ?? || ?? || ??
|-
| Wifi || Atheros AR6014 || ?? || ?? || ?? || Atheros AR6014G-AL1C
|-
| Infrared IC || NXP S750 0803 TSD031C || ?? || ?? || ?? || NXP S750 1603 TSD438C
|-
| Custom Microcontroller || Renesas UC CTR || ?? || Renesas UC CTR 324KM47 KG10 || Renesas UC KTR || Renesas UC KTR 442KM13 TK14
|-
| PMIC? || TI 93045A4 OAAH86W || ?? || ?? || TI 93045A4 38A6TYW G2 || TI 93045A4 49AF3NW G2
|-
| Wifi SPI Flash
| Raw ID data: 20 58 || ?? || ?? || Raw ID data: 62 62 || ??
|}

* [11] Official Documentation

* [5],[10] According to iFixit.com ([http://www.ifixit.com/Teardown/Nintendo-3DS-Teardown/5029/1#s22696 source]):

* Datasheet for memory is for a chip in the same series, it has less memory than the one inside the 3DS (128mbits vs 512mbits).

* There is a trove of data on the FCC website at [https://fjallfoss.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=N&application_id=462292&fcc_id=%27EW4DWMW028%27].

* [12] This IC is somewhat similar to [http://www.alldatasheet.net/datasheet-pdf/pdf/347838/NXP/SC16IS750IBS.html this].

* The Raw ID data for Wifi SPI Flash is from command 0x9F, RDID.

== FCRAM ==

There is one FCRAM (Fast Cycle RAM) IC in the 3DS, produced by Fujitsu and branded as MB82M8080-07L. The Fujitsu MB82M8080-07L chip internally contains 2 dies, where each die is branded MB81EDS516545 and MB82DBS08645.

The MB81EDS516545 die is a CMOS Fast Cycle Random Access Memory (FCRAM) with Low Power Double Data Rate (LPDDR) SDRAM Interface containing 512MBit storage accessible in a 64-bit format. The MB81EDS516545 is suited for consumer applications requiring high data bandwidth with low power consumption.

== SoC ==

The 3DS has much of it's internals housed in a SoC (System on Chip) just like it's predecessors. This is done to reduce build costs, cut down on power consumption, as well as make the PCB layout less complex and make the system harder to tamper with. The SoC, branded as the Nintendo 1048 0H, contains the CPU, GPU, DSP and VRAM.

According to official documents, the CPU used is a dual-core ARM11 CPU, clocked at 268MHz. One core is dedicated to system software, while the other is used for application programming, each known as the syscore and appcore, respectively.

== GPU ==

Designed by Digital Media Professionals Inc. (DMP) and codenamed PICA200, 268Mhz.

Block diagram of an ULTRAY2000 based architecture PICA200:

[[File:Pica200BlockDiagram.png]]

PICA200 is compatible with OpenGL ES 1.1. It furthermore provides unique functionality for:
* Per-fragment lighting ("Lighting Maestro")
* Hard- and soft-shadowing ("Shadow Maestro")
* Polygon subdivision ("Figure Maestro")
* Bump mapping and procedural textures ("Mapping Maestro")
* Rendering of gaseous objects ("Particle Maestro")

Some parts of the extended functionality are provided in hardware by an extended geometry pipeline. Most importantly, PICA200 has three programmable vertex processors. There is furthermore a unit called [[GPU/Primitive_Engine|Primitive Engine]], which is a geometry shader unit (using the same instruction set as vertex shaders) with support for variable-size primitives. The Primitive Engine functionality may be disabled, and the geometry shader unit then acts as a fourth vertex processor. See [[Shader_Instruction_Set]] for more information on the shader instruction set.

[[GPU/Fragment Lighting|Fragment lighting]] is implemented as an optional pipeline step during pixel processing. It's implemented by having the vertex shader output an additional attribute describing the transformation (represented by a quaternion) to surface-local space. This per-vertex quaternion can then be interpolated across screen space to calculate dot products relevant for lighting (e.g. light vector dot normal vector). To provide support for advanced lighting models, these dot products are used as indices into programmable lookup tables. With this setup, PICA200 in particular supports the shading models Blinn-Phong, Cook-Terrance, Ward, and microfacet-based BRDF-models.

PICA200 supports four texture units, the fourth of which is used exclusively for [[GPU/Procedural Texture Generation|procedural texture generation]].

== SDIO controller ==

Nintendo recommends SD cards up to 32 GB however the internal SDIO controller seems to support SD cards up to 2.19 Terabyte (32-bit sector number). It's unknown if it really can handle that much. 128 GB was tested and works fine however it causes a major slowdown of the system especially at boot.

== Images ==

=== Front ===

[[Image:CTR_Front.jpg|600px]]

[http://guide-images.ifixit.net/igi/ishJaSCOwLkvbLYK High Resolution]

=== Back ===

[[Image:CTR_Back.jpg]]

[http://guide-images.ifixit.net/igi/n1CKAdbPrHyNPNuW High Resolution]

=== NAND pinout ===

NAND dumping has been successful, but the image is encrypted.

==== Normal model ====

[[Image:CTR_NAND_pinout.png]]

==== XL model ====

[[Image:CTR_NAND_pinout_XL.jpg|500px]]

==== 2DS ====

[[Image:2DSeMMC.jpg|500px]]

==== New 3DS ====

[[Image:N3DSeMMC.jpg]]

==== New 3DS XL ====

[[Image:N3DSXLeMMC.jpg]]

=== WiFi dongle pinout ===
[[Image:CTR_WiFiDongle_pinout.png|600px]]

SDIO interface is colored red:
* CLK
* CMD
* D0, D1, D2, D3

This is the interface for the 'NEW' WiFi module (based on Atheros AR6002) first included in DSi.

The proprietary DS-mode WiFi is colored yellow, pins are unknown.

I²C eeprom is colored blue:
* SCL
* SDA

SPI Flash is colored purple:
* CLK
* CS#
* SI
* SO
* WP#
* NC

=== Auxiliary Microcontroller (MCU) ===
[[Image:CTR_UC.png|600px]]

Monitors HOME button, WiFi switch, 3D slider, volume control slider.
Controls LEDs, various power supplies via an I²C connection to the PMIC.

Two I²C buses are attached to the MCU. For one, the SoC is the master; for the other, the MCU is the master.

Devices attached to MCU master I²C bus:
* MCU (master)
* Fuel Gauge
* Accelerometer (slave address 0x18)
* PMIC
* maybe more?

Devices attached to the SoC master I²C bus:
* SoC (master)
* MCU
* LCD
* Camera
* QTM (New3DS-only)

The MCU uses the [http://mcs.uwsuper.edu/sb/327/Resources/RL78.pdf RL78 ISA].

The MCU uses some custom Special Function Registers, but documentation for much of the hardware protocol/general SFRs can be found [http://courses.ee.sun.ac.za/Computer_Systems_245/Dokumentasie/RL78%20hardware%20manual%20(registers).pdf here].

News

2017-02-11T04:48:16Z

Smea:

<noinclude>
==Adding an item==
* Log in to the wiki. Editing is disabled if you don't have an account.
* Add the news event to the top of the list, using this format for the date: <tt><nowiki>'''</nowiki>{{#time: d F y}}<nowiki>''' </nowiki></tt>. Please include the application's creator, version number, and a link to a page on 3DBrew about the application. No external links please.
* '''Move the last entry to the [[:News/Archive|news archive]]. There should be no more than 4 entries in the list.'''

==Archives==
For older news, see the [[:News/Archive|news archive]].

=== News ===
</noinclude>
*'''10 February 17''' [[User:smea|smea]] updated [https://smealum.github.io/3ds/ *hax payloads] with 11.3 support.
*'''6 February 17''' Nintendo released system update [[11.3.0-36]].
*'''17 January 2017''' WinterMute released [http://devkitpro.org/viewtopic.php?f=13&t=8643 devkitARM release 46].
*'''9 January 2017''' [[User:Yellows8|Yellows8]] released: new oot3dhax [https://github.com/yellows8/oot3dhax/releases saveimages], ctr-httpwn [https://github.com/yellows8/ctr-httpwn/releases v1.2], menuhax [https://github.com/yellows8/3ds_homemenuhax/releases v3.2], [https://github.com/yellows8/ctpkpwn ctpkpwn_tfh], and others.

News/Archive

2017-02-11T04:48:11Z

Smea:

*'''27 December 2016''' [https://fahrplan.events.ccc.de/congress/2016/Fahrplan/events/8344.html Nintendo Hacking 2016] lecture at Chaos Communication Congress.
*'''26 December 2016''' [[User:Dazzozo|Dazzozo]] released an update to [https://citizens.salthax.org/ humblehax] with [[11.2.0-35]] support.
*'''31 October 2016''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/3ds_dsiwarehax_installer/releases 3ds_dsiwarehax_installer] v1.0. v1.1 was released on November 2nd.
*'''24 October 2016''' Nintendo released system update [[11.2.0-35]].
*'''4 October 2016''' An update for EUR version of VVVVVV was finally released (title was re-added to the eShop versionlist). Likewise for the USA version on the October 11th (this title was already listed in the versionlist however).
*'''22 September 2016''' [[User:shinyquagsire23|Shiny Quagsire]] released an update to [https://smd.salthax.org/ supermysterychunkhax] with [[11.1.0-34]] support.
*'''20 September 16''' [[User:Smea|Smea]] released an update to [http://smealum.github.io/ninjhax2/ Ninjhax 2] with [[11.1.0-34]] support.
*'''16 September 16''' [[User:Plutooo|plutoo]] released an update to [https://plutooo.github.io/freakyhax/ freakyhax] with [[11.1.0-34]] support.
*'''15 September 16''' [[User:Yellows8|Yellows8]] released updated oot3dhax [https://github.com/yellows8/oot3dhax/releases/tag/09-15-16 saveimages] for latest *hax payloads + [[11.1.0-34]] support.
*'''13 September 16''' Nintendo released system update [[11.1.0-34]].
*'''20 August 16''' [[User:Yellows8|Yellows8]] released hblauncher_loader [https://github.com/yellows8/hblauncher_loader/releases/tag/v1.2 v1.2], menuhax [https://github.com/yellows8/3ds_homemenuhax/releases/tag/v3.1 v3.1], and updated the starter-kit. The sploit_installer build from the starter-kit now supports all regions for stickerhax except CHNTWN. This also sends the Home Menu title-version for the initial *hax payload network request, unless the user changed the system-info(like the latest menuhax_manager and hblauncher_loader).
*'''9 August 16''' An updated version of USA SmileBASIC is now available(the updated JPN version was released exactly 2 weeks ago).
*'''29 July 16''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/stickerhax stickerhax], which supports <=[[11.0.0-33]].
*'''27 July 16''' [[User:Yellows8|Yellows8]] released new browserhax(see changelog [[browserhax|here]]) and menuhax [https://github.com/yellows8/3ds_homemenuhax/releases v3.0], all of these now support [[11.0.0-33]].
*'''26 July 16''' Various JPN-only eShop app updates were released. This includes JPN SmileBASIC: the update-title was removed from versionlist, and the main-title was updated. Updating an already installed version of the game will currently update to 3.3.1. Uninstalling and redownloading will give you 3.3.2. [https://plutooo.github.io/smilehax/ smilehax] was fixed in [http://smilebasic.com/debug/ 3.3.2].
*'''22 July 16''' [[User:Dazzozo|Dazzozo]] released [https://citizens.salthax.org/ humblehax v2], supporting the Citizens of Earth update released on the eShop 3 days ago.
*'''20 July 16''' [[User:Plutooo|plutoo]] (with help from [[User:Yellows8|Yellows8]]) released [https://plutooo.github.io/smilehax/ smilehax].
*'''19 July 16''' An updated version of the EUR "Citizens of Earth" regular-title is now available on the EUR-eShop, ~2 months after being originally removed. Likewise for USA on the 21st.
*'''18 July 16''' [[User:Smea|Smea]] updated the hosted *hax payload builds(only otherapp for non-KOR) and this [https://smealum.github.io/3ds/ page]. KOR is now supported thanks to d3m3vilurr(system-version >=v9.6). All otherapp payloads were rebuilt+updated, hence these now include a commit for compression(committed by [[User:Yellows8|Yellows8]] with compression code by mtheall). Due to this, oot3dhax+payload can now be installed with multiple other normal save-files, without any issues(via sploit_installer from the starter-kit). [[User:Yellows8|Yellows8]] also updated the [https://smealum.github.io/3ds/ hosted] boot.3dsx to hbmenu 1.1.1.
*'''10 July 16''' MrNbaYoh released [https://mrnbayoh.github.io/basicsploit/ BASICSploit] for version 3.2.1 of SmileBASIC. Currently only the US version is supported. On July 11th the main-app title was removed from USA/JPN eShop: it's no longer listed on the former, while on the latter it can't be purchased.
*'''26 June 16''' [[User:Yellows8|Yellows8]] released oot3dhax builds for supporting [[11.0.0-33]], via updated sploit_installer in the [https://smealum.github.io/3ds/ starter-kit] and raw [https://github.com/yellows8/oot3dhax/releases/tag/06-26-16 saveimages]. Note that attempting to run sploit_installer on a 11.0.0-33 system with *hax payload <=v2.7 is equivalent to [[11.0.0-33|trying]] to use the older oot3dhax on that version.
*'''3 June 16''' [[User:Plutooo|plutoo]] released [https://plutooo.github.io/freakyhax/ freakyhax]. The USA game was removed from the eShop <=3-hours later("... currently unavailable" message).
*'''9 May 16''' Nintendo released system update [[11.0.0-33]].
*'''24 March 16''' Nintendo updated the pages stored on the server used for browser-version-check. Due to almost all of the Old3DS/New3DS pages for non-latest-browser being updated(content is now "99999"), browser versions prior to [[10.7.0-32]] are not usable anymore without using the browser-version-check bypass(fixed with [[10.7.0-32]]). The only exception is New3DS v10.2, it was "updated" but the content is still "0"(this is due to browser-version-check being [[Internet_Browser|broken]] with New3DS v10.2).
*'''22 March 16''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]. v1.0.1 was released on the 25th for a RootCA cert update.
*'''14 March 16''' Nintendo released system update [[10.7.0-32]].
*'''24-25 February 16''' On the 24th the Old3DS [[Internet_Browser|browser-version-check]] pages were updated so that browser version >=v10.6 is now required. The New3DS pages for this were not changed. About 5 hours later, [[User:Yellows8|Yellows8]] disclosed a bypass for the browser-version-check. User instructions are available [http://yls8.mtheall.com/3dsbrowserhax.php here], details [[3DS_Userland_Flaws|here]].
*'''22 February 16''' Nintendo released system update [[10.6.0-31]].
*'''1 February 16''' As of this date (time zones notwithstanding) following server maintenance Nintendo now checks server-side that users are on current firmware before allowing access to online functionality in games. See [[10.5.0-30|here]] for details.
*'''25 January 16''' Nintendo released system update [[10.5.0-30]].
*'''25 January 16''' [[User:Yellows8|Yellows8]] updated [http://yls8.mtheall.com/3dsbrowserhax.php browserhax], [https://github.com/yellows8/3ds_homemenuhax/releases menuhax], and the oot3dhax [https://github.com/yellows8/oot3dhax/releases saveimages] for v10.4.
*'''18 January 16''' Nintendo released system update [[10.4.0-29]].
*'''7 January 16''' (roughly, not automatically detected) Ironfall v1.0 is no longer downloadable due to the main-CXI content files on CDN being removed (TMD wasn't removed).
*'''27 December 15''' A 3DS console hacking [https://events.ccc.de/congress/2015/Fahrplan/events/7240.html talk] was at 32C3. A recording can be found [https://www.youtube.com/watch?v=UutYOidFx3c here]. Around the end of the talk, [[User:Yellows8|Yellows8]] released [[browserhax]] and [[menuhax]] compatible with the latest system-version at the time of release ([[10.3.0-28]]). The homebrew [https://smealum.github.io/3ds/ starter-kit] was updated for latest menuhax, and for an option for downloading the old vulnerable version of Ironfall from eShop.
*'''15 December 15''' Nintendo released Smash Bros update v1.1.3 which fixed [[smashbroshax]], see [https://github.com/yellows8/3ds_smashbroshax here] for details. However, [[smashbroshax]] is still possible on latest firmware: simply remove the update from SD card before attempting the exploit.
*'''13 December 15''' WinterMute released [http://devkitpro.org/viewtopic.php?f=13&t=8542 devkitARM release 45].
*'''25 November 15''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/hblauncher_loader/releases hblauncher_loader].
*'''17-20 November 15''' Nintendo released an update for the normal (non-invite-code) Super Smash Bros demos in USA, EUR and JPN, fixing [[smashbroshax]]. Only the demos were updated, the cartridge and eShop version of the full game are still vulnerable.
*'''12 November 15''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/oot3dhax/releases oot3dhax] raw savedata images for gamecards with the latest *hax payloads. The official [https://github.com/smealum/sploit_installer installer] is now [https://smealum.github.io/3ds/ included] in the homebrew starter kit.
*'''9 November 15''' Nintendo released system update [[10.3.0-28]].
*'''2 November 15''' Following an eShop servers maintenance, changes to the [[eShop]] system application require an update of the Homebrew starter kit for eShop access on system versions older than [[10.0.0-27]]. See [[EShop|here]] for details.
*'''30 October 15''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/3ds_homemenuhax/releases menuhax] v2.0.
*'''29 October 15''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/3ds_smashbroshax/releases 3ds_smashbroshax] v1.2.
*'''26 October 15''' A [[Internet_Browser#v9.9_dummy_web-browser|dummy web browser]] is now being included in CUPs (cart updates) on Old3DS/New3DS likely starting with games shipping [[9.9.0-26|9.9.0-X]]. NVer is not updated by this.
*'''26 October 15''' The system web-browser on Old3DS/New3DS now displays a "sysupdate required" message on systems with [[9.9.0-26]] or above installed, if the installed browser(?) is not the latest version. See [[Internet_Browser#Forced_system-update|here]] for details.
*'''25 October 15''' [[User:Smea|smea]] released *hax 2.5 payloads, which fixes a number of bugs and adds new features such as screenshot-taking, romhacking and eshop access.
*'''20 October 15''' Nintendo released system update [[10.2.0-28]]. The publicly available versions of [[menuhax]] and [[browserhax]] at the time of sysupdate release, were blocked.
*'''15 October 15''' The [[YouTube]] application was updated with a fix for [[tubehax]]. This update is forced: the app itself checks whether a newer version of the title is available.
*'''13 October 15''' "Ironfall: Invasion" was made available on the eShop again (originally pulled on August 11th). The updated version blocks [[ironhax]].
*'''25 September 15''' [[User:Yellows8|Yellows8]] released [[browserhax]] and [[menuhax]]. On the 26th menuhax v1.2 was [https://github.com/yellows8/3ds_homemenuhax/releases released].
*'''14 September 15''' Nintendo released system update [[10.1.0-27]].
*'''11 September 15'''(11:30 EDT) [[User:Yellows8|Yellows8]] released [[smashbroshax]]. On the 30th v1.1 was [https://github.com/yellows8/3ds_smashbroshax/releases released] for supporting Super Smash Bros v1.1.1.
*'''8 September 15''' Nintendo released system update [[10.0.0-27]].
*'''18 July 15''' smea released [[ninjhax]] 2 beta [http://smealum.github.io/ninjhax2/], enabling ARM11 homebrew execution on Old/New 3DS up to firmware 9.9.0-26.
*'''13 July 15''' Nintendo released system update [[9.9.0-26]].
*'''1 June 15''' Nintendo released system update [[9.8.0-25]].
*'''03 May 15''' smea released regionFOUR [https://github.com/smealum/regionFOUR/blob/master/README.md], enabling region free gaming on latest firmware. (again)
*'''20 April 15''' Nintendo released system update [[9.7.0-25]].
*'''23 March 15''' Nintendo released system update [[9.6.0-24]].
*'''2 March 15''' Nintendo released system update [[9.5.0-23]].
*'''15 February 15''' WinterMute released [http://devkitpro.org/viewtopic.php?f=13&t=8409 devkitARM release 44].
*'''2 February 15''' Nintendo released system update [[9.5.0-22]], which fixes [[3DS System Flaws|firmlaunch-hax]].
*'''16 January 15''' smea released regionthree [https://github.com/smealum/regionthree/blob/master/README.md], enabling region free gaming on latest firmware.
*'''24 December 14''' smea released [[Ninjhax]] 1.1 ('''NOT''' a fix for firmware [[9.3.0-21]] or [[9.4.0-21]]).
*'''11 December 14''' Nintendo released system update [[9.4.0-21]].
*'''8 December 14''' Nintendo released system update [[9.3.0-21]], which fixes [[3DS System Flaws|rohax]].
*'''20 November 14''' smea released [[Ninjhax]], the first public [[Homebrew Exploits|homebrew exploit]] compatible with system-versions [[4.0.0-7]]-[[9.2.0-20]].
*'''29 October 14''' Nintendo released system update [[9.2.0-20]].
*'''10 October 14''' Nintendo released system update [[9.1.0-20J]].
*'''6 October 14''' Nintendo released system update [[9.0.0-20]].
*'''29 August 14''' Nintendo announced [[New 3DS]].
*'''7 August 14''' Nintendo released system update [[8.1.0-19]].
*'''24 July 14''' Nintendo released system update [[8.1.0-18]].
*'''7 July 14''' Nintendo released system update [[8.0.0-18]].
*'''12 May 14''' Nintendo released system update [[7.2.0-17]].
*'''26 February 14''' Nintendo released system update [[7.1.0-16]].
*'''22 January 14''' Nintendo released system update [[7.1.0-15]].
*'''19 December 13''' Nintendo released system update [[7.1.0-14]].
*'''9 December 13''' Nintendo released system update [[7.0.0-13]].
*'''13 September 13''' Nintendo released system update [[6.3.0-12]].
*'''20 August 13''' [[3DSExplorer|3DSExplorer v1.5.3]] updated by [[User:Elisherer|Elisherer]] (Enable trimming NCSD)
*'''6 August 13''' Nintendo released system update [[6.2.0-12]].
*'''11 July 13''' Nintendo released system update [[6.1.0-12U]] for only USA.
*'''27 June 13''' Nintendo released system update [[6.1.0-11]] (6.1.0-12 for all regions except USA).
*'''17 June 13''' Nintendo released system update [[6.0.0-11]] (6.0.0-12 for all regions except USA).
*'''4 April 13''' Nintendo released system update [[5.1.0-11]].
*'''25 March 13''' Nintendo released system update [[5.0.0-11]].
*'''14 January 13''' [[3DSExplorer|3DSExplorer v1.5.1]] updated by [[User:Elisherer|Elisherer]]
*'''4 December 12''' Nintendo released system update [[4.5.0-10]].
*'''1 December 12''' [[3DSExplorer|3DSExplorer v1.4]] updated by [[User:Elisherer|Elisherer]]
*'''2 November 12''' Added page for [[Fundraiser|Chip decapping fundraiser]]
*'''8 January 13''' [[3DSExplorer|3DSExplorer v1.5]] updated by [[User:Elisherer|Elisherer]]
*'''23 September 12''' [[005tools|005tools v0.1b]] by [[User:McHaggis|McHaggis]]
*'''19 September 12''' Nintendo released system update [[4.4.0-10]].
*'''17 August 12''' Nintendo released New Super Mario Bros. 2, the first 3DS title released simultaneously in stores and as an [[eShop]] download.
*'''28 July 12''' [[3DSExplorer|3DSExplorer v1.3]] (modified by 3DSGuy) updated by [[User:Elisherer|Elisherer]]
*'''24 July 12''' Nintendo released system update [[4.3.0-10]].
*'''26 June 12''' Nintendo released system update [[4.2.0-9]].
*'''19 May 12''' [[3DSExplorer|3DSExplorer v1.2.1]] updated by [[User:Elisherer|Elisherer]]
*'''15 May 12''' Nintendo released its first implementation of 3DS '[[Title list#0004000E - Add-on Content|Add-on Content]]' with the Mario Kart 1.1 update.
*'''14 May 12''' Nintendo released system update [[4.1.0-8]].
*'''24 April 12''' Nintendo released system update [[4.0.0-7]].
*'''08 February 12''' [[CiTRUS|CiTRUS v0.2]] updated by [[User:Xcution|Xcution]]
*'''04 February 12''' [[CiTRUS|CiTRUS v0.1]] released by [[User:Xcution|Xcution]]
*'''02 February 12''' [[3DSExplorer|3DSExplorer v1.2]] updated by [[User:Elisherer|elisherer]]
*'''26 January 12''' [[Crappy Tiny Reader|CTR - Crappy Tiny Reader v0.07]] updated by [[User:PsyKopaT|PsyKo]]
*'''05 January 12''' [[Crappy Tiny Reader|CTR - Crappy Tiny Reader v0.06]] updated by [[User:PsyKopaT|PsyKo]]
*'''21 December 11''' Nintendo released system update [[3.0.0-6]]
*'''21 December 11''' [[3DSExplorer|3DSExplorer v1.1.1]] updated by [[User:Elisherer|elisherer]]
*'''7 December 11''' [[3DSExplorer|3DSExplorer v0.96]] updated by [[User:Elisherer|elisherer]]
*'''4 September 11''' [[3DSViewer|3DSViewer v0.1]] released by [[User:Elisherer|elisherer]]
*'''1 August 11''' [[3DS Save DeEncrypter3DS|Save DeEncrypter v1.0]] released by [[User:Blite|Blite]]
*'''25 July 11''' Nintendo released system update [[2.1.0-4]].
*'''15 June 11''' Nintendo released system update [[2.1.0-3]].
*'''6 June 11''' Nintendo released system update [[2.0.0-2]].
*'''6 April 11''' [[DSaveManager|DSaveManager v0.1]] released by [[User:Crediar|crediar]]
*'''4 April 11''' [[3DSaveTool|3DSaveTool v0.2b]] released by [[User:Crediar|crediar]]
*'''2 April 11''' [[3DSaveTool|3DSaveTool v0.1]] released by [[User:Crediar|crediar]]
*'''28 March 11''' Fixed 3DBrew wiki issues, now fully operational!
*'''18 March 11''' 3DBrew launched.

== 3DBrew International ==
Our community is an international community.

We have freedom, and we will express it in our language (but you have to write it in English before ;)!

Homebrew Exploits

2016-10-25T15:15:23Z

Smea:

==Payload==
{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Description
! Supported firmwares
|-
| style="background: lightgreen" | Yes
| [https://smealum.github.io/3ds/ *hax payload]
| Booted by all of the below non-sysmodule exploits.
| From '''9.0.0-7''' up to and including '''11.2.0-35'''.
|}

For the rest of this page, "Supported firmwares" refers to the exploit ''itself'', not whether *hax payload supports it.

==Standalone Homebrew Launcher Exploits==
The following homebrew exploits can be executed on a previously un-exploited system. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ninjhax|Ninjhax 1.1b]]
| From '''4.0.0-7''' up to and including '''9.2.0-20'''.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [http://smealum.net/ninjhax/ Install]
|-
| style="background: lightgreen" | Yes
| [[ninjhax|Ninjhax 2.x]]
| From '''9.0.0-7''' up to and including '''11.2.0-34'''.
| A cartridge or eShop version (JPN-only, not available anymore for purchase) of "Cubic Ninja".
| smea
| [https://smealum.github.io/ninjhax2/ Install]
|-
| style="background: lightgreen" | Yes
| [http://plutooo.github.io/freakyhax/ freakyhax]
| From '''9.0.0-7''' up to and including '''11.1.0-34'''.
| A cartridge or eShop version (USA/EUR/JAP, not available anymore for purchase) of "Freakyform Deluxe".
| plutoo
| [http://plutooo.github.io/freakyhax/ Install]
|-
| style="background: salmon" | No
| [http://plutooo.github.io/smilehax/ smilehax]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (JPN all versions up to 3.32 excluded, USA 3.31 only)
| plutoo
| [http://plutooo.github.io/smilehax/ Install]
|-
| style="background: salmon" | No
| [http://mrnbayoh.github.io/basicsploit/ BASICSploit]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (USA all versions)
| MrNbaYoh
| [http://mrnbayoh.github.io/basicsploit/ Install]
|-
| style="background: lightgreen" | Yes
| [[smashbroshax|smashbroshax]] (beaconhax)
| (New 3DS only) From '''9.0.0-X''' up to and including '''11.1.0-34'''.
| Super Smash Bros 3DS (full-game) and a way to broadcast raw wifi beacons. The demo (prior to the updated November 2015 [https://github.com/yellows8/3ds_smashbroshax version]) isn't usable with the *hax payloads. Game-version v1.1.3 fixed the vuln used with this, see the repo for a workaround for that.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_smashbroshax Install]
|-
| style="background: salmon" | No
| [[browserhax]]
| From '''9.0.0-2''' to '''11.0.0-33'''
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| A USA, EUR, JPN, or KOR system.
| [[User:Yellows8|Yellows8]]
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]
|}

Note that ninjhax 1.x is still not obsolete. Even though ninjhax 2.x can be run on 9.3+, this was made possible (amongst other things) by sacrificing the memory remapping exploit used in ninjhax 1.x (rohax). Therefore, things like JIT engines for emulators can only be supported on ninjhax 1.x. Furthermore, ninjhax 2.x does not run on system versions below 9.0.0-X, while ninjhax 1.x does.

==Secondary Exploits==
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ironhax]]
| From '''9.5.0-X''' up to and including '''10.3.0-X''', for '''X''' up to and including 28.
| A copy of "Ironfall: Invasion" downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.
| smea
| [http://smealum.github.io/3ds/ Install]
|-
| style="background: salmon" | No, exploit update required.
| [http://vegaroxas.github.io/ steelhax]
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A copy of Steel Diver: Sub wars
| Vegaroxas
| [https://github.com/VegaRoXas/vegaroxas.github.io/raw/master/files/steelhax-installer.zip Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/oot3dhax oot3dhax]
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D. Besides using the installer app, writing raw saveimages with a save dongle for example is another option. Before compression was introduced in the 2016-7-18 release, the size of the *hax payload meant the exploit can't coexist with regular saves on a physical version of the game.
| Yellows8 / smea et al.
| See [https://smealum.github.io/3ds/ here].
|-
| style="background: salmon" | No
| [[menuhax]]
| JPN/USA/EUR: From '''9.0.0-X''' up to and including '''11.0.0-X'''.
KOR: From '''9.6.0-X''' up to and including '''11.0.0-X'''.
| JPN/USA/EUR: Having created [[Home_Menu#Home_Menu_Theme_SD_ExtData|theme extdata]] through opening the official theme selector at least once.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]
|-
| style="background: lightgreen" | Yes
| [https://github.com/shinyquagsire23/supermysterychunkhax supermysterychunkhax]
| From '''9.9.0-X''' (USA/JPN) / '''10.2.0-X''' (EUR) up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A gamecard or eShop-install of Pokémon Super Mystery Dungeon.
| Shiny Quagsire / SALT team
| [https://smd.salthax.org/ Install].
|-
| style="background: salmon" | No
| [https://github.com/shinyquagsire23/v_hax (v*)hax]
| From '''9.0.0-X''' up to and including '''11.0.0-X''', for '''X''' up to and including 33.
Note that '''9.0.0-X''' is only required for the Homebrew Launcher - the game itself only requires '''2.1.0-X''' for primitive userland code execution.
| A copy of VVVVVV downloaded after March 2012 (v1). v1.1 patches out the overflow vulnerability used by (v*)hax.
| Shiny Quagsire / SALT team
| [https://vvvvvv.salthax.org/ Install].
|-
| style="background: salmon" | No, exploit update required.
| [https://github.com/Dazzozo/humblehax humblehax]
| From '''9.0.0-X''' (USA/EUR) up to and including '''11.0.0-X''', for '''X''' up to and including 33.
| An eShop-install of Citizens of Earth (either v1 or v2), featured in the Humble "Friends of Nintendo" Bundle.
| Dazzozo / SALT team
| [https://citizens.salthax.org/ Install].
|-
| style="background: lightgreen" | Yes
| [http://mrnbayoh.github.io/basehaxx/ basehaxx]
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A gamecard or eShop-install of Pokémon Omega Ruby / Alpha Sapphire.
| MrNbaYoh
| [http://mrnbayoh.github.io/basehaxx/ install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/stickerhax stickerhax]
| From '''9.0.0-X''' up to and including '''11.2.0-X'''(not including installation).
| A gamecard or eShop-install of Paper Mario: Sticker Star.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/stickerhax Here]
|}

==Exploits without Homebrew Launcher (Not recommended)==

'''Warning:''' The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)
| (Old3DS) From '''5.0.0-2''' to '''11.0.0-33''' (Pre-v5.0 is supported for some versions if you manually modify the source)

(New3DS) From '''9.0.0-20''' to '''11.0.0-33'''

Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| An USA, EUR, or JPN system.
| [[User:Yellows8|Yellows8]]
| [[browserhax|Install]]
|-
| style="background: salmon" | No
| Ninjhax (with specialized payloads)
| Up to '''9.2.0-20'''?
|
| smea + independent developers
| N/A
|}

==Previous Exploits==
'''Warning:''' These exploits '''do not work'''. They are exploits which no longer function at all, regardless of software or firmware revision.
{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[tubehax|Tubehax]]
| None. '''Was''': From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| The YouTube application and an Internet connection. As of October 15, 2015, this is no longer usable due to an update being released which fixes the vuln used by tubehax + app update being forced (see [[YouTube|here]]).
| smea
| [http://smealum.github.io/3ds/ Install]
|}

==Other Homebrew Loaders==
The [https://github.com/yellows8/hblauncher_loader hblauncher_loader] title can be used when running under modded-FIRM which allows running unsigned titles, to boot the *hax payloads.

==Sysmodule Exploits==
This section is for system-module exploits, which can be run from the *hax payloads.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
|-
| style="background: lightgreen" | Yes, that's not the intended default use however.
| [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]
| From '''9.6.0-X''' up to and including '''11.1.0-X'''.
| None
| [[User:Yellows8|Yellows8]]
|}

==WebKit vuln testing==
See [https://github.com/yellows8/3ds_browserhax_common/issues/28 here].

Homebrew Exploits

2016-10-25T15:14:17Z

Smea:

==Payload==
{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Description
! Supported firmwares
|-
| style="background: lightgreen" | Yes
| [https://smealum.github.io/3ds/ *hax payload]
| Booted by all of the below non-sysmodule exploits.
| From '''9.0.0-7''' up to and including '''11.1.0-34'''.
|}

For the rest of this page, "Supported firmwares" refers to the exploit ''itself'', not whether *hax payload supports it.

==Standalone Homebrew Launcher Exploits==
The following homebrew exploits can be executed on a previously un-exploited system. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ninjhax|Ninjhax 1.1b]]
| From '''4.0.0-7''' up to and including '''9.2.0-20'''.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [http://smealum.net/ninjhax/ Install]
|-
| style="background: lightgreen" | Yes
| [[ninjhax|Ninjhax 2.x]]
| From '''9.0.0-7''' up to and including '''11.1.0-34'''.
| A cartridge or eShop version (JPN-only, not available anymore for purchase) of "Cubic Ninja".
| smea
| [https://smealum.github.io/ninjhax2/ Install]
|-
| style="background: lightgreen" | Yes
| [http://plutooo.github.io/freakyhax/ freakyhax]
| From '''9.0.0-7''' up to and including '''11.1.0-34'''.
| A cartridge or eShop version (USA/EUR/JAP, not available anymore for purchase) of "Freakyform Deluxe".
| plutoo
| [http://plutooo.github.io/freakyhax/ Install]
|-
| style="background: salmon" | No
| [http://plutooo.github.io/smilehax/ smilehax]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (JPN all versions up to 3.32 excluded, USA 3.31 only)
| plutoo
| [http://plutooo.github.io/smilehax/ Install]
|-
| style="background: salmon" | No
| [http://mrnbayoh.github.io/basicsploit/ BASICSploit]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (USA all versions)
| MrNbaYoh
| [http://mrnbayoh.github.io/basicsploit/ Install]
|-
| style="background: lightgreen" | Yes
| [[smashbroshax|smashbroshax]] (beaconhax)
| (New 3DS only) From '''9.0.0-X''' up to and including '''11.1.0-34'''.
| Super Smash Bros 3DS (full-game) and a way to broadcast raw wifi beacons. The demo (prior to the updated November 2015 [https://github.com/yellows8/3ds_smashbroshax version]) isn't usable with the *hax payloads. Game-version v1.1.3 fixed the vuln used with this, see the repo for a workaround for that.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_smashbroshax Install]
|-
| style="background: salmon" | No
| [[browserhax]]
| From '''9.0.0-2''' to '''11.0.0-33'''
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| A USA, EUR, JPN, or KOR system.
| [[User:Yellows8|Yellows8]]
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]
|}

Note that ninjhax 1.x is still not obsolete. Even though ninjhax 2.x can be run on 9.3+, this was made possible (amongst other things) by sacrificing the memory remapping exploit used in ninjhax 1.x (rohax). Therefore, things like JIT engines for emulators can only be supported on ninjhax 1.x. Furthermore, ninjhax 2.x does not run on system versions below 9.0.0-X, while ninjhax 1.x does.

==Secondary Exploits==
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ironhax]]
| From '''9.5.0-X''' up to and including '''10.3.0-X''', for '''X''' up to and including 28.
| A copy of "Ironfall: Invasion" downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.
| smea
| [http://smealum.github.io/3ds/ Install]
|-
| style="background: salmon" | No, exploit update required.
| [http://vegaroxas.github.io/ steelhax]
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A copy of Steel Diver: Sub wars
| Vegaroxas
| [https://github.com/VegaRoXas/vegaroxas.github.io/raw/master/files/steelhax-installer.zip Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/oot3dhax oot3dhax]
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D. Besides using the installer app, writing raw saveimages with a save dongle for example is another option. Before compression was introduced in the 2016-7-18 release, the size of the *hax payload meant the exploit can't coexist with regular saves on a physical version of the game.
| Yellows8 / smea et al.
| See [https://smealum.github.io/3ds/ here].
|-
| style="background: salmon" | No
| [[menuhax]]
| JPN/USA/EUR: From '''9.0.0-X''' up to and including '''11.0.0-X'''.
KOR: From '''9.6.0-X''' up to and including '''11.0.0-X'''.
| JPN/USA/EUR: Having created [[Home_Menu#Home_Menu_Theme_SD_ExtData|theme extdata]] through opening the official theme selector at least once.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]
|-
| style="background: lightgreen" | Yes
| [https://github.com/shinyquagsire23/supermysterychunkhax supermysterychunkhax]
| From '''9.9.0-X''' (USA/JPN) / '''10.2.0-X''' (EUR) up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A gamecard or eShop-install of Pokémon Super Mystery Dungeon.
| Shiny Quagsire / SALT team
| [https://smd.salthax.org/ Install].
|-
| style="background: salmon" | No
| [https://github.com/shinyquagsire23/v_hax (v*)hax]
| From '''9.0.0-X''' up to and including '''11.0.0-X''', for '''X''' up to and including 33.
Note that '''9.0.0-X''' is only required for the Homebrew Launcher - the game itself only requires '''2.1.0-X''' for primitive userland code execution.
| A copy of VVVVVV downloaded after March 2012 (v1). v1.1 patches out the overflow vulnerability used by (v*)hax.
| Shiny Quagsire / SALT team
| [https://vvvvvv.salthax.org/ Install].
|-
| style="background: salmon" | No, exploit update required.
| [https://github.com/Dazzozo/humblehax humblehax]
| From '''9.0.0-X''' (USA/EUR) up to and including '''11.0.0-X''', for '''X''' up to and including 33.
| An eShop-install of Citizens of Earth (either v1 or v2), featured in the Humble "Friends of Nintendo" Bundle.
| Dazzozo / SALT team
| [https://citizens.salthax.org/ Install].
|-
| style="background: lightgreen" | Yes
| [http://mrnbayoh.github.io/basehaxx/ basehaxx]
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A gamecard or eShop-install of Pokémon Omega Ruby / Alpha Sapphire.
| MrNbaYoh
| [http://mrnbayoh.github.io/basehaxx/ install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/stickerhax stickerhax]
| From '''9.0.0-X''' up to and including '''11.2.0-X'''(not including installation).
| A gamecard or eShop-install of Paper Mario: Sticker Star.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/stickerhax Here]
|}

==Exploits without Homebrew Launcher (Not recommended)==

'''Warning:''' The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)
| (Old3DS) From '''5.0.0-2''' to '''11.0.0-33''' (Pre-v5.0 is supported for some versions if you manually modify the source)

(New3DS) From '''9.0.0-20''' to '''11.0.0-33'''

Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| An USA, EUR, or JPN system.
| [[User:Yellows8|Yellows8]]
| [[browserhax|Install]]
|-
| style="background: salmon" | No
| Ninjhax (with specialized payloads)
| Up to '''9.2.0-20'''?
|
| smea + independent developers
| N/A
|}

==Previous Exploits==
'''Warning:''' These exploits '''do not work'''. They are exploits which no longer function at all, regardless of software or firmware revision.
{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[tubehax|Tubehax]]
| None. '''Was''': From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| The YouTube application and an Internet connection. As of October 15, 2015, this is no longer usable due to an update being released which fixes the vuln used by tubehax + app update being forced (see [[YouTube|here]]).
| smea
| [http://smealum.github.io/3ds/ Install]
|}

==Other Homebrew Loaders==
The [https://github.com/yellows8/hblauncher_loader hblauncher_loader] title can be used when running under modded-FIRM which allows running unsigned titles, to boot the *hax payloads.

==Sysmodule Exploits==
This section is for system-module exploits, which can be run from the *hax payloads.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
|-
| style="background: lightgreen" | Yes, that's not the intended default use however.
| [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]
| From '''9.6.0-X''' up to and including '''11.1.0-X'''.
| None
| [[User:Yellows8|Yellows8]]
|}

==WebKit vuln testing==
See [https://github.com/yellows8/3ds_browserhax_common/issues/28 here].

3DS System Flaws

2016-05-15T16:14:52Z

Smea: /* Kernel11 */

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=
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.

* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.

==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). An 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 unitialized 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's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).
| 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]]
|-
| 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).

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
|}

== 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
|-
| 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.0.0-33|11.0.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 derrek.
| 32c3 3ds talk (December 27, 2015)
| [[User:Yellows8|Yellows8]]
|-
| Missing verification-block for the 9.6 keys (arm9loaderhax)
| 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
| None
| [[11.0.0-33|11.0.0-X]]
| March, 2015
|
| [[User:Plutooo|plutoo]]
|-
| 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 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]]
|-
| ntrcardhax
|
| ARM9 code execution
| 10.4.0-29
|
| 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]] attempted to fix 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.
| Attempted with [[11.0.0-33|11.0.0-X]], for key system titles.
| NATIVE_FIRM / AM-sysmodule [[11.0.0-33|11.0.0-X]]
| ?
|
| ?
|-
| 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.0.0-33|11.0.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.0.0-33|11.0.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 however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.
| 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.
| Unknown, probably none.
| ?
| April 2013
|
| [[User:Yellows8|Yellows8]]
|-
| [[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]] command 0x003D0108(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#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_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]]), it is possible to boot a New3DS using Old3DS firmware 1.0-2.X and an Old3DS [[NCSD#NCSD_header|NCSD Header]] to retrieve the required OTP data using this flaw.
| Dumping of the [[OTP Registers|OTP]] area
| [[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]] 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.0.0-33|11.0.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
|-
| [[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.0.0-33|11.0.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
| None
| [[10.4.0-29|10.4.0-X]]
|
| derrek, aliaspider
|-
| memchunkhax2
|
| ARM11 kernel code execution
| [[10.4.0-29|10.4.0-X]] (partially)
| [[10.4.0-29|10.4.0-X]]
|
| 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]] (partial)
| [[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]]
|}

=== 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
|-
| [[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
| [[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
| [[9.6.0-24|9.6.0-X]] (Latest sysmodule version as of [[10.7.0-32|10.7.0-32]])
| 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.
|
| None
| [[9.5.0-22]]
| 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 0x2DC00000 on New3DS. This is BASE_memregion_start(aka SYSTEM_memregion_end)-0x400000 with the default memory-layout on Old3DS/New3DS.
| 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
|-
| [[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]]
|}

Talk:Flash Filesystem

2016-04-17T19:07:00Z

Smea: and at spelling apparently

* Can't help with nand reading but lib references give some indication of the filesystem.

'''Note! some of these NAND paths below may be outdated'''. Confirmed NAND directories/directory structures are on the [[Flash Filesystem]] page.

{| class="wikitable" border="1"
|-
|nand:/extdata
|-
|nand:/ro/
|-
|nand:/ro/sys/HWCAL0.dat
|-
|nand:/ro/sys/HWCAL1.dat
|-
|nand:/rw/
|-
|nand:/rw/sys/
|-
|nand:/rw/sys/config
|-
|nand:/rw/sys/updater.log
|-
|nand:/rw/sys/PlayHistory.dat
|-
|nand:/rw/sys/PedometerHistory.dat
|-
|nand:/rw/sys/LocalFriendCodeSeed
|-
|nand:/rw/sys/SecureInfo
|-
|nand:/title
|-
|nand:/title/%08x/%08x
|-
|nand:/title/%08x/%08x/%08x.app
|-
|nand:/title/%08x/%08x/title.tmd
|-
|nand:/ticket
|-
|nand:/ticket/%08x/%08x.tik
|-
|nand:/tmp
|}

@yellows8, since the \titles directory is similar between nand and sdmc, do you think it should have a separate page from the [[SD Filesystem]] page?--[[User:3dsguy|3dsguy]] 02:36, 23 August 2012 (CEST)
:Go ahead.(SD/NAND /title is exactly the same, except for the additional encryption for SD perhaps) NAND has .db files too, but I'm not sure where those are located. --[[User:Yellows8|Yellows8]] 02:59, 23 August 2012 (CEST)

== Possible firmware downgrade vulnerability ==

Please correct where I'm wrong. Assume we have NAND-dumps from two 3DS units A and B for both firmware versions X and Y. I.e. 4 data sets AX, AY, BX, BY. Assume that all clear data is identical for the same firmware version or unique per console and stay untouched with firmware version change (i.e. AX, BX is a brand-new console with a factory reset dumps and AY, BY have just updated firmwares). Then AX xor AY = BX xor BY and BX = BY xor AX xor AY.
:There's no way to convert a NAND image from one 3DS for use on another 3DS, without generating the NAND xorpad(s) for both systems(requires ARM9 code exec on both). Another reason why ARM9 exec is needed here is because there's certain files stored in CTRNAND containing console-unique AESMACs. Since that keyslot is initialized by bootrom those AESMACs can only be calculated on the same 3DS which you're calculating these CTRNAND AESMACs for. --[[User:Yellows8|Yellows8]] 18:02, 10 April 2014 (CEST)
::I'm not about converting a NAND image from system to another directly. Can we alculate for a various firmware byte-to-byte XOR-difference, which result the same xorpads for each system to annihilate. And for the same CTRNAND files untouched with a firmware update this difference will be zero. So applying this difference for another console CTRNAND will update a firmware without the need of the actual console-unique xorpad--[[User:Duke srg|Duke srg]] 21:48, 10 April 2014 (CEST)
:::The CTRNAND files /w console-unique AESMACs I'm referring to get updated when sys-updates get installed, if those don't get updated properly(invalid AESMACs for example) you would have a system which would fail to boot when it tries to launch titles from CTRNAND-FS. There's no way to properly update those files without proper NAND xorpads/etc. --[[User:Yellows8|Yellows8]] 22:11, 10 April 2014 (CEST)
::::Ok, just to clarify, during system update AESMAC init file IS updated with the new console-unique data. So after transferring firmware changes from one system to another without complete decypher, during next boot at least AESMAC file on CTR NAND partition contents will have wrong data and REG_AESMAC being initialized with that will fail the following boot process. Smart enough.--[[User:Duke srg|Duke srg]] 05:59, 11 April 2014 (CEST)
:::::Yeah, at least one of those console-unique AESMACs would be rendered invalid with method you're describing. --[[User:Yellows8|Yellows8]] 06:21, 11 April 2014 (CEST)
::::::Aren't you talking about a movable.sed file or there are others not mentioned explicitly?--[[User:Duke srg|Duke srg]] 14:01, 11 April 2014 (CEST)
:::::::No, I mean this: [[Title_Database]]. --[[User:Yellows8|Yellows8]] 18:23, 11 April 2014 (CEST)

== Note: ==

There is currently a third TWL partition whose location in NAND is currently unknown. Said partition is TWLS, or TWL Sound. By default, this partition is empty, however, if you record a sound with the DSi Sound app, the partition is populated, similar to TWLP. --[[User:MassExplosion213|MassExplosion213]] 23:03, 17 April 2016 (CEST)

Raving Rabbids: Travel in Time 3D

2016-03-07T23:10:33Z

Smea:

[[File:boxart-rabbids3D-300x269.jpg]]
{{Infobox homebrew
| title = Raving Rabbids: Travel in Time 3D
| image =
| type = Game Title
| author = Ubisoft
| website = http://rabbids.us.ubi.com/travel-in-time
| version =
}}
==Note==
FST of this game is stored at 0x004630.
filename is 00.dat.
block_offset is 0x9269000.
file_size is 0x20011.
FST of this game are stored at 0x006630.
filename is00.dat,01.dat,02.dat.
block_offset is same.
file_size is 0x200011+500000*x.

This page was lost for a long time only to be rediscovered on March 7th, 2016.

News

2015-10-26T17:34:09Z

Smea:

<noinclude>
==Adding an item==
* Log in to the wiki. Editing is disabled if you don't have an account.
* Add the news event to the top of the list, using this format for the date: <tt><nowiki>'''</nowiki>{{#time: d F y}}<nowiki>''' </nowiki></tt>. Please include the application's creator, version number, and a link to a page on 3DBrew about the application. No external links please.
* '''Move the last entry to the [[:News/Archive|news archive]]. There should be no more than 4 entrees in the list.'''

==Archives==
For older news, see the [[:News/Archive|news archive]].

=== News ===
</noinclude>
*'''25 October 15''' [[User:Smea|smea]] released *hax 2.5 payloads, which fixes a number of bugs and adds new features such as screenshot-taking, romhacking and eshop access.
*'''20 October 15''' Nintendo released system update [[10.2.0-28]]. The publicly available versions of [[themehax]] and [[browserhax]] at the time of sysupdate release, were blocked.
*'''15 October 15''' The [[YouTube]] application was updated with a fix for [[tubehax]]. This update is forced: the app itself checks whether a newer version of the title is available.
*'''13 October 15''' "Ironfall: Invasion" was made available on the eShop again (originally pulled on August 11th). The updated version blocks [[ironhax]].

PTM Services

2015-10-18T00:06:54Z

Smea:

A total of 24 sessions can be open for each of these services combined. The commands for each service are handled by the PTM module main() thread.

=User PTM Service "ptm:u" / PTM services=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010002
| RegisterAlarmClient
|-
| 0x00020080
| SetRtcAlarm
|-
| 0x00030000
| GetRtcAlarm
|-
| 0x00040000
| CancelRtcAlarm
|-
| 0x00050000
| [[PTM:GetAdapterState|GetAdapterState]]
|-
| 0x00060000
| [[PTM:GetShellState|GetShellState]]
|-
| 0x00070000
| [[PTM:GetBatteryLevel|GetBatteryLevel]]
|-
| 0x00080000
| [[PTM:GetBatteryChargeState|GetBatteryChargeState]]
|-
| 0x00090000
| [[PTM:GetPedometerState|GetPedometerState]]
|-
| 0x000A0042
| GetStepHistoryEntry
|-
| 0x000B00C2
| GetStepHistory
|-
| 0x000C0000
| [[PTM:GetTotalStepCount|GetTotalStepCount]]
|-
| 0x000D0040
| SetPedometerRecordingMode
|-
| 0x000E0000
| GetPedometerRecordingMode
|-
| 0x000F0084
| GetStepHistoryAll
|}

The above commands are available for all PTM services.

=PlayHistory PTM Service "ptm:play" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x08070082
| GetPlayHistory
|-
| 0x08080000
| GetPlayHistoryStart
|-
| 0x08090000
| GetPlayHistoryLength
|-
| 0x080B0080
| CalcPlayHistoryStart
|}

=SystemControl PTM Service "ptm:s"=
Identical to the below "ptm:sysm"

=SysMenu PTM Service "ptm:sysm"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x040100C0
| SetRtcAlarmEx
|-
| 0x04020042
| ReplySleepQuery
|-
| 0x04030042
| NotifySleepPreparationComplete
|-
| 0x04040102
| SetWakeupTrigger
|-
| 0x04050000
| GetAwakeReason
|-
| 0x04060000
| RequestSleep
|-
| 0x040700C0
| [[PTM:ShutdownAsync|ShutdownAsync]]
|-
| 0x04080000
| Awake
|-
| 0x04090080
| [[PTMSYSM:LaunchFIRMRebootSystem|RebootAsync]]
|-
| 0x040A0000
| [[PTMSYSM:CheckNew3DS|CheckNew3DS]] (Added with [[8.0.0-18]])
|-
| 0x08010640
| [[PTMSYSM:SetInfoLEDPattern|SetInfoLEDPattern]] (These 4 LED commands are used for the notification LED, see [[MCU]] regarding boot fail with invalid parameters)
|-
| 0x08020040
| [[PTMSYSM:SetInfoLEDPatternHeader|SetInfoLEDPatternHeader]]
|-
| 0x08030000
| [[PTMSYSM:GetInfoLEDStatus|GetInfoLEDStatus]]
|-
| 0x08040040
| [[PTMSYSM:SetBatteryEmptyLEDPattern|SetBatteryEmptyLEDPattern]]
|-
| 0x08050000
| ClearStepHistory
|-
| 0x080600C2
| SetStepHistory
|-
| 0x08070082
| GetPlayHistory
|-
| 0x08080000
| GetPlayHistoryStart
|-
| 0x08090000
| GetPlayHistoryLength
|-
| 0x080A0000
| ClearPlayHistory
|-
| 0x080B0080
| CalcPlayHistoryStart
|-
| 0x080C0080
| SetUserTime
|-
| 0x080D0000
| InvalidateSystemTime
|-
| 0x080E0140
| [[PTMSYSM:NotifyPlayEvent|NotifyPlayEvent]]
|-
| 0x080F0000
| IsLegacyPowerOff
|-
| 0x08100000
| ClearLegacyPowerOff
|-
| 0x08110000
| GetShellStatus
|-
| 0x08120000
| IsShutdownByBatteryEmpty
|-
| 0x08130000
| FormatSavedata
|-
| 0x08140000
| GetLegacyJumpProhibitedFlag
|-
| 0x0814...
| unknown
|-
| 0x0815...
| unknown
|-
| 0x0816....
| unknown
|-
| 0x0817....
| unknown
|-
| 0x08180040
| [[PTMSYSM:ConfigureNew3DSCPU|ConfigureNew3DSCPU]]
|-
|}

=GetSystemTime PTM Service "ptm:gets"=
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x04010000
| GetSystemTime
|-
|}

=SetSystemTime? PTM Service "ptm:sets"=

=PTM [[System_SaveData]]=
During system boot PTM attempts to open the PTM savedata, if this fails it will repeatedly keep trying to open the archive. When opening the archive is failing due to savedata corruption, PTM eventually(during system boot) deletes the savedata then creates it again.

PTM:ShutdownAsync

2015-10-18T00:06:30Z

Smea: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x040700C0] |- | 1 | 0 ? |- | 2-3 | u64 timeout value in nanoseconds |} =Response..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x040700C0]
|-
| 1
| 0 ?
|-
| 2-3
| u64 timeout value in nanoseconds
|}

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

NSS:ShutdownAsync

2015-10-18T00:04:50Z

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

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

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

=Description=
Performs a call to [[PTM:ShutdownAsync]] with a timeout value of 14 seconds.

NS and APT Services

2015-10-18T00:01:49Z

Smea: /* NS Service "ns:s" */

[[Category:Services]]
The NS ('''N'''intendo User Interface '''S'''hell) system module is the first module launched from a CTR-NAND title after the [[FIRM]] processes are loaded. This module is launched by the pm process, with the titleID loaded from NS state(hard-coded TID initialized during applet TID-array initialization). NS first launches [[ErrDisp]], then the menu. On retail the menu TID is loaded from NS state, while on dev/debug the menu TID is loaded from [[Config_Savegame|config]]. On dev-units if the menu TID block doesn't exist in [[Config_Savegame|config]], NS will attempt to launch the alternate menu instead. The TID of the launched menu is then written to [[Configuration Memory|ACTIVEMENUTID]]. NS uses [[PMApp:LaunchTitle|pm:app]] to launch titles.

NS will not trigger the [[ErrDisp|fatal-error]] screen when launching the regular/alternate menu fails.

Like home menu NS is constantly running while the system is in 3DS-mode. When attempting to return to home-menu when the home-menu process isn't running(like when the process terminated/crashed), NS will trigger a [[ErrDisp|fatal]] error.

= Alternate menu =
When launching the regular menu fails, NS will then attempt to launch the alternate menu. This title could be used as a recovery process, however it's normally not used after the factory.

At the factory for all 3DS systems, [[3DS Development Unit GUI#Test Menu|Test Menu]] is installed with this TID. On retail this title is eventually deleted during [[Factory Setup]].

= Auto-boot =
After [[PMApp:GetFIRMLaunchParams|loading]] [[FIRM]] params and prior to launching [[ErrDisp]]/Home Menu, NS handles auto-booting titles. The same code called by [[APT:Reboot]] is used for launching FIRM here. When the [[Configuration_Memory|UPDATEFLAG]] is set, NS will launch SAFE_MODE_FIRM with the application titleID set to the [[System_Settings#System_Updater|System Updater]] titleID for this region. When the UPDATEFLAG is not set, NS can auto-boot the following titles as well if [[Configuration_Memory|0x1FF80016]] bit0 is set.

When bit1 and bit2 are value zero in [[Configuration_Memory|0x1FF80016]], NS will [[NSS:LaunchFIRM|launch]] the title specified by the [[FIRM]] parameters if the title-info is set. This FIRM launch is done after launching [[ErrDisp]] and Home Menu. Otherwise when [[Configuration_Memory|0x1FF80016]] is value 2 and the output u8 from [[PTM|PTMSYSM]] command 0x08140000 is value 0, NS will boot the title specified from the TWL TLNC block from FIRMparams+0x300. This is the same TLNC block which DSi titles wrote to RAM+0x300 for launching other titles via the launcher title. When handling the TLNC block, NS will boot the 3DS System Settings title when the TLNC titleID is the DSi System Settings titleID(the region field in the TLNC TID is not checked/used). When the TLNC titleID is not System Settings, NS will convert the input DSi titleID-high to the 3DS TWL titleID-high(tidhigh = (TLNCtidhigh & 0x7FFF) | 0x48000), then launch TWL_FIRM to run the title. NS does not support launching from gamecard via TLNC.

= NS Workaround =
A "ns_workaround" was [[5.1.0-11|added]] in NS to workaround the flaw added with [[5.0.0-11]]. When NS is loading before launching any ARM11 processes and certain [[Configuration Memory]] fields are set, NS will launch [[Application_Manager_Services|AM]] then use command [[AM:InstallNATIVEFIRM]]. NS will then execute the code called by [[APT:StartNewestHomeMenu]], the code related to APT:PrepareToStartNewestHomeMenu is not executed here.

NS will only execute this code-path when [[Configuration Memory|0x1FF80016]] is value zero, when KERNEL_VERSIONMAJOR is value 2, and when KERNEL_VERSIONMINOR is less than 35. Therefore, this code-path is only executed when the running NATIVE_FIRM version is prior to [[5.0.0-11]].

= NS Service "ns:s" =
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x000100C0
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:LaunchFIRM|LaunchFIRM]]
|-
| 0x000200C0
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:LaunchTitle|LaunchTitle]]
|-
| 0x0003....
| [[1.0.0-0]] - [[2.0.0-2]]
| Wrapper for [[Process_Manager_Services|PMApp]] command 0x00030080.
|-
| 0x0004....
| [[1.0.0-0]] - [[2.0.0-2]]
| Wrapper for [[Process_Manager_Services|PMApp]] command 0x000500C0.
|-
| 0x000500C0
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:LaunchApplicationFIRM|LaunchApplicationFIRM]]
|-
| 0x00060042
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:SetFIRMParams4A0|SetFIRMParams4A0]]
|-
| 0x00070042
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:CardUpdateInitialize|CardUpdateInitialize]]
|-
| 0x00080000
| [[1.0.0-0]] - [[2.0.0-2]]
| This shuts down the gamecard system update interface: the shared memory is unmapped, the CFA archive is closed, state is cleared, etc.
|-
| 0x0009....
| [[1.0.0-0]] - [[2.0.0-2]]
| Gamecard system update related.
|-
| 0x000A....
| [[1.0.0-0]] - [[2.0.0-2]]
| Gamecard system update related.
|-
| 0x000B....
| [[1.0.0-0]] - [[2.0.0-2]]
| Gamecard system update related.
|-
| 0x000C....
| [[1.0.0-0]] - [[2.0.0-2]]
| Gamecard system update related.
|-
| 0x000D0140
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:SetFIRMParams4B0|SetFIRMParams4B0]]
|-
| 0x000E0000
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:ShutdownAsync|ShutdownAsync]]
|-
| 0x000F0000
| [[1.0.0-0]] - [[2.0.0-2]]
| This calls [[APT:AppletUtility]] with fixed input params.
|-
| 0x00100180
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:RebootSystem|RebootSystem]]
|-
| 0x0011....
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:TerminateProcessTID|TerminateProcessTID]]
|-
| 0x0012....
| ?
| Uses pm:app cmdA&B
|-
| 0x0013....
| ?
| ?
|-
| 0x0014....
| ?
| ?
|-
| 0x00150140
| ?
| [[NSS:LaunchApplication|LaunchApplication]] : unlike LaunchTitle, this will do a "proper" app launch, using the update title if present. It seems to set proper internal states, like [[APT:PrepareToStartApplication]] and [[APT:StartApplication]] would.
|-
| 0x00160000
| [[8.0.0-18]]
| This triggers a hw-reboot.
|}

The maximum sessions that can be used with this service is two, therefore only two processes can use this service at the same time.

=NS Service "ns:p"=
This was added with [[3.0.0-5]]. The PTM sysmodule connects to this service, and syncs whenever [[PTM|ptm:s GetShellState()]] changes.

=NS Service "ns:c"=
This was added with [[5.0.0-11]], it's unknown what this is used for.

=APT Services=
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Accessible with APT:U
! Description
|-
| 0x00010040
|
| Yes
| GetLockHandle
|-
| 0x00020080
|
| See [[APTU:Initialize|here]].
| [[APTU:Initialize|Initialize]]
|-
| 0x00030040
|
| Yes
| Enable
|-
| 0x00040040
|
| Yes
| Finalize
|-
| 0x00050040
|
| Yes
| [[APT:GetAppletManInfo|GetAppletManInfo]]
|-
| 0x00060040
|
| Yes
| [[APT:GetAppletInfo|GetAppletInfo]]
|-
| 0x00070000
|
| Yes
| GetLastSignaledAppletId
|-
| 0x00080000
|
| Yes
| CountRegisteredApplet
|-
| 0x00090040
|
| Yes
| [[APT:IsRegistered|IsRegistered]]
|-
| 0x000A0040
|
| Yes
| GetAttribute
|-
| 0x000B0040
|
| Yes
| [[APTU:GetSignalType|InquireNotification]]
|-
| 0x000C0104
|
| Yes
| [[APT:SendParameter|SendParameter]]
|-
| 0x000D0080
|
| Yes
| [[APT:ReceiveParameter|ReceiveParameter]]
|-
| 0x000E0080
|
| Yes
| [[APT:GlanceParameter|GlanceParameter]]
|-
| 0x000F0100
|
| Yes
| [[APT:CancelParameter|CancelParameter]]
|-
| 0x001000C2
|
| Yes
| DebugFunc
|-
| 0x001100C0
|
| Yes
| [[APT:MapProgramIdForDebug|MapProgramIdForDebug]]
|-
| 0x00120040
|
| Yes
| SetHomeMenuAppletIdForDebug
|-
| 0x00130000
|
| Yes
| GetPreparationState
|-
| 0x00140040
|
| Yes
| SetPreparationState
|-
| 0x00150140
|
| No
| [[APT:PrepareToStartApplication|PrepareToStartApplication]]
|-
| 0x00160040
|
| Yes
| PreloadLibraryApplet
|-
| 0x00170040
|
| Yes
| FinishPreloadingLibraryApplet
|-
| 0x00180040
|
| Yes
| PrepareToStartLibraryApplet
|-
| 0x00190040
|
| Yes
| [[APT:PrepareToStartSystemApplet|PrepareToStartSystemApplet]]
|-
| 0x001A0000
|
| Yes
| PrepareToStartNewestHomeMenu
|-
| 0x001B00C4
|
| Yes
| [[APT:StartApplication|StartApplication]]
|-
| 0x001C0000
|
| Yes
| WakeupApplication
|-
| 0x001D0000
|
| Yes
| CancelApplication
|-
| 0x001E0084
|
| Yes
| StartLibraryApplet
|-
| 0x001F0084
|
| Yes
| [[APT:StartSystemApplet|StartSystemApplet]]
|-
| 0x00200044
|
| Yes
| [[APT:StartNewestHomeMenu|StartNewestHomeMenu]]
|-
| 0x00210000
|
| No
| OrderToCloseApplication
|-
| 0x00220040
|
| Yes
| PrepareToCloseApplication(bool isJumpToHome)
|-
| 0x00230040
|
| Yes
| PrepareToJumpToApplication
|-
| 0x00240044
|
| Yes
| JumpToApplication
|-
| 0x002500C0
|
| Yes
| PrepareToCloseLibraryApplet
|-
| 0x00260000
|
| Yes
| PrepareToCloseSystemApplet
|-
| 0x00270044
|
| Yes
| CloseApplication
|-
| 0x00280044
|
| Yes
| CloseLibraryApplet
|-
| 0x00290044
|
| Yes
| CloseSystemApplet
|-
| 0x002A0000
|
| Yes
| OrderToCloseSystemApplet
|-
| 0x002B0000
|
| Yes
| PrepareToJumpToHomeMenu
|-
| 0x002C0044
|
| Yes
| JumpToHomeMenu
|-
| 0x002D0000
|
| Yes
| PrepareToLeaveHomeMenu
|-
| 0x002E0044
|
| Yes
| LeaveHomeMenu
|-
| 0x002F0040
|
| Yes
| PrepareToLeaveResidentApplet This is stubbed: this just returns 0.
|-
| 0x00300044
|
| Yes
| LeaveResidentApplet This is stubbed: this just returns 0 after verifying the cmd/translate headers.
|-
| 0x00310100
|
| Yes
| [[APT:PrepareToDoApplicationJump|PrepareToDoApplicationJump]]
|-
| 0x00320084
|
| Yes
| [[APT:DoApplicationJump|DoApplicationJump]]
|-
| 0x00330000
|
| Yes
| GetProgramIdOnApplicationJump
|-
| 0x00340084
|
| Yes
| [[APT:SendDeliverArg|SendDeliverArg]]
|-
| 0x00350080
|
| Yes
| ReceiveDeliverArg
|-
| 0x00360040
|
| Yes
| [[APT:LoadSysMenuArg|LoadSysMenuArg]]
|-
| 0x00370042
|
| Yes
| [[APT:StoreSysMenuArg|StoreSysMenuArg]]
|-
| 0x00380040
|
| Yes
| PreloadResidentApplet This is stubbed: this just returns 0.
|-
| 0x00390040
|
| Yes
| PrepareToStartResidentApplet This is stubbed: this just returns 0.
|-
| 0x003A0044
|
| Yes
| StartResidentApplet This is stubbed: this just returns 0 after verifying the cmd/translate headers.
|-
| 0x003B0040
|
| Yes
| CancelLibraryApplet
|-
| 0x003C0042
|
| Yes
| SendDspSleep
|-
| 0x003D0042
|
| Yes
| SendDspWakeUp
|-
| 0x003E0080
|
| Yes
| ReplySleepQuery
|-
| 0x003F0040
|
| Yes
| ReplySleepNotificationComplete
|-
| 0x00400042
|
| Yes
| [[APT:SendCaptureBufferInfo|SendCaptureBufferInfo]]
|-
| 0x00410040
|
| Yes
| [[APT:ReceiveCaptureBufferInfo|ReceiveCaptureBufferInfo]]
|-
| 0x00420080
|
| Yes
| SleepSystem
|-
| 0x00430040
|
| Yes
| NotifyToWait
|-
| 0x00440000
|
| Yes
| GetSharedFont
|-
| 0x00450040
|
| Yes
| GetWirelessRebootInfo
|-
| 0x00460104
|
| Yes
| [[APT:Wrap|Wrap]]
|-
| 0x00470104
|
| Yes
| [[APT:Unwrap|Unwrap]]
|-
| 0x00480100
|
| No
| [[APT:GetProgramInfo|GetProgramInfo]]
|-
| 0x00490180
|
| No
| [[APT:Reboot|Reboot]]
|-
| 0x004A0040
|
| Yes
| [[APT:GetCaptureInfo|GetCaptureInfo]]
|-
| 0x004B00C2
|
| Yes
| [[APT:AppletUtility|AppletUtility]]
|-
| 0x004C0000
|
| Yes
| SetFatalErrDispMode
|-
| 0x004D0080
|
| Yes
| [[APT:GetAppletProgramInfo|GetAppletProgramInfo]]
|-
| 0x004E0000
|
| Yes
| HardwareResetAsync
|-
| 0x004F0080
| [[2.2.0-X]]
| Yes
| [[APT:SetApplicationCpuTimeLimit|SetApplicationCpuTimeLimit]]
|-
| 0x00500040
| [[2.2.0-X]]
| Yes
| [[APT:GetApplicationCpuTimeLimit|GetApplicationCpuTimeLimit]]
|-
| 0x00510080
| [[3.0.0-5]]
| ?
| Uses pm:app cmdB
|-
| 0x00520104
| [[4.0.0-7]]
| ?
| Wrap1
|-
| 0x00530104
| [[4.0.0-7]]
| ?
| Unwrap1
|-
| 0x00540040
| [[5.0.0-11]]
| ?
| ?
|-
| 0x00550040
| [[7.0.0-13]]
| Yes
| This writes the input u8 to a NS state field.
|-
| 0x00560000
| [[7.0.0-13]]
| Yes
| This returns an u8 NS state field(which can be set by cmd 0x00550040), at cmdreply+8.
|-
| 0x00570044
| [[7.0.0-13]]
| ?
| WakeupApplication2?
|-
| 0x00580002
| [[7.0.0-13]]
| Yes
| [[APT:GetProgramID]]
|-
| 0x01010000
| [[8.0.0-18]]
| Yes
| This writes an output u8 to cmdreply indexword[2]. This uses [[PTMSYSM:CheckNew3DS]]. When a certain NS state field is non-zero, the output value is zero, otherwise the output is from [[PTMSYSM:CheckNew3DS]]. Normally this NS state field is zero, however this state field is set to 1 when [[APT:PrepareToStartApplication]] is used with flags bit8 is set.
|-
| 0x01020000
| [[8.0.0-18]]
| Yes
| Wrapper for [[PTMSYSM:CheckNew3DS]].
|-
| 0x01030000
| [[8.0.0-18]]
| Yes
| ?
|-
| 0x01040000
| [[8.0.0-18]]
| ?
| ?
|}

These "APT:U" and "APT:S" NS services can handle launching titles/"applets", these services handle signaling for home/power button as well. Only one session for either APT service can be open at a time, normally processes close the service handle immediately once finished using the service. The commands for APT:U and APT:S are exactly the same, however certain commands are only accessible with APT:S(NS module will call [[SVC|svcBreak]] when the command isn't accessible).

Applets returning to home-menu first use commands APT:PrepareToJumpToHomeMenu and APT:JumpToHomeMenu, followed by these commands to launch home-menu: [[APT:PrepareToStartSystemApplet]] and [[APT:StartSystemApplet]]. [[APT:PrepareToStartSystemApplet]] and [[APT:StartSystemApplet]] are also used for launching the [[Internet Browser]], the camera applet, etc.

Processes launch applications via home-menu, not directly with [[APT:PrepareToStartApplication]] and [[APT:StartApplication]]. Regular applications can't directly launch applications since [[APT:StartApplication]] launches the process without terminating the currently running application.

APT:PrepareToDoApplicationJump and APT:DoApplicationJump are used by applications, for launching native/<non-NATIVE_FIRM> applications. These commands notify Home Menu that title launching needs done, Home Menu does the actual title launching via NS commands.

="APT:A" Service=
This was added with [[7.0.0-13|7.0.0-X]]. Official apps built with the CTRSDK for system-version >=[[7.0.0-13|7.0.0-X]] normally use the "APT:A" service instead of "APT:U". Those processes also have "APT:A" instead of "APT:U" in the service-access-control. It's unknown whether there's anything which is only accessible via "APT:A".

=Applets=
NS module does not verify that the input appID for the APT service cmds are correct for that type of command. For example, a process-launch of a SystemApplet via LibraryApplet commands works fine(minus the launched-process side of APT probably).

==System Applets==
On Old3DS there could only be one applet here(Home Menu, Internet Browser, Friend-List, etc) with programID-high 00040030 running at a time. On Old3DS when directly launching one of these 00040030 applets with Home Menu, the Home Menu process will terminate once the process is launched. On Old3DS when returning to Home Menu from that launched process, the Home Menu process is launched again.

On New3DS the Home Menu process is still running/in-memory, while another system-applet is running. On New3DS it appears that the Home Menu process is terminated+relaunched, when another system-applet terminated without exiting with APT properly.

==Library Applets==
Library applets can be launched by applications and regular applets. These library applets render to the screen(s) when running, etc. For example, this includes swkbd for text input. See the below appIDs in the 0x2XX range, the actual appID used is 0x4XX however.

Input data can be sent to the library applet via the NS [[APT:SendParameter|parameter]] buffer, and/or with shared-memory with a shared-mem handle sent to the library applet. Output data from the library applet can be received by [[APT:ReceiveParameter]], the library applet can also use the specified shared-mem for output too.

=AppIDs=
{| class="wikitable" border="1"
|-
! AppID
! Description
|-
| 0x101
| Home Menu (menu)
|-
| 0x103
| Alternate Menu
|-
| 0x110
| Camera applet (CtrApp)
|-
| 0x112
| Friends List applet (friend)
|-
| 0x113
| Game Notes applet (Cherry)
|-
| 0x114
| [[Internet Browser]] (spider/SKATER)
|-
| 0x115
| Instruction Manual applet
|-
| 0x116
| Notifications applet (newslist)
|-
| 0x117
| Miiverse applet (olv)
|-
| 0x118
| Miiverse posting applet (solv3)
|-
| 0x119
| Amiibo settings (cabinet)
|-
| 0x201
| Software Keyboard (swkbd) (?)
|-
| 0x202
| Mii Selector (appletEd) (?)
|-
| 0x204
| Photo Selector (PNOTE_AP) (?)
|-
| 0x205
| Sound Selector (SNOTE_AP) (?)
|-
| 0x206
| Error Display (error) (?)
|-
| 0x207
| eShop applet (mint) (?)
|-
| 0x208
| Circle Pad Pro Calibrator ([[Extrapad_Applet|extrapad]]) (?)
|-
| 0x209
| Notepad (memolib) (?)
|-
| 0x300
| Application
|-
| 0x301
| eShop (tiger)
|-
| 0x401
| Software Keyboard (swkbd)
|-
| 0x402
| Mii Selector (appletEd)
|-
| 0x404
| Photo Selector (PNOTE_AP)
|-
| 0x405
| Sound Selector (SNOTE_AP)
|-
| 0x406
| Error Display (error)
|-
| 0x407
| eShop applet (mint)
|-
| 0x408
| Circle Pad Pro Calibrator ([[Extrapad_Applet|extrapad]])
|-
| 0x409
| Notepad (memolib)
|-
| 0xF10
| ProgramID: 0004003000008900.
|-
| 0xF11
| ProgramID: 000400000FFFFD00.
|-
| 0xF12
| ProgramID: 000400000FFFFC00.
|-
| 0xF13
| ProgramID: 000400000FFFFB00.
|-
| 0xF14
| ProgramID: 000400000FFFF900.
|-
| 0xF15
| ProgramID: 000400000FFFF800.
|-
| 0xF16
| ProgramID: 000400000FFFF700.
|-
| 0xF17
| ProgramID: 000400000FFFF600.
|-
| 0xF18
| ProgramID: 000400000FFFF500.
|}

These AppIDs are all for NAND titles, except for 0x300. AppIDs in the 0x1XX range are applets(programID-high 00040030), and the AppIDs in the 0x2XX range are "system libraries"(programID-high 00040030). The 0xFXX AppID range is for development NAND applications, these are not available for retail.

Note that at some point the total AppID entry count was changed from 28 to 27.

NSS:LaunchApplication

2015-10-11T04:24:03Z

Smea:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00150140]
|-
| 1-4
| 0x10-byte [[FS:GetProgramLaunchInfo|struct]]
|-
| 5
| Process launch flags
|}

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

=Description=
Unlike LaunchTitle, this will do a "proper" app launch, using the update title if present. It seems to set proper internal states, like [[APT:PrepareToStartApplication]] and [[APT:StartApplication]] would.

NSS:LaunchApplication

2015-10-11T04:18:26Z

Smea: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x00150140] |- | 1-4 | 0x10-byte struct |- | 5 | Proce..."

NS and APT Services

2015-10-11T04:17:35Z

Smea:

[[Category:Services]]
The NS ('''N'''intendo User Interface '''S'''hell) system module is the first module launched from a CTR-NAND title after the [[FIRM]] processes are loaded. This module is launched by the pm process, with the titleID loaded from NS state(hard-coded TID initialized during applet TID-array initialization). NS first launches [[ErrDisp]], then the menu. On retail the menu TID is loaded from NS state, while on dev/debug the menu TID is loaded from [[Config_Savegame|config]]. On dev-units if the menu TID block doesn't exist in [[Config_Savegame|config]], NS will attempt to launch the alternate menu instead. The TID of the launched menu is then written to [[Configuration Memory|ACTIVEMENUTID]]. NS uses [[PMApp:LaunchTitle|pm:app]] to launch titles.

NS will not trigger the [[ErrDisp|fatal-error]] screen when launching the regular/alternate menu fails.

Like home menu NS is constantly running while the system is in 3DS-mode. When attempting to return to home-menu when the home-menu process isn't running(like when the process terminated/crashed), NS will trigger a [[ErrDisp|fatal]] error.

= Alternate menu =
When launching the regular menu fails, NS will then attempt to launch the alternate menu. This title could be used as a recovery process, however it's normally not used after the factory.

At the factory for all 3DS systems, [[3DS Development Unit GUI#Test Menu|Test Menu]] is installed with this TID. On retail this title is eventually deleted during [[Factory Setup]].

= Auto-boot =
After [[PMApp:GetFIRMLaunchParams|loading]] [[FIRM]] params and prior to launching [[ErrDisp]]/Home Menu, NS handles auto-booting titles. The same code called by [[APT:Reboot]] is used for launching FIRM here. When the [[Configuration_Memory|UPDATEFLAG]] is set, NS will launch SAFE_MODE_FIRM with the application titleID set to the [[System_Settings#System_Updater|System Updater]] titleID for this region. When the UPDATEFLAG is not set, NS can auto-boot the following titles as well if [[Configuration_Memory|0x1FF80016]] bit0 is set.

When bit1 and bit2 are value zero in [[Configuration_Memory|0x1FF80016]], NS will [[NSS:LaunchFIRM|launch]] the title specified by the [[FIRM]] parameters if the title-info is set. This FIRM launch is done after launching [[ErrDisp]] and Home Menu. Otherwise when [[Configuration_Memory|0x1FF80016]] is value 2 and the output u8 from [[PTM|PTMSYSM]] command 0x08140000 is value 0, NS will boot the title specified from the TWL TLNC block from FIRMparams+0x300. This is the same TLNC block which DSi titles wrote to RAM+0x300 for launching other titles via the launcher title. When handling the TLNC block, NS will boot the 3DS System Settings title when the TLNC titleID is the DSi System Settings titleID(the region field in the TLNC TID is not checked/used). When the TLNC titleID is not System Settings, NS will convert the input DSi titleID-high to the 3DS TWL titleID-high(tidhigh = (TLNCtidhigh & 0x7FFF) | 0x48000), then launch TWL_FIRM to run the title. NS does not support launching from gamecard via TLNC.

= NS Workaround =
A "ns_workaround" was [[5.1.0-11|added]] in NS to workaround the flaw added with [[5.0.0-11]]. When NS is loading before launching any ARM11 processes and certain [[Configuration Memory]] fields are set, NS will launch [[Application_Manager_Services|AM]] then use command [[AM:InstallNATIVEFIRM]]. NS will then execute the code called by [[APT:StartNewestHomeMenu]], the code related to APT:PrepareToStartNewestHomeMenu is not executed here.

NS will only execute this code-path when [[Configuration Memory|0x1FF80016]] is value zero, when KERNEL_VERSIONMAJOR is value 2, and when KERNEL_VERSIONMINOR is less than 35. Therefore, this code-path is only executed when the running NATIVE_FIRM version is prior to [[5.0.0-11]].

= NS Service "ns:s" =
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x000100C0
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:LaunchFIRM|LaunchFIRM]]
|-
| 0x000200C0
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:LaunchTitle|LaunchTitle]]
|-
| 0x0003....
| [[1.0.0-0]] - [[2.0.0-2]]
| Wrapper for [[Process_Manager_Services|PMApp]] command 0x00030080.
|-
| 0x0004....
| [[1.0.0-0]] - [[2.0.0-2]]
| Wrapper for [[Process_Manager_Services|PMApp]] command 0x000500C0.
|-
| 0x000500C0
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:LaunchApplicationFIRM|LaunchApplicationFIRM]]
|-
| 0x00060042
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:SetFIRMParams4A0|SetFIRMParams4A0]]
|-
| 0x00070042
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:CardUpdateInitialize|CardUpdateInitialize]]
|-
| 0x00080000
| [[1.0.0-0]] - [[2.0.0-2]]
| This shuts down the gamecard system update interface: the shared memory is unmapped, the CFA archive is closed, state is cleared, etc.
|-
| 0x0009....
| [[1.0.0-0]] - [[2.0.0-2]]
| Gamecard system update related.
|-
| 0x000A....
| [[1.0.0-0]] - [[2.0.0-2]]
| Gamecard system update related.
|-
| 0x000B....
| [[1.0.0-0]] - [[2.0.0-2]]
| Gamecard system update related.
|-
| 0x000C....
| [[1.0.0-0]] - [[2.0.0-2]]
| Gamecard system update related.
|-
| 0x000D0140
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:SetFIRMParams4B0|SetFIRMParams4B0]]
|-
| 0x000E....
| [[1.0.0-0]] - [[2.0.0-2]]
| Wrapper for "ptm:sysm" service command 0x040700C0.
|-
| 0x000F0000
| [[1.0.0-0]] - [[2.0.0-2]]
| This calls [[APT:AppletUtility]] with fixed input params.
|-
| 0x00100180
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:RebootSystem|RebootSystem]]
|-
| 0x0011....
| [[1.0.0-0]] - [[2.0.0-2]]
| [[NSS:TerminateProcessTID|TerminateProcessTID]]
|-
| 0x0012....
| ?
| Uses pm:app cmdA&B
|-
| 0x0013....
| ?
| ?
|-
| 0x0014....
| ?
| ?
|-
| 0x00150140
| ?
| [[NSS:LaunchApplication|LaunchApplication]] : unlike LaunchTitle, this will do a "proper" app launch, using the update title if present. It seems to set proper internal states, like [[APT:PrepareToStartApplication]] and [[APT:StartApplication]] would.
|-
| 0x00160000
| [[8.0.0-18]]
| This triggers a hw-reboot.
|}

The maximum sessions that can be used with this service is two, therefore only two processes can use this service at the same time.

=NS Service "ns:p"=
This was added with [[3.0.0-5]]. The PTM sysmodule connects to this service, and syncs whenever [[PTM|ptm:s GetShellState()]] changes.

=NS Service "ns:c"=
This was added with [[5.0.0-11]], it's unknown what this is used for.

=APT Services=
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Accessible with APT:U
! Description
|-
| 0x00010040
|
| Yes
| GetLockHandle
|-
| 0x00020080
|
| See [[APTU:Initialize|here]].
| [[APTU:Initialize|Initialize]]
|-
| 0x00030040
|
| Yes
| Enable
|-
| 0x00040040
|
| Yes
| Finalize
|-
| 0x00050040
|
| Yes
| [[APT:GetAppletManInfo|GetAppletManInfo]]
|-
| 0x00060040
|
| Yes
| [[APT:GetAppletInfo|GetAppletInfo]]
|-
| 0x00070000
|
| Yes
| GetLastSignaledAppletId
|-
| 0x00080000
|
| Yes
| CountRegisteredApplet
|-
| 0x00090040
|
| Yes
| [[APT:IsRegistered|IsRegistered]]
|-
| 0x000A0040
|
| Yes
| GetAttribute
|-
| 0x000B0040
|
| Yes
| [[APTU:GetSignalType|InquireNotification]]
|-
| 0x000C0104
|
| Yes
| [[APT:SendParameter|SendParameter]]
|-
| 0x000D0080
|
| Yes
| [[APT:ReceiveParameter|ReceiveParameter]]
|-
| 0x000E0080
|
| Yes
| [[APT:GlanceParameter|GlanceParameter]]
|-
| 0x000F0100
|
| Yes
| [[APT:CancelParameter|CancelParameter]]
|-
| 0x001000C2
|
| Yes
| DebugFunc
|-
| 0x001100C0
|
| Yes
| [[APT:MapProgramIdForDebug|MapProgramIdForDebug]]
|-
| 0x00120040
|
| Yes
| SetHomeMenuAppletIdForDebug
|-
| 0x00130000
|
| Yes
| GetPreparationState
|-
| 0x00140040
|
| Yes
| SetPreparationState
|-
| 0x00150140
|
| No
| [[APT:PrepareToStartApplication|PrepareToStartApplication]]
|-
| 0x00160040
|
| Yes
| PreloadLibraryApplet
|-
| 0x00170040
|
| Yes
| FinishPreloadingLibraryApplet
|-
| 0x00180040
|
| Yes
| PrepareToStartLibraryApplet
|-
| 0x00190040
|
| Yes
| [[APT:PrepareToStartSystemApplet|PrepareToStartSystemApplet]]
|-
| 0x001A0000
|
| Yes
| PrepareToStartNewestHomeMenu
|-
| 0x001B00C4
|
| Yes
| [[APT:StartApplication|StartApplication]]
|-
| 0x001C0000
|
| Yes
| WakeupApplication
|-
| 0x001D0000
|
| Yes
| CancelApplication
|-
| 0x001E0084
|
| Yes
| StartLibraryApplet
|-
| 0x001F0084
|
| Yes
| [[APT:StartSystemApplet|StartSystemApplet]]
|-
| 0x00200044
|
| Yes
| [[APT:StartNewestHomeMenu|StartNewestHomeMenu]]
|-
| 0x00210000
|
| No
| OrderToCloseApplication
|-
| 0x00220040
|
| Yes
| PrepareToCloseApplication(bool isJumpToHome)
|-
| 0x00230040
|
| Yes
| PrepareToJumpToApplication
|-
| 0x00240044
|
| Yes
| JumpToApplication
|-
| 0x002500C0
|
| Yes
| PrepareToCloseLibraryApplet
|-
| 0x00260000
|
| Yes
| PrepareToCloseSystemApplet
|-
| 0x00270044
|
| Yes
| CloseApplication
|-
| 0x00280044
|
| Yes
| CloseLibraryApplet
|-
| 0x00290044
|
| Yes
| CloseSystemApplet
|-
| 0x002A0000
|
| Yes
| OrderToCloseSystemApplet
|-
| 0x002B0000
|
| Yes
| PrepareToJumpToHomeMenu
|-
| 0x002C0044
|
| Yes
| JumpToHomeMenu
|-
| 0x002D0000
|
| Yes
| PrepareToLeaveHomeMenu
|-
| 0x002E0044
|
| Yes
| LeaveHomeMenu
|-
| 0x002F0040
|
| Yes
| PrepareToLeaveResidentApplet This is stubbed: this just returns 0.
|-
| 0x00300044
|
| Yes
| LeaveResidentApplet This is stubbed: this just returns 0 after verifying the cmd/translate headers.
|-
| 0x00310100
|
| Yes
| [[APT:PrepareToDoApplicationJump|PrepareToDoApplicationJump]]
|-
| 0x00320084
|
| Yes
| [[APT:DoApplicationJump|DoApplicationJump]]
|-
| 0x00330000
|
| Yes
| GetProgramIdOnApplicationJump
|-
| 0x00340084
|
| Yes
| [[APT:SendDeliverArg|SendDeliverArg]]
|-
| 0x00350080
|
| Yes
| ReceiveDeliverArg
|-
| 0x00360040
|
| Yes
| [[APT:LoadSysMenuArg|LoadSysMenuArg]]
|-
| 0x00370042
|
| Yes
| [[APT:StoreSysMenuArg|StoreSysMenuArg]]
|-
| 0x00380040
|
| Yes
| PreloadResidentApplet This is stubbed: this just returns 0.
|-
| 0x00390040
|
| Yes
| PrepareToStartResidentApplet This is stubbed: this just returns 0.
|-
| 0x003A0044
|
| Yes
| StartResidentApplet This is stubbed: this just returns 0 after verifying the cmd/translate headers.
|-
| 0x003B0040
|
| Yes
| CancelLibraryApplet
|-
| 0x003C0042
|
| Yes
| SendDspSleep
|-
| 0x003D0042
|
| Yes
| SendDspWakeUp
|-
| 0x003E0080
|
| Yes
| ReplySleepQuery
|-
| 0x003F0040
|
| Yes
| ReplySleepNotificationComplete
|-
| 0x00400042
|
| Yes
| [[APT:SendCaptureBufferInfo|SendCaptureBufferInfo]]
|-
| 0x00410040
|
| Yes
| [[APT:ReceiveCaptureBufferInfo|ReceiveCaptureBufferInfo]]
|-
| 0x00420080
|
| Yes
| SleepSystem
|-
| 0x00430040
|
| Yes
| NotifyToWait
|-
| 0x00440000
|
| Yes
| GetSharedFont
|-
| 0x00450040
|
| Yes
| GetWirelessRebootInfo
|-
| 0x00460104
|
| Yes
| [[APT:Wrap|Wrap]]
|-
| 0x00470104
|
| Yes
| [[APT:Unwrap|Unwrap]]
|-
| 0x00480100
|
| No
| [[APT:GetProgramInfo|GetProgramInfo]]
|-
| 0x00490180
|
| No
| [[APT:Reboot|Reboot]]
|-
| 0x004A0040
|
| Yes
| [[APT:GetCaptureInfo|GetCaptureInfo]]
|-
| 0x004B00C2
|
| Yes
| [[APT:AppletUtility|AppletUtility]]
|-
| 0x004C0000
|
| Yes
| SetFatalErrDispMode
|-
| 0x004D0080
|
| Yes
| [[APT:GetAppletProgramInfo|GetAppletProgramInfo]]
|-
| 0x004E0000
|
| Yes
| HardwareResetAsync
|-
| 0x004F0080
| [[2.2.0-X]]
| Yes
| [[APT:SetApplicationCpuTimeLimit|SetApplicationCpuTimeLimit]]
|-
| 0x00500040
| [[2.2.0-X]]
| Yes
| [[APT:GetApplicationCpuTimeLimit|GetApplicationCpuTimeLimit]]
|-
| 0x00510080
| [[3.0.0-5]]
| ?
| Uses pm:app cmdB
|-
| 0x00520104
| [[4.0.0-7]]
| ?
| Wrap1
|-
| 0x00530104
| [[4.0.0-7]]
| ?
| Unwrap1
|-
| 0x00540040
| [[5.0.0-11]]
| ?
| ?
|-
| 0x00550040
| [[7.0.0-13]]
| Yes
| This writes the input u8 to a NS state field.
|-
| 0x00560000
| [[7.0.0-13]]
| Yes
| This returns an u8 NS state field(which can be set by cmd 0x00550040), at cmdreply+8.
|-
| 0x00570044
| [[7.0.0-13]]
| ?
| WakeupApplication2?
|-
| 0x00580002
| [[7.0.0-13]]
| Yes
| [[APT:GetProgramID]]
|-
| 0x01010000
| [[8.0.0-18]]
| Yes
| This writes an output u8 to cmdreply indexword[2]. This uses [[PTMSYSM:CheckNew3DS]]. When a certain NS state field is non-zero, the output value is zero, otherwise the output is from [[PTMSYSM:CheckNew3DS]]. Normally this NS state field is zero, however this state field is set to 1 when [[APT:PrepareToStartApplication]] is used with flags bit8 is set.
|-
| 0x01020000
| [[8.0.0-18]]
| Yes
| Wrapper for [[PTMSYSM:CheckNew3DS]].
|-
| 0x01030000
| [[8.0.0-18]]
| Yes
| ?
|-
| 0x01040000
| [[8.0.0-18]]
| ?
| ?
|}

These "APT:U" and "APT:S" NS services can handle launching titles/"applets", these services handle signaling for home/power button as well. Only one session for either APT service can be open at a time, normally processes close the service handle immediately once finished using the service. The commands for APT:U and APT:S are exactly the same, however certain commands are only accessible with APT:S(NS module will call [[SVC|svcBreak]] when the command isn't accessible).

Applets returning to home-menu first use commands APT:PrepareToJumpToHomeMenu and APT:JumpToHomeMenu, followed by these commands to launch home-menu: [[APT:PrepareToStartSystemApplet]] and [[APT:StartSystemApplet]]. [[APT:PrepareToStartSystemApplet]] and [[APT:StartSystemApplet]] are also used for launching the [[Internet Browser]], the camera applet, etc.

Processes launch applications via home-menu, not directly with [[APT:PrepareToStartApplication]] and [[APT:StartApplication]]. Regular applications can't directly launch applications since [[APT:StartApplication]] launches the process without terminating the currently running application.

APT:PrepareToDoApplicationJump and APT:DoApplicationJump are used by applications, for launching native/<non-NATIVE_FIRM> applications. These commands notify Home Menu that title launching needs done, Home Menu does the actual title launching via NS commands.

="APT:A" Service=
This was added with [[7.0.0-13|7.0.0-X]]. Official apps built with the CTRSDK for system-version >=[[7.0.0-13|7.0.0-X]] normally use the "APT:A" service instead of "APT:U". Those processes also have "APT:A" instead of "APT:U" in the service-access-control. It's unknown whether there's anything which is only accessible via "APT:A".

=Applets=
NS module does not verify that the input appID for the APT service cmds are correct for that type of command. For example, a process-launch of a SystemApplet via LibraryApplet commands works fine(minus the launched-process side of APT probably).

==System Applets==
On Old3DS there could only be one applet here(Home Menu, Internet Browser, Friend-List, etc) with programID-high 00040030 running at a time. On Old3DS when directly launching one of these 00040030 applets with Home Menu, the Home Menu process will terminate once the process is launched. On Old3DS when returning to Home Menu from that launched process, the Home Menu process is launched again.

On New3DS the Home Menu process is still running/in-memory, while another system-applet is running. On New3DS it appears that the Home Menu process is terminated+relaunched, when another system-applet terminated without exiting with APT properly.

==Library Applets==
Library applets can be launched by applications and regular applets. These library applets render to the screen(s) when running, etc. For example, this includes swkbd for text input. See the below appIDs in the 0x2XX range, the actual appID used is 0x4XX however.

Input data can be sent to the library applet via the NS [[APT:SendParameter|parameter]] buffer, and/or with shared-memory with a shared-mem handle sent to the library applet. Output data from the library applet can be received by [[APT:ReceiveParameter]], the library applet can also use the specified shared-mem for output too.

=AppIDs=
{| class="wikitable" border="1"
|-
! AppID
! Description
|-
| 0x101
| Home Menu (menu)
|-
| 0x103
| Alternate Menu
|-
| 0x110
| Camera applet (CtrApp)
|-
| 0x112
| Friends List applet (friend)
|-
| 0x113
| Game Notes applet (Cherry)
|-
| 0x114
| [[Internet Browser]] (spider/SKATER)
|-
| 0x115
| Instruction Manual applet
|-
| 0x116
| Notifications applet (newslist)
|-
| 0x117
| Miiverse applet (olv)
|-
| 0x118
| Miiverse posting applet (solv3)
|-
| 0x119
| Amiibo settings (cabinet)
|-
| 0x201
| Software Keyboard (swkbd) (?)
|-
| 0x202
| Mii Selector (appletEd) (?)
|-
| 0x204
| Photo Selector (PNOTE_AP) (?)
|-
| 0x205
| Sound Selector (SNOTE_AP) (?)
|-
| 0x206
| Error Display (error) (?)
|-
| 0x207
| eShop applet (mint) (?)
|-
| 0x208
| Circle Pad Pro Calibrator ([[Extrapad_Applet|extrapad]]) (?)
|-
| 0x209
| Notepad (memolib) (?)
|-
| 0x300
| Application
|-
| 0x301
| eShop (tiger)
|-
| 0x401
| Software Keyboard (swkbd)
|-
| 0x402
| Mii Selector (appletEd)
|-
| 0x404
| Photo Selector (PNOTE_AP)
|-
| 0x405
| Sound Selector (SNOTE_AP)
|-
| 0x406
| Error Display (error)
|-
| 0x407
| eShop applet (mint)
|-
| 0x408
| Circle Pad Pro Calibrator ([[Extrapad_Applet|extrapad]])
|-
| 0x409
| Notepad (memolib)
|-
| 0xF10
| ProgramID: 0004003000008900.
|-
| 0xF11
| ProgramID: 000400000FFFFD00.
|-
| 0xF12
| ProgramID: 000400000FFFFC00.
|-
| 0xF13
| ProgramID: 000400000FFFFB00.
|-
| 0xF14
| ProgramID: 000400000FFFF900.
|-
| 0xF15
| ProgramID: 000400000FFFF800.
|-
| 0xF16
| ProgramID: 000400000FFFF700.
|-
| 0xF17
| ProgramID: 000400000FFFF600.
|-
| 0xF18
| ProgramID: 000400000FFFF500.
|}

These AppIDs are all for NAND titles, except for 0x300. AppIDs in the 0x1XX range are applets(programID-high 00040030), and the AppIDs in the 0x2XX range are "system libraries"(programID-high 00040030). The 0xFXX AppID range is for development NAND applications, these are not available for retail.

Note that at some point the total AppID entry count was changed from 28 to 27.

PMApp:SetAppResourceLimit

2015-10-11T04:14:28Z

Smea: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x000a0140] |- | 1 | ? (usually 0) |- | 2 | Resource limit type. |- | 3 | Resource..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x000a0140]
|-
| 1
| ? (usually 0)
|-
| 2
| Resource limit type.
|-
| 3
| Resource limit value.
|-
| 4
| ? (usually 0)
|-
| 5
| ? (usually 0)
|}

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

=Description=

Interface for [[SVC|svcSetResourceLimitLimitValues]]. Sets a single resource limit at a time. Resource limit types are in the 0-9 range and can be found at [[KResourceLimit]] : 0 is "Max Priority" and 9 is "Max CPU time".

PMApp:LaunchTitleUpdate

2015-10-11T04:10:54Z

Smea: Created page with "=Request= {| class="wikitable" border="1" |- ! Index Word ! Description |- | 0 | Header code [0x000D0240] |- | 1-4 | 0x10-byte struct for main title..."

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x000D0240]
|-
| 1-4
| 0x10-byte [[FS:GetProgramLaunchInfo|struct]] for main title
|-
| 5-8
| 0x10-byte [[FS:GetProgramLaunchInfo|struct]] for update title
|-
| 9
| Process launch flags
|}

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

Process Manager Services

2015-10-11T04:09:07Z

Smea:

= Process Manager app service "pm:app" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010140
| [[PMApp:LaunchTitle|LaunchTitle]]
|-
| 0x00020082
| [[PMApp:LaunchFIRMSetParams|LaunchFIRMSetParams]]
|-
| 0x00030080
| Terminates processes. The input u64 @ cmdbuf+4 is timeout in nanoseconds.
|-
| 0x00040100
| [[PMApp:TerminateProcessTID|TerminateProcessTID]]
|-
| 0x000500C0
| Mostly the same as TerminateProcessTID, except this uses an unknown process field instead of the TID.
|-
| 0x00060082
| (u64 val, 0x0, processid) Probably used to send the termination signal to the specified process?
|-
| 0x00070042
| [[PMApp:GetFIRMLaunchParams|GetFIRMLaunchParams]]
|-
| 0x00080100
| [[PMApp:GetTitleExheaderFlags|GetTitleExheaderFlags]]
|-
| 0x00090042
| [[PMApp:SetFIRMLaunchParams|SetFIRMLaunchParams]]
|-
| 0x000A0140
| [[PMApp:SetResourceLimit|SetResourceLimit]]
|-
| 0x000B0140
| Interface for [[SVC|svcGetResourceLimitLimitValues]].
|-
| 0x000C0080
| (u64 programID) Process shutdown related?
|-
| 0x000D0240
| [[PMApp:LaunchTitleUpdate|LaunchTitleUpdate]]
|}

= Process Manager debug service "pm:dbg" =
{| class="wikitable" border="1"
|-
! Command Header
! Available since system version
! Description
|-
| 0x0001....
|
| [[PMDbg:LaunchTitleDebug|LaunchTitleDebug]]
|-
| 0x0002....
|
| [[PMDbg:LaunchTitle|LaunchTitle]]
|-
| 0x00030000
| ?
| ?
|}

A maximum of three sessions can be open with both of these services combined, therefore only three processes can use either of these services at once.

GSPGPU:TryAcquireRight

2015-10-10T19:16:15Z

Smea:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x00150002]
|-
| 1
| Value 0x0
|-
| 2
| Process handle
|}

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

=Description=

This is a non-blocking version of [[GSPGPU:AcquireRight|AcquireRight]]. It returns error 0xc8402bf0 if the rights couldn't be acquired.

KHeapChunkHeader

2015-09-26T15:34:35Z

Smea: come back when you're ready to grow up

FirmwareNews

2015-09-16T18:00:47Z

Smea:

Original [[ninjhax]]: From '''4.0.0-X''' up to and including '''9.2.0-X''', when '''X''' is between 7 and 20.

[[ninjhax|ninjhax2]], [[tubehax]]: From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including '''27'''.

[[ironhax]]: From '''9.5.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including '''27'''.

[[smashbroshax]] with hb-launcher payload ([[smashbroshax|New3DS only]]): From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including '''27'''.

For more detailed info, see the [[Homebrew_Exploits|Homebrew Exploits]] page.

----

Full system control exploits are only public for system versions up to and including '''9.2.0'''.

Homebrew Applications

2015-08-19T01:19:19Z

Smea:

==Installing==
Applications are installed by copying the necessary files to the 3ds/ folder in the root of the SD-card. Most applications come with two files:
* boot.3dsx: The executable.
* icon.bin: The icon/metadata.

The [[Homebrew Launcher]] will scan the sdcard for all .3dsx files, but will only display an icon for those who have one according to the format described above.

==List==

===Launcher===
{| class="wikitable" border="1" width="100%"
! width="20%" | Name
! width="50%" | Description
! width="10%" | Author
! width="10%" | Download
! width="10%" | Open-Source
|-
| [https://github.com/smealum/3ds_hb_menu Ninjhax homebrew launcher]
| Ninjhax homebrew launcher can be started by exploiting a bug in the '''Cubic Ninja''' 3DS game. Works on 3DS devices between version 4.4.0 and 9.2.0.
| [https://twitter.com/smealum smea] et al.
| [http://smealum.net/ninjhax/dl/hbmenu/boot.3dsx Here]
| Yes
|-
| [http://smealum.github.io/ninjhax2/ Ninjhax homebrew launcher (v2.1)]
| Ninjhax homebrew launcher can be started by exploiting a bug in the '''Cubic Ninja''' 3DS game. Works on all 3DS devices between version 9.0.0 and 9.9.0
| [https://twitter.com/smealum smea] et al.
| [http://smealum.github.io/ninjhax2/boot.3dsx Here]
| No
|-
| [http://smealum.github.io/3ds/ Tubehax homebrew launcher]
| Tubehax homebrew launcher can be started by exploiting a bug in the '''Youtube''' 3DS app. Works on all 3DS devices between version 9.0.0 and 9.9.0.
| [https://twitter.com/smealum smea] et al.
| [https://smealum.github.io/ninjhax2/boot.3dsx Here]
| No
|-
| [http://smealum.github.io/3ds/ IRONhax homebrew launcher]
| IRONhax homebrew launcher can be started by exploiting a bug in the '''IronFall''' 3DS game. Works on all 3DS devices between version 9.0.0 and 9.9.0. '''IMPORTANT: Another exploit is required to run this installer. You need to be able to run the homebrew to install the exploit on your device.'''
| [https://twitter.com/smealum smea] et al.
| [http://smealum.github.io/ninjhax2/installer.zip Here]
| No
|}

===Applications===
{| class="wikitable" border="1"
! width="20%" | Name
! width="50%" | Description
! width="10%" | Author
! width="10%" | Download
! width="10%" | Open-Source
|-
| [https://github.com/yellows8/3ds_homemenu_extdatatool 3DS HomeMenu extdata Tool]
| Tool for accessing the SD extdata which Home Menu uses. This essentially allows writing custom themes to extdata which get loaded at Home Menu startup.
| [[User:yellows8|yellows8]]
| [https://github.com/yellows8/3ds_homemenu_extdatatool/releases]
| Yes
|-
| [https://github.com/markwinap/3DS_Nyan_Cat 3DS Nyan Cat]
| 3DS Nyan Cat using LIBSF2D.
| [[User:markwinap|markwinap]]
| [https://www.dropbox.com/s/e400my3xm0zw74r/nyan_cat.zip?dl=0 Here]
| Yes
|-
| [https://github.com/plutooo/ctrrpc ctrrpc]
| A small and easily extensible RPC server/client written in C/Python. Allows you to quickly poke service-commands and syscalls over wifi from a Python shell on your PC. Useful during reverse-engineering.
| [[User:plutooo|plutoo]]
| N/A
| Yes
|-
| [https://github.com/yellows8/ctr-streaming-server ctr-streaming-server]
| This is a server which runs on a 3DS, which receives audio/video for playback. This can also send [[HID_Shared_Memory|HID]] state to the client (see the README) when enabled. The included parse_hidstream tool can be used to parse that HID data to simulate keyboard/mouse input events, via Linux uinput.
| [[User:yellows8|yellows8]]
| N/A
| Yes
|-
| [https://github.com/DownloadMii/DownloadMii DownloadMii]
| This is a WIP homebrew online store.
| [[User:filfat|filfat]]
| [https://www.downloadmii.com/download/#release Latest]
| Yes
|-
| [https://github.com/linoma/fb43ds fb43ds]
| This is a simple Facebook's chat client
| [[User:linoma|linoma]]
| [https://github.com/linoma/fb43ds Here]
| Yes
|-
| [https://github.com/Steveice10/FBI FBI]
| Open source CIA (un)installer.
| [[User:Steveice10|Steveice10]]
| [https://www.dropbox.com/s/866yhujdg859mor/FBI.zip?dl=0 Here]
| Yes
|-
| [https://github.com/iamevn/for-anyone-who-walks-a-lot for-anyone-who-walks-a-lot]
| Tool to get past the 10 coin per day limit on earning Play Coins by walking.
| [[User:iamevn|iamevn]]
| [https://github.com/iamevn/for-anyone-who-walks-a-lot/releases Here]
| Yes
|-
| [https://github.com/mtheall/ftbrony ftBRONY]
| An FTP server.
| [[User:mtheall|mtheall]]
| N/A
| Yes
|-
| [https://github.com/iamevn/FTP-3DS FTP-3DS]
| Fork of ftBRONY with a Nintendo theme.
| [[User:iamevn|iamevn]]
| [https://github.com/iamevn/FTP-3DS/releases Here]
| Yes
|-
| [https://github.com/smealum/ftPONY ftPONY]
| A basic FTP server, useful for testing new homebrew versions without swapping the SD card.
| [[User:smea|smea]]
| [https://mega.co.nz/#!nchBkL7B!T3vXnX4q8Uwp6APYYTDSZi2bkm25la-Qyz6j4CjsllI Here]
| Yes
|-
| [https://github.com/zeta0134/3ds-homebrew-browser Homebrew Browser]
| Download homebrew from the internet!
| [[User:cromo|cromo]] [[User:zeta0134|zeta0134]]
| [https://github.com/zeta0134/3ds-homebrew-browser/releases/tag/v0.1 Here]
| Yes
|-
| vid3o
| A real video player for 3ds with support for many codecs.
| [[User:ILOVEPIE|ILOVEPIE]]
| N/A
| Maybe
|}

===Games===
{| class="wikitable" border="1"
! width="20%" | Name
! width="50%" | Description
! width="10%" | Author
! width="10%" | Download
! width="10%" | Open-Source
|-
| [http://gbatemp.net/threads/release-100-boxes-2ds.384714/ 100 Boxes 2DS]
| Simple puzzle game.
| [[User:Cid2mizard|Cid2mizard]]
| [http://3ds.nintendomax.com/Homebrews/Jeux/100Boxes2DS/100_Boxes_2DS.rar Here]
| Yes
|-
| [https://github.com/MrJPGames/2048-3D 2048-3D]
| "2048 was a big hit not so long ago, and I still see many people at my school playing it. So I thought it would be pretty cool to be able to play 2048 on the go on the 3DS."
| [[User:MrJPGames|Jasper Peters]]
| [https://github.com/MrJPGames/2048-3D/blob/master/2048-3D.3dsx?raw=true Here]
| Yes
|-
| [https://github.com/smealum/3dscraft 3DSCraft]
| Minecraft clone.
| [https://twitter.com/smealum smea]
| [http://smealum.github.io/3dscraft/downloads/3dscraft_141120.zip Here]
| Yes
|-
| [http://gbatemp.net/threads/release-hamsters-2ds.383457/ Hamsters 2DS]
| A hamster breeding game in text mode.
| [[User:Cid2mizard|Cid2mizard]]
| [http://3ds.nintendomax.com/Homebrews/Jeux/Hamsters2DS/Hamsters_2DS.rar Here]
| No
|-
| [https://gbatemp.net/threads/release-mastermind-3ds.394710/#post-5611660 Mastermind 3DS]
| Mastermind on 3DS
| [[User:MrJPGames|Jasper Peters]]
| [https://github.com/MrJPGames/Mastermind-3DS/blob/master/Mastermind.zip?raw=true Here]
| Yes
|-
| [http://gbatemp.net/threads/release-minesweeper-2ds.384185/ Minesweeper 2DS]
| Minesweeper clone.
| [[User:Cid2mizard|Cid2mizard]]
| [http://3ds.nintendomax.com/Homebrews/Jeux/Minesweeper2DS/Minesweeper_2DS.rar Here]
| Yes
|-
| [http://gbatemp.net/threads/release-paddle-puffle-3ds.392215/ Paddle Puffle 3DS]
| A port of [http://puffles.gatuno.mx Paddle Puffle] for the 3DS.
| Peanut42
| [http://puffles.gatuno.mx/releases/paddlepuffle3ds.zip Here]
| [https://github.com/gatuno/PaddlePuffle3DS Yes]
|-
| [https://github.com/smealum/portal3DS Portal3DS]
| An adaptation of [https://en.wikipedia.org/wiki/Portal_(video_game) Portal] for the 3DS.
| [https://twitter.com/smealum smea]
| N/A
| [https://github.com/smealum/portal3DS Yes]
|-
| [http://gbatemp.net/threads/release-tilemap-2ds.386733/ TileMap 2DS]
| Puzzle game.
| [[User:Cid2mizard|Cid2mizard]]
| [http://3ds.nintendomax.com/Homebrews/Jeux/TileMap2DS/TileMap_2DS.rar Here]
| Yes
|-
| [http://gbatemp.net/threads/release-tiles-2ds.385796/ Tiles 2DS]
| Puzzle game, Lights Out Like.
| [[User:Cid2mizard|Cid2mizard]]
| [http://3ds.nintendomax.com/Homebrews/Jeux/Tiles2DS/Tiles_2DS.rar Here]
| Yes
|-
| [https://github.com/Steveice10/WorldOf3DSand World of 3DSand]
| World of Sand clone.
| [[User:Steveice10|Steveice10]]
| [https://www.dropbox.com/s/91tqtydxpny9p1g/WorldOf3DSand.zip?dl=0 Here]
| Yes
|-
| [https://github.com/smealum/yeti3DS Yeti3DS]
| A quick and dirty port of Derek Evans' Yeti3D software rendering engine.
| [https://twitter.com/smealum smea]
| N/A
| Yes
|}

===Emulators===
{| class="wikitable" border="1"
! width="20%" | Name
! width="50%" | Description
! width="10%" | Author
! width="10%" | Download
! width="10%" | Open-Source
|-
| [https://github.com/st4rk/3DNES 3DNES]
| An NES emulator.
| St4rk
| [http://filetrip.net/3ds-downloads/homebrew/dl-3dnes-1-2-f32931.html Here]
| Yes
|-
| [https://github.com/Steveice10/3DSGBA 3DSGBA]
| A GBA emulator.
| Steveice10
| [https://www.dropbox.com/s/fraixj1fn9ql3w4/3DSGBA.zip?dl=0 Here]
| Yes
|-
| [https://github.com/StapleButter/blargSnes blargSnes]
| A Super Nintendo emulator.
| StapleButter
| [http://blargsnes.kuribo64.net/download/blargSnes_1.2.zip Here]
| Yes
|-
| [https://github.com/xerpi/CHIP-3DS CHIP-3DS]
| A simple and slow CHIP-8 emulator.
| xerpi
| [https://www.mediafire.com/?y94yjhzf70fsfsi Here]
| Yes
|-
| [https://github.com/shinyquagsire23/gpsp CitrAGB]
| Yet another GBA emulator.
| shinyquagsire23
| [https://www.dropbox.com/s/sxb7x34u58g4zo2/3ds.3dsx?dl=0 Here]
| Yes
|-
| [https://github.com/Drenn1/GameYob/tree/master/platform/3ds GameYob]
| A Game Boy (Color) emulator.
| Drenn
| [https://gbatemp.net/threads/gameyob-3ds-gb-c-emu.372523/ Here]
| Yes
|}
===Demos===
{| class="wikitable" border="1"
! width="20%" | Name
! width="50%" | Description
! width="10%" | Author
! width="10%" | Download
! width="10%" | Open-Source
|-
| cubedemo
| A short demo of Homebrew on 3ds with working sound.
| [[User:plutoo|plutoo]]
| [https://mega.co.nz/#!KUQFiQYA!pv8HDEyrmuX6Eyw2hW0opL7gf9Ztmjd9J5pPsvs_rD4 Here]
| No
|}

Homebrew Applications

2015-08-16T19:23:57Z

Smea: Undo revision 13060 by Jabo (talk) (reason : no)

==Installing==
Applications are installed by copying the necessary files to the 3ds/ folder in the root of the SD-card. Most applications come with two files:
* boot.3dsx: The executable.
* icon.bin: The icon/metadata.

The [[Homebrew Launcher]] will scan the sdcard for all .3dsx files, but will only display an icon for those who have one according to the format described above.

==List==

===Launcher===
{| class="wikitable" border="1" width="100%"
! width="20%" | Name
! width="50%" | Description
! width="10%" | Author
! width="10%" | Download
! width="10%" | Open-Source
|-
| [https://github.com/smealum/3ds_hb_menu The Homebrew Launcher]
| The ninjhax homebrew launcher.
| [[User:smea|smea]] et al.
| [http://smealum.net/ninjhax/dl/hbmenu/boot.3dsx Here]
| Yes
|}
===Applications===
{| class="wikitable" border="1"
! width="20%" | Name
! width="50%" | Description
! width="10%" | Author
! width="10%" | Download
! width="10%" | Open-Source
|-
| [https://github.com/yellows8/3ds_homemenu_extdatatool 3DS HomeMenu extdata Tool]
| Tool for accessing the SD extdata which Home Menu uses. This essentially allows writing custom themes to extdata which get loaded at Home Menu startup.
| [[User:yellows8|yellows8]]
| [https://github.com/yellows8/3ds_homemenu_extdatatool/releases]
| Yes
|-
| [https://github.com/markwinap/3DS_Nyan_Cat 3DS Nyan Cat]
| 3DS Nyan Cat using LIBSF2D.
| [[User:markwinap|markwinap]]
| [https://www.dropbox.com/s/e400my3xm0zw74r/nyan_cat.zip?dl=0 Here]
| Yes
|-
| [https://github.com/plutooo/ctrrpc ctrrpc]
| A small and easily extensible RPC server/client written in C/Python. Allows you to quickly poke service-commands and syscalls over wifi from a Python shell on your PC. Useful during reverse-engineering.
| [[User:plutooo|plutoo]]
| N/A
| Yes
|-
| [https://github.com/yellows8/ctr-streaming-server ctr-streaming-server]
| This is a server which runs on a 3DS, which receives audio/video for playback. This can also send [[HID_Shared_Memory|HID]] state to the client (see the README) when enabled. The included parse_hidstream tool can be used to parse that HID data to simulate keyboard/mouse input events, via Linux uinput.
| [[User:yellows8|yellows8]]
| N/A
| Yes
|-
| [https://github.com/DownloadMii/DownloadMii DownloadMii]
| This is a WIP homebrew online store.
| [[User:filfat|filfat]]
| [https://www.downloadmii.com/download/#release Latest]
| Yes
|-
| [https://github.com/linoma/fb43ds fb43ds]
| This is a simple Facebook's chat client
| [[User:linoma|linoma]]
| [https://github.com/linoma/fb43ds Here]
| Yes
|-
| [https://github.com/Steveice10/FBI FBI]
| Open source CIA (un)installer.
| [[User:Steveice10|Steveice10]]
| [https://www.dropbox.com/s/866yhujdg859mor/FBI.zip?dl=0 Here]
| Yes
|-
| [https://github.com/iamevn/for-anyone-who-walks-a-lot for-anyone-who-walks-a-lot]
| Tool to get past the 10 coin per day limit on earning Play Coins by walking.
| [[User:iamevn|iamevn]]
| [https://github.com/iamevn/for-anyone-who-walks-a-lot/releases Here]
| Yes
|-
| [https://github.com/mtheall/ftbrony ftBRONY]
| An FTP server.
| [[User:mtheall|mtheall]]
| N/A
| Yes
|-
| [https://github.com/smealum/ftPONY ftPONY]
| A basic FTP server, useful for testing new homebrew versions without swapping the SD card.
| [[User:smea|smea]]
| [https://mega.co.nz/#!nchBkL7B!T3vXnX4q8Uwp6APYYTDSZi2bkm25la-Qyz6j4CjsllI Here]
| Yes
|-
| [https://github.com/zeta0134/3ds-homebrew-browser Homebrew Browser]
| Download homebrew from the internet!
| [[User:cromo|cromo]] [[User:zeta0134|zeta0134]]
| [https://github.com/zeta0134/3ds-homebrew-browser/releases/tag/v0.1 Here]
| Yes
|-
| vid3o
| A real video player for 3ds with support for many codecs.
| [[User:ILOVEPIE|ILOVEPIE]]
| N/A
| Maybe
|}

===Games===
{| class="wikitable" border="1"
! width="20%" | Name
! width="50%" | Description
! width="10%" | Author
! width="10%" | Download
! width="10%" | Open-Source
|-
| [http://gbatemp.net/threads/release-100-boxes-2ds.384714/ 100 Boxes 2DS]
| Simple puzzle game.
| [[User:Cid2mizard|Cid2mizard]]
| [http://3ds.nintendomax.com/Homebrews/Jeux/100Boxes2DS/100_Boxes_2DS.rar Here]
| Yes
|-
| [https://github.com/MrJPGames/2048-3D 2048-3D]
| "2048 was a big hit not so long ago, and I still see many people at my school playing it. So I thought it would be pretty cool to be able to play 2048 on the go on the 3DS."
| [[User:MrJPGames|Jasper Peters]]
| [https://github.com/MrJPGames/2048-3D/blob/master/2048-3D.3dsx?raw=true Here]
| Yes
|-
| [https://github.com/smealum/3dscraft 3DSCraft]
| Minecraft clone.
| [[User:smea|smea]]
| [http://smealum.github.io/3dscraft/downloads/3dscraft_141120.zip Here]
| Yes
|-
| [http://gbatemp.net/threads/release-hamsters-2ds.383457/ Hamsters 2DS]
| A hamster breeding game in text mode.
| [[User:Cid2mizard|Cid2mizard]]
| [http://3ds.nintendomax.com/Homebrews/Jeux/Hamsters2DS/Hamsters_2DS.rar Here]
| No
|-
| [https://gbatemp.net/threads/release-mastermind-3ds.394710/#post-5611660 Mastermind 3DS]
| Mastermind on 3DS
| [[User:MrJPGames|Jasper Peters]]
| [https://github.com/MrJPGames/Mastermind-3DS/blob/master/Mastermind.zip?raw=true Here]
| Yes
|-
| [http://gbatemp.net/threads/release-minesweeper-2ds.384185/ Minesweeper 2DS]
| Minesweeper clone.
| [[User:Cid2mizard|Cid2mizard]]
| [http://3ds.nintendomax.com/Homebrews/Jeux/Minesweeper2DS/Minesweeper_2DS.rar Here]
| Yes
|-
| [http://gbatemp.net/threads/release-paddle-puffle-3ds.392215/ Paddle Puffle 3DS]
| A port of [http://puffles.gatuno.mx Paddle Puffle] for the 3DS.
| Peanut42
| [http://puffles.gatuno.mx/releases/paddlepuffle3ds.zip Here]
| [https://github.com/gatuno/PaddlePuffle3DS Yes]
|-
| [http://gbatemp.net/threads/release-tilemap-2ds.386733/ TileMap 2DS]
| Puzzle game.
| [[User:Cid2mizard|Cid2mizard]]
| [http://3ds.nintendomax.com/Homebrews/Jeux/TileMap2DS/TileMap_2DS.rar Here]
| Yes
|-
| [http://gbatemp.net/threads/release-tiles-2ds.385796/ Tiles 2DS]
| Puzzle game, Lights Out Like.
| [[User:Cid2mizard|Cid2mizard]]
| [http://3ds.nintendomax.com/Homebrews/Jeux/Tiles2DS/Tiles_2DS.rar Here]
| Yes
|-
| [https://github.com/Steveice10/WorldOf3DSand World of 3DSand]
| World of Sand clone.
| [[User:Steveice10|Steveice10]]
| [https://www.dropbox.com/s/91tqtydxpny9p1g/WorldOf3DSand.zip?dl=0 Here]
| Yes
|-
| [https://github.com/smealum/yeti3DS Yeti3DS]
| A quick and dirty port of Derek Evans' Yeti3D software rendering engine.
| [[User:smea|smea]]
| N/A
| Yes
|}

===Emulators===
{| class="wikitable" border="1"
! width="20%" | Name
! width="50%" | Description
! width="10%" | Author
! width="10%" | Download
! width="10%" | Open-Source
|-
| [https://github.com/st4rk/3DNES 3DNES]
| An NES emulator.
| St4rk
| [http://filetrip.net/3ds-downloads/homebrew/dl-3dnes-1-2-f32931.html Here]
| Yes
|-
| [https://github.com/Steveice10/3DSGBA 3DSGBA]
| A GBA emulator.
| Steveice10
| [https://www.dropbox.com/s/fraixj1fn9ql3w4/3DSGBA.zip?dl=0 Here]
| Yes
|-
| [https://github.com/StapleButter/blargSnes blargSnes]
| A Super Nintendo emulator.
| StapleButter
| [http://blargsnes.kuribo64.net/download/blargSnes_1.2.zip Here]
| Yes
|-
| [https://github.com/xerpi/CHIP-3DS CHIP-3DS]
| A simple and slow CHIP-8 emulator.
| xerpi
| [https://www.mediafire.com/?y94yjhzf70fsfsi Here]
| Yes
|-
| [https://github.com/shinyquagsire23/gpsp CitrAGB]
| Yet another GBA emulator.
| shinyquagsire23
| [https://www.dropbox.com/s/sxb7x34u58g4zo2/3ds.3dsx?dl=0 Here]
| Yes
|-
| [https://github.com/Drenn1/GameYob/tree/master/platform/3ds GameYob]
| A Game Boy (Color) emulator.
| Drenn
| [https://dl.dropboxusercontent.com/u/100702766/gameyob/gameyob_3ds.zip Here]
| Yes
|}
===Demos===
{| class="wikitable" border="1"
! width="20%" | Name
! width="50%" | Description
! width="10%" | Author
! width="10%" | Download
! width="10%" | Open-Source
|-
| cubedemo
| A short demo of Homebrew on 3ds with working sound.
| [[User:plutoo|plutoo]]
| [https://mega.co.nz/#!KUQFiQYA!pv8HDEyrmuX6Eyw2hW0opL7gf9Ztmjd9J5pPsvs_rD4 Here]
| No
|}

HTTP Services

2015-08-02T21:58:00Z

Smea:

[[Category:Services]]
= HTTP service "http:C" =
{| class="wikitable" border="1"
|-
! Command Header
! Description
|-
| 0x00010044
| [[HTTPC:Initialize|Initialize]]
|-
| 0x00020082
| [[HTTPC:CreateContext|CreateContext]]
|-
| 0x00030040
| [[HTTPC:CloseContext|CloseContext]]
|-
| 0x00040040
| CancelConnection (Context)
|-
| 0x00050040
| [[HTTPC:GetRequestState|GetRequestState]]
|-
| 0x00060040
| [[HTTPC:GetDownloadSizeState|GetDownloadSizeState]]
|-
| 0x00070040
| GetRequestError
|-
| 0x00080042
| [[HTTPC:InitializeConnectionSession|InitializeConnectionSession]]
|-
| 0x00090040
| [[HTTPC:BeginRequest|BeginRequest]]
|-
| 0x000A0040
| BeginRequestAsync
|-
| 0x000B0082
| [[HTTPC:ReceiveData|ReceiveData]]
|-
| 0x000C0102
| [[HTTPC:ReceiveDataTimeout|ReceiveDataTimeout]]
|-
| 0x000D0146
| SetProxy
|-
| 0x000E0040
| [[HTTPC:SetProxyDefault|SetProxyDefault]]
|-
| 0x000F00C4
| SetBasicAuthorization (char *user, u32 user_size, char *pass, u32 pass_size)
|-
| 0x00100080
| SetSocketBufferSize
|-
| 0x001100C4
| [[HTTPC:AddRequestHeader|AddRequestHeader]]
|-
| 0x001200C4
| [[HTTPC:AddPostDataAscii|AddPostDataAscii]]
|-
| 0x001300C4
| AddPostDataBinary
|-
| 0x00140082
| AddPostDataRaw
|-
| 0x00150080
| SetPostDataType(u8 enum)
|-
| 0x001600C4
| SendPostDataAscii
|-
| 0x00170144
| SendPostDataAsciiTimeout
|-
| 0x001800C4
| SendPostDataBinary
|-
| 0x00190144
| SendPostDataBinaryTimeout
|-
| 0x001A0082
| SendPostDataRaw
|-
| 0x001B0102
| [[HTTPC:SendPOSTDataTimeout|SendPOSTDataRawTimeout]]
|-
| 0x001C0080
| SetPostDataEncoding
|-
| 0x001D0040
| NotifyFinishSendPostData
|-
| 0x001E00C4
| [[HTTPC:GetResponseHeader|GetResponseHeader]]
|-
| 0x001F0144
| [[HTTPC:GetResponseHeaderTimeout|GetResponseHeaderTimeout]]
|-
| 0x00200082
| [[HTTPC:GetResponseData|GetResponseData]]
|-
| 0x00210102
| GetResponseDataTimeout
|-
| 0x00220040
| [[HTTPC:GetResponseStatusCode|GetResponseStatusCode]]
|-
| 0x002300C0
| [[HTTPC:GetResponseStatusCodeTimeout|GetResponseStatusCodeTimeout]]
|-
| 0x00240082
| [[HTTPC:AddTrustedRootCA|AddTrustedRootCA]]
|-
| 0x00250080
|
|-
| 0x00260080
|
|-
| 0x002700C4
|
|-
| 0x00280080
|
|-
| 0x00290080
|
|-
| 0x002A0040
|
|-
| 0x002B0080
|
|-
| 0x002C0080
|
|-
| 0x002D0000
|
|-
| 0x002E0040
|
|-
| 0x002F0082
|
|-
| 0x00300080
|
|-
| 0x00310080
|
|-
| 0x00320084
|
|-
| 0x00330040
|
|-
| 0x00340040
|
|-
| 0x00350186
| SetDefaultProxy
|-
| 0x00360000
| ClearDNSCache
|-
| 0x00370080
| SetKeepAlive (bool)
|-
| 0x003800C0
| SetPostDataTypeSize (u8 enum, u32 size) (similar to SetPostDataType)
|-
| 0x00390000
| Finalize
|-
| 0x003A....
|
|-
| 0x003B0082
|
|-
| 0x003C....
|
|-
| 0x003D....
|
|-
| 0x003E....
|
|-
| 0x003F....
|
|-
| 0x00400082
|
|-
| 0x0041....
|
|-
| 0x0042....
|
|}

= Error codes =

0xd8a0a066 indicates that the context handle is wrong.

HTTPC:ReceiveData

2015-08-02T21:55:33Z

Smea:

=Request=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code [0x000B0082]
|-
| 1
| HTTP context handle
|-
| 2
| Buffer size
|-
| 3
| (OutSize<<4) <nowiki>|</nowiki> 12
|-
| 4
| Output data pointer
|}

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

=Description=
This is the same as [[HTTPC:ReceiveDataDelay]], without the delay. This returns error 0xd8a0a066 if the context handle is wrong.

News/Archive

2015-05-04T18:44:48Z

Smea:

*'''15 February 15''' WinterMute released [http://devkitpro.org/viewtopic.php?f=13&t=8409 devkitARM release 44].
*'''2 February 15''' Nintendo released system update [[9.5.0-22]], which fixes [[3DS System Flaws|firmlaunch-hax]].
*'''16 January 15''' smea released regionthree [https://github.com/smealum/regionthree/blob/master/README.md], enabling region free gaming on latest firmware.
*'''24 December 14''' smea released [[Ninjhax]] 1.1 ('''NOT''' a fix for firmware [[9.3.0-21]] or [[9.4.0-21]]).
*'''11 December 14''' Nintendo released system update [[9.4.0-21]].
*'''8 December 14''' Nintendo released system update [[9.3.0-21]], which fixes [[3DS System Flaws|rohax]].
*'''20 November 14''' smea released [[Ninjhax]], the first public [[Homebrew Exploits|homebrew exploit]] compatible with system-versions [[4.0.0-7]]-[[9.2.0-20]].
*'''29 October 14''' Nintendo released system update [[9.2.0-20]].
*'''10 October 14''' Nintendo released system update [[9.1.0-20J]].
*'''6 October 14''' Nintendo released system update [[9.0.0-20]].
*'''29 August 14''' Nintendo announced [[New 3DS]].
*'''7 August 14''' Nintendo released system update [[8.1.0-19]].
*'''24 July 14''' Nintendo released system update [[8.1.0-18]].
*'''7 July 14''' Nintendo released system update [[8.0.0-18]].
*'''12 May 14''' Nintendo released system update [[7.2.0-17]].
*'''26 February 14''' Nintendo released system update [[7.1.0-16]].
*'''22 January 14''' Nintendo released system update [[7.1.0-15]].
*'''19 December 13''' Nintendo released system update [[7.1.0-14]].
*'''9 December 13''' Nintendo released system update [[7.0.0-13]].
*'''13 September 13''' Nintendo released system update [[6.3.0-12]].
*'''20 August 13''' [[3DSExplorer|3DSExplorer v1.5.3]] updated by [[User:Elisherer|Elisherer]] (Enable trimming NCSD)
*'''6 August 13''' Nintendo released system update [[6.2.0-12]].
*'''11 July 13''' Nintendo released system update [[6.1.0-12U]] for only USA.
*'''27 June 13''' Nintendo released system update [[6.1.0-11]] (6.1.0-12 for all regions except USA).
*'''17 June 13''' Nintendo released system update [[6.0.0-11]] (6.0.0-12 for all regions except USA).
*'''4 April 13''' Nintendo released system update [[5.1.0-11]].
*'''25 March 13''' Nintendo released system update [[5.0.0-11]].
*'''14 January 13''' [[3DSExplorer|3DSExplorer v1.5.1]] updated by [[User:Elisherer|Elisherer]]
*'''4 December 12''' Nintendo released system update [[4.5.0-10]].
*'''1 December 12''' [[3DSExplorer|3DSExplorer v1.4]] updated by [[User:Elisherer|Elisherer]]
*'''2 November 12''' Added page for [[Fundraiser|Chip decapping fundraiser]]
*'''8 January 13''' [[3DSExplorer|3DSExplorer v1.5]] updated by [[User:Elisherer|Elisherer]]
*'''23 September 12''' [[005tools|005tools v0.1b]] by [[User:McHaggis|McHaggis]]
*'''19 September 12''' Nintendo released system update [[4.4.0-10]].
*'''17 August 12''' Nintendo released New Super Mario Bros. 2, the first 3DS title released simultaneously in stores and as an [[eShop]] download.
*'''28 July 12''' [[3DSExplorer|3DSExplorer v1.3]] (modified by 3DSGuy) updated by [[User:Elisherer|Elisherer]]
*'''24 July 12''' Nintendo released system update [[4.3.0-10]].
*'''26 June 12''' Nintendo released system update [[4.2.0-9]].
*'''19 May 12''' [[3DSExplorer|3DSExplorer v1.2.1]] updated by [[User:Elisherer|Elisherer]]
*'''15 May 12''' Nintendo released its first implementation of 3DS '[[Title list#0004000E - Add-on Content|Add-on Content]]' with the Mario Kart 1.1 update.
*'''14 May 12''' Nintendo released system update [[4.1.0-8]].
*'''24 April 12''' Nintendo released system update [[4.0.0-7]].
*'''08 February 12''' [[CiTRUS|CiTRUS v0.2]] updated by [[User:Xcution|Xcution]]
*'''04 February 12''' [[CiTRUS|CiTRUS v0.1]] released by [[User:Xcution|Xcution]]
*'''02 February 12''' [[3DSExplorer|3DSExplorer v1.2]] updated by [[User:Elisherer|elisherer]]
*'''26 January 12''' [[Crappy Tiny Reader|CTR - Crappy Tiny Reader v0.07]] updated by [[User:PsyKopaT|PsyKo]]
*'''05 January 12''' [[Crappy Tiny Reader|CTR - Crappy Tiny Reader v0.06]] updated by [[User:PsyKopaT|PsyKo]]
*'''21 December 11''' Nintendo released system update [[3.0.0-6]]
*'''21 December 11''' [[3DSExplorer|3DSExplorer v1.1.1]] updated by [[User:Elisherer|elisherer]]
*'''7 December 11''' [[3DSExplorer|3DSExplorer v0.96]] updated by [[User:Elisherer|elisherer]]
*'''4 September 11''' [[3DSViewer|3DSViewer v0.1]] released by [[User:Elisherer|elisherer]]
*'''1 August 11''' [[3DS Save DeEncrypter3DS|Save DeEncrypter v1.0]] released by [[User:Blite|Blite]]
*'''25 July 11''' Nintendo released system update [[2.1.0-4]].
*'''15 June 11''' Nintendo released system update [[2.1.0-3]].
*'''6 June 11''' Nintendo released system update [[2.0.0-2]].
*'''6 April 11''' [[DSaveManager|DSaveManager v0.1]] released by [[User:Crediar|crediar]]
*'''4 April 11''' [[3DSaveTool|3DSaveTool v0.2b]] released by [[User:Crediar|crediar]]
*'''2 April 11''' [[3DSaveTool|3DSaveTool v0.1]] released by [[User:Crediar|crediar]]
*'''28 March 11''' Fixed 3DBrew wiki issues, now fully operational!
*'''18 March 11''' 3DBrew launched.

== 3DBrew International ==
Our community is an international community.

We have freedom, and we will express it in our language (but you have to write it in English before ;)!

News

2015-05-04T18:42:59Z

Smea: /* News */

<noinclude>
==Adding an item==
* Log in to the wiki. Editing is disabled if you don't have an account.
* Add the news event to the top of the list, using this format for the date: <tt><nowiki>'''</nowiki>{{#time: d F y}}<nowiki>''' </nowiki></tt>. Please include the application's creator, version number, and a link to a page on 3DBrew about the application. No external links please.
* '''Move the last entry to the [[:News/Archive|news archive]]. There should be no more than 4 entrees in the list.'''

==Archives==
For older news, see the [[:News/Archive|news archive]].

=== News ===
</noinclude>
*'''03 May 15''' smea released regionFOUR [https://github.com/smealum/regionFOUR/blob/master/README.md], enabling region free gaming on latest firmware. (again)
*'''20 April 15''' Nintendo released system update [[9.7.0-25]].
*'''23 March 15''' Nintendo released system update [[9.6.0-24]].
*'''2 March 15''' Nintendo released system update [[9.5.0-23]].

News

2015-05-04T15:27:43Z

Smea:

<noinclude>
==Adding an item==
* Log in to the wiki. Editing is disabled if you don't have an account.
* Add the news event to the top of the list, using this format for the date: <tt><nowiki>'''</nowiki>{{#time: d F y}}<nowiki>''' </nowiki></tt>. Please include the application's creator, version number, and a link to a page on 3DBrew about the application. No external links please.
* '''Move the last entry to the [[:News/Archive|news archive]]. There should be no more than 4 entrees in the list.'''

==Archives==
For older news, see the [[:News/Archive|news archive]].

=== News ===
</noinclude>
*'''03 May 15''' smea released regionFOUR [https://github.com/smealum/regionFOUR/blob/master/README.md], enabling region free gaming on latest firmware. (again)
*'''20 April 15''' Nintendo released system update [[9.7.0-25]].
*'''23 March 15''' Nintendo released system update [[9.6.0-24]].
*'''2 March 15''' Nintendo released system update [[9.5.0-23]].
*'''15 February 15''' WinterMute released [http://devkitpro.org/viewtopic.php?f=13&t=8409 devkitARM release 44].

IO Registers

2015-04-07T17:08:25Z

Smea: Undo revision 12253 by Neobrain (talk)

= Overview =

{| class="wikitable" border="1"
! Old3DS
! A9/A11
! Category
! Physaddr
! Used by
! Comments
|-
| style="background: green" | Yes
| A9
| [[CONFIG Registers]]
| 0x10000000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[IRQ Registers]]
| 0x10001000
| Boot9, Process9, Kernel9
| ARM9 Interrupt Masking
|-
| style="background: green" | Yes
| A9
| [[NDMA Registers]]
| 0x10002000
| Boot9, Process9
| DMA Engine
|-
| style="background: green" | Yes
| A9
| [[TIMER Registers]]
| 0x10003000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[CTRCARD Registers]]
| 0x10004000 / 0x10005000
| Process9
|
|-
| style="background: green" | Yes
| A9
| [[EMMC Registers]]
| 0x10006000 / 0x10007000
| Boot9, Process9
| 0x10007000 is normally not enabled on retail, all-zeros when read.
|-
| style="background: green" | Yes
| A9
| [[PXI Registers]]
| 0x10008000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[AES Registers]]
| 0x10009000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[SHA Registers]]
| 0x1000A000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[RSA Registers]]
| 0x1000B000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[XDMA Registers]]
| 0x1000C000
| Boot9, Kernel9
| [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0424d/index.html CoreLink™ DMA-330] (single-channel).
|-
| style="background: green" | Yes
| A9
| [[SPICARD Registers]]
| 0x1000D800
| Process9
|
|-style="border-top: double"
| style="background: green" | Yes
| ?
| [[CONFIG Registers]]
| 0x10010000
| Process9
|
|-
| style="background: green" | Yes
| ?
| PRNG Registers
| 0x10011000
| Process9
| Used as entropy-source for seeding random number generators.
|-
| style="background: green" | Yes
| ?
| [[OTP Registers]]
| 0x10012000
| Kernel9, NewKernel9Loader
| Top secret.
|-
| style="background: green" | Yes
| ?
|
| 0x10018000
| TwlProcess9
| Used to setup the ARM7 core for AGB/TWL
|-style="border-top: double"
| style="background: green" | Yes
| ?
| ?
| 0x10100000
| ?
| ?
|-
| style="background: green" | Yes
| A11/A9
| [[HASH Registers]]
| 0x10101000
| [[Filesystem services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[Camera Registers]]
| 0x10102000
| [[Camera Services]]
| y2r
|-
| style="background: green" | Yes
| A11/A9
| [[CSND Registers]] / [[DSP Registers]]
| 0x10103000
| TwlBg, [[Codec Services]], [[CSND Services]], [[DSP Services]]
| Sound hardware. For DSP regs, see the "DSi XpertTeak" section in [http://problemkaputt.de/gba.htm no$gba] help.
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| LGYFB0
| 0x10110000
| TwlBg
| IO registers used to access legacy output framebuffer, as well as configure the upscaling filter.
|-
| style="background: green" | Yes
| A11/A9
| LGYFB1
| 0x10111000
| TwlBg
| IO registers used to access legacy output framebuffer, as well as configure the upscaling filter.
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[Camera Registers]]
| 0x10120000
| [[Camera Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[Camera Registers]]
| 0x10121000
| [[Camera Services]]
| Mirror of 0x10120000?
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10122000
| [[NWM Services]]
| WIFI?
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10123000
| [[NWM Services]]
| WIFI?
|-style="border-top: double"
| style="background: red" | No
| A11/A9
| [[MVD Registers]]
| 0x10130000
| [[MVD Services]]
|
|-
| style="background: red" | No
| A11/A9
| [[MVD Registers]]
| 0x10131000
| [[MVD Services]]
|
|-
| style="background: red" | No
| A11/A9
| [[MVD Registers]]
| 0x10132000
| [[MVD Services]]
|
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[PDN Registers]]
| 0x10140000
| Process9, Boot11, Kernel11, TwlBg, [[DSP Services]], [[NWM Services]], [[SPI Services]]
| Power management.
|-
| style="background: green" | Yes
| A11/A9
| [[PDN Registers]]
| 0x10141000
| Process9, Boot11, Kernel11, TwlBg, [[Codec Services]], [[NWM Services]], [[SPI Services]], [[PDN Services]]
| Power management
|-
| style="background: green" | Yes
| A11/A9
| [[SPI Registers]]
| 0x10142000
| TwlBg, [[SPI Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[SPI Registers]]
| 0x10143000
| TwlBg
| Only used under TWL_FIRM?
|-
| style="background: green" | Yes
| A11/A9
| [[I2C Registers]]
| 0x10144000
| Boot11, Kernel11, TwlBg, [[I2C Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[CODEC Registers]]
| 0x10145000
| TwlBg, [[Codec Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[HID Registers]]
| 0x10146000
| Boot11, Kernel11, TwlBg, [[HID Services]], dlp Services
| See [[PAD]].
|-
| style="background: green" | Yes
| A11/A9
| [[GPIO Registers]]
| 0x10147000
| Boot11, TwlBg, [[GPIO Services]], [[DSP Services]](v0)
|
|-
| style="background: green" | Yes
| A11/A9
| [[I2C Registers]]
| 0x10148000
| TwlBg, [[I2C Services]]
|
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[SPI Registers]]
| 0x10160000
| Boot9, TwlBg, [[SPI Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[I2C Registers]]
| 0x10161000
| Boot11, TwlBg, [[I2C Services]]
| See [http://problemkaputt.de/gba.htm no$gba] help for some clues maybe.
|-
| style="background: green" | Yes
| A11/A9
| [[MIC Registers]]
| 0x10162000
| [[MIC Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[PXI Registers]]
| 0x10163000
| Boot11, Kernel11, TwlBg, [[PXI Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[NTRCARD Registers]]
| 0x10164000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10165000
| [[MP Services]]
|
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10170000
| [[MP Services]]
| NTR WIFI Registers, see [http://problemkaputt.de/gbatek.htm#dswirelesscommunications GBATek].
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10171000
| [[MP Services]]
| NTR WIFI Registers (mirror)
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10172000
|?
| NTR WIFI Unused?
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10173000
|?
| NTR WIFI Unused?
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10174000
| [[MP Services]]
| NTR WIFI RAM
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10175000
|?
| NTR WIFI RAM
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10176000
|?
| NTR WIFI Registers (mirror)
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10177000
|?
| NTR WIFI Registers (mirror)
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10178000 - 0x10180000
| [[MP Services]]
| NTR WIFI WS1 Region
|-style="border-top: double"
| style="background: green" | Yes
| A11
| CDMA
| 0x10200000
| Boot11, Kernel11
| [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0424d/index.html CoreLink™ DMA-330]. Not used on New3DS.
|-
| style="background: green" | Yes
| A11
| ?
| 0x10201000
|
|
|-
| style="background: green" | Yes
| A11
| [[LCD Registers]]
| 0x10202000
| TwlBg, Kernel11, [[GSP Services]]
|
|-
| style="background: green" | Yes
| A11
| [[DSP Registers]]
| 0x10203000
| [[DSP Services]]
|
|-
| style="background: green" | Yes
| A11
| ?
| 0x10204000
|
|
|-style="border-top: double"
| style="background: red" | No
| A11
| CDMA
| 0x10206000
| NewKernel11
| CDMA was moved here on New 3DS. [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0424d/index.html CoreLink™ DMA-330].
|-
| style="background: red" | No
| A11
| [[MVD Registers]]
| 0x10207000
| [[MVD Services]]
| New 3DS only?
|-style="border-top: double"
| style="background: green" | Yes
| A11
| AXI
| 0x1020F000
| TwlBg, [[GSP Services]]
| [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0422a/CHDGHIID.html CoreLink™ NIC-301 r1p0].
|-style="border-top: double"
| style="background: green" | Yes
| A11
| MIRROR
| 0x10300000-0x10400000
|
| Mirror of 0x10100000-0x10200000 (faster bus?), CDMA wants these addresses
|-style="border-top: double"
| style="background: green" | Yes
| A11
| [[GPU Registers]]
| 0x10400000
| Boot11, Kernel11, [[GSP Services]]
||
|}

IO registers starting at physical address 0x10200000 are not accessible from the ARM9 (which includes all LCD/GPU registers). It seems IO registers below physical address 0x10100000 are not accessible from the ARM11 bus.

ARM11 kernel virtual address mappings for these registers varies for different builds. For ARM11 user mode applications you have:
physaddr = virtaddr - 0x1EC00000 + 0x10100000

IO Registers

2015-04-07T16:28:12Z

Smea:

IO Registers

2015-04-07T16:22:20Z

Smea: Undo revision 12250 by Neobrain (talk)

= Overview =

{| class="wikitable" border="1"
! Old3DS
! A9/A11
! Category
! Physaddr
! Used by
! Comments
|-
| style="background: green" | Yes
| A9
| [[CONFIG Registers]]
| 0x10000000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[IRQ Registers]]
| 0x10001000
| Boot9, Process9, Kernel9
| ARM9 Interrupt Masking
|-
| style="background: green" | Yes
| A9
| [[NDMA Registers]]
| 0x10002000
| Boot9, Process9
| DMA Engine
|-
| style="background: green" | Yes
| A9
| [[TIMER Registers]]
| 0x10003000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[CTRCARD Registers]]
| 0x10004000 / 0x10005000
| Process9
|
|-
| style="background: green" | Yes
| A9
| [[EMMC Registers]]
| 0x10006000 / 0x10007000
| Boot9, Process9
| 0x10007000 is normally not enabled on retail, all-zeros when read.
|-
| style="background: green" | Yes
| A9
| [[PXI Registers]]
| 0x10008000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[AES Registers]]
| 0x10009000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[SHA Registers]]
| 0x1000A000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[RSA Registers]]
| 0x1000B000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[XDMA Registers]]
| 0x1000C000
| Boot9, Kernel9
| [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0424d/index.html CoreLink™ DMA-330] (single-channel).
|-
| style="background: green" | Yes
| A9
| [[SPICARD Registers]]
| 0x1000D800
| Process9
|
|-style="border-top: double"
| style="background: green" | Yes
| ?
| [[CONFIG Registers]]
| 0x10010000
| Process9
|
|-
| style="background: green" | Yes
| ?
| PRNG Registers
| 0x10011000
| Process9
| Used as entropy-source for seeding random number generators.
|-
| style="background: green" | Yes
| ?
| [[OTP Registers]]
| 0x10012000
| Kernel9, NewKernel9Loader
| Top secret.
|-
| style="background: green" | Yes
| ?
|
| 0x10018000
| TwlProcess9
| Used to setup the ARM7 core for AGB/TWL
|-style="border-top: double"
| style="background: green" | Yes
| ?
| ?
| 0x10100000
| ?
| ?
|-
| style="background: green" | Yes
| A11/A9
| [[HASH Registers]]
| 0x10101000
| [[Filesystem services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[Camera Registers]]
| 0x10102000
| [[Camera Services]]
| y2r
|-
| style="background: green" | Yes
| A11/A9
| [[CSND Registers]] / [[DSP Registers]]
| 0x10103000
| TwlBg, [[Codec Services]], [[CSND Services]], [[DSP Services]]
| Sound hardware. For DSP regs, see the "DSi XpertTeak" section in [http://problemkaputt.de/gba.htm no$gba] help.
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| LGYFB_SUB
| 0x10110000
| TwlBg
| IO registers used to access legacy output framebuffer, as well as configure the upscaling filter.
|-
| style="background: green" | Yes
| A11/A9
| LGYFB_MAIN
| 0x10111000
| TwlBg
| IO registers used to access legacy output framebuffer, as well as configure the upscaling filter.
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[Camera Registers]]
| 0x10120000
| [[Camera Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[Camera Registers]]
| 0x10121000
| [[Camera Services]]
| Mirror of 0x10120000?
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10122000
| [[NWM Services]]
| WIFI?
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10123000
| [[NWM Services]]
| WIFI?
|-style="border-top: double"
| style="background: red" | No
| A11/A9
| [[MVD Registers]]
| 0x10130000
| [[MVD Services]]
|
|-
| style="background: red" | No
| A11/A9
| [[MVD Registers]]
| 0x10131000
| [[MVD Services]]
|
|-
| style="background: red" | No
| A11/A9
| [[MVD Registers]]
| 0x10132000
| [[MVD Services]]
|
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[PDN Registers]]
| 0x10140000
| Process9, Boot11, Kernel11, TwlBg, [[DSP Services]], [[NWM Services]], [[SPI Services]]
| Power management.
|-
| style="background: green" | Yes
| A11/A9
| [[PDN Registers]]
| 0x10141000
| Process9, Boot11, Kernel11, TwlBg, [[Codec Services]], [[NWM Services]], [[SPI Services]], [[PDN Services]]
| Power management
|-
| style="background: green" | Yes
| A11/A9
| [[SPI Registers]]
| 0x10142000
| TwlBg, [[SPI Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[SPI Registers]]
| 0x10143000
| TwlBg
| Only used under TWL_FIRM?
|-
| style="background: green" | Yes
| A11/A9
| [[I2C Registers]]
| 0x10144000
| Boot11, Kernel11, TwlBg, [[I2C Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[CODEC Registers]]
| 0x10145000
| TwlBg, [[Codec Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[HID Registers]]
| 0x10146000
| Boot11, Kernel11, TwlBg, [[HID Services]], dlp Services
| See [[PAD]].
|-
| style="background: green" | Yes
| A11/A9
| [[GPIO Registers]]
| 0x10147000
| Boot11, TwlBg, [[GPIO Services]], [[DSP Services]](v0)
|
|-
| style="background: green" | Yes
| A11/A9
| [[I2C Registers]]
| 0x10148000
| TwlBg, [[I2C Services]]
|
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[SPI Registers]]
| 0x10160000
| Boot9, TwlBg, [[SPI Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[I2C Registers]]
| 0x10161000
| Boot11, TwlBg, [[I2C Services]]
| See [http://problemkaputt.de/gba.htm no$gba] help for some clues maybe.
|-
| style="background: green" | Yes
| A11/A9
| [[MIC Registers]]
| 0x10162000
| [[MIC Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[PXI Registers]]
| 0x10163000
| Boot11, Kernel11, TwlBg, [[PXI Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[NTRCARD Registers]]
| 0x10164000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10165000
| [[MP Services]]
|
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10170000
| [[MP Services]]
| NTR WIFI Registers, see [http://problemkaputt.de/gbatek.htm#dswirelesscommunications GBATek].
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10171000
| [[MP Services]]
| NTR WIFI Registers (mirror)
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10172000
|?
| NTR WIFI Unused?
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10173000
|?
| NTR WIFI Unused?
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10174000
| [[MP Services]]
| NTR WIFI RAM
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10175000
|?
| NTR WIFI RAM
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10176000
|?
| NTR WIFI Registers (mirror)
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10177000
|?
| NTR WIFI Registers (mirror)
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10178000 - 0x10180000
| [[MP Services]]
| NTR WIFI WS1 Region
|-style="border-top: double"
| style="background: green" | Yes
| A11
| CDMA
| 0x10200000
| Boot11, Kernel11
| [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0424d/index.html CoreLink™ DMA-330]. Not used on New3DS.
|-
| style="background: green" | Yes
| A11
| ?
| 0x10201000
|
|
|-
| style="background: green" | Yes
| A11
| [[LCD Registers]]
| 0x10202000
| TwlBg, Kernel11, [[GSP Services]]
|
|-
| style="background: green" | Yes
| A11
| [[DSP Registers]]
| 0x10203000
| [[DSP Services]]
|
|-
| style="background: green" | Yes
| A11
| ?
| 0x10204000
|
|
|-style="border-top: double"
| style="background: red" | No
| A11
| CDMA
| 0x10206000
| NewKernel11
| CDMA was moved here on New 3DS. [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0424d/index.html CoreLink™ DMA-330].
|-
| style="background: red" | No
| A11
| [[MVD Registers]]
| 0x10207000
| [[MVD Services]]
| New 3DS only?
|-style="border-top: double"
| style="background: green" | Yes
| A11
| AXI
| 0x1020F000
| TwlBg, [[GSP Services]]
| [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0422a/CHDGHIID.html CoreLink™ NIC-301 r1p0].
|-style="border-top: double"
| style="background: green" | Yes
| A11
| MIRROR
| 0x10300000-0x10400000
|
| Mirror of 0x10100000-0x10200000 (faster bus?), CDMA wants these addresses
|-style="border-top: double"
| style="background: green" | Yes
| A11
| [[GPU Registers]]
| 0x10400000
| Boot11, Kernel11, [[GSP Services]]
||
|}

IO registers starting at physical address 0x10200000 are not accessible from the ARM9 (which includes all LCD/GPU registers). It seems IO registers below physical address 0x10100000 are not accessible from the ARM11 bus.

ARM11 kernel virtual address mappings for these registers varies for different builds. For ARM11 user mode applications you have:
physaddr = virtaddr - 0x1EC00000 + 0x10100000

IO Registers

2015-04-06T20:43:28Z

Smea: LGYFB

= Overview =

{| class="wikitable" border="1"
! Old3DS
! A9/A11
! Category
! Physaddr
! Used by
! Comments
|-
| style="background: green" | Yes
| A9
| [[CONFIG Registers]]
| 0x10000000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[IRQ Registers]]
| 0x10001000
| Boot9, Process9, Kernel9
| ARM9 Interrupt Masking
|-
| style="background: green" | Yes
| A9
| [[NDMA Registers]]
| 0x10002000
| Boot9, Process9
| DMA Engine
|-
| style="background: green" | Yes
| A9
| [[TIMER Registers]]
| 0x10003000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[CTRCARD Registers]]
| 0x10004000 / 0x10005000
| Process9
|
|-
| style="background: green" | Yes
| A9
| [[EMMC Registers]]
| 0x10006000 / 0x10007000
| Boot9, Process9
| 0x10007000 is normally not enabled on retail, all-zeros when read.
|-
| style="background: green" | Yes
| A9
| [[PXI Registers]]
| 0x10008000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[AES Registers]]
| 0x10009000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[SHA Registers]]
| 0x1000A000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[RSA Registers]]
| 0x1000B000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A9
| [[XDMA Registers]]
| 0x1000C000
| Boot9, Kernel9
| [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0424d/index.html CoreLink™ DMA-330] (single-channel).
|-
| style="background: green" | Yes
| A9
| [[SPICARD Registers]]
| 0x1000D800
| Process9
|
|-style="border-top: double"
| style="background: green" | Yes
| ?
| [[CONFIG Registers]]
| 0x10010000
| Process9
|
|-
| style="background: green" | Yes
| ?
| PRNG Registers
| 0x10011000
| Process9
| Used as entropy-source for seeding random number generators.
|-
| style="background: green" | Yes
| ?
| [[OTP Registers]]
| 0x10012000
| Kernel9, NewKernel9Loader
| Top secret.
|-
| style="background: green" | Yes
| ?
|
| 0x10018000
| TwlProcess9
| Used to setup the ARM7 core for AGB/TWL
|-style="border-top: double"
| style="background: green" | Yes
| ?
| ?
| 0x10100000
| ?
| ?
|-
| style="background: green" | Yes
| A11/A9
| [[HASH Registers]]
| 0x10101000
| [[Filesystem services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[Camera Registers]]
| 0x10102000
| [[Camera Services]]
| y2r
|-
| style="background: green" | Yes
| A11/A9
| [[CSND Registers]] / [[DSP Registers]]
| 0x10103000
| TwlBg, [[Codec Services]], [[CSND Services]], [[DSP Services]]
| Sound hardware. For DSP regs, see the "DSi XpertTeak" section in [http://problemkaputt.de/gba.htm no$gba] help.
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| LGYFB_SUB
| 0x10110000
| TwlBg
| IO registers used to access legacy output framebuffer, as well as configure the upscaling filter.
|-
| style="background: green" | Yes
| A11/A9
| LGYFB_MAIN
| 0x10111000
| TwlBg
| IO registers used to access legacy output framebuffer, as well as configure the upscaling filter.
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[Camera Registers]]
| 0x10120000
| [[Camera Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[Camera Registers]]
| 0x10121000
| [[Camera Services]]
| Mirror of 0x10120000?
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10122000
| [[NWM Services]]
| WIFI?
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10123000
| [[NWM Services]]
| WIFI?
|-style="border-top: double"
| style="background: red" | No
| A11/A9
| [[MVD Registers]]
| 0x10130000
| [[MVD Services]]
|
|-
| style="background: red" | No
| A11/A9
| [[MVD Registers]]
| 0x10131000
| [[MVD Services]]
|
|-
| style="background: red" | No
| A11/A9
| [[MVD Registers]]
| 0x10132000
| [[MVD Services]]
|
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[PDN Registers]]
| 0x10140000
| Process9, Boot11, Kernel11, TwlBg, [[DSP Services]], [[NWM Services]], [[SPI Services]]
| Power management.
|-
| style="background: green" | Yes
| A11/A9
| [[PDN Registers]]
| 0x10141000
| Process9, Boot11, Kernel11, TwlBg, [[Codec Services]], [[NWM Services]], [[SPI Services]], [[PDN Services]]
| Power management
|-
| style="background: green" | Yes
| A11/A9
| [[SPI Registers]]
| 0x10142000
| TwlBg, [[SPI Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[SPI Registers]]
| 0x10143000
| TwlBg
| Only used under TWL_FIRM?
|-
| style="background: green" | Yes
| A11/A9
| [[I2C Registers]]
| 0x10144000
| Boot11, Kernel11, TwlBg, [[I2C Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[CODEC Registers]]
| 0x10145000
| TwlBg, [[Codec Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[HID Registers]]
| 0x10146000
| Boot11, Kernel11, TwlBg, [[HID Services]], dlp Services
| See [[PAD]].
|-
| style="background: green" | Yes
| A11/A9
| [[GPIO Registers]]
| 0x10147000
| Boot11, TwlBg, [[GPIO Services]], [[DSP Services]](v0)
|
|-
| style="background: green" | Yes
| A11/A9
| [[I2C Registers]]
| 0x10148000
| TwlBg, [[I2C Services]]
|
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[SPI Registers]]
| 0x10160000
| Boot9, TwlBg, [[SPI Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[I2C Registers]]
| 0x10161000
| Boot11, TwlBg, [[I2C Services]]
| See [http://problemkaputt.de/gba.htm no$gba] help for some clues maybe.
|-
| style="background: green" | Yes
| A11/A9
| [[MIC Registers]]
| 0x10162000
| [[MIC Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[PXI Registers]]
| 0x10163000
| Boot11, Kernel11, TwlBg, [[PXI Services]]
|
|-
| style="background: green" | Yes
| A11/A9
| [[NTRCARD Registers]]
| 0x10164000
| Boot9, Process9
|
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10165000
| [[MP Services]]
|
|-style="border-top: double"
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10170000
| [[MP Services]]
| NTR WIFI Registers, see [http://problemkaputt.de/gbatek.htm#dswirelesscommunications GBATek].
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10171000
| [[MP Services]]
| NTR WIFI Registers (mirror)
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10172000
|?
| NTR WIFI Unused?
|-
| style="background: green" | Yes
| A11/A9
|?
| 0x10173000
|?
| NTR WIFI Unused?
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10174000
| [[MP Services]]
| NTR WIFI RAM
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10175000
|?
| NTR WIFI RAM
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10176000
|?
| NTR WIFI Registers (mirror)
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10177000
|?
| NTR WIFI Registers (mirror)
|-
| style="background: green" | Yes
| A11/A9
| [[MP Registers]]
| 0x10178000 - 0x10180000
| [[MP Services]]
| NTR WIFI WS1 Region
|-style="border-top: double"
| style="background: green" | Yes
| A11
| CDMA
| 0x10200000
| Boot11, Kernel11
| [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0424d/index.html CoreLink™ DMA-330]. Not used on New3DS.
|-
| style="background: green" | Yes
| A11
| ?
| 0x10201000
|
|
|-
| style="background: green" | Yes
| A11
| [[LCD Registers]]
| 0x10202000
| TwlBg, Kernel11, [[GSP Services]]
|
|-
| style="background: green" | Yes
| A11
| [[DSP Registers]]
| 0x10203000
| [[DSP Services]]
|
|-
| style="background: green" | Yes
| A11
| ?
| 0x10204000
|
|
|-style="border-top: double"
| style="background: red" | No
| A11
| CDMA
| 0x10206000
| NewKernel11
| CDMA was moved here on New 3DS. [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0424d/index.html CoreLink™ DMA-330].
|-
| style="background: red" | No
| A11
| [[MVD Registers]]
| 0x10207000
| [[MVD Services]]
| New 3DS only?
|-style="border-top: double"
| style="background: green" | Yes
| A11
| AXI
| 0x1020F000
| TwlBg, [[GSP Services]]
| [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0422a/CHDGHIID.html CoreLink™ NIC-301 r1p0].
|-style="border-top: double"
| style="background: green" | Yes
| A11
| MIRROR
| 0x10300000-0x10400000
|
| Mirror of 0x10100000-0x10200000 (faster bus?), CDMA wants these addresses
|-style="border-top: double"
| style="background: green" | Yes
| A11
| [[GPU Registers]]
| 0x10400000
| Boot11, Kernel11, [[GSP Services]]
||
|}

IO registers starting at physical address 0x10200000 are not accessible from the ARM9 (which includes all LCD/GPU registers). It seems IO registers below physical address 0x10100000 are not accessible from the ARM11 bus.

ARM11 kernel virtual address mappings for these registers varies for different builds. For ARM11 user mode applications you have:
physaddr = virtaddr - 0x1EC00000 + 0x10100000

GPU/External Registers

2015-03-31T01:25:33Z

Smea:

This page describes the address range used to configure the basic GPU functionality.

== Map ==
{| class="wikitable" border="1"
! User VA
! PA
! Length
! Name
! Comments
|-
| 0x1EF00004
| 0x10400004
| 4
| ?
|
|-
| 0x1EF00010
| 0x10400010
| 16
| [[#Memory Fill|Memory Fill1]] "PSC0"
| GX command 2
|-
| 0x1EF00020
| 0x10400020
| 16
| [[#Memory Fill|Memory Fill2]] "PSC1"
| GX command 2
|-
| 0x1EF00030
| 0x10400030
| 4
| ?
|
|-
| 0x1EF00034
| 0x10400034
| 4
| GPU Busy
| Bit31 = cmd-list busy, bit27 = PSC0 busy, bit26 = PSC1 busy.
|-
| 0x1EF00050
| 0x10400050
| 4
| ?
| Writes 0x22221200 on GPU init.
|-
| 0x1EF00054
| 0x10400054
| 4
| ?
| Writes 0xFF2 on GPU init.
|-
| 0x1EF00400
| 0x10400400
| 0x100
| [[#Framebuffer_Setup|Framebuffer Setup]] "PDC0" (top screen)
|
|-
| 0x1EF00500
| 0x10400500
| 0x100
| [[#Framebuffer_Setup|Framebuffer Setup]] "PDC1" (bottom)
|
|-
| 0x1EF00C00
| 0x10400C00
| ?
| [[#Transfer_Engine|Transfer Engine]] "DMA"
|
|-
| 0x1EF01000
| 0x10401000
| 0x4
| ?
| Writes 0 on GPU init.
|-
| 0x1EF01080
| 0x10401080
| 0x4
| ?
| Writes 0x12345678 on GPU init.
|-
| 0x1EF010C0
| 0x104010C0
| 0x4
| ?
| Writes 0xFFFFFFF0 on GPU init.
|-
| 0x1EF010D0
| 0x104010D0
| 0x4
| ?
| Writes 1 on GPU init.
|-
| 0x1EF014??
| 0x104014??
| 0x14
| "PPF" ?
|
|-
| 0x1EF018E0
| 0x104018E0
| 0x14
| [[#Command_List|Command List]] "P3D"
|
|}

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

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

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

== LCD Source Framebuffer Setup ==
{| class="wikitable" border="1"
! Offset
! Length
! Name
! Comments
|-
| 0x5C
| 4
| Framebuffer width & height
| Lower 16 bits: width, upper 16 bits: height
|-
| 0x68
| 4
| Framebuffer A first address
| For top screen, this is the left eye 3D framebuffer.
|-
| 0x6C
| 4
| Framebuffer A second address
| For top screen, this is the left eye 3D framebuffer.
|-
| 0x70
| 4
| Framebuffer format
| Bit0-15: framebuffer format, bit16-31: unknown
|-
| 0x78
| 4
| Framebuffer select
| Bit0: which framebuffer to display, bit1-7: unknown
|-
| 0x90
| 4
| Framebuffer stride
| Distance in bytes between two framebuffer pixel rows (must be a multiple of 8).
|-
| 0x94
| 4
| Framebuffer B first address
| For top screen, this is the right eye 3D framebuffer. Unused for bottom screen.
|-
| 0x98
| 4
| Framebuffer B second address
| For top screen, this is the right eye 3D framebuffer. Unused for bottom screen.
|}

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

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

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

== Transfer Engine ==
{| class="wikitable" border="1"
! Register address
! Description
|-
| 0x1EF00C00
| Input physical address>>3
|-
| 0x1EF00C04
| Output physical address>>3
|-
| 0x1EF00C08
| Output framebuffer dimensions, used with cmd3
|-
| 0x1EF00C0C
| Input framebuffer dimensions, used with cmd3
|-
| 0x1EF00C10
| Flags, used with cmd3 and cmd4.
|-
| 0x1EF00C14
| GSP module writes value 0 here prior to writing to 0x1EF00C18, for cmd3.
|-
| 0x1EF00C18
| Setting bit0 starts the transfer. Upon completion, bit0 is unset and bit8 is set.
|-
| 0x1EF00C20
| Texture info? used with cmd4 ("Size" in [[GSP_Shared_Memory|GX command]])
|-
| 0x1EF00C24
| Texture info? used with cmd4 ("Input dimensions?" in [[GSP_Shared_Memory|GX command]])
|-
| 0x1EF00C28
| Texture info? used with cmd4 ("Output dimensions?" in [[GSP_Shared_Memory|GX command]])
|}

These registers are used by [[GSP_Shared_Memory|GX command]] 3 and 4. For cmd4, *0x1EF00C18 |= 1 is used instead of just writing value 1. The dimensions fields seem to use the same format as [[LCD]] register 0x1EF00X5C. The input framebuffer width for the main screen is normally 480.

==== 0x1EF00C10 ====
{| class="wikitable" border="1"
! Bit
! Description
|-
| 0
| When set, the framebuffer data is flipped vertically.
|-
| 1
| When set, the input framebuffer is treated as linear and converted to tiled in the output, converts tiled->linear when unset.
|-
| 2
| This bit is set when the out-framebuf width/height is less than the input framebuf width/height, clear otherwise. Bit24 is normally clear when this bit is set.
|-
| 3
| When set, the input framebuffer data is copied as-is to the output framebuffer, without any kind of conversions. The data is truncated to the output size.
|-
| 4
| Not writable
|-
| 5
| Writable, but purpose unknown (usually zero)
|-
| 7-6
| Not writable
|-
| 10-8
| Input framebuffer color format, value0 and value1 are the same as the [[GPU Registers#Framebuffer_color_formats|LCD Source Framebuffer Formats]] (usually zero)
|-
| 11
| Not writable
|-
| 14-12
| Output framebuffer color format
|-
| 15
| Not writable
|-
| 16
| Unknown, normally zero.
|-
| 17-23
| Not writable
|-
| 24
| Scale down the input image to its half width using a box filter.
|-
| 25
| Scale down the input image to its half height and half width using a box filter.
|-
| 31-26
| Not writable
|}

== Command List ==
{| class="wikitable" border="1"
! Register address
! Description
|-
| 0x1EF018E0
| Buffer size >> 3
|-
| 0x1EF018E8
| Buffer physical address >> 3
|-
| 0x1EF018F0
| Writing value 1 here triggers GPU to execute the commands.
|}

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

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

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

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

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

CONFIG11 Registers

2015-03-31T00:40:17Z

Smea:

= Registers =
{| class="wikitable" border="1"
! Old3DS
! Name
! Address
! Width
! Used by
|-
| style="background: green" | Yes
| [[#PDN_SHAREDWRAM_32K_DATA|PDN_SHAREDWRAM_32K_DATA]]<0-7>
| 0x10140000
| 1*8
| Boot11, Process9, [[DSP Services]]
|-
| style="background: green" | Yes
| [[#PDN_SHAREDWRAM_32K_CODE|PDN_SHAREDWRAM_32K_CODE]]<0-7>
| 0x10140008
| 1*8
| Boot11, Process9, [[DSP Services]]
|-
| style="background: green" | Yes
| ?
| 0x10140100
| 2
|
|-
| style="background: green" | Yes
| ?
| 0x10140102
| 2
|
|-
| style="background: green" | Yes
| ARM11 interrupt related.
| 0x10140104
| 1
| Kernel11.
|-
| style="background: green" | Yes
| ?
| 0x10140105
| 1
| Kernel11.
|-
| style="background: green" | Yes
| ?
| 0x10140108
| 2
| TwlBg
|-
| style="background: green" | Yes
| ?
| 0x1014010C
| 2
|
|-
| style="background: green" | Yes
| ?
| 0x10140140
| 2
|
|-
| style="background: green" | Yes
| [[#PDN_WIFI_CNT|PDN_WIFI_CNT]]
| 0x10140180
| 1
| TwlBg
|-
| style="background: green" | Yes
| [[#PDN_SPI_CNT|PDN_SPI_CNT]]
| 0x101401C0
| 4
| [[SPI Services]], TwlBg
|-
| style="background: green" | Yes
| ?
| 0x10140200
| 4
|
|-style="border-top: double"
| style="background: red" | No
| Clock related?
| 0x10140400
| 1
| NewProcess11
|-
| style="background: red" | No
| Clock related?
| 0x10140410
| 4
| NewProcess11
|-
| style="background: red" | No
| [[#PDN_BOOTROM_OVERLAY_CNT|PDN_BOOTROM_OVERLAY_CNT]]
| 0x10140420
| 4
| NewProcess11
|-
| style="background: red" | No
| [[#PDN_BOOTROM_OVERLAY_VAL|PDN_BOOTROM_OVERLAY_VAL]]
| 0x10140424
| 4
| NewProcess11
|-
| style="background: red" | No
| ?
| 0x10140428
| 4
|
|-style="border-top: double"
| style="background: green" | Yes
| [[#PDN_MPCORE_CFG|PDN_MPCORE_CFG]]
| 0x10140FFC
| 1
| NewKernel11
|-style="border-top: double"
| style="background: green" | Yes
| PDN_GPU_STATUS?
| 0x10141000
| 4
| Kernel11, TwlBg
|-
| style="background: green" | Yes
| PDN_PTM_0
| 0x10141008
| 4
| [[PTM Services]], [[PDN Services]]
|-
| style="background: green" | Yes
| PDN_PTM_1
| 0x1014100C
| 4
| [[PTM Services]], TwlBg, [[PDN Services]]
|-style="border-top: double"
| style="background: green" | Yes
| [[#PDN_TWLMODE_0|PDN_TWLMODE_0]]
| 0x10141100
| 2
| TwlProcess9, TwlBg
|-
| style="background: green" | Yes
| [[#PDN_TWLMODE_1|PDN_TWLMODE_1]]
| 0x10141104
| 2
| TwlBg
|-
| style="background: green" | Yes
| [[#PDN_TWLMODE_2|PDN_TWLMODE_2]]
| 0x10141108
| 2
| TwlBg
|-
| style="background: green" | Yes
|
| 0x1014110A
| 2
| TwlBg
|-
| style="background: green" | Yes
| PDN_WIFI?
| 0x1014110C
| 1
|
|-
| style="background: green" | Yes
| ?
| 0x10141110
| 2
| TwlBg
|-
| style="background: green" | Yes
| ?
| 0x10141112
| 2
| TwlBg
|-
| style="background: green" | Yes
| [[#PDN_CODEC|PDN_CODEC_0]]
| 0x10141114
| 2
| [[CODEC Services]], TwlBg
|-
| style="background: green" | Yes
| [[#PDN_CODEC|PDN_CODEC_1]]
| 0x10141116
| 2
| [[CODEC Services]], TwlBg
|-
| style="background: green" | Yes
| ?
| 0x10141118
| 1
| TwlBg
|-
| style="background: green" | Yes
| ?
| 0x10141119
| 1
| TwlBg
|-
| style="background: green" | Yes
| ?
| 0x10141120
| 1
| TwlBg
|-
|-style="border-top: double"
| style="background: green" | Yes
| [[#PDN_GPU_CNT|PDN_GPU_CNT]]
| 0x10141200
| 4
| Boot11, Kernel11, [[PDN Services]]
|-
| style="background: green" | Yes
| [[#PDN_GPU_CNT2|PDN_GPU_CNT2]]
| 0x10141204
| 4
| Boot11, Kernel11
|-
| style="background: green" | Yes
| PDN_GPU_CNT3
| 0x10141210
| 2
| Kernel11, TwlBg
|-
| style="background: green" | Yes
| [[#PDN_CODEC_CNT|PDN_CODEC_CNT]]
| 0x10141220
| 1
| Boot11, TwlBg, [[PDN Services]]
|-
| style="background: green" | Yes
| [[#PDN_CAMERA_CNT|PDN_CAMERA_CNT]]
| 0x10141224
| 1
| [[PDN Services]]
|-
| style="background: green" | Yes
| PDN_DSP_CNT
| 0x10141230
| 1
| Process9, [[PDN Services]]
|-style="border-top: double"
| style="background: red" | No
| [[#PDN_MPCORE_STATUS|PDN_MPCORE_STATUS]]
| 0x10141300
| 2
| NewProcess11
|-
| style="background: red" | No
| [[#PDN_MPCORE_CNT|PDN_MPCORE_CNT]]
| 0x10141304
| 2
| NewProcess11
|-
| style="background: red" | No
| [[#PDN_MPCORE_BOOTCNT<0-3>|PDN_MPCORE_BOOTCNT]]<0-3>
| 0x10141310
| 1*4
| NewProcess11
|}

== PDN_SHAREDWRAM_32K_DATA ==
Used for mapping 32K chunks of shared WRAM for DSP data.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| Master (0=ARM9?, 1=ARM11?, 2 or 3=DSP/data)
|-
| 2-4
| Offset (0..7) (slot 0..7) (LSB of address in 32Kbyte units)
|-
| 5-6
| Not used (0)
|-
| 7
| Enable (0=Disable, 1=Enable)
|}

== PDN_SHAREDWRAM_32K_CODE ==
Used for mapping 32K chunks of shared WRAM for DSP data.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-1
| Master (0=ARM9?, 1=ARM11?, 2 or 3=DSP/code)
|-
| 2-4
| Offset (0..7) (slot 0..7) (LSB of address in 32Kbyte units)
|-
| 5-6
| Not used (0)
|-
| 7
| Enable (0=Disable, 1=Enable)
|}

== PDN_SPI_CNT ==
{| class="wikitable" border="1"
! Bit
! Description
|-
| 0
| Enable [[SPI Registers]] 0x10160000.
|-
| 1
| Enable [[SPI Registers]] 0x10142000.
|-
| 2
| Enable [[SPI Registers]] 0x10143800.
|}

== PDN_BOOTROM_OVERLAY_CNT ==
Bit0: Enable bootrom overlay functionality.

== PDN_BOOTROM_OVERLAY_VAL ==
The 32-bit value to overlay data-reads to bootrom with. See [[#PDN_MPCORE_BOOTCNT|PDN_MPCORE_BOOTCNT]].

== PDN_MPCORE_CFG ==
Read-only register.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| Always set to 1 on both Old3DS and New3DS.
|-
| 1
| 3rd ARM11 MPCore available maybe?
|-
| 2
| 4th ARM11 MPCore available maybe?
|}

== PDN_MPCORE_STATUS ==
Read-only register.

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| Always set to 1 on both Old3DS and New3DS.
|-
| 1
| 3rd ARM11 MPCore powered on maybe?
|-
| 2
| 4th ARM11 MPCore powered on maybe?
|}

== PDN_MPCORE_CNT ==
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| Power on 3rd ARM11 MPCore maybe?
|-
| 8
| Power on 4th ARM11 MPCore maybe?
|}

== PDN_MPCORE_BOOTCNT<0-3> ==
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| Enable bootrom instruction overlay. This bit is only writable for core2 and core3.
|-
| 1
| Enable bootrom data overlay. This bit is only writable for core2 and core3.
|-
| 4
| Has core booted maybe?
|-
| 5
| Always 1?
|}

The normal ARM11 bootrom checks cpuid and hangs if cpuid >= 2. This is a problem when booting the 2 additional New3DS ARM11 MPCores. NewKernel11 solves this by using a hardware feature to overlay the bootrom with a configurable branch to a kernel function. This overlay feature was added with the New3DS.

Bit1 in register above enables a bootrom data-override for physical addresses 0xFFFF0000-0xFFFF1000 and 0x10000-0x11000. All _data reads_ made to those regions now read the 32-bit value provided in [[#PDN_BOOTROM_OVERLAY_VAL|PDN_BOOTROM_OVERLAY_VAL]].

Bit0 enables a bootrom instruction-overlay which means that _instruction reads_ made to the bootrom region are overridden. We have not been able to dump what instructions are actually placed at bootrom by this switch (because reading the area only yields data-reads). Jumping randomly into the 0xFFFF0000-0xFFFF1000 region works fine and jumps to the value provided by the data overlay [[#PDN_BOOTROM_OVERLAY_VAL|PDN_BOOTROM_OVERLAY_VAL]]. Thus we may predict that the entire bootrom region is filled by:
ldr pc, [pc]

Or equivalent. However, jumping to some high addresses such as 0xFFFF0FF0+ will crash the core. This may be explained by prefetching in the ARM pipeline, and might help us identify what instructions are placed by the instruction-overlay.

==PDN_WIFI_CNT==
Bit0: Enable wifi.

==PDN_TWLMODE_0==
Observed 0x8001 when running under TWL_FIRM, 0 NATIVE_FIRM.

The very last 3DS-mode register poke the [[FIRM|TWL_FIRM]] Process9 does before it gets switched into TWL-mode, is writing 0x8000 to this register. Before writing this register, TWL Process9 waits for the value of this register to become non-zero. The Process9 code for this runs from ITCM, since switching into TWL-mode includes remapping all ARM9 physical memory.

Writing 0x8000 to here from the ARM9 with NATIVE_FIRM running doesn't seem to do anything, other reg-pokes likely need done first.

==PDN_TWLMODE_1==
Observed 0x8000 when running under TWL_FIRM, 0 NATIVE_FIRM.

==PDN_GPU_CNT==
This one seems to control the LCD/GPU/Backlight.

Bit0: Enable GPU registers at 0x10400000+.
Bit16: Turn on LCD backlight.

==PDN_GPU_CNT2==
Bit0: Power on GPU?

==PDN_GPU_CNT3==
Bit1: FCRAM access from arm11?

==PDN_CODEC==
The following is the only time the ARM11 CODEC module uses any 0x1EC41XXX registers. In one case CODEC module clears bit1 in register 0x1EC41114, in the other case CODEC module sets bit1 in registers 0x1EC41114 and 0x1EC41116.

==PDN_CODEC_CNT==
This is the power register used for the [[PDN_Services|PDN]] CODEC service.

bit0 = unknown, bit1 = turn on/off DSP, rest = always 0.

==PDN_CAMERA_CNT==
This is the power register used for the [[PDN_Services|PDN]] camera service.

bit0 = unknown, bit1 = turn on/off cameras, rest = always 0.

IRU:GetIRLEDRecvState

2015-03-30T01:48:41Z

Smea:

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

=Response=
{| class="wikitable" border="1"
|-
! Index Word
! Description
|-
| 0
| Header code
|-
| 1
| Result code
|-
| 2
| u32 [[IRU:SetIRLEDState|value]]
|}

=Description=
This gets the current bit value received from IR, via GPIO (bitmask 0x20 from register 0x10147020). The GPIO value seems to be reset to zero when value 1 is returned, the GPIO value is updated the next time the IR hw checks for an IR signal.

IRU:SetIRLEDState

2015-03-29T23:18:06Z

Smea:

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

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

=Description=
Value 1 enables the IR LED, while value 0 disables it. Note that the IR LED will automatically turn off after a certain amount of time if left on this way, however to turn it back on the state has to be set to value zero first. This is set via GPIO : it writes 0x10 to 0x10147020 (0x1EC47020 in process space) to enable the LED, and clears that bit to disable it.

3DS Userland Flaws

2015-03-11T21:56:36Z

Smea:

This page lists vulnerabilities / exploits for 3DS applications and applets. Exploiting these initially results in ROP.

=Non-system applications=
{| class="wikitable" border="1"
|-
! Application name
! Summary
! Description
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| The Legend of Zelda: Ocarina of Time 3D
| UTF-16 name string buffer overflow via unchecked u8 length field
| The u8 at offfset 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.
Length value>=0xCD causes a crash while loading the saveslot, via a heap buffer overflow. When value is >=0x6E it crashes when saving the saveslot. With value >=0x9A, it crashes via stack-smash in-game once any dialogs are opened(touching buttons on the touch-screen to enter certain menu(s) can trigger it too).
| None
|
| Around October 22, 2012
| [[User:Yellows8|Yellows8]]
|-
| Cubic Ninja
| Map-data stack smash
| See [[Ninjhax|here]] regarding Ninjhax.
| None
|
| July 2014
| [[User:smea|smea]]
|}

=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]]
|}

=System applets=

News

2015-01-18T06:10:50Z

Smea:

<noinclude>
==Adding an item==
* Log in to the wiki. Editing is disabled if you don't have an account.
* Add the news event to the top of the list, using this format for the date: <tt><nowiki>'''</nowiki>{{#time: d F y}}<nowiki>''' </nowiki></tt>. Please include the application's creator, version number, and a link to a page on 3DBrew about the application. No external links please.
* '''Move the last entry to the [[:News/Archive|news archive]]. There should be no more than 4 entrees in the list.'''

==Archives==
For older news, see the [[:News/Archive|news archive]].

=== News ===
</noinclude>
*'''16 January 15''' smea released regionthree [https://github.com/smealum/regionthree/blob/master/README.md], enabling region free gaming on latest firmware
*'''24 December 14''' smea released [[Ninjhax]] 1.1 ('''NOT''' a fix for firmware [[9.3.0-21]] or [[9.4.0-21]]).
*'''11 December 14''' Nintendo released system update [[9.4.0-21]].
*'''8 December 14''' Nintendo released system update [[9.3.0-21]], which fixes [[3DS System Flaws|rohax]].
*'''20 November 14''' smea released [[Ninjhax]], the first public [[Homebrew Exploits|homebrew exploit]] compatible with system-versions [[4.0.0-7]]-[[9.2.0-20]].

SHBIN

2015-01-09T19:05:01Z

Smea:

[[Category:File formats]]
== Overview ==

The SHBIN (SHader BINary) file is used to contain compiled and linked shader programs. These can include vertex shaders (typically compiled from .vsh files) and geometry shaders (typically compiled from .gsh files, though .asm have been observed).
In commercial games/apps, SHBIN files can be found as standalone files with the extension .shbin, or contained within .bcsdr files. BCSDR files use CGFX as a container, but the underlying DVLB/DVLP/DVLE structure remains unchanged.

A SHBIN's structure starts with a header, then a DVLP, then DVLE(s).

== DVLB Header ==

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Magic "DVLB"
|-
| 0x4
| 0x4
| N = number of DVLEs in SHBIN
|-
| 0x8
| 0x4*N
| DVLE offset table; each offset is a u32 relative to the start of the DVLB section
|-
|}

The DVLP file comes directly after the header.

== DVLP ==

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Magic "DVLP"
|-
| 0x4
| 0x4
| ? (Maybe a version number?)
|-
| 0x8
| 0x4
| Offset (relative to DVLP start) to the compiled shader binary blob
|-
| 0xC
| 0x4
| Size of compiled shader binary blob, in words
|-
| 0x10
| 0x4
| Offset (relative to DVLP start) to shader instruction extension table
|-
| 0x14
| 0x4
| Number of shader instruction extension table entries (each entry is 8-byte long)
|-
| 0x18
| 0x4
| Offset (relative to DVLP start) to filename symbol table
|-
|}

== DVLE ==

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Magic "DVLE"
|-
| 0x6
| 0x1
| Shader type (0x0 = vertex shader, 0x1 = geometry shader; might contain other flags)
|-
| 0x8
| 0x4
| Program's main offset in binary blob (in words)
|-
| 0xC
| 0x4
| Program's endmain offset in binary blob (in words)
|-
| 0x18
| 0x4
| Offset (relative to DVLE start) to constant table
|-
| 0x1C
| 0x4
| Number of entries in constant table (each entry is 0x14-byte long)
|-
| 0x20
| 0x4
| Offset (relative to DVLE start) to label table
|-
| 0x24
| 0x4
| Number of entries in label table (each entry is 0x10-byte long)
|-
| 0x28
| 0x4
| Offset (relative to DVLE start) to output register table
|-
| 0x2C
| 0x4
| Number of entries in output register table (each entry is 0x8-byte long)
|-
| 0x30
| 0x4
| Offset (relative to DVLE start) to uniform table
|-
| 0x34
| 0x4
| Number of entries in uniform table (each entry is 0x8-byte long)
|-
| 0x38
| 0x4
| Offset (relative to DVLE start) to symbol table
|-
| 0x3C
| 0x4
| Size of symbol table (in bytes)
|-
|}

Label table entry :
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Label ID
|-
| 0x4
| 0x4
| Offset (relative to shader program blob start) to label's location, in words
|-
| 0x8
| 0x4
| ?
|-
| 0xC
| 0x4
| Offset (relative to DVLE symbol table start) to label's symbol
|-
|}

Constant table entry header :

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Constant type
|-
| 0x2
| 0x1
| Uniform ID
|}

There are (at least) 3 types of constants : 0 is boolean, 1 is integer vec4 and 2 is float24 vec4.

Corresponding constant entry formats :

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| 0x0
|-
| 0x2
| 0x1
| Uniform bool ID
|-
| 0x4
| 0x1
| Value (boolean)
|}

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| 0x1
|-
| 0x2
| 0x1
| Uniform integer vector ID
|-
| 0x4
| 0x1
| x (u8)
|-
| 0x5
| 0x1
| y (u8)
|-
| 0x6
| 0x1
| z (u8)
|-
| 0x7
| 0x1
| w (u8)
|}

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| 0x2
|-
| 0x2
| 0x1
| Uniform vector ID
|-
| 0x4
| 0x4
| x (float24)
|-
| 0x8
| 0x4
| y (float24)
|-
| 0xC
| 0x4
| z (float24)
|-
| 0x10
| 0x4
| w (float24)
|}

Output register table entry:
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0-3
| Output type (see table below)
|-
| 16-19
| Register ID
|-
| 32-35
| Output attribute component mask (e.g. 5=xz)
|}

Output types :
{| class="wikitable" border="1"
|-
! ID
! Description
|-
| 0x0
| result.position
|-
| 0x1
| result.normalquat
|-
| 0x2
| result.color
|-
| 0x3
| result.texcoord0
|-
| 0x4
| result.texcoord0w
|-
| 0x5
| result.texcoord1
|-
| 0x6
| result.texcoord2
|-
| 0x7
| ?
|-
| 0x8
| result.view
|}

Uniform table entry :
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Offset (relative to DVLE symbol table start) to variable's symbol
|-
| 0x4
| 0x2
| Variable start register
|-
| 0x6
| 0x2
| Variable end register
|-
|}

Each DVLE is associated to an individual shader shader program contained in the binary blob. A single shader binary blob may contain multiple shader programs of the same kind.

Each program's constants are stored as vec4 in a uniform table. These are sent over to the GPU when changing to a give program.

== Instruction Set ==

For a description of the instruction set, see the following page : [[Shader Instruction Set]]

SHBIN

2015-01-09T19:01:47Z

Smea:

[[Category:File formats]]
== Overview ==

The SHBIN (SHader BINary) file is used to contain compiled and linked shader programs. These can include vertex shaders (typically compiled from .vsh files) and geometry shaders (typically compiled from .gsh files, though .asm have been observed).
In commercial games/apps, SHBIN files can be found as standalone files with the extension .shbin, or contained within .bcsdr files. BCSDR files use CGFX as a container, but the underlying DVLB/DVLP/DVLE structure remains unchanged.

A SHBIN's structure starts with a header, then a DVLP, then DVLE(s).

== DVLB Header ==

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Magic "DVLB"
|-
| 0x4
| 0x4
| N = number of DVLEs in SHBIN
|-
| 0x8
| 0x4*N
| DVLE offset table; each offset is a u32 relative to the start of the DVLB section
|-
|}

The DVLP file comes directly after the header.

== DVLP ==

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Magic "DVLP"
|-
| 0x4
| 0x4
| ? (Maybe a version number?)
|-
| 0x8
| 0x4
| Offset (relative to DVLP start) to the compiled shader binary blob
|-
| 0xC
| 0x4
| Size of compiled shader binary blob, in words
|-
| 0x10
| 0x4
| Offset (relative to DVLP start) to shader instruction extension table
|-
| 0x14
| 0x4
| Number of shader instruction extension table entries (each entry is 8-byte long)
|-
| 0x18
| 0x4
| Offset (relative to DVLP start) to filename symbol table
|-
|}

== DVLE ==

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Magic "DVLE"
|-
| 0x6
| 0x1
| Shader type (0x0 = vertex shader, 0x1 = geometry shader; might contain other flags)
|-
| 0x8
| 0x4
| Program's main offset in binary blob (in words)
|-
| 0xC
| 0x4
| Program's endmain offset in binary blob (in words)
|-
| 0x18
| 0x4
| Offset (relative to DVLE start) to constant table
|-
| 0x1C
| 0x4
| Number of entries in constant table (each entry is 0x14-byte long)
|-
| 0x20
| 0x4
| Offset (relative to DVLE start) to label table
|-
| 0x24
| 0x4
| Number of entries in label table (each entry is 0x10-byte long)
|-
| 0x28
| 0x4
| Offset (relative to DVLE start) to output register table
|-
| 0x2C
| 0x4
| Number of entries in output register table (each entry is 0x8-byte long)
|-
| 0x30
| 0x4
| Offset (relative to DVLE start) to uniform table
|-
| 0x34
| 0x4
| Number of entries in uniform table (each entry is 0x8-byte long)
|-
| 0x38
| 0x4
| Offset (relative to DVLE start) to symbol table
|-
| 0x3C
| 0x4
| Size of symbol table (in bytes)
|-
|}

Label table entry :
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Label ID
|-
| 0x4
| 0x4
| Offset (relative to shader program blob start) to label's location, in words
|-
| 0x8
| 0x4
| ?
|-
| 0xC
| 0x4
| Offset (relative to DVLE symbol table start) to label's symbol
|-
|}

Constant table entry header :

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Constant type
|-
| 0x2
| 0x1
| Uniform ID
|}

There are (at least) 3 types of constants : 0 is boolean, 1 is integer vec4 and 2 is float24 vec4.

Corresponding constant entry formats :

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| 0x0
|-
| 0x2
| 0x1
| Uniform bool ID
|-
| 0x4
| 0x1
| Value (boolean)
|}

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| 0x1
|-
| 0x2
| 0x1
| Uniform integer vector ID
|-
| 0x4
| 0x1
| x (u8)
|-
| 0x5
| 0x1
| y (u8)
|-
| 0x6
| 0x1
| z (u8)
|-
| 0x7
| 0x1
| w (u8)
|}

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| 0x2
|-
| 0x2
| 0x1
| Uniform vector ID
|-
| 0x4
| 0x4
| x (float24)
|-
| 0x8
| 0x4
| y (float24)
|-
| 0xC
| 0x4
| z (float24)
|-
| 0x10
| 0x4
| w (float24)
|}

Output register table entry:
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0-3
| Output type (see table below)
|-
| 16-19
| Register ID
|-
| 32-35
| Output attribute component mask (e.g. 5=xz)
|}

Output types (vertex shader) :
{| class="wikitable" border="1"
|-
! ID
! Description
|-
| 0x0
| result.position
|-
| 0x1
| result.normalquat
|-
| 0x2
| result.color
|-
| 0x3
| result.texcoord0
|-
| 0x4
| result.texcoord0w
|-
| 0x5
| result.texcoord1
|-
| 0x6
| result.texcoord2
|-
| 0x7
| ?
|-
| 0x8
| result.view
|}

Uniform table entry :
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Offset (relative to DVLE symbol table start) to variable's symbol
|-
| 0x4
| 0x2
| Variable start register
|-
| 0x6
| 0x2
| Variable end register
|-
|}

Each DVLE is associated to an individual shader shader program contained in the binary blob. A single shader binary blob may contain multiple shader programs of the same kind.

Each program's constants are stored as vec4 in a uniform table. These are sent over to the GPU when changing to a give program.

== Instruction Set ==

For a description of the instruction set, see the following page : [[Shader Instruction Set]]

SHBIN

2015-01-03T01:24:39Z

Smea:

[[Category:File formats]]
== Overview ==

The SHBIN (SHader BINary) file is used to contain compiled and linked shader programs. These can include vertex shaders (typically compiled from .vsh files) and geometry shaders (typically compiled from .gsh files, though .asm have been observed).
In commercial games/apps, SHBIN files can be found as standalone files with the extension .shbin, or contained within .bcsdr files. BCSDR files use CGFX as a container, but the underlying DVLB/DVLP/DVLE structure remains unchanged.

A SHBIN's structure starts with a header, then a DVLP, then DVLE(s).

== DVLB Header ==

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Magic "DVLB"
|-
| 0x4
| 0x4
| N = number of DVLEs in SHBIN
|-
| 0x8
| 0x4*N
| DVLE offset table; each offset is a u32 relative to the start of the DVLB section
|-
|}

The DVLP file comes directly after the header.

== DVLP ==

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Magic "DVLP"
|-
| 0x4
| 0x4
| ? (Maybe a version number?)
|-
| 0x8
| 0x4
| Offset (relative to DVLP start) to the compiled shader binary blob
|-
| 0xC
| 0x4
| Size of compiled shader binary blob, in words
|-
| 0x10
| 0x4
| Offset (relative to DVLP start) to shader instruction extension table
|-
| 0x14
| 0x4
| Number of shader instruction extension table entries (each entry is 8-byte long)
|-
| 0x18
| 0x4
| Offset (relative to DVLP start) to filename symbol table
|-
|}

== DVLE ==

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Magic "DVLE"
|-
| 0x6
| 0x1
| Shader type (0x0 = vertex shader, 0x1 = geometry shader; might contain other flags)
|-
| 0x8
| 0x4
| Program's main offset in binary blob (in words)
|-
| 0xC
| 0x4
| Program's endmain offset in binary blob (in words)
|-
| 0x18
| 0x4
| Offset (relative to DVLE start) to constant table
|-
| 0x1C
| 0x4
| Number of entries in constant table (each entry is 0x14-byte long)
|-
| 0x20
| 0x4
| Offset (relative to DVLE start) to label table
|-
| 0x24
| 0x4
| Number of entries in label table (each entry is 0x10-byte long)
|-
| 0x28
| 0x4
| Offset (relative to DVLE start) to output register table
|-
| 0x2C
| 0x4
| Number of entries in output register table (each entry is 0x8-byte long)
|-
| 0x30
| 0x4
| Offset (relative to DVLE start) to uniform table
|-
| 0x34
| 0x4
| Number of entries in uniform table (each entry is 0x8-byte long)
|-
| 0x38
| 0x4
| Offset (relative to DVLE start) to symbol table
|-
| 0x3C
| 0x4
| Size of symbol table (in bytes)
|-
|}

Label table entry :
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Label ID
|-
| 0x4
| 0x4
| Offset (relative to shader program blob start) to label's location, in words
|-
| 0x8
| 0x4
| ?
|-
| 0xC
| 0x4
| Offset (relative to DVLE symbol table start) to label's symbol
|-
|}

Constant table entry header :

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Constant type
|-
| 0x2
| 0x1
| Uniform ID
|}

There are (at least) 3 types of constants : 0 is boolean, 1 is integer vec4 and 2 is float24 vec4.

Corresponding constant entry formats :

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| 0x0
|-
| 0x2
| 0x1
| Uniform bool ID
|-
| 0x4
| 0x1
| Value (boolean)
|}

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| 0x1
|-
| 0x2
| 0x1
| Uniform integer vector ID
|-
| 0x4
| 0x1
| x (u8)
|-
| 0x5
| 0x1
| y (u8)
|-
| 0x6
| 0x1
| z (u8)
|-
| 0x7
| 0x1
| w (u8)
|}

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| 0x2
|-
| 0x2
| 0x1
| Uniform vector ID
|-
| 0x4
| 0x4
| x (float24)
|-
| 0x8
| 0x4
| y (float24)
|-
| 0xC
| 0x4
| z (float24)
|-
| 0x10
| 0x4
| w (float24)
|}

Output register table entry:
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0-3
| Output type (see table below)
|-
| 16-19
| Register ID
|-
| 32-35
| Output attribute component mask (e.g. 5=xz)
|}

Output types (vertex shader) :
{| class="wikitable" border="1"
|-
! ID
! Description
|-
| 0x0
| result.position
|-
| 0x1
| result.normalquat
|-
| 0x2
| result.color
|-
| 0x3
| result.texcoord0
|-
| 0x4
| result.texcoord0w
|-
| 0x5
| result.texcoord1
|-
| 0x6
| result.texcoord2
|-
| 0x7
| ?
|-
| 0x8
| result.view
|-
| 0x9
| result.normal
|}

Uniform table entry :
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Offset (relative to DVLE symbol table start) to variable's symbol
|-
| 0x4
| 0x2
| Variable start register
|-
| 0x6
| 0x2
| Variable end register
|-
|}

Each DVLE is associated to an individual shader shader program contained in the binary blob. A single shader binary blob may contain multiple shader programs of the same kind.

Each program's constants are stored as vec4 in a uniform table. These are sent over to the GPU when changing to a give program.

== Instruction Set ==

For a description of the instruction set, see the following page : [[Shader Instruction Set]]

SHBIN

2015-01-03T01:24:16Z

Smea:

[[Category:File formats]]
== Overview ==

The SHBIN (SHader BINary) file is used to contain compiled and linked shader programs. These can include vertex shaders (typically compiled from .vsh files) and geometry shaders (typically compiled from .gsh files, though .asm have been observed).
In commercial games/apps, SHBIN files can be found as standalone files with the extension .shbin, or contained within .bcsdr files. BCSDR files use CGFX as a container, but the underlying DVLB/DVLP/DVLE structure remains unchanged.

A SHBIN's structure starts with a header, then a DVLP, then DVLE(s).

== DVLB Header ==

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Magic "DVLB"
|-
| 0x4
| 0x4
| N = number of DVLEs in SHBIN
|-
| 0x8
| 0x4*N
| DVLE offset table; each offset is a u32 relative to the start of the DVLB section
|-
|}

The DVLP file comes directly after the header.

== DVLP ==

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Magic "DVLP"
|-
| 0x4
| 0x4
| ? (Maybe a version number?)
|-
| 0x8
| 0x4
| Offset (relative to DVLP start) to the compiled shader binary blob
|-
| 0xC
| 0x4
| Size of compiled shader binary blob, in words
|-
| 0x10
| 0x4
| Offset (relative to DVLP start) to shader instruction extension table
|-
| 0x14
| 0x4
| Number of shader instruction extension table entries (each entry is 8-byte long)
|-
| 0x18
| 0x4
| Offset (relative to DVLP start) to filename symbol table
|-
|}

== DVLE ==

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Magic "DVLE"
|-
| 0x6
| 0x1
| Shader type (0x0 = vertex shader, 0x1 = geometry shader; might contain other flags)
|-
| 0x8
| 0x4
| Program's main offset in binary blob (in words)
|-
| 0xC
| 0x4
| Program's endmain offset in binary blob (in words)
|-
| 0x18
| 0x4
| Offset (relative to DVLE start) to constant table
|-
| 0x1C
| 0x4
| Number of entries in constant table (each entry is 0x14-byte long)
|-
| 0x20
| 0x4
| Offset (relative to DVLE start) to label table
|-
| 0x24
| 0x4
| Number of entries in label table (each entry is 0x10-byte long)
|-
| 0x28
| 0x4
| Offset (relative to DVLE start) to output register table
|-
| 0x2C
| 0x4
| Number of entries in output register table (each entry is 0x8-byte long)
|-
| 0x30
| 0x4
| Offset (relative to DVLE start) to uniform table
|-
| 0x34
| 0x4
| Number of entries in uniform table (each entry is 0x8-byte long)
|-
| 0x38
| 0x4
| Offset (relative to DVLE start) to symbol table
|-
| 0x3C
| 0x4
| Size of symbol table (in bytes)
|-
|}

Label table entry :
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Label ID
|-
| 0x4
| 0x4
| Offset (relative to shader program blob start) to label's location, in words
|-
| 0x8
| 0x4
| ?
|-
| 0xC
| 0x4
| Offset (relative to DVLE symbol table start) to label's symbol
|-
|}

Constant table entry header :

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Constant type
|-
| 0x2
| 0x1
| Uniform ID
|}

There are (at least) 3 types of constants : 0 is boolean, 1 is integer vec4 and 2 is float24 vec4.

Corresponding constant entry formats :

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| 0x0
|-
| 0x2
| 0x1
| Uniform bool ID
|-
| 0x4
| 0x1
| Value (boolean)
|}

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| 0x1
|-
| 0x2
| 0x1
| Uniform integer vector ID
|-
| 0x4
| 0x1
| x (u8)
|-
| 0x5
| 0x1
| y (u8)
|-
| 0x6
| 0x1
| z (u8)
|-
| 0x7
| 0x1
| w (u8)
|}

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| 0x2
|-
| 0x2
| 0x1
| Uniform vector ID
|-
| 0x4
| 0x4
| x (float24)
|-
| 0x8
| 0x4
| y (float24)
|-
| 0xC
| 0x4
| z (float24)
|-
| 0x10
| 0x4
| w (float24)
|}

Output register table entry:
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0-3
| Output type (see table below)
|-
| 16-19
| Register ID
|-
| 32-35
| Output attribute component mask (e.g. 5=xz)
|}

Output types (vertex shader) :
{| class="wikitable" border="1"
|-
! ID
! Description
|-
| 0x0
| result.position
|-
| 0x1
| result.normalquat
|-
| 0x2
| result.color
|-
| 0x3
| result.texcoord0
|-
| 0x4
| ?
|-
| 0x5
| result.texcoord1
|-
| 0x6
| result.texcoord2
|-
| 0x7
| ?
|-
| 0x8
| result.view
|-
| 0x9
| result.normal
|}

Uniform table entry :
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Offset (relative to DVLE symbol table start) to variable's symbol
|-
| 0x4
| 0x2
| Variable start register
|-
| 0x6
| 0x2
| Variable end register
|-
|}

Each DVLE is associated to an individual shader shader program contained in the binary blob. A single shader binary blob may contain multiple shader programs of the same kind.

Each program's constants are stored as vec4 in a uniform table. These are sent over to the GPU when changing to a give program.

== Instruction Set ==

For a description of the instruction set, see the following page : [[Shader Instruction Set]]

GPU/Shader Instruction Set

2015-01-02T20:20:27Z

Smea:

[[Category:GFX]]

== Overview ==
A compiled shader binary is comprised of two parts : the main instruction sequence and the operand descriptor table. These are both sent to the GPU around the same time but using separate [[GPU Commands]]. Instructions (such as format 1 instruction) may reference operand descriptors. When such is the case, the operand descriptor ID is the offset, in words, of the descriptor within the table.
Both instructions and descriptors are coded in little endian.
Basic implementations of the following specification can be found at [https://github.com/smealum/aemstro] and [https://github.com/neobrain/nihstro].
The instruction set seems to have been heavily inspired by Microsoft's vs_3_0 [http://msdn.microsoft.com/en-us/library/windows/desktop/bb172938%28v=vs.85%29.aspx].
Please note that this page is being written as the instruction set is reverse engineered; as such it may very well contain mistakes.

== Nomenclature ==

* opcode names with I appended to them are the same as their non-I version, except they use the inverted instruction format, giving 7 bits to SRC2 (and access to uniforms) and 5 bits to SRC1

* opcode names with U appended to them are the same as their non-U version, except they are executed conditionally based on the value of a uniform boolean.

* opcode names with C appended to them are the same as their non-C version, except they are executed conditionally based on a logical expression specified in the instruction.

== Instruction formats ==

Format 1 : (used for register operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0x7
| 0x5
| Source 2 register (SRC2)
|-
| 0xC
| 0x7
| Source 1 register (SRC1)
|-
| 0x13
| 0x2
| Address register index for SRC1 (IDX_1)
|-
| 0x15
| 0x5
| Destination register (DST)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 1i : (used for register operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0x7
| 0x7
| Source 2 register (SRC2)
|-
| 0xE
| 0x5
| Source 1 register (SRC1)
|-
| 0x13
| 0x2
| Address register index for SRC2 (IDX_2)
|-
| 0x15
| 0x5
| Destination register (DST)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 1u : (used for unary register operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0xC
| 0x7
| Source 1 register (SRC1)
|-
| 0x13
| 0x2
| Address register index for SRC1 (IDX_1)
|-
| 0x15
| 0x5
| Destination register (DST)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 1c : (used for comparison operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0x7
| 0x7
| Source 1 register (SRC1)
|-
| 0xE
| 0x5
| Source 2 register (SRC2)
|-
| 0x13
| 0x2
| Address register index for SRC1 (IDX_1)
|-
| 0x15
| 0x3
| Comparison operator for Y (CMPY)
|-
| 0x18
| 0x3
| Comparison operator for X (CMPX)
|-
| 0x1B
| 0x5
| Opcode
|}

Format 2 : (used for flow control instructions)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x8
| Number of instructions (NUM)
|-
| 0xA
| 0xC
| Destination offset (in words) (DST)
|-
| 0x16
| 0x2
| Condition boolean operator (CONDOP)
|-
| 0x18
| 0x1
| Y reference bit (REFY)
|-
| 0x19
| 0x1
| X reference bit (REFX)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 3 : (used for uniform-based conditional flow control instructions)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x8
| Number of instructions ? (NUM)
|-
| 0xA
| 0xC
| Destination offset (in words) (DST)
|-
| 0x16
| 0x4
| Uniform ID (BOOL/INT)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 4 : (used for SETEMIT)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x16
| 0x1
| Winding flag (FLAG_WINDING)
|-
| 0x17
| 0x1
| Primitive emit flag (FLAG_PRIMEMIT)
|-
| 0x18
| 0x2
| Vertex ID (VTXID)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 5 : (used for MAD)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x5
| Operand descriptor ID (DESC)
|-
| 0x5
| 0x5
| Source 3 register (SRC3)
|-
| 0xA
| 0x7
| Source 2 register (SRC2)
|-
| 0x11
| 0x7
| Source 1 register (SRC1)
|-
| 0x18
| 0x5
| Destination register (DST)
|-
| 0x1D
| 0x3
| Opcode
|}

Format 5i : (used for MADI)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x5
| Operand descriptor ID (DESC)
|-
| 0x5
| 0x7
| Source 3 register (SRC3)
|-
| 0xC
| 0x5
| Source 2 register (SRC2)
|-
| 0x11
| 0x7
| Source 1 register (SRC1)
|-
| 0x18
| 0x5
| Destination register (DST)
|-
| 0x1D
| 0x3
| Opcode
|}

== Instructions ==

{| class="wikitable" border="1"
|-
! Opcode
! Format
! Name
! Description
|-
| 0x00
| 1
| ADD
| Adds two vectors component by component; DST[i] = SRC1[i]+SRC2[i] for all i (modulo destination component masking)
|-
| 0x01
| 1
| DP3
| Computes dot product on 3-component vectors; DST = SRC1.SRC2
|-
| 0x02
| 1
| DP4
| Computes dot product on 4-component vectors; DST = SRC1.SRC2
|-
| 0x03
| 1
| DPH
| Computes dot product on a 4-component vector and a 3-component one with 1.0 appended to it; DST = SRC1.SRC2 (with SRC2 homogenous)
|-
| 0x04
| 1
| ???
| ?
|-
| 0x05
| 1u
| EX2
| Computes SRC1's exp component by component; DST[i] = EXP(SRC1[i]) for all i (modulo destination component masking) (base 2)
|-
| 0x06
| 1u
| LG2
| Computes SRC1's log2 component by component; DST[i] = LOG2(SRC1[i]) for all i (modulo destination component masking) (base 2)
|-
| 0x07
| 1u
| ???
| ?
|-
| 0x08
| 1
| MUL
| Multiplies two vectors component by component; DST[i] = SRC1[i].SRC2[i] for all i (modulo destination component masking)
|-
| 0x09
| 1
| SGE
| Sets output if SRC1 is greater than or equal to SRC2; DST[i] = (SRC1[i] >= SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x0A
| 1
| SLT
| Sets output if SRC1 is strictly less than SRC2; DST[i] = (SRC1[i] < SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x0B
| 1u
| FLR
| Computes SRC1's floor component by component; DST[i] = FLOOR(SRC1[i]) for all i (modulo destination component masking)
|-
| 0x0C
| 1
| MAX
| Takes the max of two vectors, component by component; DST[i] = MAX(SRC1[i], SRC2[i]) for all i (modulo destination component masking)
|-
| 0x0D
| 1
| MIN
| Takes the min of two vectors, component by component; DST[i] = MIN(SRC1[i], SRC2[i]) for all i (modulo destination component masking)
|-
| 0x0E
| 1u
| RCP
| Computes the reciprocal of the vector, component by component; DST[i] = 1/SRC1[i] for all i (modulo destination component masking)
|-
| 0x0F
| 1u
| RSQ
| Computes the reciprocal of the square root of the vector, component by component; DST[i] = 1/sqrt(SRC1[i]) for all i (modulo destination component masking)
|-
| 0x10
| ?
| ???
| ?
|-
| 0x11
| ?
| ???
| ?
|-
| 0x12
| 1u
| MOVA
| Address Register Load; sets (a0.x, a0.y, _, _) to SRC1 (cast to integer).
|-
| 0x13
| 1u
| MOV
| Moves value from one register to another; DST = SRC1.
|-
| 0x14
| ?
| ???
| ?
|-
| 0x15
| ?
| ???
| ?
|-
| 0x16
| ?
| ???
| ?
|-
| 0x17
| ?
| ???
| ?
|-
| 0x18
| 1i
| DPHI
| Computes dot product on a 4-component vector and a 3-component one with 1.0 appended to it; DST = SRC1.SRC2 (with SRC2 homogenous)
|-
| 0x19
| 1i
| ???
| ?
|-
| 0x1A
| 1i
| SGEI
| Sets output if SRC1 is greater than or equal to SRC2; DST[i] = (SRC1[i] >= SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x1B
| 1i
| SLTI
| Sets output if SRC1 is strictly less than SRC2; DST[i] = (SRC1[i] < SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x1C
| ?
| ???
| ?
|-
| 0x1D
| ?
| ???
| ?
|-
| 0x1E
| ?
| ???
| ?
|-
| 0x1F
| ?
| ???
| ?
|-
| 0x20
| ?
| ???
| ?
|-
| 0x21
| 0
| NOP
| Does litterally nothing.
|-
| 0x22
| 0
| END
| Signals the shader unit that processing for this vertex/primitive is done.
|-
| 0x23
| 2
| BREAKC
| If condition (see [[#Conditions|below]] for details) is true, then breaks out of LOOP block.
|-
| 0x24
| 2
| CALL
| Jumps to DST and executes instructions until it reaches DST+NUM instructions
|-
| 0x25
| 2
| CALLC
| If condition (see [[#Conditions|below]] for details) is true, then jumps to DST and executes instructions until it reaches DST+NUM instructions, else does nothing.
|-
| 0x26
| 3
| CALLU
| Jumps to DST and executes instructions until it reaches DST+NUM instructions if BOOL is true
|-
| 0x27
| 3
| IFU
| If condition BOOL is true, then executes instructions until DST, then jumps to DST+NUM; else, jumps to DST.
|-
| 0x28
| 2
| IFC
| If condition (see [[#Conditions|below]] for details) is true, then executes instructions until DST, then jumps to DST+NUM; else, jumps to DST
|-
| 0x29
| 3
| LOOP
| Loops over the code between itself and DST. First sets aL to INT.y, then increments aL by INT.z after each loop. Loops until aL reaches INT.y+INT.x, inclusive (that is : for(aL=INT.y;aL<=INT.y+INT.x;aL+=INT.z)). (INT is i0-i3, an integer vector uniform)
|-
| 0x2A
| 0 (no param)
| EMIT
| (geometry shader only) Emits a vertex (and primitive if FLAG_PRIMEMIT was set in the corresponding SETEMIT). SETEMIT must be called before this.
|-
| 0x2B
| 4
| SETEMIT
| (geometry shader only) Sets VTXID, FLAG_WINDING and FLAG_PRIMEMIT for the next EMIT instruction. VTXID is the ID of the vertex about to be emitted within the primitive, while FLAG_PRIMEMIT is zero if we are just emitting a single vertex and non-zero if are emitting a vertex and primitive simultaneously. FLAG_WINDING controls the output primitive's winding. Note that the output vertex buffer (which holds 4 vertices) is '''not''' cleared when the primitive is emitted, meaning that vertices from the previous primitive can be reused for the current one. (this is still a working hypothesis and unconfirmed)
|-
| 0x2C
| 2
| JMPC
| If condition (see [[#Conditions|below]] for details) is true, then jumps to DST, else does nothing.
|-
| 0x2D
| 3
| JMPU
| If condition BOOL is true, then jumps to DST, else does nothing. It seems possible that having NUM = 1 will jump if BOOL is false instead, though this is unconfirmed.
|-
| 0x2E-0x2F
| 1c
| CMP
| Sets booleans cmp.x and cmp.y based on the operand's x and y components and the CMPX and CMPY comparison operators respectively. See [[#Comparison_operator|below]] for details about operators.
|-
| 0x30-0x37
| 5i
| MADI
| Multiplies two vectors and adds a third one component by component; DST[i] = SRC3[i] + SRC2[i].SRC1[i] for all i (modulo destination component masking)
|-
| 0x38-0x3F
| 5
| MAD
| Multiplies two vectors and adds a third one component by component; DST[i] = SRC3[i] + SRC2[i].SRC1[i] for all i (modulo destination component masking)
|}

== Operand descriptors ==
Sizes below are in bits, not bytes.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Destination component mask. Bit 3 = x, 2 = y, 1 = z, 0 = w.
|-
| 0x4
| 0x1
| Source 1 negation bit
|-
| 0x5
| 0x8
| Source 1 component selector
|-
| 0xD
| 0x1
| Source 2 negation bit
|-
| 0xE
| 0x8
| Source 2 component selector
|-
| 0x16
| 0x1
| Source 3 negation bit
|-
| 0x17
| 0x8
| Source 3 component selector
|}

Component selector :
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x2
| Component 3 value
|-
| 0x2
| 0x2
| Component 2 value
|-
| 0x4
| 0x2
| Component 1 value
|-
| 0x6
| 0x2
| Component 0 value
|}

{| class="wikitable" border="1"
|-
! Value
! Component
|-
| 0x0
| x
|-
| 0x1
| y
|-
| 0x2
| z
|-
| 0x3
| w
|}

The component selector enables swizzling. For example, component selector 0x1B is equivalent to .xyzw, while 0x55 is equivalent to .yyyy.

== Relative addressing ==

There are 3 global address registers : a0.x, a0.y and aL (loop counter). For format 1 instructions, when IDX != 0, the value of the corresponding address register is added to SRC1's value.

For example, if IDX = 2, a0.y = 3 and SRC1 = c8, then instead SRC1+a0.y = c11 will be used for the instruction.

a0.x and a0.y can be set manually through the MOVA instruction. aL is set automatically by the LOOP instruction. Note that aL is still accessible and valid after exiting a LOOP block.

== Comparison operator ==

{| class="wikitable" border="1"
|-
! CMPX/CMPY raw value
! Operator name
! Expression
|-
| 0x0
| EQ
| src1 == src2
|-
| 0x1
| NE
| src1 != src2
|-
| 0x2
| LT
| src1 < src2
|-
| 0x3
| LE
| src1 <= src2
|-
| 0x4
| GT
| src1 > src2
|-
| 0x5
| GE
| src1 >= src2
|-
| 0x6
| ??
| true ?
|-
| 0x7
| ??
| true ?
|}

6 and 7 seem to always return true.

== Conditions ==

A number of format 2 instructions are executed conditionally. These conditions are based on two boolean registers which can be set with CMP : cmp.x and cmp.y.

Conditional instructions include 3 parameters : CONDOP, REFX and REFY. REFX and REFY are reference values which are tested for equality against cmp.x and cmp.y, respectively. CONDOP describes how the final truth value is constructed from the results of the two tests. There are four conditional expression formats :

{| class="wikitable" border="1"
|-
! CONDOP raw value
! Expression
! Description
|-
| 0x0
| <nowiki>cmp.x == REFX || cmp.y == REFY</nowiki>
| OR
|-
| 0x1
| <nowiki>cmp.x == REFX && cmp.y == REFY</nowiki>
| AND
|-
| 0x2
| cmp.x == REFX
| X
|-
| 0x3
| cmp.y == REFY
| Y
|}

== Registers ==
Most registers (all the ones within the 0x00-0x7F range) are float[4] vectors. There are also boolean registers (b0-b7) and integer registers (i0-i7). How the latter ones are set is as of yet unknown.

Attribute (input, RO) registers are located within the 0x0-0xF range. What data they are fed is specified by the CPU.

Output (WO) registers are also located within the 0x0-0xF range. What type of data they are contain is specified by the CPU.

Temporary (RW) register are located within the 0x10-0x1F range. They can contain any type of data.

Uniform (RO) registers are located within the 0x20-0x7F range. Their content is set by the CPU.

SRC2 being only 5 bits long rather than 7 bits like its friend SRC1, it can only access v (input attribute) and r (temporary) registers.

Registers in the 0x88-0x97 range are uniform booleans.

It appears that writing twice to the same output register can cause problems, such as the GPU hanging.

DST mapping :

{| class="wikitable" border="1"
|-
! DST raw value
! Register name
! Description
|-
| 0x0-0x6
| o0-o6
| Output registers.
|-
| 0x10-0x1F
| r0-r15
| Temporary registers.
|}

SRC mapping :

{| class="wikitable" border="1"
|-
! SRC1 raw value
! Register name
! Description
|-
| 0x0-0x7
| v0-v7
| Input attribute registers.
|-
| 0x10-0x1F
| r0-r15
| Temporary registers.
|-
| 0x20-0x7F
| c0-c95
| Vector uniform registers.
|}

Note that 5bit SRC registers (SRC2 in format 1 for example) can't access c0-c95 because they don't have enough bits.

GPU/Shader Instruction Set

2015-01-02T20:02:59Z

Smea: /* Conditions */

[[Category:GFX]]

== Overview ==
A compiled shader binary is comprised of two parts : the main instruction sequence and the operand descriptor table. These are both sent to the GPU around the same time but using separate [[GPU Commands]]. Instructions (such as format 1 instruction) may reference operand descriptors. When such is the case, the operand descriptor ID is the offset, in words, of the descriptor within the table.
Both instructions and descriptors are coded in little endian.
Basic implementations of the following specification can be found at [https://github.com/smealum/aemstro] and [https://github.com/neobrain/nihstro].
The instruction set seems to have been heavily inspired by Microsoft's vs_3_0 [http://msdn.microsoft.com/en-us/library/windows/desktop/bb172938%28v=vs.85%29.aspx].
Please note that this page is being written as the instruction set is reverse engineered; as such it may very well contain mistakes.

== Nomenclature ==

* opcode names with I appended to them are the same as their non-I version, except they use the inverted instruction format, giving 7 bits to SRC2 (and access to uniforms) and 5 bits to SRC1

* opcode names with U appended to them are the same as their non-U version, except they are executed conditionally based on the value of a uniform boolean.

* opcode names with C appended to them are the same as their non-C version, except they are executed conditionally based on a logical expression specified in the instruction.

== Instruction formats ==

Format 1 : (used for register operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0x7
| 0x5
| Source 2 register (SRC2)
|-
| 0xC
| 0x7
| Source 1 register (SRC1)
|-
| 0x13
| 0x2
| Address register index for SRC1 (IDX_1)
|-
| 0x15
| 0x5
| Destination register (DST)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 1i : (used for register operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0x7
| 0x7
| Source 2 register (SRC2)
|-
| 0xE
| 0x5
| Source 1 register (SRC1)
|-
| 0x13
| 0x2
| Address register index for SRC2 (IDX_2)
|-
| 0x15
| 0x5
| Destination register (DST)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 1u : (used for unary register operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0xC
| 0x7
| Source 1 register (SRC1)
|-
| 0x13
| 0x2
| Address register index for SRC1 (IDX_1)
|-
| 0x15
| 0x5
| Destination register (DST)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 1c : (used for comparison operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0x7
| 0x7
| Source 1 register (SRC1)
|-
| 0xE
| 0x5
| Source 2 register (SRC2)
|-
| 0x13
| 0x2
| Address register index for SRC1 (IDX_1)
|-
| 0x15
| 0x3
| Comparison operator for Y (CMPY)
|-
| 0x18
| 0x3
| Comparison operator for X (CMPX)
|-
| 0x1B
| 0x5
| Opcode
|}

Format 2 : (used for flow control instructions)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x8
| Number of instructions (NUM)
|-
| 0xA
| 0xC
| Destination offset (in words) (DST)
|-
| 0x16
| 0x2
| Condition boolean operator (CONDOP)
|-
| 0x18
| 0x1
| Y reference bit (REFY)
|-
| 0x19
| 0x1
| X reference bit (REFX)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 3 : (used for uniform-based conditional flow control instructions)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x8
| Number of instructions ? (NUM)
|-
| 0xA
| 0xC
| Destination offset (in words) (DST)
|-
| 0x16
| 0x4
| Uniform ID (BOOL/INT)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 4 : (used for SETEMIT)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x16
| 0x1
| Winding flag (FLAG_WINDING)
|-
| 0x17
| 0x1
| Primitive emit flag (FLAG_PRIMEMIT)
|-
| 0x18
| 0x2
| Vertex ID (VTXID)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 5 : (used for MAD)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x5
| Operand descriptor ID (DESC)
|-
| 0x5
| 0x5
| Source 3 register (SRC3)
|-
| 0xA
| 0x7
| Source 2 register (SRC2)
|-
| 0x11
| 0x7
| Source 1 register (SRC1)
|-
| 0x18
| 0x5
| Destination register (DST)
|-
| 0x1D
| 0x3
| Opcode
|}

Format 5i : (used for MADI)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x5
| Operand descriptor ID (DESC)
|-
| 0x5
| 0x7
| Source 3 register (SRC3)
|-
| 0xC
| 0x5
| Source 2 register (SRC2)
|-
| 0x11
| 0x7
| Source 1 register (SRC1)
|-
| 0x18
| 0x5
| Destination register (DST)
|-
| 0x1D
| 0x3
| Opcode
|}

== Instructions ==

{| class="wikitable" border="1"
|-
! Opcode
! Format
! Name
! Description
|-
| 0x00
| 1
| ADD
| Adds two vectors component by component; DST[i] = SRC1[i]+SRC2[i] for all i (modulo destination component masking)
|-
| 0x01
| 1
| DP3
| Computes dot product on 3-component vectors; DST = SRC1.SRC2
|-
| 0x02
| 1
| DP4
| Computes dot product on 4-component vectors; DST = SRC1.SRC2
|-
| 0x03
| 1
| DPH
| Computes dot product on a 4-component vector and a 3-component one with 1.0 appended to it; DST = SRC1.SRC2 (with SRC2 homogenous)
|-
| 0x04
| 1
| ???
| ?
|-
| 0x05
| 1u
| EX2
| Computes SRC1's exp component by component; DST[i] = EXP(SRC1[i]) for all i (modulo destination component masking) (base 2)
|-
| 0x06
| 1u
| LG2
| Computes SRC1's log2 component by component; DST[i] = LOG2(SRC1[i]) for all i (modulo destination component masking) (base 2)
|-
| 0x07
| 1u
| ???
| ?
|-
| 0x08
| 1
| MUL
| Multiplies two vectors component by component; DST[i] = SRC1[i].SRC2[i] for all i (modulo destination component masking)
|-
| 0x09
| 1
| SGE
| Sets output if SRC1 is greater than or equal to SRC2; DST[i] = (SRC1[i] >= SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x0A
| 1
| SLT
| Sets output if SRC1 is strictly less than SRC2; DST[i] = (SRC1[i] < SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x0B
| 1u
| FLR
| Computes SRC1's floor component by component; DST[i] = FLOOR(SRC1[i]) for all i (modulo destination component masking)
|-
| 0x0C
| 1
| MAX
| Takes the max of two vectors, component by component; DST[i] = MAX(SRC1[i], SRC2[i]) for all i (modulo destination component masking)
|-
| 0x0D
| 1
| MIN
| Takes the min of two vectors, component by component; DST[i] = MIN(SRC1[i], SRC2[i]) for all i (modulo destination component masking)
|-
| 0x0E
| 1u
| RCP
| Computes the reciprocal of the vector, component by component; DST[i] = 1/SRC1[i] for all i (modulo destination component masking)
|-
| 0x0F
| 1u
| RSQ
| Computes the reciprocal of the square root of the vector, component by component; DST[i] = 1/sqrt(SRC1[i]) for all i (modulo destination component masking)
|-
| 0x10
| ?
| ???
| ?
|-
| 0x11
| ?
| ???
| ?
|-
| 0x12
| 1u
| MOVA
| Address Register Load; sets (a0.x, a0.y, _, _) to SRC1 (cast to integer).
|-
| 0x13
| 1u
| MOV
| Moves value from one register to another; DST = SRC1.
|-
| 0x14
| ?
| ???
| ?
|-
| 0x15
| ?
| ???
| ?
|-
| 0x16
| ?
| ???
| ?
|-
| 0x17
| ?
| ???
| ?
|-
| 0x18
| 1i
| DPHI
| Computes dot product on a 4-component vector and a 3-component one with 1.0 appended to it; DST = SRC1.SRC2 (with SRC2 homogenous)
|-
| 0x19
| 1i
| ???
| ?
|-
| 0x1A
| 1i
| SGEI
| Sets output if SRC1 is greater than or equal to SRC2; DST[i] = (SRC1[i] >= SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x1B
| 1i
| SLTI
| Sets output if SRC1 is strictly less than SRC2; DST[i] = (SRC1[i] < SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x1C
| ?
| ???
| ?
|-
| 0x1D
| ?
| ???
| ?
|-
| 0x1E
| ?
| ???
| ?
|-
| 0x1F
| ?
| ???
| ?
|-
| 0x20
| ?
| ???
| ?
|-
| 0x21
| 0
| NOP
| Does litterally nothing.
|-
| 0x22
| 0
| END
| Signals the shader unit that processing for this vertex/primitive is done.
|-
| 0x23
| 2
| BREAKC
| If condition (see [[#Conditions|below]] for details) is true, then breaks out of LOOP block.
|-
| 0x24
| 2
| CALL
| Jumps to DST and executes instructions until it reaches DST+NUM instructions
|-
| 0x25
| 2
| CALLC
| If condition (see [[#Conditions|below]] for details) is true, then jumps to DST and executes instructions until it reaches DST+NUM instructions, else does nothing.
|-
| 0x26
| 3
| CALLU
| Jumps to DST and executes instructions until it reaches DST+NUM instructions if BOOL is true
|-
| 0x27
| 3
| IFU
| If condition BOOL is true, then executes instructions until DST, then jumps to DST+NUM; else, jumps to DST.
|-
| 0x28
| 2
| IFC
| If condition (see [[#Conditions|below]] for details) is true, then executes instructions until DST, then jumps to DST+NUM; else, jumps to DST
|-
| 0x29
| 3
| LOOP
| Loops over the code between itself and DST. First sets aL to INT.y, then increments aL by INT.z after each loop. Loops until aL reaches INT.y+INT.x, inclusive (that is : for(aL=INT.y;aL<=INT.y+INT.x;aL+=INT.z)). (INT is i0-i3, an integer vector uniform)
|-
| 0x2A
| 0 (no param)
| EMIT
| (geometry shader only) Emits a vertex (and primitive if FLAG_PRIMEMIT was set in the corresponding SETEMIT). SETEMIT must be called before this.
|-
| 0x2B
| 4
| SETEMIT
| (geometry shader only) Sets VTXID, FLAG_WINDING and FLAG_PRIMEMIT for the next EMIT instruction. VTXID is the ID of the vertex about to be emitted within the primitive, while FLAG_PRIMEMIT is zero if we are just emitting a single vertex and non-zero if are emitting a vertex and primitive simultaneously. FLAG_WINDING controls the output primitive's winding. Note that the output vertex buffer (which holds 4 vertices) is '''not''' cleared when the primitive is emitted, meaning that vertices from the previous primitive can be reused for the current one. (this is still a working hypothesis and unconfirmed)
|-
| 0x2C
| 2
| JMPC
| If condition (see [[#Conditions|below]] for details) is true, then jumps to DST, else does nothing.
|-
| 0x2D
| 3
| JMPU
| If condition BOOL is true, then jumps to DST, else does nothing. It seems possible that having NUM = 1 will jump if BOOL is false instead, though this is unconfirmed.
|-
| 0x2E-0x2F
| 1c
| CMP
| Sets booleans cmp.x and cmp.y based on the operand's x and y components and the CMPX and CMPY comparison operators respectively. See [[#Comparison_operator|below]] for details about operators.
|-
| 0x30-0x37
| 5i
| MADI
| Multiplies two vectors and adds a third one component by component; DST[i] = SRC3[i] + SRC2[i].SRC1[i] for all i (modulo destination component masking)
|-
| 0x38-0x3F
| 5
| MAD
| Multiplies two vectors and adds a third one component by component; DST[i] = SRC3[i] + SRC2[i].SRC1[i] for all i (modulo destination component masking)
|}

== Operand descriptors ==
Sizes below are in bits, not bytes.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Destination component mask. Bit 3 = x, 2 = y, 1 = z, 0 = w.
|-
| 0x4
| 0x1
| Source 1 negation bit
|-
| 0x5
| 0x8
| Source 1 component selector
|-
| 0xD
| 0x1
| Source 2 negation bit
|-
| 0xE
| 0x8
| Source 2 component selector
|-
| 0x16
| 0x1
| Source 3 negation bit
|-
| 0x17
| 0x8
| Source 3 component selector
|}

Component selector :
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x2
| Component 3 value
|-
| 0x2
| 0x2
| Component 2 value
|-
| 0x4
| 0x2
| Component 1 value
|-
| 0x6
| 0x2
| Component 0 value
|}

{| class="wikitable" border="1"
|-
! Value
! Component
|-
| 0x0
| x
|-
| 0x1
| y
|-
| 0x2
| z
|-
| 0x3
| w
|}

The component selector enables swizzling. For example, component selector 0x1B is equivalent to .xyzw, while 0x55 is equivalent to .yyyy.

== Relative addressing ==

There are 3 global address registers : a0.x, a0.y and aL (loop counter). For format 1 instructions, when IDX != 0, the value of the corresponding address register is added to SRC1's value.

For example, if IDX = 2, a0.y = 3 and SRC1 = c8, then instead SRC1+a0.y = c11 will be used for the instruction.

a0.x and a0.y can be set manually through the MOVA instruction. aL is set automatically by the LOOP instruction. Note that aL is still accessible and valid after exiting a LOOP block.

== Comparison operator ==

{| class="wikitable" border="1"
|-
! CMPX/CMPY raw value
! Operator name
! Expression
|-
| 0x0
| EQ
| src1 == src2
|-
| 0x1
| NE
| src1 != src2
|-
| 0x2
| LT
| src1 < src2
|-
| 0x3
| LE
| src1 <= src2
|-
| 0x4
| GT
| src1 > src2
|-
| 0x5
| GE
| src1 >= src2
|-
| 0x6
| ??
| true ?
|-
| 0x7
| ??
| true ?
|}

6 and 7 seem to always return true.

== Conditions ==

A number of format 2 instructions are executed conditionally. These conditions are based on two boolean registers which can be set with CMP : cmp.x and cmp.y.

Conditional instructions include 3 parameters : CONDOP, REFX and REFY. REFX and REFY are reference values which are tested for equality against cmp.x and cmp.y, respectively. CONDOP describes how the final truth value is constructed from the results of the two tests. There are four conditional expression formats :

{| class="wikitable" border="1"
|-
! CONDOP raw value
! Expression
! Description
|-
| 0x0
| <nowiki>cmp.x == REFX || cmp.y == REFY</nowiki>
| OR
|-
| 0x1
| <nowiki>cmp.x == REFX && cmp.y == REFY</nowiki>
| AND
|-
| 0x2
| cmp.x == REFY
| X
|-
| 0x3
| cmp.y == REFY
| Y
|}

== Registers ==
Most registers (all the ones within the 0x00-0x7F range) are float[4] vectors. There are also boolean registers (b0-b7) and integer registers (i0-i7). How the latter ones are set is as of yet unknown.

Attribute (input, RO) registers are located within the 0x0-0xF range. What data they are fed is specified by the CPU.

Output (WO) registers are also located within the 0x0-0xF range. What type of data they are contain is specified by the CPU.

Temporary (RW) register are located within the 0x10-0x1F range. They can contain any type of data.

Uniform (RO) registers are located within the 0x20-0x7F range. Their content is set by the CPU.

SRC2 being only 5 bits long rather than 7 bits like its friend SRC1, it can only access v (input attribute) and r (temporary) registers.

Registers in the 0x88-0x97 range are uniform booleans.

It appears that writing twice to the same output register can cause problems, such as the GPU hanging.

DST mapping :

{| class="wikitable" border="1"
|-
! DST raw value
! Register name
! Description
|-
| 0x0-0x6
| o0-o6
| Output registers.
|-
| 0x10-0x1F
| r0-r15
| Temporary registers.
|}

SRC mapping :

{| class="wikitable" border="1"
|-
! SRC1 raw value
! Register name
! Description
|-
| 0x0-0x7
| v0-v7
| Input attribute registers.
|-
| 0x10-0x1F
| r0-r15
| Temporary registers.
|-
| 0x20-0x7F
| c0-c95
| Vector uniform registers.
|}

Note that 5bit SRC registers (SRC2 in format 1 for example) can't access c0-c95 because they don't have enough bits.

GPU/Shader Instruction Set

2015-01-01T03:25:29Z

Smea: LRP -> MADI

[[Category:GFX]]

== Overview ==
A compiled shader binary is comprised of two parts : the main instruction sequence and the operand descriptor table. These are both sent to the GPU around the same time but using separate [[GPU Commands]]. Instructions (such as format 1 instruction) may reference operand descriptors. When such is the case, the operand descriptor ID is the offset, in words, of the descriptor within the table.
Both instructions and descriptors are coded in little endian.
Basic implementations of the following specification can be found at [https://github.com/smealum/aemstro] and [https://github.com/neobrain/nihstro].
The instruction set seems to have been heavily inspired by Microsoft's vs_3_0 [http://msdn.microsoft.com/en-us/library/windows/desktop/bb172938%28v=vs.85%29.aspx].
Please note that this page is being written as the instruction set is reverse engineered; as such it may very well contain mistakes.

== Nomenclature ==

* opcode names with I appended to them are the same as their non-I version, except they use the inverted instruction format, giving 7 bits to SRC2 (and access to uniforms) and 5 bits to SRC1

* opcode names with U appended to them are the same as their non-U version, except they are executed conditionally based on the value of a uniform boolean.

* opcode names with C appended to them are the same as their non-C version, except they are executed conditionally based on a logical expression specified in the instruction.

== Instruction formats ==

Format 1 : (used for register operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0x7
| 0x5
| Source 2 register (SRC2)
|-
| 0xC
| 0x7
| Source 1 register (SRC1)
|-
| 0x13
| 0x2
| Address register index for SRC1 (IDX_1)
|-
| 0x15
| 0x5
| Destination register (DST)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 1i : (used for register operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0x7
| 0x7
| Source 2 register (SRC2)
|-
| 0xE
| 0x5
| Source 1 register (SRC1)
|-
| 0x13
| 0x2
| Address register index for SRC2 (IDX_2)
|-
| 0x15
| 0x5
| Destination register (DST)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 1u : (used for unary register operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0xC
| 0x7
| Source 1 register (SRC1)
|-
| 0x13
| 0x2
| Address register index for SRC1 (IDX_1)
|-
| 0x15
| 0x5
| Destination register (DST)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 1c : (used for comparison operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0x7
| 0x7
| Source 1 register (SRC1)
|-
| 0xE
| 0x5
| Source 2 register (SRC2)
|-
| 0x13
| 0x2
| Address register index for SRC1 (IDX_1)
|-
| 0x15
| 0x3
| Comparison operator for Y (CMPY)
|-
| 0x18
| 0x3
| Comparison operator for X (CMPX)
|-
| 0x1B
| 0x5
| Opcode
|}

Format 2 : (used for flow control instructions)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x8
| Number of instructions (NUM)
|-
| 0xA
| 0xC
| Destination offset (in words) (DST)
|-
| 0x16
| 0x2
| Condition boolean operator (CONDOP)
|-
| 0x18
| 0x1
| Y reference bit (REFY)
|-
| 0x19
| 0x1
| X reference bit (REFX)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 3 : (used for uniform-based conditional flow control instructions)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x8
| Number of instructions ? (NUM)
|-
| 0xA
| 0xC
| Destination offset (in words) (DST)
|-
| 0x16
| 0x4
| Uniform ID (BOOL/INT)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 4 : (used for SETEMIT)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x16
| 0x1
| Winding flag (FLAG_WINDING)
|-
| 0x17
| 0x1
| Primitive emit flag (FLAG_PRIMEMIT)
|-
| 0x18
| 0x2
| Vertex ID (VTXID)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 5 : (used for MAD)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x5
| Operand descriptor ID (DESC)
|-
| 0x5
| 0x5
| Source 3 register (SRC3)
|-
| 0xA
| 0x7
| Source 2 register (SRC2)
|-
| 0x11
| 0x7
| Source 1 register (SRC1)
|-
| 0x18
| 0x5
| Destination register (DST)
|-
| 0x1D
| 0x3
| Opcode
|}

Format 5i : (used for MADI)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x5
| Operand descriptor ID (DESC)
|-
| 0x5
| 0x7
| Source 3 register (SRC3)
|-
| 0xC
| 0x5
| Source 2 register (SRC2)
|-
| 0x11
| 0x7
| Source 1 register (SRC1)
|-
| 0x18
| 0x5
| Destination register (DST)
|-
| 0x1D
| 0x3
| Opcode
|}

== Instructions ==

{| class="wikitable" border="1"
|-
! Opcode
! Format
! Name
! Description
|-
| 0x00
| 1
| ADD
| Adds two vectors component by component; DST[i] = SRC1[i]+SRC2[i] for all i (modulo destination component masking)
|-
| 0x01
| 1
| DP3
| Computes dot product on 3-component vectors; DST = SRC1.SRC2
|-
| 0x02
| 1
| DP4
| Computes dot product on 4-component vectors; DST = SRC1.SRC2
|-
| 0x03
| 1
| DPH
| Computes dot product on a 4-component vector and a 3-component one with 1.0 appended to it; DST = SRC1.SRC2 (with SRC2 homogenous)
|-
| 0x04
| 1
| ???
| ?
|-
| 0x05
| 1u
| EX2
| Computes SRC1's exp component by component; DST[i] = EXP(SRC1[i]) for all i (modulo destination component masking) (base 2)
|-
| 0x06
| 1u
| LG2
| Computes SRC1's log2 component by component; DST[i] = LOG2(SRC1[i]) for all i (modulo destination component masking) (base 2)
|-
| 0x07
| 1u
| ???
| ?
|-
| 0x08
| 1
| MUL
| Multiplies two vectors component by component; DST[i] = SRC1[i].SRC2[i] for all i (modulo destination component masking)
|-
| 0x09
| 1
| SGE
| Sets output if SRC1 is greater than or equal to SRC2; DST[i] = (SRC1[i] >= SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x0A
| 1
| SLT
| Sets output if SRC1 is strictly less than SRC2; DST[i] = (SRC1[i] < SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x0B
| 1u
| FLR
| Computes SRC1's floor component by component; DST[i] = FLOOR(SRC1[i]) for all i (modulo destination component masking)
|-
| 0x0C
| 1
| MAX
| Takes the max of two vectors, component by component; DST[i] = MAX(SRC1[i], SRC2[i]) for all i (modulo destination component masking)
|-
| 0x0D
| 1
| MIN
| Takes the min of two vectors, component by component; DST[i] = MIN(SRC1[i], SRC2[i]) for all i (modulo destination component masking)
|-
| 0x0E
| 1u
| RCP
| Computes the reciprocal of the vector, component by component; DST[i] = 1/SRC1[i] for all i (modulo destination component masking)
|-
| 0x0F
| 1u
| RSQ
| Computes the reciprocal of the square root of the vector, component by component; DST[i] = 1/sqrt(SRC1[i]) for all i (modulo destination component masking)
|-
| 0x10
| ?
| ???
| ?
|-
| 0x11
| ?
| ???
| ?
|-
| 0x12
| 1u
| MOVA
| Address Register Load; sets (a0.x, a0.y, _, _) to SRC1 (cast to integer).
|-
| 0x13
| 1u
| MOV
| Moves value from one register to another; DST = SRC1.
|-
| 0x14
| ?
| ???
| ?
|-
| 0x15
| ?
| ???
| ?
|-
| 0x16
| ?
| ???
| ?
|-
| 0x17
| ?
| ???
| ?
|-
| 0x18
| 1i
| DPHI
| Computes dot product on a 4-component vector and a 3-component one with 1.0 appended to it; DST = SRC1.SRC2 (with SRC2 homogenous)
|-
| 0x19
| 1i
| ???
| ?
|-
| 0x1A
| 1i
| SGEI
| Sets output if SRC1 is greater than or equal to SRC2; DST[i] = (SRC1[i] >= SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x1B
| 1i
| SLTI
| Sets output if SRC1 is strictly less than SRC2; DST[i] = (SRC1[i] < SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x1C
| ?
| ???
| ?
|-
| 0x1D
| ?
| ???
| ?
|-
| 0x1E
| ?
| ???
| ?
|-
| 0x1F
| ?
| ???
| ?
|-
| 0x20
| ?
| ???
| ?
|-
| 0x21
| 0
| NOP
| Does litterally nothing.
|-
| 0x22
| 0
| END
| Signals the shader unit that processing for this vertex/primitive is done.
|-
| 0x23
| 2
| BREAKC
| If condition (see [[#Conditions|below]] for details) is true, then breaks out of LOOP block.
|-
| 0x24
| 2
| CALL
| Jumps to DST and executes instructions until it reaches DST+NUM instructions
|-
| 0x25
| 2
| CALLC
| If condition (see [[#Conditions|below]] for details) is true, then jumps to DST and executes instructions until it reaches DST+NUM instructions, else does nothing.
|-
| 0x26
| 3
| CALLU
| Jumps to DST and executes instructions until it reaches DST+NUM instructions if BOOL is true
|-
| 0x27
| 3
| IFU
| If condition BOOL is true, then executes instructions until DST, then jumps to DST+NUM; else, jumps to DST.
|-
| 0x28
| 2
| IFC
| If condition (see [[#Conditions|below]] for details) is true, then executes instructions until DST, then jumps to DST+NUM; else, jumps to DST
|-
| 0x29
| 3
| LOOP
| Loops over the code between itself and DST. First sets aL to INT.y, then increments aL by INT.z after each loop. Loops until aL reaches INT.y+INT.x, inclusive (that is : for(aL=INT.y;aL<=INT.y+INT.x;aL+=INT.z)). (INT is i0-i3, an integer vector uniform)
|-
| 0x2A
| 0 (no param)
| EMIT
| (geometry shader only) Emits a vertex (and primitive if FLAG_PRIMEMIT was set in the corresponding SETEMIT). SETEMIT must be called before this.
|-
| 0x2B
| 4
| SETEMIT
| (geometry shader only) Sets VTXID, FLAG_WINDING and FLAG_PRIMEMIT for the next EMIT instruction. VTXID is the ID of the vertex about to be emitted within the primitive, while FLAG_PRIMEMIT is zero if we are just emitting a single vertex and non-zero if are emitting a vertex and primitive simultaneously. FLAG_WINDING controls the output primitive's winding. Note that the output vertex buffer (which holds 4 vertices) is '''not''' cleared when the primitive is emitted, meaning that vertices from the previous primitive can be reused for the current one. (this is still a working hypothesis and unconfirmed)
|-
| 0x2C
| 2
| JMPC
| If condition (see [[#Conditions|below]] for details) is true, then jumps to DST, else does nothing.
|-
| 0x2D
| 3
| JMPU
| If condition BOOL is true, then jumps to DST, else does nothing. It seems possible that having NUM = 1 will jump if BOOL is false instead, though this is unconfirmed.
|-
| 0x2E-0x2F
| 1c
| CMP
| Sets booleans cmp.x and cmp.y based on the operand's x and y components and the CMPX and CMPY comparison operators respectively. See [[#Comparison_operator|below]] for details about operators.
|-
| 0x30-0x37
| 5i
| MADI
| Multiplies two vectors and adds a third one component by component; DST[i] = SRC3[i] + SRC2[i].SRC1[i] for all i (modulo destination component masking)
|-
| 0x38-0x3F
| 5
| MAD
| Multiplies two vectors and adds a third one component by component; DST[i] = SRC3[i] + SRC2[i].SRC1[i] for all i (modulo destination component masking)
|}

== Operand descriptors ==
Sizes below are in bits, not bytes.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Destination component mask. Bit 3 = x, 2 = y, 1 = z, 0 = w.
|-
| 0x4
| 0x1
| Source 1 negation bit
|-
| 0x5
| 0x8
| Source 1 component selector
|-
| 0xD
| 0x1
| Source 2 negation bit
|-
| 0xE
| 0x8
| Source 2 component selector
|-
| 0x16
| 0x1
| Source 3 negation bit
|-
| 0x17
| 0x8
| Source 3 component selector
|}

Component selector :
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x2
| Component 3 value
|-
| 0x2
| 0x2
| Component 2 value
|-
| 0x4
| 0x2
| Component 1 value
|-
| 0x6
| 0x2
| Component 0 value
|}

{| class="wikitable" border="1"
|-
! Value
! Component
|-
| 0x0
| x
|-
| 0x1
| y
|-
| 0x2
| z
|-
| 0x3
| w
|}

The component selector enables swizzling. For example, component selector 0x1B is equivalent to .xyzw, while 0x55 is equivalent to .yyyy.

== Relative addressing ==

There are 3 global address registers : a0.x, a0.y and aL (loop counter). For format 1 instructions, when IDX != 0, the value of the corresponding address register is added to SRC1's value.

For example, if IDX = 2, a0.y = 3 and SRC1 = c8, then instead SRC1+a0.y = c11 will be used for the instruction.

a0.x and a0.y can be set manually through the MOVA instruction. aL is set automatically by the LOOP instruction. Note that aL is still accessible and valid after exiting a LOOP block.

== Comparison operator ==

{| class="wikitable" border="1"
|-
! CMPX/CMPY raw value
! Operator name
! Expression
|-
| 0x0
| EQ
| src1 == src2
|-
| 0x1
| NE
| src1 != src2
|-
| 0x2
| LT
| src1 < src2
|-
| 0x3
| LE
| src1 <= src2
|-
| 0x4
| GT
| src1 > src2
|-
| 0x5
| GE
| src1 >= src2
|-
| 0x6
| ??
| true ?
|-
| 0x7
| ??
| true ?
|}

6 and 7 seem to always return true.

== Conditions ==

A number of format 2 instructions are executed conditionally. These conditions are based on two boolean registers which can be set with CMP : cmp.x and cmp.y.

Conditional instructions include 3 parameters : CONDOP, REFX and REFY. REFX and REFY are reference values which are tested for equality against cmp.x and cmp.y, respectively. CONDOP describes how the final truth value is constructed from the results of the two tests. There are four conditional expression formats :

{| class="wikitable" border="1"
|-
! CONDOP raw value
! Expression
! Description
|-
| 0x0
| <nowiki>cmp.x == REFX || cmp.y == REFY</nowiki>
| OR
|-
| 0x1
| <nowiki>cmp.x == REFX && cmp.y == REFY</nowiki>
| AND
|-
| 0x2
| cmp.y == REFY
| Y
|-
| 0x3
| cmp.x == REFX
| X
|}

== Registers ==
Most registers (all the ones within the 0x00-0x7F range) are float[4] vectors. There are also boolean registers (b0-b7) and integer registers (i0-i7). How the latter ones are set is as of yet unknown.

Attribute (input, RO) registers are located within the 0x0-0xF range. What data they are fed is specified by the CPU.

Output (WO) registers are also located within the 0x0-0xF range. What type of data they are contain is specified by the CPU.

Temporary (RW) register are located within the 0x10-0x1F range. They can contain any type of data.

Uniform (RO) registers are located within the 0x20-0x7F range. Their content is set by the CPU.

SRC2 being only 5 bits long rather than 7 bits like its friend SRC1, it can only access v (input attribute) and r (temporary) registers.

Registers in the 0x88-0x97 range are uniform booleans.

It appears that writing twice to the same output register can cause problems, such as the GPU hanging.

DST mapping :

{| class="wikitable" border="1"
|-
! DST raw value
! Register name
! Description
|-
| 0x0-0x6
| o0-o6
| Output registers.
|-
| 0x10-0x1F
| r0-r15
| Temporary registers.
|}

SRC mapping :

{| class="wikitable" border="1"
|-
! SRC1 raw value
! Register name
! Description
|-
| 0x0-0x7
| v0-v7
| Input attribute registers.
|-
| 0x10-0x1F
| r0-r15
| Temporary registers.
|-
| 0x20-0x7F
| c0-c95
| Vector uniform registers.
|}

Note that 5bit SRC registers (SRC2 in format 1 for example) can't access c0-c95 because they don't have enough bits.

News

2014-12-25T16:37:37Z

Smea:

<noinclude>
==Adding an item==
* Log in to the wiki. Editing is disabled if you don't have an account.
* Add the news event to the top of the list, using this format for the date: <tt><nowiki>'''</nowiki>{{#time: d F y}}<nowiki>''' </nowiki></tt>. Please include the application's creator, version number, and a link to a page on 3DBrew about the application. No external links please.
* '''Move the last entry to the [[:News/Archive|news archive]]. There should be no more than 4 entrees in the list.'''

==Archives==
For older news, see the [[:News/Archive|news archive]].

=== News ===
</noinclude>
*'''24 December 14''' Smea has released [[Ninjhax]] 1.1.
*'''11 December 14''' Nintendo released system update [[9.4.0-21]].
*'''8 December 14''' Nintendo released system update [[9.3.0-21]], which partially fixes [[Ninjhax]].
*'''20 November 14''' Smea has released [[Ninjhax]], the first public [[Homebrew Exploits|homebrew exploit]] compatible with system-versions [[4.0.0-7]]-[[9.2.0-20]].

User talk:Luigi2us

2014-12-23T06:27:14Z

Smea: Created page with "please only name registers in "GPU Internal Registers" if the contents are properly understood and documented. there's no point in copy-pasting official reg names. thanks ! --~~~~"

please only name registers in "GPU Internal Registers" if the contents are properly understood and documented. there's no point in copy-pasting official reg names. thanks ! --[[User:Smea|Smea]] 08:27, 23 December 2014 (CET)

GPU/Internal Registers

2014-12-18T05:04:13Z

Smea: GPUREG_*SH_CODE_CONFIG => GPUREG_*SH_CODETRANSFER_CONFIG, GPUREG_*SH_CODETRANSFER_END

[[Category:GFX]]
(this page is hugely WIP)

== 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.

== 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_GSH_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_DATA|GPUREG_VSH_FLOATUNIFORM_DATA]] so that a consecutively writing command based at 02C0 will write its first parameter to [[#GPUREG_VSH_FLOATUNIFORM_CONFIG|GPUREG_VSH_FLOATUNIFORM_CONFIG]] and ever subsequent ones to [[#GPUREG_VSH_FLOATUNIFORM_DATA|GPUREG_VSH_FLOATUNIFORM_DATA]]

== Register list ==

{| class="wikitable" border="1"
! Register ID
! Register name
! Notes
|-
| 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]]
|
|-
| 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]]
|
|-
| 0040
| [[#GPUREG_FACECULLING_CONFIG|GPUREG_FACECULLING_CONFIG]]
|
|-
| 0041
| [[#GPUREG_0041|GPUREG_0041]]
|
|-
| 0042
| [[#GPUREG_0042|GPUREG_0042]]
|
|-
| 0043
| [[#GPUREG_0043|GPUREG_0043]]
|
|-
| 0044
| [[#GPUREG_0044|GPUREG_0044]]
|
|-
| 0045
| [[#GPUREG_0045|GPUREG_0045]]
|
|-
| 0046
| [[#GPUREG_0046|GPUREG_0046]]
|
|-
| 0047
| [[#GPUREG_0047|GPUREG_0047]]
|
|-
| 0048
| [[#GPUREG_0048|GPUREG_0048]]
|
|-
| 0049
| [[#GPUREG_0049|GPUREG_0049]]
|
|-
| 004A
| [[#GPUREG_004A|GPUREG_004A]]
|
|-
| 004B
| [[#GPUREG_004B|GPUREG_004B]]
|
|-
| 004C
| [[#GPUREG_004C|GPUREG_004C]]
|
|-
| 004D
| [[#GPUREG_DEPTHRANGE_NEAR|GPUREG_DEPTHRANGE_NEAR]]
|
|-
| 004E
| [[#GPUREG_DEPTHRANGE_FAR|GPUREG_DEPTHRANGE_FAR]]
|
|-
| 004F
| [[#GPUREG_SH_OUTMAP_TOTAL|GPUREG_SH_OUTMAP_TOTAL]]
|
|-
| 0050
| [[#GPUREG_SH_OUTMAP_O0|GPUREG_SH_OUTMAP_O0]]
|
|-
| 0051
| [[#GPUREG_SH_OUTMAP_O1|GPUREG_SH_OUTMAP_O1]]
|
|-
| 0052
| [[#GPUREG_SH_OUTMAP_O2|GPUREG_SH_OUTMAP_O2]]
|
|-
| 0053
| [[#GPUREG_SH_OUTMAP_O3|GPUREG_SH_OUTMAP_O3]]
|
|-
| 0054
| [[#GPUREG_SH_OUTMAP_O4|GPUREG_SH_OUTMAP_O4]]
|
|-
| 0055
| [[#GPUREG_SH_OUTMAP_O5|GPUREG_SH_OUTMAP_O5]]
|
|-
| 0056
| [[#GPUREG_SH_OUTMAP_O6|GPUREG_SH_OUTMAP_O6]]
|
|-
| 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_0061|GPUREG_0061]]
|
|-
| 0062
| [[#GPUREG_0062|GPUREG_0062]]
|
|-
| 0063
| [[#GPUREG_0063|GPUREG_0063]]
|
|-
| 0064
| [[#GPUREG_0064|GPUREG_0064]]
|
|-
| 0065
| [[#GPUREG_SCISSORTEST_MODE|GPUREG_SCISSORTEST_MODE]]
|
|-
| 0066
| [[#GPUREG_SCISSORTEST_POS|GPUREG_SCISSORTEST_POS]]
|
|-
| 0067
| [[#GPUREG_SCISSORTEST_DIM|GPUREG_SCISSORTEST_DIM]]
|
|-
| 0068
| [[#GPUREG_0068|GPUREG_0068]]
|
|-
| 0069
| [[#GPUREG_0069|GPUREG_0069]]
|
|-
| 006A
| [[#GPUREG_006A|GPUREG_006A]]
|
|-
| 006B
| [[#GPUREG_006B|GPUREG_006B]]
|
|-
| 006C
| [[#GPUREG_006C|GPUREG_006C]]
|
|-
| 006D
| [[#GPUREG_006D|GPUREG_006D]]
|
|-
| 006E
| [[#GPUREG_006E|GPUREG_006E]]
|
|-
| 006F
| [[#GPUREG_006F|GPUREG_006F]]
|
|-
| 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]]
|
|-
| 0080
| [[#GPUREG_TEXUNITS_CONFIG|GPUREG_TEXUNITS_CONFIG]]
|
|-
| 0081
| [[#GPUREG_0081|GPUREG_0081]]
|
|-
| 0082
| [[#GPUREG_TEXUNIT0_DIM|GPUREG_TEXUNIT0_DIM]]
|
|-
| 0083
| [[#GPUREG_TEXUNIT0_PARAM|GPUREG_TEXUNIT0_PARAM]]
|
|-
| 0084
| [[#GPUREG_0084|GPUREG_0084]]
|
|-
| 0085
| [[#GPUREG_TEXUNIT0_LOC|GPUREG_TEXUNIT0_LOC]]
|
|-
| 0086
| [[#GPUREG_0086|GPUREG_0086]]
|
|-
| 0087
| [[#GPUREG_0087|GPUREG_0087]]
|
|-
| 0088
| [[#GPUREG_0088|GPUREG_0088]]
|
|-
| 0089
| [[#GPUREG_0089|GPUREG_0089]]
|
|-
| 008A
| [[#GPUREG_008A|GPUREG_008A]]
|
|-
| 008B
| [[#GPUREG_008B|GPUREG_008B]]
|
|-
| 008C
| [[#GPUREG_008C|GPUREG_008C]]
|
|-
| 008D
| [[#GPUREG_008D|GPUREG_008D]]
|
|-
| 008E
| [[#GPUREG_TEXUNIT0_TYPE|GPUREG_TEXUNIT0_TYPE]]
|
|-
| 008F
| [[#GPUREG_008F|GPUREG_008F]]
|
|-
| 0090
| [[#GPUREG_0090|GPUREG_0090]]
|
|-
| 0091
| [[#GPUREG_0091|GPUREG_0091]]
|
|-
| 0092
| [[#GPUREG_TEXUNIT1_DIM|GPUREG_TEXUNIT1_DIM]]
|
|-
| 0093
| [[#GPUREG_TEXUNIT1_PARAM|GPUREG_TEXUNIT1_PARAM]]
|
|-
| 0094
| [[#GPUREG_0094|GPUREG_0094]]
|
|-
| 0095
| [[#GPUREG_TEXUNIT1_LOC|GPUREG_TEXUNIT1_LOC]]
|
|-
| 0096
| [[#GPUREG_TEXUNIT1_TYPE|GPUREG_TEXUNIT1_TYPE]]
|
|-
| 0097
| [[#GPUREG_0097|GPUREG_0097]]
|
|-
| 0098
| [[#GPUREG_0098|GPUREG_0098]]
|
|-
| 0099
| [[#GPUREG_0099|GPUREG_0099]]
|
|-
| 009A
| [[#GPUREG_TEXUNIT2_DIM|GPUREG_TEXUNIT2_DIM]]
|
|-
| 009B
| [[#GPUREG_TEXUNIT2_PARAM|GPUREG_TEXUNIT2_PARAM]]
|
|-
| 009C
| [[#GPUREG_009C|GPUREG_009C]]
|
|-
| 009D
| [[#GPUREG_TEXUNIT2_LOC|GPUREG_TEXUNIT2_LOC]]
|
|-
| 009E
| [[#GPUREG_TEXUNIT2_TYPE|GPUREG_TEXUNIT2_TYPE]]
|
|-
| 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_00A8|GPUREG_00A8]]
|
|-
| 00A9
| [[#GPUREG_00A9|GPUREG_00A9]]
|
|-
| 00AA
| [[#GPUREG_00AA|GPUREG_00AA]]
|
|-
| 00AB
| [[#GPUREG_00AB|GPUREG_00AB]]
|
|-
| 00AC
| [[#GPUREG_00AC|GPUREG_00AC]]
|
|-
| 00AD
| [[#GPUREG_00AD|GPUREG_00AD]]
|
|-
| 00AE
| [[#GPUREG_00AE|GPUREG_00AE]]
|
|-
| 00AF
| [[#GPUREG_00AF|GPUREG_00AF]]
|
|-
| 00B0
| [[#GPUREG_00B0|GPUREG_00B0]]
|
|-
| 00B1
| [[#GPUREG_00B1|GPUREG_00B1]]
|
|-
| 00B2
| [[#GPUREG_00B2|GPUREG_00B2]]
|
|-
| 00B3
| [[#GPUREG_00B3|GPUREG_00B3]]
|
|-
| 00B4
| [[#GPUREG_00B4|GPUREG_00B4]]
|
|-
| 00B5
| [[#GPUREG_00B5|GPUREG_00B5]]
|
|-
| 00B6
| [[#GPUREG_00B6|GPUREG_00B6]]
|
|-
| 00B7
| [[#GPUREG_00B7|GPUREG_00B7]]
|
|-
| 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_TEXENV0_CONFIG0|GPUREG_TEXENV0_CONFIG0]]
|
|-
| 00C1
| [[#GPUREG_TEXENV0_CONFIG1|GPUREG_TEXENV0_CONFIG1]]
|
|-
| 00C2
| [[#GPUREG_TEXENV0_CONFIG2|GPUREG_TEXENV0_CONFIG2]]
|
|-
| 00C3
| [[#GPUREG_TEXENV0_CONFIG3|GPUREG_TEXENV0_CONFIG3]]
|
|-
| 00C4
| [[#GPUREG_TEXENV0_CONFIG4|GPUREG_TEXENV0_CONFIG4]]
|
|-
| 00C5
| [[#GPUREG_00C5|GPUREG_00C5]]
|
|-
| 00C6
| [[#GPUREG_00C6|GPUREG_00C6]]
|
|-
| 00C7
| [[#GPUREG_00C7|GPUREG_00C7]]
|
|-
| 00C8
| [[#GPUREG_TEXENV1_CONFIG0|GPUREG_TEXENV1_CONFIG0]]
|
|-
| 00C9
| [[#GPUREG_TEXENV1_CONFIG1|GPUREG_TEXENV1_CONFIG1]]
|
|-
| 00CA
| [[#GPUREG_TEXENV1_CONFIG2|GPUREG_TEXENV1_CONFIG2]]
|
|-
| 00CB
| [[#GPUREG_TEXENV1_CONFIG3|GPUREG_TEXENV1_CONFIG3]]
|
|-
| 00CC
| [[#GPUREG_TEXENV1_CONFIG4|GPUREG_TEXENV1_CONFIG4]]
|
|-
| 00CD
| [[#GPUREG_00CD|GPUREG_00CD]]
|
|-
| 00CE
| [[#GPUREG_00CE|GPUREG_00CE]]
|
|-
| 00CF
| [[#GPUREG_00CF|GPUREG_00CF]]
|
|-
| 00D0
| [[#GPUREG_TEXENV2_CONFIG0|GPUREG_TEXENV2_CONFIG0]]
|
|-
| 00D1
| [[#GPUREG_TEXENV2_CONFIG1|GPUREG_TEXENV2_CONFIG1]]
|
|-
| 00D2
| [[#GPUREG_TEXENV2_CONFIG2|GPUREG_TEXENV2_CONFIG2]]
|
|-
| 00D3
| [[#GPUREG_TEXENV2_CONFIG3|GPUREG_TEXENV2_CONFIG3]]
|
|-
| 00D4
| [[#GPUREG_TEXENV2_CONFIG4|GPUREG_TEXENV2_CONFIG4]]
|
|-
| 00D5
| [[#GPUREG_00D5|GPUREG_00D5]]
|
|-
| 00D6
| [[#GPUREG_00D6|GPUREG_00D6]]
|
|-
| 00D7
| [[#GPUREG_00D7|GPUREG_00D7]]
|
|-
| 00D8
| [[#GPUREG_TEXENV3_CONFIG0|GPUREG_TEXENV3_CONFIG0]]
|
|-
| 00D9
| [[#GPUREG_TEXENV3_CONFIG1|GPUREG_TEXENV3_CONFIG1]]
|
|-
| 00DA
| [[#GPUREG_TEXENV3_CONFIG2|GPUREG_TEXENV3_CONFIG2]]
|
|-
| 00DB
| [[#GPUREG_TEXENV3_CONFIG3|GPUREG_TEXENV3_CONFIG3]]
|
|-
| 00DC
| [[#GPUREG_TEXENV3_CONFIG4|GPUREG_TEXENV3_CONFIG4]]
|
|-
| 00DD
| [[#GPUREG_00DD|GPUREG_00DD]]
|
|-
| 00DE
| [[#GPUREG_00DE|GPUREG_00DE]]
|
|-
| 00DF
| [[#GPUREG_00DF|GPUREG_00DF]]
|
|-
| 00E0
| [[#GPUREG_00E0|GPUREG_00E0]]
|
|-
| 00E1
| [[#GPUREG_00E1|GPUREG_00E1]]
|
|-
| 00E2
| [[#GPUREG_00E2|GPUREG_00E2]]
|
|-
| 00E3
| [[#GPUREG_00E3|GPUREG_00E3]]
|
|-
| 00E4
| [[#GPUREG_00E4|GPUREG_00E4]]
|
|-
| 00E5
| [[#GPUREG_00E5|GPUREG_00E5]]
|
|-
| 00E6
| [[#GPUREG_00E6|GPUREG_00E6]]
|
|-
| 00E7
| [[#GPUREG_00E7|GPUREG_00E7]]
|
|-
| 00E8
| [[#GPUREG_00E8|GPUREG_00E8]]
|
|-
| 00E9
| [[#GPUREG_00E9|GPUREG_00E9]]
|
|-
| 00EA
| [[#GPUREG_00EA|GPUREG_00EA]]
|
|-
| 00EB
| [[#GPUREG_00EB|GPUREG_00EB]]
|
|-
| 00EC
| [[#GPUREG_00EC|GPUREG_00EC]]
|
|-
| 00ED
| [[#GPUREG_00ED|GPUREG_00ED]]
|
|-
| 00EE
| [[#GPUREG_00EE|GPUREG_00EE]]
|
|-
| 00EF
| [[#GPUREG_00EF|GPUREG_00EF]]
|
|-
| 00F0
| [[#GPUREG_TEXENV4_CONFIG0|GPUREG_TEXENV4_CONFIG0]]
|
|-
| 00F1
| [[#GPUREG_TEXENV4_CONFIG1|GPUREG_TEXENV4_CONFIG1]]
|
|-
| 00F2
| [[#GPUREG_TEXENV4_CONFIG2|GPUREG_TEXENV4_CONFIG2]]
|
|-
| 00F3
| [[#GPUREG_TEXENV4_CONFIG3|GPUREG_TEXENV4_CONFIG3]]
|
|-
| 00F4
| [[#GPUREG_TEXENV4_CONFIG4|GPUREG_TEXENV4_CONFIG4]]
|
|-
| 00F5
| [[#GPUREG_00F5|GPUREG_00F5]]
|
|-
| 00F6
| [[#GPUREG_00F6|GPUREG_00F6]]
|
|-
| 00F7
| [[#GPUREG_00F7|GPUREG_00F7]]
|
|-
| 00F8
| [[#GPUREG_TEXENV5_CONFIG0|GPUREG_TEXENV5_CONFIG0]]
|
|-
| 00F9
| [[#GPUREG_TEXENV5_CONFIG1|GPUREG_TEXENV5_CONFIG1]]
|
|-
| 00FA
| [[#GPUREG_TEXENV5_CONFIG2|GPUREG_TEXENV5_CONFIG2]]
|
|-
| 00FB
| [[#GPUREG_TEXENV5_CONFIG3|GPUREG_TEXENV5_CONFIG3]]
|
|-
| 00FC
| [[#GPUREG_TEXENV5_CONFIG4|GPUREG_TEXENV5_CONFIG4]]
|
|-
| 00FD
| [[#GPUREG_00FD|GPUREG_00FD]]
|
|-
| 00FE
| [[#GPUREG_00FE|GPUREG_00FE]]
|
|-
| 00FF
| [[#GPUREG_00FF|GPUREG_00FF]]
|
|-
| 0100
| [[#GPUREG_COLOROUTPUT_CONFIG|GPUREG_COLOROUTPUT_CONFIG]]
| ?
|-
| 0101
| [[#GPUREG_BLEND_CONFIG|GPUREG_BLEND_CONFIG]]
|
|-
| 0102
| [[#GPUREG_COLORLOGICOP_CONFIG|GPUREG_COLORLOGICOP_CONFIG]]
|
|-
| 0103
| [[#GPUREG_BLEND_COLOR|GPUREG_BLEND_COLOR]]
|
|-
| 0104
| [[#GPUREG_ALPHATEST_CONFIG|GPUREG_ALPHATEST_CONFIG]]
|
|-
| 0105
| [[#GPUREG_STENCILTEST_CONFIG|GPUREG_STENCILTEST_CONFIG]]
|
|-
| 0106
| [[#GPUREG_STENCILOP_CONFIG|GPUREG_STENCILOP_CONFIG]]
|
|-
| 0107
| [[#GPUREG_DEPTHTEST_CONFIG|GPUREG_DEPTHTEST_CONFIG]]
|
|-
| 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_0110|GPUREG_0110]]
|
|-
| 0111
| [[#GPUREG_0111|GPUREG_0111]]
|
|-
| 0112
| [[#GPUREG_0112|GPUREG_0112]]
|
|-
| 0113
| [[#GPUREG_0113|GPUREG_0113]]
|
|-
| 0114
| [[#GPUREG_0114|GPUREG_0114]]
|
|-
| 0115
| [[#GPUREG_0115|GPUREG_0115]]
|
|-
| 0116
| [[#GPUREG_DEPTHBUFFER_FORMAT|GPUREG_DEPTHBUFFER_FORMAT]]
|
|-
| 0117
| [[#GPUREG_COLORBUFFER_FORMAT|GPUREG_COLORBUFFER_FORMAT]]
|
|-
| 0118
| [[#GPUREG_0118|GPUREG_0118]]
|
|-
| 0119
| [[#GPUREG_0119|GPUREG_0119]]
|
|-
| 011A
| [[#GPUREG_011A|GPUREG_011A]]
|
|-
| 011B
| [[#GPUREG_011B|GPUREG_011B]]
|
|-
| 011C
| [[#GPUREG_DEPTHBUFFER_LOC|GPUREG_DEPTHBUFFER_LOC]]
|
|-
| 011D
| [[#GPUREG_COLORBUFFER_LOC|GPUREG_COLORBUFFER_LOC]]
|
|-
| 011E
| [[#GPUREG_OUTBUFFER_DIM|GPUREG_OUTBUFFER_DIM]]
|
|-
| 011F
| [[#GPUREG_011F|GPUREG_011F]]
|
|-
| 0120
| [[#GPUREG_0120|GPUREG_0120]]
|
|-
| 0121
| [[#GPUREG_0121|GPUREG_0121]]
|
|-
| 0122
| [[#GPUREG_0122|GPUREG_0122]]
|
|-
| 0123
| [[#GPUREG_0123|GPUREG_0123]]
|
|-
| 0124
| [[#GPUREG_0124|GPUREG_0124]]
|
|-
| 0125
| [[#GPUREG_0125|GPUREG_0125]]
|
|-
| 0126
| [[#GPUREG_0126|GPUREG_0126]]
|
|-
| 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_0130|GPUREG_0130]]
|
|-
| 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]]
|
|-
| 0140
| [[#GPUREG_0140|GPUREG_0140]]
|
|-
| 0141
| [[#GPUREG_0141|GPUREG_0141]]
|
|-
| 0142
| [[#GPUREG_0142|GPUREG_0142]]
|
|-
| 0143
| [[#GPUREG_0143|GPUREG_0143]]
|
|-
| 0144
| [[#GPUREG_0144|GPUREG_0144]]
|
|-
| 0145
| [[#GPUREG_0145|GPUREG_0145]]
|
|-
| 0146
| [[#GPUREG_0146|GPUREG_0146]]
|
|-
| 0147
| [[#GPUREG_0147|GPUREG_0147]]
|
|-
| 0148
| [[#GPUREG_0148|GPUREG_0148]]
|
|-
| 0149
| [[#GPUREG_0149|GPUREG_0149]]
|
|-
| 014A
| [[#GPUREG_014A|GPUREG_014A]]
|
|-
| 014B
| [[#GPUREG_014B|GPUREG_014B]]
|
|-
| 014C
| [[#GPUREG_014C|GPUREG_014C]]
|
|-
| 014D
| [[#GPUREG_014D|GPUREG_014D]]
|
|-
| 014E
| [[#GPUREG_014E|GPUREG_014E]]
|
|-
| 014F
| [[#GPUREG_014F|GPUREG_014F]]
|
|-
| 0150
| [[#GPUREG_0150|GPUREG_0150]]
|
|-
| 0151
| [[#GPUREG_0151|GPUREG_0151]]
|
|-
| 0152
| [[#GPUREG_0152|GPUREG_0152]]
|
|-
| 0153
| [[#GPUREG_0153|GPUREG_0153]]
|
|-
| 0154
| [[#GPUREG_0154|GPUREG_0154]]
|
|-
| 0155
| [[#GPUREG_0155|GPUREG_0155]]
|
|-
| 0156
| [[#GPUREG_0156|GPUREG_0156]]
|
|-
| 0157
| [[#GPUREG_0157|GPUREG_0157]]
|
|-
| 0158
| [[#GPUREG_0158|GPUREG_0158]]
|
|-
| 0159
| [[#GPUREG_0159|GPUREG_0159]]
|
|-
| 015A
| [[#GPUREG_015A|GPUREG_015A]]
|
|-
| 015B
| [[#GPUREG_015B|GPUREG_015B]]
|
|-
| 015C
| [[#GPUREG_015C|GPUREG_015C]]
|
|-
| 015D
| [[#GPUREG_015D|GPUREG_015D]]
|
|-
| 015E
| [[#GPUREG_015E|GPUREG_015E]]
|
|-
| 015F
| [[#GPUREG_015F|GPUREG_015F]]
|
|-
| 0160
| [[#GPUREG_0160|GPUREG_0160]]
|
|-
| 0161
| [[#GPUREG_0161|GPUREG_0161]]
|
|-
| 0162
| [[#GPUREG_0162|GPUREG_0162]]
|
|-
| 0163
| [[#GPUREG_0163|GPUREG_0163]]
|
|-
| 0164
| [[#GPUREG_0164|GPUREG_0164]]
|
|-
| 0165
| [[#GPUREG_0165|GPUREG_0165]]
|
|-
| 0166
| [[#GPUREG_0166|GPUREG_0166]]
|
|-
| 0167
| [[#GPUREG_0167|GPUREG_0167]]
|
|-
| 0168
| [[#GPUREG_0168|GPUREG_0168]]
|
|-
| 0169
| [[#GPUREG_0169|GPUREG_0169]]
|
|-
| 016A
| [[#GPUREG_016A|GPUREG_016A]]
|
|-
| 016B
| [[#GPUREG_016B|GPUREG_016B]]
|
|-
| 016C
| [[#GPUREG_016C|GPUREG_016C]]
|
|-
| 016D
| [[#GPUREG_016D|GPUREG_016D]]
|
|-
| 016E
| [[#GPUREG_016E|GPUREG_016E]]
|
|-
| 016F
| [[#GPUREG_016F|GPUREG_016F]]
|
|-
| 0170
| [[#GPUREG_0170|GPUREG_0170]]
|
|-
| 0171
| [[#GPUREG_0171|GPUREG_0171]]
|
|-
| 0172
| [[#GPUREG_0172|GPUREG_0172]]
|
|-
| 0173
| [[#GPUREG_0173|GPUREG_0173]]
|
|-
| 0174
| [[#GPUREG_0174|GPUREG_0174]]
|
|-
| 0175
| [[#GPUREG_0175|GPUREG_0175]]
|
|-
| 0176
| [[#GPUREG_0176|GPUREG_0176]]
|
|-
| 0177
| [[#GPUREG_0177|GPUREG_0177]]
|
|-
| 0178
| [[#GPUREG_0178|GPUREG_0178]]
|
|-
| 0179
| [[#GPUREG_0179|GPUREG_0179]]
|
|-
| 017A
| [[#GPUREG_017A|GPUREG_017A]]
|
|-
| 017B
| [[#GPUREG_017B|GPUREG_017B]]
|
|-
| 017C
| [[#GPUREG_017C|GPUREG_017C]]
|
|-
| 017D
| [[#GPUREG_017D|GPUREG_017D]]
|
|-
| 017E
| [[#GPUREG_017E|GPUREG_017E]]
|
|-
| 017F
| [[#GPUREG_017F|GPUREG_017F]]
|
|-
| 0180
| [[#GPUREG_0180|GPUREG_0180]]
|
|-
| 0181
| [[#GPUREG_0181|GPUREG_0181]]
|
|-
| 0182
| [[#GPUREG_0182|GPUREG_0182]]
|
|-
| 0183
| [[#GPUREG_0183|GPUREG_0183]]
|
|-
| 0184
| [[#GPUREG_0184|GPUREG_0184]]
|
|-
| 0185
| [[#GPUREG_0185|GPUREG_0185]]
|
|-
| 0186
| [[#GPUREG_0186|GPUREG_0186]]
|
|-
| 0187
| [[#GPUREG_0187|GPUREG_0187]]
|
|-
| 0188
| [[#GPUREG_0188|GPUREG_0188]]
|
|-
| 0189
| [[#GPUREG_0189|GPUREG_0189]]
|
|-
| 018A
| [[#GPUREG_018A|GPUREG_018A]]
|
|-
| 018B
| [[#GPUREG_018B|GPUREG_018B]]
|
|-
| 018C
| [[#GPUREG_018C|GPUREG_018C]]
|
|-
| 018D
| [[#GPUREG_018D|GPUREG_018D]]
|
|-
| 018E
| [[#GPUREG_018E|GPUREG_018E]]
|
|-
| 018F
| [[#GPUREG_018F|GPUREG_018F]]
|
|-
| 0190
| [[#GPUREG_0190|GPUREG_0190]]
|
|-
| 0191
| [[#GPUREG_0191|GPUREG_0191]]
|
|-
| 0192
| [[#GPUREG_0192|GPUREG_0192]]
|
|-
| 0193
| [[#GPUREG_0193|GPUREG_0193]]
|
|-
| 0194
| [[#GPUREG_0194|GPUREG_0194]]
|
|-
| 0195
| [[#GPUREG_0195|GPUREG_0195]]
|
|-
| 0196
| [[#GPUREG_0196|GPUREG_0196]]
|
|-
| 0197
| [[#GPUREG_0197|GPUREG_0197]]
|
|-
| 0198
| [[#GPUREG_0198|GPUREG_0198]]
|
|-
| 0199
| [[#GPUREG_0199|GPUREG_0199]]
|
|-
| 019A
| [[#GPUREG_019A|GPUREG_019A]]
|
|-
| 019B
| [[#GPUREG_019B|GPUREG_019B]]
|
|-
| 019C
| [[#GPUREG_019C|GPUREG_019C]]
|
|-
| 019D
| [[#GPUREG_019D|GPUREG_019D]]
|
|-
| 019E
| [[#GPUREG_019E|GPUREG_019E]]
|
|-
| 019F
| [[#GPUREG_019F|GPUREG_019F]]
|
|-
| 01A0
| [[#GPUREG_01A0|GPUREG_01A0]]
|
|-
| 01A1
| [[#GPUREG_01A1|GPUREG_01A1]]
|
|-
| 01A2
| [[#GPUREG_01A2|GPUREG_01A2]]
|
|-
| 01A3
| [[#GPUREG_01A3|GPUREG_01A3]]
|
|-
| 01A4
| [[#GPUREG_01A4|GPUREG_01A4]]
|
|-
| 01A5
| [[#GPUREG_01A5|GPUREG_01A5]]
|
|-
| 01A6
| [[#GPUREG_01A6|GPUREG_01A6]]
|
|-
| 01A7
| [[#GPUREG_01A7|GPUREG_01A7]]
|
|-
| 01A8
| [[#GPUREG_01A8|GPUREG_01A8]]
|
|-
| 01A9
| [[#GPUREG_01A9|GPUREG_01A9]]
|
|-
| 01AA
| [[#GPUREG_01AA|GPUREG_01AA]]
|
|-
| 01AB
| [[#GPUREG_01AB|GPUREG_01AB]]
|
|-
| 01AC
| [[#GPUREG_01AC|GPUREG_01AC]]
|
|-
| 01AD
| [[#GPUREG_01AD|GPUREG_01AD]]
|
|-
| 01AE
| [[#GPUREG_01AE|GPUREG_01AE]]
|
|-
| 01AF
| [[#GPUREG_01AF|GPUREG_01AF]]
|
|-
| 01B0
| [[#GPUREG_01B0|GPUREG_01B0]]
|
|-
| 01B1
| [[#GPUREG_01B1|GPUREG_01B1]]
|
|-
| 01B2
| [[#GPUREG_01B2|GPUREG_01B2]]
|
|-
| 01B3
| [[#GPUREG_01B3|GPUREG_01B3]]
|
|-
| 01B4
| [[#GPUREG_01B4|GPUREG_01B4]]
|
|-
| 01B5
| [[#GPUREG_01B5|GPUREG_01B5]]
|
|-
| 01B6
| [[#GPUREG_01B6|GPUREG_01B6]]
|
|-
| 01B7
| [[#GPUREG_01B7|GPUREG_01B7]]
|
|-
| 01B8
| [[#GPUREG_01B8|GPUREG_01B8]]
|
|-
| 01B9
| [[#GPUREG_01B9|GPUREG_01B9]]
|
|-
| 01BA
| [[#GPUREG_01BA|GPUREG_01BA]]
|
|-
| 01BB
| [[#GPUREG_01BB|GPUREG_01BB]]
|
|-
| 01BC
| [[#GPUREG_01BC|GPUREG_01BC]]
|
|-
| 01BD
| [[#GPUREG_01BD|GPUREG_01BD]]
|
|-
| 01BE
| [[#GPUREG_01BE|GPUREG_01BE]]
|
|-
| 01BF
| [[#GPUREG_01BF|GPUREG_01BF]]
|
|-
| 01C0
| [[#GPUREG_01C0|GPUREG_01C0]]
|
|-
| 01C1
| [[#GPUREG_01C1|GPUREG_01C1]]
|
|-
| 01C2
| [[#GPUREG_01C2|GPUREG_01C2]]
|
|-
| 01C3
| [[#GPUREG_01C3|GPUREG_01C3]]
|
|-
| 01C4
| [[#GPUREG_01C4|GPUREG_01C4]]
|
|-
| 01C5
| [[#GPUREG_01C5|GPUREG_01C5]]
|
|-
| 01C6
| [[#GPUREG_01C6|GPUREG_01C6]]
|
|-
| 01C7
| [[#GPUREG_01C7|GPUREG_01C7]]
|
|-
| 01C8
| [[#GPUREG_01C8|GPUREG_01C8]]
|
|-
| 01C9
| [[#GPUREG_01C9|GPUREG_01C9]]
|
|-
| 01CA
| [[#GPUREG_01CA|GPUREG_01CA]]
|
|-
| 01CB
| [[#GPUREG_01CB|GPUREG_01CB]]
|
|-
| 01CC
| [[#GPUREG_01CC|GPUREG_01CC]]
|
|-
| 01CD
| [[#GPUREG_01CD|GPUREG_01CD]]
|
|-
| 01CE
| [[#GPUREG_01CE|GPUREG_01CE]]
|
|-
| 01CF
| [[#GPUREG_01CF|GPUREG_01CF]]
|
|-
| 01D0
| [[#GPUREG_01D0|GPUREG_01D0]]
|
|-
| 01D1
| [[#GPUREG_01D1|GPUREG_01D1]]
|
|-
| 01D2
| [[#GPUREG_01D2|GPUREG_01D2]]
|
|-
| 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_01D9|GPUREG_01D9]]
|
|-
| 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]]
|
|-
! colspan=3 | Geometry pipeline registers
|-
| 0200
| [[#GPUREG_ATTRIBBUFFERS_LOC|GPUREG_ATTRIBBUFFERS_LOC]]
|
|-
| 0201
| [[#GPUREG_ATTRIBBUFFERS_FORMAT_LOW|GPUREG_ATTRIBBUFFERS_FORMAT_LOW]]
|
|-
| 0202
| [[#GPUREG_ATTRIBBUFFERS_FORMAT_HIGH|GPUREG_ATTRIBBUFFERS_FORMAT_HIGH]]
|
|-
| 0203
| [[#GPUREG_ATTRIBBUFFER0_CONFIG0|GPUREG_ATTRIBBUFFER0_CONFIG0]]
|
|-
| 0204
| [[#GPUREG_ATTRIBBUFFER0_CONFIG1|GPUREG_ATTRIBBUFFER0_CONFIG1]]
|
|-
| 0205
| [[#GPUREG_ATTRIBBUFFER0_CONFIG2|GPUREG_ATTRIBBUFFER0_CONFIG2]]
|
|-
| 0206
| [[#GPUREG_ATTRIBBUFFER1_CONFIG0|GPUREG_ATTRIBBUFFER1_CONFIG0]]
|
|-
| 0207
| [[#GPUREG_ATTRIBBUFFER1_CONFIG1|GPUREG_ATTRIBBUFFER1_CONFIG1]]
|
|-
| 0208
| [[#GPUREG_ATTRIBBUFFER1_CONFIG2|GPUREG_ATTRIBBUFFER1_CONFIG2]]
|
|-
| 0209
| [[#GPUREG_ATTRIBBUFFER2_CONFIG0|GPUREG_ATTRIBBUFFER2_CONFIG0]]
|
|-
| 020A
| [[#GPUREG_ATTRIBBUFFER2_CONFIG1|GPUREG_ATTRIBBUFFER2_CONFIG1]]
|
|-
| 020B
| [[#GPUREG_ATTRIBBUFFER2_CONFIG2|GPUREG_ATTRIBBUFFER2_CONFIG2]]
|
|-
| 020C
| [[#GPUREG_ATTRIBBUFFER3_CONFIG0|GPUREG_ATTRIBBUFFER3_CONFIG0]]
|
|-
| 020D
| [[#GPUREG_ATTRIBBUFFER3_CONFIG1|GPUREG_ATTRIBBUFFER3_CONFIG1]]
|
|-
| 020E
| [[#GPUREG_ATTRIBBUFFER3_CONFIG2|GPUREG_ATTRIBBUFFER3_CONFIG2]]
|
|-
| 020F
| [[#GPUREG_ATTRIBBUFFER4_CONFIG0|GPUREG_ATTRIBBUFFER4_CONFIG0]]
|
|-
| 0210
| [[#GPUREG_ATTRIBBUFFER4_CONFIG1|GPUREG_ATTRIBBUFFER4_CONFIG1]]
|
|-
| 0211
| [[#GPUREG_ATTRIBBUFFER4_CONFIG2|GPUREG_ATTRIBBUFFER4_CONFIG2]]
|
|-
| 0212
| [[#GPUREG_ATTRIBBUFFER5_CONFIG0|GPUREG_ATTRIBBUFFER5_CONFIG0]]
|
|-
| 0213
| [[#GPUREG_ATTRIBBUFFER5_CONFIG1|GPUREG_ATTRIBBUFFER5_CONFIG1]]
|
|-
| 0214
| [[#GPUREG_ATTRIBBUFFER5_CONFIG2|GPUREG_ATTRIBBUFFER5_CONFIG2]]
|
|-
| 0215
| [[#GPUREG_ATTRIBBUFFER6_CONFIG0|GPUREG_ATTRIBBUFFER6_CONFIG0]]
|
|-
| 0216
| [[#GPUREG_ATTRIBBUFFER6_CONFIG1|GPUREG_ATTRIBBUFFER6_CONFIG1]]
|
|-
| 0217
| [[#GPUREG_ATTRIBBUFFER6_CONFIG2|GPUREG_ATTRIBBUFFER6_CONFIG2]]
|
|-
| 0218
| [[#GPUREG_ATTRIBBUFFER7_CONFIG0|GPUREG_ATTRIBBUFFER7_CONFIG0]]
|
|-
| 0219
| [[#GPUREG_ATTRIBBUFFER7_CONFIG1|GPUREG_ATTRIBBUFFER7_CONFIG1]]
|
|-
| 021A
| [[#GPUREG_ATTRIBBUFFER7_CONFIG2|GPUREG_ATTRIBBUFFER7_CONFIG2]]
|
|-
| 021B
| [[#GPUREG_ATTRIBBUFFER8_CONFIG0|GPUREG_ATTRIBBUFFER8_CONFIG0]]
|
|-
| 021C
| [[#GPUREG_ATTRIBBUFFER8_CONFIG1|GPUREG_ATTRIBBUFFER8_CONFIG1]]
|
|-
| 021D
| [[#GPUREG_ATTRIBBUFFER8_CONFIG2|GPUREG_ATTRIBBUFFER8_CONFIG2]]
|
|-
| 021E
| [[#GPUREG_ATTRIBBUFFER9_CONFIG0|GPUREG_ATTRIBBUFFER9_CONFIG0]]
|
|-
| 021F
| [[#GPUREG_ATTRIBBUFFER9_CONFIG1|GPUREG_ATTRIBBUFFER9_CONFIG1]]
|
|-
| 0220
| [[#GPUREG_ATTRIBBUFFER9_CONFIG2|GPUREG_ATTRIBBUFFER9_CONFIG2]]
|
|-
| 0221
| [[#GPUREG_ATTRIBBUFFERA_CONFIG0|GPUREG_ATTRIBBUFFERA_CONFIG0]]
|
|-
| 0222
| [[#GPUREG_ATTRIBBUFFERA_CONFIG1|GPUREG_ATTRIBBUFFERA_CONFIG1]]
|
|-
| 0223
| [[#GPUREG_ATTRIBBUFFERA_CONFIG2|GPUREG_ATTRIBBUFFERA_CONFIG2]]
|
|-
| 0224
| [[#GPUREG_ATTRIBBUFFERB_CONFIG0|GPUREG_ATTRIBBUFFERB_CONFIG0]]
|
|-
| 0225
| [[#GPUREG_ATTRIBBUFFERB_CONFIG1|GPUREG_ATTRIBBUFFERB_CONFIG1]]
|
|-
| 0226
| [[#GPUREG_ATTRIBBUFFERB_CONFIG2|GPUREG_ATTRIBBUFFERB_CONFIG2]]
|
|-
| 0227
| [[#GPUREG_INDEXBUFFER_CONFIG|GPUREG_INDEXBUFFER_CONFIG]]
|
|-
| 0228
| [[#GPUREG_NUMVERTICES|GPUREG_NUMVERTICES]]
|
|-
| 0229
| [[#GPUREG_GEOSTAGE_CONFIG|GPUREG_GEOSTAGE_CONFIG]]
| ?
|-
| 022A
| [[#GPUREG_022A|GPUREG_022A]]
|
|-
| 022B
| [[#GPUREG_022B|GPUREG_022B]]
|
|-
| 022C
| [[#GPUREG_022C|GPUREG_022C]]
|
|-
| 022D
| [[#GPUREG_022D|GPUREG_022D]]
|
|-
| 022E
| [[#GPUREG_DRAWARRAYS|GPUREG_DRAWARRAYS]]
|
|-
| 022F
| [[#GPUREG_DRAWELEMENTS|GPUREG_DRAWELEMENTS]]
|
|-
| 0230
| [[#GPUREG_0230|GPUREG_0230]]
|
|-
| 0231
| [[#GPUREG_0231|GPUREG_0231]]
|
|-
| 0232
| [[#GPUREG_0232|GPUREG_0232]]
|
|-
| 0233
| [[#GPUREG_0233|GPUREG_0233]]
|
|-
| 0234
| [[#GPUREG_0234|GPUREG_0234]]
|
|-
| 0235
| [[#GPUREG_0235|GPUREG_0235]]
|
|-
| 0236
| [[#GPUREG_0236|GPUREG_0236]]
|
|-
| 0237
| [[#GPUREG_0237|GPUREG_0237]]
|
|-
| 0238
| [[#GPUREG_0238|GPUREG_0238]]
|
|-
| 0239
| [[#GPUREG_0239|GPUREG_0239]]
|
|-
| 023A
| [[#GPUREG_023A|GPUREG_023A]]
|
|-
| 023B
| [[#GPUREG_023B|GPUREG_023B]]
|
|-
| 023C
| [[#GPUREG_023C|GPUREG_023C]]
|
|-
| 023D
| [[#GPUREG_023D|GPUREG_023D]]
|
|-
| 023E
| [[#GPUREG_023E|GPUREG_023E]]
|
|-
| 023F
| [[#GPUREG_023F|GPUREG_023F]]
|
|-
| 0240
| [[#GPUREG_0240|GPUREG_0240]]
|
|-
| 0241
| [[#GPUREG_0241|GPUREG_0241]]
|
|-
| 0242
| [[#GPUREG_0242|GPUREG_0242]]
|
|-
| 0243
| [[#GPUREG_0243|GPUREG_0243]]
|
|-
| 0244
| [[#GPUREG_0244|GPUREG_0244]]
|
|-
| 0245
| [[#GPUREG_0245|GPUREG_0245]]
|
|-
| 0246
| [[#GPUREG_0246|GPUREG_0246]]
|
|-
| 0247
| [[#GPUREG_0247|GPUREG_0247]]
|
|-
| 0248
| [[#GPUREG_0248|GPUREG_0248]]
|
|-
| 0249
| [[#GPUREG_0249|GPUREG_0249]]
|
|-
| 024A
| [[#GPUREG_024A|GPUREG_024A]]
|
|-
| 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_0251|GPUREG_0251]]
|
|-
| 0252
| [[#GPUREG_0252|GPUREG_0252]]
|
|-
| 0253
| [[#GPUREG_0253|GPUREG_0253]]
|
|-
| 0254
| [[#GPUREG_0254|GPUREG_0254]]
|
|-
| 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]]
| ?
|-
| 025F
| [[#GPUREG_025F|GPUREG_025F]]
|
|-
| 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]]
|
|-
! colspan=3 | Geometry shader registers
|-
| 0280
| [[#GPUREG_GSH_BOOLUNIFORM|GPUREG_GSH_BOOLUNIFORM]]
|
|-
| 0281
| [[#GPUREG_GSH_INTUNIFORM_I0|GPUREG_GSH_INTUNIFORM_I0]]
|
|-
| 0282
| [[#GPUREG_GSH_INTUNIFORM_I1|GPUREG_GSH_INTUNIFORM_I1]]
|
|-
| 0283
| [[#GPUREG_GSH_INTUNIFORM_I2|GPUREG_GSH_INTUNIFORM_I2]]
|
|-
| 0284
| [[#GPUREG_GSH_INTUNIFORM_I3|GPUREG_GSH_INTUNIFORM_I3]]
|
|-
| 0285
| [[#GPUREG_0285|GPUREG_0285]]
|
|-
| 0286
| [[#GPUREG_0286|GPUREG_0286]]
|
|-
| 0287
| [[#GPUREG_0287|GPUREG_0287]]
|
|-
| 0288
| [[#GPUREG_0288|GPUREG_0288]]
|
|-
| 0289
| [[#GPUREG_GSH_INPUTBUFFER_CONFIG|GPUREG_GSH_INPUTBUFFER_CONFIG]]
|
|-
| 028A
| [[#GPUREG_GSH_ENTRYPOINT|GPUREG_GSH_ENTRYPOINT]]
|
|-
| 028B
| [[#GPUREG_GSH_ATTRIBUTES_PERMUTATION_LOW|GPUREG_GSH_ATTRIBUTES_PERMUTATION_LOW]]
|
|-
| 028C
| [[#GPUREG_GSH_ATTRIBUTES_PERMUTATION_HIGH|GPUREG_GSH_ATTRIBUTES_PERMUTATION_HIGH]]
|
|-
| 028D
| [[#GPUREG_GSH_OUTMAP_MASK|GPUREG_GSH_OUTMAP_MASK]]
|
|-
| 028E
| [[#GPUREG_028E|GPUREG_028E]]
|
|-
| 028F
| [[#GPUREG_GSH_CODETRANSFER_END|GPUREG_GSH_CODETRANSFER_END]]
|
|-
| 0290
| [[#GPUREG_GSH_FLOATUNIFORM_CONFIG|GPUREG_GSH_FLOATUNIFORM_CONFIG]]
|
|-
| 0291
| [[#GPUREG_GSH_FLOATUNIFORM_DATA|GPUREG_GSH_FLOATUNIFORM_DATA]]
|
|-
| 0292
| [[#GPUREG_GSH_FLOATUNIFORM_DATA|GPUREG_GSH_FLOATUNIFORM_DATA]]
|
|-
| 0293
| [[#GPUREG_GSH_FLOATUNIFORM_DATA|GPUREG_GSH_FLOATUNIFORM_DATA]]
|
|-
| 0294
| [[#GPUREG_GSH_FLOATUNIFORM_DATA|GPUREG_GSH_FLOATUNIFORM_DATA]]
|
|-
| 0295
| [[#GPUREG_GSH_FLOATUNIFORM_DATA|GPUREG_GSH_FLOATUNIFORM_DATA]]
|
|-
| 0296
| [[#GPUREG_GSH_FLOATUNIFORM_DATA|GPUREG_GSH_FLOATUNIFORM_DATA]]
|
|-
| 0297
| [[#GPUREG_GSH_FLOATUNIFORM_DATA|GPUREG_GSH_FLOATUNIFORM_DATA]]
|
|-
| 0298
| [[#GPUREG_GSH_FLOATUNIFORM_DATA|GPUREG_GSH_FLOATUNIFORM_DATA]]
|
|-
| 0299
| [[#GPUREG_0299|GPUREG_0299]]
|
|-
| 029A
| [[#GPUREG_029A|GPUREG_029A]]
|
|-
| 029B
| [[#GPUREG_GSH_CODETRANSFER_CONFIG|GPUREG_GSH_CODETRANSFER_CONFIG]]
| ?
|-
| 029C
| [[#GPUREG_GSH_CODETRANSFER_DATA|GPUREG_GSH_CODETRANSFER_DATA]]
|
|-
| 029D
| [[#GPUREG_GSH_CODETRANSFER_DATA|GPUREG_GSH_CODETRANSFER_DATA]]
|
|-
| 029E
| [[#GPUREG_GSH_CODETRANSFER_DATA|GPUREG_GSH_CODETRANSFER_DATA]]
|
|-
| 029F
| [[#GPUREG_GSH_CODETRANSFER_DATA|GPUREG_GSH_CODETRANSFER_DATA]]
|
|-
| 02A0
| [[#GPUREG_GSH_CODETRANSFER_DATA|GPUREG_GSH_CODETRANSFER_DATA]]
|
|-
| 02A1
| [[#GPUREG_GSH_CODETRANSFER_DATA|GPUREG_GSH_CODETRANSFER_DATA]]
|
|-
| 02A2
| [[#GPUREG_GSH_CODETRANSFER_DATA|GPUREG_GSH_CODETRANSFER_DATA]]
|
|-
| 02A3
| [[#GPUREG_GSH_CODETRANSFER_DATA|GPUREG_GSH_CODETRANSFER_DATA]]
|
|-
| 02A4
| [[#GPUREG_02A4|GPUREG_02A4]]
|
|-
| 02A5
| [[#GPUREG_GSH_OPDESCS_CONFIG|GPUREG_GSH_OPDESCS_CONFIG]]
|
|-
| 02A6
| [[#GPUREG_GSH_OPDESCS_DATA|GPUREG_GSH_OPDESCS_DATA]]
|
|-
| 02A7
| [[#GPUREG_GSH_OPDESCS_DATA|GPUREG_GSH_OPDESCS_DATA]]
|
|-
| 02A8
| [[#GPUREG_GSH_OPDESCS_DATA|GPUREG_GSH_OPDESCS_DATA]]
|
|-
| 02A9
| [[#GPUREG_GSH_OPDESCS_DATA|GPUREG_GSH_OPDESCS_DATA]]
|
|-
| 02AA
| [[#GPUREG_GSH_OPDESCS_DATA|GPUREG_GSH_OPDESCS_DATA]]
|
|-
| 02AB
| [[#GPUREG_GSH_OPDESCS_DATA|GPUREG_GSH_OPDESCS_DATA]]
|
|-
| 02AC
| [[#GPUREG_GSH_OPDESCS_DATA|GPUREG_GSH_OPDESCS_DATA]]
|
|-
| 02AD
| [[#GPUREG_GSH_OPDESCS_DATA|GPUREG_GSH_OPDESCS_DATA]]
|
|-
| 02AE
| [[#GPUREG_02AE|GPUREG_02AE]]
|
|-
| 02AF
| [[#GPUREG_02AF|GPUREG_02AF]]
|
|-
! colspan=3 | Vertex shader registers
|-
| 02B0
| [[#GPUREG_VSH_BOOLUNIFORM|GPUREG_VSH_BOOLUNIFORM]]
|
|-
| 02B1
| [[#GPUREG_VSH_INTUNIFORM_I0|GPUREG_VSH_INTUNIFORM_I0]]
|
|-
| 02B2
| [[#GPUREG_VSH_INTUNIFORM_I1|GPUREG_VSH_INTUNIFORM_I1]]
|
|-
| 02B3
| [[#GPUREG_VSH_INTUNIFORM_I2|GPUREG_VSH_INTUNIFORM_I2]]
|
|-
| 02B4
| [[#GPUREG_VSH_INTUNIFORM_I3|GPUREG_VSH_INTUNIFORM_I3]]
|
|-
| 02B5
| [[#GPUREG_02B5|GPUREG_02B5]]
|
|-
| 02B6
| [[#GPUREG_02B6|GPUREG_02B6]]
|
|-
| 02B7
| [[#GPUREG_02B7|GPUREG_02B7]]
|
|-
| 02B8
| [[#GPUREG_02B8|GPUREG_02B8]]
|
|-
| 02B9
| [[#GPUREG_VSH_INPUTBUFFER_CONFIG|GPUREG_VSH_INPUTBUFFER_CONFIG]]
|
|-
| 02BA
| [[#GPUREG_VSH_ENTRYPOINT|GPUREG_VSH_ENTRYPOINT]]
|
|-
| 02BB
| [[#GPUREG_VSH_ATTRIBUTES_PERMUTATION_LOW|GPUREG_VSH_ATTRIBUTES_PERMUTATION_LOW]]
|
|-
| 02BC
| [[#GPUREG_VSH_ATTRIBUTES_PERMUTATION_HIGH|GPUREG_VSH_ATTRIBUTES_PERMUTATION_HIGH]]
|
|-
| 02BD
| [[#GPUREG_VSH_OUTMAP_MASK|GPUREG_VSH_OUTMAP_MASK]]
|
|-
| 02BE
| [[#GPUREG_02BE|GPUREG_02BE]]
|
|-
| 02BF
| [[#GPUREG_VSH_CODETRANSFER_END|GPUREG_VSH_CODETRANSFER_END]]
|
|-
| 02C0
| [[#GPUREG_VSH_FLOATUNIFORM_CONFIG|GPUREG_VSH_FLOATUNIFORM_CONFIG]]
|
|-
| 02C1
| [[#GPUREG_VSH_FLOATUNIFORM_DATA|GPUREG_VSH_FLOATUNIFORM_DATA]]
|
|-
| 02C2
| [[#GPUREG_VSH_FLOATUNIFORM_DATA|GPUREG_VSH_FLOATUNIFORM_DATA]]
|
|-
| 02C3
| [[#GPUREG_VSH_FLOATUNIFORM_DATA|GPUREG_VSH_FLOATUNIFORM_DATA]]
|
|-
| 02C4
| [[#GPUREG_VSH_FLOATUNIFORM_DATA|GPUREG_VSH_FLOATUNIFORM_DATA]]
|
|-
| 02C5
| [[#GPUREG_VSH_FLOATUNIFORM_DATA|GPUREG_VSH_FLOATUNIFORM_DATA]]
|
|-
| 02C6
| [[#GPUREG_VSH_FLOATUNIFORM_DATA|GPUREG_VSH_FLOATUNIFORM_DATA]]
|
|-
| 02C7
| [[#GPUREG_VSH_FLOATUNIFORM_DATA|GPUREG_VSH_FLOATUNIFORM_DATA]]
|
|-
| 02C8
| [[#GPUREG_VSH_FLOATUNIFORM_DATA|GPUREG_VSH_FLOATUNIFORM_DATA]]
|
|-
| 02C9
| [[#GPUREG_02C9|GPUREG_02C9]]
|
|-
| 02CA
| [[#GPUREG_02CA|GPUREG_02CA]]
|
|-
| 02CB
| [[#GPUREG_VSH_CODETRANSFER_CONFIG|GPUREG_VSH_CODETRANSFER_CONFIG]]
| ?
|-
| 02CC
| [[#GPUREG_VSH_CODETRANSFER_DATA|GPUREG_VSH_CODETRANSFER_DATA]]
|
|-
| 02CD
| [[#GPUREG_VSH_CODETRANSFER_DATA|GPUREG_VSH_CODETRANSFER_DATA]]
|
|-
| 02CE
| [[#GPUREG_VSH_CODETRANSFER_DATA|GPUREG_VSH_CODETRANSFER_DATA]]
|
|-
| 02CF
| [[#GPUREG_VSH_CODETRANSFER_DATA|GPUREG_VSH_CODETRANSFER_DATA]]
|
|-
| 02D0
| [[#GPUREG_VSH_CODETRANSFER_DATA|GPUREG_VSH_CODETRANSFER_DATA]]
|
|-
| 02D1
| [[#GPUREG_VSH_CODETRANSFER_DATA|GPUREG_VSH_CODETRANSFER_DATA]]
|
|-
| 02D2
| [[#GPUREG_VSH_CODETRANSFER_DATA|GPUREG_VSH_CODETRANSFER_DATA]]
|
|-
| 02D3
| [[#GPUREG_VSH_CODETRANSFER_DATA|GPUREG_VSH_CODETRANSFER_DATA]]
|
|-
| 02D4
| [[#GPUREG_02D4|GPUREG_02D4]]
|
|-
| 02D5
| [[#GPUREG_VSH_OPDESCS_CONFIG|GPUREG_VSH_OPDESCS_CONFIG]]
| ?
|-
| 02D6
| [[#GPUREG_VSH_OPDESCS_DATA|GPUREG_VSH_OPDESCS_DATA]]
|
|-
| 02D7
| [[#GPUREG_VSH_OPDESCS_DATA|GPUREG_VSH_OPDESCS_DATA]]
|
|-
| 02D8
| [[#GPUREG_VSH_OPDESCS_DATA|GPUREG_VSH_OPDESCS_DATA]]
|
|-
| 02D9
| [[#GPUREG_VSH_OPDESCS_DATA|GPUREG_VSH_OPDESCS_DATA]]
|
|-
| 02DA
| [[#GPUREG_VSH_OPDESCS_DATA|GPUREG_VSH_OPDESCS_DATA]]
|
|-
| 02DB
| [[#GPUREG_VSH_OPDESCS_DATA|GPUREG_VSH_OPDESCS_DATA]]
|
|-
| 02DC
| [[#GPUREG_VSH_OPDESCS_DATA|GPUREG_VSH_OPDESCS_DATA]]
|
|-
| 02DD
| [[#GPUREG_VSH_OPDESCS_DATA|GPUREG_VSH_OPDESCS_DATA]]
|
|-
! colspan=3 | Unknown registers
|-
| 02DE
| [[#GPUREG_02DE|GPUREG_02DE]]
|
|-
| 02DF
| [[#GPUREG_02DF|GPUREG_02DF]]
|
|-
| 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]]
|
|}

=== GPUREG_FINALIZE ===

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.

=== GPUREG_GEOSTAGE_CONFIG ===

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| Geometry stage mode. (0=Vertex shader only, 2=Vertex shader + geometry shader)
|-
| 0-7
| Unknown. Often set to 1.
|-
| 0-7
| Unknown.
|-
| 0-7
| Unknown. Often set to 0.
|}

This register configures the geometry stage of the GPU pipeline.

=== Geometry shader registers ===

==== GPUREG_GSH_BOOLUNIFORM ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| Value of geometry shader unit's b0 boolean register. (0=true, 1=false)
|-
| 1
| Value of geometry shader unit's b1 boolean register. (0=true, 1=false)
|-
| 2
| Value of geometry shader unit's b2 boolean register. (0=true, 1=false)
|-
| 3
| Value of geometry shader unit's b3 boolean register. (0=true, 1=false)
|-
| 4
| Value of geometry shader unit's b4 boolean register. (0=true, 1=false)
|-
| 5
| Value of geometry shader unit's b5 boolean register. (0=true, 1=false)
|-
| 6
| Value of geometry shader unit's b6 boolean register. (0=true, 1=false)
|-
| 7
| Value of geometry shader unit's b7 boolean register. (0=true, 1=false)
|-
| 8
| Value of geometry shader unit's b8 boolean register. (0=true, 1=false)
|-
| 9
| Value of geometry shader unit's b9 boolean register. (0=true, 1=false)
|-
| 10
| Value of geometry shader unit's b10 boolean register. (0=true, 1=false)
|-
| 11
| Value of geometry shader unit's b11 boolean register. (0=true, 1=false)
|-
| 12
| Value of geometry shader unit's b12 boolean register. (0=true, 1=false)
|-
| 13
| Value of geometry shader unit's b13 boolean register. (0=true, 1=false)
|-
| 14
| Value of geometry shader unit's b14 boolean register. (0=true, 1=false)
|-
| 15
| Value of geometry shader unit's b15 boolean register. (0=true, 1=false)
|-
| 16-31
| Unknown. This seems to always be set to 0x7FFF, and other values may cause the GPU to hang
|}

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

==== GPUREG_GSH_INTUNIFORM_I0 ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| Value for geometry shader's i0.x (u8, 0-255)
|-
| 8-15
| Value for geometry shader's i0.y (u8, 0-255)
|-
| 16-23
| Value for geometry shader's i0.z (u8, 0-255)
|-
| 24-31
| Value for geometry shader's i0.w (u8, 0-255)
|}

This register is used to set the geometry shader's i0 integer register.

==== GPUREG_GSH_INTUNIFORM_I1 ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| Value for geometry shader's i1.x (u8, 0-255)
|-
| 8-15
| Value for geometry shader's i1.y (u8, 0-255)
|-
| 16-23
| Value for geometry shader's i1.z (u8, 0-255)
|-
| 24-31
| Value for geometry shader's i1.w (u8, 0-255)
|}

This register is used to set the geometry shader's i1 integer register.

==== GPUREG_GSH_INTUNIFORM_I2 ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| Value for geometry shader's i2.x (u8, 0-255)
|-
| 8-15
| Value for geometry shader's i2.y (u8, 0-255)
|-
| 16-23
| Value for geometry shader's i2.z (u8, 0-255)
|-
| 24-31
| Value for geometry shader's i2.w (u8, 0-255)
|}

This register is used to set the geometry shader's i2 integer register.

==== GPUREG_GSH_INTUNIFORM_I3 ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| Value for geometry shader's i3.x (u8, 0-255)
|-
| 8-15
| Value for geometry shader's i3.y (u8, 0-255)
|-
| 16-23
| Value for geometry shader's i3.z (u8, 0-255)
|-
| 24-31
| Value for geometry shader's i3.w (u8, 0-255)
|}

This register is used to set the geometry shader's i3 integer register.

==== GPUREG_GSH_INPUTBUFFER_CONFIG ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| Input buffer stride minus 1, in float vec4 registers. (value 0 means a stride of 1 float vec4 register)
|-
| 8-23
| Unknown. These bits typically aren't updated by games.
|-
| 24-31
| Unknown. This is typically set to 8 for geometry shaders.
|}

This register is used to configure the geometry shader's input buffer. In the context of a geometry shader, the stride parameter can be interpreted as the input primitive size in registers, though it is not a limit on the number of input registers which can be accessed from the geometry shader.

==== GPUREG_GSH_ENTRYPOINT ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-15
| Geometry shader unit entrypoint, in words.
|-
| 16-31
| Unknown. This seems to always be set to 0x7FFF, and other values may cause the GPU to hang
|}

This sets the entrypoint for the program running on 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 entrypoint, it can also be used to set this single shader unit to run from a different entrypoint than the other three even when running a vertex shader.

==== GPUREG_GSH_ATTRIBUTES_PERMUTATION_LOW ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| Index of geometry shader input register which the 1st attribute will be stored in.
|-
| 4-7
| Index of geometry shader input register which the 2nd attribute will be stored in.
|-
| 8-11
| Index of geometry shader input register which the 3rd attribute will be stored in.
|-
| 12-15
| Index of geometry shader input register which the 4th attribute will be stored in.
|-
| 16-19
| Index of geometry shader input register which the 5th attribute will be stored in.
|-
| 20-23
| Index of geometry shader input register which the 6th attribute will be stored in.
|-
| 24-27
| Index of geometry shader input register which the 7th attribute will be stored in.
|-
| 28-31
| Index of geometry shader input register which the 8th attribute will be stored in.
|}

This register sets the geometry shader 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 geometry shader program, v5 will contain the input buffer's 1st attribute.

==== GPUREG_GSH_ATTRIBUTES_PERMUTATION_HIGH ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| Index of geometry shader input register which the 9th attribute will be stored in.
|-
| 4-7
| Index of geometry shader input register which the 10th attribute will be stored in.
|-
| 8-11
| Index of geometry shader input register which the 11th attribute will be stored in.
|-
| 12-15
| Index of geometry shader input register which the 12th attribute will be stored in.
|-
| 16-19
| Index of geometry shader input register which the 13th attribute will be stored in.
|-
| 20-23
| Index of geometry shader input register which the 14th attribute will be stored in.
|-
| 24-27
| Index of geometry shader input register which the 15th attribute will be stored in.
|-
| 28-31
| Index of geometry shader input register which the 16th attribute will be stored in.
|}

This register sets the geometry shader 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 geometry shader program, v5 will contain the input buffer's 9th attribute.

==== GPUREG_GSH_OUTMAP_MASK ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| Enable bit for geometry shader's o0 output register. (1 = o0 enabled, 0 = o0 disabled)
|-
| 1
| Enable bit for geometry shader's o1 output register. (1 = o1 enabled, 0 = o1 disabled)
|-
| 2
| Enable bit for geometry shader's o2 output register. (1 = o2 enabled, 0 = o2 disabled)
|-
| 3
| Enable bit for geometry shader's o3 output register. (1 = o3 enabled, 0 = o3 disabled)
|-
| 4
| Enable bit for geometry shader's o4 output register. (1 = o4 enabled, 0 = o4 disabled)
|-
| 5
| Enable bit for geometry shader's o5 output register. (1 = o5 enabled, 0 = o5 disabled)
|-
| 6
| Enable bit for geometry shader's o6 output register. (1 = o6 enabled, 0 = o6 disabled)
|}

This register toggles the geometry shader unit's output registers.

==== GPUREG_GSH_CODETRANSFER_END ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| Code data transfer end signal bit.
|}

This register's value should be set to 1 in order to finalize the transfer of geometry shader code. It is unknown whether this register is used for other functions.

==== GPUREG_GSH_FLOATUNIFORM_CONFIG ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-6
| Target float vec4 geometry shader uniform ID for transfer. (range 0-95, where 0 = c0 and 95 = c95)
|-
| 31
| Float vec4 geometry shader uniform data transfer mode. (0 = float24, 1 = float32)
|}

This register sets the target float vec4 geometry shader uniform ID and transfer mode for the data transfer system. As such it is typically used right before [[#GPUREG_GSH_FLOATUNIFORM_DATA|GPUREG_GSH_FLOATUNIFORM_DATA]], though writing to one register does not make writing to the other mandatory.

==== GPUREG_GSH_FLOATUNIFORM_DATA ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| Float vec4 geometry shader uniform data. (format depends on transfer mode, see below for details)
|}

This register is used to set the value of float vec4 geometry shader uniform registers. The data format which should be written to it depends on the transfer mode set with [[#GPUREG_GSH_FLOATUNIFORM_CONFIG|GPUREG_GSH_FLOATUNIFORM_CONFIG]]. This register functions as a FIFO queue : after each time a uniform register is successfully set, the target uniform ID value is incremented, meaning that groups of uniforms with contiguous register IDs can be set with only one initial write to [[#GPUREG_GSH_FLOATUNIFORM_CONFIG|GPUREG_GSH_FLOATUNIFORM_CONFIG]].

* 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_GSH_CODETRANSFER_CONFIG ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-11
| Target geometry shader code offset for data transfer.
|}

This register is used to set the offset at which upcoming geometry shader code data transferred through [[#GPUREG_GSH_CODETRANSFER_DATA|GPUREG_GSH_CODETRANSFER_DATA]] should be written.

NOTE : as we do not yet know what a shader program's maximum size is yet, we also do not know how many bits the code offset parameter holds. The biggest shader binary observed so far was 2422 instructions long.

==== GPUREG_GSH_CODETRANSFER_DATA ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| Geometry shader instruction data.
|}

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

==== GPUREG_GSH_OPDESCS_CONFIG ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-6
| Target geometry shader operand descriptor offset for data transfer.
|}

This register is used to set the offset at which upcoming geometry shader operand descriptor data transferred through [[#GPUREG_GSH_OPDESCS_DATA|GPUREG_GSH_OPDESCS_DATA]] should be written.

==== GPUREG_GSH_OPDESCS_DATA ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| Geometry shader operand descriptor data.
|}

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

=== Vertex shader registers ===

==== GPUREG_VSH_BOOLUNIFORM ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| Value of vertex shader unit's b0 boolean register. (0=true, 1=false)
|-
| 1
| Value of vertex shader unit's b1 boolean register. (0=true, 1=false)
|-
| 2
| Value of vertex shader unit's b2 boolean register. (0=true, 1=false)
|-
| 3
| Value of vertex shader unit's b3 boolean register. (0=true, 1=false)
|-
| 4
| Value of vertex shader unit's b4 boolean register. (0=true, 1=false)
|-
| 5
| Value of vertex shader unit's b5 boolean register. (0=true, 1=false)
|-
| 6
| Value of vertex shader unit's b6 boolean register. (0=true, 1=false)
|-
| 7
| Value of vertex shader unit's b7 boolean register. (0=true, 1=false)
|-
| 8
| Value of vertex shader unit's b8 boolean register. (0=true, 1=false)
|-
| 9
| Value of vertex shader unit's b9 boolean register. (0=true, 1=false)
|-
| 10
| Value of vertex shader unit's b10 boolean register. (0=true, 1=false)
|-
| 11
| Value of vertex shader unit's b11 boolean register. (0=true, 1=false)
|-
| 12
| Value of vertex shader unit's b12 boolean register. (0=true, 1=false)
|-
| 13
| Value of vertex shader unit's b13 boolean register. (0=true, 1=false)
|-
| 14
| Value of vertex shader unit's b14 boolean register. (0=true, 1=false)
|-
| 15
| Value of vertex shader unit's b15 boolean register. (0=true, 1=false)
|-
| 16-31
| Unknown. This seems to always be set to 0x7FFF, and other values may cause the GPU to hang
|}

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

==== GPUREG_VSH_INTUNIFORM_I0 ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| Value for vertex shader's i0.x (u8, 0-255)
|-
| 8-15
| Value for vertex shader's i0.y (u8, 0-255)
|-
| 16-23
| Value for vertex shader's i0.z (u8, 0-255)
|-
| 24-31
| Value for vertex shader's i0.w (u8, 0-255)
|}

This register is used to set the vertex shader's i0 integer register.

==== GPUREG_VSH_INTUNIFORM_I1 ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| Value for vertex shader's i1.x (u8, 0-255)
|-
| 8-15
| Value for vertex shader's i1.y (u8, 0-255)
|-
| 16-23
| Value for vertex shader's i1.z (u8, 0-255)
|-
| 24-31
| Value for vertex shader's i1.w (u8, 0-255)
|}

This register is used to set the vertex shader's i1 integer register.

==== GPUREG_VSH_INTUNIFORM_I2 ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| Value for vertex shader's i2.x (u8, 0-255)
|-
| 8-15
| Value for vertex shader's i2.y (u8, 0-255)
|-
| 16-23
| Value for vertex shader's i2.z (u8, 0-255)
|-
| 24-31
| Value for vertex shader's i2.w (u8, 0-255)
|}

This register is used to set the vertex shader's i2 integer register.

==== GPUREG_VSH_INTUNIFORM_I3 ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| Value for vertex shader's i3.x (u8, 0-255)
|-
| 8-15
| Value for vertex shader's i3.y (u8, 0-255)
|-
| 16-23
| Value for vertex shader's i3.z (u8, 0-255)
|-
| 24-31
| Value for vertex shader's i3.w (u8, 0-255)
|}

This register is used to set the vertex shader's i3 integer register.

==== GPUREG_VSH_INPUTBUFFER_CONFIG ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-7
| Input buffer stride minus 1, in float vec4 registers. (value 0 means a stride of 1 float vec4 register)
|-
| 8-23
| Unknown. These bits typically aren't updated by games.
|-
| 24-31
| Unknown. This is typically set to 0xA for vertex shaders.
|}

This register is used to configure the vertex shader's input buffer. In the context of a geometry shader, the stride parameter can be interpreted as the number of attributes per vertex.

==== GPUREG_VSH_ENTRYPOINT ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-15
| Vertex shader entrypoint, in words.
|-
| 16-31
| Unknown. This seems to always be set to 0x7FFF, and other values may cause the GPU to hang
|}

This sets the entrypoint for the program running on 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_VSH_ATTRIBUTES_PERMUTATION_LOW ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| Index of vertex shader input register which the 1st attribute will be stored in.
|-
| 4-7
| Index of vertex shader input register which the 2nd attribute will be stored in.
|-
| 8-11
| Index of vertex shader input register which the 3rd attribute will be stored in.
|-
| 12-15
| Index of vertex shader input register which the 4th attribute will be stored in.
|-
| 16-19
| Index of vertex shader input register which the 5th attribute will be stored in.
|-
| 20-23
| Index of vertex shader input register which the 6th attribute will be stored in.
|-
| 24-27
| Index of vertex shader input register which the 7th attribute will be stored in.
|-
| 28-31
| Index of vertex shader input register which the 8th attribute will be stored in.
|}

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

==== GPUREG_VSH_ATTRIBUTES_PERMUTATION_HIGH ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-3
| Index of vertex shader input register which the 9th attribute will be stored in.
|-
| 4-7
| Index of vertex shader input register which the 10th attribute will be stored in.
|-
| 8-11
| Index of vertex shader input register which the 11th attribute will be stored in.
|-
| 12-15
| Index of vertex shader input register which the 12th attribute will be stored in.
|-
| 16-19
| Index of vertex shader input register which the 13th attribute will be stored in.
|-
| 20-23
| Index of vertex shader input register which the 14th attribute will be stored in.
|-
| 24-27
| Index of vertex shader input register which the 15th attribute will be stored in.
|-
| 28-31
| Index of vertex shader input register which the 16th attribute will be stored in.
|}

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

==== GPUREG_VSH_OUTMAP_MASK ====

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

This register toggles the vertex shader units' output registers.

==== GPUREG_VSH_CODETRANSFER_END ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| Code data transfer end signal bit.
|}

This register's value should be set to 1 in order to finalize the transfer of vertex shader code. It is unknown whether this register is used for other functions.

==== GPUREG_VSH_FLOATUNIFORM_CONFIG ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-6
| Target float vec4 vertex shader uniform ID for transfer. (range 0-95, where 0 = c0 and 95 = c95)
|-
| 31
| Float vec4 vertex shader uniform data transfer mode. (0 = float24, 1 = float32)
|}

This register sets the target float vec4 vertex shader uniform ID and transfer mode for the data transfer system. As such it is typically used right before [[#GPUREG_VSH_FLOATUNIFORM_DATA|GPUREG_VSH_FLOATUNIFORM_DATA]], though writing to one register does not make writing to the other mandatory.

==== GPUREG_VSH_FLOATUNIFORM_DATA ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| Float vec4 vertex shader uniform data. (format depends on transfer mode, see below for details)
|}

This register is used to set the value of float vec4 vertex shader uniform registers. The data format which should be written to it depends on the transfer mode set with [[#GPUREG_VSH_FLOATUNIFORM_CONFIG|GPUREG_VSH_FLOATUNIFORM_CONFIG]]. This register functions as a FIFO queue : after each time a uniform register is successfully set, the target uniform ID value is incremented, meaning that groups of uniforms with contiguous register IDs can be set with only one initial write to [[#GPUREG_VSH_FLOATUNIFORM_CONFIG|GPUREG_VSH_FLOATUNIFORM_CONFIG]].

* 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_VSH_CODETRANSFER_CONFIG ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-11
| Target vertex shader code offset for data transfer.
|}

This register is used to set the offset at which upcoming vertex shader code data transferred through [[#GPUREG_VSH_CODETRANSFER_DATA|GPUREG_VSH_CODETRANSFER_DATA]] should be written.

NOTE : as we do not yet know what a shader program's maximum size is yet, we also do not know how many bits the code offset parameter holds. The biggest shader binary observed so far was 2422 instructions long.

==== GPUREG_VSH_CODETRANSFER_DATA ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| Vertex shader instruction data.
|}

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

==== GPUREG_VSH_OPDESCS_CONFIG ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-6
| Target vertex shader operand descriptor offset for data transfer.
|}

This register is used to set the offset at which upcoming vertex shader operand descriptor data transferred through [[#GPUREG_VSH_OPDESCS_DATA|GPUREG_VSH_OPDESCS_DATA]] should be written.

==== GPUREG_VSH_OPDESCS_DATA ====

{| class="wikitable" border="1"
! Bits
! Description
|-
| 0-31
| Vertex shader operand descriptor data.
|}

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

GPU/Shader Instruction Set

2014-12-17T04:26:23Z

Smea: NOP, END

[[Category:GFX]]

== Overview ==
A compiled shader binary is comprised of two parts : the main instruction sequence and the operand descriptor table. These are both sent to the GPU around the same time but using separate [[GPU Commands]]. Instructions (such as format 1 instruction) may reference operand descriptors. When such is the case, the operand descriptor ID is the offset, in words, of the descriptor within the table.
Both instructions and descriptors are coded in little endian.
Basic implementations of the following specification can be found at [https://github.com/smealum/aemstro] and [https://github.com/neobrain/nihstro].
The instruction set seems to have been heavily inspired by Microsoft's vs_3_0 [http://msdn.microsoft.com/en-us/library/windows/desktop/bb172938%28v=vs.85%29.aspx].
Please note that this page is being written as the instruction set is reverse engineered; as such it may very well contain mistakes.

== Nomenclature ==

* opcode names with I appended to them are the same as their non-I version, except they use the inverted instruction format, giving 7 bits to SRC2 (and access to uniforms) and 5 bits to SRC1

* opcode names with U appended to them are the same as their non-U version, except they are executed conditionally based on the value of a uniform boolean.

* opcode names with C appended to them are the same as their non-C version, except they are executed conditionally based on a logical expression specified in the instruction.

== Instruction formats ==

Format 1 : (used for register operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0x7
| 0x5
| Source 2 register (SRC2)
|-
| 0xC
| 0x7
| Source 1 register (SRC1)
|-
| 0x13
| 0x2
| Address register index for SRC1 (IDX_1)
|-
| 0x15
| 0x5
| Destination register (DST)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 1i : (used for register operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0x7
| 0x7
| Source 2 register (SRC2)
|-
| 0xE
| 0x5
| Source 1 register (SRC1)
|-
| 0x13
| 0x2
| Address register index for SRC2 (IDX_2)
|-
| 0x15
| 0x5
| Destination register (DST)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 1u : (used for unary register operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0xC
| 0x7
| Source 1 register (SRC1)
|-
| 0x13
| 0x2
| Address register index for SRC1 (IDX_1)
|-
| 0x15
| 0x5
| Destination register (DST)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 1c : (used for comparison operations)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x7
| Operand descriptor ID (DESC)
|-
| 0x7
| 0x7
| Source 1 register (SRC1)
|-
| 0xE
| 0x5
| Source 2 register (SRC2)
|-
| 0x13
| 0x2
| Address register index for SRC1 (IDX_1)
|-
| 0x15
| 0x3
| Comparison operator for Y (CMPY)
|-
| 0x18
| 0x3
| Comparison operator for X (CMPX)
|-
| 0x1B
| 0x5
| Opcode
|}

Format 2 : (used for flow control instructions)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x8
| Number of instructions (NUM)
|-
| 0xA
| 0xC
| Destination offset (in words) (DST)
|-
| 0x16
| 0x2
| Condition boolean operator (CONDOP)
|-
| 0x18
| 0x1
| Y reference bit (REFY)
|-
| 0x19
| 0x1
| X reference bit (REFX)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 3 : (used for uniform-based conditional flow control instructions)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x8
| Number of instructions ? (NUM)
|-
| 0xA
| 0xC
| Destination offset (in words) (DST)
|-
| 0x16
| 0x4
| Uniform ID (BOOL/INT)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 4 : (used for SETEMIT)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x16
| 0x1
| Winding flag (FLAG_WINDING)
|-
| 0x17
| 0x1
| Primitive emit flag (FLAG_PRIMEMIT)
|-
| 0x18
| 0x2
| Vertex ID (VTXID)
|-
| 0x1A
| 0x6
| Opcode
|}

Format 5 : (used for MAD and LRP)
{| class="wikitable" border="1"
|-
! Offset
! Size (bits)
! Description
|-
| 0x0
| 0x5
| Operand descriptor ID (DESC)
|-
| 0x5
| 0x5
| Source 3 register (SRC3)
|-
| 0xA
| 0x7
| Source 2 register (SRC2)
|-
| 0x11
| 0x7
| Source 1 register (SRC1)
|-
| 0x18
| 0x5
| Destination register (DST)
|-
| 0x1D
| 0x3
| Opcode
|}

== Instructions ==

{| class="wikitable" border="1"
|-
! Opcode
! Format
! Name
! Description
|-
| 0x00
| 1
| ADD
| Adds two vectors component by component; DST[i] = SRC1[i]+SRC2[i] for all i (modulo destination component masking)
|-
| 0x01
| 1
| DP3
| Computes dot product on 3-component vectors; DST = SRC1.SRC2
|-
| 0x02
| 1
| DP4
| Computes dot product on 4-component vectors; DST = SRC1.SRC2
|-
| 0x03
| 1
| DPH
| Computes dot product on a 4-component vector and a 3-component one with 1.0 appended to it; DST = SRC1.SRC2 (with SRC2 homogenous)
|-
| 0x04
| 1
| ???
| ?
|-
| 0x05
| 1u
| EX2
| Computes SRC1's exp component by component; DST[i] = EXP(SRC1[i]) for all i (modulo destination component masking) (base 2)
|-
| 0x06
| 1u
| LG2
| Computes SRC1's log2 component by component; DST[i] = LOG2(SRC1[i]) for all i (modulo destination component masking) (base 2)
|-
| 0x07
| 1u
| ???
| ?
|-
| 0x08
| 1
| MUL
| Multiplies two vectors component by component; DST[i] = SRC1[i].SRC2[i] for all i (modulo destination component masking)
|-
| 0x09
| 1
| SGE
| Sets output if SRC1 is greater than or equal to SRC2; DST[i] = (SRC1[i] >= SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x0A
| 1
| SLT
| Sets output if SRC1 is strictly less than SRC2; DST[i] = (SRC1[i] < SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x0B
| 1u
| FLR
| Computes SRC1's floor component by component; DST[i] = FLOOR(SRC1[i]) for all i (modulo destination component masking)
|-
| 0x0C
| 1
| MAX
| Takes the max of two vectors, component by component; DST[i] = MAX(SRC1[i], SRC2[i]) for all i (modulo destination component masking)
|-
| 0x0D
| 1
| MIN
| Takes the min of two vectors, component by component; DST[i] = MIN(SRC1[i], SRC2[i]) for all i (modulo destination component masking)
|-
| 0x0E
| 1u
| RCP
| Computes the reciprocal of the vector, component by component; DST[i] = 1/SRC1[i] for all i (modulo destination component masking)
|-
| 0x0F
| 1u
| RSQ
| Computes the reciprocal of the square root of the vector, component by component; DST[i] = 1/sqrt(SRC1[i]) for all i (modulo destination component masking)
|-
| 0x10
| ?
| ???
| ?
|-
| 0x11
| ?
| ???
| ?
|-
| 0x12
| 1u
| MOVA
| Address Register Load; sets (a0.x, a0.y, _, _) to SRC1 (cast to integer).
|-
| 0x13
| 1u
| MOV
| Moves value from one register to another; DST = SRC1.
|-
| 0x14
| ?
| ???
| ?
|-
| 0x15
| ?
| ???
| ?
|-
| 0x16
| ?
| ???
| ?
|-
| 0x17
| ?
| ???
| ?
|-
| 0x18
| 1i
| DPHI
| Computes dot product on a 4-component vector and a 3-component one with 1.0 appended to it; DST = SRC1.SRC2 (with SRC2 homogenous)
|-
| 0x19
| 1i
| ???
| ?
|-
| 0x1A
| 1i
| SGEI
| Sets output if SRC1 is greater than or equal to SRC2; DST[i] = (SRC1[i] >= SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x1B
| 1i
| SLTI
| Sets output if SRC1 is strictly less than SRC2; DST[i] = (SRC1[i] < SRC2[i]) ? 1.0 : 0.0 for all i (modulo destination component masking)
|-
| 0x1C
| ?
| ???
| ?
|-
| 0x1D
| ?
| ???
| ?
|-
| 0x1E
| ?
| ???
| ?
|-
| 0x1F
| ?
| ???
| ?
|-
| 0x20
| ?
| ???
| ?
|-
| 0x21
| 0
| NOP
| Does litterally nothing.
|-
| 0x22
| 0
| END
| Signals the shader unit that processing for this vertex/primitive is done.
|-
| 0x23
| 2
| BREAKC
| If condition (see [[#Conditions|below]] for details) is true, then breaks out of LOOP block.
|-
| 0x24
| 2
| CALL
| Jumps to DST and executes instructions until it reaches DST+NUM instructions
|-
| 0x25
| 2
| CALLC
| If condition (see [[#Conditions|below]] for details) is true, then jumps to DST and executes instructions until it reaches DST+NUM instructions, else does nothing.
|-
| 0x26
| 3
| CALLU
| Jumps to DST and executes instructions until it reaches DST+NUM instructions if BOOL is true
|-
| 0x27
| 3
| IFU
| If condition BOOL is true, then executes instructions until DST, then jumps to DST+NUM; else, jumps to DST.
|-
| 0x28
| 2
| IFC
| If condition (see [[#Conditions|below]] for details) is true, then executes instructions until DST, then jumps to DST+NUM; else, jumps to DST
|-
| 0x29
| 3
| LOOP
| Loops over the code between itself and DST. First sets aL to INT.y, then increments aL by INT.z after each loop. Loops until aL reaches INT.y+INT.x, inclusive (that is : for(aL=INT.y;aL<=INT.y+INT.x;aL+=INT.z)). (INT is i0-i3, an integer vector uniform)
|-
| 0x2A
| 0 (no param)
| EMIT
| (geometry shader only) Emits a vertex (and primitive if FLAG_PRIMEMIT was set in the corresponding SETEMIT). SETEMIT must be called before this.
|-
| 0x2B
| 4
| SETEMIT
| (geometry shader only) Sets VTXID, FLAG_WINDING and FLAG_PRIMEMIT for the next EMIT instruction. VTXID is the ID of the vertex about to be emitted within the primitive, while FLAG_PRIMEMIT is zero if we are just emitting a single vertex and non-zero if are emitting a vertex and primitive simultaneously. FLAG_WINDING controls the output primitive's winding. Note that the output vertex buffer (which holds 4 vertices) is '''not''' cleared when the primitive is emitted, meaning that vertices from the previous primitive can be reused for the current one. (this is still a working hypothesis and unconfirmed)
|-
| 0x2C
| 2
| JMPC
| If condition (see [[#Conditions|below]] for details) is true, then jumps to DST, else does nothing.
|-
| 0x2D
| 3
| JMPU
| If condition BOOL is true, then jumps to DST, else does nothing. It seems possible that having NUM = 1 will jump if BOOL is false instead, though this is unconfirmed.
|-
| 0x2E-0x2F
| 1c
| CMP
| Sets booleans cmp.x and cmp.y based on the operand's x and y components and the CMPX and CMPY comparison operators respectively. See [[#Comparison_operator|below]] for details about operators.
|-
| 0x30-0x37
| 5
| LRP
| Does linear interpolation between two vectors, using a third as the interpolation factor, component by component; DST[i] = SRC1[i].(1.0 - SRC3[i]) + SRC2[i].(SRC3[i]) for all i (modulo destination component masking)
|-
| 0x38-0x3F
| 5
| MAD
| Multiplies two vectors and adds a third one component by component; DST[i] = SRC3[i] + SRC2[i].SRC1[i] for all i (modulo destination component masking)
|}

== Operand descriptors ==
Sizes below are in bits, not bytes.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Destination component mask. Bit 3 = x, 2 = y, 1 = z, 0 = w.
|-
| 0x4
| 0x1
| Source 1 negation bit
|-
| 0x5
| 0x8
| Source 1 component selector
|-
| 0xD
| 0x1
| Source 2 negation bit
|-
| 0xE
| 0x8
| Source 2 component selector
|-
| 0x16
| 0x1
| Source 3 negation bit
|-
| 0x17
| 0x8
| Source 3 component selector
|}

Component selector :
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x2
| Component 3 value
|-
| 0x2
| 0x2
| Component 2 value
|-
| 0x4
| 0x2
| Component 1 value
|-
| 0x6
| 0x2
| Component 0 value
|}

{| class="wikitable" border="1"
|-
! Value
! Component
|-
| 0x0
| x
|-
| 0x1
| y
|-
| 0x2
| z
|-
| 0x3
| w
|}

The component selector enables swizzling. For example, component selector 0x1B is equivalent to .xyzw, while 0x55 is equivalent to .yyyy.

== Relative addressing ==

There are 3 global address registers : a0.x, a0.y and aL (loop counter). For format 1 instructions, when IDX != 0, the value of the corresponding address register is added to SRC1's value.

For example, if IDX = 2, a0.y = 3 and SRC1 = c8, then instead SRC1+a0.y = c11 will be used for the instruction.

a0.x and a0.y can be set manually through the MOVA instruction. aL is set automatically by the LOOP instruction. Note that aL is still accessible and valid after exiting a LOOP block.

== Comparison operator ==

{| class="wikitable" border="1"
|-
! CMPX/CMPY raw value
! Operator name
! Expression
|-
| 0x0
| EQ
| src1 == src2
|-
| 0x1
| NE
| src1 != src2
|-
| 0x2
| LT
| src1 < src2
|-
| 0x3
| LE
| src1 <= src2
|-
| 0x4
| GT
| src1 > src2
|-
| 0x5
| GE
| src1 >= src2
|-
| 0x6
| ??
| true ?
|-
| 0x7
| ??
| true ?
|}

6 and 7 seem to always return true.

== Conditions ==

A number of format 2 instructions are executed conditionally. These conditions are based on two boolean registers which can be set with CMP : cmp.x and cmp.y.

Conditional instructions include 3 parameters : CONDOP, REFX and REFY. REFX and REFY are reference values which are tested for equality against cmp.x and cmp.y, respectively. CONDOP describes how the final truth value is constructed from the results of the two tests. There are four conditional expression formats :

{| class="wikitable" border="1"
|-
! CONDOP raw value
! Expression
! Description
|-
| 0x0
| <nowiki>cmp.x == REFX || cmp.y == REFY</nowiki>
| OR
|-
| 0x1
| <nowiki>cmp.x == REFX && cmp.y == REFY</nowiki>
| AND
|-
| 0x2
| cmp.y == REFY
| Y
|-
| 0x3
| cmp.x == REFX
| X
|}

== Registers ==
Most registers (all the ones within the 0x00-0x7F range) are float[4] vectors. There are also boolean registers (b0-b7) and integer registers (i0-i7). How the latter ones are set is as of yet unknown.

Attribute (input, RO) registers are located within the 0x0-0xF range. What data they are fed is specified by the CPU.

Output (WO) registers are also located within the 0x0-0xF range. What type of data they are contain is specified by the CPU.

Temporary (RW) register are located within the 0x10-0x1F range. They can contain any type of data.

Uniform (RO) registers are located within the 0x20-0x7F range. Their content is set by the CPU.

SRC2 being only 5 bits long rather than 7 bits like its friend SRC1, it can only access v (input attribute) and r (temporary) registers.

Registers in the 0x88-0x97 range are uniform booleans.

It appears that writing twice to the same output register can cause problems, such as the GPU hanging.

DST mapping :

{| class="wikitable" border="1"
|-
! DST raw value
! Register name
! Description
|-
| 0x0-0x6
| o0-o6
| Output registers.
|-
| 0x10-0x1F
| r0-r15
| Temporary registers.
|}

SRC mapping :

{| class="wikitable" border="1"
|-
! SRC1 raw value
! Register name
! Description
|-
| 0x0-0x7
| v0-v7
| Input attribute registers.
|-
| 0x10-0x1F
| r0-r15
| Temporary registers.
|-
| 0x20-0x7F
| c0-c95
| Vector uniform registers.
|}

Note that 5bit SRC registers (SRC2 in format 1 for example) can't access c0-c95 because they don't have enough bits.