Ver la versión completa : Proyecto Mezclador de audio PCM para Atari STE - Completado
masteries
09/05/2020, 19:50
Hacía mucho que no lograba encontrar tiempo para el STE,
Pero por fin aquí está el mezclador de sonido PCM definitivo para usar en juegos;
he tenido que reescribirlo todo en ensamblador y ha sido bastante horroroso.
Lo bueno es que ahora funciona mucho mejor, empalma los frames de audio sin que se note nada raro.
Admite hasta 3 voces (3 sonidos simultáneos) y los sonidos se pueden reproducir en bucle.
Mezcla a 12,5 KHz y consume el 6,5 % de la CPU disponible en cada fotograma, por lo que te queda mucha CPU para usar en tus juegos.
Más rápido y efectivo que la anterior versión en C.
Adjunto ejecutable .tos a modo de demo y código fuente.
53619
Editado: Adjunto juego de prueba con audio.
(Funciona bien, pero hay un conflicto entre el Timer A y el D que provoca un fallo en el overscan cada 4 - 5 segundos, YA ESTÁ ARREGLADO; pero podéis probarlo para escuchar el audio del STE en toda su gloria)
Las teclas son A,W,S,D y shift para disparar.
53637
Editado: El problema con el overscan ya ha sido arreglado.
Oju cuanto código. Según contaron los de ULM es mas rápido usar samples ADPCM ya que lees menos memoria y encima te ocupan menos, lo dejo como ejercicio XDXDXD
-----Actualizado-----
Lo usaron es esta demo, es en un ST normal.
https://www.youtube.com/watch?v=nqHK4IQhtVo
masteries
09/05/2020, 23:40
Oju cuanto código. Según contaron los de ULM es mas rápido usar samples ADPCM ya que lees menos memoria y encima te ocupan menos, lo dejo como ejercicio XDXDXD
-----Actualizado-----
Lo usaron es esta demo, es en un ST normal.
Para usar el YM2149 está bastante bien; el mezclador que he adjuntado sólo utiliza el canal DMA disponible sólo en los STE. Usar ADPCM te implica que ahorras espacio, cierto, pero has de demultiplexar y aplicar el filtro inverso para pasar de la componente frecuencial al valor en el tiempo... no sería muy viable para juegos. A menos que la componente frecuencial la puedas usar directamente en las 3 voces de onda cuadrada del YM2149, por lo que de ser así, es mucho más interesante para guardar y reproducir música con mayor fidelidad en el YM2149
Y el mezclador PCM DMA para los efectos de sonido,
Hay que estudiar esto del ADPCM aplicado al YM2149, porque ahora lo que ha quedado pendiente es la reproducción, y por qué no, conversión de músicas mod a algún formato que podamos reproducir en el YM2149, y que dé resultados muy buenos.
¿Hay más información respecto a cómo manejan el YM2149 en estas demos?
No, el ADPCM es mucho mas sencillo, mira este post.
http://www.atari-forum.com/viewtopic.php?f=1&t=4357&p=32070&#p32070
Para tocar samples en el YM2149 coges el valor del sample [0..255] miras en una tabla y escribes los valores correspondiente en los registros de volumen. Lo malo es que chupa bastante CPU
masteries
10/05/2020, 12:32
No, el ADPCM es mucho mas sencillo, mira este post.
http://www.atari-forum.com/viewtopic.php?f=1&t=4357&p=32070&#p32070
Para tocar samples en el YM2149 coges el valor del sample [0..255] miras en una tabla y escribes los valores correspondiente en los registros de volumen. Lo malo es que chupa bastante CPU
Hmmm... con esas premisas, casi sale más a cuenta consumir otro 2% de CPU y añadirle una voz más al mezclador; para utilizarla con la música. Y probar que tal suena esta voz de música a 6,25 KHz o incluso a 3,125 KHz (para que la música ocupe menos); total si 3000 muestras es lo máximo que he leído que le hayan "metido" al YM2149, y aún a ese muestreo tan bajo sonará mejor en un DAC de verdad que imitando un DAC en el YM.
También si usas una voz de 8 bits de verdad, en verdad 7 bits porque tienes que bajar el volumen para que no sature al mezclar con las otras, puedes convertir cualquier melodía (.mod o lo que sea) independientemente de las voces instrumentales que tenga originalmente.
Por supuesto, interpolaría con un primer orden las 2 muestras que te quedan cojas, para que suene un poquito más suave.
Todo esto a nivel de CPU no consume mucho, otro 2% de cada frame.
masteries
12/05/2020, 11:44
swapd0
fbustamante
En el primer mensaje he añadido un juego de prueba que hace uso del mezclador.
Podéis probarlo en emulador o en STE real.
Va muy bien.
Si quitas el overscan te olvidas de problemas con los timers, ¿no? Por cierto, el juego con 1MB no funciona, con 4MB si, pero deberías poner algo.
masteries
13/05/2020, 02:47
Con 2 MB también funciona, básicamente es lo que tiene usar el dualfield, mayor colorido, pero gráficos ocupando el doble; junto a un escenario de Metal Slug siendo NeoGeo una máquina que reutilizaba pocos tiles... pues tienes que todo ocupa 1.33 MB
La verdad es que 1 MB se te queda corto muy pronto, en cuanto te pongas a hacer un juego en serio.
Sobre todo si usas un decorado de NeoGeo, al principio pone que son 2500 tiles aproximadamente, cuando en muchos juegos de los 16bits los tiles te ocupaban en una pantalla (320x200) y te sobraba espacio.
masteries
14/05/2020, 18:20
Va muy bien.
Si quitas el overscan te olvidas de problemas con los timers,
@fbustamante (https://www.gp32spain.com/foros/member.php?u=41268)
¿Por qué te ibas a conformar con 320 x 200 cuando puedes tener 320 x 240 píxels? :awesome:
Ya está solucionado, ha sido sencillo, pero rarito; se ha añadido una variable que se pone a 1 cuando se ejecuta la interrupción del blanking vertical en la primera línea de la pantalla;
cuando llega a la última línea, esta interrupción se vuelve a ejecutar y la variable se pone a 0. Obviamente esta interrupción ya forma parte de las librerías gráficas de las AGT
Ha sido un añadido minúsculo.
Ahora cuando se ejecuta la interrupción del mezclador de audio, se comprueba el valor de esta variable; si es 1 es que estamos cerca de la interrupción de la línea 1 y si es cero estamos demasiado cerca de la interrupción de la última línea.
En la interrupción del mezclador se añade un sample adicional al DMA si el valor es 1, y no se añade nada si es 0; así mantienes la ejecución del mezclador en un intervalo de tiempo seguro donde no se van a perturbar varias interrupciones.
He añadido la correción al defectillo en el primer post,
fbustamante
15/05/2020, 08:53
Yo sigo el hilo. No me entero de ná, pero lo sigo.
El mundo del amiga y los st siempre me ha atraído.
Muchas gracias.
Ok, entonces el problema es que el mezclador hacia que la interrupción se ejecutase un poco mas tarde y por eso se "quitaba" el overscan, ya que hay que hacer los cambios de hercios en una posiciones concretas para liar al shifter, ¿no?
masteries
16/05/2020, 21:44
Ok, entonces el problema es que el mezclador hacia que la interrupción se ejecutase un poco mas tarde y por eso se "quitaba" el overscan, ya que hay que hacer los cambios de hercios en una posiciones concretas para liar al shifter, ¿no?
Eso si es correcto; el proceso de dibujar más resolución es distinto para STE y para ST (sí, el ST también está soportado, aunque los sprites van todos por software y eso lastra, pero el scroll es "hardware" de la manera que te cuento a continuación)
En un ST: Tienes dos bufferes de 32 KB, consiste en cambiar la dirección a donde apunta el puntero de inicio del cuadro; es la misma técnica que están usando para hacer scroll en el Spectrum, pero en una máquina mejor. En este caso se utiliza para disponer de mayor resolución y hacer scroll al mismo tiempo. Para este ordenador la IRQ del overscan permite sacar más información de imagen para el conversor de vídeo (Shifter), alternar entre una u otra paleta de las dos que existen de 16 colores, con las que se componen más colores por superposición y hacer scroll al pixel, la rutina es algo más larga que la versión para STE.
En un STE: Al blitter le da tanto lo mismo porque no está limitado a esos dos búferes de 32 KB. El hardware del scroll puede desplazar áreas mayores y no limitadas a esos búferes, por lo que el scroll es más sencillo. Para este ordenador la IRQ del overscan permite sacar más información de imagen para el conversor de vídeo y alternar entre una u otra paleta de las dos que existen de 16 colores, con las que se componen más colores por superposición.
Técnica de la superposición de colores: A la izquierda la imagen con la técnica del dualfield en un ST/STE. A la derecha esa misma imagen con sólo 16 colores, podrías usar un dithering mejor, pero no alcanzarías la calidad del lado derecho. Por cierto, si ves cada imagen del dualfield por separado, se ven muy raras porque se componen con un dithering muy especial, que conlleva muchos cálculos para hacer que la imagen resultante de unir las dos se vea así, es un proceso iterativo a 4 hilos de ejecución que tarda un rato muy largo en dar su resultado.
107 colores vs 16
5364253643
122 vs 16
5364453645
masteries
17/05/2020, 17:39
Actualización gorda:
Dándole vueltas a como mezclar más y mejor, como disponer de más canales de sonido...
Me he decidido a pensar en el procesador del Atari ST/E como realmente lo vendían, como un micro de 32 bits, y sin pensar en si el bus es de 16 bits...
total que he probado una versión del mezclador pensando en un sistema de 32 bits. Sin miramientos...
¡Ahora el mezclador puede mezclar 6 canales de sonido al precio que antes costaban 3! Con 6 canales ya no tienes límite en lo que a audio se refiere, al menos para juegos 2D.
Si las muestras están capadas para que no haya overflow en un byte puedes hacer sumas de 32bits sin problemas y estarías tratando 4 muestras de cada sample a la vez.
masteries
18/05/2020, 14:30
Si las muestras están capadas para que no haya overflow en un byte puedes hacer sumas de 32bits sin problemas y estarías tratando 4 muestras de cada sample a la vez.
hehehe
Muy listo el señor,
Así es como está hecho, pero aunque no haya overflow, se produce en algunas ocasiones una propagación de un bit al byte adyacente; por lo que se te introduce una muy ligera variación, casi no se nota; y como ganas tanto en eficiencia computacional, pues tienes que aceptarlo.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.