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

Viendo vuestro conocimiento (sobretodo el de @magno ) lo que yo me pregunto es cuando dejareis de teorizar sobre el tema y pasareis a la práctica. Que el homebrew de la super es casi inexistente y necesita hamor .

MasterDan escribió:Viendo vuestro conocimiento (sobretodo el de @magno ) lo que yo me pregunto es cuando dejareis de teorizar sobre el tema y pasareis a la práctica. Que el homebrew de la super es casi inexistente y necesita hamor .

Algún día, hamijo
Yo apenas tengo tiempo libre en mi vida real y el que tengo lo dedico a alguno de los otros proyectos prioritarios en estos momentos... Star Ocean, Gokuuden 1 y 2 y otros proyectos de electrónica.
Además, no es fácil hacer ciertas demos, necesitas gráficos, samples o cosas por el estilo para llevarlos a la práctica y eso es bastante costoso.

@magno Bueno, me tendré que conformar y esperar a la (supongo) traducción del Star Ocean (los Gokuden no se lo merecen ). Yo por mi parte debería predicar con el ejemplo y ponerme con la programación de NES.

magno escribió: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.

Tiene sentido, y es que debe hacerse al margen del DMA, cosa que deja ocupada inevitablemente a la cpu. Anda que no es una lástima, ni nada

magno escribió: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.

Mas que no haberse probado en hardware, lo que he detectado es que muchos juegos hacen pirulas con el scroll si desactivas la emulación del hdma, así que habría que tener cuidado ahí.

¿Como va el uso del hdma a través de varios canales?, ¿se puede hacer de forma simultánea? (enviar samples de sonido por un lado, mientras que por otro actualizas la posición de un plano).

De todos modos 896 bytes por frame me parece muy aceptable. Son 53,7KB por segundo, y tal vez puedas conseguir arañar algo mas si transfieres mas samples dejando la cpu parada solo la mitad del tiempo, así podría usarse con algún tipo de juego que no requiera tanta cpu, y con la ventaja de una gran capacidad para el sonido.

Siempre hay géneros que admiten mas margen en este sentido.

Señor Ventura escribió:Mas que no haberse probado en hardware, lo que he detectado es que muchos juegos hacen pirulas con el scroll si desactivas la emulación del hdma, así que habría que tener cuidado ahí.

Me refería a probarlo en una demo para sacar todo el potencial a esta técnica sin tener en cuenta otros canales.
Si se usara en algún juego, no tendrías que desactivar ningún canal HDMA, simplemente tener cuidado de que en cada línea el HDMA se ejecute dentro del HBlank y no lo estés sobrecargando tanto que se salga de él.

Señor Ventura escribió:¿Como va el uso del hdma a través de varios canales?, ¿se puede hacer de forma simultánea? (enviar samples de sonido por un lado, mientras que por otro actualizas la posición de un plano).

No, de forma simultánea no, ya que tanto el DMA como el HDMA mantienen a la CPU principal parada mientras se ejecuta para evitar colisiones de bus y por tanto, la necesidad de un controlador de memoria.
Puedes programar varios canales HDMA antes de que empiece un frame, y luego, al empezar cada scanline se ejecutan los canales HDMA habilitados para esa línea. Por ejemplo, podrías estar escribiendo a los registros de la CGRAM con el HDMA[0] en las líneas 180-224 para darle color a una caja de diálogo en un juego de RPG, escribiendo en todas las líneas en los registros de scroll con el HDMA[1] y usar el HDMA[2] para enviar samples de audio en las líneas que sean necesarias para cumplir el ancho de banda que necesites, por ejemplo en las líneas 112 a 179.
Así, cuando arranca un nuevo frame y empieza el scanline 0, se ejecutaría sólo el HDMA[1], en la línea 1 lo mismo y así hasta la línea 112, en la que se ejecutaría primero el HDMA[1] y luego el HDMA[2] para enviar el audio. Aquí es donde tendrías que tener cuidado de no exceder el HBlank, ya que estarías escribiendo 16 bits de color en CGRAM con el HDMA[1] y entre 1 y 4 bytes de audio con el HDMA[2].