Blog Personal.

Nintendo, Opinión, Retro

Sobre el Leak de Nintendo

Comentario Original:

Hola Urian, un gusto saludaros nuevamente. Primera vez que comento desde que cambiaste al nuevo blog sin la coletilla de wordpress.

Me gustaría que hablaras del leak que ha habido de la Wii y otras consolas de Nintendo de generaciones anteriores. ¿Qué significa todo esto, sobretodo de cara al homebrew o cualquier otra aplicación similar?

En realidad lo realmente interesante del leak son los archivos fuente en Verilog, el cual es un lenguaje de descripción de circuitos. Con ello es posible crear un chip utilizando un FPGA o una serie de FPGAs de base para el prototipaje para luego una vez el modelo es funcional puedes enviar a fabricar tu diseño en forma de chip dedicado.

Una matriz de puertas lógicas programable en campo12​ o FPGA (del inglés field-programmable gate array), es un dispositivo programable que contiene bloques de lógica cuya interconexión y funcionalidad puede ser configurada en el momento, mediante un lenguaje de descripción especializado. La lógica programable puede reproducir desde funciones tan sencillas como las llevadas a cabo por una puerta lógica o un sistema combinacional hasta complejos sistemas en un chip.

Esto es así porque se llego a punto en que los chips eran tan complejos que construir prototipos de ellos a través de wirewrapping y haciendo uso de circuitos TTS o CMOS ya no era viable por la enorme cantidad de elementos por mm2 y el enorme tamaño manual que había en consecuencia por lo que se llego al punto en que se dejo de hacer esto para prototipar.

Si os suena a chino lo de los chips TTL y CMOS para aclararlo os dire que son chips de funciones lógicas comunes y más utilizadas que se podían combinar entre si. El caso es que cuando se queria hacer un procesador dedicado lo primero se probaba su arquitectura creando complejas estructuras de chips TTL o CMOS (dependiendo de la época aunque más los chips TTL) que luego se reducían en un solo chip en la versión comercial.

El uso de los lenguajes de descripción del hardware como VHDL y Verilog ahorra un montón de tiempo porque evita que los desarrolladores tengan que estar todo el rato soldando y des-soldando cables. ¿Pero como funcionan? Pues básicamente describen el hardware y como esta este organizado internamente en un lenguaje con una sintaxis de C, aunque personalmente solo conozco Verilog, el cual voy a describir muy brevemente.

El código descriptivo de Verilog funciona a través de módulos, cada módulo se define por tres paramétros:

  • Conexiones de Entrada
  • Función
  • Conexiones de Salida.

Supongamos que queremos describir una puerta AND.

Pues bien, el código en Verilog seria

module Puerta_AND (a, b, ab);
 input a, b; // Puertos de Entrada
 output ab; //Puerto de Salida
 
 assign ab = a & b;

endmodule

Verilog no tiene una función main ya que no es un lenguaje de programación y es igual el orden en el que escribas. Lo bueno de tener el código fuente en verilog de algo es que permite hacer a la inversa, desde el momento en que describe un circuito te permite conocer su diseño interno por completo. Por lo que puedes tomar el código Verilog y hacer lo siguiente:

  • Puedes volcar el archivo en un FPGA y tener una versión vía FPGA 100% funcional, lo cual no es legal porque te puede caer una demanda enorme.
  • Puedes utilizar la información para realizar ingeniería inversa, es decir, estudiar el chip para ver como funciona y construir algo con la misma funcionalidad.

Y aquí hay una cosa que aclarar sobre todo sistema antiguo implementado en un FPGA, muchos de ellos si los comparas con el hardware original no funcionan de la misma manera y no dan los mismos resultados exactos. ¿El motivo? En realidad el código en el lenguaje descriptivo no es el original sino que por ingeniería inversa y conociendo el sistema saben que un elemento hace una cosa determinada, pero no sabemos como lo hace por lo que se acaba diseñando un circuito alternativo realizando esa función dentro de los parámetros conocidos.

Pero esto tiene una explicación, si quieres tener la información de un chip vía ingenieria inversa necesitas decapar el chip y vía ingeniería inversa a través de un microscopio electrónico y papel hacer el trabajo de chinos de ir creando el mapa del chip. Tened en cuenta que los chips cada vez son más complejos y hacer un trabajo así manualmente supone un tiempo enorme porque es coger puerta por puerta, esperar a obtener la organización de un chip a partir de cierta complejidad con ese método es cuanto menos un suplicio. ¿Os podéis imaginar coger el microscopio e ir apuntando parte por parte las diferentes puertas lógicas? Cuando terminasen de apuntarlo todo entonces…

