Curiosidades de la NES/Famicom [Cuidado 56k y Tarifas Datos]

Responder
1…7, 8, 9, 10, 11
Señor Ventura escribió:@Diskover un mapper que permita 30 bloques de 256 tiles cada 8 scanlines (uno para establecer la longitud del escenario, junto con los otros 29 bloques para establecer una actualización de estado de las tiles para una animación), empleando una ch-ram para postprocesarlos para un efecto de escalado (zoom in, zoom out), y ser usada como ch-rom...

Todo a 60fps, animación de escenario a 2 tics (aunque si quisieras, también a 60fps).


¿Si?.


Claro. De hecho, MMC5 podía hacerlo, o el nuevo MXM-1 ya lo hace. Aunque lo del zoom creo que sería más complejo, pero creo que se conseguiría solventar.

Como siempre, el problema sería el tamaño de la memoria y los costes, si quieres luego lanzar el videojuego en un mercado real en pleno 1990 - 1994

Diskover escribió:Como he puesto antes, son 128 tiles reservados para el efecto, y utiliza en total 27 bancos de 256 tiles


27 bancos...

¿Ese zoom está funcionando a 30fps?.[/quote]

Por lo menos. Probándolo en la NES diría que da los 60fps perfectamente.

Te puedo decir que el contador IRQ no deja de funcionar en todo momento, y que el cambio de banco se realiza cada 2 fps... pero insisto, el IRQ continuando con su aplicación, por lo que da la sensación de 60fps finales.
Diskover escribió:Claro. De hecho, MMC5 podía hacerlo, o el nuevo MXM-1 ya lo hace. Aunque lo del zoom creo que sería más complejo, pero creo que se conseguiría solventar.


Básicamente porque en ch-ram sigues teniendo tus 32 tiles, pero cuanto mas lejano sea el zoom, mas tiles de la ch-rom van a conformarlos. Por lo tanto, si reservas 128 tiles para cada columna, y el escenario es demasiado grande, vas a tener que prever una cierta repetición de tiles para no quedarte sin información gráfica al alejar el plano.

1 -Postprocesar todos los tiles implicados en la ch-ram.

2 -En zoom out la información de mas de un tile debe conformar la información del tile resultante. Esta conversión requiere de mucha potencia de cálculo, pero el propio mapper podría servirla estando hecho para esto.

3 -Si el escenario ocupa 128 tiles de ancho, reservas 128 tiles por bloque cada 8 scanlines, y contemplas un zoom out de 3 tiles en el espacio de 1, necesitas que el patrón del dibujo esté conformado por unos 42 tiles en bucle, o por mas tiles para una mayor complejidad del dibujo, pero con espacios, tiles repetidos, etc

4 -Los personajes deben tener un tamaño máximo de 32 píxeles de ancho, y aconsejablemente de no mas de 100 píxeles de alto.

5 -50 colores para planos, y mas de 6 para sprites.

6 -Ese canal pcm echando fuego.
De parte del señor @doblete, que lo publicó en el hilo de Novedades de la scene retro.

Demo de la intro de Another World para la NES:



Descarga en la descripción del video.
La cosa es como se ha hecho, porque vídeo, vídeo... no se yo.
Señor Ventura escribió:La cosa es como se ha hecho, porque vídeo, vídeo... no se yo.

Cambio de CHR al vuelo en escenas con movimiento. Se ve perfectamente con el emulador Mesen.

No lo he mirado, pero me imagino que han usado MMC3.

Edito: está usando el MMC5 [beer]
@Diskover puede que decepcione, pero es que es mucha resolución como para pretender algo en tiempo real.

La cosa es que ya que se usa un mapper, que este pueda realizar esas tareas junto a su propia ram (como el élite), para no meter una rom de 64 megabits... que aunque hoy en día no supone ningún problema, no sabe igual 8 megabits en tiempo real que 64 megabits de actualización de tiles, aunque en la práctica no notes nada.

O, ¿que tal precalcular todo?, ¿hay cpu para gestionarlo?, ¿hasta dónde se va el uso de una rom?.


Empiezo a querer verlo en una nes.
Sabía que había habido versiones coreanas de la Famicom. La que no había visto nunca es la India.
La Samurai puede parecer una consola bootleg pero inicialmente sí que tenía licencia/permiso de Nintendo. https://bootleggames.fandom.com/wiki/Sa ... ic_TV_Game

Imagen
Esto es una nes. Con sus 64 sprites en pantalla, y sus 8 sprites por línea.

