[HO] Former Dawn (NES). Avances y actualizaciones.

Consola: NES
Grupo: Something Nerdy Studios
Mapper: MXM-0 (propio)
Fecha de salida: Indeterminado

Demos públicas:

PC emulación -> MesenMXM: Download Former Dawn Playable Demo v3.2

Flashcard ->EverDrive N8 Pro: Download Former Dawn Playable Demo v3.2

Video demo de la versión 2.7:



Anuncio del Kickstarter:



Kickstarter: https://www.kickstarter.com/projects/so ... ref=8iw7dt

Como todos sabeís, actualmente la NES goza de una etapa dorada en la scene homebrew por ser la consola que más videojuegos nuevos está recibiendo en los ultimos años, a parte de diversas demos técnicas.

Aquí deberiamos postrarnos actualmente ante el proyecto Former Dawn, un videojuego homebrew que está realizando el equipo de Something Nerdy Studio.

Pero además, Something Nerdy Studio está desarrollando su propio mapeador de memoria para NES, cuya filosofía consiste en respetar las limitaciones de la NES, pero explotar todo lo que se pueda los accesos que permite a su CPU y PPU para sacar el máximo partido al hardware.

De esta formar, nace MXM-0, un mapeador del que ya he hablado hace meses en el Hilo Oficial de la NES y que hará volar la cabeza a más de uno.

Pero vayamos por partes. Antes de nada, presentaremos Former Dawn, para ir abriendo bocas:








Twitter: https://twitter.com/SomethinNerdy

No se sabé mucho más de el. Como es obvió, nos vamos a encontrar ante un Action-RPG de corte clásico que recuerda mucho a Chronno Triger de SNES. Y poco más se sabe.

Sobre el tema del MXM-0, nos presentan el mapeador más avanzado hasta la fecha cuya idea original era imaginar como hubiese sido un CD-ROM para NES si este hubiese sido lanzado en 1994, al final de la vida util de la consola. Como es obvio, con la tecnología actual, ya no nos hace falta el CD-ROM para acceder a los datos, y se ha tratado de adaptar todo a meros integrados ROMS, muy al estilo Neo Geo. Además, el mapeador añade chip de sonido propio para poner más canales (como hacian Konami, Sunsoft o Namco en su día), un reproductor FMV, y otras mejoras que ponen al PPU (unidad de procesamiento de imagenes) de la NES al límite máximo y real.

En resumen:

- Hasta 2,8GB de acceso a datos PRG/CHR
- Añade 1Mb de RAM
- Reestructuración de la búsquedas de datos del PPU para mejorar su fluided, pudiendo ahora:
*Mostrar 960 tiles únicos por background (como hacía el MMC5 en 1990).
*Compatibilidad con las 4 nametables background a la vez (esto está integrado en el hardware de NES pero pocas veces usado).
*Atributos de color para backgrounds de 8×8 pixeles (como hacía el MMC5 en un background estático) y/o ¡8×1 pixeles!
- Cambio de banco PRG/CHR automático.
- Cambio de banco de nametables rápido y automático que permite animaciones de fondo de alto rendimiento.
- Un contador de línea de exploración IRQ perfécto, sin los errores vistos en MMC3 o MMC5.
- El PCM de la NES permite muestras de 16MB.
- Chip de síntesis de audio [emulación] (YM2608, YM2610, YM2612, etc.) para expansión de audio.
- Reproducción de vídeos FMV.

Si quereís saber más, os paso enlace a su web: https://somethingnerdy.com/

Y además, os pongo traducido el último articulo que han publicado hablando sobre el desarrollo del mapeador MXM-0 y el videojuego Former Dawn. Lo he hecho con Google Translater, e intentaré arreglar lo que vaya viendo.



31 de enero de 2022 por Jared Hoag

Definición de desbloquear
verbo transitivo
3 : liberarse de ataduras o restricciones
// el impacto desbloqueó un torrente de lágrimas

Former Dawn pretende ser el ejemplo más extremo hasta ahora de lo que podría llamarse Neo Vintage: un juego nuevo para un sistema antiguo. Esto es literalmente lo opuesto al excelente foro VOGONS (Very Old Games On New Systems). Cuando formamos Something Nerdy Studios a principios de 2019 y lanzamos nuestro primer proyecto de juego, todos sentimos que crear un juego de rol moderno y avanzado dirigido a NES sería algo realmente divertido y genial, pero los mapeadores de memoria disponibles del apogeo del sistema parecía demasiado limitante. Sabíamos bastante bien que lo más fácil sería rendirnos y hacer un juego retro en la PC, pero eso nos molestó. No solo era un mercado muy concurrido para 2019, sino que no era lo suficientemente bueno simplemente para crear un NES- comojuego que nunca podría funcionar en una NES real. ¡Queríamos saber hasta dónde podíamos llegar en la realidad!



Al principio, parecía que MMC3 o MMC5 serían nuestra mejor opción, a pesar de la persistente sensación de que se podría crear algo mucho mejor si solo tuviéramos los conocimientos y las conexiones de fabricación. Nos pareció que había un gran potencial sin explotar en la NES, y que proporcionarle montones de ROM es la forma principal de aprovecharlo. Aunque NEC fue pionera en tamaños de ROM muy grandes a principios de los 90 a través de Neo·Geo, tanto ese sistema como los juegos para él eran excesivamente caros debido a los precios de las ROM de máscara en ese momento. ¿Y si hubiera habido una solución más económica en ese entonces? Específicamente, ¿qué pasaría si la NES hubiera disfrutado de juegos en CD-ROM que hubieran continuado su vida útil y le hubieran dado un mordisco a TurboGrafx-CD, Sega CD y 3DO? Trate de imaginar cómo serían los juegos de PC modernos si solo tuviera 1 mega para jugar; ¿alguien se lo tomaría en serio? Claro, todavía se podría hacer mucho en 1 mega, pero no sería suficiente espacio para las funciones que los jugadores modernos esperan en los juegos nuevos:incluso juegos independientes. Del mismo modo, no hay una buena razón para pensar que no ocurre lo mismo con la NES.



Además de los requisitos de espacio, hay muchas piezas de fruta al alcance de la mano que casi ningún juego clásico de NES arrancó. Por ejemplo, ¿sabía que el desplazamiento diagonal sin fallos (usando 4 "tablas de nombres") se incorporó al diseño de hardware de la NES desde el principio? A pesar de que Super Mario Bros. 3 usó el mapeador de memoria MMC3, Nintendo optó por no hacerlo .para incluir la pequeña cantidad de RAM adicional en el cartucho necesaria para desbloquear la mejora de desplazamiento de MMC3, que es la razón por la cual las desagradables fallos gráficos aparecen en el lado derecho del background durante el juego. Ese tipo de cosas nos parecieron imperdonables, así que para mojarnos los pies, implementamos un desplazamiento de 8 direcciones sin fallos y perfectamente suave en una demostración del juego "simulador de caminar" MMC3. Hasta donde sabemos, esto solo se logró en NES (léase: no en Famicom) en 1 título: Tengen's Gauntlet(que técnicamente es un predecesor más simple de MMC3). E incluso en ese juego solo había 4 pantallas por nivel, que es la forma más fácil de hacerlo. Nuestra prueba de concepto presentaba un nivel de 16 pantallas con muchos gráficos complejos, con la capacidad de agregar aún más pantallas. Esta fue una hazaña mucho más difícil, pero lo que es más importante, mucho más conducente a algo así como un juego de rol en expansión.



