Análisis del interior de un cartucho de Super Nintendo

 (fabiensanglard.net)
1 puntos por GN⁺ 2024-04-23 | 1 comentarios | Compartir por WhatsApp
  • Los cartuchos de Super Nintendo no eran simples medios de almacenamiento: eran hardware que ampliaba las funciones de la consola al incluir protección anticopia CIC, SRAM y coprocesadores
  • En esa época, la capacidad de la ROM se promocionaba en bits, y entre los 3,378 títulos analizados, Star Ocean y Tales of Phantasia tenían 48Mb, mientras que Super Mario World tenía 4Mb
  • La función de guardado dependía de SRAM mantenida por batería, y hubo casos como la PCB de Zelda III que incluían un decodificador de direcciones MAD-1 para coordinar el acceso a ROM/RAM
  • En total, 13 tipos de chips auxiliares se usaron en 72 juegos, encargándose desde el cartucho de tareas como aceleración de CPU, manejo de sprites, descompresión, operaciones matemáticas y rasterización de polígonos
  • Estos chips ampliaron mucho la expresividad de los juegos de la época, pero también dejaron una carga de ingeniería inversa durante años para la implementación de emuladores, como en los casos en que se necesitaban paquetes gráficos por desconocer la estructura interna del S-DD1

Composición básica del cartucho: CIC, ROM, SRAM

  • Los cartuchos de Super Nintendo podían contener no solo instrucciones y assets en chips ROM, sino también un chip anticopia CIC, SRAM y coprocesadores
  • CIC funciona mediante comunicación en lockstep entre el chip del lado de la consola y el chip del lado del cartucho
    • Si el CIC de la consola detecta un estado anómalo, reinicia todos los procesadores
    • No todos los cartuchos de SNES tienen CIC; el juego no oficial Super 3D Noah's Ark no tiene CIC
    • En Super 3D Noah's Ark primero hay que insertar el juego en la consola y luego insertar encima un cartucho oficial; el lado de Noah's pasa las líneas del bus hacia el CIC del juego oficial
  • En esa época, la capacidad de ROM se expresaba en bits, no en bytes
    • Zelda III se promocionó como una ROM de 8Mb, no como 1,048,576 bytes
    • La lista analizada incluye 3,378 títulos de USA/Japan/Europe
    • Star Ocean y Tales of Phantasia están entre los más grandes, con 48Mb, es decir 6,291,456 bytes
    • Super Mario World usa una ROM de 4Mb, es decir 524,288 bytes
  • Algunos títulos con función de guardado usan SRAM alimentada por batería
    • Cuando la consola se apaga, la SRAM entra en un modo de bajo consumo para reducir el uso de energía
    • La PCB de Zelda III tiene el CIC (D413A) en U4, una ROM de 0x80000 (524,288 bytes) en U1, una SRAM LH5268AF-10TLL de 64Kbit (8KiB) en U2 y un decodificador de direcciones de memoria MAD-1 en U3

Alcance de los chips auxiliares y SA-1

  • El coprocesador auxiliar más famoso es Super FX, usado en Star Fox en 1993, pero antes de eso ya se habían usado chips EC
  • En total, 13 tipos de EC se usaron en 72 juegos
  • SA-1, es decir Super Accelerator 1, es un chip auxiliar representativo incluido en 34 cartuchos
    • Es la misma CPU 65C816 que la CPU de la consola SNES, pero funciona 4 veces más rápido, a 10.74MHz
    • Incluye 2KiB de SRAM y un CIC integrado
    • La PCB de Super Mario RPG no tiene un CIC separado; tiene el SA-1 en U3, ROM en U1 y SRAM con decodificador integrado en U2
    • El SA-1 recibe el System Master clock del puerto del cartucho sin un oscilador separado, lo divide internamente a la mitad y funciona a 21.4772700MHz / 2 = 10.74MHz
  • Al iniciar, el SA-1 está en estado stop, y la CPU de SNES crea el Reset Vector y reanuda el SA-1
    • El Instruction Pointer inicial del SA-1 se toma de un Reset Vector dedicado
    • Sus modos de operación son tres: Accelerator, Parallel Processing y Mixed Processing
    • En la configuración más potente, la CPU SA-1 y la CPU Super NES funcionan simultáneamente, lo que hace que el rendimiento del Super Accelerator System sea 5 veces el del Super NES original
  • La mayor capacidad de procesamiento se usó para animar los 128 sprites completos que ofrece la PPU, detectar colisiones, y hacer rotación y escalado en tiempo real de sprites antes de escribirlos en la VRAM de la PPU
    • El cartucho demo Nintendo SA-1 muestra estas mejoras
    • La comunidad de juegos retro redujo el slowdown de juegos existentes con proyectos como Eliminating slowdown in Super Mario World, Gradius III slowdown removal y Contra III slowdown removal
    • Para convertir un título a SA-1 parece bastante complejo, ya que en especial se necesita remapear el acceso a RAM/ROM; esto deja dudas considerando que la documentación de SA-1 dice que “SNES y SA-1 usan el mismo mapeo de memoria”
    • En 2019, mediante el SA-1 Collection Project, seguía en curso un trabajo para remapear automáticamente más juegos de SNES y convertirlos a SA-1

