"Magic Floor" primer juego Homebrew para PlayStation SNES-CD

Se trata de un sencillo juego de ajedrez, anteriormente versionado en otras consolas y ordenadores.. Tambien funciona bajo el sistema Satellaview. Ojalá dentro de pocos años podamos ver juegos que aprovechen todo el potencial de este sistema.

http://www.retrocollect.com/News/the-ve ... eased.html

http://forums.nesdev.com/viewtopic.php? ... 45#p166176

Imagen


Imagen


Imagen


A few weeks ago we broke the news that the fabled Nintendo PlayStation / SNES-CD’s BIOS had leaked onto the internet. After sparking plenty of interest and leaving many wondering about its legitimacy, the brains behind the emulation scene have managed to reverse engineer its very core. As a result we’re impressed to say that the first playable game for the system will be hitting your emulators soon.

As it stands we’re yet to see an authentic SNES-CD game disc surface, nevermind actually obtaining any playable code. While there are plenty of rumoured titles out there and even suggestions that a game disc could be in collector’s hands, the whole SNES-CD saga to date has been focused on the hardware alone. While this has left homebrew developers in a tricky situation, the creator of the NOCASH emulators has somehow managed to decipher how the hardware’s BIOS/system cart was supposed to work.

According to the most recent post from Martin Korth on the NESDev forums, the upcoming release of NO$SNS (The NOCASH Super Nintendo emulator) will feature support for the long lost hardware. This includes being able to simulate discs being inserted and ejected, along with access to what appears to be a built in memory management - similar to PlayStation memory cards.

Following on from this research, the NOCASH developer has further proved that the prototype system found is the real deal by porting his homebrew release Magic Floor to the SNES-CD. Although this version of the game can now be downloaded, the updated version of NO$SNS is yet to be released, leaving Magic Floor CD currently unplayable. At the same time, it’s worth noting that this homebrew release is very much a proof of concept to show that the BIOS/system cartridge for the SNES-CD is indeed authentic and working just fine.

While we may never know how powerful the system could have been, this homebrew release is potentially the start of something bigger… and something hopefully backed up by the arrival of those long lost game discs. In the meantime, there's always the fantastic MSU-1 development scene which also offers 'CD quality' Super Nintendo enhancements.



Saludos
Veamos...

Así que tenemos las especificaciones técnicas del CD de la snes confirmadas... tenemos hardware real que confirma el funcionamiento de este software... y tenemos una escena capaz de crear hardware nuevo si es necesario (MSU1).

¿Alguien mas piensa que el primero que fabrique este hardware (ingeniería inversa, probablemente) va a vender como churros?.


Yo aprovecharía, y metería el MSU1 con una buena cantidad de ram, porque así además de permitir mapear la memoria de un DVD, habilitaría un procesador de sonido extra (compatibilidad con esa scene), o la emulación de chips especiales para un extra de computación.
Bueno yo creo que ya con el MSU1 honestamente es como tener la snes-CD.

Sin embargo mas alla de meter musica en CD, que a veces honestamente desentona incluso, no he visto nada mas, quizas lo mas interesante el a Link to the past con la intro y todo.

Pero en mi caso no me gusta cuando hacen eso, porque el juego original se optimizo y se concibio para un HW especifico, el sonido esta hecho a medida y todo.

Seria interesante es ver nuevos proyectos desarrollados especificamente para ese chip, pero dudo mucho que veamo algo al respecto con toda honestidad.
pues a mi todo esto cada vez me suenamas a chino!
resulta que hay un tipo que asegura que tiene un prototipo... vale...
y ahora resulta que como teoricamente se conocen las especificaciones tecnicas, se sacan un emulador del bolsillo y empiezan ha hacer juegos... esto cada vez me huele peor.

como se puede hacer un emulador de un hardware que apenas hay 4 fotos? habran vendido el prototipo por una burrada de pasta ?
Quizas porque ese unidad no agregaba potencia extra a la consola sino simplemente mas espacio?

O en caso de agregar mas potencia quizas era mas potencia al sistema central, como decir va 3Mhz y con el addon ahora va 20Mhz lo cual es facil de interpolar rapidamente.