Por lo tanto, envalentonados pero sin la capacidad de crear nuestro propio mapeador, seguimos adelante con la invención de tantos trucos nuevos como pudimos, lo que se llamó "novedades" en la oficina. Terminamos creando bastantes de estos... tantos que realmente parecía que las limitaciones de espacio ROM de MMC3 nos habrían impedido explotarlos por completo. MMC5 permitió un poco más de espacio que MMC3 (aproximadamente el doble), pero carecía de la función de tabla de nombres cuádruple de MMC3. MMC5 también lucía atributos de 8 × 8 (es decir, una coloración más densa del background de lo que permiten los atributos de 16 × 16 estándar de NES), pero la función está programada para usar solo una tabla de nombres. Por lo tanto, 8×8 está tan roto en MMC5 que no funciona correctamente con el desplazamiento por hardware. Toda esta situación del mapeador clásico era un desastre y, en cualquier caso,

Fue en ese momento que tuvimos la suerte de conocer a Paul Molloy de Infinite NES Lives. Le contamos nuestras ambiciones y él, a su vez, nos dijo que había diseñado un nuevo tipo de cartucho NES basado en FPGA que probablemente satisfaría nuestras necesidades. En ese momento, necesitaba resolver algunos problemas y rediseñar parcialmente la placa de circuito impreso, pero allí había suficiente funcionalidad para decirnos que teníamos nuestro camino a seguir. El principal problema era que el hardware no era suficiente; al menos uno de nosotros tuvo que aprender Verilog para implementar nuestro mapeador en ese hardware. Pero a su vez, antes de especificar el mapeador en Verilog, ¡teníamos que saber qué especificar!
Este demake de logotipo para NES de Ellen Larsson es la única parte legítima de Doom que realmente puede ejecutarse en NES.

Hasta ese momento, había llamado descaradamente a mi mapeador de fantasía "The Gigamapper", porque, como mínimo, proporcionaría acceso a la CPU y PPU de la NES a un gigabyte de ROM. (También jugamos con darle solo un giga bit de ROM, para estar en línea con la nomenclatura de tamaño de ROM de NES y SNES). Este requisito básico ahora parecía casi trivial, y rápidamente se hizo evidente que podíamos hacer muchas, muchas cosas con un cartucho como este que hasta ahora había sido imposible. Pero definitivamente no queríamos "hacer trampa" como lo hace Doom-on-the-Raspberry-Pi-on-the-NES. Algo innegablemente anacrónico como eso estaba muy lejos de nuestros intereses. En otras palabras, la NES necesitaba algo nuevo que podría haber sido algo viejo, pero nunca lo fue. ¿Qué hacer entonces?

= Principios Rectores =

Decidimos que, dado que 1994 marcó el final de la vida útil original de NES, teníamos que crear un sistema de expansión que hubiera sido plausible en 1994, tecnológica y económicamente. Este es el principio básico a partir del cual fluye el resto de nuestra filosofía de diseño de mapeadores. Al mismo tiempo, elegimos no hacer absolutamente todo lo que era posible en 1994. Esto se debe en parte a que queríamos saber de qué era capaz la NES "por sí sola" en el sentido muy específico de que todavía hace todos los cálculos. que son fines en sí mismos. Esencialmente, esto significa que algo parecido a una expansión de CD-ROM está perfectamente bien, pero que un acelerador 3D o un coprocesador matemático no lo están.

Además, los algoritmos de compresión de video como MPEG eran, en el mejor de los casos, sospechosos y preferíamos evitarlos. Aunque MPEG-2 salió en 1994, estaba destinado a resoluciones de pantalla, libertades de paleta y profundidades de color que no son posibles en NES. Debido a esto, para poder usarlo, tendríamos que implementar una lógica de conversión adicional en el hardware, lo que probablemente violaría el requisito económico mencionado anteriormente (incluso más de lo que ya haría agregar un decodificador MPEG a la lista de materiales). Probablemente también daría como resultado una calidad de imagen terrible en comparación con los algoritmos personalizados que se nos ocurrieron.

Cuestionamos estos principios y después de mucho debate en la oficina y con otras personas en la comunidad de desarrollo de NES más amplia, llegamos a estas conclusiones. Para facilitar la lectura y el contraste, se dividen entre lo que se debe y lo que no se debe hacer.

= Conclusiones =

La jerga técnica es prácticamente inevitable cuando se habla de un tema como este, así que aquí está. Cualquier persona a la que no le importen estos detalles puede saltar a continuación, donde demostraré gráficamente lo que desbloquean estas funciones en el desarrollo de juegos de NES.

Permitido:

- Acceso directo a la mayor cantidad de datos que se pueden almacenar en poco más de 1 CD-ROM. (768MiB)
- Acceso indirecto a la mayor cantidad de datos que se puedan almacenar en 4 CD-ROM. (2,8 GiB)
- Acceso directo a hasta 1 MiB de RAM.
- Interponer las búsquedas de datos del PPU para aliviar limitaciones onerosas:
* 256 tiles únicos por background -> 960 tiles únicos por background.
* 2 tablas de nombres -> 4 tablas de nombres.
* Atributos 16×16 -> Atributos 8×8 y/o 8×1.
- Cambio de banco automático que facilita los puntos 4.1 y 4.3.
- Cambio de banco de tabla de nombres, lo que permite animaciones de fondo de alto rendimiento compuestas con otras características del mapeador.
- Atributo bankswitching que facilita el ítem 4.3.
- Múltiples bancos CHR de grano fino. (16 bancos de 512 bytes cada uno)
- Múltiples bancos de PRG de grano medio. (4 bancos de 8KiB cada uno)
- Corrección de errores o funciones de "eliminación de fallos", simplemente para corregir el comportamiento que equivale a errores en el diseño de hardware de NES.
- Contador de línea de exploración. (Mejor que MMC3, ya que funciona correctamente con todas las demás funciones del mapeador).
- Expansión del tamaño de la muestra de DPCM. (4081 bytes -> 16MiB)
- Chip de síntesis de audio [emulación] (YM2608, YM2610, YM2612, etc.) para expansión de audio.
- ROM y RAM de doble puerto.

Prohibido:

- Descarga de cálculos de propósito general. (Es decir, sin CPU, FPU o cualquier otro tipo de coprocesador en el cartucho).
- Descarga de procesamiento gráfico. (Así que nada como Super FX, SA-1, etc.)
- Transmisión de audio PCM a través de audio de expansión.
- Exceder el poder computacional o la complejidad del propio NES.
- Superando la complejidad del circuito de MMC5, que fue el mapeador de memoria clásico más complicado para NES.
- Re-implementar el PPU por cualquier motivo.
- Factor de forma física más grande que un Game Pak tradicional. (Es decir, el cartucho del juego debe encajar correctamente en una NES de carga frontal).
- Transferencia de datos desde la tarjeta SD a la RAM del cartucho a una velocidad de datos que supera la de una unidad de CD-ROM de velocidad cuádruple. (600 KiB/s)

Nuestro mapeador de memoria comenzó como un código C++ insertado en nuestra bifurcación local de Mesen, y solo implementó la función 1. Todas las demás funciones, excepto la 2, 13 y 14, eventualmente se implementaron juntas en un solo paquete que llamamos Módulo de expansión de memoria 0 o MXM-0. Tomar MXM-0 y combinarlo con stubs para 2 y 13 es lo que llamamos MXM-1. Notarás que la característica 14 se deja fuera de ambos; eso se debe a que INL nos proporciona esa función en el cartucho. Por lo tanto, en realidad no es parte de nuestro(s) mapeador(es). La función 13 también está simplemente anulada, porque estamos creando tres tipos diferentes de cartuchos para Former Dawn : uno con un ASIC Yamaha YM2610 genuino en su interior, uno con síntesis de audio YM2610 simulada que habita en el FPGA que implementa MXM-1 y otro sin audio de expansión por completo. .

