Sobre la capacidad de audio de las 16 bits, y su hipotético límite real...

Archivado
1, 2
Un pequeño ejercicio práctico.

Centrándome en el sistema de audio de la snes... esta puede procesar samples de sonido de 32Khz a 16 bits, pero nos encontramos con que almacenar los samples necesarios para componer un tema a esa calidad choca con la limitada capacidad de almacenamiento de la consola (64KB), por lo que un sample necesario para reproducirse tardará demasiados frames en cargarse como para estar listo a tiempo, además del hecho de que tendrías que borrar otros para meter el nuevo, y podría ser que sea necesario para reproducirse también justo ahora.

¿Conclusión?, te cargas la partitura. No es viable.

La solución es hacer un streaming de audio, de modo que además ahorrarías canales de sonido para efectos de sonido (lo cual es una agradable ventaja), y de paso conseguirías un gran salto en calidad de sonido, además de en su complejidad, pudiendo permitir así incluso canciones.


Bien, son buenas ventajas, pero, ¿que calidad se puede alcanzar así?, y mas importante aún... ¿hay ancho de banda para tanto?.

Pues veamos... teniendo en cuenta que el ancho de banda de la snes es de 5,72KB por frame, y que en un segundo hay 60 frames, tenemos que la snes transfiere 343,2KB por segundo. que es un 33% mas rápido que un lectgor de CD de 2X, y teniendo en cuenta que esos bichos reproducían música a 44Khz, la cosa pinta muy bien.

Ya solo queda por saber cual es el precio a pagar en términos de ancho de banda... cuanta de esa cantidad va a ser necesaria para poder reproducir una canción en stereo a una calidad cercana al CD.

Bien, pues tenemos que16(bits)*32000(Hz)*2(canales)/1000(kb)=1024kbps.

Esto está en bits, así que hay que hacer la conversión a bytes. 1024/8=128KB por segundo... ¡mira, como un mp3 a 128Kbs!.

Pero eso no resuelve la pregunta del ancho de banda, puesto que necesito saber cuánto voy a tener que sacrificar por frame, que es la medida con la que tengo que contar para hacer mis cosas.
Pues es tan sencillo como dividir 128KB entre 60, que da una cantidad de 2,13KB por frame del ancho de banda total, lo cual nos deja una cantidad de 3,59KB por frame para gráficos (los efectos de sonido los puedes dejar almacenados en su mayoría).


Pues resuelto entonces, la snes puede reproducir una canción a 128KB/s reservando 6 canales para los efectos de sonido, pero, ¿como se procede?.

Pues básicamente vas a necesitar reservar una pequeña cantidad de memoria de la ram del sistema de audio a modo de "doble buffer". Tienes dos regiones de memoria desde las que se reproduce la canción para cada canal, mientras que en otras dos regiones el DMA está cargando el siguiente "trozo" a reproducir en cuánto el actual termine de leerse.

¿Y cuánto tamaño debe tener ese doble buffer?, pues depende de la cantidad de trocitos quieras tener que estar preparando para que se reproduzca una canción entera. El mínimo serían 4,26KB reservados de los 63,5KB de la memoria ram del sonido, y el máximo, hasta que ocupes toda la memoria, si quieres.


¿Ventajas e inconvenientes?, pues que cuánto menor sea el buffer, mas espacio dejas para almacenar efectos de sonido, y que cuánto mayor sea el buffer menos espacio te quedará para guardarlos, pero a cambio dará menos trabajo tener que dividir la canción en menos "trocitos".


Eso es todo, mas caótico imposible, pero no tengo tiempo de ordenarlo (y tampoco creo que sea tan chungo).
https://www.youtube.com/watch?v=TJ7pENNocbo
La primera frase no podría ser mas desacertada.
Un ejemplo de en que juegos se le podría sacar provecho a esto, sería el rock'n roll racing.
Ese juego almacena el escenario en la VRAM de una vez, y se queda instalado, y luego los 4 coches con sus animaciones, también. Una vez cargado el escenario, y empiezas a jugar, el DMA no transfiere ningún tipo de gráficos, o no sería necesario que lo hiciera, vaya.

Esto deja todo el ancho de banda para música y efectos de sonido... y viendo el ejemplo anterior, hay potencial de sobra para que las músicas sean las reales, además de que te podrías permitir que el narrador no deje de hablar.

¡No necesitas el MSU1!.

Furrinchas escribió:La primera frase no podría ser mas desacertada.


Pero el concepto si lo es, explicarlo es otra cosa xD
Meando un poco fuera del tiesto... y no hablo del sonido, no era esto lo que querían conseguir con el cdrom de la megadrive?

Es decir, estuve leyendo a nosekuawa (léase japo cuyo nombre no recuerdo), que participó en el diseño del megacd, que el objetivo inicial del megacd era superar el límite de capacidad que te imponía el cartucho (poca capacidad y muy caro), para ello primero cargarían el juego y luego, según iba necesitando el desarrollador, ir borrando y cargando partes nuevas del cd.

Pero claro, el megacd era caro, y además con una velocidad de lectura de mierda, y luego les dio a todos por usarlo para vídeos de mierda en vez de usarlo para su objetivo inicial.

En fin, no es mi intención ensuciar el hilo, pero si el ejercicio práctico vale para sonido, porqué no para sprites, rutinas de IA, nuevas fases, etc
¿Una 16 bits con música de calidad CD? Lo veo imposible.
danibus escribió:En fin, no es mi intención ensuciar el hilo, pero si el ejercicio práctico vale para sonido, porqué no para sprites, rutinas de IA, nuevas fases, etc


Es que una animación es un streaming de tiles, y esa "técnica" no se había hecho nunca con el sonido de una forma tan directa.

P.D: El lector de CD del megacd lee(valga la redundancia) a 150KB/s. La megadrive puede reproducir vídeos notablemente a mas calidad y mas fotogramas que el megacd (pero los cartuchos no admiten mas de 32mb sin mapear).

Coliflor escribió:¿Una 16 bits con música de calidad CD? Lo veo imposible.


https://www.youtube.com/watch?v=p_60V8UdYEY
Señor Ventura escribió:https://www.youtube.com/watch?v=p_60V8UdYEY
Impresionante ese sonido, y uno que sale en relacionados con el pcm de la mega. Es increíble lo que nos falta por ver exprimiendo esas consolas.
Manveru Ainu escribió:
Señor Ventura escribió:https://www.youtube.com/watch?v=p_60V8UdYEY
Impresionante ese sonido, y uno que sale en relacionados con el pcm de la mega. Es increíble lo que nos falta por ver exprimido en esas consolas.


A mi me está matando la ingenieria, pero como me pegue un año sabático le voy a meter tal pedrada a la programación de snes, que si no hago algo para esta máquina de aquí a un lustro, me corto los huevines xD

edit:
https://www.youtube.com/watch?v=h9WzrJ5OyWA
Pero el problema no es que la ROM debería ser prohibitivamente enorme? Supongo que es por esto que ningún juego comercial de su época utilizase esta técnica.
Señor Ventura escribió:A mi me está matando la ingenieria, pero como me pegue un año sabático le voy a meter tal pedrada a la programación de snes, que si no hago algo para esta máquina de aquí a un lustro, me corto los huevines xD

edit:
https://www.youtube.com/watch?v=h9WzrJ5OyWA
Conozco a más de uno que le gustaría más actividad en la SNES jejeje, a ver si te enganchas.

Justo ese vídeo era [oki]

@Gammenon sí, es la cosa, que eso ocupa una barbaridad. El del vídeo de la mega creo que dice que solo la canción ocupa 24mbits
(mensaje borrado)
Señor Ventura escribió:
Coliflor escribió:¿Una 16 bits con música de calidad CD? Lo veo imposible.


https://www.youtube.com/watch?v=p_60V8UdYEY


Hosssstiasss!!! Me acabas de fundir los plomos. [looco]
Te voy a meter un capón de los gordos, @Señor Ventura... ¡La SNES no trasmite los samples de audio por DMA ni necesariamente durante el NMI!
Así que lamento decirte que tus cálculos no sirven cawento

