Arquitectura de la Nintendo 64

Un análisis práctico por Rodrigo Copetti

Traducido por Rodrigo Copetti

Edición clásica - Última actualización: 30 de agosto de 2022

Idiomas disponibles: 🇬🇧 - English, 🇵🇱 - Polski, 🇪🇸 - Español, 🇨🇳 - 简体字, 👋 - Añadir traducción


Acerca de esta edición

La edición 'clásico' es una versión alternativa a la contraparte 'moderna'. No requiere Javascript, CSS de última generación o HTML convoluted para trabajar, lo que lo hace ideal para lectores que utilizan herramientas de accesibilidad o navegadores de Internet heredados. Por otra parte, los usuarios de eBooks ahora pueden consultar la edición eBook.

Esta edición es idéntica en cuanto al contenido. Sin embargo, los widgets interactivos han sido simplificado para trabajar con HTML puro. De cualquier manera, esto ofrecerá un enlace al artículo original en caso de que el lector quiera comprobar la "versión completa".

Como siempre, este artículo está disponible en Github para permitir a los lectores reportar errores o proponer cambios. También hay una lista de lectura de apoyo disponible para ayudar a entender la serie. El autor también acepta donaciones para ayudar a mejorar la calidad de los artículos actuales y próximos.


Tabla de Contenidos

  1. Imágenes de apoyo
  2. Una breve introducción
  3. CPU
    1. Simplificando el acceso a la memoria
    2. ¿Sin controlador de DMA?
    3. Diseño de la memoria
    4. Gestión de memoria
  4. Gráficos
    1. Arquitectura
      1. Reality Signal Processor
      2. Reality Display Processor
    2. Demostración rápida
      1. Procesado de Vértices
      2. Procesado de Píxeles
    3. Diseños
    4. Una solución moderna al problema de superficies visibles
    5. Secretos y limitaciones
      1. Atascos
      2. Memoria de Textura
    6. La salida de video universal
  5. Audio
    1. Repertorio musical
    2. Secretos y limitaciones
  6. Sistema Operativo
  7. I/O
    1. Accesorios
  8. Juegos
    1. Kit de Desarrollo
    2. El medio alternativo
  9. Anti-piratería / Region-lock
    1. Puertos sin utilizar
    2. Emulación
  10. Eso es todo amigos
  11. Copyright and permissions
  12. Fuentes / Sigue leyendo
  13. Contribuir
  14. Registro de cambios

Imágenes de apoyo

Modelos

Image
La Nintendo 64
Lanzada el 23/06/1996 en Japón, el 29/09/1996 en América y el 01/03/1997 en Europa

Motherboard

Image
Motherboard
Mostrando la revision 'NUS-CPU-03'.
Versiones posteriores redujeron el número de chips requeridos para la codificar el audio y video
El conector de 'Disk Drive' se encuentra en la otra cara
Image
Motherboard con partes importantes etiquetadas

Diagrama

Image
Diagrama de arquitectura

Una breve introducción

El objetivo de Nintendo era dar a los jugadores los mejores gráficos posibles, para llevar a cabo esta tarea, se asociaron con uno de los mayores expertos en gráficos de la industria para producir el chip definitivo.

El resultado fue una bonita consola para toda la familia… y un manual de instrucciones de 500 páginas para los desarrolladores.

No te preocupes, te prometo que este artículo no va a ser tan largo como el manual… ¡Disfrútalo!


CPU

El procesador principal es un NEC VR4300 que corre a 93.75 MHz, una versión compatible binaria del MIPS R4300i de Silicon Graphics que incluye:

También se incluye en este paquete una Floating-point unit o ‘FPU’ (Unidad de coma flotante) de 64 bits. La VR4300 la identifica como un co-procesador (CP1) aunque la unidad está instalada junto a la ALU (unidad aritmética) y solo se accede a ella a través de esa unidad, con lo que no hay co-procesamiento de por si. De todas maneras, la FPU contiene un archivo de registro dedicado y acelerará las operaciones con números de coma flotante de 64 y 32 bits. La FPU sigue el estándar IEEE754.

Simplificando el acceso a la memoria