https://x.com/morphcat/status/193866141 ... BkRPg&s=19


Te quedas...
Seideraco está baneado por "clon o troll multinick que no va a cambiar"
Señor Ventura escribió:Esto es una nes. Con sus 64 sprites en pantalla, y sus 8 sprites por línea.

https://x.com/morphcat/status/193866141 ... BkRPg&s=19


Te quedas...


Madre mía que espectáculo y que control tiene el programador del hardware de la consola.

Haces ese efecto en Snes o Megadrive y te quedas loco igual xD
Se vienen cositas:

Diskover escribió:Se vienen cositas:



No he entendido nada, nuevo mapper?
SuperPadLand escribió:
Diskover escribió:Se vienen cositas:



No he entendido nada, nuevo mapper?

Eso parece, con capacidad para mover polígonos básicos al estilo Super FX
Pero en esa placa hay una micro pi, no sera quien esta haciendo los calculos??
Esto tiene 16 años...

https://www.youtube.com/watch?v=Fgnd3Ws ... x4&index=5
Scroll Paralax con dos planos de profundidad

Un usuario del canal NESdev de Discord, @CardboardBox, está desarrollando un interesante concepto de parallax "real" para nuestra NES.

Por supuesto, tiene truco, pero no deja de ser meritorio. Otra curiosidad más para nuestra 8 bits favorita:

Imagen


Imagen

Imagen
La última demo técnica para NES, sin ningún tipo de mapper.

Diskover escribió:La última demo técnica para NES, sin ningún tipo de mapper.


Estoy impresionado. Que ni ve lón!
Sobre el tema de aplicar un "chip Super FX" a la Famicom/NES... bueno, hubiese sido algo así.

Utilizando un Rasperry Pi Pico que previamente procese los polígonos y luego se lo escupa mascadito y ordenado a los CHR 256 tiles en BG (seguramente sean más tiles, dado que VRAM de NES puede procesar aún más tiles que esos si les mapeas, tal como hace el MMC5 o el MXM-1), para que lo represente con las restricciones de la Famicom/NES.



Interesante para pantallas estáticas, ojo, y poco más futuro le vería. Algún boss que no se mueva de pantalla y que haga alarde de movimientos tridimensionales, o algún escenario que simule algo.

Las estrellas son sprites, pertenecientes al otro CHR 256 tiles en SP, que aun queda espacio para poner enemigos, colisiones, etc...
@Diskover porque dices que no podría hacer mucho más? El Doom de NES es jugable y viene a ser algo similar a esto no? Un SFX en la época podría ser eso.

Edit: Y sabes si puedo comprar la ROM de Form Dawn ahora para apoyar al proyecto o ya desde el kickstarter no recogen más? Es que compré el de krikzz asíque ahora sí puedo comprarme juegos dopados [poraki]
Pero ya hubo algo así durante su etapa comercial.

https://www.youtube.com/shorts/0N4v_qtvwOQ
SuperPadLand escribió:@Diskover porque dices que no podría hacer mucho más? El Doom de NES es jugable y viene a ser algo similar a esto no? Un SFX en la época podría ser eso.


Creo recordar que, hace años, cuando se presentó con un Rasperry Pi el Doom de NES, este era muy tramposo porque prácticamente ejecutaba todo el Rasperry Pi y luego usaba la NES como paso de video para mostrar la imagen y poco más. A lo mucho, usaba los controles de la NES para manejarnos por el entorno y ya.

¿Notas la diferencia?



En cambio, este Rasperry Pi Pico para Famicom/NES lo que hace es atenerse a las limitaciones de la NES, procesando todo el entorno gráfico 3D, cortándolo en cachitos en forma de tiles de 8x8 destinados al background, y enviándoselo a la VRAM para que la PPU lo muestre en pantalla.

Quizá estoy metiendo la pata afirmando que no se podría usar para mucho más, pero es cierto que saltándote la restricción de 256 tiles por background como hacen muchos mapeadores, perfectamente podrías mostrar a pantalla completa eso y mucho más, simulando un Star Fox o un Virtua Racing.

Nos sobrarían 256 tiles de sprites para todo lo demás.

SuperPadLand escribió:Y sabes si puedo comprar la ROM de Form Dawn ahora para apoyar al proyecto o ya desde el kickstarter no recogen más? Es que compré el de krikzz asíque ahora sí puedo comprarme juegos dopados [poraki]


Que yo sepa, no.

Señor Ventura escribió:Pero ya hubo algo así durante su etapa comercial.

