Ahora le toca el turno a la 64 bits de Nintendo y con ello terminamos la tercera temporada, tengo ganas de dedicarme a otras cosas, sinceramente.

#1 La Historia de Nintendo64

La historia de N64 realmente empieza en Silicon Graphics donde un joven ingeniero llamado Tim Van Hook crear un procesador llamado Multimedia Engine.

MultimediaEngine

El Multimedia Engine se acabo convirtiendo con el tiempo en uno de los dos procesadores de la N64, pero se trataba del primer chip doméstico capaz de mostrar de generar todo el pipeline 3D por si mismo y de manera independiente. Silicon Graphics lo fue ofreciendo a diferentes clientes, incluida Sega que lo rechazo. Al final termino en manos de Nintendo que llamo al proyecto Project Reality inicialmente para luego convertirse en Ultra64 para ser lanzada definitivamente como Nintendo 64. La historia de la consola es en general conocida por todos y por motivos de hacer más amena la lectura no me voy a extender mucho más, tampoco voy a comentar cosas como el 64DD que no daban capacidades de proceso adicionales a la consola, más que nada porque las entradas se me van acumulando y tenía que acabar esta serie.

#2 Las entrañas de Nintendo64

Por sorprendente que os pueda suponer, la arquitectura y el hardware de N64 son sumamente simples en comparación con otros sistemas de la época, esto se ve haciendo una simple observación a su placa y comparadola con sus contemporaneas como Saturn y PlayStation.

rev4n64smallselected

La consola carece de unidad CD-ROM y por eso se ahorra la circuitería a su alrededor junto al lector CD-ROM y también carece de chip de sonido dedicado por lo que tambien dicho hardware desaparece de la estructura de costes de la consola. En realidad aunque sorprenda, en comparación con otras arquitecturas que hemos ido viendo en esta serie, la Nintendo64 es sumamente sencilla realmente.

#2.1 CPU

La CPU de N64 es un NEC VR4300, una versión del MIPS R4300 fabricada por NEC para Nintendo funcionando a unos 93.75Mhz de velocidad de reloj. Dentro de la serie MIPS, si el R3000 fuese el 80386, el R4000 seria el 80486. En realidad la diferencia en rendimiento de ambos por ciclo de reloj no era mucha, pero claro, en el caso que nos ocupa ahblamos de casi tres veces el rendimiento, por lo que sobre el papel esta CPU por encima de la de PlayStation.

Ic-photo-NEC--VR4300-(R4300i)-(Nintendo-64-CPU-NUS_A).png

El VR4300/R4300 tiene los siguientes cambio respecto al chip original:

  • Dado que en el sistema la RDRAM que es la única RAM del sistema esta conectada a al RCP, la interfaz física de la conexión con la memoria externa ha sido eliminada en este caso y las peticiones a memoria se hacen al controlador de memoria integrado en el RCP.
  • En algunos juegos el audio es generado por el VR4300/R4300 con tal de liberar al RSP.

En cuanto a los Co-Procesadores se mantienen respecto al R4300 estándar, siendo el  COP0 la unidad MMU y el COP la unidad de coma flotante.

#2.2 RCP

El Reality Co-Processor es el segundo chip dentro del hardware de la N64.

RCP

rcpdiagram

El RCP esta compuesto por el RSP y el RDP encargados de la generación de imagen y sonido, así como el controlador de memoria del sistema y el control de E/S (cartucho y periféricos). En realidad Nintendo desde N64 en adelante aglutinaría todas esas funciones en un mismo chip en el caso de sus consolas de sobremesa. RCP, Flipper, Hollywood, Latte y el X1 de la actual Switch donde nos encotnramos con un SoC completo.

#2.2.1 Controlador de memoria (RAMBUS Controller) y RDRAM