… Por no decir que pese a que se tenga el código en Verilog si el chip es lo suficientemente complejo se llega al punto en que no puedes deducir de forma directa el funcionamiento y en tiempo te es mucho más fácil crear tu propia implementación de esa parte del chip si conoces cual es su funcionamiento de manera única, pero se llega a un punto donde la complejidad es tan grande que no merece la pena copiar la implementación via hardware y es recomendable un emulador por el hecho de que es más productivo al poder realizar la solución en menos tiempo, aunque claro esta que obviamente es menos precisa.

¿Pero nos sirve lo obtenido tal cual? No, no nos sirve. Por ejemplo si yo utilizará el código en Verilog del RCP obtendria el RCP tal cual, pensado para interactuar con la memoria RDRAM, si quisiera utilizar otro tipo de memoria tendría que re-diseñar por completo el código en verilog del controlador de memoria y todo lo que va conectado a él debido a que estas utilizando otra memoria diferente a la original y con otras reglas. En todo caso en todo esto hay un tema que es interesante relacionado con N64 y como Genyo Takeda se cargo el diseño original de Silicon Graphics al utilizar RDRAM con un bus solo de 8 bits, por lo que necesitaba varios ciclos de reloj adicionales para los envios creando una latencia enorme, lo bueno es que si toman el código Verilog del RCP de N64 entonces pueden crear una versión FPGA de la consola que no este limitada por la RDRAM y funcione tal y como Silicon Graphics lo diseño originalmente.

En el número 14 de la Next Generation Magazine, en el reportaje correspondiente al Shoshinkai 95 donde se presento la consola hay una entrevista a Genyo Takeda donde él dijo lo siguiente:

Por otro lado, existe la entrevista hecha a uno de los arquitectos del RCP de Nintendo64 junto a Tim Van Hook cuando trabajaban en Silicon Graphics.

Hay una parte donde hablan del estropicio que hizo Takeda al diseño original.

Gosset: Así que vayamos a los de Rambus ahora. Uno de los errores más obvios fue el hecho de escoger Rambus. Lo siento por Rambus pero se suponía que tenía que ser algo que redujese los costes. Por lo que el Sr. Takeda, quien era el directivo de Nintendo a cargo del proyecto, ya sabéis «Dos yenes por chip», bueno. él iba a iba, bueno, eran 2 yenes por pin, cierto. Así que él continuo contando pines debido a que costaban y como sabéis eso es cierto.

Se refiere a los pines externos de la memoria, cuanto un chip más pines necesita más grande es su perimetro y por tanto más área. Takeda pretendia reducir costes con ello y tiene su lógica.

Gosset:… La desafortunada realidad es que la Rambus era de 8 caminos (8 pines, es decir, 8 bits) multiplexada por lo que enviaba 8 bits de datos en cada pulso de reloj. Vale, los buses son algo desafiantes bajo Bueno. Ahora, los buses son un desafío en las circunstancias menos restringidas, y si vas ocho veces más rápido de lo normal, sabes, quiero decir, eh… Esto no va a ir bien, cierto. Entonces tienes que hacer cosas, y las cosas que tiendes a hacer es tener muchos contactos a tierra. Bueno. Así que sí, tenía menos pines de datos, pero lo compensaba con pines a tierra.

Es decir, Takeda, el arquitecto jefe de Nintendo durante las eras de N64, Gamecube, Wii y Wii U… ¡Desconocia por completo que su idea realmente no iba a suponer un ahorro en la cantidad de pines debido a que la contrapartida era el aumento de los pines a tierra!

Gosset: Por lo que no pienso que se ahorrasen nada en lo que es la cantidad de pines, y era una pesadilla desde el punto de vista de la arquitectura, debido a que las entradas y salidas estaban compartidas, los datos que entraban y salían se compartían (bajo los mismos pines). Así que tenías que activar la esquina, cierto, y no teníamos permitido hacer mucho en forma de poder tener un búfer en el chip, ya que intentábamos recortar el tamaño del chip. Así que realmente daba asco en cuanto a rendimiento.

