There's plenty to talk about here, primarily because the capabilities of this console inspired programmers and artists to come up with innovative designs and new methods of interaction. Let's see...
Medium
This console runs games from three sources, where only two of them can make 'full' utilisation of the hardware:
Example of a Slot-1 retail game.
- NDS or 'Slot-1' cards: This is the main medium for loading native DS games, and the only format used for commercial distribution.
- GBA or 'Slot-2' cartridge: This slot is one of the pillars of native Game Boy Advance compatibility. However, since Slot-1 games can also access this interface, expansion cartridges were developed to enhance DS programs. These provided additional RAM, extra input controls (e.g. the Guitar Hero Grip Controller), or haptic feedback (i.e. the Rumble pack).
- Download Play: Also known as 'Wireless MultiBoot', this enables another console running a Slot-1 game to transfer a program via wireless communication. The downloaded content is stored in WRAM and booted after the transfer finishes. Since WRAM is volatile, the downloaded data is erased when the console is powered off.
- Authorised retail stores used this feature to deploy Download Stations, where consumers were invited to download game demos.
Program structure
You've seen that this console's BIOS must be split into ARM9 and ARM7 code. Well, the same principle largely applies to games. Thus, the ROM inside NDS cards is organised into the following areas:
- Header (4 KB): Contains metadata, including the entrypoint of each executable, manufacturer information, and Nintendo's Logo .
- Secure Area (16 KB): Used for copy-protection purposes. We'll cover the details in the 'Anti-piracy' section.
- Main content (variable size): The remainder space stores the executables and game data (graphics, sounds, and so forth). Furthermore, the arrangement of this data was shaped by Nintendo's official Software Development Kit or 'SDK' (a mandatory dependency for retail games), which implemented a filesystem structured hierarchically with files and directories .
Development ecosystem
For game studios interested in developing games for this console, Nintendo supplied both hardware kits and a Software Development Kit (SDK) with lots of utilities.
The hardware
The development kit, called IS-NITRO-EMULATOR, consisted of a medium-size blue unit housing most of the DS's internal hardware and I/O components . Attached to it was a thick cable connected to a dummy Nintendo DS shell, serving as a 'controller' and display. On request, the devkit could be fitted with optional capabilities such as Audio/Video out, a real Wi-Fi interface (by default, Wi-Fi was emulated using Ethernet), and debugging support. To be honest, I expected the latter to be a standard, but these units could also be used by testing teams.
The kit reads DS cards, yet Nintendo also provided rewritable development cards to ease the life of developers. These featured a larger case with swappable backup chips .
Overall, these are only a handful examples, but throughout the console's lifetime, many other pieces of equipment were sold to help with certain tasks, such as music composition, where Nintendo offered 'IS-NITRO-UIC', a MIDI adapter linking the Nintendo DS to a PC.
The software
By contrast, DS-NITRO-SDK was the software counterpart. This package included utilities for interacting with the devkit, the C and C++ toolchains, and the hardware APIs . Notably, Nintendo forbade any attempt to circumvent the provided APIs to access the hardware directly. Even though games run on bare metal, Nintendo would not approve their distribution if they executed 'prohibited' operations . These included controlling the ARM7 directly or turning off the screens, for instance.
There are understandable reasons for imposing such rules. For example, to maintain a consistent player experience and enforce high quality levels. Although, in my opinion, limiting the ARM7 to I/O duties reflects a lack of trust in developers, which ultimately squandered the CPU's potential...
Freedom of interaction
Dr Kawashima's Brain Training (2005). New categories of games attracted audiences beyond the traditional youth circle.
On the positive side, with all the new forms of interaction available, studios had the opportunity to prioritise gameplay experience over visuals.
For the first time in consumer electronics, there were two screens, a touchscreen, a microphone, Wi-Fi connection, and a real-time clock - all packaged in the same portable console. Consequently, over the years, subsequent games presented novel forms of interaction: some required to hold the console sideways (e.g. Brain Training), others encouraged to fiddle with the hinge (e.g. Hotel Dusk), and some even used the microphone to try to teach English (English Training).
Nintendo even leveraged this wave with a new campaign called Touch Generations, aimed at offering products to an older audience.
In fact, some 'games' were simply standalone applications wrapped in Nintendo's charm, like the Nintendo DS Browser, a port of Opera 8.5 ; or Cooking Guide: Can't Decide What to Eat?, an interactive recipe book. Doesn't this look familiar to the business model that upcoming smartphones (and apps) would later adopt?