Pero claro esas son elucubraciones mias nada mas
AlbertX escribió:Pero en mi caso no me gusta cuando hacen eso, porque el juego original se optimizo y se concibio para un HW especifico, el sonido esta hecho a medida y todo.


Ahí te equivocas. La gran mayoría (y digo el 99% de los títulos), infrautilizan enormemente el spc700.

AlbertX escribió:Seria interesante es ver nuevos proyectos desarrollados especificamente para ese chip, pero dudo mucho que veamo algo al respecto con toda honestidad.


Imagina un juego en el que puedes poner cuatro planos por hardware, transportados a una velocidad de 9MB/s (81 megabits), y que dada esa tasa de ancho de banda durante cada frame de animación puedes tener totalmente renovada los datos de la VRAM (a esta capacidad potencial hay que restarle la latencia cada "equis" ciclos, que no aceptaría ni borrado ni llenado, pero eso sucede casi de forma anecdótica en comparación).

Imagina que los 64KB de la ram del spc700 (en realidad 63.5KB, porque las tablas de su programación se almacenan ahí en cuánto enciendes la máquina), y los 8 canales de sonido, se utilizan exclusivamente para los efectos de sonido y las voces (es mas de lo que ma la mayoría de los arcades dedicaban). Todo tendría mas calidad, y ninguna voz o efecto de sonido solaparía a ninguna otra.

Imagina que usas el MSU1 para meter música de alta calidad (no hace falta que sea calidad CD, puedes poner por ejemplo chiptune de alta calidad, como la banda sonora del sunset riders, las de neo geo, y un largo etcétera).

Y por último, imagina poder hacer que todo eso funcione en una rom de hasta 4GB, en bloques de 128 megas (el máximo que la snes puede direccionar de una vez).


Si unes todo eso, al tonto a lo tonto, te podría salir una cosa muy, muy parecida a un metal slug.

jordigahan escribió:y ahora resulta que como teoricamente se conocen las especificaciones tecnicas, se sacan un emulador del bolsillo y empiezan ha hacer juegos... esto cada vez me huele peor.


Se filtraron los planos y las especificaciones. Es algo que ha podido ver todo el mundo.
Señor Ventura escribió:
AlbertX escribió:Pero en mi caso no me gusta cuando hacen eso, porque el juego original se optimizo y se concibio para un HW especifico, el sonido esta hecho a medida y todo.


Ahí te equivocas. La gran mayoría (y digo el 99% de los títulos), infrautilizan enormemente el spc700.

AlbertX escribió:Seria interesante es ver nuevos proyectos desarrollados especificamente para ese chip, pero dudo mucho que veamo algo al respecto con toda honestidad.


Imagina un juego en el que puedes poner cuatro planos por hardware, transportados a una velocidad de 9MB/s (81 megabits), y que dada esa tasa de ancho de banda durante cada frame de animación puedes tener totalmente renovada los datos de la VRAM (a esta capacidad potencial hay que restarle la latencia cada "equis" ciclos, que no aceptaría ni borrado ni llenado, pero eso sucede casi de forma anecdótica en comparación).

Imagina que los 64KB de la ram del spc700 (en realidad 63.5KB, porque las tablas de su programación se almacenan ahí en cuánto enciendes la máquina), y los 8 canales de sonido, se utilizan exclusivamente para los efectos de sonido y las voces (es mas de lo que ma la mayoría de los arcades dedicaban). Todo tendría mas calidad, y ninguna voz o efecto de sonido solaparía a ninguna otra.

Imagina que usas el MSU1 para meter música de alta calidad (no hace falta que sea calidad CD, puedes poner por ejemplo chiptune de alta calidad, como la banda sonora del sunset riders, las de neo geo, y un largo etcétera).

Y por último, imagina poder hacer que todo eso funcione en una rom de hasta 4GB, en bloques de 128 megas (el máximo que la snes puede direccionar de una vez).


Si unes todo eso, al tonto a lo tonto, te podría salir una cosa muy, muy parecida a un metal slug.

jordigahan escribió:y ahora resulta que como teoricamente se conocen las especificaciones tecnicas, se sacan un emulador del bolsillo y empiezan ha hacer juegos... esto cada vez me huele peor.