La manera en la que la RAM está ensamblada sigue la arquitectura de memoria unificada (o ‘UMA’, del inglés ‘Unified-memory Architecture’) donde toda la RAM disponible se centraliza en un solo lugar y cualquier otro componente que requiera RAM accederá a esta ubicación compartida. El componente que arbitra su acceso es, en este caso, la GPU.

La razón por la cual se eligió este diseño es por el ahorro considerable en costes de producción, mientras que por otro lado, incrementa la contención de acceso si no se gestiona adecuadamente.

¿Sin controlador de DMA?

Debido a la arquitectura de memoria unificada, la CPU ya no tiene acceso directo a la RAM, por lo que la GPU también proporciona la funcionalidad DMA (‘Direct Memory Access’).

Diseño de la memoria

Aparte de la UMA, la estructura de la RAM es un poco complicada, así que trataré de explicarlo en términos simples. Aquí va…

El sistema contiene físicamente 4,5 MB de RAM, sin embargo, está conectada a un bus de datos de 9 bits donde el 9º bit está reservado para la GPU (más detalles en adelante). Como consecuencia, cada componente excepto la GPU sólo encontrará hasta 4 MB.

Image
Trazado de la memoria en este sistema.
Asumo que la velocidad del CPU-RCP bus es la velocidad de reloj del RCP o la de la CPU, pero aún no he conseguido confirmarlo.

El tipo de memoria RAM instalada en la placa se llama Rambus DRAM o ‘RDRAM’ para abreviar, este fue otro diseño que compitió con SDRAM para convertirse en el siguiente estándar. RDRAM está conectada en serie (donde las transferencias se hacen de un bit a la vez) mientras que SDRAM utiliza una conexión paralela (transfiere múltiples bits a la vez)..

La latencia de la RDRAM es directamente proporcional al número de bancos instalados, por lo que en este caso, con la cantidad de RAM que tiene este sistema, la latencia resultante es importante (un post en el foro beyond3d menciona que es alrededor de 640ns). Aunque esto es compensado con una alta velocidad de reloj de 250 MHz (~2.6 veces más rápida que la CPU) aplicada a los bancos de memoria. Nintendo afirma que RDRAM puede proveer una transferencia de datos de alta velocidad a 500 MB por segundo para leer o escribir datos consecutivos.

Además, hay otro debate en los foros de beyond3d que afirma que Nintendo escogió los bancos de memoria uPD488170L de NEC por su placa base. Estos chips utilizan una tecnología denominada ‘Rambus Signaling Logic’ que duplica la tasa de transferencia. Esto puede explicar porque algunas fuentes declaran que la tasa ’efectiva’ es 500 MHz

Finalmente, la cantidad de RAM disponible en esta consola se puede ampliar instalando el accesorio Expansion Pak: Una bonita pequeña caja que incluye 4,5 MB. Curiosamente, el bus de RAM debe ser terminado, por lo que la consola siempre se vende con un terminador (llamado Jumper Pak) instalado en el lugar del Expansion Pak. Ahora, uno podría preguntarse, ¿qué pasaría si encendemos la consola sin ningún Pak instalado? Literalmente nada, ¡te quedas con una pantalla en blanco!

Gestión de memoria

El VR4300 incluye otro procesador llamado System Control Coprocessor (CP0) que contiene una Unidad de gestión de memoria (o MMU, del inglés) y un Translation Lookaside Buffer (TLB), el primero controla como la memoria es organizada y almacenada en el caché. El VR4300 puede acceder hasta 4 GB de direcciones de memoria de 32 bit, pero como ya hemos observado, no tenemos 4 GB de RAM en esta consola (incluso después de considerar la I/O mapeada en memoria). Por lo tanto, la MMU se hace cargo de el direccionamiento de memoria y provee un útil mapeado de memoria donde la memoria física se refleja varias veces. Como consecuencia, las ubicaciones de memoria se tratan como ‘direcciones virtuales’ (en vez de ‘direcciones físicas). Además, el TLB permite a desarrolladores poder definir su propio mapeado de memoria en algunos reflejos sin (considerable) bajas al rendimiento.

Al principio, esto puede parecer innecesario, pero cada mirror (llamado ‘segmento’) está conectado a circuitos diferentes (por ejemplo, caché de L1, sin caché, dirección de TLB), así los desarrolladores pueden optimizar su uso seleccionando el segmento más apropiado para la tarea.