El diseño ideal es que los pines de entrada y salida estén separados pero en algunas memorias suele haber un pin RW o como quieran llamarlo que colocando en 0 o 1 nos permite configurar la memoria en modo lectura o escritura para el siguiente envio o recepción de datos.

¿Y a que viene explicar todo esto? Pues bien, alguien puede coger y decidir hacer una N64 via FPGA no limitada por la Rambus donde los juegos no se vean limitados por la elección en el sistema de memoria. El otro elemento que pueden solucionar es el hecho de tener una RAM lo suficientemente rápida como para que el Z-Buffer no recorte la tasa de relleno a la mitad… Por lo que con esto y si alguien se pone podemos obtener un hardware 100% compatible y que funcione mejor que el hardware original al no tener sus limitaciones.

Por otro lado la explicación de Gosset nos dice el motivo por el cual los ex de SGI cuando diseñaron la GX GPU para Gamecube decidieron utilizar memoria embebida en su diseño. Porque conocían la mania de Takeda de tener la cantidad menor de pines posible en sus diseños, idea que fue manteniendo hasta Wii U.

Y esto nos lleva a otro elemento, ArtX cuando diseño la GX GPU de Gamecube se vieron obligados a no reventar la propiedad intelectual de SGI porque eran una empresa muy pequeña y los podían crujir legalmente hablando por lo que conociendo su propio chip crearon una versión altamente mejorada y re-implantaron su tecnología pero de otra forma, claro esta que Nintendo se quedo la propiedad intelectual del chip al 100%, es por ello que el hardware de la GPU de Gamecube/Wii se encuentra integrado en la GPU de Wii U.

El Secreto de la Virtual Console

Uno de los secretos que mucha gente desconoce sobre Wii es el hecho que al contrario de Gamecube, el hardware del RCP de N64 se encuentra en el interior del chip Hollywood que es donde se encuentra la GX GPU en Wii y el resto de componentes excepto la RAM y la CPU.

En realidad el diseño de Wii es un producto de BroadON, una empresa china creada por Wei Yen quien fue uno de los arquitectos jefe de los proyectos de N64 y GameCube. Cuando ATI compro ArtX fue cuando Wei Yen creo BroadON y su primer trabajo fue un sistema llamado iQue.

iQue es técnicamente una N64 colocada en un mando, pero va más allá, con tal de no reventar la propiedad intelectual de SGI en el RCP original, la gente de BroadON creo una implementación diferente de la arquitectura via verilog y creo la de SNES también, ambas implementaciones fueron re-utilizadas en Wii con tal de realizar la consola virtual. En realidad no es tener el hardware completo sino partes del hardware que son difíciles de emular via CPU integradas en el hardware.

Esto es todo, tenéis el Discord y los comentarios de esta entrada para comentarla.

0 0 vote
Article Rating
7 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
N64Kid

¿Esto explicaría por qué Switch no tiene juegos de N64?

Tienen que emularlos desde 0 sin el apoyo de esas partes del hardware dedicadas.

Me gustaría saber cuál es tu visión sobre la llegada de juegos de N64, gamecube, Wii a switch sea por la vía que sea: remakes, emulación, Nintendo online… me refiero a cuál es tu visión en cuanto a viabilidad y la estrategia que crees que seguirá Nintendo.

Echo de menos mucha propiedad intelectual de Nintendo en las que los amantes de los refritos nos dejaríamos la pasta.

Saludos

Steven

Hola disculpa si no entiendo ahora no se diseña algo como el 8086 que según se fue echo a lápiz sino software que de una vez verifica el funcionamiento disculpa la torpeza

nolgan

que opinas de esto
https://m.mydrivers.com/newsview/687449.html

segun esta gente AMD y nintendo estarian haciendo switch 2

Bob

Interesante! Estaba viendo un video al respecto y junto a tu entrada es mas claro.

https://www.youtube.com/watch?v=n8G7eq0GlQs&t=336s

Klayf

Me pasó lo mismo, tiene buenos videos ese canal

Argonauta

Ahora entiendo. Es decir, que en términos un poco más simples, los chinos pueden hacer una especie de «polystation» de la N64. O sea, una consola en un chip.

Pues, no me parece nada mal porque sería un gran avance si se pueden reproducir los juegos originales en un hardware incluso compatible con pantallas digitales sin emulación y con mejor rendimiento que la consola original.