Se filtraron los planos y las especificaciones. Es algo que ha podido ver todo el mundo.


Quizas fue infrautilizado, pero a lo que me refiero es que el juego se diseño pensando en unas limitaciones X, los ejemplos que he visto simplemente no me cuadran esa musica con esos graficos y no porque sea instrumental, sino porque esta claro que la musica no se hizo para acompañar al juego sino es una pieza musical.

Sobre lo segundo es que yo no niego la calidad de lo que podria hacerse, lo que dudo es que alquien haga nada.
AlbertX escribió:Quizas fue infrautilizado, pero a lo que me refiero es que el juego se diseño pensando en unas limitaciones X, los ejemplos que he visto simplemente no me cuadran esa musica con esos graficos y no porque sea instrumental, sino porque esta claro que la musica no se hizo para acompañar al juego sino es una pieza musical.


Pero es que ya digo, que puedes sustituir la música en calidad CD por otros ejemplos que suenen a chiptune, solo que de gran calidad.

Por ejemplo, puedes ponerle al F-xero un cover de música real pregrabada, o puedes poner un remaster basado en chiptune, pero que suene a una altísima calidad (como sonaría por ejemplo la propia super nintendo si tuviera 256KB de ram, en vez de los 64 que lleva, y añadirle montones de matices y profundidad). Al MSU1 le da igual lo que le metas, si es calidad CD, o si es un WAV con una canción de la atari 2600.

AlbertX escribió:Sobre lo segundo es que yo no niego la calidad de lo que podria hacerse, lo que dudo es que alquien haga nada.


El día que exista una herramienta que genere por si sola el código en ASM, sin tener que pelearte gran cosa con el mismo (porque nunca podrá optimizar al 100% por si solo), y preocupándote de decirle al programa únicamente que gráficos quieres, y como los quieres, además de la música y otros detalles, surgiran juegos a punta pala.

Metes los sprites, y el programa se encarga solito de trocearlos... o implementas un tipo de rutina para la IA, tipo plantilla (entre varias disponibles)... o un engine pre-generado para meter datos a partir de ahí.

Por ejemplo, que funcione de forma modular, de la misma forma que funciona el BOR para con los gráficos, pero con IA's, engines, etc (para shoot'em ups, brawlers, o rpg's).

Se lo que me vas a decir, pero es una opinión que la escena debe apuntar hacia esta dirección para que puedan surgir los contenidos.
Vamos y de la placa arcade CPS3 que tenía una década y había especificaciones y diagramas los dumpeadores y mame team ni jodida idea de como hacer un emulador y hacerlos correr....estos de ya en menos tiempo ya hasta sacaron emulador y juego....
AlbertX escribió:Quizas porque ese unidad no agregaba potencia extra a la consola sino simplemente mas espacio?

O en caso de agregar mas potencia quizas era mas potencia al sistema central, como decir va 3Mhz y con el addon ahora va 20Mhz lo cual es facil de interpolar rapidamente.

Pero claro esas son elucubraciones mias nada mas


Se me olvidó comentar que no es así. El snes CD añadía una cpu de 32 bits a 21mhz, aunque parece ser que hacía las veces de coprocesador junto con el 65816 de snes. Contaba con 1MB de ram principal (8 megabits), 512KB de ram secundaria (4 megabits), y un sistema patentado que mejoraba la transferencia de datos, o algo así.

Vamos, que no añadía solo capacidad. Lo que no se, es que tipos de efectos gráficos podría haber llegado a mostrar ese hardware, pero pocho, lo que se dice pocho no era.
Eso no lo sabia, interesante de verdad, lo que pudo haber sido si hubiera seguido por esa via.

Creo que usar cartuchos para la N64 fue el inicio de su declive, luego no quiso usar DVD en la gamecube.

Si la Snes hubiera sacado el CD addon creo que habria sido una consola aun mas legendaria, con ese aumento de velocidad muchos arcades hubieran sido porteados directamente y la N64 hubiera sido seguramente con CD y no con cartuchos.
atreyu_ac está baneado del subforo por "faltas de respeto"
Señor Ventura escribió:
AlbertX escribió:Quizas porque ese unidad no agregaba potencia extra a la consola sino simplemente mas espacio?

