[SUPER NINTENDO] Hilo oficial.

ChepoXX escribió:sobre esta afirmación los juegos con el chip sfx2 solo podian usar 16 megas¿¿? estas seguro juraría que el doom usa 32 igual que yoshi island ¬_¬ ¬_¬


Exacto, me la juego a que nos quedamos sin comanche FX porque, después de la demo, se debieron dar cuenta de que se quedaban cortos. Si las next gen hubieran llegado mas tarde, nintendo no hubiera tenido problema en rediseñar el FX (lo que hubiera supuesto la verdadera segunda generación del chip FX). La cosa es que después de diseñar el chip, lo capan para sacarlo a la venta con el star wing, y mas tarde le devuelven sus prestaciones originales, y lo sacan con el sobrenombre de "FX2", pero en realidad es la configuración original.


magno escribió:Sí que puedes... lo de FX2 realmente sólo es una denominación para indicar que se han corregido los errores de la primera versión y que pueden hacerlo funcionar más rápido (21 MHz), pero es el mismo chip con el mismo juego de instrucciones.
También es verdad que si un juego diseñado para la GSU-2 lo haces correr en la GSU-1 igual no te funciona correctamente porque baje el framerate o haga algún tipo de transferencia o trap con unas temporizaciones diferentes. Lo mismo podría pasar al revés.


El encapsulado y patillaje son diferentes. Para apañar un FX2 en un star wing hay que ser ingeniero XD (veo mas facil overclockearlo, que andar compensando la posición de las patillas a base de cables).

Lo del frame rate no se yo si el juego pondrá pegas, aunque viendo lo visto en ejemplos de emulación, el juego se acelera, que no es lo mismo que acelerar el rendimiento. ¿Estaríamos hablando del mismo resultado metiendo un FX2, en vez de un FX al 200%? (en el video que vi yo, overclockeaban via emulador, un FX al 400%. A lo mejor via emulador, lo que realmente hacen es meterle al juego un 4X, y ni se enteraban del detalle).


magno escribió:No, ambos juegos son de 16 Mbtis; el MARIO chip (FX que se usó en Starwing) y el FX GSU-1 sólo podían direccionar 8 Mbit, mientras que GSU-2 podía hasta 16 Mbit de ROM.


Entonces tengo esto mal (o incompleto), ¿no?:


* Architecture: RISC
* Clock Speed: 10.74Mhz/21MHz
* Peripheral ROM: 16Mbits max
* Peripheral RAM: 1Mbit max
* Internal Data Bus: 16 bits
* External Data Bus: 8 bits
* Internal Registers: 16 bit x 16
* Instruction Cache: 512 Bytes
* Processing Advantages: Polygon Processing; Software Sprite Processing


Debería ser:

* Architecture: RISC
* Clock Speed: 10.74Mhz/21MHz
* Peripheral ROM: 8Mbits FX / 16Mbits FX2
* Peripheral RAM: 1Mbit max
* Internal Data Bus: 16 bits
* External Data Bus: 8 bits
* Internal Registers: 16 bit x 16
* Instruction Cache: 512 Bytes
* Processing Advantages: Polygon Processing; Software Sprite Processing


...pero, ¿y el resto?. Echame un cablecillo porfas XD


magno escribió:Lo de las nomenclaturas es algo que tendré que comprobar, porque creo que lo que se llama comercialmente "Chip Super FX" es tanto el "MARIO" chip del Starwing como el GSU-1 de los primeros juegos, mientras que "Chip Super FX 2" hace referencia a la GSU-2.


MARIO fué la designación inicial, lo que está claro es que el juego ya estaba en el horno cuando se decidió fabricar los chips. Seguramente fué un cambio en el marketing, todo sobre la marcha. El chip es el mismo.
KILLER INSTINCT

Imagen



La ambientación de Killer Instinct nos sitúa en un futuro marcado por el poderío tecnológico de diversas corporaciones que realizan experimentos genéticos, así como desarrollos armamentísticos en forma de cyborgs encaminados a la venta a ejércitos de todo el mundo. Para entretener a las masas se ha creado un torneo donde luchadores de todo el mundo, así como diversos conejillos de indias, o incluso prototipos de robots, participan para conseguir metas como una cura al mal que lo azota, la libertad, información sobre el paradero de un hermano perdido, etc.

Killer Instinct nos presenta a una serie de personajes muy estereotipados como Jago, el Ryu de turno, Orchid, la chica explosiva que no podía faltar en todo juego de lucha como Chun Li en Street Fighter o Mai Shiranui en Fatal Fury/King of Fighters, TJ Combo, un boxeador al más puro estilo Balrog de Street Fighter, así como criaturas más originales como Cinder, un ente permanentemente en llamas, como uno de los 4 Fantásticos, Fulgore, un cyborg, Riptor, un dinosaurio, siguiendo la estela de títulos como Primal Rage, Sabrewulf, un hombre lobo, Chief Thunder, un chamán indio, Glacius, un extraterrestre que podía realizar diversos golpes de morphing al más puro estilo T-1000 de Terminator 2.


Imagen

Imagen

Imagen


¿Realmente nos encontramos ante un título de 16 bits?

Esa es la pregunta que asaltará a cualquiera que pruebe este cartucho negro de 32 megas comercializado en 1995. Mientras que la competencia sacaba títulos como Mortal Kombat 3, meras evoluciones de lo ya visto en anteriores entregas de la saga, o Super Street Fighter II, que pese a incluir un mayor colorido y nuevas animaciones, tampoco rompía gráficamente con lo presentado en Street Fighter II Turbo, Killer Instinct lucía de una forma tremendamente espectacular, pese a ciertos recortes imprescindibles


Las intros en formato FMV, tanto en las pantallas de versus, como en las bios de los personajes o las pantallas de celebración de victoria con los Awesome Victory, Supreme Victory, etc., fueron sustituidas por unas imágenes estáticas extraídas de las mismas, algo natural, ya que 32 megas se nos antojan incluso cortos para todo lo que alberga el cartucho.

Imagen

Imagen


En cuanto a la BSO tenemos unas composiciones que abarcan diversos estilos desde el hip hop a temas rockeros, pasando a composiciones instrumentales, y temas techno, todos ellos de una grandísima calidad. Podremos disfrutar de algunas de estas composiciones dentro del CD Killer Cuts que Nintendo España regaló junto al juego.

Los efectos de sonido también rayaban a un grandísimo nivel, con un speaker tremendamente notorio que anunciaba ciertos combos, movimientos finales, etc., algo recortados en longitud frente a la recreativa, con un toque oscuro y siniestro, en la línea de lo visto en Mortal Kombat.

Imagen

Puntuación: 9
Ralph escribió:La cosa es que después de diseñar el chip, lo capan para sacarlo a la venta con el star wing, y mas tarde le devuelven sus prestaciones originales, y lo sacan con el sobrenombre de "FX2", pero en realidad es la configuración original.


¿Tú crees? Yo creo que no, que el MARIO chip fue diseñado rápido para ajustarse a las necesidades del Starwing, pero luego lo pulieron, corrigieron y añadieron una línea de direcciones más para llegar hasta 16 Megabits de ROM máximo. Y creo que hay una explicación de por qué no se puede direccionar más, algo relacionado con el mapa Hi/Lo, pero tendría que mirar el manual del desarrollador del FX para asegurarme...


Ralph escribió:El encapsulado y patillaje son diferentes. Para apañar un FX2 en un star wing hay que ser ingeniero XD (veo mas facil overclockearlo, que andar compensando la posición de las patillas a base de cables).


Me has entendido mal o me he explicado mal: me refería a meter una EPROM con un juego diseñado para la GSU-1 en una PCB con un GSU-2. El patillaje es diferente... es más, estuve haciendo hace tiempo un dibujo con el pinout de todas las versiones del FX, a ver si lo termino y lo cuelgo.


Ralph escribió:Lo del frame rate no se yo si el juego pondrá pegas, aunque viendo lo visto en ejemplos de emulación, el juego se acelera, que no es lo mismo que acelerar el rendimiento. ¿Estaríamos hablando del mismo resultado metiendo un FX2, en vez de un FX al 200%? (en el video que vi yo, overclockeaban via emulador, un FX al 400%. A lo mejor via emulador, lo que realmente hacen es meterle al juego un 4X, y ni se enteraban del detalle).


No creo que un FX se pueda poner a 21MHz (x2) sin que haya problemas en la ejecución del código en él, si no, lo habrían hecho de entrada lo más seguro. A ver si repaso los datos que tengo de funcionamiento y te cuento, porque todo esto tiene un por qué.



Ralph escribió:Debería ser:

* Architecture: RISC
* Clock Speed: 10.74Mhz/21MHz
* Peripheral ROM: 8Mbits FX / 16Mbits FX2
* Peripheral RAM: 1Mbit max
* Internal Data Bus: 16 bits
* External Data Bus: 8 bits
* Internal Registers: 16 bit x 16
* Instruction Cache: 512 Bytes
* Processing Advantages: Polygon Processing; Software Sprite Processing


...pero, ¿y el resto?. Echame un cablecillo porfas XD


Cierto, debería ser así, pero te lo confirmaré en cuanto pueda :)
El Killer instinct lo compré el otro día completo por 12 o 13 eurillos, todavía lo estoy esperando. Siempre, incluso en su día, me pareció demasiado sobrevalorado... sin zoom (cuando hemos visto que hubiera sido posible, ahí está el art of fighting... aunque eso si, quizas no quedara espacio para currarse una rutina por software. No se cuantas lineas de código necesitarían... o directamente quizás les valió así).

Los sprites tiene un tamaño justito, y la musica es casi ratonera en algunos escenarios. A este Killer instinct siempre le faltó un esfuerzo mas para ser un juego tan sorprendente como el arcade(salvando las distancias. O sea, para lo que es una super nintendo). Con 12 Mbits mas se hubiera conseguido un apartado sonoro soberbio, algo mas que imprescindible para que un título parezca otra cosa.

Muy poquito le falta a este Killer instinct, como digo, para que me hubiese parecido una bestialidad de juego... mejor sonido, mejor musica, sprites un pelín mas grande, y algo de zoom. Los escenarios se quedan como están, porque ya hablariamos de necesitar cartuchos todavía mas grandes que 48 Mbits... y hablamos de inflarlo un poquito mas de detalles, no de meter los detalles de la maquina recreativa.

El resto del juego es impecable, la jugabilidad es REALMENTE solida, tiene todos los ataques, combos, movimientos, y contundencia del arcade. Las animaciones rara vez ahorran descaradamente en frames, a dobles tiene su puntazo, y en el fondo, tal y como está, no anda mal de espectacularidad en algunos momentos. Un juego recomendable, y como curiosidad todavía mas recomendable.


...no recuerdo ahora si en el escenario de eyedol la lava es estática, o también está animada :-?


magno escribió:¿Tú crees? Yo creo que no, que el MARIO chip fue diseñado rápido para ajustarse a las necesidades del Starwing, pero luego lo pulieron, corrigieron y añadieron una línea de direcciones más para llegar hasta 16 Megabits de ROM máximo. Y creo que hay una explicación de por qué no se puede direccionar más, algo relacionado con el mapa Hi/Lo, pero tendría que mirar el manual del desarrollador del FX para asegurarme...


No con total certeza. Es mas o menos lo que tengo entendido... es que siendo el starwing de 8 Mbits, y no necesitando mas de 10.5Mhz para ir bien, me sorprendería que hayan diferencias entre ambos chips. En todo caso hablaba del chip MARIO, y el FX GSU-1, ojo.


magno escribió:Me has entendido mal o me he explicado mal: me refería a meter una EPROM con un juego diseñado para la GSU-1 en una PCB con un GSU-2. El patillaje es diferente... es más, estuve haciendo hace tiempo un dibujo con el pinout de todas las versiones del FX, a ver si lo termino y lo cuelgo.


Ya me vale la chorradilla, si XD. Mas facil es cambiar la EEPROM a una PCB con el FX2 pinchado, que no cambiar los FX de sitio [toctoc]



magno escribió:No creo que un FX se pueda poner a 21MHz (x2) sin que haya problemas en la ejecución del código en él, si no, lo habrían hecho de entrada lo más seguro. A ver si repaso los datos que tengo de funcionamiento y te cuento, porque todo esto tiene un por qué.


Ya, fijate que sobre hardware real no se han complicado demasiado. Tan solo 5Mhz para ganar unos 5 o 6 frames... ¿y por qué no mas, ya que te pones?, pues por lo que tu dices, imagino, ¿no?.


magno escribió:Cierto, debería ser así, pero te lo confirmaré en cuanto pueda :)


Pero, ¿que hay del resto?:

* Peripheral RAM: 1Mbit max
* Internal Data Bus: 16 bits
* External Data Bus: 8 bits
* Internal Registers: 16 bit x 16
* Instruction Cache: 512 Bytes


...esto también debería cambiar, ¿no?. Los bus de datos seguro que no, y realmente la RAM periférica (peripheral RAM) tampoco creo que se demandara en un star fox 2, doom, o yoshi's island, aunque mantengo la duda con todo (por si acaso). Sin embargo, lo que remarco en negrita, debido a sus cambios, quizás si haya pasado algo por alto...
Me has entendido mal o me he explicado mal: me refería a meter una EPROM con un juego diseñado para la GSU-1 en una PCB con un GSU-2. El patillaje es diferente... es más, estuve haciendo hace tiempo un dibujo con el pinout de todas las versiones del FX, a ver si lo termino y lo cuelgo.


Entiendo que ffantasy6 sacrifico un stun race fx para el star fox 2......... eso debería generar varios problemas de acuerdo a lo explicado por ti cierto?

sobre el killer instinct, buen anális pero falta comentar para mi gusto sobre el game play, y las caracteristicas que únicas del juego, por cierto el cd que regalaban en las primeras unidades traía las canciones del arcade. [fumando] [fumando]
El stunt race lleva el FX2, aunque no lo parezca XD
ChepoXX escribió:Entiendo que ffantasy6 sacrifico un stun race fx para el star fox 2......... eso debería generar varios problemas de acuerdo a lo explicado por ti cierto?


No no, como dice Ralph, el Stunt Race FX lleva la GSU-2, de ahí que ambos sean compatibles.
El stunt race lleva el FX2, aunque no lo parezca XD



No no, como dice Ralph, el Stunt Race FX lleva la GSU-2, de ahí que ambos sean compatibles.




Va a ser entonces sobre juegos con chip fx1 y fx2 esta mal

Juegos:

Juegos que usaron el chip FX1:

* Dirt Trax FX
* Star Fox (North America/Japan) / Star Wing (PAL)
* Stunt Race FX (North America/PAL) / Wild Trax (Japan)
* Vortex


Juegos que usaron el chip FX2:

* Dirt Racer
* Doom
* Super Mario World 2: Yoshi's Island
* Winter Gold / FX Skiing
Bueno, pues os cuento a las deducciones que he llegado por mi cuenta.
Resulta que, como sabréis, la SNES tiene 2 mapas de memoria (conocidos HiROM y LoROM) que le implican a la CPU el tiempo de espera entre una petición a memoria y el dato recibido (esto se debe a que es una transferencia asíncrona con la ROM del cartucho); así, en HiROM sólo espera 3 ciclos (creo recordar) y en LoROM son 4 ciclos del reloj maestro. Como el SuperFX es el que gestiona la ROM con los datos del programa (y la bufferea), lo lógico es usar el modo de memoria más lento, de modo que se pueda consumir el tiempo necesario dentro de la GSU para que los datos lleguen a la SNES.
Al usar un mapa LoROM, ya implica usar el rango de memoria [$00-$3F]:[$8000-$FFFF] para los datos de ROM (2 Megabytes), más [$40-$7D]:[$0000-$FFFF] haciendo un total de 4Megaytes (algo menos realmente, por los dos bancos reservados a la WRAM). Pero además, hay que meter el acceso a la RAM que tiene la GSU, que es de 128Kbytes, es decir 2 bancos más, y también hay que meterla en LoROM (para tener los 4 ciclos), por lo que hace de ser en la zona de bancos [$40-$7D], así que es lógico pensar que, para simplificar el decodificador de direcciones, esta zona se reserva para la memoria RAM de la GSU, y de paso se usa para la memoria RAM que se usa para las partidas, de modo que se decodifica todo el rango [$40-$7F] de la misma forma, usando todo el banco, no sólo la parte alta del mismo.

Después de todo este rollo, tengo que añadir una cosa... realmente la SNES podría direccionar datos de programa en ROM en el rango [$C0-$FF]:[$0000-$FFFF] como una HiROM normal y en el rango [$80-$BF]:[$0000-$8000] como una LoROM normal, de modo que se podría añadir una ROM extra de hasta 4 Megabytes (HiROM) + 2 Megabytes (LoROM), haciendo un total de 48 Megabits que no podrían ser accedidos por la GSU. Imaginad por ejemplo esa zona para la música, enemigos y fondos 2D, texturas y demás cosas.

En cuanto a las características que hablábamos antes, están todas bien, añadiendo lo de las velocidades. Por cierto, que me sorprende que en la documentación que tengo describen la GSU-1 e indican que tiene 2Megabytes de direccionamiento como he explicado y funcionamiento a 10.74MHz, por lo que entonces entiendo que los nombres comerciales quedan así:

* MARIO chip -> usado sólo en StarFox, es la GSU-1 pero con capacidad de direccionar sólo 1 Megabyte de ROM. Funciona a 10.74 MHz