El audio de la SNEs es un subsistema propio, dotado de boot (para cargar el código inicial al micro), microprocesador (SPC700), coprocesador (es un DSP dediado a procesar samples) y 64KB de RAM propia.
Para acceder a ese subsistema desde el micro principal (el 65C816) se hace de esta manera:

SuperFamicom Wiki

Francamente, me encanta ver tu entusiasmo, @Señor Ventura y me gustaría que tuvieras un nivel suficiente para mantener charlas productivas (incluso podríamos colaborar para hacer cosas chulas en SNES), pero te montas unas enormes pajas mentales infundadas y llenas el foro de información confusa e inexacta, cosa que se podía evitar fácilmente consultando la Wikipedia (donde explica el subsistema de audio de la SNES) o SuperFamicom Wiki. Concretamente, esto del audio te lo comenté acuando hablamos del SFA2, que el parón inicial antes del combate se hace porque se ha de transferir el audio al subsistema [enfa]

Por cierto, la SNES nunca puede sacar audio en calidad CD puesto que la "calidad CD" como tal implica siempre 44.1KHz de frecuencia de muestreo de audio.
magno escribió:Te voy a meter un capón de los gordos, @Señor Ventura... ¡La SNES no trasmite los samples de audio por DMA ni necesariamente durante el NMI!
Así que lamento decirte que tus cálculos no sirven cawento

El audio de la SNEs es un subsistema propio, dotado de boot (para cargar el código inicial al micro), microprocesador (SPC700), coprocesador (es un DSP dediado a procesar samples) y 64KB de RAM propia.
Para acceder a ese subsistema desde el micro principal (el 65C816) se hace de esta manera:

SuperFamicom Wiki

Francamente, me encanta ver tu entusiasmo, @Señor Ventura y me gustaría que tuvieras un nivel suficiente para mantener charlas productivas (incluso podríamos colaborar para hacer cosas chulas en SNES), pero te montas unas enormes pajas mentales infundadas y llenas el foro de información confusa e inexacta, cosa que se podía evitar fácilmente consultando la Wikipedia (donde explica el subsistema de audio de la SNES) o SuperFamicom Wiki. Concretamente, esto del audio te lo comenté acuando hablamos del SFA2, que el parón inicial antes del combate se hace porque se ha de transferir el audio al subsistema [enfa]

Por cierto, la SNES nunca puede sacar audio en calidad CD puesto que la "calidad CD" como tal implica siempre 44.1KHz de frecuencia de muestreo de audio.


Me siento como un niño con tirachinas en el paraíso de los jarrones de porcelana xD

Estaba convencido de que los parones del SFA2 se debían al proceso de reiniciar el driver de sonido, y no a la transferencia de samples, de hecho la razón de que tarde tanto es debida a que se hace por HDMA (si paras todo para llenar la ram del sonido, lo estarás haciendo a 5,72KB, y completarías la tarea en menos de 12 frames, no los 4 o 5 segundos que tarda el juego).

A veces como me entiendo yo solo, luego no me doy cuenta de las que lio... el DMA está "imbuído" dentro de una de las ppu's del sistema de vídeo, y comunica únicamente la VRAM con la ROM, por lo que no es posible compartir ese canal con la RAM del sistema de sonido. Hablar de DMA cuando hablas del sonido es una cagada importante, claro...

La cuestión es que el bus que comunica la RAM del sonido con la ROM, sigue siendo de 5,72KB por frame, ¿no?... la pega es que gráficos y sonido tienen que transferir datos turnandose, entonces.

Pero tal vez si sea posible apañar un buffer, después de todo (de hecho, es que sin el no habría streaming que valga).


P.D: Estoy rezando para no haber dicho otra de las mías XD
Teorizar y practicar, o por lo menos conocer los detalles de la práctica, no sólo de la teoría; sólo teorizando es más cómodo todo, pero se comenten más errores, sobre todo si se quiere juzgar el trabajo real de otros.

De nada vale teorizar y especular sobre cosas si luego se caen fácilmente en la práctica; y en programación esto debería ser básico; donde en teoría puedes abrir una puerta igual cierras otras, pero si no lo has comprobado realmente puede ser imposible que lo sepas, porque la teoría a lo peor lo omite.

El otro día estuve viendo la peli de Tom Hanks del Apollo XIII (ya había visto la peli hace mucho, y después un documental también), y se ve claramente que si hubieran tirado sólo de teoría, aún siendo todos expertos, profesionales, e incluso los propios diseñadores de las naves y módulos, desde luego los astronautas no habrían vuelto.
Señor Ventura escribió:Estaba convencido de que los parones del SFA2 se debían al proceso de reiniciar el driver de sonido, y no a la transferencia de samples [...]


A ver, no lo he examinado en detalle, pero lo que se comenta en otros foros y la lógica dice que el parón es por enviar todo a la ARAM (Audio RAM) del SPC-700.

Señor Ventura escribió: [...] de hecho la razón de que tarde tanto es debida a que se hace por HDMA (si paras todo para llenar la ram del sonido, lo estarás haciendo a 5,72KB, y completarías la tarea en menos de 12 frames, no los 4 o 5 segundos que tarda el juego).


No, no se hace por HDMA. El HDMA, como ya te he comentado en otra ocasión, es Horizontal Direct Memory Access, y se usa para acceder a la PPU durante el borrado horizontal en vez de el vertical. Esto permite cambiar ciertos registros de la PPU cada línea de pantalla de forma automatizada, ya que el HDMA lo programas antes de que empiece el frame siguiente y éste va saltando automáticamente en cada línea haciendo las transferencias deseadas.

Y no, para transferir los samples de audio has de hacer lo que puse en el link anterior... ¿Lo has mirado? [poraki] Se hace escribiendo en unos registros, pero no por DMA, sino registro a registro.



Señor Ventura escribió:el DMA está "imbuído" dentro de una de las ppu's del sistema de vídeo, y comunica únicamente la VRAM con la ROM, por lo que no es posible compartir ese canal con la RAM del sistema de sonido. Hablar de DMA cuando hablas del sonido es una cagada importante, claro...


Tampoco, macho, estás en racha [beer] El DMA es un modo de transferencia de datos entre el bus A y el bus B de la SNES. El bus A es el que todos conocemos como bus estándar: el que está conectado al bus de direcciones del micro principal 65C816 por el que se accede a RAM y ROM.
El bus B es un bus separado que está mapeado en las direcciones $21XX del mapa de memoria de la SNES. Este bus conecta el micro con los "periféricos" del sistema: PPU y sus modos gráficos, CG-RAM (paleta de colores), OAM (memoria de sprites), VRAM (memoria de video), multiplicadores, divisores, etc...
Las transferencias DMA solo se pueden hacer entre el bus-A y el bus-B o viceversa. Así, por ejemplo, EN PRINCIPIO (con lo que te acabo de explicar) no puedes hacer DMA entre la dirección de RAM $7E:8000 y la $7F:0000, por ejemplo, porque ambas direcciones están en el bus A; tampoco podrías hacerlas entre ROM $C0:0000 y $7F:8000, por ejemplo. Pero como esas dos transferencias podrían ser útiles a los programadores, los desarrolladores del hardware de Nintendo abrieron hábilmente un acceso en el bus-B para acceder a la RAM del sistema. Así, puedes hacer una transferencia DMA desde ROM $C0:0000 al registro $2180, previamente habiendo configurado $2181/82/83 con la dirección $7F:8000.


Señor Ventura escribió:La cuestión es que el bus que comunica la RAM del sonido con la ROM, sigue siendo de 5,72KB por frame, ¿no?... la pega es que gráficos y sonido tienen que transferir datos turnandose, entonces.