O en caso de agregar mas potencia quizas era mas potencia al sistema central, como decir va 3Mhz y con el addon ahora va 20Mhz lo cual es facil de interpolar rapidamente.

Pero claro esas son elucubraciones mias nada mas


Se me olvidó comentar que no es así. El snes CD añadía una cpu de 32 bits a 21mhz, aunque parece ser que hacía las veces de coprocesador junto con el 65816 de snes. Contaba con 1MB de ram principal (8 megabits), 512KB de ram secundaria (4 megabits), y un sistema patentado que mejoraba la transferencia de datos, o algo así.

Vamos, que no añadía solo capacidad. Lo que no se, es que tipos de efectos gráficos podría haber llegado a mostrar ese hardware, pero pocho, lo que se dice pocho no era.


¿Y qué CPU era esa? Una CPU de 32 bits a 21Mhz, pero ¿qué arquitectura? No encuentro nada al respecto.
atreyu_ac escribió:¿Y qué CPU era esa? Una CPU de 32 bits a 21Mhz, pero ¿qué arquitectura? No encuentro nada al respecto.


RISC.

Su función era la de proporcionar computación algoritmica. No habían upgrades gráficos, ni paletas de 16 millones de colores, ni tropocientos colores en pantalla, ni mas de los 128 sprites que la snes podía manejar de por si... en definitiva, el snes cd habría sido lo que era la snes... con sus 256 colores en pantalla, con su paleta de 32.000 colores, etc, etc, etc.

Lo que ocurría, es que ahora los juegos podían pesar 500 y pico megas, aportaba un DMA muy mejorado que llevaba los gráficos directamente a la VRAM de la snes a partir de los 8 megabits de ram del SNES CD... pero además con otra ventaja, y es que la lectura desde el cd era un streaming sin que nada se detuviese, por lo que esos 8 megabits siempre podrían estar actualizándose para mandarle cosas a la snes.

Y luego está el RISC a 21mhz, que aportaba poder de computación a modo de chip de apoyo, solo que tendría que hacerse por software. ¿Que haces un port del art of fighting?, pues de la lógica del juego se encarga el 65c816, del proceso de scaling de sprites el RISC del snes CD (programado por software), del scaling del plano se encargaría el modo 7 del PPU (o el mismo risc, porque por potencia seguro que no sería), de la música el arranged del CD, y de los sonidos los 8 canales del spc700 con sus 64KB (ahora mismo no recuerdo si aportaba mas canales)... y todo sin la limitación típica de tener que cargar todo de golpe, de tener que sufrir parones, y sin la limitación de no poder ejecutar mas datos de lo que hayas podido cargar en la ram.
Señor Ventura escribió:Su función era la de proporcionar computación algoritmica.


What?
atreyu_ac está baneado del subforo por "faltas de respeto"
Señor Ventura escribió:RISC.



What? :D

Tio, es todo muy loco. ¿Cómo que arquitectura RISC? RISC es una clasificación de arquitecturas de esa época según el juego de instrucciones, no es una arquitectura.
El resto de la explicación, hombre, se agradece mucho, pero yo no he visto una unidad óptica haciendo streaming de tiles y sprites a la VRAM mientras un juego se mueve jamás. Que no digo que no sea cierto que quisieran hacer eso, pero es una cosa muy rara que no se ha visto hasta donde yo sé.
Pero en serio, lo de la CPU esa de la que nadie sabe nada más que generalidades me tiene mosca. Para mi que lo que iba a ir como coprocesador matemático en el SNES CD este iba a ser lo que acabó siendo el SuperFX o el SuperFX2, que hasta donde yo sé no es más que un multiplicador de matrices para transformaciones geométricas. Y ya.
Pues que si quieres scaling --> RISC del snes CD
Si quieres poner 17 planos de scroll --> de 13 se encarga el tío.
Si quieres una IA compleja --> Ahí va el RISC pa lo que usté mande.
Si quieres físicas, cálculo de polígonos, voxels, deformaciones, o cualquier cosa que se te pueda ocurrir, ahí tienes potencia de proceso para ejecutarlo por software, vía RISC del snesCD.