MXM-0 y MXM-1 ahora también están implementados en Verilog, con casi todas las funciones totalmente utilizables y completas. Como todos los mapeadores de memoria clásicos para NES, el nuestro funciona maravillosamente en EverDrive N8 Pro. Muy pronto adaptaremos MXM-1 a nuestros prototipos de cartuchos de INL. En otras palabras, este mapeador es real . ¡No es una construcción teórica! Cualquiera de ustedes con un hardware NES genuino (cargador frontal o cargador superior) podría insertar uno de nuestros cartuchos de desarrollo N8 Pro y ejecutar la versión actual de Former Dawn ahora mismo. La compatibilidad con los clones de NES varía, pero es bastante buena; más sobre eso más tarde.

= Explicación (Permitido) =

Para comprender nuestras motivaciones para implementar cada una de las funciones permitidas, cada una debe describirse con cierto detalle junto con ejemplos visuales, si es posible. En tales casos, la imagen de la izquierda será un juego de NES que sufrirá las restricciones clásicas, y la imagen de la derecha será algo posible gracias a MXM, preferiblemente de Former Dawn .

1. Acceso directo a la mayor cantidad de datos que se pueden almacenar en poco más de 1 CD-ROM. (768MiB)





Cuando comenzamos a implementar lo que se conoció como MXM-0, pensamos que Former Dawniba a almacenarse completamente en NOR flash en la nueva placa INL. (Dado que la producción de ROM de máscara incurre en costos fijos prohibitivos, esto es lo que todos los demás en la escena "homebrew" moderna de NES están haciendo). Debido a varias incertidumbres en el suministro de chips y dificultades técnicas, optamos por aceptar la oferta de INL de incluir una tarjeta SD en El cartucho también. Resulta que creemos que la parte de acceso rápido del juego se puede almacenar cómodamente en 16MiB de ROM (flash NOR). Si hubiéramos sabido desde el principio que íbamos a ir por la ruta de la tarjeta SD, es posible que no hubiéramos facilitado el acceso directo a 768MiB de ROM en MXM-0. Pero lo hicimos, y ahora no vemos ninguna razón para eliminarlo, especialmente porque cualquiera que use MXM-0 en el futuro podría querer crear un cartucho de estilo Neo·Geo para NES con una gran cantidad de ROM en forma de chip en lugar de tarjeta SD. ¿Por qué no? En cualquier caso, el punto básico es que tener tanta ROM significa que ahora uno puede gastar esa ROM generosamente para actualizar la cantidad.y la calidad de prácticamente cualquier aspecto de un juego de NES que se te ocurra.


2. Acceso indirecto a tantos datos como puedan almacenarse en 4 CD-ROM. (2,8 GiB)







Debido al hecho de que estamos basando las especificaciones del cartucho y el consumo de memoria de Former Dawn en una consola de CD-ROM clásica o un complemento de consola, tenía sentido basar nuestros límites de ROM en ejemplos reales de juegos de CD-ROM de la principios de los 90 La mayoría de los juegos en CD-ROM usaban solo 1 disco, pero algunos usaban más, incluso al principio. Night Trap , lanzado en 1992 para 3DO y Sega CD salió en 2 discos. A fines de 1994, Slam City con Scottie Pipp ense lanzó para el CD de Sega y contenía 4 discos, y este puede ser el récord de 1994. Por lo tanto, estamos configurando nuestro tamaño máximo de ROM en 4 CD-ROM o 2,8 GiB. Que nos acerquemos o no a eso depende de cuánto FMV terminemos incluyendo en el juego. Ningún otro activo empujaría la huella de la ROM más allá del valor de 1 disco. Incluso si la OST tuviera una duración de 2 horas y la almacenáramos como PCM mono sin procesar de 7 bits y 33,1 KHz, solo necesitaríamos 239 MiB. Antes de MXM-0, los tamaños de ROM y los mapeadores de memoria más primitivos significaban que FMV en NES nunca se lograba con la velocidad de fotogramas completa en pantalla completa.


3. Acceso directo a hasta 1 MiB de RAM.

Para justificar la decisión de incluir 1MiB de RAM en este sistema de expansión, hay 3 preguntas relevantes: A) ¿Esta cantidad de RAM puede ser razonablemente utilizada por una CPU basada en 6502? B) ¿Habría sido económico hacerlo a finales de 1994? C) ¿POR QUÉ?

R) Sí. Apple //e admite hasta 1MiB de RAM. Todo lo que se necesita es un cambio de banco y/o una carga en serie cuidadosamente administrados.

B) Técnicamente, estamos usando 1MiB de RAM estática, lo que no hubiera sido económico en 1994. Pero esto se debe a que nos resulta más económico usar SRAM que DRAM en 2021. Usar RAM dinámica implicaría tener que tener algún tipo de memoria controlador en el cartucho, lo que costaría mucho dinero y tiempo de ingeniería, sin mencionar que posiblemente excedería nuestra energía eléctrica disponible. Sin embargo, tenga en cuenta que la PlayStation original se lanzó a fines de 1994 y tenía más de 3MiB de RAM integrados.

¿Por qué? Porque lo necesitamos. Los juegos de cartuchos clásicos en NES a menudo tenían 8KiB de RAM integrados y algunos tenían hasta 32KiB. La razón por la que necesitaban comparativamente poca memoria RAM era que todos los activos del juego estaban almacenados en una ROM de máscara que actuaba como RAM en términos de velocidades de acceso. Esto es algo que puede ser difícil de apreciar para cualquiera que venga del mundo de los juegos de PC, donde la memoria RAM es crucial (sin juego de palabras). Cuando cambia a un tipo de modelo de acceso de CD-ROM, necesita un gran búfer para contener niveles, gráficos, etc. Una de las muchas razones por las que fallaron las primeras consolas de videojuegos basadas en CD-ROM es que no tenían suficiente RAM. para servir como un búfer para los datos provenientes de la unidad de CD-ROM. Esto aumentó innecesariamente la frecuencia de los tiempos de carga, o "golpeteo", y resultó en una experiencia de juego terrible. En realidad, nos estamos restringiendo de manera bastante significativa para concentrar todo lo que queremos hacer en 1 MiB de RAM.

Considere el hecho de que el FDS tenía un búfer de 32 KiB para cargas desde los disquetes a pesar de que cada lado solo tenía 56 KiB. Eso significa que hasta el 29% de un juego podría almacenarse en caché en un momento dado en la RAM. Dado queEs probable que el antiguo Dawn ocupe docenas de megabytes incluso sin FMV involucrado, nuestra proporción correspondiente es más del 3%; Es decir, estamos sufriendo con aproximadamente una décima parte del búfer en una comparación de manzanas con manzanas. Existe la posibilidad de que podamos hacer que nuestro código sea lo suficientemente eficiente como para reducir todo aún más y trabajar con 512 KiB de RAM en lugar de los 1024 KiB completos, en cuyo caso ahorraremos algo de dinero en la lista de materiales para los cartuchos y nos sentiremos un poco más presumidos.