Algunos segmentos están hechos para diferenciar ubicaciones ‘kernel’ de las ubicaciones ‘usuario’ por razones de seguridad. La N64 siempre opera en modo ‘kernel’. Asimismo, el segmento ‘kernel no-TLB almacenado en caché’ (llamado ‘KSEG0’) es el más común para juegos.

La MMU también puede operar en modo 64 bit, donde el espacio para direcciones virtuales cubre 1 TB de direcciones. Aunque por razones obvias, no hace falta explicar este modo en este artículo


Gráficos

Lo que se ve en la pantalla esta producido por un inmenso chip diseñado por Silicon Graphics llamado Reality Co-Processor que corre a 62,5 MHz. Este paquete contiene un montón de circuitería así que no te preocupes si te resulta difícil de seguir, el sub-sistema de gráficos tiene una arquitectura muy compleja.

Este diseño se basa en la filosofía de que la GPU no debe ser una ‘simple’ rasterizadora como la de <a href=“https://classic.copetti.org/writings/consoles/playstation/#graphics"la competencia. Por el contrario, debe ser capaz de acelerar los cálculos geometricos (aliviando la carga de la CPU) y para ello, es necesario más circuitería.

Arquitectura

Este chip está dividido en tres módulos principales, dos de los cuales se utilizan para el procesamiento de gráficos:

Reality Signal Processor

Image
Arquitectura del RSP

También conocido como RSP, es simplemente otro paquete con una CPU compuesto por:

Para operar este módulo, la CPU almacena en la RAM una serie de comandos llamados Display list junto con los datos que serán manipulados, luego el RSP lee dicha lista y aplica las operaciones requeridas sobre los datos. La funcionalidad disponible incluye transformaciones geométricas (como la proyección en perspectiva), clipping e iluminación.

Esto parece sencillo, pero ¿cómo realiza estas operaciones? Bueno, aquí está la parte interesante: A diferencia de sus competidores (PS1 y Sega Saturn), el motor de la geometría no está fijado. En su lugar, el RSP contiene un poco de memoria (4 KB para instrucciones y 4 KB para datos) para almacenar microcode, un pequeño programa, con no más de 1000 instrucciones, que implementa la tubería de gráficos. En otras palabras, dirige a la Scalar Unit como debe operar nuestros gráficos. La CPU envía microcode mientras el programa se encuentra en ejecución.

Nintendo proporcionó diferentes versiones de microcode para elegir y, similarmente a los modos de background de SNES, cada uno balancea los recursos a su manera.

Reality Display Processor

Image
Arquitectura del RDP

Una vez que el RSP termine de procesar los datos de nuestros polígonos, empezará a enviar comandos de rasterización al siguiente módulo, el RDP, para dibujar el frame. Estos comandos se envían por un bus dedicado llamado XBUS o por la RAM principal.

El RDP es otro procesador (esta vez con funcionalidad fija) que incluye múltiples motores utilizados para rasterizar vectores, mapear las texturas en nuestros polígonos, mezclar colores y componer el nuevo frame.

Este puede procesar triángulos o rectángulos como primitivos, el último es útil para dibujar sprites. El motor de rasterización del RDP contiene los siguientes bloques:

La RDP proporciona cuatro modos de operación, cada uno combina estos bloques de forma diferente para optimizar operaciones específicas.

Dado que este módulo requiere actualizar constantemente el frame-buffer, la RAM se maneja de forma diferente: ¿Recuerdas el inusual ‘byte’ de 9 bits? El noveno bit se utiliza para los cálculos relacionados con el frame-buffer (z-buffering y el antialiasing) y sólo se puede acceder a él a través de la Memory interface.

El frame que se obtiene debe ser enviado al Video Encoder para visualizarlo en pantalla (DMA y el Video Interface son esenciales para llevar a cabo esto).

En papel, las capacidades máximas son una profundidad de color de 24 bits (16,8 millones de colores) y una resolución de 720x576 (o 640x480 en la región NTSC). En la práctica no se utilizan todos, ya que hacer uso de las capacidades máximas puede ser muy costoso en términos de recursos, por lo que los programadores tenderán a utilizar cifras más bajas para proveer suficientes recursos a otros servicios.

Demostración rápida

