Pregunta sobre el SPC700

Sinceramente , no tengo mucha idea pero hace tiempo en este documento leí lo siguiente:

The memory on the SPC is 64K (kilobytes that is, not kilobits) in size. The DSP is 16-bit and supports eight stereo channels, each independantly pannable Left to Right. Samples sent into the DSP aren't the normal raw smapling used on an Amiga or PC. The samples in the SPC are encoded in a compressed format (I will get more to that later). The designers only placed 32K of RAM into the SPC however, so the upper 32K is unusable.

http://emureview.ztnet.com/developerscorner/SoundCPU/spc.htm

Para probar tu spc en un hardware real , si quieres me puedes mandar el archivo lo pruebo con la Super Nintendo y el Power Pack y te envió una grabación sacada directamente de la Super.

kappa64 escribió:Sinceramente , no tengo mucha idea pero hace tiempo en este documento leí lo siguiente:

The memory on the SPC is 64K (kilobytes that is, not kilobits) in size. The DSP is 16-bit and supports eight stereo channels, each independantly pannable Left to Right. Samples sent into the DSP aren't the normal raw smapling used on an Amiga or PC. The samples in the SPC are encoded in a compressed format (I will get more to that later). The designers only placed 32K of RAM into the SPC however, so the upper 32K is unusable.

http://emureview.ztnet.com/developerscorner/SoundCPU/spc.htm

Para probar tu spc en un hardware real , si quieres me puedes mandar el archivo lo pruebo con la Super Nintendo y el Power Pack y te envió una grabación sacada directamente de la Super.

Entonces está la cosa un poco complicada, 32Kb para samples... En cuanto a lo del SPC, ahora mismo ando con la tarjeta de sonido estropeada, por lo cual he de cambiarla, pero tengo previsto recibir una dentro de unos días, cuando me llegue me pongo manos a la obra y aver que puedo conseguir meter en esos 32Kb.

Un saludo y muchas gracias.

68000 escribió:Para aquellos que sepan realmente las limitaciones técnicas: ¿Los 64 KB de ram son completamente usables, o solo puedes usar 32KB entre programa y samples? Por más que busco por la red, algunos dicen que puedes usar toda la RAM, otros dicen que 32KB y así...

He compuesto varias piezas y el resultado es bueno, pero ya se sabe, de emulación a hardware real va un trecho y lo que en un emulador es aceptable, en la realidad cuelga el sistema.

Son usables 63.5KB, el medio kilobyte restante, no se si es código (registros) almacenado para acceder a sus funciones desde el programa principal, o un espacio reservado para ejecutarlas (estando ya imbuidas el el propio spc).


Lo de los 32Kbytes se ha dicho bastantes veces, pero va a ser que no (socram puso un link hace algún tiempo, pero no lo encuentro). Lo mejor es disponer de un everdrive, y probar a almacenar mas de 32KBytes.

Ralph escribió:

68000 escribió:Para aquellos que sepan realmente las limitaciones técnicas: ¿Los 64 KB de ram son completamente usables, o solo puedes usar 32KB entre programa y samples? Por más que busco por la red, algunos dicen que puedes usar toda la RAM, otros dicen que 32KB y así...

He compuesto varias piezas y el resultado es bueno, pero ya se sabe, de emulación a hardware real va un trecho y lo que en un emulador es aceptable, en la realidad cuelga el sistema.

Son usables 63.5KB, el medio kilobyte restante, no se si es código (registros) almacenado para acceder a sus funciones desde el programa principal, o un espacio reservado para ejecutarlas (estando ya imbuidas el el propio spc).


Lo de los 32Kbytes se ha dicho bastantes veces, pero va a ser que no :) (socram puso un link hace algún tiempo, pero no lo encuentro). Lo mejor es disponer de un everdrive, y probar a almacenar mas de 32KBytes.

Preguntaba lo de los 32kb porque en SNES hay que tener todo planificado desde un principio, si diseñas una canción con 50kb por ejemplo y luego resulta que solo entraban 32, pues hay que volver a cambiar las cosas, era para estar seguro.

Entonces al final mi idea era exportar el SPC, despúes crearía un reproductor en un SMC y pasarlo por el BSNES, a ver qué ocurría. Sabiendo eso, creo que voy a usar casi toda la RAM, gracias :)

Haz una prueba y sales de dudas, pero vamos, parece ser que las direcciones de memoria indican que están disponibles los 63.5KB

Magno seguramente sepa mas sobre todo esto. De todos modos, a parte de que hay pruebas al respecto, luego está el factor "coherencia"... si nintendo tuviera planificado usar solo 32KB para su SPC, no se hubiera gastado el dinero en meter unas memorias mas grandes (lo cual incrementa el coste).

El 64KB por supuesto no va a estar disponible, ya que el DSP usa parte de esa memoria para almacenar el efecto de eco, y luego además hay que meter el interprete (tracker) de las canciones

Los registros están almacenados en 0.5KB, como ya digo... son unos 4K de datos, como mucho.

Entonces es seguro que tenemos 64KB, es algo que había leido pero quería confirmarlo al 100%. Por otra parte, también sabía lo de la reverb, pero nunca la he usado, prefiero hacerlo de forma manual y así rascar más RAM.

¿Qué tal unos 50 KB en samples? supongo que en casi 14KB podriamos almacenar el driver o cualquier cosa que se necesitara, no?, porque en este caso no estoy contando con los efectos de sonido.

Así que, la cosa queda en que kappa64 me probaría en hardware real el SPC y a ver como avanzaría la cosa, también escribiría un pequeño tutorial para ilustrar a todo aquel que quiera saber como va esto.

68000 escribió:Entonces es seguro que tenemos 64KB, es algo que había leido pero quería confirmarlo al 100%. Por otra parte, también sabía lo de la reverb, pero nunca la he usado, prefiero hacerlo de forma manual y así rascar más RAM.

No vas a rascar mas RAM. El SPC no engorda los samples, los reproduce con reverb en tiempo real.

68000 escribió:¿Qué tal unos 50 KB en samples? supongo que en casi 14KB podriamos almacenar el driver o cualquier cosa que se necesitara, no?, porque en este caso no estoy contando con los efectos de sonido.

En esa RAM solo se van a ocupar 0.5KB, y con ello ya tendremos acceso a todas sus funcionalidades.

Aclaremonos (que a mi me ha hecho falta tambien, y seguramente necesite ser corregido ). El SPC es, por así decirlo, un intermediario que reserva 0.5 KB en su propia RAM, para hacer llamadas a los 6 registros con los que opera internamente... este SPC puede ejecutar hasta 256 opcodes, y con toda esta tralla, se comunica con el DSP, que es el verdadero monstruo que permite sonido de 16 bits y 32Khz de muestreo.

Los registros internos del SPC, son los que indican al DSP cómo hacer el panning de voces, el efecto de eco (o reverberación), el envolvente acustico (efectos de fading off/fading on, bucles, control de tempos, balances, etc)... tambien permite el uso de ruido como fuente de sonido... y alguna cosilla mas, como la de acumular 16 bits con un multiplicador, razón fundamental para que el DSP opere a 16 bits, ya que tiene un sistema de ficheros de 8(bits).

La comunicación entre el SPC y el DSP, se raliza mediante E/S mapeada en memoria, razón por la cual es necesario ocupar RAM, sin embargo, la lógica ya está embebida dentro del SPC, por lo que las llamadas, y su proceso, se realizan al vuelo sin ocupar espacio, y ciclos de reloj del 65C816.


Los congelamientos llegan cuando la CPU introduce el paquete de instrucciones en esa pequeña porción de la RAM del SPC (junto con toda la serie de samples nuevos a ejecutar), ya que tiene que esperar a que el SPC libere el bus antes de poder escribir. Es un micro de 8 bits, así que tarda el doble de tiempo en hacerlo.