¡¡Tampoco!! ¡Has hecho pleno! [carcajad] [carcajad] [carcajad] No hay bus específico que comunica la ROM (que está en el bus A) con la ARAM (que está en el bus B, registro $2140); a priori podrías decir: "hombre, pues hago un DMA desde ROM al registro $2140 y envío todos los samples"... Y eso técnicamente es posible, pero el resultado no sería válido, es decir, no habrías conseguido meter los samples en ARAM... ¿Por qué? Pues si miras el código ensamblador que te enlacé antes, verás que cada byte de samples que se envían a ARAM implica escribir el byte en el registro $2140 y esperar a que el SPC-700 lo lea, momento en el cual cambia el valor que el 65C816 lee del registro $2140 y es una forma de confirmar que el SPC-700 ha recibido ese byte.
Si quieres saber la velocidad de transferencia de muestras, tendrías que ejecutar ese código en el bsnes con el perfil ACCURACY y comprobar cuánto tarda en transferir 1Kbyte, por ejemplo. Ya te digo que el tiempo es mucho mayor del que imaginas.
magno escribió:
Señor Ventura escribió:Estaba convencido de que los parones del SFA2 se debían al proceso de reiniciar el driver de sonido, y no a la transferencia de samples [...]


A ver, no lo he examinado en detalle, pero lo que se comenta en otros foros y la lógica dice que el parón es por enviar todo a la ARAM (Audio RAM) del SPC-700.

Señor Ventura escribió: [...] de hecho la razón de que tarde tanto es debida a que se hace por HDMA (si paras todo para llenar la ram del sonido, lo estarás haciendo a 5,72KB, y completarías la tarea en menos de 12 frames, no los 4 o 5 segundos que tarda el juego).


No, no se hace por HDMA. El HDMA, como ya te he comentado en otra ocasión, es Horizontal Direct Memory Access, y se usa para acceder a la PPU durante el borrado horizontal en vez de el vertical. Esto permite cambiar ciertos registros de la PPU cada línea de pantalla de forma automatizada, ya que el HDMA lo programas antes de que empiece el frame siguiente y éste va saltando automáticamente en cada línea haciendo las transferencias deseadas.

Y no, para transferir los samples de audio has de hacer lo que puse en el link anterior... ¿Lo has mirado? [poraki] Se hace escribiendo en unos registros, pero no por DMA, sino registro a registro.



Señor Ventura escribió:el DMA está "imbuído" dentro de una de las ppu's del sistema de vídeo, y comunica únicamente la VRAM con la ROM, por lo que no es posible compartir ese canal con la RAM del sistema de sonido. Hablar de DMA cuando hablas del sonido es una cagada importante, claro...


Tampoco, macho, estás en racha [beer] El DMA es un modo de transferencia de datos entre el bus A y el bus B de la SNES. El bus A es el que todos conocemos como bus estándar: el que está conectado al bus de direcciones del micro principal 65C816 por el que se accede a RAM y ROM.
El bus B es un bus separado que está mapeado en las direcciones $21XX del mapa de memoria de la SNES. Este bus conecta el micro con los "periféricos" del sistema: PPU y sus modos gráficos, CG-RAM (paleta de colores), OAM (memoria de sprites), VRAM (memoria de video), multiplicadores, divisores, etc...
Las transferencias DMA solo se pueden hacer entre el bus-A y el bus-B o viceversa. Así, por ejemplo, EN PRINCIPIO (con lo que te acabo de explicar) no puedes hacer DMA entre la dirección de RAM $7E:8000 y la $7F:0000, por ejemplo, porque ambas direcciones están en el bus A; tampoco podrías hacerlas entre ROM $C0:0000 y $7F:8000, por ejemplo. Pero como esas dos transferencias podrían ser útiles a los programadores, los desarrolladores del hardware de Nintendo abrieron hábilmente un acceso en el bus-B para acceder a la RAM del sistema. Así, puedes hacer una transferencia DMA desde ROM $C0:0000 al registro $2180, previamente habiendo configurado $2181/82/83 con la dirección $7F:8000.


Señor Ventura escribió:La cuestión es que el bus que comunica la RAM del sonido con la ROM, sigue siendo de 5,72KB por frame, ¿no?... la pega es que gráficos y sonido tienen que transferir datos turnandose, entonces.


¡¡Tampoco!! ¡Has hecho pleno! [carcajad] [carcajad] [carcajad] No hay bus específico que comunica la ROM (que está en el bus A) con la ARAM (que está en el bus B, registro $2140); a priori podrías decir: "hombre, pues hago un DMA desde ROM al registro $2140 y envío todos los samples"... Y eso técnicamente es posible, pero el resultado no sería válido, es decir, no habrías conseguido meter los samples en ARAM... ¿Por qué? Pues si miras el código ensamblador que te enlacé antes, verás que cada byte de samples que se envían a ARAM implica escribir el byte en el registro $2140 y esperar a que el SPC-700 lo lea, momento en el cual cambia el valor que el 65C816 lee del registro $2140 y es una forma de confirmar que el SPC-700 ha recibido ese byte.
Si quieres saber la velocidad de transferencia de muestras, tendrías que ejecutar ese código en el bsnes con el perfil ACCURACY y comprobar cuánto tarda en transferir 1Kbyte, por ejemplo. Ya te digo que el tiempo es mucho mayor del que imaginas.


Tenía entendido que era muy lento pasar los datos al SPC-700 pero no sospechaba que fuese tan lento. Entonces lo de cambiar los samples mientras el juego esté en funcionamiento, como hacen los Sonics en los créditos finales como que no, no?
Gammenon escribió:Tenía entendido que era muy lento pasar los datos al SPC-700 pero no sospechaba que fuese tan lento. Entonces lo de cambiar los samples mientras el juego esté en funcionamiento, como hacen los Sonics en los créditos finales como que no, no?


Sí, es muy lento el proceso, a pesar de ser un sub-sistema de audio muy potente. Lo de cambiar los samples con el juego funcionando sí se hace en algunos juegos de plataformas, por ejemplo en la trilogía Star Wars, que cuando empieza el jefe de final de fase cambia la música y para hacerlo, crean el efecto de "cámara lenta" mientras el monstruo entra en pantalla. Era algo bastante habitual en los juegos cuando llegabas al monstruo final, que uno pensaba que el efecto de "cámara lenta" era para hacerlo más épico y normalmente era para tener más tiempo para meter nuevas tiles en VRAM e ir actualizando la memoria de sonido.
Los tipicos parones que se aprecian en el axelay, casualmente cuando cambia de música, ¿es por esa razón?
O´Neill escribió:Los tipicos parones que se aprecian en el axelay, casualmente cuando cambia de música, ¿es por esa razón?


Habría que confirmarlo viendo el código, pero lo más seguro es que sí.
Recuerdo que en los menús de Romancing Saga 3, cada vez que seleccionas una poción o algo que modifica el estado actual del personaje, sonaba un sonidito de confirmación que se cargaba cada vez que pulsabas el botón 'A' para aceptar la acción en concreto. Cuando dumpeaba el código, veía miles de línea que sabía que pertenecían al driver de sonido y que duraban como 2~3 frames, solo para enviar el sonidito a la APU.
MITO... busted pues
danibus escribió:MITO... busted pues


¿A qué te refieres? El "mito" como tú lo llamas es una realidad: el sonido de la SNES es mucho mejor que el del resto de máquina de su nivel y potencia; Lo que pasa es que la comunicación con él es poco flexible para toda la flexibilidad de programación que tiene la APU (por todos los microcódigos que puedes descargar y las diferentes configuraciones del DSP), pero eso no quita que se hayan hecho grandes obras musicales para la SNES.
magno escribió:
danibus escribió:MITO... busted pues


¿A qué te refieres? El "mito" como tú lo llamas es una realidad: el sonido de la SNES es mucho mejor que el del resto de máquina de su nivel y potencia; Lo que pasa es que la comunicación con él es poco flexible para toda la flexibilidad de programación que tiene la APU (por todos los microcódigos que puedes descargar y las diferentes configuraciones del DSP), pero eso no quita que se hayan hecho grandes obras musicales para la SNES.


El scp700 no era un chip del todo adecuado para una consola como SNES basada en cartuchos, donde habia que estar comprimiendo todo para abaratar costo de la ROM, la que si le sacó jugo fue la PS1 que lleva el mismo chip o una evolución de este y ahi si que le dieron pa tenga y guarde, tambien hubiera estado bueno que Sony hubiese lanzaddo una version en tarjeta ISA para PCs, pero viendo la oferta de la competencia ni siquiera se lo plantearon, Roland Sound Canvas, Yamaha SW600, Creative waveblaster etc.
magno escribió:
Señor Ventura escribió:Estaba convencido de que los parones del SFA2 se debían al proceso de reiniciar el driver de sonido, y no a la transferencia de samples [...]