https://www.youtube.com/shorts/0N4v_qtvwOQ


Imagen


Sí, el concepto es el mismo, pero con diferencias:

- Elite usa la CPU para procesar los vectores, luego los corta en cachitos de tiles de 8x8 y se lo pasa a la VRAM de la PPU para que lo muestre en pantalla. Esto ya deja a la CPU sin muchos diclos.
- Elite se salta la restricción de los 256 tiles de background y utiliza direcciones de memoria de los 256 tiles de sprites para mostrar parte del background ("se roba" 128 tiles en principio solo para los vectores, pero veo que aún usa muchos más para otros detalles, dejando pocos tiles para dibujar las estrellas y ya).
- Debido al uso intenso de la CPU, Elite a lo mucho tira a 12 o 15 frames por segundo. No le da para mucho más.
- Elite solo funciona en PAL debido a que el tiempo de procesamiento que tiene la CPU es mucho más largo que en NTSC cuando llega al VBLANK.

Con este Rasperry Pi Pico, liberas a la CPU de hacer todo ese trabajo, puedes hacer graficos 3D más detallados y no limitarte solo a vectores, ganas más frames, y puede reproducirse tanto en PAL como en NTSC.

Es como un "Super FX" pero para NES.
@Diskover pero el SFX en SNES no hace algo similar a Doom NES? Genera todo el chip que lo vuelva a su propio framebuffer y de ahí lo pasa ya generado a la VRAM de la máquina. O lo que es lo mismo, se podría haber metido un SFX a NES en los 90 y tener un Starfox/Doom en NES como los de SNES, pero adaptados a las limitaciones de la PPU de NES?
SuperPadLand escribió:@Diskover pero el SFX en SNES no hace algo similar a Doom NES? Genera todo el chip que lo vuelva a su propio framebuffer y de ahí lo pasa ya generado a la VRAM de la máquina. O lo que es lo mismo, se podría haber metido un SFX a NES en los 90 y tener un Starfox/Doom en NES como los de SNES, pero adaptados a las limitaciones de la PPU de NES?


Lo que tu estas diciendo es exactamente lo que hace este nuevo Rasperry Pi Pico, pero no funciona así el Doom de NES.

El Doom de NES ni siquiera pasa por la VRAM de la PPU. Ni siquiera usa la CPU más que para procesar los controles del mando.

Procesa todo en el Rasperry Pi (programa y gráficos) y lo lanza directamente a la salida del video, aunque en el video dice que funciona de forma similar al Super FX de SNES, eso no es cierto.

Al menos así tengo entendido que se explicó en su día.
Diskover escribió:
SuperPadLand escribió:@Diskover pero el SFX en SNES no hace algo similar a Doom NES? Genera todo el chip que lo vuelva a su propio framebuffer y de ahí lo pasa ya generado a la VRAM de la máquina. O lo que es lo mismo, se podría haber metido un SFX a NES en los 90 y tener un Starfox/Doom en NES como los de SNES, pero adaptados a las limitaciones de la PPU de NES?


Lo que tu estas diciendo es exactamente lo que hace este nuevo Rasperry Pi Pico, pero no funciona así el Doom de NES.

El Doom de NES ni siquiera pasa por la VRAM de la PPU. Ni siquiera usa la CPU más que para procesar los controles del mando.

Procesa todo en el Rasperry Pi (programa y gráficos) y lo lanza directamente a la salida del video, aunque en el video dice que funciona de forma similar al Super FX de SNES, eso no es cierto.

Al menos así tengo entendido que se explicó en su día.



Ah vale vale, creía que era lo mismo. Pero a efectos de usar un SFX de NES podría usarse para crear juegos 3D para algo más que generar algún boss o elemento 3D del escenario no?
SuperPadLand escribió:Ah vale vale, creía que era lo mismo. Pero a efectos de usar un SFX de NES podría usarse para crear juegos 3D para algo más que generar algún boss o elemento 3D del escenario no?


Si.

Quizá me precipité al asegurar lo contrario primeramente. Pero si tienen acceso a los registros de memoria de cualquier de los tiles del CHR, sean para BG o SPR, da de sobra para dibujar un Star Fox en pantalla.
Diskover escribió:Lo que tu estas diciendo es exactamente lo que hace este nuevo Rasperry Pi Pico, pero no funciona así el Doom de NES.

El Doom de NES ni siquiera pasa por la VRAM de la PPU. Ni siquiera usa la CPU más que para procesar los controles del mando.