4. Interponer las búsquedas de datos de la PPU .

La mayoría de los mapeadores de memoria clásicos para NES interponen el PPU de alguna manera. Por lo general, era para proporcionar más de los míseros 8KiB de CHR, pero a veces se hacía para facilitar CHR-ROM y CHR-RAM en el mismo cartucho (MMC3), proporcionar más de 256 tiles por cuadro (MMC5), cambio automático de CHR en mitad del background (MMC2), entre otras razones. Hemos llevado todo esto a sus extremos lógicos; aquí están los detalles:





4.1. 256 tiles únicos por background -> 960 tiles únicos por background.
Debido a la naturaleza de 8 bits de la CPU (y la PPU), existen muchas restricciones artificiales en el diseño de la NES. Uno de ellos es el hecho de que sin el soporte del mapeador, no puede colocar más de 2^8 = 256 tiles únicos en un solo background, a pesar de que el background en sí requiere 960 tiles para cubrirlo por completo. MMC5 levantó esta restricción hasta 960 tiles de un conjunto máximo de 16 384. MXM-0 lo eleva aún más a 960 tiles de un máximo de 65,536. Cuando se limita a 256 tiles por escena, se coloca una gran carga sobre el artista para crear la ilusión de que no existe una restricción tan fuerte. Esto se puede lograr haciendo la escena/imagen más pequeña o reutilizando tiles por todas partes. El resultado típico en la era clásica de NES fue un aspecto muy estampado o simplista en lugar de mostrar un arte más intrincado ("entrópico").





4.2. 2 tablas de nombres -> 4 tablas de nombres.
Como se mencionó en el preámbulo, incluimos soporte para 4 tablas de nombres principalmente para facilitar el desplazamiento fluido de 8 direcciones sin restricciones. De hecho, tenemos soporte para másde 4 tablas de nombres, pero solo a través de la conmutación de bancos. En un momento dado, el PPU "ve" 4 tablas de nombres porque así fue diseñado para funcionar. Una de las razones por las que los desarrolladores de los juegos NES de la era original aceptaron fallos tan terribles (resultantes de tener solo 2 tablas de nombres) en sus sistemas de desplazamiento es que la mayoría de los televisores CRT minoristas del día oscurecieron los errores debido a la sobreexploración típica de NTSC. No tenemos ese lujo porque mucha gente usa PVM, escaladores o emuladores para jugar juegos de NES en la era moderna. Nos mantenemos en el estándar máximo: el juego debe verse perfecto cuando se ve en la pantalla al completo de 256 × 240, en todo momento.





4.3. Atributos 16×16 -> Atributos 8×8 y/o 8×1.
El hardware estándar de NES impone una cuadrícula de "atributos" a lo largo de la pantalla donde cada cuadrado de 16px X 16px (un "metátile") tiene que suscribirse a una paleta de 4 colores de las 4 paletas de tiles de fondo totales que están en la memoria RAM interna de la PPU en cualquier momento. tiempo dado. Esta es una restricción extrema que, naturalmente, hizo que casi todos los juegos para Famicom/NES tuvieran cierto aspecto debido a lo difícil que es "luchar contra la red", para usar un término que acuñó David Crane. MMC5 eliminó esta restricción para que la cuadrícula de atributos sea 4 veces más granular: 8×8 cuadrados en su lugar. Desafortunadamente, el modo de atributo 8×8 de MMC5 no es realmente compatible con el desplazamiento por hardware porque solo funciona con 1 tabla de nombres a la vez. Debido a que creemos firmemente que la función de desplazamiento por hardware de la NES es lo más importante de su diseño, fuimos más allá de lo que hizo MMC5 en este sentido.Totalmente compatible con desplazamiento por hardware en las 8 direcciones, usando 4 tablas de nombres simultáneas como se mencionó en 4.2. Después de eso, fuimos aún más lejos y creamos un modo de atributo 8×1 que también es totalmente compatible con tablas de nombres cuádruples. Este modo de atributos de 8×1 es clave para la estética de Former Dawn , porque permite que la PPU dibuje con la mayor libertad posible dadas sus limitaciones de diseño intrínsecas.

En otras palabras, no hay más mejoras que hacer. Es literalmente imposible obtener atributos de 1×1 (es decir, gráficos completamente en mapa de bits) en toda la pantalla. En una región local de un cuadro, se pueden superponer varios sprites.utilizarse para lograr esto. Pero eso tiene el costo extremadamente alto de explotar el sistema de sprites, que es algo que rara vez vale la pena. Nuestro modo de atributo 8×1 se puede usar libremente en todo el juego, lo que significa que los artistas del proyecto tienen mucha más libertad para usar sus habilidades de pixel art para lograr sombreados complejos en toda la pantalla, algo que hasta ahora era imposible en NES. Por extraño que parezca, esto sigue siendo imposible en la SNES debido al hecho de que la dirección y los pines de datos de la (S-)PPU no están directamente expuestos a la ranura del cartucho en ese sistema. Por lo tanto, hasta donde sabemos, este modo de atributo 8×1 en MXM-0 y MXM-1 es algo completamente único en todo el espacio de las consolas de juegos antiguas que usan gráficos de fondo basados ​​en tiles.


5. Cambio de banco automático que facilita los puntos 4.1 y 4.3.

Para evitar molestas dificultades y restricciones de tiempo, también mejoramos el cambio de banco de CHR para que sea automático en función de los metadatos que ingresamos a CHR entre regiones de datos de tiles. Esto ayuda a liberar la CPU para realizar el trabajo importante que solo ella puede hacer. Ya sabes, ejecutar la lógica del juego en lugar de cuidar el PPU o el mapeador de memoria.


6. Cambio de banco de tabla de nombres .





Yendo más allá en la línea de evitar que la CPU cuide a la PPU, implementamos el cambio de banco de la tabla de nombres de una manera muy útil. Nuevamente, esta es una función que técnicamente se implementó en mapeadores de memoria anteriores (por ejemplo, Sunsoft-4, que usó After Burner), pero esas implementaciones no se desarrollaron lo suficiente como para ser realmente útiles. Nuestro cambio de banco de tabla de nombres se puede componer con cambio de banco CHR automático y atributos 8×1 u 8×8. Esto permite tiles de fondo intrincadamente animados sin obligar a la CPU a atravesar los datos de la tabla de nombres y actualizar regiones para facilitar esa animación. ¡También significa que se pueden usar varios tiles en la misma pantalla simultáneamente, e incluso animarse a diferentes velocidades de cuadro! Esta sutileza es clave para hacer Former DawnLos entornos de se sienten dinámicos y vivos sin sentirse abrumadores (como lo es en Willow), algo que incluso Chrono Trigger no logró de manera consistente. Para ser justos, SNES es más que capaz de lograr lo mismo por otros medios, por lo que probablemente solo falte en Chrono Trigger debido a las limitaciones de tamaño de ROM que no sufrimos.


7. Atributo bankswitching que facilita el ítem 4.3.

Este es un requisito sencillo. Solo lo menciono para señalar que era necesario para que otras funciones funcionaran.


8. Múltiples bancos CHR de grano fino. (16 bancos de 512 bytes cada uno)