A ver, no lo he examinado en detalle, pero lo que se comenta en otros foros y la lógica dice que el parón es por enviar todo a la ARAM (Audio RAM) del SPC-700.


Es que se me hace rarísimo tener que estar escribiendo samples en ram que ya están ahí a cada round, ese problema no sucede por ejemplo en el street fighter 2 world warrior/turbo, y viendo como suenan los 3, dudo que el alpha 2 requiera mas memoria.

magno escribió:No, no se hace por HDMA. El HDMA, como ya te he comentado en otra ocasión, es Horizontal Direct Memory Access, y se usa para acceder a la PPU durante el borrado horizontal en vez de el vertical. Esto permite cambiar ciertos registros de la PPU cada línea de pantalla de forma automatizada, ya que el HDMA lo programas antes de que empiece el frame siguiente y éste va saltando automáticamente en cada línea haciendo las transferencias deseadas.


Si, 4 bytes por scanline, pero pensaba que ese tiempo podías emplearlo en comunicarte con el spc700, tenga sentido o no (es obvio que no tengo bien miradas las direcciones de memoria ^^u).

magno escribió:Y no, para transferir los samples de audio has de hacer lo que puse en el link anterior... ¿Lo has mirado? [poraki] Se hace escribiendo en unos registros, pero no por DMA, sino registro a registro.


Si, y me pareció un trabajo de chinos xD

Tiene que haber alguna salida, porque claramente el streaming de audio (en el vídeo dice que son 4MB en un minuto, pero en realidad son 8), está transifiriendo a una tasa de datos 16 veces superior a la que en teoría estoy viendo que en realidad parece que hace (en condiciones normales).

magno escribió:Tampoco, macho, estás en racha [beer] El DMA es un modo de transferencia de datos entre el bus A y el bus B de la SNES. El bus A es el que todos conocemos como bus estándar: el que está conectado al bus de direcciones del micro principal 65C816 por el que se accede a RAM y ROM.
El bus B es un bus separado que está mapeado en las direcciones $21XX del mapa de memoria de la SNES. Este bus conecta el micro con los "periféricos" del sistema: PPU y sus modos gráficos, CG-RAM (paleta de colores), OAM (memoria de sprites), VRAM (memoria de video), multiplicadores, divisores, etc...
Las transferencias DMA solo se pueden hacer entre el bus-A y el bus-B o viceversa. Así, por ejemplo, EN PRINCIPIO (con lo que te acabo de explicar) no puedes hacer DMA entre la dirección de RAM $7E:8000 y la $7F:0000, por ejemplo, porque ambas direcciones están en el bus A; tampoco podrías hacerlas entre ROM $C0:0000 y $7F:8000, por ejemplo. Pero como esas dos transferencias podrían ser útiles a los programadores, los desarrolladores del hardware de Nintendo abrieron hábilmente un acceso en el bus-B para acceder a la RAM del sistema. Así, puedes hacer una transferencia DMA desde ROM $C0:0000 al registro $2180, previamente habiendo configurado $2181/82/83 con la dirección $7F:8000.


Lo que pensaba es que de ese modo de transferencia para el bus de datos, se encarga el sistema de vídeo. La cpu le dice al sistema de vídeo lo que va a necesitar, y este lo baja de la rom.

Eso que comentas es lo que sucede por ejemplo en el super mario world, en el que se transfieren tiles comprimidas a la memoria RAM, y se envían descomprimidas a la VRAM a través de la dirección $7E:8000 y $7F:0000 que comentas, ¿no?.
Pero lo de configurar el registro $2181/82/83 como registro $2180 se me escapa, ¿con que instrucción puedes hacer eso?.

magno escribió:¡¡Tampoco!! ¡Has hecho pleno! [carcajad] [carcajad] [carcajad] No hay bus específico que comunica la ROM (que está en el bus A) con la ARAM (que está en el bus B, registro $2140); a priori podrías decir: "hombre, pues hago un DMA desde ROM al registro $2140 y envío todos los samples"... Y eso técnicamente es posible, pero el resultado no sería válido, es decir, no habrías conseguido meter los samples en ARAM... ¿Por qué? Pues si miras el código ensamblador que te enlacé antes, verás que cada byte de samples que se envían a ARAM implica escribir el byte en el registro $2140 y esperar a que el SPC-700 lo lea, momento en el cual cambia el valor que el 65C816 lee del registro $2140 y es una forma de confirmar que el SPC-700 ha recibido ese byte.


Como para volver a fiarme de los diagramas... [+risas]

Estoy leyendo que puedes usar el HDMA para que el 65c816 lea ese registro... pero esto sigue siendo lento, aunque evitas tener a la cpu constantemente ocupada, ¿no?. Vamos, no usas el HDMA para transferir, sino para "checkear", así que estaba equivocado, claro.

Todavía me encuentro algo confuso con esto, es como si hubiera que paralizar todo para mandar samples mas rápido... coño, y acabo de caer en la cuenta de que eso es lo que sucede xDDD. ¿Entonces lo he entendido bien?.

Pero, ¿como se explica que se puedan enviar samples todavía mas rápido?:
https://youtu.be/p_60V8UdYEY?t=13

magno escribió:Si quieres saber la velocidad de transferencia de muestras, tendrías que ejecutar ese código en el bsnes con el perfil ACCURACY y comprobar cuánto tarda en transferir 1Kbyte, por ejemplo. Ya te digo que el tiempo es mucho mayor del que imaginas.


Con esto ya me tiras por la ventana.

8 frames... es que no puede ser [burla3]

chinitosoccer escribió:El scp700 no era un chip del todo adecuado para una consola como SNES basada en cartuchos, donde habia que estar comprimiendo todo para abaratar costo de la ROM, la que si le sacó jugo fue la PS1 que lleva el mismo chip o una evolución de este y ahi si que le dieron pa tenga y guarde, tambien hubiera estado bueno que Sony hubiese lanzaddo una version en tarjeta ISA para PCs, pero viendo la oferta de la competencia ni siquiera se lo plantearon, Roland Sound Canvas, Yamaha SW600, Creative waveblaster etc.


Te refieres al concepto de sonido, y no a la cpu, ¿no? (que en si misma no tiene ninguna culpa de nada).

De todos modos, viendo algunos resultados, tengo que discrepar, porque se han hecho cosas tremendas para lo que son las 16 bits.
danibus escribió:Es decir, estuve leyendo a nosekuawa (léase japo cuyo nombre no recuerdo), que participó en el diseño del megacd, que el objetivo inicial del megacd era superar el límite de capacidad que te imponía el cartucho (poca capacidad y muy caro), para ello primero cargarían el juego y luego, según iba necesitando el desarrollador, ir borrando y cargando partes nuevas del cd.

Pero claro, el megacd era caro, y además con una velocidad de lectura de mierda, y luego les dio a todos por usarlo para vídeos de mierda en vez de usarlo para su objetivo inicial.



Se q el comentario tiene unos dias, pero joder... no podia dejarlo pasar, es que no pegas ni una

Primero, fijate el catalogo de MegaCD, y veras q los juegos FMV son una parte no tan significativa del catalogo total, 15% aproximado

Segundo, el objetivo de cualquier consola con CD de la epoca, era superar el limite del cartucho...

Y cargar partes del juego en memoria, ir borrando, y cargando partes nuevas... es que eso no tiene sentido alguno mencionarlo... :-? ....pero si es la unica forma q tiene de funcionar cualquier consola en CDs...!! :-? :-? :-?

Tercero, no era caro, fijate precios los lectores de CD de la epoca

De ultimo, la velocidad de lectura del MegaCD, 1x era la estandar de la epoca, y es mas que suficiente, 150kbps es perfecto para la memoria q tiene el megaCD, llenas la ram en 3 segundos... para q mas?

El problema de todos los lectores de la epoca es el tiempo de acceso, no la transferencia. Devido al tiempo de acceso no se puede usar como rom