* GSU-1 -> usado sólo en Dirt Trax FX/Stunt Race FX, Vortex, con capacidad direccionar 2 Megabyte de ROM. Funciona a 10.74 MHz.

* GSU-2 -> usado en el resto de juegos, es la GSU-1 con alguna corrección interna y que funciona a 21 MHz.

Entonces estábamos equivocados, porque Stunt Race usa la GSU-1, pero creo que es indicada para StarFox 2 por la memoria que tiene la PCB instalada, que es de 512Kbytes y no de 256Kbytes como tiene Yoshi's Island, por ejemplo.
He leído en Nesdev que usando la GSU-2 para el StarFox 2 se producen cuelgues y pantallazos negros, aunque no es algo confirmado 100%. Si hubiera una PCB con la GSU-2 y 512 Kbytes de SRAM se podría probar a poner el StarFox 2 a ver cómo funciona.

Por cierto, que este pinout lo hice yo con el polímetro y un cartucho del Stunt Race FX:

Imagen

No lo había encontrado por ningún lado, así que lo hice yo mismo.
ueno, pues os cuento a las deducciones que he llegado por mi cuenta.
Resulta que, como sabréis, la SNES tiene 2 mapas de memoria (conocidos HiROM y LoROM) que le implican a la CPU el tiempo de espera entre una petición a memoria y el dato recibido (esto se debe a que es una transferencia asíncrona con la ROM del cartucho)


JAja ya quisiera saber la mitad que tu, en temas relacionados con la super nes [sonrisa] [sonrisa] [sonrisa]


Entonces estábamos equivocados, porque Stunt Race usa la GSU-1, pero creo que es indicada para StarFox 2 por la memoria que tiene la PCB instalada, que es de 512Kbytes y no de 256Kbytes como tiene Yoshi's Island, por ejemplo.
He leído en Nesdev que usando la GSU-2 para el StarFox 2 se producen cuelgues y pantallazos negros, aunque no es algo confirmado 100%. Si hubiera una PCB con la GSU-2 y 512 Kbytes de SRAM se podría probar a poner el StarFox 2 a ver cómo funciona.


Yo tengo la rom del star fox2 y decir que la carga poligonal así como efectos en el juego son mucho mayores en este juego que en su primera versión y me extraña mucho que solo use el chip fx1 a 10 mhz, si fuese así, me suerge la duda de como hubiera sido una star fox aprovechando el máximo de la snes y el chip fx2.

En todo caso va a ser que efectivamente solo usa el chip fx1, esto fue lo que comentó ffantasy6

Yo lo vi bien, en el emulador solo lo probé que arrancara y no puedo comparar, y era el parche que quitaba el marcador de hertzios por lo que tampoco se si se relentizaba.

Me lo pasé y lo vi bien de velocidad.
Buen aporte magno, no te imaginas lo encantadísimo que estoy de que te tengamos por aquí :). Ahora mismo estoy que se me caen los parpados, pero mañana le vuelvo a echar otro vistazo.

La verdad es que tenía pensado recopilar documentación técnica sobre el FX, que complemente lo que ya está publicado, por lo que estoy comprobando, lo que se puede conseguir por internet no es muy extenso, ¿no?.


ChepoXX escribió:Va a ser entonces sobre juegos con chip fx1 y fx2 esta mal


No, no, por lo visto lo que está mal es mi comentario. Mal matizado al menos.

Ya sabemos por la explicación de magno que el stunt race lleva un FX1(segunda revisión), y que es compatible con el star fox porque este usa el FX1 (segunda revisión).


ChepoXX escribió:Yo tengo la rom del star fox2 y decir que la carga poligonal así como efectos en el juego son mucho mayores en este juego que en su primera versión y me extraña mucho que solo use el chip fx1 a 10 mhz, si fuese así, me suerge la duda de como hubiera sido una star fox aprovechando el máximo de la snes y el chip fx2.


Bueno, es rarillo, pero no es dificil que simplemente haya un gran trabajo de optimización.

El juego que creo desaprovecha el FX2 es el yoshis island. Le podía haber metido mas caña el juego a sus virtudes, en vez de usarse solo puntualmente en unas pocas ocasiones (por lo que tengo entendido, vamos).
Me puse a divagar por wikipedia sobre Argonaut, y me di cuenta de que hay una info que has dado un poco desfasada. Es una simple anécdota que no le importará a nadie, pero lo comento xD.

Actualmente, la ARC sigue viva, ha comprado varias compañías más y hace microprocesadores, sistemas multimedia y un porrón de cosas.


ARC fue comprada el año pasado por Virage Logic. http://www.arc.com/
ImagenVolver a la página principal.




JUEGOS CANCELADOS A-B


Imagen




    · 7th Guest, The
    · Airborne Ranger
    · Akira
    · Albert Oddysey
    · Apocolypse II
    · Arcus Spirits/ Arcus Odyssey
    · Asterix
    · Batman (Software Creations)
    · Batman: Revenge of the Joker
    · Beast Ball
    · Blaster Master 2
    · Bobby's World
    · Boo!
    · Bulls Vs. Lakers








7th Guest, The
One of the only known games that was known to be in development for the Snes CD, The 7th Guest would have been a demostration of the 3D and FMV capabilities of the add-on.

Scans courtesy of RetroMags.

Imagen

There is a lot of mystery behind the canceled SNES CD add-on. There are many questions as to how far along the hardware was, and what games were in active development for the system. In the April 1992 issue of Nintendo Power, there is an article on Nintendo's partnership with Philips to create a CD system. One of the featured games in the article is "Guest", which was likely the working title for The 7th Guest.

Rene Boutin, who worked at Virgin Games, says that a fully working demo of 7th Guest existed for the SNES, including FMV (full motion video).
The 7th Guest was apparently shown behind closed doors at the CES in 1992.

Imagen