Los mapeadores de memoria clásicos tenían varias granularidades de conmutación de bancos CHR, que iban desde 8 KiB (1 banco) hasta 1 KiB (8 bancos). Llevamos esto más lejos a 16 bancos de 512 bytes cada uno. Esto hace posible tener 16 entidades basadas en sprites en el background simultáneamente, todas con animación independiente. (Por ejemplo, personajes jugables, NPC, enemigos o elementos de fondo modelados con sprites). En la práctica, rara vez usaremos más de 8 de estas entidades debido al límite global de sprites por cuadro de 64. Sin embargo, la libertad de cargar entidades con entusiasmo en pequeños bancos independientes facilita enormemente el esfuerzo de programación. Por ejemplo, los efectos de proyectiles y partículas se pueden poner en cola antes de mostrarlos mientras se procesan los activos actuales. También podemos mezclar y combinar diferentes enemigos y NPC en todo el mundo de Astraea sin duplicar gráficos en ROM y sin acoplar sus cuadros de animación entre sí. Este desacoplamiento técnico parecía muy importante para mostrar a Astraea como el mundo rico y variado que se supone que es.


9. Múltiples bancos de PRG de grano medio. (4 bancos de 8KiB cada uno)

Dividir PRG en 4 bancos de 8KiB cada uno parecía el mejor enfoque para abordar las preocupaciones de la organización del código ensamblado 6502 y la facilidad de administración en tiempo de ejecución. Las subrutinas menores a 8KiB y relacionadas a menudo no estarían disponibles simultáneamente. Cualquier cambio de banco más grande que 8KiB e incómodo tendría que realizarse con mucha más frecuencia cuando partes dispares de la base de código se llamen entre sí.


10. Funciones de corrección de errores o "eliminación de fallos" .





Cualquiera que haya jugado extensamente a la biblioteca de juegos clásica de NES seguramente se habrá topado con numerosos ejemplos de fallos de renderizado. Los ejemplos destacados incluyen: píxeles parpadeantes en el borde entre el campo de juego y el HUD en Super Mario Bros. 3 , píxeles parpadeantes en mitad de la pantalla de selección de nivel en Mega Man 3 y píxeles parpadeantes al acceder al menú Inicio en The Legend of zelda. Estas fallos se manifiestan en parte debido a las dificultades que enfrentaron los desarrolladores en los años 80 y 90 con las herramientas de desarrollo limitadas de ese momento. La temporización debe ajustarse cuidadosamente para evitar inducir un comportamiento errático en la PPU al realizar cambios en su background medio de estado interno. Pero a veces son extremadamente difíciles de eliminar incluso con herramientas modernas como el depurador de Mesen. Implementamos un truco del mapeador para ayudar a resolver estas dificultades de tiempo y otro para ayudar a reducir fallos similares que resultan de las interrupciones de hardware que se activan en medio de una línea de exploración.


11. Contador de línea de exploración .

Actualmente, tenemos implementado un contador de línea de exploración que es totalmente compatible con todos los modos del mapeador. Esto facilita muchos trucos de trama como el desplazamiento de paralaje falso que sería difícil o imposible sin él. También podemos implementar un contador de ciclos de CPU de uso general similar al del mapeador de memoria FME-7 de Sunsoft para crear trucos de trama aún más avanzados. Es difícil mostrar gráficamente la ventaja de nuestro enfoque para el conteo de líneas de exploración, pero equivale a poder hacer más sacrificando menos tiempo de CPU y lograrlo con menos tiempo de programador y dolor de cabeza. Estos ahorros se pueden gastar en hacer un mejor juego. Como se mencionó en el artículo anterior, la verdadera cantidad de colores en la paleta maestra de NES es en realidad 425, no 54. Pero acceder a esos 371 colores adicionales es difícil de hacer porque la forma ingenua de hacerlo es teñir toda la pantalla a la vez para obtener 54 colores diferentes para una background completo en lugar de mezclarlos y combinarlos en el espacio de color más grande. La forma menos ingenua es usar un contador de línea de exploración y cambiar los "bits de énfasis" en el background medio para obtener algunos de esos colores adicionales. Definitivamente haremos esto para efectos especiales específicos enEx Amanecer . Cabe señalar que 425 colores coloca a la NES cerca de TurboGrafx-16 y Genesis en términos de tamaño del espacio de color, pero en esos sistemas los colores son mucho más (pero no totalmente) utilizables libremente. Todo se reduce a que la NES tiene mucho más poder gráfico disponible de lo que la gente cree, pero desbloquear ese poder requiere un enorme esfuerzo de ingeniería de software o una pequeña cantidad de esfuerzo de ingeniería de hardware. Estamos optando por emplear ambos. Cuánto tiempo tendremos que invertir en explorar completamente las posibilidades dependerá de factores que se desconocen en este momento.

12. Expansión del tamaño de la muestra de DPCM. (4081 bytes -> 16MiB)

La parte APU de la CPU 2A03 de NES está cableada para tener una longitud de muestra DPCM máxima de 4081 bytes, que a la velocidad de reproducción máxima de 33,144 Hz equivale a 1 segundo de audio muestreado. Este es uno de los aspectos más restrictivos del diseño de NES y una verdadera tragedia. La tragedia no se sintió mucho en la era original de NES porque los tamaños de ROM estaban tan limitados que no se podía justificar mucho audio muestreado. Afortunadamente, el rango de direcciones de memoria permitido por la APU para las muestras de DPCM hace posible que un mapeador de memoria ofrezca asistencia para expandir los tamaños de muestra permitidos. Hemos hecho esto, todo el camino hasta 16MiB. Esta expansión facilitará efectos de sonido más largos, una banda sonora más rica en DPCM y pistas de audio para acompañar a FMV sin saltos ni cambios de banco complicados a mitad de cuadro. También nos permitirá implementar múltiples “canales DPCM virtuales”,y haciendo posible reproducir efectos de sonido DPCM en el juego al mismo tiempo que la banda sonora sin que ninguno corte al otro. También permitirá reproducir múltiples efectos de sonido DPCM simultáneamente. Hasta donde sabemos, nunca antes se había hecho algo así en un juego de NES.

13. Chip de síntesis de audio [emulación] .

Este es uno grande que realmente exige su propia publicación en el blog, que llegará en algún momento. Pero, en resumen, hemos optado por tener audio de expansión en el cartucho que será posible en la NES de carga frontal a través del puerto de expansión ofrecido por INL. (También debería funcionar de forma nativa en la Famicom, por supuesto). El módulo de puerto de expansión más avanzado de Perkka también debería habilitar nuestro audio de expansión. El chip de sintetizador elegido para esta expansión de audio está programado para ser el Yamaha YM2610, que era el chip de sonido del Neo·Geo. Ya tenemos funcionando la emulación basada en FPGA del YM2610, pero no hemos escrito la interfaz que evitará que el núcleo de la CPU 6502 tenga que alimentarlo. Esto se logró en el Neo·Geo a través de una CPU Z80 integrada dedicada, que nos gustaría evitar en la medida de lo posible. Se han propuesto varias soluciones y estamos analizando sus implicaciones antes de tomar una decisión. En cualquier caso, es un requisito difícil que la parte nativa 2A03 de la banda sonora suene fantástico por sí sola y combinada con la parte YM2610. Así, cualquier persona con cualquier tipo de NES o Famicom, modificada o no, podrá disfrutar de la banda sonora deex amanecer !

14. ROM y RAM de doble puerto.