Chips auxiliares de gráficos, compresión y matemáticas

  • CX4 es un chip de Capcom que impulsa Mega Man X2 y Mega Man X3
    • Puede encargarse de renderizado 3D wireframe, varias operaciones matemáticas, escalado y rotación de sprites, y escritura posterior en VRAM
    • Se pueden ver ejemplos en la intro y una pelea de jefe de MMX2
    • CX4 no solo ofrece wireframe, sino también sprite functions, propulsion, vector, triangle, trigonometric functions, result tables y coordinate transform functions, y en MMX2 y MMX3 procesa todos los sprites
    • La PCB de Mega Man X2 tiene el CIC en U4, ROM de 8M en U1, ROM adicional en U2, CX4 en U3 y un oscilador de 20MHz en X1
  • S-DD1 es un chip de descompresión de sprites que puede suministrar datos directamente a la VRAM de la PPU
    • Se usó en dos juegos: Star Ocean y Street Fighter Alpha 2
    • Había un rumor de que el blank antes de empezar una ronda en Street Fighter Alpha 2 se debía al S-DD1, pero según la explicación de Modern Vintage Gamer el problema real estaba en transferir samples de sonido a la RAM del DSP
    • La PCB de Street Fighter Alpha 2 tiene una ROM de 4MiB en U1 y el S-DD1, que descomprime assets al vuelo; el CIC está integrado en el S-DD1, así que no hay chip separado
  • DSP-1 representa 16 de los 19 títulos compatibles con la familia DSP, y se usó en Super Mario Kart y Pilotwings
    • DSP significa Digital Signal Processor, pero se considera un nombre mal puesto porque no procesa señales continuas como un DSP típico
    • Según el manual de desarrolladores, DSP-1 opera en blocking mode, de modo que la CPU de Super NES espera mientras el DSP procesa datos
    • Proporciona instrucciones como multiplicación rápida de 16 bits, inverso, sin/cos projection, vector size y rotation, que fueron importantes para programar HDMA y actualizar la vista 3D de Mode 7
    • La PCB de Super Mario Kart tiene un CIC externo, ROM, SRAM para guardado, decodificador de direcciones MAD-1, batería y oscilador para operar a 8MHz
    • Las tres versiones DSP-1, DSP-1a y DSP-1b introdujeron correcciones de bugs y mejoras de proceso, pero su comportamiento varía ligeramente, lo que hizo que en la demo de Pilotwings el avión chocara contra el suelo
  • Otros chips más pequeños también se usaron de forma limitada en juegos concretos
    • DSP-2 se usó en un solo juego, Dungeon Master, para convertir rutinas de Atari ST, y parece haber servido principalmente para ayudar con el escalado de sprites
    • DSP-3 se usó en un solo juego, SD Gundam GX
    • DSP-4 se usó en dos juegos: Top Gear 3000 y The Planet's Champ TG 3000
    • OBC-1 se usó en un solo juego, Metal Combat: Falcon's Revenge, y se rumoreaba que servía para manipular sprites, pero hay debate en nesdev.org
    • S-RTC es un chip que rastrea un reloj en tiempo real en un solo título, Daikaijuu Monogatari II, y no está claro por qué un desarrollador de Hudson Soft necesitaba seguimiento en tiempo real
    • SPC7110 de Epson es un chip de descompresión de datos usado en Tengai Makyou Zero, Momotaro Dentetsu Happy y Super Power League 4; Super Power League 4 también tiene función de reloj en tiempo real
    • Se dice que la serie ST de SETA Corporation apuntaba a mejorar la IA de juegos; ST-010 se usó solo en Exhaust Heat 2, ST-011 solo en Hayazashi Nidan: Morita Shougi, y ST-018 solo en Hayazashi Nidan Morita Shougi 2
    • ST-018 parece ser una CPU ARM con instrucciones guardadas en una ROM interna