Lo que no puede hacer, es poner mas de 256 colores en pantalla, mas de 128 sprites simultáneos, mas de los 8 modos gráficos de la snes, ni en defintiva, nada que aporte otra base que no sea la que aporta la snes.


editado:

atreyu_ac escribió:Tio, es todo muy loco. ¿Cómo que arquitectura RISC? RISC es una clasificación de arquitecturas de esa época según el juego de instrucciones, no es una arquitectura.


No te compliques, el chip era un RISC, sea cual fuese su arquitectura.

atreyu_ac escribió:El resto de la explicación, hombre, se agradece mucho, pero yo no he visto una unidad óptica haciendo streaming de tiles y sprites a la VRAM mientras un juego se mueve jamás. Que no digo que no sea cierto que quisieran hacer eso, pero es una cosa muy rara que no se ha visto hasta donde yo sé.


Eso no es cosa mía. La máquina hacía uso de un sistema llamado "HANDS", con el cual se optimizaba el proceso de lectura del cd mas o menos de la forma mencionada.

atreyu_ac escribió:Pero en serio, lo de la CPU esa de la que nadie sabe nada más que generalidades me tiene mosca. Para mi que lo que iba a ir como coprocesador matemático en el SNES CD este iba a ser lo que acabó siendo el SuperFX o el SuperFX2, que hasta donde yo sé no es más que un multiplicador de matrices para transformaciones geométricas. Y ya.


No. La cpu RISC del snes cd, es justo lo que iba a ser. El SFX era un chip que durante la etapa de desarrollo de la snes se planeó para que fuese el tercer PPU de la consola, pero la fabricación se alargó, y decidieron sacar la super nintendo sin esa mejora.

Y añado, el SFX1 es en realidad el SFX corriendo a la mitad de velocidad, direccionando la mitad de memoria, y creo que con algún problema en algunas instrucciones. El SFX2 es el verdadero chip SFX (o chip MARIO).
atreyu_ac está baneado del subforo por "faltas de respeto"
Pero es que sigo sin saber qué arquitectura implementaría ese RISC: ¿Un ARM de la época quizá? Era lo más burro en RISC por entonces, si pillas un Acorn Archimedes verás cómo mea en potencia de CPU para juegos a todo lo que había en, digamos, 1992. (En el ámbito casero, no me salte nadie al cuello con una SGI, que sí que ya, pero quitando a la niña repelente de Jurassic Park nadie tenía eso en casa...)
¿O quizá un MIPS? Sony acabó tirando por esa arquitectura en solitario y también eran RISC. ¿Alguna otra cosa? ¿Se sabe algo más de esta CPU?

Algo como esto es la respuesta que busco:

https://en.wikipedia.org/wiki/R3000

Pero no esto, sino la CPU que realmente se iba a usar o que está en el "protopito" ese de marras.

EDITO en respuesta a tu edición: ¿Cómo va a ser el SFX o el SFX2 una PPU si no hace más que multiplicar matrices el pobre?
Es que no se nada mas... en los planos no se especificaba, creo recordar. Ojalá supiera yo que calse de cpu era, para saber cuánto podría dar, pero no es el caso.

Era una cpu RISC, eso es todo lo que se.

editado:

atreyu_ac escribió:EDITO en respuesta a tu edición: ¿Cómo va a ser el SFX o el SFX2 una PPU si no hace más que multiplicar matrices el pobre?


El sfx es un microprocesador de propósito general, y si que iba a formar parte del sistema gráfico de la snes. ¿Como se come eso?, pues porque este tercer PPU no aportaría ninguna función en concreto (como el modo 7, las transparencias, o el manejo de sprites), sino la posibilidad de apoyar a la cpu con mas computación (de hecho el PPU1 ya lo hace, aportando instrucciones para multiplicar).
Solieyu escribió:Vamos y de la placa arcade CPS3 que tenía una década y había especificaciones y diagramas los dumpeadores y mame team ni jodida idea de como hacer un emulador y hacerlos correr....estos de ya en menos tiempo ya hasta sacaron emulador y juego....