Procesa todo en el Rasperry Pi (programa y gráficos) y lo lanza directamente a la salida del video, aunque en el video dice que funciona de forma similar al Super FX de SNES, eso no es cierto.

Al menos así tengo entendido que se explicó en su día.


El caso es que aún así, ninguna otra consola permite un througout de todo el pipeline gráfico, por mucho que tu quieras en lass 16 bits le mandas al line buffer lo que pueda dar el dma, y por ahí si podemos hablar de una característica de la nes usada por ese doom, y no una ausefncia de ellas.

SuperPadLand escribió:Ah vale vale, creía que era lo mismo. Pero a efectos de usar un SFX de NES podría usarse para crear juegos 3D para algo más que generar algún boss o elemento 3D del escenario no?


De hecho, a 60fps, al contrario que cualquier 16 bits.

Y es que si hablamos de juegos mediante procesador de apoyo, ya no hay un "ya, pero es que la nes...", porque van todas a tope a por el mismo objetivo, y ahí la nes asesina.
Señor Ventura escribió:De hecho, a 60fps, al contrario que cualquier 16 bits.

Ojo con esta afirmación.

En su época, seguramente era complicado por un tema de costes, pero hoy en día seguro que te pueden cascar un Super FX3 asequible que generé polígonos a 60fps e incluso texturizados sin problema para SNES y Mega Drive.
Diskover escribió:
Señor Ventura escribió:De hecho, a 60fps, al contrario que cualquier 16 bits.

Ojo con esta afirmación.

En su época, seguramente era complicado por un tema de costes, pero hoy en día seguro que te pueden cascar un Super FX3 asequible que generé polígonos a 60fps e incluso texturizados sin problema para SNES y Mega Drive.


Bueno, ojo... en una ventanita lo que quieras.

Pero ventanita. Sencillamente no les da el ancho de banda.
Señor Ventura escribió:
Diskover escribió:
Señor Ventura escribió:De hecho, a 60fps, al contrario que cualquier 16 bits.

Ojo con esta afirmación.

En su época, seguramente era complicado por un tema de costes, pero hoy en día seguro que te pueden cascar un Super FX3 asequible que generé polígonos a 60fps e incluso texturizados sin problema para SNES y Mega Drive.


Bueno, ojo... en una ventanita lo que quieras.

Pero ventanita. Sencillamente no les da el ancho de banda.

Ahí ya no discuto que no tengo ni idea.
@Diskover no sé si es él ancho de banda o lo que hace cuello de botella que no permite transmitir 60fps a full resolución. Me suena que Vilela andaba mirando de optimizar el Starfox para que fuese a 30fps y decía que el problema era que para eso tenía que bajar demasiado la resolución. Ahora que con un SFX3 podrás subir la calidad gráfica de esos 20 fotogramas y que sean texturizados.
Actualización en primera página para aclarar ciertos detalles sobre el funcionamiento de la memoria CHR, tiles dedicados a background y sprites, así como a sus "no limitaciones", con la NES a pelo.

"Pero ojo, esta configuración de 256 tiles para fondos, y 256 tiles para sprites, no es algo restringido y estricto. Si se quiere, backgrounds y sprites, pueden utilizar igualmente los tiles almacenados en cualquiera de los dos lados. Una vez que se ha cargado los 512 tiles en la VRAM para procesarse en la PPU según necesidad, las llamadas a los tiles de esta memoria pueden ser indistintos.

Si construyes un background, y no te da para formar una imagen con 256 tiles, puedes apuntar a la dirección de los sprites para "robar" espacio."
A mi esto me desconcierta:


La música viene del averno, pero ese no es el caso, hay 2 tipos de bomba, las que explotan, y otras que sueltan una burbuja con conciencia que te persigue, en el contacto invierte los bits del control.

Leo por ahí que las bombas interfieren en la ya de por si mermada melodía, pero he tenido el valor, no solo de probarlo, ya que estoy de pasármelo y solo surte efecto cuando estas siendo invertido, o bien lo de invertir los bits de control se hace a lo loco, y por lo que sea, acaba afectando al audio, o es intencionado, lo cual sería todavía más macabro.

Me ha parecido un martirio esa idea jugable, el control de calidad eran los padres.
@Conker64 suena a Atari 2600 o ordenadores sin altavoces de los 80. [carcajad]
Conker64 escribió:A mi esto me desconcierta:


La música viene del averno, pero ese no es el caso, hay 2 tipos de bomba, las que explotan, y otras que sueltan una burbuja con conciencia que te persigue, en el contacto invierte los bits del control.

Leo por ahí que las bombas interfieren en la ya de por si mermada melodía, pero he tenido el valor, no solo de probarlo, ya que estoy de pasármelo y solo surte efecto cuando estas siendo invertido, o bien lo de invertir los bits de control se hace a lo loco, y por lo que sea, acaba afectando al audio, o es intencionado, lo cual sería todavía más macabro.

Me ha parecido un martirio esa idea jugable, el control de calidad eran los padres.

Desconocía ese "bug" en este juego.

Sí, es desconcertante y está claro que la música se le ha debido de añadir un bit por encima para que suene así.

Ocurría a veces con SMB. 3 y las 1UP, que en según que circunstancias, si hacías muchas acciones con sonido a la vez que cogías un 1UP, la melodía de este se repetía a la inversa.
Antes de dar un nuevo aporte, os comento que en la primera página he puesto un sumario con distintos enlaces que van directamente a las curiosidades más llamativas de NES.

Sin más, sigamos.

Los Kits de Desarrollo de la NES


Introducción

La Famicom fue lanzada en Japón el 15 de julio de 1983 a un precio de 14.800 yenes.

El desarrollo de videojuegos para esta nueva máquina, estaba estrictamente controlado por Nintendo, y no querían que les afectase el "crash de los videojuegos" que se sufría en Estados Unidos, que achacaban a la falta de juegos de calidad. Como tal, la mayoría de los juegos lanzados inicialmente para la plataforma, fueron creados por la propia Nintendo, presumiblemente en un prototipo de hardware de NES.

Dado que Nintendo era muy nueva en el mercado de los videojuegos y se consideraba creadora de la mayor parte del software que se ejecutará en la NES, no crearon un kit de desarrollo específico o, si lo hicieron, estuvo muy bien escondido en la sede oficial de Nintendo y no se ha publicado información al respecto a día de hoy.


¿Qué pasa con las compañías de terceros?

No fue hasta que el primer juego de terceros empezó a desarrollarse, que se estableció la necesidad común de crear un kit de desarrollo para Famicom.

Sin apoyo alguno de Nintendo, pasó un año entero desde el lanzamiento de Famicom hasta que apareció el primer título. No tenían documentación alguna, y consiguieron crear estos primeros videojuegos gracias a la investigación y la ingeniería inversa.


Programa de licencia de Nintendo

En 1986, con la NES ya en el mercado americano y europeo, Nintendo lanzaría su programa de licencias en Occidente, para permitir que otros desarrolladores crearan software para NES oficialmente.

Por entonces, las compañías buscaban programadores talentosos para utilizar el chip 6502, que era relativamente poco común en el momento de su lanzamiento (aunque ya se había utilizado en el Commodore 64).

Presumiblemente, muchos desarrolladores comenzarían escribiendo código para el C64 teniendo en cuenta el modelo de memoria de la NES y probarían su código grabando un cartucho EEPROM.

Es probable que los desarrolladores que lograron obtener una licencia oficial de Nintendo recibieran documentación básica sobre el hardware, como el mapa de memoria, funcionamiento de la PPU y APU, sistema de sonido, etc. A partir de ahí, le correspondería al desarrollador crear su propio entorno de desarrollo.


Kit de desarrollo interno oficial de Nintendo

Nintendo ha sido muy reservado sobre cómo se desarrollaron sus juegos oficiales de NES durante su etapa comercial, pero hay información proveniente de una revista japonesa de carácter juvenil, que muestra lugares de las oficinas internas de la compañía durante los años 80. Esta revista fue amablemente traducida por Chris Covell en su sitio web, añadiendo todo tipo de descripciones y curiosidades visuales.


Hardware y programación

Cuando se lanzó la NES por primera vez, no era común en Japón que los PC funcionaran con un procesador 6502. Entonces..., ¿Cómo escribieron y probaron los desarrolladores código para Famicom? ¿Tuvieron que grabar una EPROM cada vez que ensamblaron su código para probar incluso el cambio más pequeño?

Bueno, sí, de hecho ese fue el caso. Se sabe que los códigos de los primeros juegos de Famicom/NES se escribieron usando un ordenador NEC PC-8001 que tenía un procesador Z80, por lo que ninguno de los códigos ensambladores 6502 podría ejecutarse sin conectarse a un sistema NES. Tocaba grabar EPROMs constantemente para probar los desarrollos y sus cambios.