Llamada de la CPU -> SPC ocupado, el multiplicador mantiene ocupado el bus todavía durante otro ciclo mas -> se libera el bus -> CPU escribe en RAM -> deja de haber comnicación entre SPC y DSP (se produce un silencio/congelamiento) -> CPU libera bus -> se retoma la comunicación entre SPC y DSP, y la CPU vuelve a sus tareas -> El programa prosigue con normalidad.

Recordemos que un programa llega a congelarse, únicamente cuando, por una mala gestión, o por necesidades de fuerza mayor (por una planificación obligada en una escena del propio programa), todo el conjunto de instrucciones y llamadas tenga que renovarse, junto con toda una serie de samples nuevos. Es decir, que si se hace paulatinamente, se puede evitar... o en su defecto, aprovechar un cambio de escenas (momento en que la pantalla se suele quedar en negro).


Hay una pequeña duda que tengo. ¿Una fuente de sonido debe ser comprimida por el programador al almacenarse en el cartucho?, o el SPC permite aplicar un filtro en tiempo real para reducir su bitrate, "al vuelo", justo antes de guardarlo en su propia RAM.

68000 escribió:Así que, la cosa queda en que kappa64 me probaría en hardware real el SPC y a ver como avanzaría la cosa, también escribiría un pequeño tutorial para ilustrar a todo aquel que quiera saber como va esto.

Pues mira, si, eso estaría genial. Antes se me pasó preguntarte a que formato conviertes los samples, con que bitrate, y cómo los comprimes... que programas utilizas, etc.



EDIT: ¿Con samples a 8 bits, y no haciendo falta el uso del multiplicador, se conseguiría que los *posibles* congelamientos durasen la mitad de tiempo?.

68000 escribió:Así que, la cosa queda en que kappa64 me probaría en hardware real el SPC y a ver como avanzaría la cosa, también escribiría un pequeño tutorial para ilustrar a todo aquel que quiera saber como va esto.

Mándame un MP con el SPC cuando quieras.

Ralph escribió:No vas a rascar mas RAM. El SPC no engorda los samples, los reproduce con reverb en tiempo real.

Me venía a referir a que el propio efecto (reverb), se lleva una pequeña parte de la ram para llevarlo a cabo, no recuerdo donde lo leí pero lo buscaré despúes y lo pego por aquí si lo encuentro.

Ralph escribió:Aclaremonos (que a mi me ha hecho falta tambien, y seguramente necesite ser corregido XD). El SPC es, por así decirlo, un intermediario que reserva 0.5 KB en su propia RAM, para hacer llamadas a los 6 registros con los que opera internamente... este SPC puede ejecutar hasta 256 opcodes, y con toda esta tralla, se comunica con el DSP, que es el verdadero monstruo que permite sonido de 16 bits y 32Khz de muestreo.

Creía que el SPC700 era totalmente independiente, tu le enviabas las muestras y un programa a ejecutar y lo hacía, corregidme si me equivoco, no estoy totalmente seguro.

Ralph escribió:Hay una pequeña duda que tengo. ¿Una fuente de sonido debe ser comprimida por el programador al almacenarse en el cartucho?, o el SPC permite aplicar un filtro en tiempo real para reducir su bitrate, "al vuelo", justo antes de guardarlo en su propia RAM.

Los samples son almacenados ya comprimidos en el cartucho, luego se cargan en la ram del SPC700 y creo recordar que se descomprimian al vuelo. Curiosamente, recuerdo (y además se recomienda en varios documentos) usar samples de 16 bit en lugar de 8 bit porque la compresión es aún mayor. El samplerate puede ser cualquiera, yo de hecho usaría 44khz en samples muy muy pequeños como ondas simples y luego usaría entre 32-16khz para muestras más grandes (más que nada para ahorrar espacio).

Ralph escribió:Pues mira, si, eso estaría genial. Antes se me pasó preguntarte a que formato conviertes los samples, con que bitrate, y cómo los comprimes... que programas utilizas, etc.

Haré un post por separado para hacer un tutorial en condiciones, porque siempre me ha gustado hacer tutoriales detallados con fotos, no te preocupes.

Ralph escribió:EDIT: ¿Con samples a 8 bits, y no haciendo falta el uso del multiplicador, se conseguiría que los *posibles* congelamientos durasen la mitad de tiempo?.

Intuyo que tendrá algo que ver con el tiempo que se tarda en transferir los datos del cartucho al SPC700, algo así como cuando el SDD-1 descomprime los datos y se los envia a los diferentes componentes (Aunque esto es solo una teoría)

kappa64 escribió:

68000 escribió:Así que, la cosa queda en que kappa64 me probaría en hardware real el SPC y a ver como avanzaría la cosa, también escribiría un pequeño tutorial para ilustrar a todo aquel que quiera saber como va esto.

Mándame un MP con el SPC cuando quieras.

De acuerdo, en cuanto lo tenga listo te lo envio.

---

EDITO:

Aquí está lo de la memoria adicional para el eco, recordaba haberlo leido en algún sitio:

"Echo Delay. 4-bit value that designates both the delay time for the echo, and the size of the echoing buffer. (d*16ms time) (d*2KB memory)"

http://ekid.nintendev.com/snes/spctech.htm

¿Lo ves?, lo he clavado

"8-bit SPC700, runs at ~1Mhz ...with the effective speed being half (each instruction takes a minimum of 2 cycles)"

El acumulador necesita dos ciclos para enviar datos al spc... en realidad la frecuencia del SPC es de 2 mhz, pero claro, tal y como dice el texto, la velocidad efectiva, es como si fuese de 1 mhz, aunque esta es una deducción demasiado hipotética, calculo que no para todo necesite esperar dos ciclos de reloj a la hora de comunicarse con el DSP.


...a lo que vamos, que el efecto de eco no es gratis, pero la llamada al registro, si, ojo. ¿Que es exactamente el echoing buffer?, ¿en que consiste?, ¿que almacena?, ¿modifica el sample a "ecoizar"?.
En vez de crear una copia del sample con ese efecto, lo que hace es dejar "escrita" la manera de hacerlo, que ya entre el SPC y el DSP se encargarán de hacerlo al vuelo.

68000 escribió:Me venía a referir a que el propio efecto (reverb), se lleva una pequeña parte de la ram para llevarlo a cabo, no recuerdo donde lo leí pero lo buscaré despúes y lo pego por aquí si lo encuentro.

Según dices mas abajo, en tu post, un eco que supone el 16/250ms(cuarto de segundo), ¿se come 2KBytes enteritos?... ¿Kbytes, y no Kbits?, ¿seguro?.

Algo no debo de estar entendiendo bien, o algo anda mal con los datos.

68000 escribió:Creía que el SPC700 era totalmente independiente, tu le enviabas las muestras y un programa a ejecutar y lo hacía, corregidme si me equivoco, no estoy totalmente seguro.

Y así es, es totalmente independiente, pero necesita instrucciones para trabajar, y esas se las proporciona la cpu. Lo que no es independiente, es el bus. Recordemos, lo que está pasando, es que la CPU está bajando hasta el sistema de sonido para dejar un paquetito... el problema es que necesita usar un camino que está constantemente ocupado, así que el cerebro, cuando se ve obligado a hacer de mensajero, pierde demasiado tiempo esperando en la puerta.

Pedazo de analogía xD... se nos vienen dos problemas a la hora de programar en SNES:

1- Es una putada no saber en que momentos el bus está libre para aprovechar, y diseñar el videojuego de tal forma, que la cpu pueda "parar" y enviar datos sin que haya penalizaciones TAN SEVERAS.

...ojo digo severas, porque lo que está claro, es que son inevitables, y aquí llega el segundo punto.

2- El bus solo puede ser ocupado para una tarea... o "comunicación CPU - SPC", o "comunicación SPC - DSP".

En el mejor de los casos, el parón solo será "muy breve", pero yo he visto en el donkey kong 1 (sin ir mas lejos), un parón de cerca de 1 segundo, cuando, en medio de la acción, toca cambiar las músicas completamente (y esto es, samples nuevos, y un set de instrucciones nuevas). No es porque la cpu no pueda hacer las dos cosas a la vez (escribir en la ram del SPC emplea porcentaje de proceso irrisorio), es porque se pierde la sincronía

