Programando en C para Atari ST / STE

[crashman]

Último mensaje de la página anterior:

No tengo ni idea de programar en C, bueno, ahora que lo digo... ni en C ni en nada... mis conocimientos de programación se fueron quedando en el camino de la vejez...
Pero lo que si me queda es conocimiento para agradecerte el trabajo que estás haciendo.
Muchas gràcias de parte de todos los Atarianos.

[masteries]

Novedades de hoy:

-Adaptando el entorno de programación para que también funcione en Windows XP; funcionará desde Win XP hasta Win 10. El instalador que estoy preparando hará todas las partes complicadillas de la instalación por tí, para que sea sólo ejecutar el instalador y listo, a programar en C para tu Atari ST / STE

-El mezclador de sonido PCM soporta 3 voces a 12,5 KHz; lo he programado de tal forma que el código se ahorra 3000+ operaciones de comparación por cada frame de audio mezclado; ahora tengo que convertirlo de un código prototipo a algo serio e integrarlo en AGT

-Estoy trabajando con Douglas Little para que se pueda entender bien el concepto de dibujado entrelazado que ha utilizado para duplicar el número de colores, y que se puedan hacer mapeados de niveles en tus juegos sin necesidad de dedicarle media vida

-Ahora AGT dibuja a 50 Hz (como antes) pero internamente el juego puede ir a 50 Hz o a 25 Hz; así puedes hacer juegos más complejos sin que lastre la tasa de cuadros por segundo. Dependiendo del juego que estés haciendo puede no se necesario actualizar los sprites a 50 Hz, quizá el mapeado si te haga falta, pero un personaje puede bastarle con mucho menos. Ahora esto ya no es estricto

[masteries]

Novedades de hoy:

-Ya tengo el mezclador de audio marchando, he tardado más de lo que había considerado porque he tenido que reprogramar una rutina de atención a interrupciones, y lo he tenido que hacer en ensamblador... sí ohh yeah!! y de ensamblador para 68000 yo estaba muy verde, ahora ya he adquirido otro color respecto a este tema del 68k

-Por otra parte, el pobre 68000 se las ve y se las desea para mantener el tipo a 12,5 KHz con 3 voces, voy a tener que bajar a 6,25 KHz para que sea factible utilizar sonidos .wav en un videojuego.

-En cuanto lo tenga más depurado, lo integramos en las Atari Game Tools

[Estrayk]

-Por otra parte, el pobre 68000 se las ve y se las desea para mantener el tipo a 12,5 KHz con 3 voces, voy a tener que bajar a 6,25 KHz para que sea factible utilizar sonidos .wav en un videojuego.

con 6Khz - 8Khz , vamos sobrados. Para explosiones, saltos, lasers y demás efectos FX sobra. créeme. ¿Pero hablamos del DAC PCM del STe o con el Yamaha 2149F del STfm?

[masteries]

-Por otra parte, el pobre 68000 se las ve y se las desea para mantener el tipo a 12,5 KHz con 3 voces, voy a tener que bajar a 6,25 KHz para que sea factible utilizar sonidos .wav en un videojuego.

con 6Khz - 8Khz , vamos sobrados. Para explosiones, saltos, lasers y demás efectos FX sobra. créeme. ¿Pero hablamos del DAC PCM del STe o con el Yamaha 2149F del STfm?

Estamos hablando del DAC PCM de STe, una vez hecha 1/50 de mezcla de los .wav, se envía a través del canal DMA

El Yamaha sigue quedando libre, para usarlo para música o lo que sea,

[explorer]

Pero, ¿cómo es posible? Mi player de mod era capaz de componer música en estéreo a 50 Khz, más un scrolltext y un par de vúmetros en tiempo real. Y a los samples se les aplicaba vibrato, cambio de volumen, fade-in, fade-out, etc.

¿Cómo es posible que te obligue a bajar a 6.25 Khz? ¿Es muy compleja la transformación desde un wav?

[masteries]

Pero, ¿cómo es posible? Mi player de mod era capaz de componer música en estéreo a 50 Khz, más un scrolltext y un par de vúmetros en tiempo real. Y a los samples se les aplicaba vibrato, cambio de volumen, fade-in, fade-out, etc.

¿Cómo es posible que te obligue a bajar a 6.25 Khz? ¿Es muy compleja la transformación desde un wav?

Muy compleja no es, se trata de sumar los valores uno a uno; y por lo que he visto una vez compilado, la CPU accede a la primera posición del array, la copia en un registro, accede a la segunda e igual, los mismo con la tercera voz... a continuación suma el resultado de las dos primeras voces, lo lleva a un registro, suma el tercero lo lleva a otro registro y de ahí lo lleva a la posición del array "mezclado".