Familia Super FX y modificaciones de la comunidad

  • GSU-1 se usó en cinco juegos: Star Fox, Stunt Race FX, Vortex, Dirt Racer y Dirt Trax FX
    • Es uno de los chips auxiliares mejor documentados; hay wikis, tutoriales y materiales de Super Nintendo Developer Manual Book II
    • Opera a 10.74MHz y divide internamente a la mitad el master clock de 21.47MHz
    • Gracias a su instruction cache interna de 512 bytes, puede funcionar sin dejar sin recursos a la CPU de SNES
    • Cuando termina una tarea, puede generar una interrupción hacia la C-CPU, la CPU de la consola
  • Mientras que PPU1/PPU2 de SNES están orientadas a tilemaps y sprites, Super FX es fuerte en renderizado de píxeles y rasterización de polígonos
    • Normalmente renderiza en un framebuffer dentro del cartucho
    • El contenido del framebuffer se transfiere a VRAM durante VSYNC
    • La PCB de Star Fox tiene el GSU-1 en U3, el CIC en U5, un 74LS139 en U4, ROM en U1, y SRAM de 32KiB sin batería en U2
    • Esta SRAM se usa parcialmente para almacenar el framebuffer de Super FX, no como savegame
  • La comunidad de SNES también invierte tiempo en GSU-1, igual que con SA-1, e intenta mejorar al máximo títulos antiguos con proyectos como Project Super FX
  • GSU-2 es un GSU-1 que funciona a velocidad completa de 21.47MHz, y se usó en tres juegos: Super Mario World 2: Yoshi's Island, DOOM y Winter Gold
    • Hay un experimento comunitario que mostró el aumento de rendimiento al reemplazar el GSU-1 de un cartucho de Star Fox por un GSU-2
    • Randy Linden, de la versión de DOOM para SNES, hizo toda la ingeniería inversa sin documentación del chip GSU ni código fuente de DOOM
    • DOOM para SNES fue el único port de consola capaz de usar niveles de PC; las demás consolas tuvieron que simplificar la geometría
    • Yoshi's Island usa el GSU-2 principalmente para escalado y estiramiento de sprites, y vuelve a escribir los sprites manipulados en la VRAM de la PPU
    • La PCB de Yoshi's Island tiene batería, por lo que la SRAM se usa tanto para el framebuffer como para el estado guardado
    • DOOM fue overclockeado a 32MHz, aumentando el framerate de 10~11fps a 14~15fps
  • MSU-1 no es un chip que haya estado dentro de cartuchos lanzados comercialmente
    • Near lo diseñó para permitir streaming de audio con calidad de CD, reproducción de FMV y acceso a hasta 4GB de RAM en SNES
    • Está dirigido a la comunidad de modding de juegos, y los resultados pueden verse en Enhanced Zelda III: A link to the past y Enhanced Another World

