« Arquitectura de la Nintendo 64 (index)

Arquitectura de la Nintendo 64

Chapter 8: Juegos


Tabla de contenidos

  1. Kit de desarrollo
  2. El soporte alternativo

Nintendo mantuvo el cartucho como soporte de almacenamiento en lugar de adoptar el disco óptico. Como consecuencia, los juegos disfrutaron de mayores anchos de banda (una media de 5 MB/s) aunque resultaban más caros de fabricar. El cartucho más grande del mercado tenía una capacidad de 64 MB.

Dentro de los cartuchos, los fabricantes solían incluir memoria adicional (en forma de EEPROM, flash o SRAM con batería) para guardar partidas. Sin embargo, esto fue perdiendo protagonismo a medida que ciertos accesorios (como el Controller Pak) ofrecían almacenamiento alternativo.

Los cartuchos se comunican con el RCP mediante un bus dedicado de 16 bits conocido como Parallel Bus (PBUS) o 'Parallel Interface' (PI) .

Kit de desarrollo

En líneas generales, el desarrollo se realizó principalmente en C y ensamblador, siendo el ensamblador especialmente necesario para sacarle el máximo partido al hardware. Aunque hemos visto que el sistema admite operaciones de 64 bits, las nuevas instrucciones se usaron raramente, ya que en la práctica las instrucciones de 32 bits resultaban más rápidas (dado que la R4300i/VR4300 tiene un bus de datos de 32 bits).

Las librerías del SDK oficial incluían varias capas de abstracción para comandar el RCP. Por ejemplo, las estructuras en C como la Graphics Binary Interface (GBI) se diseñaron para facilitar el ensamblado de Display Lists . Lo mismo se aplica a las funciones de audio, cuya estructura se llamaba Audio Binary Interface (ABI).

En cuanto al desarrollo de microcode, Nintendo proporcionó varios programas preescritos para elegir. Sin embargo, si los desarrolladores querían personalizarlos, se encontraban ante una tarea ardua: el set de instrucciones de la Scalar Unit no estaba documentado inicialmente. Con el tiempo, Nintendo y SGI cambiaron de postura y publicaron documentación y herramientas para la programación de microcode .

Image
Una SGI Indy que encontré en el Centre for Computing History (Cambridge, Reino Unido) cuando visité en agosto de 2024. A modo de comparación, este ordenador alberga una CPU MIPS R4400, la sucesora mejorada del R4000 (en resumidas cuentas, años luz por delante del VR4300).

El hardware de desarrollo incluía estaciones de trabajo suministradas por SGI , como las máquinas Indy equipadas con una placa hija adicional llamada U64, que contiene el hardware y la E/S de la consola de venta al público. También había herramientas disponibles para ordenadores Windows .

Tampoco faltaban las herramientas de terceros: cartuchos especiales con un largo cable plano que se conectaba a la estación de trabajo. Estos cartuchos encajaban en una Nintendo 64 normal, pero incorporaban circuitería interna para redirigir las peticiones de lectura de la consola a la RAM de la estación de trabajo. El proceso de despliegue y depuración consistía en transferir una copia del juego a esa RAM, de modo que, al encender la consola, empezase a leer desde ahí.

El soporte alternativo

Curiosamente, el PBUS se ramifica hacia un conector secundario en la parte inferior de la placa base de la Nintendo 64. Estaba previsto para la Nintendo 64 Disk Drive (64DD), un periférico que funcionaba como un 'piso extra' bajo la consola y albergaba un lector de disco magnético propietario. Sus discos ofrecían hasta 64 MB de capacidad.

Aunque la 64DD solo se lanzó en Japón, abrió la puerta a un soporte alternativo (y más económico) para distribuir juegos.

Image
La Nintendo 64 Disk Drive .
Lanzada el 01/12/1999 en Japón.

Image
La 64DD conectada a la consola .

El soporte magnético es más lento que los cartuchos, con velocidades de transferencia de hasta 1 MB/s, aunque todavía más rápido que los lectores de CD-ROM a 4x. Los discos son de doble cara y operan a Velocidad Angular Constante (CAV, del inglés 'Constant Angular Velocity'), como el posterior miniDVD. El área legible más pequeña se denomina bloque y corresponde a la mitad de un círculo concéntrico en la superficie del disco.

Cabe destacar que el lector no incluye memoria búfer, por lo que los datos se transmiten directamente a la RDRAM para su ejecución. Para lidiar con esa mayor demanda de memoria, Nintendo incluyó el Expansion Pak junto a la 64DD, estandarizando de paso el espacio de RAM ampliado para que todos los juegos de 64DD pudieran aprovecharlo de forma fiable.

Además, parte del disco es reescribible para guardar partidas. El espacio disponible para escritura varía según el tipo de disco (Nintendo ofreció siete tipos).

En cuanto al software, los datos del juego se estructuran con un sistema de archivos llamado 'Multi File System' (MFS), incluido por Nintendo en su SDK . Los juegos podían acceder a los datos del disco a través del sistema de archivos o directamente a nivel de bloque.

La Disk Drive también alberga una ROM interna, denominada 'DDROM', que almacena el código ejecutado por la N64 durante el arranque del disco y muestra la animación de bienvenida, añadiendo de hecho una nueva etapa IPL sobre el proceso de arranque tradicional. La ROM también almacena fuentes (latinas y kanji) y algunos sonidos.


Previous: 7. E/S

Next: 9. Antipiratería / Region Lock


Rodrigo Copetti © 2026 RSS Feed

Ir a la edición moderna

Inicio · Escritos · Soporte · Acerca del autor · Acerca del sitio web