N64 es la primera  segunda consola con una configuración de memoria unificada a nivel físico, esto significa que los 4.5MB de memoria de almacenamiento son compartidos por todos los procesadores del sistema y por tanto su acceso también. Esto hace que todos los accesos a memoria tengán que pasar por este componente del hardware que es el que controla la prioridad de entradas y salidas y es por desgracia la parte más deficiente del hardware de N64, hasta el punto en que…

steve-carell-facepalm

Con tal de ahorrarse los costes de fabricación en la placa, en Nintendo optaron por memoria RDRAM (RAMBUS DRAM), esta memoria tenía un bus de 9 bits solamente pero unos 500 Mhz de velocidad, el problema de la RDRAM es que de entrada tiene algo más de latencia y esto es mortal para el rendimiento de las CPUs cuyo rendimiento de las instruccione dependen de la latencia de los diferentes niveles de la jerarquia de memoria. Genyo Takeda que sustituyo a Uemura en el diseño de las consolas Nintendo mantuvo la misma filosofía de diseño hasta Wii U. Todas y cada una de las consolas de Nintendo se han basado en una obsesión de Genyo Takeda por ahorrar costes en el sistema ahorrando en la memodia, empezando por N64.

takedan64ram

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…

La memoria RDRAM fue una elección de Takeda para N64 y no de Silicon Graphics y esta decisión es el origen de uno de los principales problemas de rendimiento de N64 por su enorme latencia. Hay que tener en cuenta que el renderizado de la escena empieza en la CPU y si esta tarda más de lo normal en realizar todo el proceso entonces afecta al resto del sistema. ¿Pero puede esto hacer esto que un derivado del R4000 a unos 93.75 Mhz acabe rindiendo peor que un R3000 a 33 Mhz? En teoria no debería pero es así como ocurre.

Esto es cuanto menos curioso, son palabras de Martin Hollis, programador jefe de Goldeneye, donde se relata que el problema de la latencia tiene origen en el hardware y por tanto no se podia corregir por software.

Escribí una pieza de código que mostraba icosaedros. Tantos como fueran posibls hasta que la tasa de fotogramas bajase por debajo de los 60hz. Al jefe del proyecto en SGI no le gusto nada al descubrir el rendimiento de la máquina en terminos de triángulos por segundo. Me pregunto si el código era ineficiente No lo era. Después me comento que SGI casi estuvo a punto de hacerle otro cambio en el hardware para solucionar el problema, el cual era la interfaz de memoria.

No se las cifras exactas, pero una segunda versión del hardware (equivalente a la segunda edición de un libro) se dice que a veces cuesta millones dólrares, y hay un coste adicional en retrado a la hora de alcanzar un mercado que ya era enormemente grande.

Nintendo por motivos de timing y de coste decidió no solventar el problema provocando un problema de rendimiento en el hardware tremendo. Hiroshi Yamauchi estaba obsesionado en sacar la consola por 25.000 yenes como mucho y cualquier sobrecoste no era bienvenido dentro de Nintendo. Esto fue el principio del fin de la joint venture entre SGI y Nintendo. ¿El motivo? Nintendo consideraba que SGI había lastrado el rendimiento del sistema adrede al crear un controlador de memoria defectuoso y en parte razón no les faltaba, por mucha latencia de más que colocase la RDRAM el rendimiento de la CPU de N64 era defectuoso debido a ello, la tasa de fotogramas se reducia enormemente por ello, pero en parte Nintendo también fue la culpable aunque por su falta de experiencia.

Super-Mario-64-1

Super Mario 64 fue su benchmark de rendimiento inicial y no utilizaba cosas como el Color Combiner o el renderizado en dos ciclos que utilizarían juegos posteriores. Nintendo peco de ingenua en su desconocimiento y falta de experiencia con el hardware en 3D a tiempo real pero la realidad es que N64 no debería haber tenido los problemas de rendimiento que tuvo. Como ya dije en la entrada de la N64 Mini me gustaría verla pero con los juegos de la consola corriendo a la tasa de fotogramas correcta y sin los problemas asociados al controlador de memoria. Nos encontramos ante una consola que al contrario que sus antecesoras no renderiza al compás del haz de electrones del televisor. Por lo que al contrario de la NES Mini y la SNES Mini sería posible una N64 Mini sin los problemas asociados al hardware original.