La carga que dejó para la implementación de emuladores

  • Los chips auxiliares mejoraron mucho la experiencia de los jugadores y redujeron costos para los publishers, pero después se convirtieron en un desafío difícil para los desarrolladores de emuladores
  • Algunos juegos que dependían de EC poco comunes no fueron emulados correctamente hasta 2012
  • Al principio, como no se conocía la estructura interna del S-DD1, juegos como Street Fighter Alpha 2 se “emulaban” mediante paquetes gráficos de sprites graphic pack previamente descomprimidos
  • Implementar los chips requirió bastante ingeniería inversa
    • Algunos chips tenían funciones hardcodeadas, por lo que fue necesario hacer de-capping
    • En chips que almacenaban instrucciones en ROM interna, como los basados en ARM, el emulador debe recibir un archivo BIOS
  • Incluso en 2020, la emulación de algunos de los chips más raros todavía no estaba completa

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-04-23
Opiniones de Hacker News

  • Me encanta que los cartuchos de las consolas antiguas fueran casi iguales a las tarjetas de expansión PCI de una PC.
    Estaban conectados directamente al bus y básicamente podían hacer cualquier cosa, pero lamentablemente esa práctica se terminó después de GameBoy Advance, y desde Nintendo DS pasaron a ser más bien dispositivos puros de almacenamiento de datos.
    Por eso hoy son posibles expansiones modernas rarísimas, como un chip de ray tracinghttps://www.youtube.com/watch?v=2jee4tlakqo, e incluso el chip de expansión MSU1, que parece existir solo en emuladores de software y no como chip físico real.
    En teoría se podría fabricar, así que también se podría hacer un cartucho físico de Road Blaster para SNEShttps://www.youtube.com/watch?v=BvIXUOr4yxU.
    En el artículo en sí, en la lista aparece “Street Fighter Zero 2” como ROM de EE. UU., pero Street Fighter Zero era el nombre de Street Fighter Alpha en Japón, así que Zero 2 debería ser la versión japonesa de Alpha 2.

    • También existe la emulación inversa de NES, que es una locura total.
      Ahí, al reemplazar el cartucho por una computadora moderna, empiezan a pasar cosas raras. Por ejemplo, hacer con la NES lo que básicamente es una presentación de PowerPoint sobre humor.
      https://www.youtube.com/watch?v=ar9WRwCiSr0
    • No es del todo cierto. Algunos cartuchos de DS tenían al menos un receptor infrarrojo. Por ejemplo, Pokemon HeartGold; y, si no me equivoco, Learn with Pokémon: Typing Adventure incluso agregaba Bluetooth mediante la tarjeta.
      Así que sí había cierta capacidad limitada para agregar funciones, y aunque no fuera tan interesante como una CPU adicional, tampoco es que en GBA hubiera muchísimos casos de cosas tan impresionantes.
    • Me da curiosidad cómo funcionaban los juegos que traían un transmisor infrarrojo dentro del cartucho, como Pokemon SoulSilver.
      Me gustaría saber si estaba planeado para casos de uso específicos o si había algún canal separado para componentes limitados de expansión del cartucho.
    • Tengo entendido que los cartuchos flash modernos de SNES pueden soportar MSU1. MiSTer FPGA también soporta MSU1.
    • La localización de Street Fighter es un desastre. No entiendo por qué les cambiaron el mismo nombre a personajes distintos.

  • Otro detalle que falta aquí es que incluso los cartuchos sin chips de expansión tenían distintas categorías de rendimiento.
    La CPU del SNES nominalmente funcionaba a 3.58 MHz, pero para correr realmente a esa velocidad tenía que estar insertado un cartucho “FastROM”. Nintendo también ofrecía a los publishers un formato “SlowROM” más barato, en cuyo caso la CPU bajaba hasta 2.68 MHz.
    Hay una comunidad de modders que desarrolla parches para convertir juegos SlowROM en juegos FastROM y reducir el lag. Una vez leí que algunos juegos SlowROM parecían haber sido desarrollados originalmente para FastROM y luego cambiados a SlowROM a último momento por exigencias de los publishers para reducir costos.

    • Out Of This World es un caso SlowROM/FastROM en el que al desarrollador no le permitieron usar FastROM.
      Si mal no recuerdo, afirmaban que en ese caso usar SlowROM ahorraba nada menos que 50 centavos por cartucho.
    • Lo sorprendente del SNES es que ni siquiera se puede acceder a la RAM interna a los 3.58 MHz de reloj nominales, y aun entonces el sistema se ralentiza.
      Su competidora, la TurboGrafx-16, normalmente corría a 7 MHz y usaba una CPU de la familia 6502 que necesitaba timings de memoria similares; siempre me confundió por qué el SNES era tan tacaño con la velocidad.
      Aun así, la TurboGrafx fracasó en Occidente y la SNES tuvo éxito en todo el mundo, así que algo habrán hecho bien.
    • Siempre me pregunté si eso era una distinción de licencias inventada arbitrariamente por Nintendo o si realmente había una diferencia en la velocidad de lectura de datos del cartucho.
      Al final, todos los cartuchos de SNES tenían mask ROM.
    • Me pregunto si había una razón de hardware, o si Nintendo simplemente les estaba cobrando de más a sus clientes y empeorando la vida de los gamers.
    • Como el artículo menciona LoROM y HiROM, probablemente esté hablando de lo mismo.

  • Ojalá los desarrolladores siguieran blogueando estos detalles en formato escrito en vez de convertirlos en vlogs de YouTube.
    Se pueden meter muchos detalles en unos pocos KB.
    “Super Mario World” sigue siendo una obra maestra absoluta. Metieron personajes, sprites y niveles increíbles en apenas 360 KB.

    • El tamaño de archivo que aparece en el sitio está mal. Super Mario World ocupa 512 KB, y si se descarta el padding del final, 508 KB.
      Solo llega a unos 360 KB si se comprime en formato ZIP.
    • Super Mario World también es excelente, pero creo que el mejor juego de SNES es Donkey Kong Country 2.
      Hizo bien todos los aspectos de un juego de plataformas: música espectacular, controles precisos y gráficos atractivos.
      Terranigma está casi al mismo nivel, y para mí Super Mario World probablemente queda en tercer lugar.
    • Creo que una de las grandes razones por las que los desarrolladores eligen YouTube en vez de escribir es que, en muchos casos, es más difícil robar contenido en video.
      El texto se puede scrapear, cambiarle unas palabras y reutilizarlo en sitios de anuncios SEO.
    • “Pitfall!” de Atari VCS metía 255 pantallas de juego completamente distintas en un cartucho de 4 KB :)

  • Me pregunto qué se podría hacer hoy con tecnología moderna aprovechando la capacidad de poner “chips de expansión” en los cartuchos.
    Dice que SuperFX tiene su propio framebuffer y copia todo eso a la VRAM.
    Entonces, técnicamente, ¿sería posible meter un SoC absurdamente potente en el cartucho, renderizar con él gráficos modernos a la resolución de SNES y luego copiar el frame resultante a la VRAM del SNES?
    Me pregunto dónde está el límite.

  • La parte de que “Randy Linden, autor de DOOM para SNES, no tenía acceso ni a la documentación del chip GSU ni al código fuente de DOOM. Lo hizo todo mediante ingeniería inversa” es técnicamente impresionante, pero me da curiosidad por qué tuvo que ser así.

    • Hay detalles en Doom Wiki: https://doomwiki.org/wiki/Super_NES
      Randy Linden, quien fue el único programador del port, quedó fascinado con el juego y al principio empezó por su cuenta a portar Doom a Super NES.
      Como en ese momento el código fuente de Doom todavía no se había publicado, Linden consultó las Unofficial Doom Specs para entender en detalle la estructura de lumps del juego. Los recursos se extrajeron del IWAD, pero algunos no se usaron por limitaciones técnicas.
      Según entrevistas, como faltaban sistemas de desarrollo para Super FX, antes de encarar el desarrollo del port Linden creó por su cuenta en su Amiga un conjunto de herramientas llamado ACCESS, con ensamblador, linker y depurador.
      Como kit de hardware, conectó al puerto paralelo de la Amiga un cartucho de Star Fox hackeado y dos controles de Super NES modificados enchufados a la consola, y usó un protocolo serial para conectar dos dispositivos más.
      Después de crear un prototipo completo, se lo mostró a su empleador, Sculptured Software, y la empresa ayudó a terminar el desarrollo. Linden dijo que le habría gustado incluir los niveles faltantes, pero el juego ya había llegado al tamaño máximo de un juego de Super FX 2: 16 megabits, unos 2 MB, y quedaban apenas unos 16 bytes libres.
      También agregó compatibilidad con la pistola de luz Super Scope, el mouse de Super NES y el módem XBAND para multijugador. Su colega programador John Coffey, fan de la serie Doom, modificó niveles, aunque id Software rechazó algunos de ellos.
    • En el port de Wolfenstein 3D pasó algo parecido. John Carmack elogió a Rebecca Heineman por aprender japonés para leer patentes con el fin de conseguir documentación técnica.
      Siempre hay historias geniales alrededor de estas cosas, y también dejé algo más sobre el tema aquí: https://eludevisibility.org/super-noahs-ark-3d-source-code
    • No conozco este caso, pero los kits de desarrollo y los SDK/documentación a menudo son SKU separados, y muchas veces estos últimos son más caros.
      Si no recuerdo mal, el equipo de Crash Bandicoot tampoco tenía el SDK, así que usó código propio y terminó encontrando un bug de hardware relacionado con el guardado en tarjetas de memoria.

  • Me pregunto de dónde salieron los conteos de bytes de varios juegos.
    Los juegos venían en chips ROM y, como corresponde a los chips ROM, sus tamaños eran potencias de 2. Por ejemplo, Super Mario World salió en una ROM de 512 kb, así que ¿de dónde sale la cifra de 346,330 bytes? ¿Es el tamaño comprimido?

    • Las cifras son estimaciones basadas en el tamaño de los ZIP. Pero no es un buen método.
      Habría que escribir un programa que descomprima cada ZIP y cuente el padding de bytes 0 al final del archivo.
      Hoy ya es muy tarde; mañana lo escribiré y actualizaré el artículo.
    • Parece el tamaño comprimido. Si comprimís SMW.SMC con gzip, sale un archivo de 347 KB. Eso es bastante engañoso.
      También hay otros problemas. El artículo lo plantea como si MVG hubiera descubierto que los congelamientos de SFA2 se debían a la carga de datos de audio, pero eso ya se sabía desde mucho antes de ese video: https://forums.nesdev.org/viewtopic.php?p=70474#p70474
      También parece bastante confundido respecto al RTC. Es obvio, como en los juegos de Pokémon para GBC/GBA, que la intención era que el reloj siguiera corriendo aunque la consola estuviera apagada y el cartucho fuera retirado, pero habla como si quizá pudiera deberse al drift del reloj NTSC. No entiendo qué quiso decir con eso.
    • Es padding de datos.

  • Sobre la parte que dice “Super Mario World también recibió este tratamiento. No recuerdo ralentizaciones, pero en ese entonces apenas tenía doce años”, Yoshi’s Island 4 tiene ralentizaciones bajo ciertas condiciones.
    Pasa si conseguís un Starman montado en Yoshi y presionás un P-Switch, y también en otro nivel que no recuerdo exactamente. Era un lugar donde salen muchos Monty Mole de golpe; creo que era en Chocolate Island.
    Creo que había un tercer caso en el que aparecen en pantalla dos Sumo Bros. junto con un Amazing Flying Hammer Bro.

    • Recuerdo que en Outrageous el lag era enorme.

  • Nunca entendí cómo se dumpean desde un cartucho las ROM para emuladores.
    Entiendo que se dumpeen las instrucciones y los assets, y que se empaqueten en un archivo de datos que el emulador pueda interpretar. Pero ¿cómo modela el emulador todo el hardware de chips de expansión dentro del cartucho? ¿Cómo se dumpea eso desde el cartucho original?

    • Los chips de expansión no son ROM, así que hay que emularlos por separado.
      Personalmente, creo que la situación era un poco peor en la NES, la antecesora de la SNES.
      La NES tenía bastantes chips de expansión llamados mappers. Su función habitual era ampliar el espacio de memoria de la NES, más que agregar procesadores o capacidades adicionales; sin ellos, la NES quedaba limitada a 32 KB de PRG ROM y 4 KB u 8 KB de ROM gráfica CHR, así que estaban presentes en la mayoría de los juegos.
      La mayoría de los juegos posteriores al lanzamiento de la NES usaron estos chips.
      También hubo que aplicar ingeniería inversa a todos ellos, además de a la propia consola. Por suerte, eran mucho más simples que hacer ingeniería inversa de una CPU adicional o un acelerador.
      Hay chips comunes usados en muchos juegos, como MMC1 y MMC3, y otros como MMC2, que en la práctica se usó casi exclusivamente para Punch-Out.
    • No se dumpean. La implementación del emulador reproduce en software la funcionalidad de los chips de expansión.
      No hay tantísimos tipos de chips de expansión, así que no es algo inmanejable.

  • El método de protección contra copias del SNES era fácil de eludir desde el punto de vista del consumidor. Aunque quizá no lo era para los desarrolladores o publishers de juegos.
    En esa época todo el mundo tenía un “dispositivo de respaldo” para SNES. Era un aparato que se conectaba al SNES y tenía una unidad de disquetes, y permitía “respaldar” juegos en disquetes de 3.5 pulgadas muy baratos.
    Lo único necesario para que el sistema funcionara era un cartucho original; al insertarlo en la copiadora, el dispositivo reutilizaba el chip CIC de ese cartucho.
    https://en.wikipedia.org/wiki/Game_backup_device

  • Al leer la parte que dice: “El DSP-1 tuvo tres versiones: DSP-1, DSP-1a y DSP-1b. Con correcciones de bugs y mejoras en el proceso de fabricación, el comportamiento del chip cambió ligeramente y, como resultado, el avión de la demo de Pilot Wings se estrellaba contra el suelo”, creo que voy a usar esa excusa cuando alguien me pregunte por qué soy tan malo jugando.