Bibliography:

    · rec.video.games - discussion on CES 1992 (link)
    · Nintendo Power, Super NES Technology Update - CD-ROM, Publication date: April 1992, Volume: 35, Pages: 70-71
    · Nintendo Power - Super Power Club Extra, Future Technologies, Future Games (Talks about The 7th Guest in terms of it being a good example of a CD-ROM game, though it doesn't state it is in development for the SNES CD), Publication date: January 1993, Volume: 44, Pages: 14-15


Airborne Ranger
Airborne Ranger is a cancelled action game / third person shooter that was in development by Microprose for the Super Nintendo. The game was a sequel / remake of the original Airborne Ranger released in 1987 / 1988 for Amiga and various PCs. As the original version, we would have play as a sole airborne military to infiltrate enemy territory to complete various objectives. It’s currently unknown if the SNES version was going to use the same level system as the original game, that created maps and objective locations randomly so missions were never the same.

Some screens of the game were found in magazines Banzzai #14 and Super Power #12

ImagenImagen

    Imagen

Imagen


Akira
Rod_Wod from the Assembler Forum has posted various scans from the cancelled Akira games (based on the manga / anime with the same name) that were meant to be released by THQ for the Genesis / Mega Drive, Super Nintendo, Mega CD and Game Gear. Probably the screens published in the magazines were all from the same version, as the graphic looks almost the same for all the various consoles. It’s currently unknow why these games were never released or if they were somehow finishes. Some more screens were found by Celine in Player One #44, Console Plus #44 and #35.

Images:

Imagen Imagen

Imagen Imagen

Imagen Imagen

Imagen Imagen

Imagen Imagen


Albert Odyssey Gaiden
Albert Odyssey Gaiden (known in USA as Legend of Eldean) is RPG developed by Sunsoft and released for the Saturn in 1996, but it was originally meant to be published for the Super Famicom / Super Nintendo. The SNES version was soon cancelled and the project was ported to the new SEGA console, with many differences. Obviously the graphic was boosted for the Saturn, but even the SNES version looked really good for a 16 bit system.

As in 1994 / 1995 many japanese gamers were going to buy one of the new 32 bit consoles to replace the Super Famicom / Mega Drive, probably Sunsoft thought that Albert Odyssey Gaiden would have sold better on the Saturn.

It’s currently unknown how much the SNES version was completed before its cancellation.

Thanks to Celine for the contribution! (Scans from Super Power magazine #20 and #22)

Images:

Imagen Imagen Imagen

Imagen Imagen Imagen


Apocolypse II
Well, I received an email yesterday from Dave Allwein, and he said that he had in his possession an unreleased game. He said that it might be only source code, and I kind of winced as I was unsure whether or not I would be able to compile a snes game with the tools that are available. Anyway, he sent it today, and it was a binary! The game is called Apocalypse II, and SNES Central is proud to debut it for the masses! (note, this article was originally published on September 25, 2003)

Thanks to Simon Nicol (the developer) for making this ROM image available!

Imagen

This game is probably complete (although the checksum is bad), and it was already licensed by Nintendo. The game was being made for Psygnosis, written by Simon Nicol, graphics by Herman Serrano, and music by Mike Clarke. It was to be released in April 1995 (though the copyright screen says 1994). The game is multitap compatible.

Appcalypse II was covered in print media in early 1995. In fact, it was reviewed in Nintendo Power, where they complained that it was standard shooter fare, though they liked the graphics and the challenge. The following scans come from Nintendo Power (courtesy of Retromags):

Imagen
Preview in the January 1995 issue of Nintendo Power

Imagen
Review in the April 1995 issue of Nintendo Power


Imagen Imagen


This game is a shooter in the vein of Asteroids. You pilot a space ship that shoots laser shots at moons of varying sizes. Hitting the moons gains you points for each hit, and destroying them at various sizes gives you more points. Before each stage begins, there are various power ups that fall across the screen. The power ups include:

    · Speed Up (makes your ship faster)
    · Rotate (allows you to rotate the ship 360 degrees)
    · Missile (gives you one missile)
    · Shield (makes you temporarily invincible)
    · 1up (gives you an extra ship)

The control scheme is as follows:

    · A/B: Shoots laser
    · L: Rotate counterclockwise
    · R: Rotate clockwise
    · X: Shield
    · Y: Missile


Imagen Imagen


The goal of the game is to destroy the moons and gain points. Getting 10,000 points gains you a life. As you continue to shoot the moons, they begin to glow.
image
Destroyed one!

However, this game is basically impossible to pass further than level 3 or so. Once the moons begin to glow, they start to move very rapidly (even faster than your ship), and quite often follow you until you eventually die. I suppose the trick to the game is to destroy the moons when they first come on the screen so that you can destroy them easily, as when they are large, they take a lot of hits to destroy. And even with missiles, the purple and blue moons still take far too many hits to die.

So, to remedy this situation, I created an infinite ships cheat:

7E1118 05

Using this cheat kind of defeats the purpose of the game as the moons are instantly destroyed if your ship hits them (though you get no points for this), but I decided to play with it on for a while.

Imagen

As I am unsure if this game is 100% complete, however, I will sum up the various aspects.

Graphics

Nothing spectacular here. The ship isn't spectacularly designed, and the moons seem designed based on actual planets in the solar system. The planetary meltdowns look cool for the 3 seconds you have before it destroys you. The backgrounds are essentially just a starscape, but it rotates around which is pretty neat.

Sound

The sounds are typical of many space shooters, like Gradius III. However, the voice samples are very muffled (the best example is at the Psygnosis title). Overall, the sound sounds muted. Plus it sucks that there is only one song throughout the game. It is pretty good for a snes game, but after a while it gets old.

Controls

The controls work fairly well in this game, although rotating your ship doesn't always work well enough when a moon is chasing you around. The controls are pretty solid and shooter fans shouldn't have much problems getting into it.

Well, there you have it. It was cool to be able to sample the game, but it wasn't exactly my cup of tea. If you are into old style arcade games, give it a shot, as I am not very good at them. I'm sure most people will have the frustrations with the rapid death that I did as well.


Imagen Imagen


Published Review Scores:
Imagen

Bibliography:

    · Nintendo Power, Pak Watch (mentions it is development by Psygnosis), Publication date: January 1995, Volume: 68, Pages: 112
    · Nintendo Power, Now Playing (review), Publication date: April 1995, Volume: 71, Pages: 100,105


Arcus Spirits/ Arcus Odyssey
Arcus Odyssey was one of several unreleased games by Renovation. There exists an English beta of the game under the Japanese title, Arcus Spirits.

Imagen

    · Publisher: Renovation Products
    · Developer: Sammy
    · Game ID: SNS-A5-USA
    · Players: 1-2
    · Release: Scheduled for 1993
    · Genre: Action RPG
    · Released: Japan (as Arcus Spirits)

Arcus Spirits is an overhead adventure game, somewhat similar to The Legend of Zelda. You can choose between 4 characters and it had a Greecian theme to it. A beta version of the game was discovered, with the original Japanese name "Arcus Spirits" still on the title. The beta had the Wolf Team logo on it, suggesting they were preparing it for release. Renovation was purchased by Sega, so that is likely why the game never came out.

Imagen
Screenshot in the September 1993 issue of Nintendo power (scan by Retromags)


Information courtesy of Sakura Matsumoto:

A beta was leaked, however... it fails to credit Renovation (the company that translated it and was to publish it) or, in fact, any company except Wolfteam who made it and is still under the original title of Arcus Spirits, but seems to be otherwise completely translated. (An oddity: the Sammy logo has been removed from the game, as Sammy had nothing to do with American publication, but was replaced with the Wolfteam logo instead of the Renovation logo.)


Imagen
box found on half.com


Imagen
Screenshot in the October 1993 issue of Nintendo Power (scan by Retromags)


Imagen
Review in the November 1993 issue of Nintendo Power (scan by Retromags)


More Screenshots:

Imagen Imagen Imagen

Imagen Imagen Imagen

Imagen Imagen


Bibliography:

    · Nintendo Power, Pak Watch - Summer CES (as Arcus Odyssey), Publication date: August 1993, Volume: 51, Pages: 112
    · Nintendo Power, Pak Watch Update, Publication date: September 1993, Volume: 52, Pages: 112
    · Nintendo Power, Pak Watch Update, Publication date: October 1993, Volume: 53, Pages: 112-113
    · Nintendo Power, Now Playing (review; Graphics and Sound: 3.3/5; Play Control: 2.9/5; Challenge: 3.3/5; Theme and Fun: 3.3/5), Publication date: November 1993, Volume: 54, Pages: 105,107


Asterix
Asterix was a platform game developed by Infogrames and was intended for release in late 1993 by Electro Brain. It was based on the popular French cartoon.


Imagen

This game was released in Europe, but had no US release. I played the game for a few minutes, and it seems like a decent platform/action game with good graphics. But at the time, there were lots of platform games being released, and likely this one was lost in the shuffle. In the October 1993 issue of Nintendo Power, they stated it was intended for a Fall 1993 release.

Additional information provided by TRM

I believe the reason that Asterix was unreleased on the SNES was as follows. There was also an Asterix game on the NES, as well as a few Smurfs titles. Both of these cartoon characters are much more popular in Europe, and the games never made it over to the US. There are still Asterix games coming out for GBA, which aren't being released in the US. Once again, probably due to popularity and so forth.

Serial Code: SNS-XE-USA

Imagen
Box from Half.com


Bibliography

    · Nintendo Power, Pak Watch - Summer CES, Publication date: August 1993, Volume: 51, Pages: 111
    · Nintendo Power, Pak Watch, Publication date: October 1993, Volume: 53, Pages: 110,113
    · Nintendo Power, Super Nintendo Entertainment System Power Index (release list), Publication date: January 1994, Volume: 56, Pages: 1


Batman (Software Creations)
This unnamed prototype of Batman, also known as "Real Shitty Batman!", was a game in production by Software Creations. As its nickname suggests, it is very lacklustre. This beta game haves only two levels, and no sound.

Imagen Imagen

I'll admit, for the longest time I thought that Batman: Revenge of the Joker (another unreleased Batman game for the SNES) was the game known as "Real Shitty Batman!". I believe this was the case because the former owner of the Revenge of the Joker prototype told me it was. However, members at the Lost Levels forums informed me there was a Batman prototype which makes Revenge of the Joker look like a masterpiece.

Software Creation's Batman received its name for good reason, this (obviously alpha) early prototype is terrible. Whoever originally released the ROM image to the masses hacked it so that the name was "Real Shitty Batman!". I am unsure who owns the prototype now, but it was sold by Castlevania4Ever sometime last year when he was getting out of the prototype market. Just to keep things clean, the ROM image that I am including in this article has been modified back to have the original header name (though if you really must have Real Shitty Batman!, the ROM image is out there).


Imagen
Someone wasn't happy with this game

The Prototype

Unfortunately, I do not have a picture of the prototype cart that this ROM image originally came from. In fact, for all I know, the source of the ROM image is not a prototype cart at all! Like many of the ROM images of unreleased games out there, it is very possible that this was leaked out back in the 1990s when Usenet was all the rage.

The game itself is in a very incomplete state, probably alpha. The game consists of two stages, plus an introductory screen that is the same for both levels. The gameplay is largely in the style of Final Fight, though the look and feel is much different from Software Creations' other superhero beat-em-ups, Maximum Carnage and The Tick. The sprites are very large, but aside from Batman, very undetailed and incomplete. The Joker makes an appearance at the end of the first stage, but the attack and damage sprites are identical to the other enemies of the game, albeit in a glitched form (see images below). The background of stage one is actually not too bad, though stage two, the enemy sprites kind of blend in with the background. The game has no sound, and the controls are rudimentary (the enemies do not get knocked back when hit, making it simple for them to gang up on you). At the very least, if you run out of health, you do not die.

Imagen Imagen

Imagen Imagen

Imagen Imagen

Imagen

Youtube:
http://www.youtube.com/watch?v=zfQ1mgIS ... r_embedded

The ROM

On the whole, this prototype is interesting in that Software Creations tackled other comic book properties, but never released anything by DC Comics. I'm sure this prototype was created as a mock-up for pitching the idea. Instead, we got the excellent (if you like beat-em-ups, unlike myself) Batman Returns by Konami, and the downright dreadful Batman Forever by Acclaim. I have included the ROM image, should anyone feel the need to play this.


Batman: Revenge of the Joker
Batman: Revenge of the Joker was going to be released by Sunsoft in 1992. The company that developed it was Icom Simulations. It was commercially released on the NES (as Return of the Joker) and Genesis, but not the SNES, even though appears to be finished. Warning, this review contains many spoilers!

Imagen Imagen

Batman: Revenge of the Joker is one of those completed games that have been floating around since the dawn of the Internet, with little or no information on its origin or why it never came to be released. A prototype board of this game does exist, which is shown on the right. This board was owned by udisi, and sold on Ebay around February-March 2004. He mistakenly believed this was the game known as "Real Shitty Batman!", however the screenshots that he took of the game clearly show it is Batman: Revenge of the Joker. Direct comparison with screenshots from the ROM image show that this prototype is identical. The game was developed by Icom Simulations in 1992 for Sunsoft. That company's most notable games include Sherlock Holmes: Consulting Detective, Deja Vu, Shadowgate and Road Runner: Death Valley Rally.


The Game

This game appears to be complete, though it becomes evident very quickly as to why it was likely not released. Probably the best comparison of the gameplay would be Total Recall, though that might be a bit unfair as it is probably beatable. The game is a platform shooter, with a couple of side-scrolling shooter levels thrown in. The extreme difficulty and poor level design hampers what could have been a worthy upgrade of the original NES game.

Imagen

Stage 1

The first stage begins with enemies that shoot at you relentlessly, and spike balls that drop from unseen parts of the ceiling, both things that are unavoidable. Getting weapons upgrades makes life easier, but your are still forced to contend with hidden traps. The worst part is in the later part of the level, where you confront these statues that shoot lightning at you. In order to hit them, they first have to be in attack mode, which pretty much guarantees you get hit. If you don't have four health points (you fight three of them in a row), then you are out of luck. The level is very short, but because of the dangers, it took me many deaths to pass. I guess they expect memorization!.

Imagen Imagen

Stage 2 (password: DNCN)

The second level features a blimp that continually brings up enemies. They are not as relentless as the enemies in the first level, but they keep coming. The level automatically scrolls, meaning if you get caught behind a barrier or an inescapable hole (see right), you die. One of the big problems is if you get a gun powerup that is one shot at a time, you can be vulnerable to attack (in particular, the spread gun). The level itself is actually a bit easier than the first level, mainly due to the lack of hidden dangers.

At the end of the level, there is a boss battle. The rules of the battle boss are rather unique: rather than having a health gauge, the boss and Batman have a score gauge that decreases every time a hit registers. Of course, the catch here is that it is nearly impossible to avoid the enemy's shots unless it he is shooting on the far opposite side of the screen. Complicating things is the fact that the robots descending take off points off your health, and the boss' shots take off 300 points, while your default gun takes off only 100 points. I ended up configuring the fire button on turbo. Luckily if you die, you start over at the boss rather than the start of the level.

Imagen Imagen Imagen

Stage 3 (password: MCHT)

This is a short stage, but not without its insane difficulty. There are barrels that defy laws of physics and start to fly towards you if you shoot them. The enemies that jump around and shoot endlessly are back. In one part, there is a platform you need to use that goes up and down that bounded by two flames that are nearly impossible to avoid. Later on, the barrels are flying relentlessly through this corridor. Again, it is very difficult to avoid damage.

Imagen Imagen

Stage 4 (password: DDPP)

Stage 4 changes it up by becoming a side-scrolling shooter. Unfortunately, it is a bad side-scrolling shooter. Your character is so large, that it is pretty much impossible to actually avoid shots, which is the main skill of shooters. Most of the enemies, save the blue characters will shoot at you before you can kill them. The three boss robots take a lot of hits to kill, and will follow your every move, making the completion of this level very difficult. The background has some neat-ish Mode 7 graphics.

Imagen

Stage 5 (password: LDRN)

Stage 5 is composed largely of snowman heads flying through the air (damaging you only if they hit you on their way down), snowmen with bombs that go off when you pass by, and these strange cloaked things that shoot off whirlwinds that take off half your health. It is a difficult stage, for sure. If you want a real challenge, try to beat it with the crappy one-shot-at-a-time spread gun. It will leave you cursing.

Imagen Imagen

Stage 6 (password: KLTT)

Also known as the missile train, your best bet is to find the wave weapon and let the train do the scrolling for you. The missiles only harm you if they explode, so provided that you destroy them before they are automatically do, you should have the upper hand, in theory. In reality, the missiles come unendingly and some will get past your shooting range. To top it off, near the end of the train you also have to contend with these electric shadow monsters. There is little point trying to kill the enemies shooting off the missiles, nor is there any point trying to pass the level with the spread gun.

Imagen

Stage 7 (password: CRLB)

This stage wasn't nearly as bad as it seemed when I first started going through it. First off, get the wave spread gun, anything else is useless. The level scrolls automatically, but provided that you have the wave gun, the minor robot enemies aren't a problem. What is a problem is this flying machine that drops exploding bombs. What I learned is the best defence is a good offence. Start firing at them and don't stop and they will be destroyed before you die. This is the second stage with an end boss. Like level 2, you have to drain the enemy's health points before it does the same to you. When you first get to it, it seems downright ludicrous for a boss. The floor has holes that mean instant death. Fire comes up from the floor everywhere, and missiles come non-stop. Also, the blue beam the boss emits drains your health very rapidly. I eventually found that no matter how much damage you take from the fire and missiles, if you stay on the left side and shoot whenever the boss passes by, you should be able to take off more damage than you take. It takes a ridiculous amount of time to beat the boss this way, though. I threw on some turbo on the fire button, and it seemed to make it go a bit faster.

Imagen Imagen

Stage 8 (password: LKCM)

Quite possibly the easiest level in the game. I passed it second try, and I'll admit that the first try I fell into a pit. The level takes place in a sewer system, where the only obstacles are bombs falling out of pipes and crazy jumping scuba divers that shoot lasers. Really, you can pass this level without any concern for your health by ignoring the enemies.

Imagen

Stage 9 (password: DVWH)

Another shooting stage, similar to Stage 4. The background is a bit different, but otherwise it is the same except with more enemies. Not even worth a screenshot.

Stage 10 (password: TTKR)

This stage would be pretty easy (the barrels that bounce around are relatively easy to avoid), but there is a section where these white beams come down and extinguish your health. Later in the level, there are platforms that fall very quickly after you land on them. All the while, the level auto-scrolls.

Imagen Imagen

Stage 11 (password: BTMR)

This is a strange, but straight-forward level. You must follow along this tank, while this trail of fire follows behind. The fire is instant death, so you must stay ahead of it. Spike balls fall at regular intervals, and a man throwing firebombs comes out of the tank regularly. This is a level of endurance, and should be beatable after a few tries.

Imagen

Stage 12 (password: VNGF)

This is the final stage. The main level is rather easy, the only thing to watch out for are these parabolic line of bombs flying at you unexpectedly. Simple.

Imagen Imagen


The Joker comes in as two bosses. The first boss starts off with these fire trails that can be easily avoided with practise. You will need every bit of health possible to fight The Joker, as he throws a ton of bombs at you, and it is not possible to avoid them. I turned on turbo and just ignored the bombs, and even with full health I barely got through. The second boss is one of those decreasing score bosses. This boss is ridiculously hard, taking 1000 hits with the default gun to beat. The only way to beat the boss is to lure it to one side (without getting hit by the rockets on the robot's boots), jump up on the platforms so that the laser shield stops blocking from the bottom, and jumping back down between the robot's legs. All the while, you have to watch for fireballs coming down at you from the robot's mouth. Even with turbo on the shooting button, this is a tedious process, and would likely take at least 20 minutes. If you even get hit by a couple of times every few cycles, you are likely to lose. I got fed up after many tries and just created a cheat so I didn't die. Seriously, who designed this boss?.

Summary of the game

First, I would like to discuss the graphics and sound. Sound effects are pretty non-existent, except for your gun and the death throws of the enemy. Speaking of that, the cries of agony when you defeat human foes has to be one of the most chilling death sounds in any video game. The music sounds like it is straight out of an NES game. The graphics are not terrible, but the stages are largely very bland. The Batman sprite isn't bad, but the enemies lack detail. The mode 7 backgrounds in shooter levels look nice, and even with a lot of sprites in the screen, there is no slowdown.

On the whole, this game would have served as an example of how not to do an action shooter. The stages are relatively short, but for the most part can only passed through sheer memorization. The boss battles are tedious and have no strategy to avoid damage, essentially forcing you to beat the enemy by brute force. Several of the weapon "powerups" (in particular the spread gun and ricochet gun) are pretty much useless because they don't allow you to fire more than one shot at a time. The jump button is quite often unresponsive, causing death in situations where quick jumping is required. There is a special move (when you press A) that causes you to spew dozens of your weapon shots around you, but considering that the most troublesome enemies are airborne, it is quite useless. Many of the obstacles (in particular the tornadoes emitted by the enemies in level 5) take off far too much of your health. The two shooter stages seem tacked on and offer none of the strategy you would find in games like Gradius III. This game is very difficult, mostly due to gameplay design flaws. After playing through, it seems pretty evident why this game was not released.

Comparison with the NES and Genesis versions

One interesting thing to note about this game is that it is actually a remake of the NES game, Return of the Joker. It was supposed to be a sequel of sorts to the 1989 Batman movie. The NES version of the game is regarded as one of the most graphically impressive games for the system (getting a 4.2/5 in Nintendo Power). On the whole, the NES version of this game is better in every respect to the unreleased SNES version. The controls are more responsive, the weapon upgrades don't cripple you, even the graphics are arguably more detailed. The music is pretty much the same between the two games.

Imagen Imagen

Imagen Imagen

The Genesis version of Revenge of the Joker was programmed by a completely different group than the SNES version. The game is more similar to the NES version than the SNES version, both graphically and gameplay-wise. However, out of the three, the Genesis version has to be the worst. At least in the SNES version, I could pass the levels with enough tries. With the Genesis version, I got to the second level (with the blimp) and nearly threw my controller in frustration. In that particular level, the bombs thrown from the blimp come down two at a time, and they drop so quickly that it becomes a matter of luck to avoid them. The controls seem more awkward than the NES version. For a 16-bit game, the graphics are pretty poor too. Really, if I was to recommend one version of this game, I would definitely go with the NES version, which is actually a really good game.

Imagen Imagen


Bibliography

    · Nintendo Power, Information on the NES version of the game, Publication date: December 1991, Volume: 31, Pages: 8-17,87
    · Nintendo Power, Summer CES Special, Publication date: August 1992, Volume: 39, Pages: 58-61
    · Review on VGMuseum (link)
    · Review of the Genesis version on Sega-16 (link)


Beast Ball
Beast Ball was listed in the November 1993 issue of Nintendo Power in a coming soon list of sports games. Beyond that, I have no information on it, as it doesn't even list the publisher. I can only speculate if the game was released as another title.

Bibliography

    · Nintendo Power, The Sports Scene (upcoming releases list), Publication date: November 1993, Volume: 54, Pages: 18


Blaster Master 2
Blaster Master 2 was reported as being in development for the Super NES in the March 1992 issue of Nintendo Power. The game was also mentioned in August 1992 issue of Nintendo Power, but they stated that it was not close to completion. The game was released on the Genesis, and was reportedly very lackluster, so it is just as well it didn't come out.

Rene Boutin, a game producer at Sunsoft states that Blaster Master 2 was never in development for the Snes.

Bibliography

    · Nintendo Power, Pak Watch - CES Special, Publication date: March 1992, Volume: 34, Pages: 112-113
    · Nintendo Power, Summer CES Special, Publication date: August 1992, Volume: 39, Pages: 58-61


Bobby's World
This game is still under debate whether it was released or not. The game was competed, there is no doubt about it, and the rom image was dumped. The game was being released by a company called Hi Tech. It was being planned for release in early 1995.

This game is based on the Howie Mandell cartoon of the same name. The story is that Bobby has to clean his room, and he has daydreams when he starts cleaning certain parts of his room. I decided to play this game until I got bored, and I ended up passing it, so here is a full review.

Graphics: 6/10

The graphics are ok, nothing that hasn't been seen on other snes games. The characters probably could have had more frames of animation, but there is a wide range of stages and enemies.

Sound: 5/10

Pretty bland. The music won't drive you crazy, but it is nothing special. The sound effects are also pretty plain, just appropriate, nothing more.

Controls: 4/10

The controls aren't that great. Bobby moves very slowly, and doesn't automatically respond to button presses. However, this game is easy enough that it isn't that big of a deal, until you get to this point:

Imagen

At this spot, you must swing from these three logs. This is the hardest part of the game, only because of the controls. I died maybe 3 times in this game, except for this point, where I died around 20 times (luckily I got pissed off after the first few deaths and used savestates). Nothing is more evil that deaths caused by poor controls.

Overall Score: 4/10

I played this game for about 40 minutes and I passed it. If it weren't for that stupid spot aforementioned above, this game offers little challenge. Part of the problem is that there were life power ups usually placed just in the spot where you are near death. It is nice that there is a bit of variety (every third stage or so it changes from a side scroller to a shooter type of game), but it was certainly made with children in mind. There were 3 bosses, but they were easily vanquished by staying in the top corner where they couldn't hit you (they all moved in the same pattern). I don't know if this would even satisfy fans of the show (if they exist). But any game that lasts only 40 minutes with no replay value doesn't really warrant release, and in this case, it seems that it didn't.

Serial Code:

SNS-ABWE-USA

Here is a box shot found at half.com:

Imagen


More pictures:

Imagen Imagen Imagen

Imagen Imagen Imagen

Imagen Imagen Imagen

Imagen Imagen Imagen

Imagen Imagen Imagen

Imagen Imagen Imagen

Imagen Imagen Imagen


Boo!
Boo! was a unreleased game that was planned for release on the SNES, Genesis and Amiga computers. It was a Mario/Sonic-style platform game.

Imagen

Boo! was in development by Micropose, a British company known for such games as Civilization and Railroad Tycoon. During the waning stages of the 16-bit era, Micropose had financial problems, which led to the cancellation of several titles, including Boo! The Amiga and Genesis versions were to be released only after the SNES version was complete. The game was designed by Richard Lemarchand.

Stuart Whyte, who was the producer of Boo!, created a webpage with information on the game. The game was far enough along that it was previewed and was the cover feature of the February 1995 issue of European Amiga gaming magazine, One Amiga. I emailed Stuart Whyte years ago (yes, this has been in the backburner for a while):

Imagen

"Status: 80% complete. Developed by the Conversion Company (based in Whitby) and with art from Keith Scoble (creator of Danger Mouse, Jamie and the Magic Torch and one of the key members of Cosgrove Hall) Boo was a game about a teenage kid who dies and becomes a ghost who’s method of attack is to shout Boo! at the enemies."

According to the Amiga article, the main protagonists are the titular character Boo, a ghost boy with a baseball hat, and his friend Stupendo the Fabtastic, a wizard. The two characters lived happily until the enemy from the planet Pasturyzd invades, using Stupendo's house as an entry point. The main enmies are "Moo-tants", a race of evil cows. Stages took place in various parts of the house, including a hall, kitchen, study, bathroom, gardens. The final two stages are Limbo and the planet Pasturyz. For the most part, the gameplay was a standard side-scrolling platform game, though you were periodically allowed to take control of some other characters, such as a Frankenstein monster and a vampire. An apparent influence on this game was Zelda II.

Imagen

According to a development document for the Amiga version, Micropose intended for the game to be completed for August 1994 and strived for a high quality game (review scores greater than 85%). The graphics for the SNES version of the game were by Keith Scoble (who did the initial graphics scetches) and the Conversion Company. Keith Scoble was one of the primary animators for the show Danger Mouse (a show that I'll admit frightened me as a child). The music and sound were done by Alistair Brimble (who worked on another unreleased Micropose SNES game, Impossible Mission). Interestingly, they state in the document that they needed sales of about 16,500 to break even on the game, though there goal was 111,000.

Imagen

On Stuart Whyte's webpage on the game, there is a collection of images from the game. Most of these were in an archaic format for Electronic Arts' Deluxe Paint. The images themselves seem to be from early versions of the game, and the article in the Amiga One magazine shows that the game was much further along and had gameplay already implemented. I managed to convert these files into PNG and animated GIF files. Enjoy!

Sprites:

Imagen Imagen

Imagen Imagen

Imagen Imagen


Various cinemas:

Imagen Imagen

Imagen Imagen

Imagen Imagen

Imagen Imagen


Converted animated files - note that many have no actual animation.


Imagen Imagen

Imagen Imagen

Imagen Imagen


Bibliography

    · Amiga One, Preview of the game (also was on the cover of the magazine), Publication date: February 1995, Volume: -, Pages: 20-22
    · Stuart Whyte's CV (link)
    · Stuart Whyte's page on Boo! (link)
    · Orchestral Media, a company that is co-owned by Allister Brimble, who did the sound for Boo! (link)


Bulls Vs. Lakers
Bulls Vs. Lakers was shown at the Winter CES in 1992 by Electronic Arts. The game came out on the Genesis, but development must have been too slow, and it was canned in favour of focusing on the next instalment of the series. Embarrassingly for Nintendo, they were going to give away this game as a prize in the November 1991 issue of Nintendo Power.

Bibliography:

    · Nintendo Power, Player's Poll Contest (given away as a prize), Publication date: November 1991, Volume: 30, Pages: 82-83
    · Nintendo Power, Pak Watch - CES Special, Publication date: March 1992, Volume: 34, Pages: 112-113




Fuente: SNEScentral & Google






ImagenVolver a la página principal.
Ralph a que te refieres a juegos cancelados?
Che_Guevara escribió:Ralph a que te refieres a juegos cancelados?

Que estaban en desarrollo pero que nunca llegaron a salir a la venta.Aunque algunos juegos cancelados fueron liberados y es posible jugarlos
ryo hazuki escribió:
Che_Guevara escribió:Ralph a que te refieres a juegos cancelados?

Que estaban en desarrollo pero que nunca llegaron a salir a la venta.Aunque algunos juegos cancelados fueron liberados y es posible jugarlos



Lo digo mas bien por el Asterix que lo he visto muchas veces por Ebay en venta y alguna vez el Bulls vs Lakers.
El Asterix podria haber sido cualquier otra version y el bulls vs lakers, conozco el de Mega drive, pero el de SNES no me suena haberlo visto nunca
Por cierto,tiene muy buena pinta el Batman: Revenge of the Joker que pena que no salio en venta,aunque en la primera fase lo veo mas parecido a los graficos de NES.

Menos mal que no sacaron el otro Batman (Software Creations) chiquita bazofia.
(mensaje borrado)
El Astérix creo que lo hemos visto todos en nuestras SNES, de hecho yo lo he jugado y tengo la ROM, ya que es de los pocos juegos de SNES creados por un grupo de programación español.
Lo que pasa es que está en esa lista porque fue cancelado el lanzamiento en USA y claro, tampoco salió en Japón...
magno escribió:El Astérix creo que lo hemos visto todos en nuestras SNES, de hecho yo lo he jugado y tengo la ROM, ya que es de los pocos juegos de SNES creados por un grupo de programación español.
Lo que pasa es que está en esa lista porque fue cancelado el lanzamiento en USA y claro, tampoco salió en Japón...

No estoy seguro, pero creo que el Asterix de super nes no es de Bit managers, sino el Obelix. El que sí es de ellos es la versión de Game Boy ( y creo que tb la de nes)

Vale, acabo de mirar y, efectivamente, el Asterix de Super no está entre los juegos que han hecho ( pero sí el Obelix):

http://es.wikipedia.org/wiki/Bit_Managers
Sí, tienes razón, era el "Astérix & Obélix" el que hicieron los españoles, pero también distribuido por Infogrames. De todas formas, me imagino que éste correría la misma suerte que aquél y ninguno de los dos fueron lanzados fuera de Europa.

Por cierto... ¿Tintín en el Tíbet para SNES no era de BitManagers también? Es que en esa lista no sale...
Como curiosidad está el 7th guest, pero el que mas me llama la atención es el akira... creoq eu todos recordamos alguna fotillo en la hobby, pero con mas calidad. No he visto nada mas decente por internet.


ryo hazuki escribió:
Che_Guevara escribió:Ralph a que te refieres a juegos cancelados?

Que estaban en desarrollo pero que nunca llegaron a salir a la venta.Aunque algunos juegos cancelados fueron liberados y es posible jugarlos


Si, hubiera estado bien incluir los links, pero en algunos casos no se sabe bien si están liberados, así que mejor curarse en salud, y quitarlos todos. Si alguien desea el juego, solo tiene que usar el google.

Che_Guevara escribió:Lo digo mas bien por el Asterix que lo he visto muchas veces por Ebay en venta y alguna vez el Bulls vs Lakers.


Será para la megadrive solamente... o si acaso para la genesis (si es que no salió en europa).

ryo hazuki escribió:El Asterix podria haber sido cualquier otra version y el bulls vs lakers, conozco el de Mega drive, pero el de SNES no me suena haberlo visto nunca


Si, eso pone, que el desarrollo se canceló porque estaba siendo demasiado lento, y decidieron concentrarse en futuras series del juego.

magno escribió:El Astérix creo que lo hemos visto todos en nuestras SNES, de hecho yo lo he jugado y tengo la ROM, ya que es de los pocos juegos de SNES creados por un grupo de programación español.
Lo que pasa es que está en esa lista porque fue cancelado el lanzamiento en USA y claro, tampoco salió en Japón...


Exacto :)

...No me he molestado en traducir o adaptar, porque en total son un montón de juegos, pero en los textos viene todo:

Serial Code: SNS-XE-USA


I believe the reason that Asterix was unreleased on the SNES was as follows. There was also an Asterix game on the NES, as well as a few Smurfs titles. Both of these cartoon characters are much more popular in Europe, and the games never made it over to the US
A ver que me lio,este juego no salio a la venta?¿

Imagen
Che_Guevara escribió:A ver que me lio,este juego no salio a la venta?¿

Imagen

Ese juego sí que salió a la venta que yo sepa. Supongo que será otra versión la que se canceló.
Che_Guevara escribió:A ver que me lio,este juego no salio a la venta?¿

Imagen


Sí salió en europa pero como ha dicho magno se canceló en usa , en el enlace que ha puesto ralph dice que se supone que una de las razones era porque en Europa Asterix sí era muy conocido al igual que los pitufos y en el otro lado del charco como que no.
ImagenVolver a la página principal.




GUÍA DE ASM

Capítulo 1: Elementos Básicos de la SNES





Introducción

Esta guía la había estado pensando hacer desde hace mucho tiempo. Si no es por Magno que me ha ayudado en todo, no hubiese sido posible hacerla. Lo mismo que a Jonas. ¡Gracias a los dos!

En este primer capítulo se estudiarán los elementos básicos de la SNES. Pero partamos con una pregunta básica:


¿Qué es el 65816?

Es un microprocesador hecho por Western Design, el cual es básicamente una actualización de 16 bits del conocido microprocesador 6502 (usado en la NES y en las viejas computadoras como el Commodore 64, etc.) y se usa en los sistemas Apple IIgs.
El 65816 es el usado por la SNES/Super Famicom. El procesador tiene registros internos de 16 bits y bus de datos de 8 bits.


¿Que es la Super Famicom?

Es la versión japonesa de la SNES (Super Nintendo Entertainment System) americana. El hardware en sí es el mismo y los cartuchos de SF (con una pequeña modificación externa) se pueden jugar en la SNES y viceversa. Lo que las diferencia principalmente es la apariencia.


Elementos Básicos de la SNES

Dentro de la SNES tenemos los siguientes componentes:

# Una CPU con Registros Internos:

    -A: Acumulador
    -X: Índice X
    -Y: Índice Y
    -D: Registro de Página Directa
    -S: Stack Register (Registro de Pila)
    -PBR: Program Bank Register (Banco de Programa)
    -DBR: Data Bank Register (Banco de Programa)
    -PC: Contador de Programa
    -P: Status Register (Registro de Banderas/Registro de Estado)

# Una Memoria que se subdivide en:

    1. Memoria ROM: aquí esta el código del juego, y los datos iniciales como Tiles (comprimidas o no), música, fonts, etc.
    2. Memoria RAM: aquí se guardan datos temporales como tiles o fonts que se descomprimen en tiempo de ejecución (runtime) si la rom esta comprimida.
    3. Memoria de Video o VRAM: se usa para mostrar en pantalla las tiles, font, maps, sprites, etc.

NOTA: El orden 1,2,3 es el que siguen los datos para ser mostrados en pantalla.

# Registros Externos al Procesador: Son puertos mapeados de memoria fijos de Entrada/Salida usados para enviar datos al PPU. Estos registros están asociados a ciertos bancos y direcciones, es decir, de cierta dirección de la memoria principal a otra. Por ejemplo: El registro de los controles o joypad ocupa de la dirección $4000 a la $41FF.

Los registros externos son:
    -Registros OAM (Object Attribute Memory): Información de sprites en la pantalla; elige una ubicación en VRAM donde el carácter y la medida de los sprites en la pantalla son guardados.
    -Registros de Color.
    -Registros de Transferencia/Dirección de VRAM.
    -Registros de Video: Controla el tamaño de los tiles de background.
    -Registros Contadores/IRQ/VBL/NMI.
    -Registros Windowing: Usados para cortar porciones de pantalla, por ejemplo en el Mario World cuando aparece el círculo de entrada al empezar a jugar.
    -Registros de Joypad/Joystick: Ocupados para manejar los controles, setear número de ellos y los botones.
    -Registros DMA (Direct Memory Access): usados para copiar datos como tiles, de ROM a la VRAM (la pantalla) de forma "rápida" sin pasar por RAM.

NOTA: Por ahora no hay que entender estos complicados registros, los explicaré en su debido momento.


Registros Internos: A, X/Y y P

Estos 4 registros son los esenciales para trabajar con asm al hackear una rom.


A: Registro Acumulador

Es el acumulador se usa para cálculo y almacenamiento general. El acumulador puede estar en modo de 8 ó 16 bits. Si está en 8 bits -1 byte-, sólo puede contener valores de 0 a 255 (00 a FF hex) y en 16 bits -2 bytes- valores de 0 a 65535 (0000 a FFFF hex).

Para saber si el acumulador está en 8 o en 16 bits, hay que chequear el bit nº 5 o "m" del registro de banderas P (este registro se verá con más detalle en otro capítulo). Si el bit 5 llamado m está seteado (es decir m = 1), el acumulador está en 8 bits y si el bit 5 está re-seteado (m = 0) el acumulador está en 16 bits.

Ejemplos:
LDA #$AC ; carga A con el valor AC hex. Los valores en ASM SNES se escriben con #$VALOR.
LDA #$25 ; carga A con el valor 25 hex.
LDA $1234 ; carga A con el valor que se encuentre dentro de la dirección $1234. Las direcciones en ASM SNES se escriben con $DIRECCION.
STA $0ABC ; mete lo de A dentro de la dirección $0ABC.


X,Y: Registros Índices

Los registros X y Y están asociados al acumulador. Puedes guardar valores dentro de estos registros y luego realizar operaciones matemáticas.
Estos registros son usados para indexar localizaciones de memoria. ¿Cómo es eso? Si se quiere leer de una dirección de memoria y de allí para abajo (se desea recorrer para revisar cada contenido), se necesita un índice que se vaya aumentando. Es como recorrer un arreglo (si no saben que es un arreglo, revisen documentación de casi cualquier lenguaje de alto nivel como C/C++/PHP/VB6 o vena en google algún manual) .

Estos dos registros también pueden ser de 8 ó 16 bits, dependiendo del flag (bandera) X del registro P. Si X = 1, entonces los registros (X y Y) estarán en modo de 8 bits. Si X = 0, están en 16 bits.

LDX #$AC ; carga X con el valor AC hex.
LDY #$20 ; carga Y con el valor 20 hex.
LDY $10 ; carga en Y lo que hay en la dirección $10.
LDA $1234, Y ; caso típico del uso del índice Y, ya que con esto cargamos en A lo que haya en la dirección $1234+Y, si Y vale 8 por ejemplo, cargamos en A lo que haya en $1234+$8 = $123C.


Sacando Datos de la Memoria

El acumulador o los índices se pueden llenar con valores de alguna dirección. Por ejemplo:

LDA $30 ; carga el acumulador con el valor que está dentro de la dirección 30 hex (las direcciones de la SNES siempre están en hexadecimal, así que de ahora en adelante, si hablo de dirección, es en HEX).

LDX $4A ; carga X con el valor que está dentro de la dirección $4A.


Introduciendo Datos a la Memoria

Se puede llenar una casilla de memoria con los valores del acumulador o de los índices.

STA $3AFF ; guarda lo que está en A en la dirección 3AFF.
STY $05C0 ; guarda lo que está en Y en la dirección 05C0.
STX $BB ; guarda lo que está en X en la dirección 00BB.


Registro de Banderas P

El registro P es de 8 bits, cada bit representa un Flag (un bit con valor 1 o 0) o Banderas de Estado de la Snes:

Imagen

    n: Negative (Negativo)
    v: Overflow (Bit de Desbordamiento)
    m: Memory/Accumulator Select (Bit Acumulador)
    x: Index Register select (Bit de Registros índices X e Y)
    d: Decimal
    i: Interrupt(Bit de la Máscara de Interrupción)
    z: Zero (Bit Cero)
    c: Carry (Bit de Acarreo)
    e: Emulation (Emulación)


n: Negative (Negativo)

Se pone a 1 si el resultado de la última operación aritmética, lógica o de manipulación de bits fue negativo.

Ejemplo:
LDY #$0002 ; se carga Y con 0x0002
DEY ;Y=0001
DEY ;Y=0000 -> solo para saber, aquí Z pasa a 1 ya que Y llegó a 0.
DEY ;Y=FFFF -> aquí N pasa a 1, ya que si al 0 le restamos 1 nos da...FFFF pero se activa N.


v: Overflow (Bit de Desbordamiento)

Es parecido al de Acarreo pero actúa con números en complemento a dos y se activa cuando se pasa del mayor numero (el +127 en 1 byte) al menor (-127 en 1 byte).


m: Memory/Accumulator Select (Bit Acumulador)

Este bit deja el Acumulador en 8 o 16 bits. Si este bit esta seteado (es decir m = 1) el acumulador esta en 8 bit y si el bit 5 esta re-seteado (m = 0) el acumulador está en 16 bit. Para dejar solo el acumulador en modo de 8-bits usa SEP #$20.

Esto es así ya que ya que 20 hex es igual a 00100000 en binario y si comparamos 00100000 con el Registro de Flag queda:

00100000
nvmxdizc, es decir m = 1

En resumen:
Para dejar solo el acumulador en modo de 8 bits usa SEP #$20.
Para dejar solo el acumulador en modo de 16 bits usa REP #$20.
Para dejar el registro X/Y y A en modo de 8 bits usa: SEP #$30
Para dejar el registro X/Y y A en modo de 16 bits usa: REP #$30

Entonces lo correcto al hacer un LDA #$1234, es hacer justo antes un REP #$20.
Lo mismo si se quiere hacer un LDA #$05 es hacer antes un SEP #$20.


x: Index Register select (Bit de Registros índices X e Y)

Este bit deja permite dejar los registros X e Y en 8 o 16 bits.

Para dejar el registro X/Y en modo de 8 bits usa SEP #$10.
Para dejar el registro X/Y en modo de 16 bits usa REP #$10.
Para dejar el registro X/Y y A en modo de 8 bits usa: SEP #$30.
Para dejar el registro X/Y y A en modo de 16 bits usa: REP #$30.

Explicación de porque ese "10":
REP #$10 ; 10 hex = 10000 bin = bit 5 (X) índices X/Y en modo 16 bit.
SEP #$10 ; 10 hex = 10000 bin = bit 5 (X) índices X/Y en modo 8 bit.


d: Decimal

Permite setear el uso de valores decimales en vez de hexadecimales. Por defecto esta en 0, es decir en modo Hexadecimal:
d=0 => Modo Hexadecimal
d=1 => Modo Decimal


i: Interrupt (Bit de la Máscara de Interrupción)

La máscara de interrupción I se pone a 1 mediante hardware o software para deshabilitar (enmascarar) todas las posibles fuentes de interrupción, tanto exteriores como interiores.


z: Zero (Bit Cero)

Se pone a 1 si el resultado de la última operación aritmética, lógica o de manipulación de bits fue nulo (cero).

Ejemplo 1:
LDA #$0000 ; esto hace que Z pase a 1.
LDX #$0000 ; esto hace que Z pase a 1.

Ejemplo 2:

LDY #$0002 ; se carga Y con 0x0002
DEY ;Y=1
DEY ;Y=0 -> aquí Z pasa a 1


c: Carry (Bit de Acarreo)

Hay veces en que una operación hace que un número se desborde y esto se debe registrar de alguna forma. Cuando un número se desborda el flag de acarreo se pone a 1. El carry puede afectar a algunas operaciones de Suma y Resta, es decir, no afecta a las operaciones de INC y DEC, en cambio si a las de ADC y SBC.

Para dejar el Carry en 0 se usa la instrucción CLC.
Para dejar el Carry en 1 se usa la instrucción SEC.

¿Pero para que dejar el Carry en 1 o en 0?
Bueno, aunque esto lo veremos en capítulo 3 y 4, diré que si queremos hacer esta operación matemática: X = A+4, en verdad es un seudo-código que representa la suma de registros. Donde A es el acumulador con valor inicial 2 y X es el registro X vacío.
Entonces haremos esto:

ADC #$04 ;sumamos el valor 0x4 a A, aquí el Operando es 0x4
TAX ; transferimos(copiamos) lo de A hacia X, supuestamente tendríamos que X = A = 2 + 4 = 6, X vale 6 hex.
Pero aquí hay algo mal ya que ADC es "add with carry", es decir "Sumar con Carry", en otras palabras la "fórmula" para ADC es:

ADC Operando => A = A + Operand + Carry

Entonces el Carry AFECTA la Suma, ¿se dan cuenta? A ver, asumamos que el carry esta en 1, entonces si hacemos la misma operación que antes:

ADC #$04
TAX

¿Cómo queda A finalmente?
La respuesta es A = 4 + 2 +1 = 7, entonces X = 7. ¿se dan cuenta ahora como afecta a la suma?
Entonces lo que hay que hacer es dejar el carry en 0 ANTES de la suma, entonces vemos como quedaría:

CLC
ADC #$04
TAX

¡Listo! Así nos queda la operación X = A + 4.

También el Carry afecta a la Resta y su "fórmula" es:

SBC Operando => A = A – Operand + Carry – 1

Entonces ustedes pueden ver como se escribiría esta operación: X = A – 3.

Sigamos adelante entonces.


e: Emulation (Bit de Emulación)

Si E = 1, entonces el procesador esta en modo de Emulación 6502 (emula el procesador de NES), Pero si esta en E = 0 el procesador esta en modo Nativo, es decir, en modo SNES.

Para cambiar a Modo Nativo (E=0) hay que hacer:
CLC ; limpia el flag de acarreo a 0.
XCE ; intercambia el bit de emulación con el de acarreo.

Para cambiar a Modo de Emulación (E=1):
SEC ; bit de acarreo en 1.
XCE ; intercambia el bit de emulación con el de acarreo


Memoria

La memoria es la encargada de almacenar:

# Conjunto de instrucciones: Aquí está el código del juego, donde se puede hackear --> Usamos Memoria ROM.
# Datos fijos que se usan en el juego, como tiles, sonidos --> Usamos Memoria ROM.
# Datos temporales que usa el juego, como tiles, trozos de código que descomprime, etc. --> Usamos la RAM.
# Datos finales, listos para ser mostrados en pantalla --> Usamos memoria VRAM.

La memoria RAM (Random Access Memory, Memoria de Acceso Aleatorio) almacena los datos a procesar. Generalmente es un tipo de memoria volátil (su contenido se pierde cuando se apaga la computadora o la consola en nuestro caso), pero depende del tipo de memoria RAM.

La memoria RAM en la SNES se subdivide en:

# WRAM (Working RAM) de 124 KBytes, que es la misma RAM interna de la SNES. Es la que importa, ya que la WRAM se compone de 3 Sub-RAMs que son: LowRAM, HighRAM y Expanded RAM. Estas tres RAMs nos guardarán los datos temporalmente al momento de extraer un texto comprimido, por ejemplo.

# VRAM (Video RAM) de 64 KBytes, que es la memoria de video que se accede por los registros y es encargada de mostrar los gràficos finales en pantalla.

# SRAM (Save RAM) de 526 o 512 KBytes, que es la memoria estática que está dentro de un cartucho de SNES; tiene el tamaño un poco mayor que una pila de esas de botón. En ella es en donde se guarda una copia de la RAM en el momento que se salva la partida jugando con una SNES real. Es más o menos como los archivos que contienen las partidas guardadas (no SaveStates) de los emuladores. El contenido de la SRAM no se pierde al apagar la consola, debido a que se encuentra en el cartucho mismo.
Cuando abres un juego con cualquier emulador, se crea un archivo .srm con el mismo nombre del archivo de la ROM y que contiene lo mismo que contendrá esa memoria RAM de un cartucho de SNES. En realidad se presenta sólo en juegos que tienen opciones para continuar, al estilo de los RPG y ZELDAs. Cuando salvas (usando SaveStates con ZSNES), te queda un archivo .zst, puesto que estos mantienen la copia EXACTA de los dos bancos de RAM y de toda la VRAM en el momento de guardar.

La memoria ROM (Read Only Memory, Memoria de Sólo Lectura) es una memoria permanente en la que no se puede escribir (viene pregrabada por el fabricante de juegos). Los programas almacenados aquí no se pierden al apagar la consola y tampoco se pueden modificar mientras ésta (la consola) está corriendo. Esta es memoria no volátil.
Los únicos que modificamos la ROM somo nosotros, los romhackers :)
La memoria principal la representaremos como un conjunto de direcciones hexadecimales donde cada dirección tiene un dato asociado.


Imagen



En la imagen se ve un modelo típico y muy básico de una Memoria de SNES. Se ve una dirección que está compuesta por un BANCO y la DIRECCIÓN. Al conjunto Banco:Dirección se le conoce como Offset. El banco parte de 00 hasta FF y la dirección de 0000 hasta FFFF.

Abajo se muestra un diagrama más concreto sobre la memoria:

Imagen


En la memoria principal se encuentra la ROM y RAM. Estas direcciones varían si la ROM es LoROM (LowROM) o HiROM(HighROM). Las LoRom fueron pensadas para juegos livianos, con poca data y las HiRom fueron hechas para rom con mucha data como algunos RPGs.
Todas las ROMs que conocemos están dentro de uno de estos 2 grupos. Las LoROM son más livianas, ya que contienen menos información.
Cada banco en LoROM es de 32 KB, y en HiROM es de 64 KB.
Como dije más arriba, en la memoria ROM se escribe el código o programa principal de una ROM, es decir que una ROM (un juego cualquiera .smc, .fig, etc.), es la copia exacta del chip ROM de un cartucho de SNES (en este caso). En la RAM se guardan sólo datos temporales. La RAM, como los Registros Internos y Externos, los provee la arquitectura de la SNES, no están dentro del cartucho.





Mapa de Memoria

Es una tabla donde se indican los bancos y direcciones de RAM, ROM y Registros Externos. Hay varios documentos en inglés en Zophar's Domain; recomiendo ver uno llamado "SNESMem.txt" hecho por ]SiMKiN[. Sólo pondré aquí lo más importante por ahora, las direcciones de RAM y ROM para una HiROM y LoROM:


Imagen

Imagen


Estos bancos están definidos por la arquitectura de la SNES, no los inventé porque si. Y como dije, es una versión muy simplificada de un mapa que está en Zophar's Domain. Lo que importa es que sepas cómo se "ve" en la memoria la RAM y ROM para entender cuando yo explique algo así: "según esta dirección se accede a la RAM..." o "sacamos este dato de la ROM".





Preguntas y Respuestas

    1. Si tenemos la instrucción LDA $7EB200, ¿de dónde sacamos datos?
    R: De la RAM, ya que tenemos 7E:B200, y 7E es la dirección de la RAM.

    2. Si tenemos la instrucción STA $CC0150, ¿dónde lo almacenamos?
    R: En la ROM, pero la memoria ROM varía de posición dependiendo de si es HiROM o LoROM, en este caso la dirección es $0150 y la LoROM no accede en direcciones menores de $8000, sólo desde $8000 a $FFFF para cada banco, por lo que STA $CC0150 lo que hace es almacenar el dato del acumulador en la ROM de una HiROM.

    3. ¿En un programa real es posible hacer STA $1234?
    R: Depende, ya que no se sabe el banco, si fuera un banco de la ROM, como por ejemplo el banco 01: STA $011234, NO seria posible ya que en la ROM no es posible escribir. Pero si fuera un banco de la RAM, como 7E: STA $7E1234, SI sería posible ya que aquí si es posible escribir.



Fuente: darkn.romhackhispano.org




ImagenVolver a la página principal.
Con toda la información que hay en este hilo se puede hacer un libro
Ralph escribió:2. Si tenemos la instrucción STA $CC0150, ¿dónde lo almacenamos?
R: En la ROM, pero la memoria ROM varía de posición dependiendo de si es HiROM o LoROM, en este caso la dirección es $0150 y la LoROM no accede en direcciones menores de $8000, sólo desde $8000 a $FFFF para cada banco, por lo que STA $CC0150 lo que hace es almacenar el dato del acumulador en la ROM de una HiROM.



No es cierto... mira que se lo dije veces a Dark-N y el tío erre que erre... En un caso MUY excepcional es posible que se pueda escribir en la dirección de memoria $CC:0150, pero lo que sí que no es posible nunca es que sea en ROM; en todo caso es en la S-RAM del cartucho. Y realmente, si el cartucho es HiROM, todos los bloques $C0 hasta $FF son para la ROM, por lo que el decodificador de direcciones del cartucho siempre activaría los chips de ROM en este caso y no el de RAM. En los HiROM, la RAM suele ir en $B0, aunque puede ir en cualquier banco entre $80 y $BF.


Ralph escribió:3. ¿En un programa real es posible hacer STA $1234?
R: Depende, ya que no se sabe el banco, si fuera un banco de la ROM, como por ejemplo el banco 01: STA $011234, NO seria posible ya que en la ROM no es posible escribir. Pero si fuera un banco de la RAM, como 7E: STA $7E1234, SI sería posible ya que aquí si es posible escribir.[/list]


Esto también es cierto a medias (y aquí el jodío SÍ dice que en ROM no se puede escribir!!!!). Realmente SIEMPRE hay un banco definido en el registro de banco de datos de la CPU, por lo que esa instrucción SIEMPRE se podría ejecutar, aunque el resultado válido o no de ella depende de lo que haya escrito en el registro de banco de datos: si es $CF por ejemplo, no hará nada, mientras que si es $7E, ó $00 escribirá en el primer banco de RAM de la CPU, y si es $B0, escribirá en la S-RAM del cartucho...
Yo no llego a comprenderlo muchas cosas todavía, magno, pero la verdad es que de momento he preferido mantenerlo intacto tal cual estaba en su transcripción original, aunque eso si, lo he incluido como un post "propio" con toda la intención, por si hace falta editar/añadir cosas. Lleva mas curro, porque hay que adaptarlo todo, pero si hay fallos o cosas que añadir, puedo editarlo yo mismo.

Sinceramente, a las preguntas no las he hecho ni caso. No hasta que no me empape bien de los contenidos... de momento, pillo bien algunos conceptos, pero otros no. Me da la impresión de que las direcciones de memoria te las aprendes como antaño uno se aprendía las lecciones de historia (a base de leer, y sin aprender realmente).


...en fin, a ver si el hilo se desatasca un poco, que quiero quitarme de encima todo lo que tengo guardado.


Only16bits escribió:Con toda la información que hay en este hilo se puede hacer un libro


La verdadera intención de este hilo es guardar todo el contenido en html, o en su defecto, en PDF (pero mejor en HTML, y aprovechar los hypervinculos). Queda mucho todavía por delante :)

...además, hay partes que usan la función "code", por lo que guardando la pagina en PDF pierdes contenido.
La verdadera intención de este hilo es guardar todo el contenido en html, o en su defecto, en PDF (pero mejor en HTML, y aprovechar los hypervinculos). Queda mucho todavía por delante :)