En cuanto a la RAM misma, N64 tiene unos 4 MB de memoria RAM del tipo RDRAM, la velocidad de reloj de la misma es de 500 Mhz con un bus de 9 bits dando un ancho de banda de 562.5MB/seg. De los cuales unos 250MB/s se asignan a la CPU, unos 250MB/s al RCP y los 62.5 MB/s al Z-Buffer del RDP. La consola podía expandir la memoria a 8MB a través del expansion pak, pero dicha memoria no aumentaba el ancho de banda de la misma, solo la capacidad de almacenamiento de la RAM.

n64_exp_pak_orig.jpg

El Expansion Pack tenia que formar parte originalmente del 64DD pero Nintendo al trasladar varios de los juegos del 64DD a la N64 estándar se encontro con que muchos de esos juegos no funcionarían sin el pack de expansión por el hecho de superar el limite de 4MB de la propia consola. Dos ejemplos de ello fueron Zelda Gaiden (luego lanzado como Majora’s Mask) y Donkey Kong 64 que no funcionan sin la expansión de memoria. Otros juegos en cambio fueron recortados para funcionar en los 4MB de memoria de la consola y por último aparecieron juegos que aprovecharon la mayor capacidad de almacenamiento para ampliar el búfer de imagen y renderizar a la por aquel entonces alta resolución de 640×480 pixeles.

#2.2.2 RSP

El Reality Signal Processor, conocido originalmente como Multimedia Engine es la parte encargada de tres tareas:

  • Calcular la geometría de la escena.
  • Generar el audio de la escena.
  • Procesador de Comandos del RDP

El RSP como hemos visto antes fue creado por Tim Van Hook y es la base de lo que se acabo convirtiendo N64 con el tiempo. Al igual que la CPU se trata de un procesador de la serie MIPS R4000 pero esta altamente modificado siendo el primer cambio la eliminación de la unidad de coma flotante en el COP1 por una unidad vectorial/SIMD que permite realizar la misma instrucción a muchos datos en un mismo ciclo de reloj, lo cual es esencial para las operaciones relacionadas con la manipulación de la geometria de la escena.

RSPmap

Como podéis ver la unidad vectorial puede realizar hasta unas 8 operaciones por instrucción con precision de 16 bits cada uno. La cantidad de instrucciones que puede realizar no difiere mucho del GTE pero puede realizar más operaciones por instrucción y por lo tanto su capacidad acaba siendo muy superior al GTE de la PlayStation original, aunque ni Nintendo ni SGI dan datos máximos teóricos como Sony se ha de tener en cuenta que la tasa de trasformación geométrica máxima de la consola ha de ser superior a la de la consola de Sony. ¿Entonces como es que esto no se veía en los juegos? Por dos motivos, el primero de ellos la latencia con la CPU, el segundo es la tasa de relleno del RDP que es un cuello de botella más grande porque no te sirve de nada calcular más poligonos que los que puedes dibujar en pantalla y es una perdida de recursos y de tiempo.

La gracia es que el RSP es que al derivar de una CPU de proposito general es en cierto grado programable, en esto también difiere del GTE de la PlayStation donde la funcionalidad esta más o menos automatizada al ser un procesador más simple y más limitado, su naturaleza le permite al RSP ser mucho más versatil. No obstante no esta pensado para que podamos programarlo como si fuese una CPU al uso, pese a tomar de base el R4000 su rendimiento en otras areas es deficiente, como por ejemplo de cara a los saltos de código ya que unidad encargada de la predicción de saltos ha sido eliminada, a la unidad de enteros (escalar) le han eliminado los registros de 64 bits (no puede operar en esa precisión con enteros) y las instruccione de suma y multiplicación, aparte que como se puede ver en los diagramas la cache disponible es de menor cantidad que en la CPU.