si no me equivoco la CPS3 tardo mucho tiempo en tener emuladores funcionales no por sus prestaciones tecnicas en si, sino por el cifrado de sus juegos (corrijanme si me equivoco)
Pues ya tenemos emulador que emula al snes cd y está en http://problemkaputt.de/sns.htm por si alguién quiere probar con el único juego homebrew que, por ahora, sólo hay para esta plataforma unrealesed
Es el no$sns y obviamente es la última versión la 1.6 la que añade dicha posibilidad entre todas estas cosas.
Hay documentacion entonces sobre su cpu?.
A mi lo que me parece es que el juego es feo con ganas XD
Señor Ventura escribió:Hay documentacion entonces sobre su cpu?.


¿Cuál CPU? :-?

Al menos este SNES CD es una simple unidad de CD.
Utiliza un cartucho con el bios, ram y algun detalle más que no recuerdo.
Por eso fue "tan sencillo" (pongo entre comillas porque aún así debe haber costado lo suyo) de emular. Cuando se dumpeó el bios se estudió el código desensablado para terminar de entender el funcionamiento.

Dudo mucho que sea algún tipo fake u hoax.
puch666 escribió:¿Cuál CPU? :-?


Pues el risc de 32 bits que lleva el prototipo real, ¿no está basado en eso el emulador?.
Señor Ventura escribió:
puch666 escribió:¿Cuál CPU? :-?


Pues el risc de 32 bits que lleva el prototipo real, ¿no está basado en eso el emulador?.


El prototipo que apareció hace poco, y de donde salió el bios, no aportaba ninguna CPU extra a la SNES.
Pero es que eso no tiene sentido, el snes cd lleva una cpu risc de 32 bits a 21mhz, no hay otra...
Menudo pedazo de mierda
@atreyu_ac

Lo más bruto eran los pa-risc
atreyu_ac está baneado del subforo por "faltas de respeto"
Pek escribió:@atreyu_ac

Lo más bruto eran los pa-risc


...que conocemos de casualidad poque somos amigueros y hubo rumores de que la próxima generación de Amigas usaría esa arquitectura, pero en informática doméstica no hubo nada con pa-risc, y yo hablaba de informática doméstica.
Señor Ventura escribió:Pero es que eso no tiene sentido, el snes cd lleva una cpu risc de 32 bits a 21mhz, no hay otra...


Este prototipo, no lleva CPU extra. Creo que existieron varios diseños diferentes para el Snes CD, con las movidas que hubo entre Sony, Phillips y Nintendo. Quizá el que lleva CPU extra no sea este en particular.
Salieron fotos de la placa y es una Snes más la circuiteria para manejar la unidad de CD y el display LCD que lleva en el frente. Incluso varios elementos (bios y algo de ram) van en el cartucho.

Esta versión parecería ser algo así como la wondermega, consola + unidad de CD en una única consola. Se supone que debería haber una unidad por separado para poder agregar a cualquier Snes estándar. Me imagino que por eso el bios y la ram extra van en un cartucho.
puch666 escribió:Este prototipo, no lleva CPU extra. Creo que existieron varios diseños diferentes para el Snes CD, con las movidas que hubo entre Sony, Phillips y Nintendo. Quizá el que lleva CPU extra no sea este en particular.
Salieron fotos de la placa y es una Snes más la circuiteria para manejar la unidad de CD y el display LCD que lleva en el frente. Incluso varios elementos (bios y algo de ram) van en el cartucho.

Esta versión parecería ser algo así como la wondermega, consola + unidad de CD en una única consola. Se supone que debería haber una unidad por separado para poder agregar a cualquier Snes estándar. Me imagino que por eso el bios y la ram extra van en un cartucho.


No, si viendo el cacao que formaron, no me extraña que al final decidieran no sacar nada.

Tal vez la escena nos compense algún día (como si el msu1 fuese algo que suceda todos los días, por otra parte xD).
atreyu_ac escribió:
Pek escribió:@atreyu_ac

Lo más bruto eran los pa-risc


...que conocemos de casualidad poque somos amigueros y hubo rumores de que la próxima generación de Amigas usaría esa arquitectura, pero en informática doméstica no hubo nada con pa-risc, y yo hablaba de informática doméstica.


También hablas de que los ordenadores Archimedes eran la ostia, cuando en este hilo solo se está poniendo en jucio los procesadores.

Personalmente, conozco los Pa-Risc hace muchos años.
32 respuestas