Cada paso como el párrafo anterior está contenido en un bucle "for", podría sacarlo del bucle, para eliminar las instrucciones de comparación del "for"; porque consumir unos KB más de código en lugar de utilizar un "for" va a ser más beneficioso; pero si lo piensas son bastantes instrucciones.

Por eso me llama la atención lo del reproductor mod; ¿reproduce sólo .mod? ¿O también juega con samples .wav? ¿La salida es a través del chip Yamaha o del PCM del STe? ¿Está el reproductor mod y su código accesibles? Hay que darle duro a esto...

[explorer]

He publicado el código en mi github: https://github.com/joaquinferrero/explo ... explorer.s

No es una versión que se pueda ensamblar, es la versión de desarrollo para Falcon, y está en pañales. Pero es la única que tengo a mano. Está codificada en el código de letras original del ST (parecido al CP437).

La idea es la siguiente: si estamos reproduciendo a 50 Khz, y tenemos un búfer para 1000 muestras, necesitamos rellenar ese búfer 50 veces por segundo. O si tenemos espacio para 2000 muestras, 25 veces por segundo. Etcétera.

Como el TimerA está asociado a la finalización de reproducción del búfer de sonido, solo tenemos que configurarlo en modo contador, con un valor de conteo igual a 1. De esa manera, el chip DMA de sonido disparará una interrupción cuando termine de reproducir el búfer.

En ese momento, le indicamos al chip las nuevas direcciones de inicio y fin del siguiente búfer que debe tocar. El DMA empieza a reproducir inmediatamente. Mientras tanto, ejecutamos la parte de composición del reproductor de MOD sobre el búfer que el DMA terminó de reproducir (o sea, es lo mismo que la técnica de doble búfer de pantalla: componemos la música en un búfer mientras que el DMA reproduce lo que hay en el otro).

[masteries]

He publicado el código en mi github: https://github.com/joaquinferrero/explo ... explorer.s

No es una versión que se pueda ensamblar, es la versión de desarrollo para Falcon, y está en pañales. Pero es la única que tengo a mano. Está codificada en el código de letras original del ST (parecido al CP437).

La idea es la siguiente: si estamos reproduciendo a 50 Khz, y tenemos un búfer para 1000 muestras, necesitamos rellenar ese búfer 50 veces por segundo. O si tenemos espacio para 2000 muestras, 25 veces por segundo. Etcétera.

Como el TimerA está asociado a la finalización de reproducción del búfer de sonido, solo tenemos que configurarlo en modo contador, con un valor de conteo igual a 1. De esa manera, el chip DMA de sonido disparará una interrupción cuando termine de reproducir el búfer.

En ese momento, le indicamos al chip las nuevas direcciones de inicio y fin del siguiente búfer que debe tocar. El DMA empieza a reproducir inmediatamente. Mientras tanto, ejecutamos la parte de composición del reproductor de MOD sobre el búfer que el DMA terminó de reproducir (o sea, es lo mismo que la técnica de doble búfer de pantalla: componemos la música en un búfer mientras que el DMA reproduce lo que hay en el otro).

Es exactamente como lo tengo programado, la IRQ del TimerA en modo contador está asociado a la finalización del DMA; se le pasan las direcciones start y end de la siguiente trama y pone a 1 la variable que indica que hay que realizar una nueva mezcla. En el programa principal se ve esa variable puesta a 1 y realiza la mezcla de 3 voces; pueden ser sonidos de verdad, o sonidos dummy si ya no hay nada que mezclar.

Para optimizar más, los .wav se cargan en memoria con padding de ceros al final, debido a que los sonidos siempre han de tener longitudes iguales a tramas de mezcla, de esta forma evito tener que estar comparando constantemente cuando llego al final del .wav . En la función de mezclado, se resta 1 a la longitud de trama de ese .wav y cuando llegue a ser cero, la longitud de trama será 1 y el puntero apuntará a un .wav dummy (todo ceros).

Gracias por el código, voy a estuadiarlo ahora mismo,

[masteries]

Depurando mi código, encontré un problema por el que la IRQ del DMA saltaba a una frecuencia mucho mayor que 50 Hz, lo he estado corrigiendo y parece que ahora salta a un ritmo normal,

A depurar un porquito más este finde , a ver si saco el mezclador en breves,

[masteries]

Por fin he sacado el tiempo que hacía falta,

Adjunto una prueba del mezclador de audio funcionando; es un .tos de los que compilo directamente con las herramientas;
lo he probado con el emulador Steem