El RSP funciona utilizando microcódigo, no se puede programar en ningún lenguaje de alto nivel ni bajo ninguna API dedicada. Un microcódigo es el nombre de una serie de instrucciones y/o estructuras de datos almacenados en una memoria que es de acceso muy rápido, en el caso que nos ocupa el microcódigo es cargado en la cache de instrucciones (IMEM) y dichas instrucciones no son invocadas en el codigo sino referidas. Los microcodigos suelen incluir una parte para la gestión del Audio dado que el RSP se encarga de generarlo junto al microcódigo especializado para la generación de imagenes en pantalla, también en el microcódigo se embedían las instrucciones para el RDP.

En realidad de cara a los desarrolladores, el RSP operaba como una unidad de función fija casi, ya que en el SDK solo tenían acceso a las instrucciones y parametros de lo microcódigos oficiales y no fue hasta muy avanzada la vida de la consola que se le dio acceso a los desarrolladores a crear su propio microcódigo. Los microcódigos oficiales que daba Nintendo en sus SDK eran:

  • Fast3D: El oficial de SGI y Nintendo es el que es más preciso en cuanto a imagen pero el menos adecuado para un videojuegos debido a que sacrifica velocidad por precisión de imagen. No obstante los desarrolladores externos a Nintendo y Rare no pudieron acceder a las entrañas del RSP para modificar el micro-código hasta muy avanzada la vida de la consola.Su rendimiento era de 100K poligonos/segundo en modo “1-Cycle” y 50K poligonos/segundo en modo “2-Cycle”.
  • Turbo3D: No utilizado en los juegos, desactivaba el bufer de profundidad, la corrección de perspectiva y renderizaba solo en modo “1-Cycle” con un rendimiento de 600K pol/seg. Nintendo nunca dejo que este modo fuese utilizado en ningún juego comercial. Pero es la demostración que de tu a tu y en comparación el hardware de N64 en el fondo era muy superior al de PlayStation.
  • Micro-códigos específicos: Desarrolladores como Boss Game Studios, Factor5, Rare y otros llegaron a desarrollar sus propios micro-códigos.
  • Sprite 2D: Utilizado en los juegos en 2D de la consola.

La forma en que la CPU se comunicaba con el RSP para enviarle el microcódigo primero y las listas de pantalla no era a través de un bus de comunicación directo sino que escribía la lista de instrucciones y datos en la RDRAM, dada la latencia entre la CPU y la RDRAM esto resultaba un problema enorme de rendimiento. ¿El motivo de dicha limitación? Pese a que la memoria estaba unificada el RCP y la CPU utilizaban espacios de memoria distintos en la RAM.

#2.2.3 RDP (3D)

El Reality Display Processor es el segundo procesador que se encuentra dentro del RCP y en la generación de gráficos en 3D se encarga de la etapa de rasterización. En realidad de base funciona como la GPU de PlayStation en el sentido de que lo que hace es dibujar primitivas gráficas texturizadas sobre un búfer de imagen, con la diferencia que  pero las similitudes terminan ahí ya que N64 difiere en muchos puntos cruciales y es mucho más avanzada.

En lo primero que difiere es en el hecho de tener un rasterizador con soporte para búfer de profundidad, el cual es un búfer que almacena a nivel de pixel la distancia respecto de la cual se encuentran los pixeles de la cámara. Esto permite que se pueda aplicar la corrección de perspectiva a la escena compuesta por triangulos y se evita por tanto el bailoteo de poligonos que existía en la consola de Sony.

Es a partir de la N64 en adelante que vamos a ver en consolas de sobremesa el texturizado con corrección de perspectiva.

 