68000 escribió:Los samples son almacenados ya comprimidos en el cartucho, luego se cargan en la ram del SPC700 y creo recordar que se descomprimian al vuelo. Curiosamente, recuerdo (y además se recomienda en varios documentos) usar samples de 16 bit en lugar de 8 bit porque la compresión es aún mayor. El samplerate puede ser cualquiera, yo de hecho usaría 44khz en samples muy muy pequeños como ondas simples y luego usaría entre 32-16khz para muestras más grandes (más que nada para ahorrar espacio).

Interesante esto que dices... comprimir a 8 bits no compensa. Ahora, esto en cuanto a economización de la memoria de un cartucho (ROM), lo que me gustaría saber, es si de esta manera obligamos al DSP a trabajar como si fuera de 8 bits, con lo que practicamente nos ahorramos el problema del punto 1, del quote anterior.

Se que lo que estoy diciendo es una barbaridad, pero desconozco si el DSP tiene las mismas propiedades que el 65C816 para trabajar en los dos modos (8 y 16 bits). Sería muy interesante.


¿Diferencias entre sonido a 16 bits y 8 bits?.

68000 escribió:Haré un post por separado para hacer un tutorial en condiciones, porque siempre me ha gustado hacer tutoriales detallados con fotos, no te preocupes.

¡Perfecto!, estaré muy pendiente

CPU aparte, el sistema de sonido es el punto fuerte de SNES, a la vez que su talón de aquiles (digo cpu aparte, poruqe claramente es lo que mas lastra al sistema, pero la ironía está ahí, con respecto al sistema de sonido). Tecnológicamente, considero que está por delante incluso de su capacidad para ejecutar las rutinas del modo 7.

Conocer bien toda esta parte de su hardware, es algo a lo que un programador mas está obligado, a la hora de toquetear en SNES... mal llevado, puede ser un autentico desastre xD

68000 escribió:Intuyo que tendrá algo que ver con el tiempo que se tarda en transferir los datos del cartucho al SPC700, algo así como cuando el SDD-1 descomprime los datos y se los envia a los diferentes componentes (Aunque esto es solo una teoría)

Que va, por desgracia tiene mas que ver con el tiempo de espera, que otra cosa.

Antes lo he esquematizado, pero de una forma incorrecta, se me ha pasado una cosa por alto. La CPU, al terminar su tarea de "mensajera", quizás no pueda empezar hasta que el SPC se sincronice con todo el sistema de nuevo, con lo que:

Llamada de la CPU -> SPC ocupado, el multiplicador mantiene ocupado el bus todavía durante otro ciclo mas -> se libera el bus -> deja de haber comnicación entre SPC y DSP -> se produce un silencio/congelamiento -> CPU escribe en RAM del SPC -> CPU libera bus -> se retoma la comunicación entre SPC y DSP, y la CPU vuelve a sus tareas, pero el SPC no lo hace al momento, necesita otros dos ciclos -> El programa prosigue con normalidad.


Explico el 4º/5º paso:
deja de haber comnicación entre SPC y DSP -> se produce un silencio/congelamiento

La CPU no necesita mas que un pequeño porcentaje de su capacidad de proceso para enviar datos a la RAM del SPC, el problema, es que el sistema de sonido hace que se quede quieta esperando, porque se pierde la sincronía.


Una analogía perfecta, sería:
...como cuando una grabadora de cd's, depende de un mal buffer de almacenamiento, y se queda sin datos que grabar, incluso a 1X. Tiene capacidad para grabar a 15X mas, pero eso es irrelevante.



Que ganas tengo de ver el MSU1 en mi SNES

Ralph escribió:...a lo que vamos, que el efecto de eco no es gratis, pero la llamada al registro, si, ojo. ¿Que es exactamente el echoing buffer?, ¿en que consiste?,

Por poner un ejemplo: ¿qué ocurriría si gritas en un acantilado la palabra "ECO"? lo que ocurrirá es que se repetirá el sonido algunas veces y cada vez más bajo, pero en el caso de la reverberación, ese pequeño fragmento de sonido, mucho más pequeño (que se almacena constantemente en esos 2 KB de RAM) se repetirá las suficientes veces en una fracción de segundo como para formar la reverberación.

Es decir, vamos a tomar un pequeño fragmento de ese ECO, unos cuantos milisegundos por ejemplo y lo vamos a repetir durante digamos 5 segundos para formar la reverberación:


|\
|..\
|....\
|......\
|........\
|..........\

Imagina que estás en el pico de esa rampa con el fragmento: en el pico suena fuerte , al final suena realmente bajo y mientras has bajado la rampa, han pasado 5 segundos, en los cuales has repetido el pequeño fragmento, pero, si el sonido está constantemente cambiando, tal como una composición musical, cogeremos siempre los ultimos milisegundos del canal, sample o sonido y haremos el proceso de la rampa constantemente.

Creo que no puedo explicarlo de mejor forma xD.

Ralph escribió:Y así es, es totalmente independiente, pero necesita instrucciones para trabajar, y esas se las proporciona la cpu. Lo que no es independiente, es el bus. Recordemos, lo que está pasando, es que la CPU está bajando hasta el sistema de sonido para dejar un paquetito... el problema es que necesita usar un camino que está constantemente ocupado, así que el cerebro, cuando se ve obligado a hacer de mensajero, pierde demasiado tiempo esperando en la puerta.

Pedazo de analogía xD... se nos vienen dos problemas a la hora de programar en SNES:

1- Es una putada no saber en que momentos el bus está libre para aprovechar, y diseñar el videojuego de tal forma, que la cpu pueda "parar" y enviar datos sin que haya penalizaciones TAN SEVERAS.

...ojo digo severas, porque lo que está claro, es que son inevitables, y aquí llega el segundo punto.

2- El bus solo puede ser ocupado para una tarea... o "comunicación CPU - SPC", o "comunicación SPC - DSP".

En el mejor de los casos, el parón solo será "muy breve", pero yo he visto en el donkey kong 1 (sin ir mas lejos), un parón de cerca de 1 segundo, cuando, en medio de la acción, toca cambiar las músicas completamente (y esto es, samples nuevos, y un set de instrucciones nuevas). No es porque la cpu no pueda hacer las dos cosas a la vez (escribir en la ram del SPC emplea porcentaje de proceso irrisorio), es porque se pierde la sincronía

Mal asunto es ese, es algo parecido a la hora de programar para la Saturn... No quiero imaginarme como tuvieron que bailar a la hora de crear código los programadores... Lo malo es que de por medio estaban los grafistas y músicos que no comprenderían las limitaciones y dificultades.

Ralph escribió:Interesante esto que dices... comprimir a 8 bits no compensa. Ahora, esto en cuanto a economización de la memoria de un cartucho (ROM), lo que me gustaría saber, es si de esta manera obligamos al DSP a trabajar como si fuera de 8 bits, con lo que practicamente nos ahorramos el problema del punto 1, del quote anterior.

Se que lo que estoy diciendo es una barbaridad, pero desconozco si el DSP tiene las mismas propiedades que el 65C816 para trabajar en los dos modos (8 y 16 bits). Sería muy interesante.


¿Diferencias entre sonido a 16 bits y 8 bits?.

Imagino que son 2 cosas distintas y diferenciadas las que mencionas, el procesador no trabajará en un modo de 8 bits o 16 porque tenga que manejar muestras de 8 o 16 bits, o al menos es lo que he entedido. En cuanto las diferencias de cara al BRR, el usar samples a 8 bits y a frecuencias muy bajas puede hacer que directamente el sample se arruine con clicks, distorsiones y se comprima mucho menos (sin contar la degradación del sample en si mismo), según entendí en varios documentos que he leido. Por otra parte, un sample a 8 bits siempre sonará peor que uno de 16 bits, puedes hacer la prueba grabando con tu micro un sonido a 44khz y a 16 bit. Luego, lo vuelves a abrir y lo exportas a 44khz pero a 8 bits. Notarás como un cierto "granulado", "viento" y una ligera distorsión general.

