Blog Personal.

Nintendo, Nintendo64, Retro

Nintendo Leaks (I): iQue Player

Las principales diferencias del iQue Player respecto a N64 son las siguientes:

  • La CPU es de la familia MIPS R5000 en vez de una de la familia R4000, esta puede correr entre los 62.5 Mhz y los 250 Mhz.
  • La RDRAM ha desaparecido, en cambio ahora tenemos memoria DDR con un bus de 32 bits y unos 125 Mhz de Memclk. La cantidad de memoria disponible es de 16MB en total en vez de los 8MB (Con expansión pack del original).
  • El mapa de memoria ha cambiado por lo que las referencias a ciertas direcciones relacionadas con los periféricos ahora son distintas y los juegos se han de parchear. Es decir, las ROMS de N64 no funcionan directamente en el iQue/BB
  • El RCP (RSP+RDP) fuera del controlador de memoria no tienen cambios internos ni mejoras de ningún tipo funcionando exactamente igual que en Nintendo64.
  • Se le han añadido una serie de interfaces de periféricos que permiten conectar memoria Flash (Tarjeta re-grabable), una pantalla LCD (no del tipo que la gente se espera), un lector de tarjetas SD y es la parte encargada de realizar la interfaz con los botones en el iQue/BB Player.
  • El sistema tiene una interfaz Ethernet para poder conectarla a la Red, supongo que era para conectar la consola a los quioscos desde donde descargar los juegos.
  • La interfaz de video y el DAC para la señal de video es el mismo que el de Nintendo64.
  • La interfaz de audio es la misma que la de Nintendo64 y no tiene cambios.

Hay que tener en cuenta que el BBPlayer/iQue no utilizaba los cartuchos tradicionales de Nintendo64 sino una serie de tarjetas re-grabables donde los juegos se podian descargar colocando las tarjetas en unos quioscos especiales.

Esto significa que el iQue Player no tiene la interfaz de cartuchos de Nintendo64 y también carece de la interfaz para el 64DD dentro de su hardware, pero no le hace falta desde que el método de distribución no son los cartuchos de la Nintendo64 sino como he comentado una serie de tarjetas re-grabables desde donde volcar los juegos.

De toda la información, el hecho de que Nintendo reemplara la RDRAM por memoria DDR tiene sentido dado que la disponibilidad de dicha memoria en el 2002 era muy baja y por los problemas de latencia y rendimiento que esta tenia respecto al modelo original.

Hay que tener en cuenta que N64 asigna del ancho de banda unos 250MB/s a la CPU (MIPS R5900) y otros 250MB/s al RCP. El problema es que su bus es de 8 bits por lo que acaba necesitando una mayor cantidad de ciclos de reloj para acceder a un dato y de ahí el problema de la latencia, cuando pedimos un dato a una memoria independientemente de cual sea el procesador lo que hacemos es enviar la dirección donde se encuentra el primer byte de la memoria y si el bus es por ejemplo de 32 bits nos enviará el primer byte (8 bits) y los otros 3 consecutivos sin que la CPU tenga que hacer peticiones a los otros 3.

Con el siguiente diagrama ultrasimplificado lo deberías entender:

La memoria como una tabla de datos donde primero se le envía a la RAM los datos de la columna y la fila donde esta el dato por separado, una vez tiene la dirección de memoria lista (esto tarda unos ciclos) se abre una ventana en el que el dato se puede leer y/o escribir. Por lo que es preferible poder cargar muchos bloques de datos en pocos ciclos porque te ahorras la búsqueda de los que van secuenciales a este y por tanto en direcciones de memoria posteriores en vez de hacer varios pequeños accesos que van añadiendo latencia por el tiempo de busqueda existente.

Una memoria DDR con un memclk de 125Mhz y de 32 bits de bus en realidad es un ancho de banda de 1 GB/s por lo que es el doble de ancho de banda que con la N64 original y dado que la tasa de relleno depende en el caso de N64 del ancho de banda pues tenemos un sistema con el suficiente ancho de banda como para poder realizar Z-Buffering sin recortar la tasa de relleno del sistema a la mitad en el proceso.

Pero lo mejor lo vamos a dejar para el final, la implementación de una CPU basada en un MIPS R5000 en vez de una versión del MIPS R4000 y el cambio es importante y hasta ahora desconocido aunque realmente tenemos un MIPS R5000 capado en comparación con lo que hubo en las estaciones de trabajo O2 de Silcon Graphics.

Los cambios en el MIPS R5000 respecto a su antecesor son los siguientes:

  • La Cache de datos e Instrucciones L1 ha pasado de ser de 8KB a 32KB.
  • Tiene soporte para cache L2 (externa al chip) en tamaños de 512KB, 1MB y 2MB, pero esto no se utiliza en el iQue Player.
  • Al contrario que el R4000 es super-escalar pudiendo resolver 2 instrucciones de enteros o 1 de coma flotante+1 de enteros por ciclo.
  • Su FPU esta ampliamente mejorada, necesitando muchos menos ciclos para coma flotante.

No en vano, pese a que el O2 dispone del RDP en forma de ICE (Image Compression Engine) debido a que el R5000 es más rápido no se utiliza para realizar la goemetría en el caso de la estación de trabajo de SGI. Pero no es el caso del iQue/BBPlayer porque los juegos son ROMS de N64 pensados para utilizar el RSP y el RDP. En realidad el uso del R5000 para calcular la geometria lo trastoca todo y convierte al sistema en un sistema completamente distinto a la hora de desarrollar, Nintendo no se calento mucho la cabeza en este proceso.

¿Entonces que sentido tiene tomar un R5000? Bueno, el sentido es que si lo sumamos a la memoria Nintendo quería un sistema que no tuviese los problemas de latencia y de framerate de la consola original. Fijaos además como el codigo en el iQue funciona de manera más rápida gracias a la nueva CPU y al reemplazar la RDRAM por DDR y esto es un ejemplo simple.

Hay que tener en cuenta un detalle importante de como funciona el pipeline 3D tradicional, la cantidad de geometria que se puede calcular no puede ir más allá de la cantidad de triangulos que la unidad de rasterizado puede convertir en fragmentos. El hecho de calcular poligonos sin ton ni son para que luego la unidad de rasterizado no los pueda convertir a la suficiente velocidad y alimentar a etapas posteriores es el máximo cuello de botella del sistema una vez solucionamos el problema de la latencia.

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

5 1 vote
Article Rating
4 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Bob

Excelente post! muy interesante!

Argonauta

Entonces el iQue Player es una n64 sin cuellos de botella y alta latencia de la consola original. Muy interesante.

Gerardo Türme

Ya ha comentado unos de los autores de la scene de Wii sobre las filtraciones de los documentos y ha dicho que meh!.. que toda la documentación filtrada ya está documentada gracias a la ingeniería inversa e incluso esa documentación es más precisa que la oficial, solo ha servido para ver curiosidades como que al parecer Nintendo tenía planeado el poder usar Wiimote y nunchuck en los juegos de GameCube pero como sabemos al final no fue así. https://twitter.com/marcan42/status/1258076270308425728 También ha comentado Extrems (uno de los autores del emulador de N64 en Wii) que la info sobre N64 ya estaba… Read more »

Gerardo Türme

Les dejo el link donde pueden ver el hilo completo de Twitter donde Marcan habla de las filtraciones.

https://twitter.com/marcan42/status/1258283541101572097