Pero el Z-Buffering tiene un problema, se trata de un búfer que es equivalente al Color Buffer y por tanto no solo ocupa memoria sino también tasa de relleno, la cual depende del ancho de banda de la memoria que tenemos disponible. El handicap del Z-Buffer en N64 es que de los 9 bits por ancho de banda de la RDRAM utilizaba el noveno para el dicho búfer. Teniendo en cuenta que la tasa de relleno del RCP es de 62.5 Mpixeles/seg y el Z-Buffer es de 2 bytes (16 bits) entonces se necesitarían unos 125 Mbytes/seg, pero el sistema de memoria de la consola solo otorgaba unos 62.5 Mbytes/seg para esta tarea por lo que la tasa de relleno general del sistema pasaba a ser de 31.5 Mpixels/seg ya que tanto el búfer de profundidad como el de color han de ser parejos y por tanto el uso del búfer de profundidad reducía la tasa de relleno teórico a la mitad.

Pero N64 tenía un método de texturizado que iba más allá de un simple texturizado, en primer lugar era capaz de aplicar filtrado de texturas con tal de eliminar el efecto de pixelación. En teoría puede soportar sobre el papel dos tipos de filtrado, el bilineal y el trilineal, pero esto tiene «trampa» pero antes de comentar la trampa hemos de tener en cuenta que los filtros de texturas requieren que se lean también los pixeles contiguos de cada pixel de la textura. El filtro bilineal necesita 4 y el trilineal unos 8. Esto significa un ancho de banda de lectura 4 veces superior que N64 no tenía y dado que el texturizado viene antes de la creación del búfer de imagen esto hubiese disminuido la tasa de relleno a poco menos de 8 Megapixeles y el rendimiento…

thumbs-downnotvjimmy-fallon

Es por ello que existe la TMEM, una memoria del tipo scratphpad que es erroneamente llamada cache de texturas y el error consiste en que la TMEM no es una cache ya que se tiene que llenar manualmente con la textura o las texturas necesarias que se han de procesar, pero esto no lo hace el el RDP sino que son cargadas a través de la lista de pantalla y por tanto por el RSP, pero la TMEM en si misma tiene una serie de particularidades que la hacen única.

En primer lugar pese a soportar filtrado bilineal (4 muestras) y trilineal (8 muestras), en realidad el filtrado bilineal de N64 esta capado a 3 muestras solamente. Así es como se ve Ocarina of Time aplicando el filtro bilineal estandar…

6z3L7Rh

Y esto es como se veía en N64…

4wwtS6o.png

El motivo de hacerlo es porque trabajar con 3 muestras es un código más sencillo y la máquina de estado encargada de ello podía ser menos complejo pero es que además es para reducir la necesidad de ancho de banda y por tanto el cableado interno del chip para dicha función. El filtrado trilineal en N64 funciona como el bilineal estandar… Es decir con 4 muestras pero gracias a que trabaja en dos ciclos soporta Mip Mapping y se le llama TLMMI en el argot de la consola, en realidad se debería llamar BLMMI y si SGI diese soporte para bilineal estandar entonces la tasa de texturizado no se reduciría al 50% al utilizar dicho efecto y con ello la tasa de relleno resultante no se reduciria a la mitad, pero asegurarlo es falso desde el momento en que esto no es la historia completa.

El RDP de cara al texturizado puede trabajar en dos modos distintos, el modo 1-ciclo y el modo 2-ciclos. En el primero funciona con una tasa de relleno de 1 pixel por ciclo de reloj…

rdp1cycle

en el segundo con una tasa de relleno de dos ciclos de reloj por pixel.

rdp2cycles

El RDP es un caso curioso porque los chips 3D de la época no se basaban en OpenGL, N64 tampoco pero si en un subconjunto y tomaba varios elementos del mismo como ahora la implementación de un Color Combiner, el cual se utiliza para hacer ciertos efectos. En algunos casos es necesario para ciertos efectos tomar unos dos ciclos en total. ¿Pero que sentido tiene el Color Combiner? Para entenderlo hemos de entender lo que son los Shader Tree que consisten en multiplicar o sumar un valor de una textura base por el de otra textura u otro valor que se le de como segundo operando.