...además, hay partes que usan la función "code", por lo que guardando la pagina en PDF pierdes contenido.


sería un lujazo pero mucho de la información al usuario medio (como yo) sirve solo para que ponga la cara de [comor?] [comor?] [comor?] perop igual esta mas que bien.

Por cierto a ver si algún rato de estos se publica un tutorial de como crear tu propio cartucho de snes con juegos al estilo del hilo de reproducciones. [sonrisa] [sonrisa] [sonrisa]
vaya peazo hilo, me adhiero para nuevas reviews.
Alguien se podria currar una review del Secret of mana... [sonrisa]

salu2
ImagenVolver a la página principal.


SPRITES EN SNES





INTRODUCCIÓN Y EL POR QUÉ DE ESTE TUTORIAL.
En primer lugar, escribo este tutorial porque no he visto ningún documento hasta la fecha que explique adecuadamente como usar sprites en la SNES, ni en español, ni en ingles. Y a mi me ha dado bastante dolores de cabeza lograr usarlos. Hay varios documentos técnicos sobre la SNES muy buenos por internet, como los de Yoshi, pero por ejemplo, este hombre explica a menudo las cosas de una forma muy poco clara. En definitiva, hay temas, como el de los sprites, donde la información está esparcida y a veces es oscura y ambigua.
Mi objetivo es explicar con detalle y suficiente claridad, el uso sencillo de sprites en la SNES, desde cero y ordenadamente.


