Nintendo’s official 3DS development hardware was created in collaboration with Intelligent Systems (IS) and Kyoto Microcomputer Co..
The earliest known 3DS dev kit was a bare-bones prototype board used during development before the final 3DS hardware was ready, which has a resemblence to the prototype board that was leaked for the DS.
An FCC filing in 2010 revealed a Nintendo CTR Target Board test kit consisting of two attached screens (a widescreen 3D top panel and a 4:3 bottom panel) mounted on a circuit board 1.
This board included a Nintendo DS cartridge slot and SD card slot, indicating backward compatibility and storage, and was used to validate new components like the Wi-Fi module prior to the 3DS’s release 2.
This early dev hardware made it clear that only the top screen would have Sharp’s auto-stereoscopic 3D capability, while the bottom screen was a standard LCD 1.
The CTR Target Board allowed first-party developers to begin building 3DS software on prototype hardware months before the retail units were finalized, but as far as we know it was never used outside of Nintendo.
Nintendo initially produced a large “big box” 3DS dev kit known as the IS-CTR-BOX, designed by Intelligent Systems. The photo on the left is by SimonMK7 on twitter 3.
This kit consists of a teal-blue external unit (“the box”) and a tethered 3DS-like controller. Notably, in this early design the handheld controller contained the main 3DS hardware (CPU/GPU), while the external box acted primarily as a “card emulator” for loading game code.
The IS-CTR-BOX couldn’t operate with the controller unplugged because the “brains” were inside the handheld, unlike later units where the box housed the processing hardware. But the controller could be used without plugging it into the IS-CTR-BOX allowing for more portable testing!
This dev kit was released around 2011 in limited quantities (estimated only a few hundred) before Nintendo quickly phased it out in favor of the Partner-CTR series, which offered greater functionality and a more standard setup 4.
Looks like this finally arrived today. This is the IS-CTR-Debugger. Created by Intelligent Systems, this piece of hardware was used to help developers test & debug their games for the Nintendo 3DS. It includes the IS-CTR-Box, the SPR for Emulator unit & a Wii ac adaptor + cables. pic.twitter.com/SX1VWcMfHs
— SimonMK7 (@SimonOrtizBrian) November 26, 2021
Nintendo’s main development kit for the 3DS became the Partner-CTR-Debugger, manufactured by Kyoto Microcomputer (KMC) in partnership with Nintendo.
This system uses a two-unit design: a dev console (code-named CTR-001(-02), often called the Partner CTR Controller) which looks like a 3DS handheld, and a debugger host unit (the Partner-CTR) that contains the core hardware and interfaces.
The handheld portion connects to the debugger box via a pair of proprietary high-bandwidth cables that plug into the base of the unit (occupying the game card slot area).
The tethered 3DS serves as the input controller and display, allowing developers to interact using the real 3DS buttons and touch screen while their code runs on the dev kit hardware in the external box.
The Partner-CTR Debugger box features USB connectivity to the development PC for deploying games and debugging, as well as connectors for the wired controller and other I/O (front panel slots exist for dev cartridges and SD cards, plus indicator LEDs and an IR port).
This kit enables setting breakpoints, inspecting memory, and other runtime debugging on actual 3DS hardware.
The Partner-CTR Debugger initially retailed for about $2,620 USD as a complete set according to an early leak from Planet3DS 5. This is the table they had on their now defunct website 5:
Part # | Item | Price |
---|---|---|
73056 | PARTNER-CTR DEBUGGER | $2,620 |
73058 | PARTNER-CTR DEBUGGER/CAPTURE (Dual Functionality) | $3,950 |
73065 | Nintendo 3DS (Development only) “Panda” USA | $324 |
73066 | Nintendo 3DS (Development only) “Panda” EU | $324 |
73067 | Nintendo 3DS (Development only) “Panda” AUS | $324 |
73062 | Flash Card, 16 Gbits (2 GBytes) CTR | $85 |
73063 | Backup Memory, 1Mbit (128 KBytes) Flash CTR | $8.35 |
73064 | Backup Memory, 4Mbits (512 KBytes) Flash CTR | $10.65 |
It is hard to find good images for the non-capture version of the Partner-CTR-Debugger online but here is a video:
The Partner-CTR Capture device is a variant of the dev kit focused on video output and capture for testing or demonstration.
It adds high-resolution video output capabilities, allowing the 3DS’s dual screens to be displayed on external monitors or capture equipment. The capture unit’s external box provides multiple output ports:
It also includes a USB output interface for direct capture to a PC. Using these, developers or QA staff could mirror the 3DS screens on large displays (up to 720p signal for each screen) or record gameplay footage, which was invaluable for preview events and creating game trailers.
The tethered 3DS controller remains wired to the capture box, so a tester can play normally on the handheld while others view the action on big screens.
Internally, the Capture unit is similar to the Debugger but with additional video encoder hardware. Nintendo offered a combined Partner-CTR Debugger/Capture kit at a higher price (~$3,905 USD for the dual-function model). These capture-enabled kits were rare and typically reserved for larger studios and events due to their cost and Nintendo’s strict licensing.
Linus Tech Tips has a video showing the Partner-CTR Debugger/Capture kit in detail:
The Photo below was posted by moreretrograde on Reddit:
The Partner-CTR development kits all use a special modified 3DS unit (model CTR-001-02) as the input device 6.
Instead of a functional game cartridge slot, the unit has a panel with two locked cable connectors that attach to the dev kit box.
Through these cables, the handheld’s screens and input are linked to the main dev hardware (video data is sent to the monitors/PC, and input is sent back to the game).
The handheld itself is a dummy terminal containing only the LCD displays, speakers, and input controls – most processing and storage are handled by the external Partner box. This design lets developers experience the game on an actual 3DS form-factor (e.g. to test 3D effect using the real screen and to use the touch interface) while still benefiting from debugging and capture features in the host unit.
The wired controller has a reduced internal board and is lighter, since many components (CPU, RAM, etc.) are relocated to the dev kit box.
Nintendo continued this approach of a wired dev-unit controller from the DS era (e.g. the IS-NITRO-Emulator’s DS controller) because it effectively emulates the user experience while enabling full debugging on the PC.
In addition to the full debugger boxes, Nintendo provided simpler development consoles, nicknamed Panda units, for teams to test games in a more portable, retail-like environment. A Panda unit is essentially a modified 3DS handheld that can run unsigned code and dev cartridges but lacks advanced debugging or video-out capabilities.
Panda units use a unique colored shell (often white, silver or black mixes) and contain special boot ROMs and NAND software (Dev Menu, etc.), but otherwise are similar in specs to a retail 3DS.
They can boot games from any region and from SD card or dev flashcards, bypassing the normal Home Menu for direct launch of software under development.
However, they will not run standard retail cartridges (the keys differ) and cannot access online services like eShop in retail mode.
These units were relatively inexpensive (~$324 USD each) compared to the full debugger kits, so studios would buy multiple Panda consoles for QA testers and developers to multiplayer test or continue work off-site.
Elliot from The Retro Future has a video showing off the Panda Development Console:
Aside from the case color and a “NOT FOR RESALE” type markings, they look nearly identical to a normal 3DS. (Notably, the term “Panda” was also used for the DSi debug units, continuing the animal-themed dev kit nicknames.)
Like past Nintendo systems, the 3DS uses special re-writable flash cartridges to load in-development games. The official CTR flash cards resem ble slightly thicker 3DS game cards with generic labels.
One common model has a 16 Gbit (2 GB) capacity, and larger versions up to 4 GB (32 Gbit) were produced as well. These dev carts have no region lock and are reprogrammable – developers can flash their compiled game builds onto the cart and run them on Panda units or Partner-CTR kits. The cartridges do not have the physical write-protect notch that retail game cards have, and they are usually colored dark gray or other non-standard colors to avoid confusion with retail games. Inside, they contain flash memory for game content and no built-in save memory, unlike retail carts.
Instead, the dev cartridges support external backup memory modules for game save data. The flash media can be erased and written thousands of times; developers noted they were “easily re-flashed… allowing for easy re-use” during the iteration process.
Some flash carts used by Nintendo at trade shows were shorter (the size of a normal cart) and preloaded with specific demo software, but the taller official dev cartridges (approximately double height) allow inserting different capacity backup-memory boards and possibly contained additional debugging interfaces.
Known Product IDs:
To accommodate various save sizes and types during development, Nintendo provided removable save flash chips for the dev cartridges instead of fixed internal save RAM. These are similar to how Sub Cards worked on the official Nintendo DS flash cards.
These were often referred to as Backup Memory (Flash) for CTR and came in at least two sizes: 1 Mbit (128 KB) and 4 Mbit (512 KB), corresponding to the typical save sizes of retail 3DS games. Developers could purchase these backup flash modules for only a few dollars each and use them in conjunction with the dev cart.
The tall CTR dev cartridge has a compartment or socket to insert the backup flash (similar in concept to the DS “sub card” system). This design let teams test their game’s save behavior with different memory sizes or technologies ( EEPROM vs. flash ) by swapping the backup chip.
If a game needed, say, 512KB of save data, the corresponding 4Mbit module could be used to ensure the game functioned within that limit. Save Data Filer tools in the 3DS SDK allowed managing the contents of this save memory during testing. (On dev units, saves could also optionally be redirected to the SD card for convenience, but the physical backup flash was used to mimic the exact retail scenario.)
The 3DS development kits largely did not require the elaborate “gang writers” of older systems, since the Partner-CTR hardware and PC software could directly flash dev cartridges over USB.
For example, the Host I/O (HIO) feature in the dev menu allowed installing game builds to a connected dev kit without manual cartridge writing. However, a few miscellaneous hardware tools were used in the 3DS dev pipeline:
The 3DS Gyro Sensor Calibration CTR hardware refers to a specialized software and hardware setup used during the manufacturing process of Nintendo 3DS systems, specifically at Foxconn.
This calibration tool ensures the correct operation of the gyroscope sensor within the 3DS units.
The calibration process involves measuring the gyroscope’s zero-rate offset, which is the sensor’s output when it is stationary and should ideally be zero. This offset arises due to manufacturing variances and sensor imperfections. The calibration software collects multiple readings to determine this offset and adjust the sensor’s output accordingly, ensuring accurate motion sensing during normal use.
When the New Nintendo 3DS was introduced (with upgraded CPU, additional RAM, and new functions), Nintendo also updated the dev hardware. Revised development kits code-named SNAKE were offered, incorporating the New 3DS’s improved specs.
These were essentially Partner-CTR Debugger/Capture devices with upgraded internals to match the new model’s faster processor and added features. For instance, the SNAKE kits allowed testing the extra CPU core and extended memory mode available to New 3DS titles.
The overall form and function remained the same (tethered New 3DS unit and dev box). This ensured backward compatibility while enabling development of exclusive New 3DS software and performance tuning on the new hardware revision. The SNAKE name appears in update tools and documentation, but the hardware was still generally referred to under the CTR Partner branding by developers.
By late in the 3DS’s life, tools like Unity and other middleware also supported the hardware, but these were software-side improvements.
Unlike the DS era, no separate third-party commercial dev kit (such as SN Systems’ ProDG) came to market for the 3DS – the Partner-CTR series effectively was the standard. (SN Systems had announced DS support years prior, but by the 3DS launch SN Systems was owned by Sony and did not provide a 3DS solution.)
Instead, licensed developers all used Nintendo’s provided SDK and hardware kits. The SDK included compiler toolchains, debugger software for the Partner-CTR, and even a Visual Studio 2010 integration plugin for coding on 3DS. Some studios did employ additional tools in their pipeline: for example, Proprietary analyzers and profilers (like SN Systems Tuner or homegrown performance tools) could be used on the output from the dev kit to optimize code.
But the core development and debugging always revolved around the Nintendo-provided hardware. Nintendo also had an online platform (NintendoWare/NW4C) for developers to download sample code, libraries, and documentation throughout the 3DS’s life. In summary, the 3DS did not see any alternative dev units from third parties; the official Partner-CTR debugger/capture and Panda units were the universal solution for 3DS game development.
One notable third-party contribution was the middleware and engine support that grew later in the 3DS lifecycle. For instance, Unity for New 3DS was released as an add-on, allowing developers to use the Unity engine and deploy to 3DS hardware. Similarly, other engines (Unreal Engine variants, etc.) and tools (like audio and physics libraries) were made compatible with Nintendo’s hardware, but those were purely software.
On the hardware side, companies like Kyoto Microcomputer were essentially acting as a contractor for Nintendo – the Partner-CTR units are sometimes branded with KMC’s logo and they handled distribution in some regions. Nintendo’s close control over 3DS development meant unofficial hardware was not really seen in studios.