Una de las cosas que no le perdono a Nintendo en medio del 35 aniversario de la saga Zelda es la enorme chapuza con Ocarina of Time y Majora’s Mask, juegos que recordemos que recibieron una versión para Nintendo 3DS hace ya unos años y que por tanto podrían portar sin problemas a Nintendo Switch para crear una versión HD tal y como hizo Capcom con Monster Hunter Generations Ultimate.

El motivo de ello es simple: ya que tienes la mejor versión en tus manos que mejor que darle a los usuarios dicha versión. En especial por el hecho que si hablamos de su consola de quinta generación, Nintendo64, la realidad es que no saben como funciona internamente por el hecho que la hicieron otros y es de sobras conocido que fue el socio, SGI, el que literalmente saboteo el rendimiento de Nintendo64 durante su desarrollo.

El jefe del proyecto en SGI era Tim Van Hook que había conseguido crear el sistema de renderizado en 3D de una estación de trabajo de Silicon Graphics en un solo chip. No era tan potente como el Reality Engine, pero permitía lanzar un sistema doméstico que primero ofrecieron a SEGA para luego terminar en manos de Nintendo. Aunque la historia era mucho más compleja que esto, ya que el primer diseño de lo que acabo siendo Nintendo64 tenía poco que ver con el diseño que había creado Van Hook y su equipo.

Cuando en 1994 el acuerdo con Nintendo ya estaba firmado, el marketing de SGI empezó a mostrar las demostraciones de su Reality Engine como si fuera la consola de Nintendo. A nivel interno tanto Van Hook como su equipo desconocían por completo las especificaciones de acuerdo y es que SGI no era una empresa que tuviese una fundición, por lo que al final terminaron escogiendo a NEC, ya que es una empresa nipona y esto le permitió a Nintendo controlar la fabricación y el desarrollo, pero esto además les dio a los ingenieros de SGI las limitaciones con las que tenían que trabajar, es decir:

  • Tamaño del chip.
  • Proceso de fabricación y por tanto densidad.
  • Lista de características del Reality Engine que se podían incluir y cuáles no.

En palabras del propio Tim Van Hook:

«La mayoría de las elecciones importantes: la CPU, la memoria, el socio para la fabricación del RCP (lo cual determino las características de las células de la librería estándar) no fueron decisiones técnicas sino de negocios.»

El RCP en N64 no es más que lo que hoy llamamos un SoC, pero por aquel entonces un LSI, ya que tenía en un solo chip todos los elementos clave del sistema a excepción de la propia CPU. Es decir, en el RCP se encuentran las circuiterías para:

  • Comunicación con la memoria RAM.
  • Gráficos
  • Sonido
  • Comunicación con los periféricos.

¿Y por qué se escogió a NEC? Por el hecho que Hiroshi Yamauchi, presidente de Nintendo, era la empresa dentro de Japón a la que él más terror le tenía, incluso más que a SONY. El siguiente extracto del Game Over de David Sheff es sobre la PC-Engine, pero es el motivo por el cual escogieron a la Nippon Electrical Company para la fabricación de ambos chips de la N64:

Cambiar a Ricoh por NEC para que hiciese los chips de la siguiente consola era quitarse de encima a un rival potencial. Fue una jugada de ajedrez por parte de Yamauchi que muy poca gente es capaz de ver, pero que de retruco influencio que librerías estándar iban a utilizar para diseñarl el chip. Por cierto, os recomiendo leer mi artículo en HardZone sobre el tema. Así pues Nintendo y SGI llegaron a un acuerdo en 1993 con NEC como tercer socio con el objetivo de fabricar una consola por menos de 25.000 yenes.

Y como es sabido toda buena historia tiene un villano y la historia del desarrollo de las consolas de sobremesa de Nintendo lo ha tenido en su mayor representante: Genyo Takeda.

La última respuesta de Takeda en cuanto al hardware de N64 es cuanto menos significativa.

La gran diferencia y lo atractivo que hace Rambus a una máquina de juegos es reducir sus costes. Y esto significa que toma menos espacio cuando estamos construyendo el sistema. Incluso pese a que funciona a 500 MHz puede ser construida con dos capas de PCB. Otras tecnologías requieren dos capas de un circuito impreso y cuando vas de dos capas a cuatro capas acabas por duplicar el coste del circuito impreso. Y esto son $5, lo cual no parece mucho pero cuando construyes millones de estas cosas…

El diseño de SGI estaba pensado para funcionar con memoria SDRAM, al fin y al cabo cuando reciclaron el RCP en forma de su ICE para las estaciones de trabajo O2 ellos utilizaron memoria SDRAM y no RDRAM, lo que lleva a la opinión de que la elección del tipo de memoria fue cosa de SGI para sabotear el rendimiento de la consola y que no se viera que era posible crear un sistema 3D competente por muy bajo precio. Dicho de otra forma a SGI le interesaba que no se supiese que se podía hacer creación de contenido 3D multimedia por una porción del precio de sus carísimas estaciones de trabajo.

En realidad el sabotaje no está en el tipo de memoria escogido sino en la forma en la que la circuitería dentro del RCP que se ha de encargar del acceso a la RAM del sistema actúa, añadiendo una latencia atroz que dejaba al clon del R4300 fabricado por NEC, el VR4200, con un rendimiento paupérrimo que se traduce en un recorte en tasa de fotogramas importante. No es el RCP al que le falta potencia para hacer gráficos, es la CPU que ve recortado enormemente su rendimiento por culpa de la circuitería en el RCP que hace de puente con la memoria.