Pongamos todas las explicaciones anteriores en perspectiva. Para ello tomaré prestado el Super Mario 64 de Nintendo para demostrar, en pocas palabras, cómo se forma un frame:

Procesado de Vértices

Image
Vista primitiva de nuestra escena
Para ahorrar polígonos, algunos caracteres se modelan con sprites (cuadriláteros)

Inicialmente, nuestros modelos 3D se encuentran en la ROM del cartucho pero para mantener un ancho de banda constante, necesitamos copiarlos a la RAM primero. En algunos casos, los datos se pueden encontrar ya comprimidos en el cartucho, por lo que la CPU tendrá que descomprimirlo antes de utilizarlo.

En cuanto este completado, es hora de construir la escena usando nuestros modelos, la CPU podría hacerlo por sí misma pero esto tardaría toda una vida, así que la tarea se delega al RCP. La CPU se limitará a enviar órdenes al RCP, esto se hace llevando a cabo las siguientes tareas:

  1. Componer la Display List que contiene las operaciones a realizar por el RSP y almacenarla en la RAM.
  2. Apuntar al RSP donde se encuentra la Display List.
  3. Enviar el microcode al RSP para poner en marcha la Scalar Unit.

Seguidamente, el RSP comenzará a realizar las tareas y el resultado será enviado al RDP en forma de comandos de rasterización.

Procesado de Píxeles

Image
Frame renderizado (Tachán!)

Hasta ahora hemos logrado procesar nuestros datos y aplicar algunos efectos sobre ellos, pero todavía tenemos que:

Como puedes adivinar, estas tareas serán realizadas por el RDP. Para que esto funcione, las texturas deben ser copiadas desde la RAM a el TMEM usando DMA.

El RDP módulo tiene una motor fijo pero permite seleccionar el modo de funcionamiento en base a la tarea que se llevará a cabo, ayudando a mejorar el framerate.

Una vez que el RDP termine de procesar los datos, escribirá el mapa de bits resultante en el frame-buffer que se encuentra dentro de la RAM. Una vez terminado, la CPU debe transferir el nuevo frame a la Video Interface (VI), preferiblemente usando el DMA, que a su vez la enviará al Video Encoder para su visualización.

Diseños

He aquí algunos ejemplos de personajes previamente diseñados en dos dimensionas para la Super Nintendo, pero que han sido rediseñados para la nueva era de tres dimensiones. Los modelos son interactivos así que os animo a que les echéis un vistazo.

Image Image Image Modelo interactivo disponible en la edición moderna
The Legend of Zelda: Ocarina of Time (1998)
785 triángulos
Image Image Image Modelo interactivo disponible en la edición moderna
Kirby 64: The Crystal Shards (2000)
516 triángulos

Una solución moderna al problema de superficies visibles

Si has leído sobre las consolas anteriores, probablemente estás al tanto del interminable problema de visibilidad de superficies y tal vez pienses que la única solución es mediante la ‘clasificación de polígonos’. Bueno, por primera vez en esta serie, el RDP presenta una solución basada en hardware llamada Z-buffering. En pocas palabras, el RDP asigna un nuevo buffer llamado Z-Buffer en la memoria. Este tiene las mismas dimensiones que un frame-buffer, pero en lugar de almacenar los valores RGB (rojo, verde y azul), cada entrada contiene la profundidad del píxel más cercano con respecto a la cámara (llamado ‘z-value’).

Una vez que el RDP rasteriza los vectores, el z-value del nuevo píxel se compara con el valor respectivo en el Z-buffer. Si el nuevo píxel contiene un z-value más pequeño, esto significa que el nuevo píxel se posiciona delante del anterior, por lo que se sobrescribe en el frame-buffer y z-buffer. De lo contrario, el píxel se descarta.

En general, el nuevo algoritmo es muy beneficioso: Los programadores ya no tienen que preocuparse por implementar métodos para clasificar polígonos basados en software que tienden a consumir bastantes recursos de la CPU. Sin embargo, el Z-buffer no previene procesar geometría innecesaria (eventualmente descartada o sobrescrita, que consumen recursos de todas maneras). Para ello, el motor del juego puede optar por incluir un algoritmo de ‘occlusion culling’ para descartar la geometría que no será visible, lo antes posible.

Secretos y limitaciones