Ralph escribió:¡Perfecto!, estaré muy pendiente :D

CPU aparte, el sistema de sonido es el punto fuerte de SNES, a la vez que su talón de aquiles (digo cpu aparte, poruqe claramente es lo que mas lastra al sistema, pero la ironía está ahí, con respecto al sistema de sonido). Tecnológicamente, considero que está por delante incluso de su capacidad para ejecutar las rutinas del modo 7.

Conocer bien toda esta parte de su hardware, es algo a lo que un programador mas está obligado, a la hora de toquetear en SNES... mal llevado, puede ser un autentico desastre xD

El problema del SPC700 es la cantidad de RAM disponible. Si, entiendo que a finales de los 80, que es cuando se empezó a diseñar, la RAM era realmente cara, pero aparte de eso yo hubiera añadido otro chip adicional más de sonido extra, aunque hubiera sido al igual que la megadrive, otro chip FM, pero hubiera ayudado y MUCHO a una gran cantidad de compositores que veian insuficiente la RAM que le habían asignado (pero peor lo tendrían los que diseñaban los efectos de sonido)

Opino que seguramente Nintendo quiso destacar por encima de una epoca dominada por el FM y saltar a algo GRANDE, y como la recién estrenada Megadrive usaba un chip FM, se querrián desmarcar de la competencia con algo superior tecnológicamente. Lo malo de esta teoría es que según está escrito, el SPC700 se desarrolló incluso a espaldas de la propia Nintendo, por lo que dudo mucho que el SPC700 se desarrollara con esas intenciones, otra cosa es que en el papel se dijera "sistema que permita reproducir voces digitales" o algo así...

Ralph escribió:

68000 escribió:Intuyo que tendrá algo que ver con el tiempo que se tarda en transferir los datos del cartucho al SPC700, algo así como cuando el SDD-1 descomprime los datos y se los envia a los diferentes componentes (Aunque esto es solo una teoría)

Que va, por desgracia tiene mas que ver con el tiempo de espera, que otra cosa.

Antes lo he esquematizado, pero de una forma incorrecta, se me ha pasado una cosa por alto. La CPU, al terminar su tarea de "mensajera", quizás no pueda empezar hasta que el SPC se sincronice con todo el sistema de nuevo, con lo que:

Llamada de la CPU -> SPC ocupado, el multiplicador mantiene ocupado el bus todavía durante otro ciclo mas -> se libera el bus -> deja de haber comnicación entre SPC y DSP -> se produce un silencio/congelamiento -> CPU escribe en RAM del SPC -> CPU libera bus -> se retoma la comunicación entre SPC y DSP, y la CPU vuelve a sus tareas, pero el SPC no lo hace al momento, necesita otros dos ciclos -> El programa prosigue con normalidad.


Explico el 4º/5º paso:
deja de haber comnicación entre SPC y DSP -> se produce un silencio/congelamiento

La CPU no necesita mas que un pequeño porcentaje de su capacidad de proceso para enviar datos a la RAM del SPC, el problema, es que el sistema de sonido hace que se quede quieta esperando, porque se pierde la sincronía.


Una analogía perfecta, sería:
...como cuando una grabadora de cd's, depende de un mal buffer de almacenamiento, y se queda sin datos que grabar, incluso a 1X. Tiene capacidad para grabar a 15X mas, pero eso es irrelevante.



Que ganas tengo de ver el MSU1 en mi SNES [babas]

Esto mismo me hace preguntarme si el Mickey Mania también sufría esto mismo o bien es que los datos también estaban comprimidos. Lo curioso del caso es que en la versión de Megadrive también sale, pero menos tiempo. ¿Estaría esa pantalla ahí para algo en concreto o bien estaba porque realmente los datos llevan compresión y se están descomprimiendo?.

68000 escribió:Por poner un ejemplo: ¿qué ocurriría si gritas en un acantilado la palabra "ECO"? lo que ocurrirá es que se repetirá el sonido algunas veces y cada vez más bajo, pero en el caso de la reverberación, ese pequeño fragmento de sonido, mucho más pequeño (que se almacena constantemente en esos 2 KB de RAM) se repetirá las suficientes veces en una fracción de segundo como para formar la reverberación.

Es decir, vamos a tomar un pequeño fragmento de ese ECO, unos cuantos milisegundos por ejemplo y lo vamos a repetir durante digamos 5 segundos para formar la reverberación:


|\
|..\
|....\
|......\
|........\
|..........\

Imagina que estás en el pico de esa rampa con el fragmento: en el pico suena fuerte , al final suena realmente bajo y mientras has bajado la rampa, han pasado 5 segundos, en los cuales has repetido el pequeño fragmento, pero, si el sonido está constantemente cambiando, tal como una composición musical, cogeremos siempre los ultimos milisegundos del canal, sample o sonido y haremos el proceso de la rampa constantemente.

Creo que no puedo explicarlo de mejor forma xD.

No tengo preguntas, muy bien explicado

...ahora, que 16ms de buffer para realizar el eco, ocupará "equis" memoria ram, dependiendo del bitrate del sample, ¿no?.

Mal asunto es ese, es algo parecido a la hora de programar para la Saturn... No quiero imaginarme como tuvieron que bailar a la hora de crear código los programadores... Lo malo es que de por medio estaban los grafistas y músicos que no comprenderían las limitaciones y dificultades.

Una opción, si el juego a ejecutar no es muy exigente con el hardware (tipo panel de pon, tetris, arkanoids, y similares), es quitar de en medio el SPC, y establecer una comunicación directa con el DSP, para conseguir cosas muy parecidas a esto, sin que andar renovando la ram con el engorro del SPC suponga posibles problemas con el rendimiento.
¿un problema?, que la CPU puede escribir en la RAM del SPC, pero no se si puede ejecutar instrucciones desde ahí, o desde la RAM del sistema. Todo sería mirarlo... lo que si está claro, es que nunca habrían parones (pero la lógica que procesa el SPC, ahora tendría que hacerlo el 65C816 por software (a parte de que tendría que ser alojada entera en memoria)... y como digo, es muy posible que solo compense en juegos poco exigentes con la capacidad de proceso del sistema).

Imagino que son 2 cosas distintas y diferenciadas las que mencionas, el procesador no trabajará en un modo de 8 bits o 16 porque tenga que manejar muestras de 8 o 16 bits, o al menos es lo que he entedido. En cuanto las diferencias de cara al BRR, el usar samples a 8 bits y a frecuencias muy bajas puede hacer que directamente el sample se arruine con clicks, distorsiones y se comprima mucho menos (sin contar la degradación del sample en si mismo), según entendí en varios documentos que he leido. Por otra parte, un sample a 8 bits siempre sonará peor que uno de 16 bits, puedes hacer la prueba grabando con tu micro un sonido a 44khz y a 16 bit. Luego, lo vuelves a abrir y lo exportas a 44khz pero a 8 bits. Notarás como un cierto "granulado", "viento" y una ligera distorsión general.

Si, ni yo mismo lo he tenido muy claro, pero he preferido soltarlo, porque así tengo la oportunidad de que me corrijan

El problema del SPC700 es la cantidad de RAM disponible. Si, entiendo que a finales de los 80, que es cuando se empezó a diseñar, la RAM era realmente cara, pero aparte de eso yo hubiera añadido otro chip adicional más de sonido extra, aunque hubiera sido al igual que la megadrive, otro chip FM, pero hubiera ayudado y MUCHO a una gran cantidad de compositores que veian insuficiente la RAM que le habían asignado (pero peor lo tendrían los que diseñaban los efectos de sonido)

256KB se me haría excesivo para una SNES, es que con eso ya te acercas a la calidad de sonido de una máquina de 32 bits (en cuanto a complejidad y calidad, mas que a duración y dinamismo).

Yo creo que 128KB hubiera sido redondo para ese hardware que tiene para el sonido.