La gracia es que justo estoy viendo una peli de esas miniHD q tanto abundan por la red, ocupa 789 megas, y la peli dura 1:32 minutos calidad 1080p

789 megas / 92 minutos = 8.57 megas por minuto
8.57 / 60 = 0.142


O sea, que el MegaCD con su lector 1x le daria perfectamente para reproducir 1080p :-|
A mi me hubiese gustado un MegaCD con mas Ram, o por lo menos expandible por medio de algún cartucho, pero hace tiempo estuve leyendo y al parecer no hay forma de establecer esa "comunicacion" entre el slot de cartuchos como expansion de RAM y el MegaCD, alguna limitacion del hardware que no permite al VDP acceder a la ROM como lo hace PC Engine, NES o Neogeo, sin antes pasar por la RAM de video......o algo asi :-?
Señor Ventura escribió:Es que se me hace rarísimo tener que estar escribiendo samples en ram que ya están ahí a cada round, ese problema no sucede por ejemplo en el street fighter 2 world warrior/turbo, y viendo como suenan los 3, dudo que el alpha 2 requiera mas memoria.


No son el mismo juego realmente... Si no recuerdo mal, en la presentación de personajes antes de un combate del SFII la música no cambia, es la principal, pero con unos acordes que terminan en fade-out. En el SFA2 creo recordar que la música sí es diferente, por lo que en algún momento hay que cargar las voces de presentación y la música del escenario.
Lo digo de memoria, igual sí se hubiera podido hacer mejor, no sé.


Señor Ventura escribió:Tiene que haber alguna salida, porque claramente el streaming de audio (en el vídeo dice que son 4MB en un minuto, pero en realidad son 8), está transifiriendo a una tasa de datos 16 veces superior a la que en teoría estoy viendo que en realidad parece que hace (en condiciones normales).


¿Y cómo sabes eso? ¿Cómo has calculado esas tasas? El bucle de trasnferencia que te linké dura 26 ciclos por cada byte transferido a $2140 y faltaría saber cuándo el SPC-700 ha leído dicho dato. Si te haces un driver bueno, podrías escribir desde la CPU $2140, luego $2141, luego $2142 y por último $2143 de forma consecutiva y que el programa que corre en el SPC-700 los vaya enviando a su ARAM de forma secuencial. Así reduces la espera a 1 vez cada 4 bytes que escribes.
Luego, esta transferencia se hace en cualquier instante, no hace falta esperar a NMIs ni nada, así que:

1 frame = 262 scanlines activas * 1362 master clocks por línea = 357368 master clocks

La CPU ejecuta cada instrucción en 6 master clocks * 26 ciclos que dura el bucle = 156 master clocks por cada byte enviado al SPC-700

Por tanto, ejecutas 2290 veces el bucle de audio en un frame si el tiempo de respuesta del SPC-700 es de 1 ciclo; si fuera de 4 (es el máximo porque funciona a 1MHz y el de SNES a 3.58MHz), tendrías lo ejecutarías 572 veces (572 bytes transferidos) en un frame EN EL PEOR CASO.

Pensando que solo transfieres samples con BBR (que comprime en un ratio 32:9), habrías enviado 1018 muestras de audio de 16 bits en un solo frame. En 1 segundo (60 frames) enviarías unos 61000 muestras de 16 bits EN EL PEOR CASO, 244000 EN EL MEJOR CASO.

¿En serio te parece poco 60Kmuestras por segundo para un sistema de audio que trabaja a 32kHz? Es prácticamente el doble de la tasa de muestreo en el peor de los casos. Y como normalmente las muestras de toda la música la envías del tirón antes de empezar una fase o una escena, podrías enviar una canción de 10 segundos de duración en 2~4 segundos sin problemas. Y todo esto, sabiendo que como mucho tienes 64KBytes para almacenar muestras en la RAM de la APU, pues fijate que todo el sistema está más o menos bien escalado: llenarías la ARAM en un cuarto de segundo (250 mseg) enviando muestras en el peor de los casos.

Un driver bien programado podría tener una rutina que agilizara al máximo la recepción de samples en el SPC-700 y a la que se llamara desde el micro principal cuando se necesitara enviar samples.




Señor Ventura escribió:Eso que comentas es lo que sucede por ejemplo en el super mario world, en el que se transfieren tiles comprimidas a la memoria RAM, y se envían descomprimidas a la VRAM a través de la dirección $7E:8000 y $7F:0000 que comentas, ¿no?.


Bueno, eso pasa con todos los juegos que conozco que tienen los gráficos comprimidos: los descomprimen a RAM primero mientras los van leyendo de ROM y de ahí lo envían a VRAM.

Señor Ventura escribió:Pero lo de configurar el registro $2181/82/83 como registro $2180 se me escapa, ¿con que instrucción puedes hacer eso?.


Para configurar la dirección de RAM $7E:8000
LDA.w #$8000
STA.w $2180
STZ.w $2183


Para configurar la dirección de RAM $7F:4530
LDA.w #$4530
STA.w $2180
LDA.b #$01
STA.w $2183




Señor Ventura escribió:Estoy leyendo que puedes usar el HDMA para que el 65c816 lea ese registro... pero esto sigue siendo lento, aunque evitas tener a la cpu constantemente ocupada, ¿no?. Vamos, no usas el HDMA para transferir, sino para "checkear", así que estaba equivocado, claro.

Todavía me encuentro algo confuso con esto, es como si hubiera que paralizar todo para mandar samples mas rápido... coño, y acabo de caer en la cuenta de que eso es lo que sucede xDDD. ¿Entonces lo he entendido bien?.


Ya te he contado otras veces que el HDMA es independiente, va pos su cuenta, así que si leyeras ese registro con el HDMA... ¿luego qué? ¿Qué haces con el dato leído?
La idea de leer el registro $2140 es saber si el SPC-700 ha leído el byte enviado en ese registro y pasar a enviar el siguiente. Si lo haces con HDMA, primero has de esperar a que acabe la línea actual para que salte el HDMA (con el consguiente gasto inútil de tiempo) y una vez leyeras el dato y lo enviaras a RAM, ¿cómo haces para que el micro sepa si es el mismo byte que envió al principio de línea? ¿Lo mantienes parado hasta entonces? Si haces eso, entonces el HDMA no sirve de nada, porque la idea de un DMA es que el micro pueda seguir haciendo otras cosas mientras se transfiere.


Señor Ventura escribió:Pero, ¿como se explica que se puedan enviar samples todavía mas rápido?:
https://youtu.be/p_60V8UdYEY?t=13


Ya vi este video y sigo sin entender como antes a qué te refieres con "más rápido".... ¿Más rápido que qué? ¿Que el programa ése que se está ejecutando en el video? ¿Tienes el código fuente del programa?



Señor Ventura escribió:Con esto ya me tiras por la ventana.

8 frames... es que no puede ser [burla3]


Y tanto que te voy a tirar por la ventana [poraki] ¿De dónde te sacas los 8 frames?
chinitosoccer escribió:A mi me hubiese gustado un MegaCD con mas Ram, o por lo menos expandible por medio de algún cartucho, pero hace tiempo estuve leyendo y al parecer no hay forma de establecer esa "comunicacion" entre el slot de cartuchos como expansion de RAM y el MegaCD, alguna limitacion del hardware que no permite al VDP acceder a la ROM como lo hace PC Engine, NES o Neogeo, sin antes pasar por la RAM de video......o algo asi :-?


No hubiese sido posible, con ese hipotético cartucho de RAM que se pusiese en el slot de la Mega Drive, que la CPU de la misma lea los datos y los suba al cartucho de RAM?
Gammenon escribió:que la CPU de la misma lea los datos y los suba al cartucho de RAM


"Que la CPU lea los datos y los suba al cartucho de RAM" ni pajolera idea de como funciona el MegaCD no?

En modo MegaCD es el 68000 de MegaCD es el que toma control de todo el sistema, el 68000 de Megadrive no hace practicamente nada.
chinitosoccer escribió:
Gammenon escribió:que la CPU de la misma lea los datos y los suba al cartucho de RAM


"Que la CPU lea los datos y los suba al cartucho de RAM" ni pajolera idea de como funciona el MegaCD no?