Es evidente que SGI invirtió mucha tecnología en este sistema. Sin embargo, esta sigue siendo una consola para el hogar y como tal, debe mantener un bajo coste. Por ahí, ciertas decisiones se convirtieron en retos para los programadores:

Atascos

Debido al gran número de componentes y operaciones en la tubería de gráficos, el RCP terminó siendo muy susceptible a burbujas de segmentación: Una situación indeseable caracterizada por subcomponentes que se mantienen inactivos durante períodos considerables de tiempo porque los datos requeridos se retrasan en llegar.

Esto siempre se manifestará en una degradación del rendimiento y depende del programador para evitarlos. Aunque para facilitar las cosas, algunas CPUs como la Scalar Unit implementan una característica llamada Bypassing que permite ejecutar instrucciones similares a un ritmo más rápido para evitar pasar por etapas de ejecución que pueden ser omitidas.

Por ejemplo, si tenemos que computar múltiples instrucciones ADD (suma) a la vez, no hay necesidad de escribir el resultado de la suma en el registro destinatario y luego leerlo de nuevo para ejecutar el siguiente ADD. En vez de eso, se puede usar el mismo registro intermediario para llevar al cabo todas las adiciones y al final, enviar el resultado al registro destinatario una vez que el último ADD se completa.

Memoria de Textura

El RDP usa 4 KB de TMEM (‘Texture Memory’) como única unidad para procesar las texturas. Desafortunadamente, en la práctica 4 KB resultaron ser insuficientes para las texturas de alta resolución. Además, si se utiliza el mipmapping, la cantidad de memoria disponible se reduce a la mitad.

Como resultado, algunos juegos utilizan colores sólidos con sombreado Gouraud (como Super Mario 64) mientras que otros hacen uso de texturas precalculadas (por ejemplo, cuando hay que mezclar varias capas).

La salida de video universal

Nintendo siguió usando la salida ‘universal’ llamada Multi Out como su predecesor, pero desafortunadamente, ¡ya no transmite más la señal RGB!. Esto suena a otra medida para acaparar costes, ya que la misma señal no se había aprovechado en la consola anterior.

Las buenas noticias son que los tres canales pueden ser reconstruidos en las primeras revisiones de la consola mediante la soldadura de algunos cables y la instalación de un amplificador de señal (tiende a ser barato). Esto es debido a que el convertidor digital a analógico de video envía una señal RGB al codificador de video. Sin embargo, las revisiones posteriores de la placa base combinaron los dos chips, así que la única solución disponible es de sobrepasar el video DAC y el codificador con algún chip especializado que pueda exponer la señal RGB.


Audio

Antes de entrar en detalles, definamos los dos puntos opuestos del subsistema de audio de la N64:

Entonces, ¿cómo conectamos ambos extremos? Las consolas normalmente incluyen un chip de audio dedicado que hace el trabajo por nosotros. Desafortunadamente, la Nintendo 64 no tiene ese chip dedicado, por lo que esta tarea se distribuye a través de estos componentes:

Los datos resultantes son, como se espera, datos que contienen la waveform. Estos se envían al bloque de Audio Interface o ‘AI’ que los transferirá al Digital-to-Analog converter. La waveform resultante contiene dos canales (ya que nuestro sistema es estéreo) con una resolución de 16-bits cada uno.

Image
Resumen de cómo se tiende a programar el motor de audio

Repertorio musical

Es hora de echar un vistazo a las bandas sonoras hechas para la N64. La verdad es que hay demasiadas (y buenas) para mencionarlas todas en este artículo, así que os dejo algunas que me llamaron la atención:

The Legend of Zelda: Majora’s Mask (2000)
La música de este juego está ligada a su atmósfera intimidante
Bomberman Hero (1998)
Este juego tiene una agradable y única banda sonora al estilo ‘House’

Secretos y limitaciones

Debido a este diseño, las limitaciones de este sistema dependerán de la implementación:

Por estas razones, los jugadores pueden llegar a notar que los ports de N64 contienen música de menor calidad o repetitivos. Un método para superar esta limitación consistía en implementar un secuenciador en software que pudiera ‘construir’ los samples mientras el juego se ejecutaba, esto requiere un banco de sonidos (similar a la música MIDI).


Sistema Operativo