ShaderTree

Y aquí viene lo curioso de la TMEM, podemos almacenar hasta 8 texturas distintas que es el limite de texturas que podemos combinar en el OpenGL estandar pero en N64 SGI lo limito a dos. Como curiosidad los ingenieros de la GX GPU de Gamecube que fueron los mismos y aumentaron a 8 ciclos concatenados. El Color Combiner es la evolución previa a los Pixel/Fragment Shaders y en N64 permiten una serie de efectos con ellos y demuestra arquitecturalmente lo avanzada que estaba N64 en este aspecto. En PC este concepto no llego hasta el lanzamiento de la Riva TNT unos dos años más tarde del lanzamiento de la N64. La Voodoo Graphics por ejemplo reemplazaba el Color Combiner con una serie de máquinas de estado para realizar algunos efectos y es que no fue hasta 1997 que Silicon Graphics liberalizo su OpenGL y aún así en PC tardamos en ver la primera GPU en PC que soportase la API OpenGL (NV10/GeForce 256), es más, el RCP de N64 en su conjunto es lo más cercano a un hardware OpenGL que había en la época, al fin y al cabo es un hardware diseñado por Silicon Graphics que fueron los que crearon el OpenGL.

#2.2.4 RDP (2D)

El RSP tiene un microcódigo pensado para los gráficos en 2D utilizando quadrangulos con texturas rectangulares como patrones/sprites de una forma muy parecida a como funciona el VDP1 de Saturn y sistema gráfico de la 3DO, pero con las funcionalidades añadidas del RDP .

Veamos lo que dice el SDK sobre la generación de escenas en 2D.

rdpsprites

El RDP al contrario de la GPU de PlayStation puede copiar hasta unos 4 pixeles en linea de la TMEM hacía el búfer de imagen con una instrucción. Esto nos permite volcar las texturas almacenadas en el TMEM en el búfer de imagen de manera directa con tal de componer una escena en 2D. La limitación es que solo podemos tener unas 8 texturas en los 4KB de la TMEM, la segunda limitación es que el RDP no puede realizar operaciones de rotación de los patrones/sprites/texturas y eso lo tiene que hacer el RSP, provocando que la version volteada o manipulada de una textura ocupe unos de los 8 slots y haciendo que la CPU o el RSP tenga que manipularlas.

No solo eso, sino que dado que no estamos hablando de un hardware en 2D especializado sino uno en 3D trampeado al igual que en PlayStation, esto supone que el orden de prioridad de los patrones/sprites no existe, es decir, si dos patrones/sprites se encuentran en el mismo espacio descartara el previamente dibujado, es por ello que es necesario utilizar el Z-Buffer para la precisión de las imagenes 2D y que el hardware sepa cuando ha de redibujar la primitiva y cuando no.

rcpsprite2d

rdpsprites2

El Z-Buffering de unos 8 bits no es lo suficientemente bueno para las escenas en 3D pero en escenas en 2D si que lo es desde el momento en que no es muy habitual ver escenas con 256 planos distintos. Esto significa que N64 con el Z-buffer activado en teoría debería tener una tasa de relleno de 62.5 Mpixeles/s, lo cual es mucho más incluso que la tasa de relleno de Saturn con el VDP1 y el VDP2 combinados y dados los 4MB de RAM de la consola debería ser capaz de mover con una soltura increible los gráficos en 2D pero la consola tiene un handicap muy importante en ese aspecto y esto nos lleva a la siguiente sección.

#2.3 Cartuchos.