En modo MegaCD es el 68000 de MegaCD es el que toma control de todo el sistema, el 68000 de Megadrive no hace practicamente nada.


El final fight de mega cd no lo mueve la MD "pelada"? La cpu de mega cd no tiene acceso a la parte de MD (ram, cartucho, vdp, etc)?
Gammenon escribió:
chinitosoccer escribió:
Gammenon escribió:que la CPU de la misma lea los datos y los suba al cartucho de RAM


"Que la CPU lea los datos y los suba al cartucho de RAM" ni pajolera idea de como funciona el MegaCD no?

En modo MegaCD es el 68000 de MegaCD es el que toma control de todo el sistema, el 68000 de Megadrive no hace practicamente nada.


El final fight de mega cd no lo mueve la MD "pelada"? La cpu de mega cd no tiene acceso a la parte de MD (ram, cartucho, vdp, etc)?


Segun tengo entendido corre enteramente sobre el Asic + 68000 de SegaCD.
chinitosoccer escribió:
Gammenon escribió:
chinitosoccer escribió:
"Que la CPU lea los datos y los suba al cartucho de RAM" ni pajolera idea de como funciona el MegaCD no?

En modo MegaCD es el 68000 de MegaCD es el que toma control de todo el sistema, el 68000 de Megadrive no hace practicamente nada.


El final fight de mega cd no lo mueve la MD "pelada"? La cpu de mega cd no tiene acceso a la parte de MD (ram, cartucho, vdp, etc)?


Segun tengo entendido corre enteramente sobre el Asic + 68000 de SegaCD.


El Asic es la GPU de MegaCD, no? Por este foro se ha dicho varias veces que el FF podría hacerse en cartucho en una MD pelada (obviando la parte musical, claro). Me extraña que el Asic tenga también problemas de parpadeo como se puede ver en el FF o el Lord of Thunder, por poner dos ejemplos.
Si, el Asic es el VDP y un procesador de sonido Ricoh para PCM todo embutido en un mismo IC.

Final Fight CD podria correr en el 68000 de Megadrive pero creo que no es el caso, para que se iban a complicar la vida utilizando el CPU mas lento? :-? , tampoco es que se usen los dos 68000 en paralelo, lo unico que agrega el uso de ambos CPUs em paralelo es en juegos donde hay que descomprimir FMV, o en juegos con scaling/zoom, como las pantallas de conduccion del Batman Returns por ejemplo.
magno escribió:
danibus escribió:MITO... busted pues


¿A qué te refieres? El "mito" como tú lo llamas es una realidad: el sonido de la SNES es mucho mejor que el del resto de máquina de su nivel y potencia; Lo que pasa es que la comunicación con él es poco flexible para toda la flexibilidad de programación que tiene la APU (por todos los microcódigos que puedes descargar y las diferentes configuraciones del DSP), pero eso no quita que se hayan hecho grandes obras musicales para la SNES.


No me he explicado bien, me refiero a la premisa del creador del hilo de que era posible, al final no lo es y de ahí el "busted", imitando a la serie de Cazadores de Mitos. No entro a valorar la música de la snes.


theelf escribió:No das ni una
Esta frase se está poniendo de moda XD
Pues claro, no tengo conocimientos técnicos del megacd, solo recuerdos. No todos somos tan cracks como tú jeje.

"Tercero, no era caro, fijate precios los lectores de CD de la epoca "
Una cosa no quita la otra. Los lectores (incluso los de PC) eran caros de cojones. Por tanto era caro, igual que el resto, el tema es que no era asequible y blablabla en realidad para el tema del hilo nos da igual.
El problema de los cd's era el tiempo de acceso, cierto, todos pecaban de lo mismo.
@danibus

Caro no, costoso que no es lo mismo. Caro es que el precio es elevado sin justificacion, costoso es cuando el precio es elevado, pero justificado

No te iban a vender una maquina con lector de CDs por dos duros, cuando costaba una pasta, el precio estaba acorde al coste de un lector de CD de la epoca de PC o de audio, incluso algo menos asi de memoria
theelf escribió:@danibus

Caro no, costoso que no es lo mismo. Caro es que el precio es elevado sin justificacion, costoso es cuando el precio es elevado, pero justificado


Mejor llamémosle "inasumible para el bolsillo de la persona media". Si no recuerdo mal era más caro que la consola en sí por aquella época.
@MasterDan

Bueno... yo vivia en argentina en ese momento, con la problematica de tener una moneda siempre devaluada, y aun asi me compre la MegaCD y un Mitsumi 1x para mi PC

Trabajaba y lo pude hacer, asi q no creo inasumible..... inasumible era si tenias 10 anios y tus padres no te la compraban
theelf escribió:Trabajaba y lo pude hacer, asi q no creo inasumible..... inasumible era si tenias 10 anios y tus padres no te la compraban


[carcajad]

Esa era la cruda realidad que nos tocaba vivir a varios; supongo que por eso algunos podían ver así el precio de la maquina, pero por lo menos los juegos tenían un precio asumíble.
@theelf En aquel momento la peseta española tampoco es que tuviera mucho valor y yo al menos tenía unos 12-13 años por lo que dependía de la generosidad de mis padres (por otra banda no tenía una Mega y sólo tenía la NES por lo que tampoco pensé en comprarme un MegaCD).

Aun así recuerdo que las propias revistas lo consideraban caro, y era un precio que muchas familias no se podían permitir (y menos para una "maquinita" para el crio). Supongo que si uno era soltero, trabajaba y no tenía muchos gastos no tendría problemas en adquirirlo: yo por ejemplo estas navidades me pillé una Play 4 con varios juegos, un desembolso que me ha picado bastante en el bolsillo, pero que me podía permitir tranquilamente. Si hubiera estado en la situación de mis padres en aquella época dudo que me hubiera gastado tanto dinero.
theelf escribió:@MasterDan

Bueno... yo vivia en argentina en ese momento, con la problematica de tener una moneda siempre devaluada, y aun asi me compre la MegaCD y un Mitsumi 1x para mi PC

Trabajaba y lo pude hacer, asi q no creo inasumible..... inasumible era si tenias 10 anios y tus padres no te la compraban



Exacto, si tenias 9-10 años en esa epoca, no podias ni siquiera pagar un Famiclon, pero todos los que teniamos entre 14-16 ya nos las arreglábamos para tener todos esos objetos de deseo de una forma u otra por mas que las leyes laborales lo quisieran de otro modo, yo trabajo prácticamente desde que salí del primario, tenia novia con tarjeta de credito y pariente en Estados Unidos XD , ademas si tenias una edad por debajo de esa franja tampoco te encontrabas en condiciones de disfrutar debidamente del mundillo.
chinitosoccer escribió:ademas si tenias una edad por debajo de esa franja tampoco te encontrabas en condiciones de disfrutar debidamente del mundillo.


Imagen
magno escribió:No son el mismo juego realmente... Si no recuerdo mal, en la presentación de personajes antes de un combate del SFII la música no cambia, es la principal, pero con unos acordes que terminan en fade-out. En el SFA2 creo recordar que la música sí es diferente, por lo que en algún momento hay que cargar las voces de presentación y la música del escenario.
Lo digo de memoria, igual sí se hubiera podido hacer mejor, no sé.


La cuestión es que en todos los street fighters de snes la música se corta entre round y round, pero en los primeros no requiere pararse alrededor de 3 o 4 segundos.

Según lo que has explicado mas abajo, pinta entonces a un driver de sonido poco optimizado, y por añadidura, a tener que volver a transferir los samples cuando ya estaban en la ram del spc700.


magno escribió:
Señor Ventura escribió:Tiene que haber alguna salida, porque claramente el streaming de audio (en el vídeo dice que son 4MB en un minuto, pero en realidad son 8), está transifiriendo a una tasa de datos 16 veces superior a la que en teoría estoy viendo que en realidad parece que hace (en condiciones normales).


¿Y cómo sabes eso? ¿Cómo has calculado esas tasas?


En realidad son 7680KB.

32Khz a 16 bits durante 1 minuto, sale eso, casi 8MB, no los 4 que dice el comentario del vídeo.