Al igual que la PS1 y Saturn, los juegos de N64 hablan directamente con el hardware. Sin embargo, no hay rutinas de la BIOS disponibles para simplificar algunas operaciones. Como sustituto, los juegos incorporan un pequeño sistema operativo que proporciona una buena cantidad de abstracción para manejar eficientemente la CPU, la GPU y el I/O.

Este no es el Sistema Operativo de escritorio convencional que podemos imaginar al principio, es sólo un micro-kernel con el menor tamaño posible que proporciona la siguiente funcionalidad:

Considerándolo todo, estas funciones son críticas para organizar audio, video y tareas lógicas de juegos que deben funcionar al mismo tiempo.

El kernel se almacena automáticamente al utilizar librerías de Nintendo. Además, si los programadores deciden no incluir una de las librerías, la porción respectiva del kernel se quita para evitar desperdiciar el espacio del cartucho.


I/O

Como ya sabéis, el I/O no está conectado directamente a la CPU, así que el tercer módulo del RCP (que no he mencionado hasta ahora) sirve como interfaz I/O. Básicamente, se comunica con la CPU, los controladores, el cartucho de juego y los DAC de Audio/Video.

Accesorios

El mando de Nintendo 64 incluye un conector para enchufar accesorios. Unos ejemplos de accesorios comerciales incluyen:

Todos los accesorios conectados al mando son manejados por el Peripheral Interface (PIF), un bloque escondido que también controla la seguridad. El RCP se comunica al PIF utilizando un ‘muy lento’ (*citado del manual de programación) Bus de serie.


Juegos

Nintendo se aferró al cartucho como medio para el almacenamiento y como consecuencia, los juegos disfrutaron de mayores anchos de banda (un promedio de 5 MB/s según Nintendo) mientras que costaban más de producir. El cartucho más grande que hubo en el mercado tiene 64 MB.

Dentro de los cartuchos, los fabricantes pueden incluir memoria extra (en forma de EEPROM, flash o SRAM con una batería) para guardar partidas. Sin embargo, no es un requerimiento estricto ya que algunos accesorios también podían ser usados para almacenar los progresos.

Los cartuchos se comunican al RCP utilizando un bus dedicado de 16 bits llamado Bus Paralelo (PBUS) o ‘Interfaz Paralela’ (PI).

Kit de Desarrollo

En términos generales, desarrollar para la N64 se hacía principalmente en C, aunque también se requería ensamblador para lograr un mejor rendimiento. Si bien este sistema contenía un conjunto de instrucciones de 64 bits, rara vez se utilizaban las de 64 bits, ya que en la práctica, las instrucciones de 32 bits resultaban ser más rápidas de ejecutar y requerían la mitad del almacenamiento.

Por otra parte, las librerías en SDK oficial contenían varias capas de abstracciones para comandar el RCP. Por ejemplo, la Graphics Binary Interface o ‘GBI’ era una estructura diseñadas para ensamblar las Display Lists más fácilmente, lo mismo se aplicaba a las funciones de audio (su estructura se llamó Audio Binary Interface o ‘ABI’).

En cuanto al uso de microcode, Nintendo proporcionó varias opciones de microcode escrito para elegir. Sin embargo, en el caso que los desarrolladores quieran modificarlo, se verían con una ardua tarea: Las instrucciones de la Scalar Unit no estaban inicialmente documentadas, aunque luego, Nintendo cambió de posición y SGI finalmente publicó cierta documentación para habilitar el desarrollo de nuevo microcode.

El hardware utilizado para el desarrollo de videojuegos incluía estaciones de trabajo suministradas por SGI, como la máquina Indy que venía con una placa extra llamada U64 que contiene el hardware y I/O de la consola. También se suministraron herramientas para ordenadores con Windows instalado.

Otras herramientas proporcionadas por terceros consistían en cartuchos con un largo cable que se conectaba a la estación de trabajo. Este cartucho se insertaba en una Nintendo 64 pero incluía un circuito interno para redirigir los comandos de lectura de la consola a la RAM de la estación de trabajo. Una vez acabado, la consola se encendía y comenzaba a leer desde la RAM (del ordenador), esto permitía llevar a cabo la implementación y depuración del juego.

El medio alternativo