Pe, pero Urian, ¿qué tiene que ver esto con el tema del 25 aniversario de Zelda y las conversiones de Ocarina of Time y Majora’s Mask?

Todo, tiene que ver todo por el hecho que Nintendo en todo este tiempo ha sido incapaz de hacer funcionar los juegos de N64 a una tasa de fotogramas decente en los emuladores y todo por el hecho que dichos emuladores se basan en el funcionamiento exacto de la consola original.

Si no conocéis la historia básicamente es la siguiente: Martin Hollis, uno de los productores de Rare por aquel momento y con la responsabilidad de producir Goldeneye 007 encontró un fallo en el diseño de la consola:

Escribí un fragmento de código que mostraba icosaedros girando; tantos como fuese posible hasta que la velocidad en fotogramas cayese por debajo de 60 Hz. Al jefe del proyecto en SGI no le gustó demasiado descubrir cuál era el rendimiento de la máquina en términos de triángulos por segundo. Pidió ver mi código con la esperanza de que fuera ineficiente. No lo fue. Más tarde me dijo que SGI casi hizo otro giro del hardware para solucionar el problema, que era con la interfaz de memoria. No sé las cifras exactas, pero a veces se dice que una segunda vuelta del hardware (equivalente a una segunda edición de un libro) cuesta un millón de dólares, y existe el costo adicional de una demora en llegar al mercado que podría ser enorme. Más grande.

Esto fue descubierto en 1994 cuando se empezaron las primeras pruebas para el desarrollo de los juegos y dado que la consola tenía que estar lista inicialmente para 1995 un retraso así era imperdonable. Bien es cierto que hardware salió en 1996 fue en Shoshinkai de 1995 donde este se mostró totalmente funcional.

El problema de la latencia se podía haber solucionado cambiando las velocidades de reloj en las que funcionaba el sistema. El RCP funciona a 62.5 MHz, 1/8 de la velocidad de comunicación de la RDRAM y la CPU funcionaba a 3/2 de la velocidad del RCP y por tanto a 93.75 MHz. Por lo que las velocidades de reloj están relacionadas y no se puede romper la relación en ningún momento.

Por lo que es la RDRAM la que dicta las velocidades de reloj del resto del sistema, en concreto Nintendo escogió los chips de memoria µPD488170L de NEC, los cuales eran chips de 18 Megabits de capacidad cada uno, y que estaban organizados en palabras de 9 bits y por tanto esto le daba una capacidad de 2 megabytes. El noveno bit habitualmente se utilizaba para el ECC, pero en N64 se utilizó para otras funciones. Dicha RAM es capaz de enviar ráfagas de hasta 256 bytes de datos a un tiempo de 2 ns por byte enviado, o lo que es lo mismo, 500 MHz.

Existían modelos de RDRAM a 600 MHz, pero Nintendo quiso que toda la fabricación se llevase en NEC y por tanto escogió dicho chip de memoria. De haber escogido la RDRAM a esa velocidad entonces el RCP hubiese funcionado a 75 MHz y por tanto un 20% más rápido y la CPU a 112.5 MHz. ¿El problema? Van Hook con tal de ahorrar costes hizo el que RDP que se encarga de calcular la geometría del juego también se encargase del audio.

Los desarrolladores obviamente se quejaron, tenían que escoger el dilema entre tener un sistema de audio bueno en los juegos y recortar rendimiento en los gráficos del juego. La respuesta de Van Hook a esa polémica fue también bastante reveladora:

«Me sorprendió que en el desarrollo de juegos aparentemente no pudiesen manejar la desconfianza entre los equipos encargados para el audio y lo gráficos en términos de compartir los recursos a tiempo real» dijo «Parecía que la gente del audio en consolas prefería el uso exclusivo de un pequeño DSP en vez de una porción de un más poderoso procesador de propósito general.

Para que la gente lo entienda, a la hora de emular el RCP para bajar la latencia solo tendrían que aumentar la velocidad de reloj de la memoria emulada, con ello del RCP y las consecuencias serían un recorte de la latencia en los juegos y una subida en la tasa de fotogramas. El problema es que esto distorsiona el sonido del juego.

Y este es el motivo por el cual el problema del framerate en N64 es irresoluble

¿Entendéis ahora el motivo por el cual hubiese sido mejor que Nintendo lanzará las versiones de 3DS para Nintendo Switch para el 35 aniversario de Zelda? Ambas funcionan a 30 FPS sin problemas y no tienen los problemas de la tasa de fotogramas. Aparte de que sus assets gráficos se han visto mejorados. Pero en cambio nos tenemos que tragar esta mierda:

Señores de Nintendo por favor, háganme el favor de:

  • Portar las versiones de 3DS de Lylat Wars/Star Fox 64, Ocarina of Time 3D y Majora’s Mask a Switch como juegos independientes.
  • Hacer un remake de los dos primeros Paper Mario como juegos independientes.
  • Hacerme un F-Zero X con el nivel visual de la versión de Gamecube, pero puesto al día.

No pido más que eso y creo que hubiese sido mejor que rememorar el tordo que fue la N64.