Aquí hay mucho de lo que hablar, principalmente porque las capacidades de esta consola inspiraron a programadores y artistas a desarrollar diseños innovadores y nuevas formas de interacción. Veamos...
Soporte
Esta consola ejecuta juegos procedentes de tres fuentes, aunque solo dos de ellas pueden hacer un aprovechamiento 'completo' del hardware:

Ejemplo de un juego comercial en Slot-1.
- Tarjetas NDS o 'Slot-1': Este es el soporte principal para cargar juegos nativos de DS y el único formato utilizado para la distribución comercial.
- Cartucho GBA o 'Slot-2': Este slot es uno de los pilares de la compatibilidad nativa con la Game Boy Advance. Sin embargo, dado que los juegos del Slot-1 también pueden acceder a esta interfaz, se desarrollaron cartuchos de expansión para mejorar los programas de DS. Estos aportaban RAM adicional, mandos de entrada extra (como el Guitar Hero Grip Controller) o retroalimentación háptica (es decir, el Rumble pack).
- Download Play: También conocido como 'MultiBoot inalámbrico', permite que otra consola que ejecute un juego del Slot-1 transfiera un programa mediante comunicación inalámbrica. El contenido descargado se almacena en la WRAM y arranca una vez completada la transferencia. Como la WRAM es volátil, los datos descargados se borran al apagar la consola.
- Los establecimientos comerciales autorizados utilizaron esta función para instalar Estaciones de Descarga, donde los consumidores podían descargar demos de juegos.
Estructura del programa
Ya has visto que la BIOS de esta consola debe dividirse en código ARM9 y ARM7. Pues bien, el mismo principio se aplica en gran medida a los juegos. Por tanto, la ROM dentro de las tarjetas NDS se organiza en las siguientes áreas:
- Cabecera (4 KB): Contiene metadatos, incluido el punto de entrada de cada ejecutable, información del fabricante y el logotipo de Nintendo .
- Área segura (16 KB): Utilizada para la protección contra copia. Los detalles se tratan en la sección 'Antipiratería'.
- Contenido principal (tamaño variable): El espacio restante almacena los ejecutables y los datos del juego (gráficos, sonidos, etc.). Además, la disposición de estos datos fue definida por el kit de desarrollo oficial de Nintendo o 'SDK' (una dependencia obligatoria para los juegos comerciales), que implementó un sistema de archivos estructurado de forma jerárquica con archivos y directorios .
Ecosistema de desarrollo
Para los estudios interesados en desarrollar juegos para esta consola, Nintendo suministraba tanto kits de hardware como un kit de desarrollo de software (SDK) repleto de utilidades.
El hardware
El kit de desarrollo, llamado IS-NITRO-EMULATOR, consistía en una unidad azul de tamaño mediano que albergaba la mayor parte del hardware interno y los componentes de E/S de la DS . A ella se conectaba un cable grueso unido a una carcasa ficticia de Nintendo DS, que servía de 'mando' y pantalla. A petición, el devkit podía equiparse con capacidades opcionales como salida de audio/vídeo, una interfaz Wi-Fi real (por defecto, el Wi-Fi se emulaba mediante Ethernet) y soporte para depuración. Personalmente, esperaba que esto último fuese estándar, aunque los equipos de pruebas también podían utilizarlas.
El kit lee tarjetas DS, y Nintendo también proporcionó tarjetas de desarrollo regrabables para facilitar el trabajo de los desarrolladores. Estas tenían una carcasa más grande con chips de respaldo intercambiables .
En definitiva, estos son solo algunos ejemplos, pero a lo largo del ciclo de vida de la consola se vendieron muchos otros equipos para ayudar con tareas específicas, como la composición musical, para lo que Nintendo ofrecía el 'IS-NITRO-UIC', un adaptador MIDI que conectaba la Nintendo DS a un PC.
El software
Por su parte, DS-NITRO-SDK era el complemento en software. Este paquete incluía utilidades para interactuar con el devkit, las cadenas de herramientas de C y C++, y las APIs de hardware . Cabe destacar que Nintendo prohibía cualquier intento de saltarse las APIs proporcionadas para acceder directamente al hardware. Aunque los juegos se ejecutan sobre el metal desnudo, Nintendo no aprobaría su distribución si realizaban operaciones 'prohibidas' , como controlar el ARM7 directamente o apagar las pantallas.
Existen razones comprensibles para imponer estas normas; por ejemplo, mantener una experiencia de juego coherente y garantizar niveles de calidad elevados. Aunque, en mi opinión, limitar el ARM7 a tareas de E/S refleja una falta de confianza en los desarrolladores, lo que en última instancia desperdició el potencial de la CPU...
Libertad de interacción

Dr. Kawashima's Brain Training (2005). Las nuevas categorías de juegos atrajeron a un público más allá del círculo juvenil tradicional.
Por el lado positivo, gracias a todas las nuevas formas de interacción disponibles, los estudios tuvieron la oportunidad de priorizar la experiencia de juego sobre los gráficos.
Por primera vez en la electrónica de consumo, dos pantallas, una pantalla táctil, un micrófono, conexión Wi-Fi y un reloj en tiempo real convivían en la misma consola portátil. En consecuencia, con el paso de los años, los juegos posteriores presentaron formas de interacción novedosas: algunos requerían sostener la consola de lado (como Brain Training), otros animaban a jugar con la bisagra (como Hotel Dusk) e incluso algunos usaban el micrófono para intentar enseñar inglés (English Training).
Nintendo aprovechó esta corriente con una nueva campaña llamada Touch Generations, orientada a ofrecer productos a un público de mayor edad.
De hecho, algunos 'juegos' eran simplemente aplicaciones independientes envueltas en el encanto de Nintendo, como el Nintendo DS Browser, una versión del Opera 8.5 , o Cooking Guide: Can't Decide What to Eat?, un libro de recetas interactivo. ¿No se asemeja esto al modelo de negocio que los futuros smartphones (y las apps) adoptarían poco después?