¿A QUIÉN VA DIRIGIDO?
A todo aquel que quiera usar sprites en la SNES, y por supuesto que sepa programar y tenga nociones de ensamblador, aunque no sea de ensamblador de la SNES. También se da por sabido conceptos como tile, bitplanes, o WRAM ;)
Ah, y también saber qué es un registro y como usarlos.
(ver otros tutoriales míos).


¿QUÉ SON LOS SPRITES?
Creo que esto sobra, pero bueno, hagamos las cosas bien. En un juego, por una parte, están los escenarios, las plataformas, etc. Que forman parte de los planos de scroll, constituidos por tiles, y que sirven para representar los niveles, los mapas, o lo que sea, en definitiva, el mundo que se representa en el juego.
Y por otra parte están los sprites, que son los objetos móviles que “viven” en ese mundo, tanto los enemigos, como el propio personaje que controla el jugador, o los ítems. En definitiva, los sprites son los objetos que interactúan en los juegos.

Por lo tanto es imprescindible saber usarlos, a no ser que queramos limitarnos a programar demos con fondos, imágenes, texto, y sin acción. Para quien tenga experiencia en programación de la NES, resultará sencillo usarlos en la SNES, aunque aquí la cosa se complica mucho. Yo empezaré a explicarlo todo suponiendo que el lector no tiene esta experiencia previa.


LA TABLA DE SPRITES (OAM)
Los sprites en SNES se llaman objetos o OAM.
Para manejarlos, la SNES tiene una zona de memoria llamada tabla OAM donde guarda información sobre todos los sprites. En esta tabla caben 128 sprites, y por lo tanto la SNES puede manejar un máximo de 128 sprites a la vez, aunque seguramente en la practica se ralentice si se usan tantos. Aún así esto supone una mejora, porque la NES sólo podía manejar 64.
Lo que tenemos que hacer es introducir los datos de los sprites en esta tabla. Cada sprite ocupa 4 bytes.

Byte 1 : xxxxxxxx Posición X del sprite en la pantalla (0-255)
Byte 2 : yyyyyyyy Posición Y del sprite en la pantalla (0-255)
Byte 3 : tttttttt Número de tile que representa al sprite
Byte 4 : vhoopppt

De este ultimo byte:
    v : mirroring vertical
    h : mirroring horizontal
    o : bits de prioridad
    p : bits de paleta
    t : bit alto de número de tile

Los 2 primeros son auto explicativos.
Por ahora hablaré de los bits de paleta y de tile.

Con el byte 3 decimos que tile se mostrará como sprite. Podemos elegir un tile desde 0 hasta 255. Pero el bit t del byte 4 también vale para elegir el tile, y de hecho es el bit más significativo de esta dirección, luego:

Bit t del byte 4 = 0
    Byte 3 elige un tile de 0 hasta 255
Bit t del byte 4 = 1
    Byte 3 elige un tile de 256 hasta 511

Luego diré como saber qué tile es el 127 o el 63.
Por ahora añadir que los bits p sirven para elegir la paleta del sprite, de entre 8 (ya que tenemos 3 bits para ello).


PALETAS Y COLORES.
Recuerdo que la paleta de la SNES es una lista de colores que se almacenan en una memoria de la SNES, la CG-RAM, que guarda todos los colores que se pueden mostrar por pantalla en un momento dado, y que se carga por el programador con los colores que se quiera. Estos colores se reverencian por el orden que ocupan en esta lista, desde el 0, hasta el 255.

Los colores que se usan en los sprites son los que van del 128 en adelante (es decir, los que vienen después de los primeros 128).
Los sprites usan 16 colores. Por lo tanto, si a un sprite le ponemos paleta 0, los 16 colores que se usarán para él serán los que van del 128 al 143, y si escoges la paleta 1, los 16 siguientes, etc.


CARGAR LA TABLA DE SPRITES (OAM)
Bueno, ahora que ya sabemos esto, es el momento de aprender a meter esta información en la tabla de sprites.
La tabla de sprites ocupa 512 bytes (4 bytes por 128 sprites), que sirven para almacenar la información ya explicada, pero esta tabla al final tiene otros 32 bytes que sirven para otras 2 cosas; para hacer de noveno bit en la posición X de los sprites, y para elegir el tamaño del sprite entre 2 posible. Pero de momento estos 32 bytes los pondremos a cero. Con esto seleccionaremos el tamaño por defecto, y no afectaremos a la posición X del sprite dada con antelación.

Esta tabla se carga usando los registros $2102, $2103, $2104.
Los dos primeros sirven para dar la dirección del sprite en la tabla, y el tercero sirve para escribir en esa dirección el byte deseado.
Cuando inicialicemos la consola, en nuestra rutina de arranque, sería bueno que llenáramos la tabla de sprites de ceros. Esto se puede hacer muy fácilmente usando DMA.
La siguiente rutina sirve perfectamente. Como necesitamos llenar la tabla con ceros, yo lo que hago es copiar a la WRAM el valor cero en alguna posición de memoria, y luego copiar el contenido de esa posición a la tabla OAM.
En este ejemplo usaré la dirección $0020. Se puede usar otra dirección sin problemas. Fijarse que en el registro $4300 de DMA se selecciona dirección fija (Fixed address), para que siempre se transfiera el mismo byte, que es lo que nos interesa.
Las opciones que hay que usar para trasnferir a la tabla OAM usando DMA son:
    - CPU memory -> PPU
    - Absolute addressing
    - 1 address write twice, o 1 address write once
    - Transferir al registro $2104, y además, en esta ocasión, como es para llenar todo su contenido de un mismo valor:
    - Fixed address