Adicionalmente, El PBUS se ramifica a otro conector en la parte inferior de la placa base de la N64. Esto estaba destinado a ser utilizado por la Nintendo 64 Disk Drive (64DD) aún inédita, una especie de ‘piso adicional’ que contiene un lector de disco magnético patentado. Sus discos contienen hasta 64 MB de capacidad. Aunque solo se lanzó en Japón, la unidad de disco abrió la puerta a un medio alternativo (y más barato) para distribuir juegos.

Image
La Nintendo 64 Disk Drive.
Lanzada el 01/12/1999 en Japón.
Image
El 64DD conectada a la consola.

El medio magnético es más lento que los cartuchos, con velocidades de transferencia de hasta 1 MB/seg, aunque más rápidos que los lectores de 4X CD-ROM. Los discos so de doble-cara y operan a una ‘Velocidad Angular Constante’ (como la posterior miniDVD). El área lejible más pequeña se llama ‘block’ y es la mitad de un círculo concéntrico.

El lector no incluye un búfer de memoria, así que los bits leídos son almacenados en RDRAM para ejecución. Nintendo incluyó la unidad de expansión de RAM con la 64DD, por lo que compensa la necesidad de más RAM (además de estandarizar la disponibilidad de RAM extendida para todos los juegos de la 64DD).

Además, partes del disco se pueden reescribir para permitir el almacenamiento de partidas, los discos utilizados determinan la cantidad de área de escritura (Nintendo proporcionó siete tipos). Del lado de software, los datos del juego son estructurados con un sistema de archivos llamado ‘Multi File System’ (MFS) que Nintendo proveyó en su SDK. Juegos pueden acceder los datos del disco utilizando el sistema de archivos o de forma ‘bloque a bloque’, la última se basa en otra librería llamada ‘Leo’ para funciones de bajo nivel.

La unidad de disco también alberga una ROM interna (denominada “DDROM”) que almacena el código que ejecuta la N64 para arrancar el disco y mostrar la animación de bienvenida, esto se denomina “Cargador de programa inicial” (IPL). La ROM también almacena tipos de letra (Latín y Kanji) y algunos sonidos. Esta ROM solo es disponible en tiendas (las unidades de desarrollo dependían de programas externos cargados a través del kit de desarrollo).


Anti-piratería / Region-lock

El sistema antipiratería es una continuación del CIC de SNES. Como sabéis, la detección de piratería y el ‘region lock’ son posibles gracias al chip CIC (que debe estar presente en cada cartucho de juego autorizado), la Nintendo 64 mejoró este sistema requiriendo que diferentes juegos tuvieran una variante específica del CIC para asegurarse de que el cartucho no era una falsificación o contenía un clon del CIC. El PIF realizaba comprobaciones por medio de checksums al principio y durante la ejecución juego para supervisar el CIC instalado en el cartucho.

Si por alguna razón el PIF considera que el cartucho insertado no es válido, este bloquea la ejecución del juego.

El region-lock se realiza alterando ligeramente la forma externa del cartucho entre las diferentes regiones para que el usuario no pueda insertar físicamente el juego en un N64 de una región diferente.

En general, no hubo demasiada preocupación por la piratería gracias al uso del cartucho como medio, aunque los precios de los juegos eran tres veces más altos que los dependientes del CD.

Puertos sin utilizar

Por muy tonto que parezca, Nintendo dejó una ‘puerta’ abierta: El puerto del Disk Drive.

Image
El Doctor V64 conectado a la consola
Image
El V64 visto desde atrás, mostrando conectores especiales para A/V

Algunas compañías, mediante ingeniería inversa, estudiaron la interfaz para desarrollar hardware propietario; Los nuevos productos lanzados llegaron a preocupar a Nintendo debido a sus capacidades para ejecutar juegos piratas.

Supongo que el que vale la pena mencionar es el Doctor v64, este dispositivo tiene la misma forma que el Disk Drive pero incluye una unidad de CD-ROM.

Esta expansión puede grabar el contenido del cartucho a un CD, aunque lo opuesto (leer la ROM desde un CD) también es posible.

Emulación

Cuando yo era niño solía jugar a algunos juegos de Nintendo 64 en un ordenador con un Pentium II usando un emulador, no funcionaba tan mal, pero años más tarde me pregunté cómo narices era capaz de emular una máquina de 64 bits tan tranquilamente si, entre muchas cosas, mi ordenador apenas tenía la suficiente RAM para mantener la tarjeta gráfica integrada con vida.