De lo que he notado, es que los sonidos habrá que normalizarlos, porque hay dos samples hard-codeados en el código del ejecutable; y uno de ellos tiene los niveles más altos y se "come" al otro sample.

Por otra parte, tengo que reescribir la parte del código que mezcla el sonido (estoy por escribirla en ensamblador), porque está dentro de un bucle for y hay al menos dos instrucciones adicionales por cada mezcla, si se hace un unroll del bucle for, ocupará algunos KB más de memoria pero te quitas de encima unas 25000 instrucciones por segundo (que a buen seguro te harán falta para otras cosas en tu videojuego, y el 68000 se sentirá más aliviado ); la instrucción que compara si ya ha mezclado 250 muestras (250 muestras * 50 Hz = 12,5 KHz) y la instrucción de salto al principio del bucle.

Todo esto se ha realizado sin tocar para nada el chip Yamaha, que estaría disponible para reproducir música, ya que la salida del Yamaha y del PCM DMA se mezcla por hardware antes de salir del Atari STE

-Por otra parte, el pobre 68000 se las ve y se las desea para mantener el tipo a 12,5 KHz con 3 voces, voy a tener que bajar a 6,25 KHz para que sea factible utilizar sonidos .wav en un videojuego.

con 6Khz - 8Khz , vamos sobrados. Para explosiones, saltos, lasers y demás efectos FX sobra. créeme. ¿Pero hablamos del DAC PCM del STe o con el Yamaha 2149F del STfm?

mostro interés...

le interesa...

le interesa...

convocando...

otro más...

ya están todos convocados,

Publicado ejecutable de muestra del mezclador de audio, a buen seguro te interesará.
Es un .tos, lo ejecutas directamente haciendo doble click con el ratón.

Buscad el nuevo post, con un ejemplo del mezclador con una voz de musiquita, otra voz con la avispa y una tercera voz con voces.

Hay que pulsar la tecla espacio para que empiece a funcionar,

[crashman]

Hola masteries!

Por fin he sacado el tiempo que hacía falta,

Tiempo... ya no se que es eso. Ni Atari tengo ahora montado.
He porbado tu fichero en el Hatari, el que tengo en OSX, y la verdad, no sabria que decirte...
Solo oigo unos "ruidos". Que clase de samples has puesto?
No se si es así lo que tiene que sonar o no...
Si me pudieras decir que he de esperar escuchar...
Tengo claro que mi setup actual atariano no es idoneo para nada, pero aún no veo la luz al final del túnel, para volver a tener un Atari en la mesa.
Siento no poder ser de más ayuda.
Si los samples, por ejemplo, fuesen voces, no se, diciendo "uno", "dos" o "izquierda", "derecha"...
Saludos.

[masteries]

Hola masteries!

Por fin he sacado el tiempo que hacía falta,

Tiempo... ya no se que es eso. Ni Atari tengo ahora montado.
He porbado tu fichero en el Hatari, el que tengo en OSX, y la verdad, no sabria que decirte...
Solo oigo unos "ruidos". Que clase de samples has puesto?
No se si es así lo que tiene que sonar o no...
Si me pudieras decir que he de esperar escuchar...
Tengo claro que mi setup actual atariano no es idoneo para nada, pero aún no veo la luz al final del túnel, para volver a tener un Atari en la mesa.
Siento no poder ser de más ayuda.
Si los samples, por ejemplo, fuesen voces, no se, diciendo "uno", "dos" o "izquierda", "derecha"...
Saludos.

Son dos tristes samples, uno de ellos es una especie de escarabajo volador (pero se oye saturado) y el otro, que se oye bien es una avispa (se debería oir varias veces); hoy quería meter una melodía, la avispa y alguna voz para que se notase mejor; de todas formas sólo lo he podido probar en el emulador STEEM, y puedo decir que el efecto de los filtros paso bajo del STE real parece no estar presente. Sinceramente desconozco que tal esta emulada la parte más puramente hardware del STE, porque en la parte de filtros activos hay 2 que afectan a la salida del PCM. Para emularlo bien, tendrían que haber programador unos integadores y derivadores en tiempo contínuo simulado (y no creo que hayan llegado a tanto).

De todas formas hoy quiero probar otros samples y a ver si puedo reprogramar la función de mezclado en ensamblador;
¡fíjate la de tiempo que necesito! jajaja

[masteries]

Hola masteries!

Por fin he sacado el tiempo que hacía falta,