Uno de los mayores problemas cuando se trata de cualquier hardware de video clásico (no solo NES) es administrar el tiempo de lectura y escritura para que la CPU y la PPU (generalmente, GPU) no accedan a la VRAM simultáneamente. En el caso específico de la NES, las partes más útiles del estado interno de la PPU no se pueden escribir en absoluto mientras el renderizado está activado. Por lo tanto, la solución segura siempre ha sido que la CPU espere hasta vblank o hblank para realizar escrituras en el estado interno de la PPU. Dado que hblank es tan corto, casi nada se puede hacer allí y lo que se puede hacer es extremadamente difícil de cronometrar correctamente. Vblank es comparativamente más largo, pero sigue siendo bastante corto. El NES se envió con 2KiB de RAM de nombre/atributo soldada a la placa base, lo que lo sometió a estos problemas. Pero también fue diseñado para que en su lugar se pudiera usar una VRAM externa, mapeada dentro de CHR-ROM o CHR-RAM. Por lo tanto, no hay nada que impida que dicha ROM o RAM sea "doble puerto"; Es decir, la CPU y la PPU pueden acceder al mismo tiempo. Todo lo que requiere es una ROM o RAM especial y/o compatibilidad con el mapeador. Debido a que INL ya estaba desarrollando un cartucho NES de doble puerto en general, decidimos diseñar este sistema conjuntamente con INL para que podamos basar gran parte deex amanecerprogramación bajo el supuesto de doble puerta. Estrictamente hablando, esto no es parte de MXM-0 o MXM-1, pero vale la pena mencionarlo porque requiere soporte de hardware de manera masiva. Básicamente, la distinción entre PRG y CHR se erosiona con dicho sistema. Una vez más, apenas hay un precedente histórico para esto: MMC5 contiene 1 KiB de "ExRAM" que tiene doble puerto. Lo llevamos mucho más lejos y dependimos completamente de él para ciertas características del juego en lugar de tratarlo como un truco como lo fue en MMC5. Podemos hacer cosas como transferir una tabla de nombres basada en RAM al espacio de direcciones de la PPU (es decir, a CHR) y al mismo tiempo transferirla al espacio de direcciones de la CPU. Así configurada, la CPU puede modificar la tabla de nombres durante el renderizado, lo que hace posibles muchas más funciones, como entornos robustos destructibles, efectos de partículas, otros efectos especiales como faux mode-7 de SNES, y más. Hasta dónde lleguemos no se sabrá hasta más adelante en el proyecto, porque tales cosas casi no tienen precedentes en la NES.

Explicar lo que no está permitido en nuestro mapeador es casi tan importante como lo que está permitido , ya que diseñar algo como esto en la década de 2020 lo pone a uno en peligro constante de pasarse de la raya. ¡Aquí están las explicaciones!

= Explicación (Rechazado) =

1. Descarga de cálculos de propósito general.



Si vas a hacer un juego para NES, debes preguntarte exactamente qué significa que esté "en NES". ¿Qué es cualquier videojuego en esencia? Es un programa de computadora que se ejecuta en tiempo real, toma la entrada del usuario y usa la lógica para combinar la entrada del usuario con gráficos para enviar una salida de video. Por lo tanto, parece sencillo permanecer firme en el punto de que la parte lógica del juego de todo esto tiene lugar en la NES; Es decir, en la CPU de la NES, la 2A03. Si está utilizando algún tipo de procesador de uso general moderno (por ejemplo, una CPU ARM) en el cartucho que ejecuta la lógica, está haciendo "trampa" por completo en el sentido de que no es realmenteun juego de NES. ¿Por qué? Debido a que es similar a atar un motor a reacción a un biplano de la década de 1910, lo convierte en algo categóricamente diferente e imposible de lograr en el contexto original del dispositivo. Por lo tanto, no importa cuán interesante o desafiante sea hacer las modificaciones necesarias para Doom-on-the-NES, en última instancia, no es interesante como una adición a la biblioteca de juegos de NES, ya que casi cualquier juego podría agregarse a la biblioteca de juegos de NES de esa manera. . En otras palabras, una definición que incluye todo es tan inútil como una definición que no incluye nada. Si, por el contrario, está utilizando un procesador de propósito específico y con precisión de período (por ejemplo, una FPU temprana) para ayudaren los cálculos, es menos obvio que es "hacer trampa". Pero creemos que es mejor evitar el problema por completo y simplemente evitar cualquier asistencia o reemplazo del núcleo 6502 del 2A03 para propósitos de lógica de juego o cálculos relacionados. En este sentido, nuestro diseño es más puro que el de MMC5, ya que MMC5 contiene una función de multiplicador de enteros de propósito general accesible desde un programa de juego y, por lo tanto, se acerca al cumplimiento de la responsabilidad de una CPU. ¡ Aún peor que eso, el 6502 ni siquiera tiene una función de multiplicación! Entonces, MMC5 es capaz de mejorar la CPU de NES de una manera que no solo agrega un poco más de lo que ya puede hacer, sino que empuja al sistema combinado hacia algo más avanzado como el Motorola 6809 o el Intel 8086.

2. Descarga de procesamiento gráfico.



Del mismo modo, una gran parte de lo que hace que un juego de NES sea un juego de NES es el hecho de que la PPU está renderizando el video. Los pequeños ajustes o mejoras parecen estar bien, especialmente porque están respaldados por varios mapeadores de memoria clásicos. Pero poner algo "grande" como el chip SA-1 o Super FX en un cartucho NES lo convertiría en un sistema fundamentalmente diferente. Obviamente, al consumidor típico no le importa en absoluto si hay o no un chip de mejora de gráficos en el cartucho. La biblioteca de juegos de SNES/Super Famicom contenía muchos títulos populares que hacían exactamente eso, incluidos algunos de los más elogiados, como Star Fox , Yoshi's Island y Super Mario RPG .. Sorprendentemente, de hecho, el chip Super FX comenzó su vida en la NES y cambiaron su sistema de destino a la SNES a la mitad del desarrollo. Así que este fenómeno nunca llegó a ningún juego en la biblioteca de juegos de NES original, y no queremos ser nosotros quienes lo presentemos. Queremos seguir siendo defendibles, y este es otro tipo de mejora que es difícil de defender. (También va en contra de nuestros gustos personales).


3. Transmisión de audio PCM a través de audio de expansión.

El análogo más cercano a la transmisión de audio PCM a la mezcla a través de la línea de audio de expansión habría sido el "audio Red Book": audio de CD. Pero eso no es posible mientras se accede a una pista de datos que no son de audio en un juego de CD-ROM. Es posible que observe en un juego de CD-ROM clásico para PC que el audio tiene una calidad reducida y/o es corto, o el video lo es. ¡Esto no es un accidente! Dado que no tenemos un búfer lo suficientemente grande como para contener audio de calidad PCM completa durante un período de tiempo trivial, usar la transmisión PCM a través de audio de expansión durante el juego es extremadamente sospechoso. Hacerlo durante FMV es otra cosa, y ya lo hemos logrado como nuestro Bad Apple FMVdemuestra Además, nuestro compositor quiere que el juego tenga un sonido auténtico de principios de los 90 de todos modos, y la mejor manera de garantizarlo es usar un chip de sintetizador de audio genuino o al menos emular uno en el FPGA. Permanecer estrictamente en el punto correcto es mucho más fácil de lograr de esa manera y ayuda a evitar la tentación.


4. Exceder el poder computacional o la complejidad del propio NES.

Esto está casi garantizado por 1. y 2., pero vale la pena mencionarlo de todos modos. Estrictamente hablando, es un requisito más débil, pero captura algunos casos extremos que podrían pasar desapercibidos sin mantenerse firme en esto.


5. Exceder la complejidad del circuito de MMC5.