magno escribió:El bucle de trasnferencia que te linké dura 26 ciclos por cada byte transferido a $2140 y faltaría saber cuándo el SPC-700 ha leído dicho dato. Si te haces un driver bueno, podrías escribir desde la CPU $2140, luego $2141, luego $2142 y por último $2143 de forma consecutiva y que el programa que corre en el SPC-700 los vaya enviando a su ARAM de forma secuencial. Así reduces la espera a 1 vez cada 4 bytes que escribes.
Luego, esta transferencia se hace en cualquier instante, no hace falta esperar a NMIs ni nada, así que:

1 frame = 262 scanlines activas * 1362 master clocks por línea = 357368 master clocks

La CPU ejecuta cada instrucción en 6 master clocks * 26 ciclos que dura el bucle = 156 master clocks por cada byte enviado al SPC-700

Por tanto, ejecutas 2290 veces el bucle de audio en un frame si el tiempo de respuesta del SPC-700 es de 1 ciclo; si fuera de 4 (es el máximo porque funciona a 1MHz y el de SNES a 3.58MHz), tendrías lo ejecutarías 572 veces (572 bytes transferidos) en un frame EN EL PEOR CASO.

Pensando que solo transfieres samples con BBR (que comprime en un ratio 32:9), habrías enviado 1018 muestras de audio de 16 bits en un solo frame. En 1 segundo (60 frames) enviarías unos 61000 muestras de 16 bits EN EL PEOR CASO, 244000 EN EL MEJOR CASO.

¿En serio te parece poco 60Kmuestras por segundo para un sistema de audio que trabaja a 32kHz? Es prácticamente el doble de la tasa de muestreo en el peor de los casos. Y como normalmente las muestras de toda la música la envías del tirón antes de empezar una fase o una escena, podrías enviar una canción de 10 segundos de duración en 2~4 segundos sin problemas. Y todo esto, sabiendo que como mucho tienes 64KBytes para almacenar muestras en la RAM de la APU, pues fijate que todo el sistema está más o menos bien escalado: llenarías la ARAM en un cuarto de segundo (250 mseg) enviando muestras en el peor de los casos.

Un driver bien programado podría tener una rutina que agilizara al máximo la recepción de samples en el SPC-700 y a la que se llamara desde el micro principal cuando se necesitara enviar samples.


Joder, que grande eres... ya hasta parce sencillo cuando lo explicas tu [+risas]

Entonces la transferencia es *virtualmente* simultánea al DMA, me parece una pasada [Alaa!]

magno escribió:Ya te he contado otras veces que el HDMA es independiente, va pos su cuenta, así que si leyeras ese registro con el HDMA... ¿luego qué? ¿Qué haces con el dato leído?
La idea de leer el registro $2140 es saber si el SPC-700 ha leído el byte enviado en ese registro y pasar a enviar el siguiente. Si lo haces con HDMA, primero has de esperar a que acabe la línea actual para que salte el HDMA (con el consguiente gasto inútil de tiempo) y una vez leyeras el dato y lo enviaras a RAM, ¿cómo haces para que el micro sepa si es el mismo byte que envió al principio de línea? ¿Lo mantienes parado hasta entonces? Si haces eso, entonces el HDMA no sirve de nada, porque la idea de un DMA es que el micro pueda seguir haciendo otras cosas mientras se transfiere.


Ostras, pues es verdad...

Lo que interpreté de ese texto es que la idea es aprovechar el margen de tiempo entre scanline y scanline para que la cpu lea esos registros, pero no lo había visto como un gasto inutil de tiempo por esperar hasta ese momento, sino como un momento del frame en el que puedes permitirte que la cpu se centre en eso.
Sin embargo, si no lo entiendo mal no puedes hacer que la cpu lo lea en el momento, sino que debes acceder a la ram posteriormente para leerlo, por lo que te da igual una cosa que la otra... o mejor dicho, no, porque pierdes canales HDMA que puedes necesitar para otras tareas.

magno escribió:
Señor Ventura escribió:Pero, ¿como se explica que se puedan enviar samples todavía mas rápido?:
https://youtu.be/p_60V8UdYEY?t=13


Ya vi este video y sigo sin entender como antes a qué te refieres con "más rápido".... ¿Más rápido que qué? ¿Que el programa ése que se está ejecutando en el video? ¿Tienes el código fuente del programa?


Perdón, no decía mas rápido, sino samples a mayor tasa, pero ya me ha quedado claro ^^u

(gracias!!)

magno escribió:
Señor Ventura escribió:Con esto ya me tiras por la ventana.

8 frames... es que no puede ser [burla3]


Y tanto que te voy a tirar por la ventana [poraki] ¿De dónde te sacas los 8 frames?


Que no, que no te lo digo [qmparto]

danibus escribió:No me he explicado bien, me refiero a la premisa del creador del hilo de que era posible, al final no lo es y de ahí el "busted", imitando a la serie de Cazadores de Mitos. No entro a valorar la música de la snes.


Lo que ha dicho es que no se hace por DMA, pero si es posible. De hecho... ¿no has visto el vídeo?.
Señor Ventura escribió:
magno escribió:No son el mismo juego realmente... Si no recuerdo mal, en la presentación de personajes antes de un combate del SFII la música no cambia, es la principal, pero con unos acordes que terminan en fade-out. En el SFA2 creo recordar que la música sí es diferente, por lo que en algún momento hay que cargar las voces de presentación y la música del escenario.
Lo digo de memoria, igual sí se hubiera podido hacer mejor, no sé.


La cuestión es que en todos los street fighters de snes la música se corta entre round y round, pero en los primeros no requiere pararse alrededor de 3 o 4 segundos.

Según lo que has explicado mas abajo, pinta entonces a un driver de sonido poco optimizado, y por añadidura, a tener que volver a transferir los samples cuando ya estaban en la ram del spc700.


magno escribió:
Señor Ventura escribió:Tiene que haber alguna salida, porque claramente el streaming de audio (en el vídeo dice que son 4MB en un minuto, pero en realidad son 8), está transifiriendo a una tasa de datos 16 veces superior a la que en teoría estoy viendo que en realidad parece que hace (en condiciones normales).


¿Y cómo sabes eso? ¿Cómo has calculado esas tasas?


En realidad son 7680KB.

32Khz a 16 bits durante 1 minuto, sale eso, casi 8MB, no los 4 que dice el comentario del vídeo.


magno escribió:El bucle de trasnferencia que te linké dura 26 ciclos por cada byte transferido a $2140 y faltaría saber cuándo el SPC-700 ha leído dicho dato. Si te haces un driver bueno, podrías escribir desde la CPU $2140, luego $2141, luego $2142 y por último $2143 de forma consecutiva y que el programa que corre en el SPC-700 los vaya enviando a su ARAM de forma secuencial. Así reduces la espera a 1 vez cada 4 bytes que escribes.
Luego, esta transferencia se hace en cualquier instante, no hace falta esperar a NMIs ni nada, así que:

1 frame = 262 scanlines activas * 1362 master clocks por línea = 357368 master clocks

La CPU ejecuta cada instrucción en 6 master clocks * 26 ciclos que dura el bucle = 156 master clocks por cada byte enviado al SPC-700

Por tanto, ejecutas 2290 veces el bucle de audio en un frame si el tiempo de respuesta del SPC-700 es de 1 ciclo; si fuera de 4 (es el máximo porque funciona a 1MHz y el de SNES a 3.58MHz), tendrías lo ejecutarías 572 veces (572 bytes transferidos) en un frame EN EL PEOR CASO.

Pensando que solo transfieres samples con BBR (que comprime en un ratio 32:9), habrías enviado 1018 muestras de audio de 16 bits en un solo frame. En 1 segundo (60 frames) enviarías unos 61000 muestras de 16 bits EN EL PEOR CASO, 244000 EN EL MEJOR CASO.