No olvidar resetar la dirección de la tabla OAM antes de copiar.

;------------------------------------------------------------------

LDX #$0
STX $2102 ; empezar desde el comienzo de la tabla OAM

LDY #$0408 ; transferir al registro $2104
STY $4300 ; con dirección fija
LDY #$0020 ; desde la dirección $20
STY $4302 ; que almacena el valor cero
LDY #544 ; transferir 544 bytes para llenar la tabla
STY $4305
LDA #$7E ; seleccionar banco de origen,
STA $4304 ; el banco 7E, comienzo de la WRAM.
LDA #$01
STA $420B ;hacer DMA!

;------------------------------------------------------------------




Listo, ya tenemos la OAM llena de ceros, incluida la tabla de 32 bytes.


¿Y LOS TILES?
Hasta ahora todo va bien, pero aunque en la tabla OAM tengamos nuestros sprites danzando, no veremos nada en la pantalla.
Para que todo esto funcione necesitamos almacenar en la VRAM los tiles que usarán los sprites, y decirle a la SNES en qué posición de memoria empiezan estos tiles. Estos tiles deben usar 4 bitplanes, para ofrecer 16 colores. Por lo tanto cada uno ocupará 32 bytes (tiles de 8x8 = 64 pixels, a 4 bits por píxel, 256 bits, que son 32 bytes). El tile 0 es el primero, el tile 1, el que está en el offset 32, el tile 2, en el offset 64, y así sucesivamente.
Procedamos a definir la dirección base de estos tiles. Para ello necesitaremos el registro $2101, que me ha dado casi todos los problemas que he tenido con sprites.

$2101: sssnnbbb

Los bits b definen la dirección base de comienzo en VRAM de los tiles que usaremos en nuestros sprites. Esta dirección se da en bloques de 8k palabras (o sea, de 16Kb).
Por ello, si ponemos los bits b a 010 (2), estaremos dando la dirección 2*8k palabras, $4000(w), o lo que es lo mismo, la dirección $8000 en bytes de la VRAM, aunque es mejor acostumbrarse a usar las direcciones en palabras de 16 bits cuando nos referimos a la VRAM, en lugar de en bytes. Como la VRAM tiene una capacidad de 32k palabras (64Kb), si la partimos en bloques de 8k palabras veremos que sólo hay 4 posibles posiciones donde colocar los tiles de los sprites.


En palabras, las posibles zonas de VRAM para sprite tiles son:

|__VRAM___| bits b |
------------------------
| $0000-1FFF | 000 |
------------------------
| $2000-3FFF | 001 |
------------------------
| $4000-5FFF | 010 |
------------------------
| $6000-7FFF | 011 |
------------------------

Para qué sirve el bit más significativo lo ignoro. Por ahora, lo considero siempre cero.

Los bits n sirven para seleccionar una dirección base distinta dentro de la que hemos seleccionado. Cuando un tile tiene un indice 256 o mayor, a la dirección base se le suma la seleccionada en los bits n, que definen un desplazamiento en bloques de de 1k palabra.
Por ejemplo, si elegimos los bits b 010, seleccionamos el bloque

------------------------
| $4000-5FFF | 010 |
------------------------

Pero si hacemos los bits n 01, para tiles de indice mayor que 255, es decir, los que ocupan posiciones a partir de $5000 (la mitad del bloque), la dirección base pasará a ser:

$5000 + 400 = $5400 (se le suma un bloque de 1k palabra)

Y análogamente, para bits 10 y 11, tendremos:

$5000 + 800 = $5800 (se le suma dos bloquess de 1k palabra)
$5000 + 1000 = $6000 (se le suma tres bloques de 1k palabra)

Esta técnica es muy útil para crear sprites animados de 4 frames, de una forma sencilla. Basta con colocar los tiles de esos sprites en posiciones 256 y superiores, y variar los bits n cada par de frames. Así, se irán eligiendo los tiles en posiciones separadas por 1k palabra de forma ciclica.


ACTIVAR SPRITES

Ahora tenemos que definir el modo gráfico en el que vamos a trabajar, activar los planos de scroll que vayamos a usar, y activar los sprites.

En primer lugar definimos modo1, por ejemplo, que es uno de los más sencillos para aprender. Este modo tiene disponible 3 planos de scroll, el BG1, el BG2 y el BG3. Los dos primeros usan 16 colores (tiles de 4 bitplanes), y el BG3 de 4 colores unicamente (tiles de 2 bitplanes). El registro para seleccionar modo es el $2105, en concreto sus 3 bits menos significativos.

$2105: abcdefff

Los bits f son los bits de modo que acabo de decir.
Del bit a, al d, sirven para seleccionar el tamaño de los tiles de los planos BG4 al BG1 (0=8x8, 1=16x16). Yo nunca he usado tiles que no sean de 8x8 así que no daré más información.
El bit e sirve para dar máxima prioridad al BG3 en modo1. Por ahora no lo usaremos tampoco.

;---------------------------------------------------------------------
lda #$01 ;mode 1, 8x8 tiles (16 colores para BG1 + BG2 y 4 para BG3)
sta $2105
;---------------------------------------------------------------------

Y para activar los planos de scroll que queramos, al igual que los sprites, está el registro $212C

$212C: 000abcde

Los 3 bits altos no se usan.
El bit a se refiere a los sprites.
El bit b al BG4
El bit c al BG3
El bit d al BG2
El bit e al BG1
Un bit a 1 significa activado, a 0, desactivado.

;--------------------------------------------------------
lda #$17 ;Activar todos los planos del modo 1, y sprites
sta $212C
;--------------------------------------------------------


ACTUALIZAR LA TABLA OAM

Hemos aprendido a resetar la tabla de sprites. Ahora vamos a necesitar llenar esta tabla con información correcta sobre cada sprite, de su posición, tile y atributos. Esto lo haremos de la siguiente manera.
En primer lugar, designaremos una zona de memoria donde almacenaremos nuestra tabla de forma temporal, y durante la rutina de refresco de pantalla, copiaremos esta tabla temporal a la tabla OAM, usando DMA, como antes.

Por ejemplo, dediquemos la zona de WRAM $0040-$25F a almacenar nuestra tabla temporal.


;------------------------------------------------
.DEFINE Sprites $40 ;544 bytes, $220
;------------------------------------------------

Con el identificativo Sprites, designaremos el offset de inicio.
Ahora debemos ir copiando aquí la información que se transferirá a la tabla OAM cada frame, en el mismo formato claro, y dejando los últimos 32 bytes a cero de momento. Los primeros 512 bytes estarán disponibles para usar hasta 128 sprites. Por ejemplo, añadamos un sprite en la posición X = 16, Y = 191, que use el tile $80, paleta cero, y sin atributos de prioridad o mirroring. Este será nuestro sprite cero, luego lo copiamos al inicio de nuestra tabla en WRAM, por ejemplo de la siguiente forma:

;--------------------
LDY #$BF10
STY Sprites + 0
LDY #$0080
STY Sprites + 2
;--------------------

Y si queremos un segundo sprite, a continuación.

;------------------
LDY #$B710
STY Sprites+4
LDY #$0081
STY Sprites+6
;------------------

Etc.
Lo que resta es volcar esta tabla temporal a la tabla OAM cada refresco de pantalla, como hacemos con el resto de planos de scroll, por ejemplo, y esto se hace fácilmente usando DMA, y una rutina casi idéntica a la de inicialización de antes, sólo que ahora usaremos como dirección origen la dirección de nuestra tabla temporal, y no se usará dirección fija (Fixed address), sino autoincremento, para ir copiando uno tras otro todos los bytes de la tabla temporal. Es decir, seleccionar:

    - CPU memory -> PPU
    - Absolute addressing
    - 1 address write twice, o 1 address write once
    - Transferir al registro $2104
    - Auto address inc/decrement.
    - Automatic increment.

;--------------------------------------------------------------
LDX.w #$0
    STX $2102 ; resetar la dirección de la tabla OAM

    LDY #$0400 ; copiar al registro $2104 (OAM)
    STY $4300 ; incrementar dirección
    LDY #Sprites ; copiar desde el inicio de nuestra
    STY $4302 ; tabla temporal
    LDY #544
    STY $4305 ; numero de bytes
    LDA #$7E ; banco 7E, primer banco de la WRAM
    STA $4304 ;
    LDA #$01
    STA $420B ; DMA!
;--------------------------------------------------------------




También se puede copiar manualmente, sin usar DMA. Es muy sencillo PERO ojo, hay que usar un registro de 8 bits para la transferencia u obtendrás resultados indeseables. Esta rutina funciona perfectamente, y es equivalente a la anterior:

;-----------------------------------------------------------
LDX.w #$0
STX $2102 ; resetear dirección OAM
SEP #$20 ; el registro A debe estar configurado en 8 bits
    LDY #$00
CopySpr:
    LDA Sprites, Y
    STA $2104
    INY
    CPY #544
    BNE CopySpr
;-----------------------------------------------------------

Con esto doy por concluído el tutorial. Creo que con esta información no será problema meter un par de sprites que revoloteén por ahí, y den alegría a un frío plano de scroll ;)
Dejo para más adelante el uso de sprites de más de 8x8 pixels, y otras cosillas más avanzadas.


RESUMEN:
1º copiar los tiles que usarán los sprites a un dirección de VRAM.
Esta tiene que ser una de las siguientes.

|___VRAM___| bits b |
------------------------
| $0000-1FFF | 000 |
------------------------
| $2000-3FFF | 001 |
------------------------
| $4000-5FFF | 010 |
------------------------
| $6000-7FFF | 011 |
------------------------

2º Establecer la dirección base de estos tiles en el registro $2101
3º Seleccionar modo gráfico en el registro $2105
4º Activar los sprites en el registro $212C
5º Limpiar la tabla OAM
6º Cada refresco de pantalla actualizar la tabla



ImagenVolver a la página principal.
Lástima que le tenga tirria al ensamblador, porque los tutoriales son muy interesantes XD

Ya que estáis con temas técnicos, tengo una pregunta: hay algún juego de Super Nintendo que use 4096 colores en pantalla? he oído algo sobre imagenes estáticas en el Donkey kong country, pero la información era algo caótica.

Y otra más: cuál creéis que es el juego del catálogo que muestra más sprites en pantalla? A mi me sorprendió el Parodius 2 (el segundo que salió en esta consola), en el que se podía apreciar como desaparecían "partes" de los enemigos.
John Torrijas escribió:Ya que estáis con temas técnicos, tengo una pregunta: hay algún juego de Super Nintendo que use 4096 colores en pantalla? he oído algo sobre imagenes estáticas en el Donkey kong country, pero la información era algo caótica.


No tengo ni idea de en que juegos concretamente se usan 4096 colores, pero si, en imagenes estáticas era el unico modo de superar los 256 en pantalla(hablamos de poder meter imagenes de 4096 colores a 512x448 de resolución. Te comes el cartucho en dos viajes. No compensa, y no creo que sea muy habitual).

Leí una vez en una revista (creo que nintendo acción), que la imagen de hulk hogan en la pantala de inicio de un juego de esos de la WWF, ocupaba 1Mbit enterito. El juego tenía 16Mbits, creo, así que ya solo te quedan 15 con la tontería de digitalizar "a todo lujo" la portada del juego.


John Torrijas escribió:Y otra más: cuál creéis que es el juego del catálogo que muestra más sprites en pantalla? A mi me sorprendió el Parodius 2 (el segundo que salió en esta consola), en el que se podía apreciar como desaparecían "partes" de los enemigos.


Copio y pego:

"Máximo número de píxeles de sprites en un scanline: 256. El generador de imágenes tiene un error de software el cual se deshacía de los sprites más cercanos en vez de los más lejanos si un scanline excedía el límite."


...vamos, que casi ningún juego creo que llegue a ese limite de 128 sprites. Son una burrada muy gansa (la superficie total de tamaño de 128 sprites a 64x64 pixels ocupa varias pantallas de TV, y no es coña).

EDIT: Rectifico, dudo que haya algún juego que supere los 128 bits en pantalla, todo esto se medía muchísimo, así que es mas cosa del generador de imagenes. Estoy convencido (y no digo qeu no exista algún caso muy puntual).
John Torrijas escribió:Ya que estáis con temas técnicos, tengo una pregunta: hay algún juego de Super Nintendo que use 4096 colores en pantalla? he oído algo sobre imagenes estáticas en el Donkey kong country, pero la información era algo caótica.


Ralph escribió:No tengo ni idea de en que juegos concretamente se usan 4096 colores, pero si, en imagenes estáticas era el unico modo de superar los 256 en pantalla(hablamos de poder meter imagenes de 4096 colores a 512x448 de resolución. Te comes el cartucho en dos viajes. No compensa, y no creo que sea muy habitual).



No, no existe ningún juego de SNES que muestre 4096 colores simultáneos en pantalla, el máximo es 256 por BG, lo que pasa es que en Mode3 puedes tener un BG con 256 colores y otro con 16; esto sumaría, usando diferentes paletas, hasta 272 colores, y jugando con la suma y resta de pantalla, se podría conseguir algún efecto como si hubiera diferentes colores, pero nunca más de esos que te indico. Y la BG2 en el Mode3 tiene que usar la paleta de BG1, así que realmente la paleta tiene 256 colores de los que eliges cualquiera de ellos para BG1 y sólo 16 para la BG2.

Lo de la imagen de 1 Megabit me parece increíble. Ese tamaño es exactamente el total de la VRAM que tiene la SNES, por lo que no cabría el mapa para mostrar dicha imagen (el mapa indica qué tile va en cada posición de la parrilla imaginaria que te harías mentalmente de la pantalla). Así que 1 megabit seguro que no es, quizá sea algo menos...

Ralph escribió:"Máximo número de píxeles de sprites en un scanline: 256. El generador de imágenes tiene un error de software el cual se deshacía de los sprites más cercanos en vez de los más lejanos si un scanline excedía el límite."


Realmente el máximo número de sprites es de 32 por scanline. Traduciendo la intro del Secret of Mana 2, me encontré con que me desaparecían letras y era porque se superaban las 32 letras por línea: cada letra era un sprite, aunque me saqué de la manga una forma de hacer más largas las líneas juntando las letras que se pudieran de 2 en 2 en un mismo tile 16x16. Esto implica que, a pesar de tener los mismos píxeles, al reducir el número de sprites, ya no desaparecía ninguna letra.

Ralph escribió:...vamos, que casi ningún juego creo que llegue a ese limite de 128 sprites. Son una burrada muy gansa (la superficie total de tamaño de 128 sprites a 64x64 pixels ocupa varias pantallas de TV, y no es coña).


Hombre, ten en cuenta que no siempre se usa el tamaño grande de los sprites; cuando fijas en un registro que los sprites sean grande, solo puedes usar sprites 32x32 ó 64x64, exclusivamente; esto implica gastar mucha memoria VRAM para almacenar las tiles que lo forman, teniendo en cuenta además que las formas de los personajes que aparecen no son cuadradas (desperdicias muchos píxeles entonces de los 64x64). Normalmente se usa el modo de sprites pequeños, que son 8x8 ó 16x16, de modo que un personaje en pantalla lo forma, por ejemplo 1 sprite 16x16 central (el "tronco" del personaje) y 4 ó 5 sprites 8x8 que periféricos (las extremidades, como brazos o piernas). Y de esta forma sí se pueden llegar a agotar los 128 sprites. El Parodius y el Probotector sí que los usan todos en algunas escenas.



Ralph escribió:EDIT: Rectifico, dudo que haya algún juego que supere los 128 bits en pantalla, todo esto se medía muchísimo, así que es mas cosa del generador de imagenes. Estoy convencido (y no digo qeu no exista algún caso muy puntual).


¿128 bits? a qué te refieres?
magno escribió:No, no existe ningún juego de SNES que muestre 4096 colores simultáneos en pantalla, el máximo es 256 por BG, lo que pasa es que en Mode3 puedes tener un BG con 256 colores y otro con 16; esto sumaría, usando diferentes paletas, hasta 272 colores, y jugando con la suma y resta de pantalla, se podría conseguir algún efecto como si hubiera diferentes colores, pero nunca más de esos que te indico. Y la BG2 en el Mode3 tiene que usar la paleta de BG1, así que realmente la paleta tiene 256 colores de los que eliges cualquiera de ellos para BG1 y sólo 16 para la BG2.


Ya, en un principio no he visto en ningún modo gráfico la posibilidad de mostrar 4096 colores, pero si recuerdo que se decía, y nunca se sabe de que manera se pudiera haber conseguido. En definitiva, que mas allá de los modos gráficos no hay nada con lo que "jugar" para conseguir otros resultados. Esto es totalmente rígido, y no se puede hacer nada al respecto.



magno escribió:Lo de la imagen de 1 Megabit me parece increíble. Ese tamaño es exactamente el total de la VRAM que tiene la SNES, por lo que no cabría el mapa para mostrar dicha imagen (el mapa indica qué tile va en cada posición de la parrilla imaginaria que te harías mentalmente de la pantalla). Así que 1 megabit seguro que no es, quizá sea algo menos...


Lo dijeron a grandes rasgos en un pié de foto, o en un comentario destacado de dos lineas, así que no, sería 1Mbit a grandes rasgos, pero vamos, que sigue siendo una burrada.

Esta es la imagen de la que hablo:


Imagen

...hay que tener en cuanta que la tecnología de compresión de antaño no es como ahora, porque si, se podría haber obtenido un resultado incluso superior con 1Mbit para una imagen digitalizada.