Ya sea justo o no, el MMC5 es un chip de mejora algo controvertido en la comunidad moderna de desarrollo de NES. Habría sido extremadamente difícil (si no imposible) fabricar económicamente en 1983 cuando se lanzó por primera vez la Famicom, por lo que representa una clara mejora en la tecnología que se introdujo tarde en la vida de la NES/Famicom. También es el chip de mejora más avanzado que jamás se haya convertido en un juego comercial de NES o Famicom. Por lo tanto, lo consideramos una buena guía de cuán complejo puede ser un circuito MXM-0. Debido a que MXM-1 también contiene lógica de acceso a la tarjeta SD, excluimos esa parte de la comparación. Si MXM-1 se hubiera lanzado en la forma de complemento de CD-ROM correcta de su período, la parte que habría manejado la unidad de CD-ROM probablemente habría estado en un ASIC separado o en un conjunto de ASIC. Esto ayuda a que la comparación con MMC5 sea más limpia. MXM-1 también contendrá una interfaz para (pero no la implementación de) el YM2610 o una forma simulada de FPGA del YM2610. La complejidad del circuito del YM2610 en forma simulada de ASIC o FPGA también se excluye de una comparación con MMC5. Por lo tanto, para ser justos, excluimos la porción de audio de expansión de MMC5 en tales comparaciones. Hasta el momento, con todas estas advertencias en su lugar, MXM-1 (y por lo tanto MXM-0) esligeramente menos complejo que MMC5. (Esto se debe en gran parte al hecho de que hemos rechazado la inclusión de muchas características de MMC5 que consideramos ingeniosas, ineficientes o innecesarias para el diseño de nuestro juego; los ejemplos incluyen desplazamiento de pantalla dividida vertical, relleno de tiles y modos de banca variable). se reserva el derecho de terminar en un lugar donde MXM-0/MXM-1 es un poco más complejo que MMC5, pero se esforzará por ser razonable y mantenerlo bajo control mientras finalizamos el diseño.


6. Re-implementar el PPU por cualquier motivo.

Esto es casi una recapitulación de 2., pero también me pareció que valía la pena señalarlo. Sería una estupidez hacer esto, incluso si pudiéramos hacerlo y aun así escabullirnos de los demás requisitos.


7. Factor de forma física más grande que un Game Pak tradicional.

Esto es, para tomar prestado un término, para evitar “la imagen de incorrección”. No debería ser un problema para nosotros de todos modos, ¡porque realmente no estamos haciendo nada tan loco! También se violaría en espíritu si MXM-1 realmente se manifestara como un módulo de puerto de expansión que encaja debajo de la NES. En cualquier caso, creemos que es mejor errar por el lado de la precaución en este frente como lo es en varios otros. También sabemos que nuestros clientes esperan un cartucho que parezca un Game Pak estándar, al menos por fuera. Y eso es lo que vamos a entregar.

8. Exceder la velocidad de carga de una unidad de CD-ROM 4X. (600 KiB/s)



El fundamento para modelar nuestras transferencias de datos en una unidad de velocidad cuádruple es que dichas unidades estaban disponibles en el mercado minorista de repuestos de computadoras antes del lanzamiento de Wario's Woods a fines de 1994. Es lógico pensar que tal unidad podría haberse utilizado en una consola de CD-ROM a finales de 1994 también. Sin embargo, solo hay una consola de videojuegos basada en CD-ROM conocida que cuenta con una unidad 4X, que es Apple Bandai Pippin. No solo eso, sino que el Pippin se lanzó a principios de 1996, lo que sin duda causa una debilidad en nuestra justificación. La mayoría de las consolas exitosas basadas en CD-ROM en los años 90 usaban una combinación de unidades 2X y compresión de video, probablemente para mantener bajos los costos de los componentes de la unidad. (La única excepción es la Dreamcast, que lucía una unidad de velocidad 12X, pero no salió hasta 1998. ) Por lo tanto, actualmente estamos experimentando con algoritmos de compresión sin pérdidas que podrían haberse implementado razonablemente en un complemento de CD-ROM 2X relativamente económico para NES en 1994 o antes. Uno de ellos es LZW. Debido a que LZW fue patentado desde 1983 hasta 2003,específicamente , probablemente no se habría utilizado en un sistema "NES CD" en 1994 debido a los costos de licencia. Sin embargo, somos libres de usarlo para Former Dawn ya que estamos creando este juego mucho después de 2003. Además, el algoritmo LZ77 relacionado pero más simple está actualmente bajo consideración porque parece tener suficiente poder de compresión para nosotros y es más simple de implementar en Verilog. . La relación de compresión proporcionada por LZ77 podría incluso ser lo suficientemente amplia como para modelar las transferencias de datos de Former Dawn en una unidad de CD-ROM 1X, lo que lo pondría en competencia directa con el TurboGrafx-CD.

Hay muchos otros aspectos (algo novedosos) en el diseño de Former Dawn además de los que hemos facilitado directamente en el mapeador/chip de expansión. Pero este artículo realmente trata de desbloquear el potencial de la NES, que creemos que es responsabilidad de dicho chip. Por lo tanto, los trucos basados ​​en software que hemos inventado o que estamos tomando prestados de otros desarrolladores se tratarán en publicaciones futuras.


= Preguntas Frecuentes =

P: ¿Esto no es hacer trampas?

R: Wow, recibimos esta pregunta mucho. ¡La respuesta es un rotundo no, en el sentido de que no estamos "haciendo más trampa" que The Legend of Zelda o Punch-Out! en su día. Usaron RAM en el cartucho (no solo para guardar); usamos RAM en el cartucho. Hicieron un cambio de banco automático a medio frame; como nosotros. La lista continúa pero las dos cosas más importantes a tener en cuenta son que todo lo que estamos haciendo en el mapeador per se, fue posible de lograr económicamente en 1989, y que la mayoría de los juegos clásicos de NES que conoces y amas usaban esencialmente los mismos trucos, aunque en formas menos refinadas y con menos efecto general debido a los tamaños de ROM limitados. La respuesta completa a esta pregunta merece su propio artículo, y probablemente escribiré uno en algún momento porque esta pregunta se plantea más que cualquier otra, y también es la más controvertida.

P: ¿Todo esto era realmente posible cuando la NES era un sistema de generación actual?

R: Sí.

P: ¿Era todo esto económicamente factible cuando la NES era un sistema de generación actual? Seguramente hubiera sido demasiado costoso diseñarlo y entregarlo al mercado a un precio que la gente hubiera pagado.