¿En serio te parece poco 60Kmuestras por segundo para un sistema de audio que trabaja a 32kHz? Es prácticamente el doble de la tasa de muestreo en el peor de los casos. Y como normalmente las muestras de toda la música la envías del tirón antes de empezar una fase o una escena, podrías enviar una canción de 10 segundos de duración en 2~4 segundos sin problemas. Y todo esto, sabiendo que como mucho tienes 64KBytes para almacenar muestras en la RAM de la APU, pues fijate que todo el sistema está más o menos bien escalado: llenarías la ARAM en un cuarto de segundo (250 mseg) enviando muestras en el peor de los casos.

Un driver bien programado podría tener una rutina que agilizara al máximo la recepción de samples en el SPC-700 y a la que se llamara desde el micro principal cuando se necesitara enviar samples.


Joder, que grande eres... ya hasta parce sencillo cuando lo explicas tu [+risas]

Entonces la transferencia es *virtualmente* simultánea al DMA, me parece una pasada [Alaa!]

magno escribió:Ya te he contado otras veces que el HDMA es independiente, va pos su cuenta, así que si leyeras ese registro con el HDMA... ¿luego qué? ¿Qué haces con el dato leído?
La idea de leer el registro $2140 es saber si el SPC-700 ha leído el byte enviado en ese registro y pasar a enviar el siguiente. Si lo haces con HDMA, primero has de esperar a que acabe la línea actual para que salte el HDMA (con el consguiente gasto inútil de tiempo) y una vez leyeras el dato y lo enviaras a RAM, ¿cómo haces para que el micro sepa si es el mismo byte que envió al principio de línea? ¿Lo mantienes parado hasta entonces? Si haces eso, entonces el HDMA no sirve de nada, porque la idea de un DMA es que el micro pueda seguir haciendo otras cosas mientras se transfiere.


Ostras, pues es verdad...

Lo que interpreté de ese texto es que la idea es aprovechar el margen de tiempo entre scanline y scanline para que la cpu lea esos registros, pero no lo había visto como un gasto inutil de tiempo por esperar hasta ese momento, sino como un momento del frame en el que puedes permitirte que la cpu se centre en eso.
Sin embargo, si no lo entiendo mal no puedes hacer que la cpu lo lea en el momento, sino que debes acceder a la ram posteriormente para leerlo, por lo que te da igual una cosa que la otra... o mejor dicho, no, porque pierdes canales HDMA que puedes necesitar para otras tareas.

magno escribió:
Señor Ventura escribió:Pero, ¿como se explica que se puedan enviar samples todavía mas rápido?:
https://youtu.be/p_60V8UdYEY?t=13


Ya vi este video y sigo sin entender como antes a qué te refieres con "más rápido".... ¿Más rápido que qué? ¿Que el programa ése que se está ejecutando en el video? ¿Tienes el código fuente del programa?


Perdón, no decía mas rápido, sino samples a mayor tasa, pero ya me ha quedado claro ^^u

(gracias!!)

magno escribió:
Señor Ventura escribió:Con esto ya me tiras por la ventana.

8 frames... es que no puede ser [burla3]


Y tanto que te voy a tirar por la ventana [poraki] ¿De dónde te sacas los 8 frames?


Que no, que no te lo digo [qmparto]

danibus escribió:No me he explicado bien, me refiero a la premisa del creador del hilo de que era posible, al final no lo es y de ahí el "busted", imitando a la serie de Cazadores de Mitos. No entro a valorar la música de la snes.


Lo que ha dicho es que no se hace por DMA, pero si es posible. De hecho... ¿no has visto el vídeo?.


Si se puede, se puede y punto, sea por DMA o no.
Solo un matiz, y es que el ejemplo del vídeo no puede llegar a pesar 7680KB porque aunque sea un mínimo siempre comprime algo... así que si ocupa 4MB, es porque le han metido una buena compresión.

Vamos, que sobra ancho de banda.
Driver de sonido en SNES????......pero de que mierda........ :-? ???
chinitosoccer escribió:Driver de sonido en SNES????......pero de que mierda........ :-? ???


No parece ser un driver en si mismo, hasta el punto de que puedas cambiar la forma en que funciona todo, sino mas bien unas instrucciones mas ordenadas para transferir con un 75% menos de interrupciones, de formas que al final puedes obtener un ancho de banda realmente grande para reproducir canciones a 32Khz y 16 bits, y aún sobra para bastante mas, lo cual está muy bien.

Estamos hablando de un ancho de banda total de 8KB por frame [boma]

(En realidad entre 7,95 y 7,96KB... 0,74KB por frame mas que megadrive... dios, tenía que decirlo xDD).
chinitosoccer escribió:Driver de sonido en SNES????......pero de que mierda........ :-? ???


¿De qué te sorprendes? Un driver es cualquier rutina que te permite el acceso a bajo nivel a un dispositivo hardware para realizar funciones repetitivas que se pueden llamar más cómodamente desde el alto nivel.
En el caso de la SNES, el driver se comunica con el código que se ejecuta en el SPC-700 y que es programable también, por lo que realmente el driver lo componen dos partes.


Señor Ventura escribió:
chinitosoccer escribió:Estamos hablando de un ancho de banda total de 8KB por frame [boma]

(En realidad entre 7,95 y 7,96KB... 0,74KB por frame mas que megadrive... dios, tenía que decirlo xDD).


Ummm... te has ido al mejor caso de los cálculos que hice... yo no apostaría porque fueran tantos bytes por segundo... A ver si encontramos el código fuente de la ROM que se ejecuta en el video o bien desensamblamos la ROM y comprobamos la tasa de muestras por segundo,
@magno Ya nos podemos imaginar el pifostio que debe haber ahi, viendo el rendimiento que tiene a ese muestreo tan bajo.

Sobre el driver, he contado con que si un ciclo (esos 2290 bucles que trabaja el spc700), consiguen por depuración no fallar ninguna de las veces, bastaría con automatizarlo a cada frame.

Guardas en ram la rutina, accedes a ella al principio de cada frame, y pocos ciclos deberian perderse (en teoría), a coste de tampoco mucha cpu dando prioridad a la transferencia de sonido.
No consiste en "fallar", consiste en que el reloj del SPC-700 es de 1,024 MHz que es aproximadamente 3,85 veces (3,85MHz) más lento que el de SNES; tendría que mirar si el acceso a los registros del bus B siempre se hace en modo Slow, lo cual implicaría que el micro de la SNES va 2,68 veces (2,68 MHz) más rápido que el del SPC-700, por lo que se tardarían, haciendo un promedio, unos 2 ciclos de reloj de SNES en que el SPC-700 capturara el byte... considerando que lo hace en 1 ciclo, lo cual es áltamente improbable.
Para eso lo mejor es mirar el código.


EDITO:

Aquí está el código, aunque no completo, de lo que implementó blargg para esa demo de música clásica; si lees lo que comentan, parece que llega a 128KB/seg de muestras sin comprimir BRR, lo cual se parece mucho a los cálculos que te hice si la APU validara los datos en cada ciclo (en mis cálculos salían 2290 bytes/frame * 60 fps = 134KB/seg).
Pero ya te he comentado que es imposible que el SPC-700 los valide en 1 ciclo por culpa de su frecuencia de reloj; lo que hace blargg es cargar el SPC-700 para que valide todos los datos de golpe y así hacer menos ciclos de espera en la SNES. La contrapartida es que no puedes poner efectos en el SPC-700 porque va a tope, incluso su buffer de eco no se actualiza, mientras que la SNES está también apurada casi al 100% enviando los frames de audio.

Otra aproximación al problema es usar el HDMA enviando 4 bytes en cada HBlank, y considerar que el SPC-700 los va a leer sí o sí en el tiempo de 1 scanline. Esto permitiría 224 scanlines * 4 bytes = 896 bytes/frame * 60 fps = 53760 bytes/seg, sin usar apenas la S-CPU a costa de tener menos tasa por segundo y el HDMA parcialmente ocupado (si no se usa para otra cosa, no habría problemas). Lo que pasa es que esto no parece que se haya probado en hardware.
alucino en colores con el conocimiento que teneis sobre el hardware de SNES (pura ingenieria), os envidio sanamente...

@magno aprovecho la ocasión y te doy las gracias por TODOS tus grandes aportes a la comunidad
sois unos cracks! [beer]
54 respuestas
Archivado
1, 2
Volver a Consolas clásicas