magno escribió:Realmente el máximo número de sprites es de 32 por scanline. Traduciendo la intro del Secret of Mana 2, me encontré con que me desaparecían letras y era porque se superaban las 32 letras por línea: cada letra era un sprite, aunque me saqué de la manga una forma de hacer más largas las líneas juntando las letras que se pudieran de 2 en 2 en un mismo tile 16x16. Esto implica que, a pesar de tener los mismos píxeles, al reducir el número de sprites, ya no desaparecía ninguna letra.


32 por scanline, pero no de cualquier tamaño, hay un límite de 256 pixels por scan, ¿no? (que realmente es ocupar toda la pantalla de izquierda a derecha). Entonces, cuando el bug del generador de imagen entra en acción, ¿es que lo dibujado se está saliendo de la pantalla?, menudo fallo de diseño(del juego), ¿no?... ¿cuantas lineas de codigo le lleva a un programador eliminar lo que se sale del limite de la resolución? :-?



magno escribió:Hombre, ten en cuenta que no siempre se usa el tamaño grande de los sprites; cuando fijas en un registro que los sprites sean grande, solo puedes usar sprites 32x32 ó 64x64, exclusivamente; esto implica gastar mucha memoria VRAM para almacenar las tiles que lo forman, teniendo en cuenta además que las formas de los personajes que aparecen no son cuadradas (desperdicias muchos píxeles entonces de los 64x64). Normalmente se usa el modo de sprites pequeños, que son 8x8 ó 16x16, de modo que un personaje en pantalla lo forma, por ejemplo 1 sprite 16x16 central (el "tronco" del personaje) y 4 ó 5 sprites 8x8 que periféricos (las extremidades, como brazos o piernas). Y de esta forma sí se pueden llegar a agotar los 128 sprites. El Parodius y el Probotector sí que los usan todos en algunas escenas.


De ahí mi siguiente comentario, aunque a esas horas uno ya escribe lo que sea XD



magno escribió:¿128 bits? a qué te refieres?


Me refería a 128 sprites:

EDIT: Rectifico, dudo que haya algún juego que supere los 128 sprites en pantalla, todo esto se medía muchísimo, así que es mas cosa del generador de imagenes. Estoy convencido (y no digo que no exista algún caso muy puntual).



Por cierto, tu que tienes bastante mano con la super nes, ¿crees que los personajes del super punch out podrían haberse animado mejor(con mas cuadros de animación) si se hubiera destinado mas memoria al cartucho?.

...y otra cosa, Kraid, del super metroid, ¿son sprites?, o es un fondo.
Pues nada, gracias por la aclaración.

Realmente me sorprendió ver eso en el Parodius, ya que no es algo muy común en esa consola.


Ralph escribió:...y otra cosa, Kraid, del super metroid, ¿son sprites?, o es un fondo.


Esto se podría averiguar con el zsnes, con el que puedes activar y desactivar los backgrounds y los sprites.

El primer bichejo del Contra, por ejemplo, que ocupaba casi toda la pantalla, era un fondo + sprites móviles.
John Torrijas escribió:Realmente me sorprendió ver eso en el Parodius, ya que no es algo muy común en esa consola.


Estoy viendo videos del parodius 2, y estoy viendo algo que veo en casi todos los juegos. cuando disparas un laser, un haz de luz, un rayo o equivalente, al desplazar la nave, desplazas TODO el disparo... odio este detalle, prefiero que no incluyan este tipo de munición antes que verlo así.
Una duda que tengo,el juego Joe&Mac salieron 3 entregas? tengo entendido que la segunda parte no salio en europa y si en America al menos que me equivoque.
Con esto hay un pequeño lio, si. Realmente el Joe & mac 2, es la tercera parte, lo que ocurre es que en europa no salió la segunda, y además salió con otro nombre. algo parecido a esto... a ver si alguien lo confirma.
Ralph escribió:Con esto hay un pequeño lio, si. Realmente el Joe & mac 2, es la tercera parte, lo que ocurre es que en europa no salió la segunda, y además salió con otro nombre. algo parecido a esto... a ver si alguien lo confirma.



Salio con el nombre de Congo,s Caper no?
En Europa:

Joe & Mac
Congo's Caper (Joe & Mac 2)
Joe & Mac 3 Lost In The Tropics

Creo que ya lo preguntaste hace un tiempo y aun está por ahi el hilo.
Only16bits escribió:En Europa:

Joe & Mac
Congo's Caper (Joe & Mac 2)
Joe & Mac 3 Lost In The Tropics

Creo que ya lo preguntaste hace un tiempo y aun está por ahi el hilo.



Creo que no,o no me acuerdo de hacer un post de dicho tema.
ImagenVolver a la página principal.




JUEGOS CANCELADOS C-E


Imagen





    · College Football
    · Comanche
    · Congo
    · Cooly Skunk
    · Corn Buster
    · Darius 3
    · Daze Before Christmas
    · Desert Sword
    · DNAction: The new breed
    · Dominus
    · Dorque & Imp
    · Dragon Warrior V
    · Dragonfly (Pilot Wings)
    · Dream Probe
    · Eurit
    · ExoSquad








College Football
College Football was being developed by HAL America, according to the August 1992 issue of Nintendo Power. However, they also mentioned that the game would not see the light until 1993, and probably was left unreleased due to the competition in football games. In all likelyhood, the game would have used the same Mode 7 based engine that was used in NCAA Basketball.

Bibliography:

    · Nintendo Power, Summer CES Special, Publication date: August 1992, Volume: 39, Pages: 58-61


Comanche
Comanche is one of the more infamous unreleased games. It was one of the games that Nintendo was using to combat the growing threads of next generation systems like the Jaguar and 3DO. The game was to feature intense helicopter fighting action. Comanche took advantage of the Super FX chip, and was being developed by Novalogic. Unfortunately, it seems that it was scrapped because of graphics and speed problems (source: Gamepro).

Scan courtesy of hydr0x (from Nintendo Fun Vision, vol 13):

Imagen

Imagen


Congo
Congo - The Secret of Zinj is an unreleased Super NES game based on the hit 1995 movie. The game was cancelled after a short development turnover and playtests indicating that the game was not good enough for release. Also contributing was the fact that the movie was a bit of a flop. A ROM image of this game exists, released by Martin at NESWorld.

Imagen

I remember watching the movie Congo in theatres when I was a kid. I recall it was a silly movie about this group of treasure hunters searching for this lost city of Solomon, which had giant diamonds. I do not remember all the details, but it featured these giant apes attacking the protagonists, while at the end, the apes perished by jumping into erupting lava. It certainly was not a great movie, but it had quite a bit of hype.

Long before knowledge of the Super NES Congo came to my attention, I was well aware of the first person shooter Congo game that was released by Sega in 1996. The Super NES version was developed by Visual Concepts and was to be published by Viacom New Media in 1995, and was completely unrelated to the Saturn game (a Genesis version was also developed at the same time as the SNES version). It remained in obscurity until a former Viacom employee made a post in an unreleased SNES games topic on Digital Press:

    furor: That list brought back some horrible memories. I almost forgot that a SNES version of Congo even existed. I worked over at Viacom and actually got to play it some. The game sucked so bad that we cancelled it. So, I know for a fact that it was never released.

    hydr0x: Hey furor that's GREAT info, thanks a lot, do you know if there are any protos left? Any screenshots? any Viacom-papers about it?Oh and tell me more about it, what kind of game was it?

    furor: No protos, screen shots, or info on the game that I know of. All I can tell you about the game is that is was a pretty bad rip off of Donkey Kong Country. It was a side scroller where you controlled a poorly animated gorilla picking up diamonds instead of banana's.

Imagen


I decided to dig into this a bit further, and I found this post on USENET, dating to December 5, 1995 by a poster known as The Flapper, who was a developer at Viacom:

    I'm just asking this out of curiosity, not because I actually want the
    game. I was just curious because Visual Concepts was programming SNES
    and Genesis Congo for us at Viacom, and it sucked hard. Worst game I
    have ever played. The whole testing department complained so much that
    the big guys finally listened and cancelled it. I haven't heard anything
    about the Saturn version lately...I'm wondering if Visual Concepts was
    doing Saturn Congo also...and it sucked and got scrapped...anyone have
    any info to satisfy my curiosity? Thanks!

And another post by the same person on April 4, 1996:

    No, it's not like the PC version...I haven't played the Saturn one, but
    Viacom New Media released Congo for PC...Sega has some other developer
    that did Congo Saturn for them. I might note that Congo Saturn looks
    VERY similar to the scrapped SNES and Genesis Congos, which I wouldn't
    take as a good sign...believe me, the 16-bit Congo was a travesty!

Imagen


Prototype found

That might have been the last we heard about the game, were it not for a moment of serendipity by Martin of NESWorld. While looking for information on the unreleased NES game, Congo's Caper, he stumbled onto a webpage by one of the developers of Congo for the SNES. Martin asked him if he had worked on Congo's Caper, but instead found that the developer had worked on another unreleased game, based on the movie Congo. After some conversations, the developer sent a prototype of the game to Martin, and wrote a lengthy article on the development of the game.

Imagen

    During the final two weeks, we were exhausted. Viacom had begun to QC the product in preparation for Nintendo’s and Sega’s more rigorous testing processes. They came back with fewer and fewer bugs. August 7, Final Day, rolled around. The customer expected the binary uploaded to their server by Midnight. That evening, my boss asked me if I needed anything from him. I told him I was fine. He confided to me that he thought Congo was in the top 20% of games out there quality-wise. Most of those games had a year or more of development time; ours had five months. I performed a few last-minute, minor changes, added the signature bytes, and created a build, which we then uploaded. We were done, just waiting for their QC process.

    And waiting… And waiting yet more.... Another day passed, and on the second day after the upload, we got a call saying their QC had found a bug and that we would not get our bonus. The bug was a shift in palette colors that happened if the user moved from the title screen to the game menu, back to the title screen, and back to the game menu. It was a legitimate bug, a bug they may have, in fact, caught earlier and not informed us, knowing they could take our bonus in this way… This is only a theory.

    However, despite this, Congo was finished, on time and on budget, and the team felt absolutely great. Most left for much needed two-week vacations after that. They returned to find that Viacom, acting on data in the film industry reflecting poorly on the movie Congo, had cancelled the project.

    The foundations of our beings shook. We had just been told that immeasurable labor, passion, sacrifice, and stress, in short, fourteen months of our lives had been wasted. For some of us, this was the most devastating day in our careers.

In essence, the development of Congo lasted for 14 months, though the initial nine months of work was scrapped after deadlines and comments from Viacom forced the restart. The story of the development of Congo was rather tragic, and certainly sapped the energy of the developer who wrote the article for NESWorld. Still, the results in the five months of development are quite impressive. However, I have to disagree with the assessment that this game would be in the "top 20% of games out there quality-wise".

Imagen


The Game

Congo is an interesting game, because it is split into five different types of gameplay. The main levels include a light-gun style shooter, a raft level that is sort of a "avoid the edges" maze game, a slide level where the character must jump to avoid spikes and other obstacles, an on-the-rails platform level, and an overhead 2.5D level. There is a lot of variety in this game, and some of the levels work. A lot of the flaws probably could have been ironed out with additional development time. The main issue with this game, in particular in the non-shooter levels, is that your character dies in one hit. This makes the game rather frustrating in parts. I will go into this later in the article. Controlling light-gun style shooters with the D-pad is always awkward, but those particular levels are not too hard anyways. The other levels feature collect-o-thon gameplay, though it is downright impossible to collect all the diamonds in the level because of forced scrolling.

In some of the levels, the graphics and sound are top-notch. The raft levels in particular really show off some great water effects. The 2.5D platform level is also excellent, and I cannot recall any game for the SNES that was able to implement this particular viewpoint. The graphics in the slide level are not as impressive, and there are problems with clipping. The shooting levels are typical of light gun games such as Lethal Enforcers, with decent animation for the gorilla enemies. As for the other levels, aside from some boulders and hippos, there are not any enemies to deal with. The developer who wrote the article was not lying when he said the lava that follows you on the last platforming level was thrown in at the last minute - it looks terrible and follows the screen rather than the level obstacles. Between levels, there are some decent digitized stills of events in the movie. The music in the game involves jungle-beats, and are very appropriate for the game. There aren't many sound effects except for when you die and when you pick up diamonds.


Level 1 - River Ride Rafting

The first real stage in the game features your character (Captain Munro Kelly?) rafting down a river. The stage is split into two levels plus a bonus level between them. The controls for this stage are fairly dicey, though you can generally slow your raft down to a crawl by pressing the opposite way of your motion. One of the most frustrating parts is the fact that you cannot go backwards, meaning if you missed a secret passage, it is impossible to go back and get it. Speaking of secret passages (generally marked with five rotating diamonds), if you fail to find them, it makes the stage much more difficult. Much of the latter parts of the first level are narrow passages lined with spikes or trees. One bad move and your life is over. If your character had three or four health points, this stage would likely be very easy. Due to the one-hit deaths, this stage is quite awkward and downright frustrating at times. The second level features hippos that are fairly well hidden until you get near them (you can tell where they are because the water is darker). Most of the hippos are fairly easy to avoid, but some of them come after you near the end of the level. The floating logs serve as the largest obstacle in the stage, and can be pretty dicey to avoid in narrow areas. With practise, the stage is very beatable, though.

Imagen


Levels 0, 2, 4, 6 - shooting

There are several light-gun style shooting levels in this game. For the most part, they involve shooting at gorillas that throw giant rocks at you, or these strange urn-like things that shoot these energy balls at you. For weapons, you are given a collection of 20 grenades and a black orb gun, which has a rechargeable energy bar that controls how fast the gun shoots. The levels are not that difficult, provided that you collect all the health powerups (by shooting at the yellow containers) and destroy all the projectiles thrown your way. The action on the screen is quite hectic. These stages are the only levels with a health bar, which makes passing these levels much easier than the other stages in the game. I passed all three levels in my first or second try.

Imagen


Level 3 - Amy the Gorilla's mudslide

Without a doubt, the gorilla slide level is the hardest and most frustrating level in the game. I was never able to even reach the first checkpoint in this level. The problem arises from the fact that the ape slides down the chutes at a fast rate, and it is difficult to react to obstacles quickly enough. Though you can jump over spikes and boulders, there is no way to slow yourself down to track which paths to take. Again, with one hit deaths, the level becomes very difficult. There are some clipping issues in this level, and sometimes the gorilla can veer way off the actual course.

Imagen


Level 5 - Karen's cave run


The developer who wrote the article on NESWorld stated that this level was supposed to have the character (Karen) riding some sort of skateboard-like platform. And really, the gameplay of this level is pretty much the same as the first mine cart level in Donkey Kong Country. In this level, the primary gameplay mechanism is simply to press the jump button at the right time, and occasionally using the whip to cross gaps. Much like the mudslide level, there is no way to slow down your character, and sometime it almost feels like pure luck to avoid smacking right into a pillar or missing a gap. Still, with practise (and a bit of memorization), this level (again split up into two sub-levels and a bonus level between) is beatable. This level might be fun for twitch gamers, but the on-the-rails component makes it rather dull.

Imagen Imagen


Level 7 - Escape from Zinj

When the former Viacom employee mentioned that the game was a "rip off of Donkey Kong Country", he must have been referring to this level. However, aside from the similarities in the graphics and animation of the gorilla character, there aren't too many similarities. This level has an interesting point of view with an angled overhead camera angle. In some ways it might be comparable to the gameplay in Sonic 3D Blast. The lava that was added in as an afterthought looks terrible and tacked on. As far as controls, they work well, though the platforming requires a lot of precision, and it is not always easy to anticipate the pools of lava or falling statues before you make a jump. Perhaps the biggest flaw I came across in this level is due to the forced scrolling. You often have to make pinpoint accurate jumps on these pillars to get over a large wall. However, because the screen scrolls too fast, you only have one chance to do this. Even worse, there is a part of the first stage where you have to hit three tiles in the correct order, but the forced scrolling often cuts off the second tile you hit before you get a chance to step on it. Again, there are issues with one-hit deaths. Because of these issues, it is highly unlikely most people will have the patience to actually beat the level.

Imagen Imagen


Codes

If you really want to delve into some of the more frustrating stages, enter the following code at the title screen: L, R, X, L, R, X. This code gives you twenty lives and five continues when you start the game, and also mirrors the lives counter. Of course, continues are rather pointless in this game, because if you lose your lives and continue, you restart from the very beginning of the level, making it no different than re-entering the level passwords. To reset the game while playing, simultaneously press L+R+Start+Select

Imagen
If the code is entered correctly, the lives number is mirrored.


Level passwords are as follows:

Imagen
Level 2: First shooting level

Imagen
Level 3: Amy the Gorilla's mudslide

Imagen
Level 4: Second shooting level

Imagen
Level 5: Karen's cave run

Imagen
Level 6: Third shooting level

Imagen
Level 7: Escape from Zinj


Summary

Congo is an impressive game if you consider that it was developed in five months. However, despite the fact this game is bug-free, it lacks the polish of a completed game. Extensive playtesting probably would have revealed the need for a life bar on the raft and mudslide levels, the need of a method to slow down in the mudslide and cave run levels, and to slow down the forced scrolling in the final platform level. The graphics in many of the levels are great, while bland in others. Collecting diamonds is a downplayed gameplay aspect compared to most collect-o-thons, mostly due to the fact you cannot retrace your steps. Congo could have been a great game, but in its final state it is not polished enough to justify the claim that it was a top tier SNES game.