Tiempo... ya no se que es eso. Ni Atari tengo ahora montado.
He porbado tu fichero en el Hatari, el que tengo en OSX, y la verdad, no sabria que decirte...
Solo oigo unos "ruidos". Que clase de samples has puesto?
No se si es así lo que tiene que sonar o no...
Si me pudieras decir que he de esperar escuchar...
Tengo claro que mi setup actual atariano no es idoneo para nada, pero aún no veo la luz al final del túnel, para volver a tener un Atari en la mesa.
Siento no poder ser de más ayuda.
Si los samples, por ejemplo, fuesen voces, no se, diciendo "uno", "dos" o "izquierda", "derecha"...
Saludos.

Esos deseos han sido escuchados, adjunto un nuevo test del mezclador con 3 voces a la vez, a 12,5 KHz.

Una es una musiquita, otra voz es la avispa y la tercera son voces diciendo 3,2,1,Go!

Ahora lo que me toca es reprogramar la función de mezclado para que sea más eficiente, (los sonidos están limitados a 64KB, por .wav, para que no haya que manejar variables de 32 bits, está pensado para hacer los cálculos en 16 bits o menos, ayúdemos al 68000 ).

[explorer]

Si fuesen solo dos voces, valdría con hacer un rorx.b, pero al ser tres voces... la cosa se complica mucho (bueno... no... en M68K tenemos instrucciones divs y divu).

¿Por qué ha de ser tres voces, y no dos, o cuatro?

Por ejemplo, si miras en mi código, a partir de la etiqueta AMIGA, verás que hago la media aritmética para los dos primeros canales del tracker para ponerlos en el canal derecho del DMA (más bien escribo dos bytes, pero no recuerdo el porqué), y luego lo mismo para los otros dos canales para el canal izquierdo. Y la media aritmética es un rorx.b, en los dos casos.

P.D.: me estoy dando cuenta de lo horrible que es mi código. Pero era la forma de programar de los años 90, cuando eras joven e inexperto: tirar líneas de ensamblador, con muy pocos comentarios, sin sangrados ni macros que facilitaran la compresión de lo que se quiere hacer... Horrible. Hoy lo haría de otra manera más eficiente y clara, por supuesto.

[masteries]

Si fuesen solo dos voces, valdría con hacer un rorx.b, pero al ser tres voces... la cosa se complica mucho.

¿Por qué ha de ser tres voces, y no dos, o cuatro?

Por ejemplo, si miras en mi código, a partir de la etiqueta AMIGA, verás que hago la media aritmética para los dos primeros canales del tracker para ponerlos en el canal derecho del DMA (más bien escribo dos bytes, pero no recuerdo el porqué), y luego lo mismo para los otros dos canales para el canal izquierdo. Y la media aritmética es un rorx.b, en los dos casos.

P.D.: me estoy dando cuenta de lo horrible que es mi código. Pero era la forma de programar de los años 90, cuando eras joven e inexperto: tirar líneas de ensamblador, con muy pocos comentarios, sin sangrados ni macros que facilitaran la compresión de lo que se quiere hacer... Horrible. Hoy lo haría de otra manera más eficiente y clara, por supuesto.

hmm... usted sabe mucho de las instrucciones del 68000, eso es muy bueno para lo que nos traemos entre manos

el código que mezcla ahora es muy simple, pero sé que es ineficiente, porque debe estar escribiendo en memoria el valor de las variables según cambian su valor... mientras que habría que hacerlo usando un registro de la CPU y guardar el valor sólo cuando se ha terminado de mezclar... es por este tipo de cosas que quiero escribir esa parte en ensamblador. Ahora mismo es un triste "while":

Código: Seleccionar todo

valor = "posicion del stream DMA que toque";
valor2 = valor + (unsigned char)250;

while(valor < valor2)
{
   dma_stream[valor] = pcm_sample1[position_pcm1] + pcm_sample2[position_pcm2] + pcm_sample3[position_pcm3];
   position_pcm1++;//Esto hay que hacerlo usando registros d0-d7
   position_pcm2++;//y las direcciones de los streams con a0-a7 y post incremento    (a0)+
   position_pcm3++;
   valor++;
}



Al bucle quiero hacerle un unroll, para que en lugar de repetirse 250 veces, se repita 10 veces o así, para reducir el número de comparaciones del "while" e instrucciones de salto al mismo,

Lo dejé en 3 voces para no seguir añadiendo sumas al bucle... pero cuéntame bien el uso de rorx.b y le metemos 4 voces en un momento,

[explorer]

Al hacer una suma, se establecen los indicadores C y X de la palabra de estado. Al hacer un rorx, lo que estamos haciendo es desplazar un bit a la derecha el registro correspondiente más el indicador X (por si hubo acarreo). El efecto neto es que hemos dividido por dos el contenido del registro. Si contenía la suma de dos valores, pues ahora tenemos la media.