Pero hubo avances en los siguientes años.

Imagen


En la fotografía de esta revista anteriormente comentada, existe una sección titulada "Stars of the Famicom Games ". Podemos observar a cuatro programadores presumiblemente trabajando en Super Mario Bros. 3, en el año 1988. En este caso, ellos están usando HP 64000 Mainframe Computers que, parece ser, ha sido modificado para tener conectada una placa adicional de Famicom o una tarjeta procesadora 6502 para poder probar su código ensamblado sin necesidad de quemar EPROMs constantemente.


Hardware de pruebas y prototipos

¿Cómo probaba Nintendo los juegos beta que estaba escribiendo en el hardware? Los escritores de EEPROM repartidos por las oficinas, dan pistas sobre cómo se hizo esto.

Un escritor EEPROM escribe en una versión borrable del chip “ROM” del juego que se puede insertar en un cartucho de desarrollo que se puede colocar en una unidad Famicom reducida para realizar pruebas avanzadas.

Imagen


En esta fotografía se puede ver un cartucho EEPROM personalizado dentro de la Famicom minorista en el escritorio de Miyamoto, por lo que revisaba el juego y daba comentarios o informes de errores a los programadores y artistas para la próxima versión del juego.

Imagen


También tenemos imágenes de una emisión ​​de la televisión americana PBS hubo un segmento de 9 minutos transmitido en 30 de diciembre de 1988 de MacNeil/Lehrer “NewsHour” 5que dio un vistazo muy breve al interior de la oficina de Investigación y Desarrollo de Nintendo y muestra un chip EEPROM escrito en un sistema llamado PROS-80 por IWASAKI :

Imagen


Este chip luego se transfiere a un cartucho NES personalizado mediante Masahiro Ishizuka y un desarrollador desconocido:

Imagen



Hardware para Artistas Gráficos

En la misma revista podemos ver al Sr. Tezuka trabajando duro en Super Mario Bros 3, y parece que está viendo los datos del personaje de la tabla de sprites de Mario.

No está claro si está conectado a la versión que se ejecuta en Famicom a la derecha del ordenador. Sería bastante útil si los cambios realizados en el PC actualizaran automáticamente los sprites en el juego en ejecución, pero es poco probable que hubiesen creado el hardware para admitir dicha característica en tiempo real.

Imagen


Presumiblemente, se trata de algún tipo de herramienta de edición de píxeles que puede unir partes de la tabla de sprites y actualizar. Posiblemente, incluso animar el resultado para el espectador. No está claro qué representan los colores en la parte superior; podría ser la paleta de colores disponible.

Imagen


El ordenador para empresas Fujitsu FM R-50 HD se utilizó para crear todo el pixel art de Super Mario Bros. 3. Era un PC compatible con IBM que ejecutaba una versión de MS-DOS.


Kits de desarrollo internos de terceros

Debido a la falta de kits de desarrollo oficiales de NES, muchas empresas tuvieron que aplicar ingeniería inversa al sistema para poder desarrollar cualquier juego.

De estas investigaciones se acabaron creando todo tipo de artilugios a cada cual más estrafalario e increible, como vamos a ver a continuación, a fin de poder crear videojuegos para NES sin ayuda de Nintendo o prestando esta la mínima posible.


Kit NES Mission Control Dev

Imagen
Imagen


El NES Mission Control Dev fue creado por Rocket Science Productions para ayudar a los desarrolladores más pequeños a penetrar en el mercado de creación de videojuegos para la nueva consola de Nintendo.

Consiste en una proto placa llena de chips y puestas integradas, atornillada a una tabla de madera, y una consola NES modificada mediante un cable interface donde conectar, supuestamente, un PC.

Entre los juegos creados con este sistema de desarrollo, nos encontramos estos:

- Bill & Ted’s Excellent Adventure
- The Mutant Virus


HAL “Game Maker” (Twin Famicom)

Imagen


HAL Laboratory, Inc., mejor conocida por crear la serie de juegos Kirby y Mother, tambien fue una de las primeras desarrolladoras para NES.

Como muchos otros, no tenían kits de desarrollo oficiales disponibles, por lo que adoptaron un enfoque bastante único para desarrollar juegos en el sistema: Usaron el sistema Twin Famicom modificada para poder conectar un ratón trackball, y crearon una serie de herramientas que disponia incluso de un teclado virtual.

Los datos del programa se escribian y leían desde el disquete FDS y, además, crearon un software que se ejecutaba en un cartucho y que les permitía editar código o datos de sprites.