Opino que seguramente Nintendo quiso destacar por encima de una epoca dominada por el FM y saltar a algo GRANDE, y como la recién estrenada Megadrive usaba un chip FM, se querrián desmarcar de la competencia con algo superior tecnológicamente. Lo malo de esta teoría es que según está escrito, el SPC700 se desarrolló incluso a espaldas de la propia Nintendo, por lo que dudo mucho que el SPC700 se desarrollara con esas intenciones, otra cosa es que en el papel se dijera "sistema que permita reproducir voces digitales" o algo así...

Creo que a nintendo le pasó como le pasó con la NES... donde en un principio tenían pensado un sistema de juegos con la complejidad del donkey kong, y luego tuvieron qeu emplear mappers a cascoporro porque se quedaron realmente cortos con sus pretensiones.

...con el sonido de la SNES es igual. El juego piloto es el SMW, y no tenían pensado que se pudiese necesitar mas para un juego de SNES... luego ves que algunos te hacen intros cantadas (cosa que seguro nunca hubieran imaginado que pasaría), y entonces si se echa de menos mas capacidad... pero es lo que digo, que para nintendo, seguro que ni se habían planteado la existencia de cartuchos de 32 megas, como para exigirle a la SNES un hardware que se coma la rom de un cartucho a base de almacenar samples (con menos memoria RAM para el sonido, mas compresión para los samples, luego, menos memoria ocupada en el cartucho).


Bueno, todo esto son opiniones muy personales... quedemonos solo con que, con 128 KB, el salto de calidad hubiera sido increible, y con mayusculas.

Esto mismo me hace preguntarme si el Mickey Mania también sufría esto mismo o bien es que los datos también estaban comprimidos. Lo curioso del caso es que en la versión de Megadrive también sale, pero menos tiempo. ¿Estaría esa pantalla ahí para algo en concreto o bien estaba porque realmente los datos llevan compresión y se están descomprimiendo?.

Nunca he jugado al mickey manía, no puedo opinar



Añado:

Super Famicom playing full motion video @224x144, 30fps + 44100Hz 16bit stereo audio via MSU1 using sd2snes.

MSU1 is a custom chip specification by byuu that provides CD quality audio and up to 4GB of DMA streamable data to the SNES.
Video data is streamed via DMA into the SNES's video memory while audio is played back through the SNES's cartridge slot line-in using sd2snes's onboard DAC.
The video is comprised of 293MB of video data and 52MB of audio data.

http://www.youtube.com/watch?v=yULkopwR8oA


Lo siento, no he podido evitarlo

...345 megas de datos han pasado por sus circuitos en menos de 6 minutos, ¿te imaginas lo que supondría eso aplicado a un videojuego?. El fatal fury 3 de neo geo ocupa 266 megas, y al menos un 80% de toda esa memoria ha viajado por sus circuitos en unos 20/30 minutos de partida (no hace falta decir que con estas cifras se consigue un juego con un montón de detalles ).

Que ganas le tengo al invento este, no te haces una idea

No se si lo visto, pero en el MSU segun eso el audio es generado por un coprocesador externo y no por el SPC700. Vamos, que al final el MSU es como el Super FX, en que la consola es meramente la fuente de alimentacion

socram8888 escribió:No se si lo visto, pero en el MSU segun eso el audio es generado por un coprocesador externo y no por el SPC700. Vamos, que al final el MSU es como el Super FX, en que la consola es meramente la fuente de alimentacion

Pero si esto lo estuvimos diciendo el otro día, llegas tarde xD

De todos modos, la comparación con el SFX se pasa de injusta. La SNES no es ni de coña solo la fuente de alimentación. De hecho, el MSU1 trabaja conjuntamente con el SPC.

Los 64KB de RAM del SPC se dedican a efectos de sonido, y voces... y el MSU1 únicamente para la música, FMV, y mapear 4GB de memoria sin cuellos de botella (que no es poco). El resto del hardware no recibe ninguna ayuda, la verdad es que no entiendo tu comentario... el megaCD es completamente lícito, pero esto, que es mucho menos invasivo, y ni de coña dopa tanto el hardware original como un mega cd (en cuanto a potencia de proceso), resulta que es un "SFX que ejecuta todo desde el cartucho".


Ves mal, socram.

Video data is streamed via DMA into the SNES's video memory while audio is played back through the SNES's cartridge slot line-in using sd2snes's onboard DAC.

Ahí leo claramente que la consola es simplemente la fuente de alimentación. El vídeo es copiado por el MSU1 a la PPU, y el audio (que no música) es generado por un componente externo. Exactamente igual que un SuperFX

Decir que el resto no recibe suficiente ayuda... Recibe la CPU ayuda por un controlador de vídeo externo, y el SPC por un DAC independiente. Como no quieras overclockear la CPU, no sé que consideras "tener ayuda"

En el MegaCD ambos procesadores se ejecutan en paralelo, ninguno se dedica a "no hacer nada". Es más, en la intro del MegaCD por ejemplo, toda la pantalla de inicio (incluyendo efectos) es generada y procesada por el 68k de la consola, no por el del addon.

Ralph escribió:...ahora, que 16ms de buffer para realizar el eco, ocupará "equis" memoria ram, dependiendo del bitrate del sample, ¿no?.

Es algo fijo e independiente, siempre se tomará la misma cantidad de RAM sin importar cual o como sea la fuente del sonido.

Ralph escribió:Yo creo que 128KB hubiera sido redondo para ese hardware que tiene para el sonido.

Creeme, siempre se agradece tener la mayor cantidad de memoria posible para muestras de sonido. Yo sinceramente hubiera preferido pagar un poco más por una SNES el día de salida si supiera que tendría 128KB de RAM para el SPC, o incluso 256 tal como dices, a costa de recortar por ejemplo, el eyector de cartuchos, pero qué le vamos a hacer, al final se quedó en lo que todos conocemos xD

Ralph escribió:Añado:

Super Famicom playing full motion video @224x144, 30fps + 44100Hz 16bit stereo audio via MSU1 using sd2snes.

MSU1 is a custom chip specification by byuu that provides CD quality audio and up to 4GB of DMA streamable data to the SNES.
Video data is streamed via DMA into the SNES's video memory while audio is played back through the SNES's cartridge slot line-in using sd2snes's onboard DAC.
The video is comprised of 293MB of video data and 52MB of audio data.

http://www.youtube.com/watch?v=yULkopwR8oA


Lo siento, no he podido evitarlo XD

...345 megas de datos han pasado por sus circuitos en menos de 6 minutos, ¿te imaginas lo que supondría eso aplicado a un videojuego?. El fatal fury 3 de neo geo ocupa 266 megas, y al menos un 80% de toda esa memoria ha viajado por sus circuitos en unos 20/30 minutos de partida (no hace falta decir que con estas cifras se consigue un juego con un montón de detalles [babas] ).

Que ganas le tengo al invento este, no te haces una idea [sonrisa]

Ya conocía el MSU1 desde hacía tiempo, un poco despúes de que se implementara en el BSNES, espero que no se quede en infinidad de hacks que lo usen tan solo para usar músicas en MP3. Podrían salir proyectos totalmente increibles, la verdad.

Como curiosidad decir que antes de que existiera el MSU1 , el satellaview ya incluía el "soundlink" para reproducir sonido retransmitido vía satelite ,( creo recordar que solo en mono).

socram8888 escribió:Ahí leo claramente que la consola es simplemente la fuente de alimentación. El vídeo es copiado por el MSU1 a la PPU, y el audio (que no música) es generado por un componente externo. Exactamente igual que un SuperFX

Decir que el resto no recibe suficiente ayuda... Recibe la CPU ayuda por un controlador de vídeo externo, y el SPC por un DAC independiente. Como no quieras overclockear la CPU, no sé que consideras "tener ayuda"

En el MegaCD ambos procesadores se ejecutan en paralelo, ninguno se dedica a "no hacer nada". Es más, en la intro del MegaCD por ejemplo, toda la pantalla de inicio (incluyendo efectos) es generada y procesada por el 68k de la consola, no por el del addon.