R: En realidad, creemos que todo lo que hemos hecho se podría haber hecho a un precio lo suficientemente bajo como para ser económicamente factible, si no convincente, ciertamente en 1994, pero podría decirse que incluso más atrás en el tiempo. La gente debe tener en cuenta que el TurboGrafx-16 disfrutó de su expansión en CD-ROM en Japón en 1988 y fue un éxito comercial allí. ¿Por qué la NES debería haber sido diferente? Sí, habría sido más difícil programar los juegos de CD-ROM para NES, pero lejos de ser imposible, como estamos demostrando continuamente a medida que avanza este proyecto. La desafortunada realidad es que Nintendo Co. Ltd. ha tenido una tendencia durante mucho tiempo a favorecer la opción menos costosa en cualquier momento de la historia. Después de la quema causada por la ruptura con Sony y el lanzamiento comercial de PlayStation independientemente de cualquier asociación con Nintendo, Nintendo optó por la ingeniería de solo cartuchos para la Nintendo 64, lo que resultó ser muy perjudicial desde el punto de vista financiero. Incluso cuando lanzaron una expansión de medios giratorios para el N64 (llamada 64DD), optaron por hacerlo (una vez más) con discos de tamaño de datos anémicos según los estándares de la época. Solo 64 MiB en un disco, mientras que sus competidores sacaban discos con 10 veces esa cantidad de datos. En otras palabras, Nintendo se encontró en la posición inversa a mediados o finales de los 90, cuando la competencia era con Sega y Sony, y a principios o mediados de los 80, cuando la competencia era con Atari y Coleco. Otro punto es que Nintendo optó por hacer expansión de memoriamucho más costoso en conjunto al incluir los mapeadores de memoria en cada cartucho de NES en lugar de en un módulo de expansión común que todos los juegos nuevos podrían usar. Si alguien poseía 20 juegos de NES, pagaba por sus chips mapeadores de memoria 20 veces por separado, con los costos enterrados en los precios de los juegos individuales. Nuestro sistema propuesto habría sido un gasto único, ya que los juegos en sí serían más baratos. Este es el mismo modelo comercial que el FDS, excepto que tiene una cantidad mucho mayor de almacenamiento. Esa mayor cantidad de almacenamiento habría evitado que la expansión se volviera obsoleta, como sucedió con el FDS dentro de uno o dos años del lanzamiento, ya que los precios de fabricación de los cartuchos seguían cayendo.

P: Si esto era posible en ese entonces, ¿por qué Nintendo o alguna otra compañía no lo hizo?

R: La respuesta obvia es que ya tenían la Super Famicom/SNES lista para investigación y desarrollo en el momento en que esto era económicamente viable (1988-1989). Nintendo probablemente pensó que si iban a sumergirse en el mercado de CD-ROM, también podrían actualizar la consola subyacente al mismo tiempo. Lo que estamos explorando es una línea de tiempo alternativa en la que mantuvieron el sistema base igual y "simplemente" lo expandieron de la forma en que lo hicieron NEC y Sega. De manera similar, es similar a lo que sucedió con las PC basadas en MS-DOS a principios de los 90: la arquitectura del sistema se dejó completamente intacta o al menos compatible con versiones anteriores, pero se agregaron unidades de CD-ROM. Estos a menudo se incluían con tarjetas de sonido que se conectaban directamente con ellos y permitían una experiencia más enriquecida que la que proporcionaban los datos adicionales por sí solos. En última instancia, sin embargo, la justificación para hacer esto se basa en la tecnología y la economía, no en la perspicacia empresarial. Está muy lejos de la verdad que cada decisión que tomó Nintendo fue la correcta. Se diseñaron y lanzaron al mercado muchos productos ingeniosos que eran mucho menos valiosos de lo que estamos tratando de lograr. Ofrezco a su consideración esta breve lista de ejemplos: Virtual Boy, Famicom Disk System, Sufami Turbo, Datach, ROB, 64DD y Power Glove... Insistir en lanzar solo hardware barato no garantiza que ese hardware sea una buena propuesta de valor. Lo que llega al mercado y lo que no es tanto una función del capricho ejecutivo como un mérito intrínseco.

P: ¿Sin embargo, esto no es solo hacer trampa?

R: No.

P: ¿Por qué no hacéis Former Dawn para SNES o PC para el caso?

R: Hay muchas razones para esto, pero la principal es que sentimos un poco de amor y respeto por la NES y su papel en la historia de los videojuegos. Lo vemos como un sistema que nunca vio su verdadero potencial. Francamente, es una pena que nadie antes que nosotros haya optado por hacer la cantidad relativamente pequeña de ingeniería de hardware para "bailar" con la CPU y la PPU de la manera correcta.

P: ¿Usar un FPGA en el cartucho no invalida sus afirmaciones sobre la corrección del período? Los FPGA ni siquiera se habían inventado cuando la NES se retiró de los estantes de las tiendas. Los FPGA también son increíblemente poderosos.

R: Bueno, esto es cierto en un sentido muy trivial: la implementación particular que elegimos emplear no era posible en 1994. Por otra parte, tampoco lo eran los chips grandes NOR flash que todo el mundo usa para los lanzamientos caseros modernos de NES. Otras personas/empresas usan NOR flash para sus cartuchos NES modernos por la misma razón por la que estamos usando un FPGA para nuestro mapeador de memoria: economía moderna. Las ROM de máscara son prohibitivamente caras en este contexto moderno, al igual que los ASIC en los niveles de producción en los que es probable que estemos cuando se lance Former Dawn . Nada técnico nos impediría enviar los planes para MXM-0 o MXM-1 a un fabricante en China y eliminar los ASIC que cumplirían exactamentelo mismo en nuestros cartuchos que hace un FPGA. Pero los FPGA nos permiten hacerlo de manera más económica y desarrollar la tecnología más rápidamente. Es nuestro nivel de disciplina guiado por nuestra filosofía lo que nos impide hacer algo con un FPGA que hubiera sido imposible durante la vida comercial original de NES. Una vez que publiquemos Former Dawn y posteriormente MXM-0 (y probablemente MXM-1) al público bajo una licencia de código abierto, cualquiera podrá verificar esto.

P: ¿Los atributos 8×1, el espacio ROM masivo y otras características de MXM-0/MXM-1 no violan la “estética de 8 bits”? ¿Cuál es el punto de hacer un juego de NES si vas a intentar que parezca un juego de SNES o algo aún más avanzado?

R: Correcto; Entonces, ¿Battletoads no debería haberse creado para NES porque tenía un aspecto más avanzado que Super Mario Bros.? ¿No debería haberse creado Solstice porque era más avanzado que Solomon's Key? ¿Qué tal Kirby's Adventure o Batman Return of the Joker? La verdad es que en cadaconsola de videojuegos, los juegos posteriores se ven y se juegan mejor que los anteriores; no es sólo la NES. Además, por muy halagador que sea para la gente comparar lo que hemos logrado con la era de los 16 bits, sabemos que fallaremos si ese es el estándar al que nos obligan. Simplemente estamos explorando lo que significa maximizar la tecnología de videojuegos de 8 bits, no convertir la tecnología de 8 bits en 16 bits.

P: ¿FMV en NES? Vamos.

R: Por favor, dime con seriedad que los niños que jugaron el juego Jurassic Park NES en 1993 no se habrían vuelto locos si hubieran visto una escena FMV de un T-Rex persiguiendo el Jeep en la jungla. Rechazar FMV como parte candidata de la estética de NES nace de una mentalidad cerrada. Es un fracaso de la imaginación y el recuerdo de cómo era realmente esa época. FMV es tan común ahora que casi se espera en un lanzamiento de juego AAA, o al menos se espera que se simule con renderizado en tiempo real. Pero debido a que solía ser tan novedoso y difícil de lograr tecnológicamente, casi todo el mundoestaba entusiasmado con FMV en los años 80 y 90. Tanto es así que, lamentablemente, se convirtió en un truco para muchas empresas de desarrollo de juegos y los juegos FMV de mala calidad se convirtieron, durante un tiempo, en una especie de shovelware. Lo que pretendemos hacer con FMV es comparativamente de buen gusto e impulsado por el deseo de mejorar el medio de narración de historias de NES, no reemplazar el buen juego con envoltorios delgados alrededor de FMV. Piensa en Otro Mundo , no en MegaRace .

P: ¡Hacéis trampa!

R: No. Además, eso no es una pregunta.

-Jared