Este kit se utilizón, por ejemplo, para programar Metal Slader Glory o Kirby's Adventure.


Kit de desarrollo de Software Creations (Mike Webb)

Software Creations, Ltd. tenia un problema entre manos: querían desarrollar juegos para la nueva consola doméstica de Nintendo, pero esta sólo permitia que las empresas que ya estaban desarrollando juegos de NES obtuvieran licencias nuevas. Esta situación tan irónica, desencadeno que Mike Webb realizara ingeniería inversa en el hardware de NES y creara su propio kit de desarrollo.

Según una entrevista en el número 37 de Retro Gamer Magazine, este kit era una creación bastante ingeniosa que consistía en una pila de chips RAM donde se podía programar gracias a un Commodore 64 y, luego, leer el código creado a través del puerto de cartucho de una NES cualquiera.

Puedes ver a Mike Webb hablando sobre la creación de Solstice para NES, un juego que no solo programó, sino que también creó mediante este kit de desarrollo.




BEAM’s NES Development System

BEAM era una empresa muy pequeña en los años 80 que creaba principalmente títulos para ZX Spectrum desde su oficina en Melbourne, Australia.

Cuando la Famicom (NES) fue lanzada en Japón con gran éxito de crítica, sabían cuál sería su próxima plataforma de desarrollo. Sin embargo, también sabían que Nintendo nunca entregaría kits de desarrollo a una empresa tan pequeña.

Adquirieron una Famicom y pasaron un año entero realizando ingeniería inversa en el hardware de esta, para que en 1987 consiguieran completar su NES Development System. La noticia se propago en las revistas de la época, y causó un gran revuelo, especialmente en la comunidad de desarrollo local australiana, hasta el punto de que BEAM comenzó a vender los kits a otras empresas de desarrollo.

La noticia de la venta de estos kits de desarrollo a terceros no agradó a Nintendo y después de un largo proceso de negociación, BEAM acordó dejar de vender su kit de desarrollo para obtener una licencia de desarrollo oficial de Nintendo.


Westwood Studios

Imagen


En 2011 se subastó en Ebay un artículo de aspecto bastante intrigante afirmando que era un kit de desarrollo de NES utilizado por los Westwood Studios.

Curiosamente, la descripción del artículo también menciona que "Atari" estaba impreso en algunos de las placas del hardware.

Actualmente se desconoce quién compró el hardware y si se utilizó para el único título de NES de Westwood Studios, llamado Dragon Strike.


Namco

Namco realizó ingeniería inversa en el hardware de Famicom al poco de ser lanzada al mercado, y creó su propio conjunto de herramientas de desarrollo. Sin embargo, se ha publicado muy poca información sobre sus kits de desarrollo internos, por lo que se presupone que fueron eliminados después de que cesase el auge en el mercado de la NES.


N2G - Nintendo Development System

Imagen
Imagen


El usuario JaxsBox, publicó detalles de un kit de desarrollo de terceros para NES, en la antigua web NintendoAge, donde, además, publicó algunas fotos y alguna información técnica.

Tened en cuenta que este kit de desarrollo no contiene una ranura para cartuchos, por lo que probablemente se conectaba directamente a un PC para enviar datos ROM a la máquina, y su consecuente emulación.

Presumiblemente esto fue desarrollado internamente por RSP (Riedel Software Productions, Inc.), aunque también es posible que haya sido desarrollado por otra empresa y que se haya concedido licencia a RSP.

Juegos que pueden haber sido creados con este kit de desarrollo:

- Sesame Street: Countdown
- Sesame Street: Big Bird’s Hide and Speak
- MTV Remote Control
- Win, Lose, or Draw


Square (Apple II & Twin Famicom)

En una entrevista muy poco conocida, Nasir Gebelli habla sobre la creación de juegos de NES por parte de Square. Aseguró que utilizaron en sus desarrollos un ordenador Apple II y un pequeño ensamblador, kit con el que crearon incluso juegos como el primer Final Fantasy.



En este otro video corto, hablan sobre cómo se hizo Final Fantasy II y parece que la mayoría de los desarrolladores están usando una Sharp Twin Famicom. Esto se usó al menos para probar sus juegos, pero no está claro si construyeron algún hardware personalizado, o incluso qué ordenadores se usaron finalmente para escribir en ensamblador 6502.




Programmers Development System (PDS)

El Programmers Development System o PDS, para abreviar, era un kit de desarrollo para muchos sistemas de 8 bits, incluidos C64 y ZX Spectrum (que era muy popular en el Reino Unido).