Ya son ganas de discutir...

A ver, que hasta el SPC llega a trabajar por cuenta propia cuando la CPU delega sus tareas.

Se trata de un chip (el MSU1), que tambien sirve para reproducir videos sin que le influya el resto del hardware... que si, que cuando hay un video de por medio, solo está funcionando el chip este desde el cartucho, pero el 65C816, los VDP, e incluso el SPC+DSP, NO ESTÁN DESACTIVADOS, es muy diferente no tener tareas, a estar desconectados (como pasa cuando hay un SFX por medio).

Cuando se está ejecutando un hack del SMW con música en calidad CD, ¿que crees que está pasando?. Está funcionando TODO... el MSU1, el SPC+DSP, el 65C816, los VDP... todo.


Supongo que es la historia de siempre... que estamos hablando de una SNES, y hay que restarle méritos como sea. Luego defendemos a capa y espada lo io indefendible cuando se trata de "otras cosas".

68000 escribió:Creeme, siempre se agradece tener la mayor cantidad de memoria posible para muestras de sonido. Yo sinceramente hubiera preferido pagar un poco más por una SNES el día de salida si supiera que tendría 128KB de RAM para el SPC, o incluso 256 tal como dices, a costa de recortar por ejemplo, el eyector de cartuchos, pero qué le vamos a hacer, al final se quedó en lo que todos conocemos xD

¿Cuanto crees que hubiera encarecido el precio de la consola, meter una RAM de 256KB, en vez de 64?.

La verdad, es que con todo lo que recortaron de lo que iba a ser el hardware inicialmente, no es para esperar que con ahorrar los costes quitando algo, hubiera bastado para que metieran mas RAM ahí.
Si quitaron un 68000 a 10Mhz, y el chip SFX como VDP3 (hubiese funcionado en serie con los otros dos VDP, y no de forma independiente), y no compensaron metiendo nada, no creo que hubieran habido muchas esperanzas de que mejoraran el sonido con mas RAM.

68000 escribió:Ya conocía el MSU1 desde hacía tiempo, un poco despúes de que se implementara en el BSNES, espero que no se quede en infinidad de hacks que lo usen tan solo para usar músicas en MP3. Podrían salir proyectos totalmente increibles, la verdad.

El chip ya está montado sobre una PCB (SD2SNES), y además está funcionando como un everdrive, o powerpak. Con esto, lo tenemos todo, una mejora de hardware importante, y un flashcart.

¿Que le falta?... mira esto:

http://www.youtube.com/watch?v=uh22ZWk6urM
http://www.youtube.com/watch?v=t5hfoNJg ... re=related
http://www.youtube.com/watch?v=Rm_q3C97 ... re=related


Va a ser el flashcart mas completo del mercado, y con diferencia.

De NesDev hablando de hacer un mapper y coprocesador con un doble PIC de 32 bits y 32 megabits de ROM:

Everyone was trying to rip off the FME too much, and now I'm hearing talk about a PIC, and all I can think about is how a lot of the people here can barely code Tic Tac Toe, how in the hell is anyone going to use 4MB of PRG rom, and why is anyone going to need a math co-processor capable of fourier transformations?
...
All I was doing was bringing that fact up. I don't care what you guys want to stick on it, you can stick a damn x86 on it for all I care, but you're not going to get anywhere unless you have a good base to go off of.

kappa64 escribió:Como curiosidad decir que antes de que existiera el MSU1 , el stellaview ya incluía el "soundlink" para reproducir sonido retransmitido vía satelite ,( creo recordar que solo en mono).

¿Algo así como audio en streaming? imagino que esto usaría el mismo codec que se usa en telefonía. Gracias por la información.

Ralph escribió:¿Cuanto crees que hubiera encarecido el precio de la consola, meter una RAM de 256KB, en vez de 64?.

La verdad, es que con todo lo que recortaron de lo que iba a ser el hardware inicialmente, no es para esperar que con ahorrar los costes quitando algo, hubiera bastado para que metieran mas RAM ahí.
Si quitaron un 68000 a 10Mhz, y el chip SFX como VDP3 (hubiese funcionado en serie con los otros dos VDP, y no de forma independiente), y no compensaron metiendo nada, no creo que hubieran habido muchas esperanzas de que mejoraran el sonido con mas RAM.

Comprendo lo que dices, pero mi perspectiva es esta: solo con ver la snes te das cuenta de que Nintendo metió en esa caja el summum tecnológico para un mercado domestico: 256 colores simultaneos, modo7, etc, etc... Parece más una máquina orientada a lo que es los gráficos que lo restante que hay en la misma.

Es más, hay algo que sinceramente no me cuadra en toda esta ecuación:

1982 - Tenemos un ordenador como el Commodore 64, con 64kb de RAM, costaba 600$ (Pero aparte de la RAM, también llevaba el SID, un buen procesador gráfico para la epoca, etc etc)

1986 - ZX Spectrum 128 +2, con 128KB de RAM, unas 44.000 pesetas

1990 - 64KB del SPC700... ¿?

No sé si entiendes a lo que me vengo a referir. Por una parte, creo haber leido que Sony le cobraba unos royalties muy altos a Nintendo por poner su SPC700 en su SNES, por lo cual CREO que si podría haberse ampliado la RAM del SPC700. Además de eso, si, el precio también variaría según el proceso de fabricación, caracteristicas, etc... Pero joder, si tenemos que esto http://en.wikipedia.org/wiki/Ensoniq_Mirage ,con 128KB para muestras y 8 canales de polifonía (además de otras cosas) valía 2000$ en 1984 ¿En 1990 seguiría valiendo lo mismo la RAM usada en el SPC700?. No hablamos por ejemplo de la reducción de componentes, sinó del coste de la RAM.

Ralph escribió:El chip ya está montado sobre una PCB (SD2SNES), y además está funcionando como un everdrive, o powerpak. Con esto, lo tenemos todo, una mejora de hardware importante, y un flashcart.

¿Que le falta?... mira esto:

http://www.youtube.com/watch?v=uh22ZWk6urM
http://www.youtube.com/watch?v=t5hfoNJg ... re=related
http://www.youtube.com/watch?v=Rm_q3C97 ... re=related


Va a ser el flashcart mas completo del mercado, y con diferencia

Casualmente, me enseñaron el mismo flascart ayer haciendo funcionar el MSU-1 (me refiero al video), imagino que de esto a la fabricación del mismo a pequeña escala hay un paso. Eso si, espero equivocarme, pero si empiezan a diseñar soluciones basadas en FPGA que admitan chips "imaginarios" (contando conque la gente se anime y empiecen a diseñarlos), van a desvirtuar de mala manera lo que es la máquina en si, pero ya te digo, espero que no sea así.

socram8888 escribió: De NesDev hablando de hacer un mapper y coprocesador con un doble PIC de 32 bits y 32 megabits de ROM:

...

Es lo mismo que decía más arriba, llegará un punto en donde digas "Donde está entonces el esfuerzo por conseguir lo máximo de la plataforma?" Miras el Alien Soldier, y dices "esto es sin duda el techo", miras por ejemplo el Donkey Kong Country y piensas lo mismo, pero ¿y si empiezas a soltar chips de apoyos en los cartuchos? no voy a negar que los Super FX eran como el agua de mayo, pero llegará el punto en que eches de menos esos juegos tochos que aprovechaban el hardware al máximo. Yo soy de esas personas que intentan meter lo máximo posible en lo minimo, y a día de hoy, este es un caso.

Vamos, me gusta la idea de conseguir lo mejor en un hardware antigüo con unas limitaciones que hoy día son muy altas, pero la satisfacción que te proporciona hacer esto en un sistema (y afición) que te gusta, no lo puede pagar el dinero xD. En resumidas cuentas, no veo mal por ejemplo que existan 2 o 3 chips nuevos que den nuevas caracteristicas, pero de ahí a que puedan aparecer un buen mazo de chips de apoyo, no lo veo, la verdad.