Imagen


Bibliography

    · Article on Congo on NESWorld (link)
    · Thread on Digital Press with comments from a former Viacom staff member who played the game (link)
    · Usenet post dated on December 5, 1995 stating the reason the game was cancelled (link)
    · Another USENET post regarding the game (link)
    · Information on the Sega Saturn game on Game Rave (link)
    · Webpage of Greg Hedger, who worked on the game. (link)
    · Page on Congo on Unseen64 (link)
    · Internet Movie Database entry on Congo (link)


Cooly Skunk
Cooly Skunk (also known as “Punky Skunk” in USA) is a platform game that was originally in development by Visit for the Super Famicom / Super Nintendo. The game was never released for the Nintendo console, but the title was somehow resurrected (by Ukiyotei?) with some graphical changes for the Playstation and later published in Japan by Visit and in America by Jaleco.

In Cooly Skunk the player takes the role of an anthropomorphic skunk and the game plays much like other side-scrolling action games, featuring a set of special tools including a skunk spray, parasail, a pogo stick, inline skates, digging claws, and a snowboard.

The project was probably canned for the 16 bit system because of the new Playstation and Saturn consoles, that “killed” the SNES / Mega Drive (Genesis) market. Although released for the Playstation, it seems that the game was “not finished to completion” (at least from what we can read on Wikipedia, does anyone know more about this?). Cooly Skunk remains a collectors curiosity due to the generally unfinished nature of the game and its Super Famicom origins.

Celine was able to find some screenshots of the Super Famicom / Super Nintendo version on Super Power magazine issue 41.

Screeshots:

Imagen Imagen

Imagen Imagen


Corn Buster
Corn Buster is an unreleased Super Nintendo game developed by Engine Software. The game is the story of a dragon named Globey, who sets out to defeat the person who’s stolen all the cornflakes in the world. The gameplay is an interesting mix of an Arkanoid-Style ball-and-paddle game and a vertical scrolling shooter. The game quietly began development around 1994, and was canceled soon after interest in the Super Nintendo waned in light of the release of Sony’s Playstation. Some time ago, Engine Software released a ROM of the game for free download on their website. The download page has since been removed, but the ROM is still easily obtainable. The game was 70-80% completed before it was canceled.

Screenshots:

Imagen Imagen Imagen Imagen

Imagen Imagen Imagen Imagen

Imagen Imagen Imagen Imagen

Imagen Imagen Imagen Imagen

Imagen Imagen Imagen Imagen

Imagen Imagen Imagen Imagen

Imagen Imagen


Darius 3
Darius 3 was listed on a release list suplemental in the January 1994 issue of Nintendo Power. In all likelyhood, it was going to be the US release of Darius Force, which was released in Japan.

Bibliography

    · Nintendo Power, Super Nintendo Entertainment System Power Index (release list), Publication date: January 1994, Volume: 56, Pages: 2


Daze Before Christmas
Daze Before Christmas was a platform game by Sunsoft set to be released in 1994. This game was released in full in Europe by Sunsoft but was cancelled in the US due to the company going bankrupt.

Imagen

Daze Before Christmas is a decent platform game featuring Santa. You fight various wintery and toy enemies while collecting presents and saving elves and reindeer. You can also tranform into a more evil looking "devil Santa" that uses the toy sack as a weapon. The colourful graphics would have made this a good release, though apparently Sunsoft USA went bankrupt before it could be released.

Information courtesy of Jonny

From Carl-Henrik Skårstedt:

"Daze took about 1 year in total, but the problem was I didn't start until 6 months into the project so I had a lot of art and the code from A Dinosaur's Tale to combine, the SNES version was converting the same code that was already on Genesis so it took me about 6 months (I was on the Genesis version and there was one programmer on the SNES version). Unfortunately Sunsoft USA ran out of money and went bankrupt about the same day the SNES version was finished."

Codes:

Level select code - At the title screen enter the code: B, A, Down, Left, A

Genesis level select code - at the title screen enter the code B, A, Right, Right, A

ccording to the main Genesis programmer Carl-Henrik Skårstedt, the Daze codes mean two different things: Barra is swedish for a Christmas tree dropping its needles, Badla is one of the musician's nickname (Geir Tjelta, he'd walk around constantly saying 'Badla' over and over).

Imagen

Imagen
Preview in the May 1994 issue of EGM (courtesy of KingMike)



Preview in the May 1994 issue of EGM
(Click to enlarge)
Imagen



Bibliography

    · Electronic Gaming Monthly, Previews, Publication date: May 1994, Volume: 58, Pages: 128


Desert Sword
G2 was shown at the 1993 Summer CES by Kemco. The game was released as G2 - Gencide 2 in Japan. It is a Ninja Gaiden style side-scroller, except with giant robots. It was pretty mediocre, which may have contributed to its cancellation.

Bibliography:

    · Nintendo Power, Pak Watch - Summer CES, Publication date: August 1993, Volume: 51, Pages: 113


DNAction: The new breed
DNAction: The New Breed is a cancelled fighting game that was in development for the Super Nintendo and Genesis / Mega Drive, that would have been published by Accolade in 1994. The game was never released in the end and there are just few info about the project, with some character renders found in Banzzai magazine #21 and in GamePro #56, plus some in-game screens from an early prototype found in Player One #43. DNAction used pre-rendered sprites for characters and backgrounds, created with Silicon Graphics in the same way as Killer Instinct.

Screenshots:

Imagen Imagen Imagen

Imagen Imagen Imagen

Imagen Imagen Imagen

Imagen Imagen Imagen


Dominus
This game was scheduled to be released by ASCII for the PC, Genesis, and of course, the SNES. It was apparently going to be some sort of strategy game. A rom image of the Genesis version is available, but as far as I can tell, it was never officially released in any form. Jonny got a hold of one of the people who worked on the game, Tim Ryan:

I worked at ASCII, the publisher. It was being developed externally by Visual Concepts on the SNES and PC. I was their producer. I was also the project leader on the Sega port done in house. There were a number of titles I worked on that got cancelled when ASCII imploded (ran out of cash) and fired everybody. Visual Concepts bought the rights back and published the PC version, possibly a Sega version. The SNES version stopped making progress well before the implosion though. Visual Concepts also became a Sega studio. That's probably why a SNES version was never published.

Dominus was shown at the Winter 1993 CES. Nintendo Power states that it allowed you to control up to 500 different monsters.

Screenshot from the March 1993 issue of Nintendo Power (scanned by Retromags)

Imagen


Bibliography:

    · Nintendo Power, Pak Watch, Publication date: March 1993, Volume: 46, Pages: 114


Dorque & Imp
Dorque & Imp is a cancelled platform that was in development by Norse (a swedish gaming studio) for the Super Nintendo. Akumu from the Lost Levels Forum translated a swedish preview in which we can read some more info on the project:

2 of the worlds are completed. When Power Player catches up with the team of programmers, they are already hard at work to finish up the demo that will be shown in England. Peter shows us how far they are come. He has 100 000 command lines which helps him to quickly change the enviroment on the screen. He is programming in assembler, and can in principal cut and paste artifacts and backgrounds from the pictures that Jim has created in a image software program.

We could assume that Norse did not find a publisher interested in Dorque & Imp, and after the studio released Legend of Myra (for PC), it seems that they had to close down.

Super Nintendo games are now being developed in Sweden!

We are used to thinking that Nintendo games are being developed in Japan, USA or England. Maybe sometimes a stumbler from France or Germany, but the fact that söta bror (=kind brother, Norwegian nickname for Sweden) would make a game for Nintendo is something few would dream of. But right now, the first Swedish SNES game is being developed in this basement location in Stockholm.

Dorque & Imp will be an elegant platformer with 4 worlds, a plethora of items and countless enemies. The clever Dorque is an apparentice of a rather sketchy wizard, and a showdown between the two is inevitable.
-The end will be fair, says Peter Wahler, who is responsible for the programming.
-To begin with we just thought we should get used to the computer and the technique that goes into making video games, but we caught on so quickly that we decided we dared start making our own game, says Jim Studt, the person responsible for the graphics.

Together with the Tv-Spill Börsen (=Video Game Stockmarket), who today funds their project, they are in the midst of founding their own company, Norse, which marks the beginning of a new softwarehouse. They contacted overseas companies for production and marketing of the game at this spring's convention in England

Cheated by Pc Games
-It's gonna be different now, compared to the PC games i have worked on. We who were involved with Legend of Myra were fooled completely. The publisher, Grand Slam has yet to pay us a single dime, Jim says. Dorque and Imp consists of 4 worlds, where Dorque sets out to find as many items as the wizard needs to become allmighty.

2 of the worlds are completed. When Power Player catches up with the team of programmers, they are already hard at work to finish up the demo that will be shown in England. Peter shows us how far they are come. He has 100 000 command lines which helps him to quickly change the envoirment on the screen. He is programming in assembler, and can in principal cut and paste artifacts and backgrounds from the pictures that Jim has created in a image software program.

Two other guys are part of the team, one of them for the music. It looks so simple and fun to make a video game. -The truth is that most of the work up till now has been hard. And also you can't see it - only if it's not working, Peter explains. - The hardest part is making colored pictures that can be used in as many places as possible. We always have to remember that the game can't take up too much memory, memory is expensive, Jim explains.

Not that many colors afterall.
Why are you making a game for Nintendo and not Sega?

-Nintendo's 256 colors versus Sega's 64, Jim answers quickly, but he does admit he is dissapointed he has to settle with less colors because of memory and time issues.
- There is 2 high thresholds you have to overcome before you start creating games. First you have to obtain Nintendo's programming manuals, which explains how you get started. These manuals are only available at "certified" game developers, and you have to know one of these.

Just as big of a problem is the software that automates the coding. This is business secrets on the highest level, and it's there Peter with his math and info education has done everything from bottom up. These tools can be used over again for future games...

Stockholm-game?
The advantage of starting out on your own is that you learn from your mistakes, find your own and maybe groundbreaking solutions and most of all get new ideas from the development. For Dorque & Imp's graphical world Jim has been inspired by Tolkien's fantasy world, and spiced it with a few nordic elements.

-It may have gotten some viking inspiration. We had the idea of including Odin to one of the worlds, even though Nintendo only allows the use of Greek gods to be used in games on their systems. But we can always rename him.
-We have begun thinking about doing a sequel. It would be fun to make something that has it's story lifted from Stockholm, where you could go our shop here and say hello to us, Peter laughs.


Screenshots:

Imagen Imagen Imagen

Imagen Imagen Imagen

Imagen Imagen Imagen

Imagen

Preview:
(Click in the images to enlarge)
Imagen Imagen


Dragon Warrior V
Dragon Warrior V was to be the first DW game released on the SNES. For whatever reason, Enix never released it outside of Japan.

Imagen

Dragon Quest is an incredibly popular franchise in Japan, and all four of the series released on the Famicom came out on the NES in the US. The assumption was that the fifth game in the series would make it out in the US as Dragon Warrior V, but it was never released.

Imagen


Bibliography:

    · Nintendo Power, Only In Japan - Games That Never Made it to America, Publication date: January 1994, Volume: 56, Pages: 66


Dragonfly (Pilot Wings)
Imagen Imagen

Imagen Imagen

Imagen Imagen

Imagen


Dream Probe
Publisher: Renovation Products
Developer: Riot
Game ID: DP
Players: 1
Release: Scheduled for 1993
Genre: Action
Released: Japan (as Psycho Dream)

Dream Probe was planned for release sometime in 1993-1994. This was another Telenet game that was being planned for release in the US. This game is a side-scrolling action game featuring a main character with a sword-like weapon. Like other Renovation games, it was likely not released due to the fact that Renovation was bought by Sega. The February 1993 issue of Nintendo Power mentioned this game. The January 1994 issue of Nintendo Power lists it as having a release during September 1993, though obviously this is incorrect.

Box scan from half.com:

Imagen


Bibliography:

    · Nintendo Power, Pak Watch Update, Publication date: February 1993, Volume: 45, Pages: 112
    · Nintendo Power, Super Nintendo Entertainment System Power Index (release list), Publication date: January 1994, Volume: 56, Pages: 2


Eurit
Eurit is an action game that was being developed by Radical Entertainment. It eventually was retooled and released on various 32 bit platforms as Grid Runner. A prototype rom has been dumped, and I will look at this casualty of the end of the 16-bit era

Thanks to Ballz, rbudrick, and Gideon Zhi for dumping these roms, and to Skrybe for sending them my way.

Imagen

Eurit is an action game that was being developed by Radical. The game is basically a souped up version of childhood games of Tag and Capture the Flag. The game features a split-screen and is an ideal two player game. A near complete beta of this game was discovered by DreamTR, and it is probably one of the best unreleased games for the snes.

The story behind the game is that the ruler of the galaxy decides that he will retire. In order to find a suitable replacement, he sets up a tournament where wizards and warriors compete to determine who shall be ruler. Throughout the game, you travel to many worlds across the galaxy to prove your might.

There are four characters to chose from at the start of the game. Each has their own strengths and weaknesses, based on their speed, spellcasting agility, and magic capacity. Through my playthrough, I used the average character.

Imagen

The gameplay is very addictive, and relatively easy to get into. Basically, one of the characters starts off being "it". The person who is it cannot capture flags, so they must chase down the other character and touch them. Once you are not it, you can collect flags necessary to win the stage.
Complicating the game is the obstacles you face. To proceed through the level, you basically have to build platforms. There are many levels with enemy creatures that usually require a number of blasts with your gun to kill. Speed tiles send you running really quickly, which can either make you quickly escape your foe, or send you far away from him.

Imagen

Probably the most compelling gameplay feature for experts is the magic system. Before each level, you learn a new magic spell. Some spells are mundane, like destroying a platform, but others can devistate your opponent, like the spell that causes all the creatures in the level to attack your opponent. Powerup balls throughout the level allow you to charge your magic meter.

The music is pretty typical "sci-fi game" fare, comparible to games like Blackthorne, B.O.B., and The Lost Vikings. The sound effects are somewhat muted, though the voice that tells you "player 1 is now it" is really well done. The graphics aren't anything too special, but they do the job.

On the whole, I liked this game. Had it been released, it would be an instant 2-player classic. The controls are a bit touchy, though not terrible. I really liked the thrill of chasing your opponent down and make him "it".

One caveat about this prototype is when you die. Although there is a password system, the game tends to crash after the death scene. I guess that is why they call it a prototype. Or perhaps it is just a problem with the emulator.

I asked Darren Schebek, a programmer who worked on the game about why it was never released:

"Radical tried very hard to find a publisher for Eurit (it was an original project being developed in-house), but in the end decided that the SNES market was kaput and canned the project very close to the end of development in order to cut their losses. Instead, they adapted the game for the newer platforms. The new, pseudo-3D version became Grid Runner on the PS1, Saturn, and PC. They later created another game

DreamTR owns a prototype of this game, and has taken some shots of it. Oddly enough, the prototype cart says "property of Electronic Arts", suggesting that they may have been interested in publishing it.

Imagen




More images:

Imagen Imagen Imagen

Imagen Imagen Imagen

Imagen Imagen Imagen

Imagen Imagen Imagen

Imagen Imagen

Imagen Imagen


ExoSquad
ExoSquad was released on the Genesis by Playmates. It is a futuristic action game based on a cartoon. This shot was taken from the German magazine Nintendo Fun Vision (issue 7). It appears that a snes version was planned, but subsequently axed.

Scan courtesy of hydr0x:

Imagen




Fuente: SNEScentral & Google






ImagenVolver a la página principal.
Che_Guevara escribió:
Only16bits escribió:En Europa:

Joe & Mac
Congo's Caper (Joe & Mac 2)
Joe & Mac 3 Lost In The Tropics

Creo que ya lo preguntaste hace un tiempo y aun está por ahi el hilo.



Creo que no,o no me acuerdo de hacer un post de dicho tema.


Te confundí con Daniels, pero si recordaba que existia este hilo de no hace mucho
hilo_duda-joe-amp-mac-2-snes-pal_1388699

El Daze Before Christmas si que salió no?
Only16bits escribió:
El Daze Before Christmas si que salió no?

No, solo se hizo el de MD aunque solo salio en Australia..........

Por cierto, yo añadiria a la lista el dinamyte headdy que segun gamefaqs estaba pensado en un principio para SNES tambien
ryo hazuki escribió:No, solo se hizo el de MD aunque solo salio en Australia..........


Si, eso pone en el articulo, pero es que además el motivo por el que no salió tiene guasa...

"Daze took about 1 year in total, but the problem was I didn't start until 6 months into the project so I had a lot of art and the code from A Dinosaur's Tale to combine, the SNES version was converting the same code that was already on Genesis so it took me about 6 months (I was on the Genesis version and there was one programmer on the SNES version). Unfortunately Sunsoft USA ran out of money and went bankrupt about the same day the SNES version was finished."

ryo hazuki escribió:Por cierto, yo añadiria a la lista el dinamyte headdy que segun gamefaqs estaba pensado en un principio para SNES tambien


Perfecto, gracias por el dato, investigaré al respecto a ver que consigo.

...pero ahora no, después del partido XD
una duda ¿que tal es el juego OPERATION STARFISH pal snes ? es que me lo venden por 30 € completo que tal el precio
2359 respuestas
13, 4, 5, 6, 748