Fue desarrollado por Andrew Glaister, Foo Katan, y su amigo Jez San, y vendido por su empresa PD Systems, Ltd.

Más tarde, Foo Katan, también fundaría Bits Studios, empresa que desarrolló el videojuego de NES Loopzy, así como muchos juegos para Game Boy, e incluso un kit de desarrollo para esta portátil. No está claro si su desarrollo para NES y GB se basó en su trabajo anterior con PDS, pero es muy probable que al menos esté influenciado por él.


Rare Ltd (PDS)

Imagen


Rare se convirtió en uno de los primeros desarrolladores extranjeros de Nintendo.

Gracias a la ingeniería inversa del hardware de Famicom, y antes de su lanzamiento en Occidente, crearon un kit de desarrollo, e incluso software de ejemplo que presentaron a Nintendo en un viaje que realizaron a Japón.

Este kit de desarrollo consistía en un circuito que se conectaba a la entrada de cartuchos de Famicom. La placa de este kit tiene serigrafiado en uno de sus laterales "COPYRIGHT 1988 RARE LTD" en lugar de una marca oficial de derechos de autor de Nintendo o Intelligent Systems. También tiene serigrafiado en la misma placa "PDS". Esto sugiere que se utilizó el PDS Development System, antes comentado, hecho por P.D. Systems, Ltd. (Andy Glaister & co).

Como PDS era un kit de desarrollo de uso común en el Reino Unido, era probable que cuando Rare estaba desarrollando juegos de ZX Spectrum usaran tambien este mismo sistema de desarrollo que tambien era compatible con Commodore 64 (CPU 6505), por lo que todo lo que tenían que hacer era aplicar ingeniería inversa a la NES y crear una interfaz para controlarla desde su configuración de desarrollo existente.


Eurocom (PDS)

En el código fuente del juego Magician de NES de 1990, que fue amablemente compartido por el desarrollador Chris Shrigley, contiene archivos .PDS que se utilizan en el kit de desarrollo de PDS.

Cuando abres los archivos .PDS, podemos encontrar con un editor de texto la cadena "P.D.Systems Ltd 1985-88". De esta manera podemos confirmar que se utilizó el sistema de desarrollo PDS, así que, definitivamente, el estudio lo utilizó para el desarrollo de juegos de NES. Aun así, sigue siendo un misterio si utilizaron la placa de interfaz de Rare o crearon la suya propia.


Zippo Software (subsidiaria de Rare, probablemente PDS)

En el número 22 de la revista UK Magazine Games, se menciona la asociación de Zippo Software con Rare. Esto significó que ambas fueron una de los primeras en recibir un kit de desarrollo de NES fuera de Japón y, por lo tanto, producir en conjunto Solar Jetman en 1989.

De esta manera posiblemente usaron un kit de sistema de desarrollo PDS con la tarjeta de interfaz construida por Rare.


Codemasters

Como desarrolladora de juegos británica que programaba videojuegos para Commodore 64 y Spectrum, Codemasters utilizó PDS para desarrollar la mayoría de sus programas en estas plataformas.

No hay pruebas de que también utilizaran este mismo kit de desarrollo para los videojuegos de NES que crearon, pero es probable, porque ya estaban familiarizados con este entorno.

En el número 136 de la revista Edge UK, se menciona que crearon su propio prototipo de kit de desarrollo para NES y así poder evitar las costosas tarifas de licencia de Nintendo.

Igualmente, así es como desarrollaron el dispositivo de trucos conocido como Game Genie.

Su kit de desarrollo fue descrito como una especie de hardware donde un PC estaba conectado a un Commodore 64, y este a una NES, junto con una masa de cables.

Como curiosidad, cada título que desarrollaron, internamente recibía el nombre de un personaje de la película Blade Runner.


Bit Managers e Infogrames(PDS)

Imagen


En una entrevista con Alberto González, quien fue compositor de muchas bandas sonoras de videojuegos clásicos junto con trabajos de desarrollo gráfico, mencionó que utilizaron PDS con modificaciones para poder desarrollar en GameBoy, Master System y NES.

La captura de pantalla pertenece a Alberto usando PDS Pc1, desarrollado por P.D.Systems Ltd 1985-88.


Versión original del artículo: https://www.retroreversing.com/famicom- ... pment-kit/
534 respuestas
Responder
1…7, 8, 9, 10, 11
Volver a Consolas clásicas