Por si te sirve de algo , un post del user que programo esta demo:
http://www.youtube.com/watch?v=MQjmsr3WA84
(puedo asegurar que funcionar en hardware real y perfectamente).

16-bit stereo 32 kHz streaming success
http://nesdev.parodius.com/bbs/viewtopic.php?t=6121

kappa64 escribió:Por si te sirve de algo , un post del user que programo esta demo:
http://www.youtube.com/watch?v=MQjmsr3WA84
(puedo asegurar que funcionar en hardware real y perfectamente).

16-bit stereo 32 kHz streaming success
http://nesdev.parodius.com/bbs/viewtopic.php?t=6121

Ahora mismo no puedo escucharlo, necesito una tarjeta de sonido nueva que pienso que tendré la semana que viene. Eso si, tengo curiosidad por saber una cosa: ¿Hay suficiente bus de datos como para transmitir 2 canales? tenemos que los canales del SPC700 son todos monofónicos, pero según el hilo que pegas, es en estéreo.

Mi pregunta es si se va cargando en pequeños bloques y luego se envia cada lado del fichero a 1 canal y luego a otro o bien se carga constantemente la información por ambos canales? (digamos, el primero y el segundo, por poner un ejemplo)

68000 escribió:

Ralph escribió:El chip ya está montado sobre una PCB (SD2SNES), y además está funcionando como un everdrive, o powerpak. Con esto, lo tenemos todo, una mejora de hardware importante, y un flashcart.

¿Que le falta?... mira esto:

http://www.youtube.com/watch?v=uh22ZWk6urM
http://www.youtube.com/watch?v=t5hfoNJg ... re=related
http://www.youtube.com/watch?v=Rm_q3C97 ... re=related


Va a ser el flashcart mas completo del mercado, y con diferencia

Casualmente, me enseñaron el mismo flascart ayer haciendo funcionar el MSU-1 (me refiero al video), imagino que de esto a la fabricación del mismo a pequeña escala hay un paso. Eso si, espero equivocarme, pero si empiezan a diseñar soluciones basadas en FPGA que admitan chips "imaginarios" (contando conque la gente se anime y empiecen a diseñarlos), van a desvirtuar de mala manera lo que es la máquina en si, pero ya te digo, espero que no sea así.

Es que ese SD2SNES ya es muy superior al propio hardware de la SNES por si solo

bertobp escribió:Es que ese SD2SNES ya es muy superior al propio hardware de la SNES por si solo

La principal función del MSU1, es mapear 4GB de memoria, con la virtud de que no hay cuellos de botella en el streaming de datos. Luego cumple como segundo procesador de audio, y permite la reproducción de videos a 224x144, 30fps, 44100Hz y 16bit, con 256 colores.

Imagino que querrás decir que la tecnología que se emplea está muy diferenciada con respecto a cómo funciona la SNES, en el sentido en que el MSU1 mejora ese rendimiento... porque por lo demás, no veo la forma en que esto pueda ser un apoyo a la CPU, o los VDP's (ni siquiera al SPC + DSP, mas allá de que permite desahogar la RAM del sonido, al liberar a estos chips de la tarea de la música... que no de los efectos sonoros y las voces, de esto si se encarga la SNES).


Con respecto a la "emulación" de los diferentes chips especiales, decir que no es una opción obligada, y por lo tanto no tiene por qué ser siempre una ventaja... que le viene muy bien a la compatibilidad en cuanto a su función como flashcart, pero que tambien puede permitir mas libertades a la hora de programar algo, si se desea.


Para mi, el mayor valor de esta tarjeta (mas allá de su valor como flashcart), es que convierte los cartuchos de SNES, en cartuchos de NEOGEO, en todos los sentidos (es prácticamente como si los 4GB mapeados, fuesen 4GB de memoria RAM).

...no es moco de pavo, pero realmente la SNES no recibe automáticamente mas potencia de proceso.


P.D: Si se usa el SFX en un programa "indie", recordemos que TODO, incluso el propio MSU1, quedará al margen de su funcionamiento, por lo que realmente, un programa solo puede contar con otros apoyos, como los DSP. Esto no le hace ser mas potente que todo el resto del hardware.

68000 escribió:Ahora mismo no puedo escucharlo, necesito una tarjeta de sonido nueva que pienso que tendré la semana que viene. Eso si, tengo curiosidad por saber una cosa: ¿Hay suficiente bus de datos como para transmitir 2 canales? tenemos que los canales del SPC700 son todos monofónicos, pero según el hilo que pegas, es en estéreo.

Mi pregunta es si se va cargando en pequeños bloques y luego se envia cada lado del fichero a 1 canal y luego a otro o bien se carga constantemente la información por ambos canales? (digamos, el primero y el segundo, por poner un ejemplo)

Los 8 canales son stereo... pero no stereo a base de gastar 2 canales para producir ese efecto, sino, la capacidad de aplicarle panning a todos y cada uno de ellos, no sería viable, ¿no?.

bertobp escribió:Es que ese SD2SNES ya es muy superior al propio hardware de la SNES por si solo

Ya, pero a lo que me refería era a que llege el día en que diga "¿esto es una Super Nintendo o es otra consola diferente?" , no sé, es algo extraño de explicar.

Ralph escribió:Los 8 canales son stereo... pero no stereo a base de gastar 2 canales para producir ese efecto, sino, la capacidad de aplicarle panning a todos y cada uno de ellos, no sería viable, ¿no?.

En cierta parte si, me explico:

Solo puedes reproducir 1 sample en mono por cada canal del SPC700, pero si puedes aplicarle panning a voluntad. Si te fijas, un sample en estéreo son 2 canales: izquierdo y derecho. Si intentamos cargar un sample estéreo por el canal 1 del SPC700, solo podrías reproducir o el canal izquierdo o el derecho, pero nunca los 2 por un mismo canal, además de que el SPC700 no admite samples en estéreo, si mal no recuerdo.

68000 escribió:

bertobp escribió:Es que ese SD2SNES ya es muy superior al propio hardware de la SNES por si solo

Ya, pero a lo que me refería era a que llege el día en que diga "¿esto es una Super Nintendo o es otra consola diferente?" , no sé, es algo extraño de explicar.

No, siempre será una SNES porque el programa del juego siempre lo va correr la CPU anfitriona, es el mismo caso de los chips SFX

Ralph escribió:
La principal función del MSU1, es mapear 4GB de memoria, con la virtud de que no hay cuellos de botella en el streaming de datos. Luego cumple como segundo procesador de audio, y permite la reproducción de videos a 224x144, 30fps, 44100Hz y 16bit, con 256 colores.

Imagino que querrás decir que la tecnología que se emplea está muy diferenciada con respecto a cómo funciona la SNES, en el sentido en que el MSU1 mejora ese rendimiento... porque por lo demás, no veo la forma en que esto pueda ser un apoyo a la CPU, o los VDP's (ni siquiera al SPC + DSP, mas allá de que permite desahogar la RAM del sonido, al liberar a estos chips de la tarea de la música... que no de los efectos sonoros y las voces, de esto si se encarga la SNES).
.

Basicamente es eso, esta claro que cada uno es un hardware distinto uno es una consola y otro es un periferico de esta.. El cartucho tiene un hardware frutan en prestaciones, tanto por su Cortex M3 como el cyclone

bertobp escribió:No, siempre será una SNES porque el programa del juego siempre lo va correr la CPU anfitriona, es el mismo caso de los chips SFX

Me refería a algo muy diferente. Ya que hablamos de chips de expansión, imagina por un momento que llegas a desarrollar las especificaciones, esquema y software de un supuesto integrado que te permita generar poligonos (1.000.000 por ejemplo), dé 32 canales adicionales de sonido y otras pequeñas cosas, con el voltaje que puede suministrar la SNES.