La diferencia entre un cartucho y el CD-ROM es que el cartucho se puede tratar como una memoria más mientras que el CD-ROM requiere volcar los datos a memoria dado que la velocidad de acceso no es lo suficientemente rápida, pero se llego al punto en que las velocidades de acceso de los cartuchos no eran lo suficientemente rápidas y se acabo necesitando también un memoria intermedia. La primera consola con este problema fue la Atari Jaguar ya que la única manera que había de alcanzar altos anchos de banda era utilizar multitud de chips para aumentar la cantidad de pines y con ello el ancho de banda, pero los costes resultante de los cartuchos resultaban en un enorme…

money-black-hole

La decisión de los cartuchos fue tomada por Nintendo en 1994, eso hizo que muchos desarrolladores artos del alto coste del formato y viendo que había una competencia viable con PlayStation mucho menos restrictiva decidieran escoger a los cartuchos como formato aumentar la RAM del sistema. En SGI y Nintendo creían que colocar más memoria RAM en la consola les daría una ventaja tecnica sobre la competencia a nivel visual, cosa que es cierta. ¿El problema? Los cartuchos de N64 eran sumamente caros, no solo por su obvio ratio de capacidad de almacenamiento/coste, sino por el hecho que un cartucho de tamaño decente eran unos $20 por copia y se tenian que pedir con meses de antelación. Si un juego no vendía se comían el stock, si un juego vendía y se quedaban cortos entonces no podían aprovechar el momentum.

Sony con su PlayStation cobraba unos $10 por copia, pero las esperas de meses no existían y si un juego no vendía podían revertir la cadena de impresión de los CDs en muy poco tiempo a otro juego que si que tenía éxito. Además, esos $10 de diferencia se podían utilizar para el marketing lo que le dio un nombre comercial a PlayStation importante y dejo el nombre de Nintendo muy tocado en el mercado en general. El rechazo de los editores y desarrolladores independientes a los cartuchos fue tal que Nintendo of America tuvo que crear un grupo de desarrolladores llamado el Dream Team.

Nintendo por el tendencioso libro de David Sheff, Game Over, de caracter puramente anti-Nintendo acabo creyendo que el motivo por el cual la NES había tenido más exito que SNES eran por los juegos exclusivos. Volvieron a las medidas draconianas de antes y obligaron a que los juegos fuesen exclusivos al menos un año pensando que así se iba a repetir el efecto y el resultado en conjunto con la elección de los cartuchos fue…

shooting-yourself-in-the-foot-300x252

A nivel técnico, la CPU y el RCP podían acceder a los datos de los cartuchos con un bus paralelo al de la memoria RAM. El ancho de banda de los cartuchos dependía de la velocidad de la ROM en estos, que podía ir de los 5MB/seg a los 20MB/seg dependiendo del tipo de ROM utilizada en los cartuchos. Lo habitual era copiar los datos del cartucho a la RAM del sistema pero si al ancho de banda de las ROMs era lo suficientemente alto entonces la CPU podía leer los datos que no son sensibles al ancho de banda desde el cartucho sin tener que pasar por la RAM. El problema es que las ROMS nunca erán lo suficientemente rápida como para prescindir de la RAM y eso acabo demostrando que los cartuchos ya eran completamente prescindibles en todos los aspectos.

El otro formato de almacenamiento que no tuvo casi nadie fue el 64DD, un lector de discos magneticos de dos capas.

n64dd-randnet-starter-kit

Los discos del 64DD eran de dos capas, la primera capa de 32MB de solo lectura podian incluir el juego o una expansión para un juego existente…

fzerox64dd

La segunda capa era escribible, esto permitía en teoría crear mundos con persistencia pero dicho concepto nunca fue explotado y es que el periférico fue realmente un fiasco. La idea de los mundos con persistencia era que se podía volcar el contenido de la RAM en el disco y continuar la situación del juego tal y como era pero ni la propia Nintendo le supo sacar ventaja a dicha capacidad realmente.

Y con esto llegamos al final, espero que hayáis disfrutado de esta entrada.