La verdad es que, mientras que reproducir la arquitectura de esta consola puede ser un tarea bastante difícil, cosas como el microcode dan una pista de lo que la consola está intentando hacer, y cómo los emuladores no tienen que ser precisos, pueden aplicar suficientes optimizaciones para proporcionar más rendimiento a cambio de una emulación idéntica.

Otro ejemplo son las instrucciones de 64 bits, ya que los juegos apenas las utilizan, la velocidad de emulación raras veces declina cuando se lleva a cabo en un ordenador de 32 bits.


Eso es todo amigos

Image
Mi N64 compartida en la casa de un amigo.
Mientras que yo solo quería la consola para este artículo, mi colega siempre soñó por un N64 DD, así que compramos un set muy completo (pero caro) de la N64 japonesa con un DD para evitar gastar demasiado de manera individual. Después, le instalé el N64RGB para que podamos conectarlo a una TV moderna; y el resultado es un buen trozo de entretenimiento (y tema de conversación!).

Debo decir que este artículo puede ser el más largo que he escrito, pero espero que al menos te haya sido de interés.

Probablemente me tome los siguientes días para ordenar algunas cosas en la web en lugar de empezar a escribir el siguiente artículo.

De todas formas, si te gustan mis artículos y me quieres ayudar, por favor echa un vistazo aquí. Si tienes algún comentario o sugerencia, no dudes en enviarme un email aquí.

¡Hasta la próxima!
Rodrigo


Contribuir

Este artículo forma parte de la serie de Arquitectura de consolas. Si te ha resultado interesante, por favor considere donar. Tu contribución se usará para tener mas herramientas y recursos que ayudarán a mejorar la calidad de los actuales artículos y próximos.

Donate with PayPal
Become a Patreon

También puedes comprar la edición eBook en inglés. Trato las ganancias como donaciones.

Image

Esta es la lista de herramientas adquiridas o interesantes a adquirir:

Interesting hardware to get (ordered by priority)

De alternativa, puedes ayudar sugiriendo cambios y/o agregando traducciones.


Copyright and permissions

This work is licensed under a Creative Commons Attribution 4.0 International License. You may use it for your work at no cost, even for commercial purposes. But you have to respect the license and reference the article properly. Please take a look at the following guidelines and permissions:

Article information and referencing

For any referencing style, you can use the following information:

For instance, to use with BibTeX:

@misc{copetti-nintendo64,
    url = {https://classic.copetti.org/writings/consoles/nintendo-64/},
    title = {Nintendo 64 Architecture - A Practical Analysis},
    author = {Rodrigo Copetti},
    year = {2019}
}

or a IEEE style citation:

[1]R. Copetti, "Nintendo 64 Architecture - A Practical Analysis", Copetti.org, 2019. [Online]. Available: https://classic.copetti.org/writings/consoles/nintendo-64/. [Accessed: day- month- year].

Special use in multimedia (Youtube, Twitch, etc)

I only ask that you at least state the author’s name, the title of the article and the URL of the article, using any style of choice.

You don’t have to include all the information in the same place if it’s not feasible. For instance, if you use the article’s imagery in a Youtube video, you may state either the author’s name or URL of the article at the bottom of the image, and then include the complete reference in the video description. In other words, for any resource used from this website, let your viewers know where it originates from.

This is a very nice example because the channel shows this website directly and their viewers know where to find it. In fact, I was so impressed with their content and commentary that I gave them an interview 🙂.

Appreciated additions

If this article has significantly contributed to your work, I would appreciate it if you could dedicate an acknowledgement section, just like I do with the people and communities that helped me.

This is of course optional and beyond the requirements of the CC license, but I think it’s a nice detail that makes us, the random authors on the net, feel part of something bigger.

Third-party publishing

If you are interested in publishing this article on a third-party website, please get in touch.

If you have translated an article and wish to publish it on a third-party website, I tend to be open about it, but please contact me first.


Fuentes / Sigue leyendo

Anti-Piratería

Audio / Vídeo

Bonus

CPU

Juegos

Sistema Operativo

Fotografía