Si, todo está muy bonito, una cosa es un super FX 1 o 2, el cual añadía cosas geniales a esos juegos, pero ¿no nos estamos olvidando de porqué seguimos usando aún consolas como una Lynx, por ejemplo?. Si pudieras implementar eso que he dicho ahí arriba, sería como tener una consola diferente, y para eso sinceramente me compro otro sistema, yo cuando voy a jugar una Super Nintendo espero ciertas cosas, no el tener la sensación de haber enchufado el mando a otra cosa diferente (Y ojo, no digo que no me gusten los procesadores de apoyo extra, tales como el MSU-1 o alguno venidero, sinó el ir mucho más lejos. Además de eso, a ver quien pagaría el precio del cartucho en sí mismo)

68000 escribió:Me refería a algo muy diferente. Ya que hablamos de chips de expansión, imagina por un momento que llegas a desarrollar las especificaciones, esquema y software de un supuesto integrado que te permita generar poligonos (1.000.000 por ejemplo), dé 32 canales adicionales de sonido y otras pequeñas cosas, con el voltaje que puede suministrar la SNES.

Si, todo está muy bonito, una cosa es un super FX 1 o 2, el cual añadía cosas geniales a esos juegos, pero ¿no nos estamos olvidando de porqué seguimos usando aún consolas como una Lynx, por ejemplo?. Si pudieras implementar eso que he dicho ahí arriba, sería como tener una consola diferente, y para eso sinceramente me compro otro sistema, yo cuando voy a jugar una Super Nintendo espero ciertas cosas, no el tener la sensación de haber enchufado el mando a otra cosa diferente (Y ojo, no digo que no me gusten los procesadores de apoyo extra, tales como el MSU-1 o alguno venidero, sinó el ir mucho más lejos. Además de eso, a ver quien pagaría el precio del cartucho en sí mismo)

Bueno, tambien podemos verlo desde otra perspectiva... muchos nos quedamos con las ganas de ver que nos hubiera ofrecido el SNES CD. Si un FPGA emula las caracteristicas de cómo iba a ser ese sistema, tambien podría tener su encanto (y con la capacidad de un DVD, con la ventaja de un cartucho que transmite datos a 20MB/s).

En realidad, con lo que es el MSU1 ya me doy por satisfecho (juegos de 4GB, sin las limitaciones de la memoria de video), y un procesador de audio adicional. Con eso la SNES ya gana un mundo.

Ralph escribió:Bueno, tambien podemos verlo desde otra perspectiva... muchos nos quedamos con las ganas de ver que nos hubiera ofrecido el SNES CD. Si un FPGA emula las caracteristicas de cómo iba a ser ese sistema, tambien podría tener su encanto (y con la capacidad de un DVD, con la ventaja de un cartucho que transmite datos a 20MB/s).

En realidad, con lo que es el MSU1 ya me doy por satisfecho (juegos de 4GB, sin las limitaciones de la memoria de video), y un procesador de audio adicional. Con eso la SNES ya gana un mundo.

A mi también me hubiera gustado ver qué podría haber hecho el Snes CD, o por lo menos ver demos técnicas, pero no pudo ser. Eso si, creo recordar que hace poco se puso en venta un prototipo del Snes CD con un mando incluido, no sé si se llegaría a vender y caer en manos adecuadas (para por ejemplo, fotografiar qué hay en la placa, si enciende y muestra algo, sus especificaciones técnicas, etc etc...).

Y si, el MSU1 es lo que deberían ser los chips de apoyo, con tan solo darte la opción de escuchar la versión que hicieron de Yume wa Owaranai más tarde en la Snes, merecería la pena comprar ese Sd2Snes.

68000 escribió:A mi también me hubiera gustado ver qué podría haber hecho el Snes CD, o por lo menos ver demos técnicas, pero no pudo ser. Eso si, creo recordar que hace poco se puso en venta un prototipo del Snes CD con un mando incluido, no sé si se llegaría a vender y caer en manos adecuadas (para por ejemplo, fotografiar qué hay en la placa, si enciende y muestra algo, sus especificaciones técnicas, etc etc...).

Ah, si, es verdad. Yo si he visto un video con ese prototipo. Sale un menú de la consola, y luego ponen el pac man, o algo así. ¿Ese era el prototipo de 32 bits que iba a ser el snes cd?

Sobre los juegos, si que hay imagenes por ahí de alguna cosilla que estaban preparando (como el 7th guest). En el hilo de la snes hay alguna cosilla sobre esto en el reportaje de los juegos cancelados


Sea como sea, a lo que mas ganas tengo de todo esto, es a ver de que es capaz la snes con un cartucho que vuelca 20MBytes/s de datos, sin cuellos de botella, ni espera. Prácticamente es como tener todo el juego en la ram

Y si, el MSU1 es lo que deberían ser los chips de apoyo, con tan solo darte la opción de escuchar la versión que hicieron de Yume wa Owaranai más tarde en la Snes, merecería la pena comprar ese Sd2Snes.

Al MSU1 le falta estar acompañado de unas buenas herramientas para programar en snes, y seguro qeu la escena sube como la espuma



EDIT: Este es el supuesto mando del prototipo del snes cd (si encuentro el video que comento, luego edito y lo pongo). 3000€, por cierto o_O

http://www.pixfans.com/el-pad-del-snes- ... ay-a-3000/


EDIT: Ya está, que rápido

http://www.youtube.com/watch?v=W78IUsRBvEw

...gamestation ^^

Ralph escribió:Ah, si, es verdad. Yo si he visto un video con ese prototipo. Sale un menú de la consola, y luego ponen el pac man, o algo así. ¿Ese era el prototipo de 32 bits que iba a ser el snes cd? [Alaa!]

Ese mando lo había visto, pero además de eso, también lo ví acompañado del supuesto prototipo del Snes CD:


(De este hilo -> hilo_hilo-oficial-quot-prototipos-de-consolas-quot_1457861_s250)

No sé en donde acabaría al final ese equípo, pero espero que algún día salga a la luz algo sobre el mismo.

Ralph escribió:Sea como sea, a lo que mas ganas tengo de todo esto, es a ver de que es capaz la snes con un cartucho que vuelca 20MBytes/s de datos, sin cuellos de botella, ni espera. Prácticamente es como tener todo el juego en la ram [chiu]

...

Al MSU1 le falta estar acompañado de unas buenas herramientas para programar en snes, y seguro qeu la escena sube como la espuma [babas]

Si el precio del Sd2Snes no es alto, algo así por ejemplo como 150€, podría se un buen impulso a la scene, pero lo malo es lo que dices, las herramientas. Las que existen ahora mismo están muy desperdigadas por la red, estaría bien que alguien desarrollara un kit completo o al menos parcial.

Ralph escribió: http://www.youtube.com/watch?v=W78IUsRBvEw

...gamestation ^^

xD es la primera que vez que veo eso, un Doctor con lector de discos fusionado con una SNES xD No muy barato debería ser para la epoca, me recuerda al CD64 para N64.

Eso parece un fake. ¿Para qué tendría una SNESCD botones de avance rápido?

para cambiar de cancion, supongo

matuanime escribió:para cambiar de cancion, supongo

¿En un videojuego?

socram8888 escribió:

matuanime escribió:para cambiar de cancion, supongo

¿En un videojuego?

el multimega lo tenía

Claro, pero también tenía función de reproductor portátil sin pantalla. MegaCD no

socram8888 escribió:

matuanime escribió:para cambiar de cancion, supongo

¿En un videojuego?

Si no tiene software reproductor de audio... como los antiguos CD_ROM de PC, que no necesitaban OS para reproducir CD audio

Hombre, pero dudo mucho que no tuviese software reproductor de audio. Vamos, al menos nunca he visto una consola con CD que lleve botones en lugar de un menú

ademas hay que tener en cuenta que es un prototipo puede tener todos los botones que quiera. ademas de puertos de expansion y demas. lo que importa es el modelo final donde solo se deja lo justo y comercialmente minimo reocomendado (bueno aveces menos de eso)

A titulo informativo, todavía no he podido encontrar una tarjeta de sonido que se ajuste a mis necesidades, por lo que creo que voy a tardar un tanto más en poder ofreceros el tutorial.

Un saludo.