Aprendiendo a manejar los chips de video V9958 y sonido YM-2149

[jltursan]

Último mensaje de la página anterior:

Dado que ahora estás trabajando con un V9958 puedes hacer lo mismo que yo y controlar tiempos de ejecución a la vieja escuela, cambiando el color del borde.

En mi código tengo la siguiente macro que podrías adaptar sin esfuerzo:

Código: Seleccionar todo

   macro BORDER clr ; 0-15
        push af
        ld a,clr             ;Get data to set
        di
        out (MSX_VDPCW),a
        ld a,$87             ;Get register #
        out (MSX_VDPCW ),a
        pop af
        ei
   endmacro

Si lo hago al comienzo y al final de las rutinas, tengo bandas de color que me indican como se reparte el tiempo a lo largo del frame. Cuando te acostumbras a interpretarlo, es muy visual

DEBUG_AGD.jpg (24.43 KiB) Visto 251 veces

Si a eso le sumas un flag DEBUG, activándolo o desactivandolo se invocan todos los BORDER o no.

Por cierto, en la macro puedes ver el uso estandar que te comentaba a la hora de deshabilitar las interrupciones, el mínimo tiempo posible entre los accesos al latch.

[pser1]

@jltursan,
me parece una excelente idea lo del borde. En cuanto a las interrupciones propias de Dragón, no me afecta para nada ya que las
tengo deshabilitadas desde que empieza el programa hasta que retorna al Basic
De momento tengo que encontrar tiempo para ver el motivo por el que los efectos, aún sin ninguno seleccionado, están entorpeciendo
la música. Luego empezaré a 'estudiar' las rutinas Music_Play y ayFX_Play para ver si las puedo optimizar para el 6309.

Suponiendo que pongo un cambio de color de borde al inicio del ISR y tras la rutina psgrout pongo un segundo color, luego tras música un
tercer color y tras efectos un cuarto color (el que tiene ahora el juego ...)
Como en Dragón trabajamos con NMI, está claro que NO podemos deshabilitarlos, de ahí el nombre de "non maskable", esto quiere decir
que se está dando el caso de llegar una interrupción antes de que la anterior haya sido totalmente 'servida' por lo que se atiende a esta
segunda y la otra queda a la espera o se pierde, no estoy seguro, tendré que mirarme el súper-manual del 6809-6309, a ver que explica.
Esta pequeña reflexión aumenta mis dudas ... ¿Porqué ahora si se oyen los efectos y antes no? Si ahora precisamente se ejecuta antes
la música que los efectos ...
Si escucho los efectos bien y la música mal, tal vez sea porqué los efectos están modificando registros de ayRegs antes de que se envíen
al chip en la próxima interrupción ... esta es una posibilidad que no se me había ocurrido antes ...
saludos
pere

[pser1]

Hola de nuevo,
revisando el código de música / efectos he encontrado un par de errores que posiblemente solo afectaban a los efectos ...
De todas formas, recompilando las tres versiones del juego, las que solamente ofrecen una funcionalidad están 'sonando'
correctamente, incluso la de música!
No obstante la que mezcla ambas funcionalidades genera la música bastante entrecortada mientras que los efectos suenan bien.
Así que voy a tener que centrarme en comparar los listados de compilación del que solo hace música con el que hace todo, a ver
si encuentro algún motivo para que la música suena mal mientras *NO* hay ni un solo efecto seleccionado
saludos
pere

Pd por cierto, los sonidos parecen modificar correctamente solamente los datos necesarios del canal C, o sea ruido, tono y volumen
además de modificar el mixer para habilitar o no Tono-Ruido en dicho canal C

[jltursan]

También hay que tener en cuenta que reproducir música y a la vez efectos no es maravilloso. Normalmente la reproducción del efecto "estorba" la reproducción de la música en una magnitud variable.

Me suele parecer que los sonidos con "ruido" generan más distorsión que los limpios, especialmente si se encadenan muchos seguidos.

Tengo pendiente mirar lo que comentas, a ver si los registros se inicializan correctamente siempre para un SFX independientemente de cual sea el canal por el que vaya a ser reproducido.

[pser1]

He hecho una sesión de trazado (DBG-XRoar) para tres programas.
- A) El programa que solo contiene el motor AGD y produce música sin scripts AGD
- B) La versión que produce música y sonido
- C) La versión DiamondGeezer8 que solo produce música
He anotado los datos de ayRegs en los tres casos durante 6 frames y estos son los resultados

Código: Seleccionar todo

   Frecuencias             No AGD-Mus     AGD-MusFx     AGD - Mus
A6,00,DD,02,44,03,00,      38,0F,0F,0F - 38 22 22 22 -- 38 0d 0d 0d             ,00,00
A6,00,DD,04,44,03,00,      38,0F,0E,0F - 38 22 f0 22 -- 38 0d dc 0d             ,00,00
A6,00,DD,06,44,03,00,      38,0F,0C,0F - 38 22 8c 22 -- 38 0d 7a 0d             ,00,00
A6,00,DD,08,44,03,00,      38,0F,0B,0F - 38 22 5a 22 -- 38 0d 4a 0d             ,00,00
A6,00,DD,0A,44,03,00,      38,0E,09,0E - 38 f0 f5 f0 -- 38 dc e8 dc             ,00,00
A6,00,DD,0C,44,03,00,      38,0E,08,0E - 38 f0 c3 f0 -- 38 dc b7 dc             ,00,00


Las frecuencias enviadas son las mismas en los tres casos. El valor del mixer también
Respecto a los niveles de volumen (tres columnas centrales), para mi los correctos son los valores de la primera columna
es decir del programa sin script AGD que hice en plan pruebas
El programa que solo envía música, quedándonos con el nibble bajo está mal pero cerca de lo esperado
Pero el programa que soporta música y efectos envía verdadera basura

Y lo triste del caso es que el motor de música es *el mismo* en los tres casos
Nunca he probado a abrir dos sesiones de debug DBG-XRoar al mismo tiempo ... me ahorraría anotaciones en papel ...
saludos
pere

Pd Lo he debugado manualmente, es decir pasando de las interrupciones, así que no puedo achacar problemas de exceso de tiempo
entre dos interrupciones ...

[pser1]

confirmo que *NO* se pueden abrir dos sesiones de DBG en el mismo PC
saludos
pere

[jltursan]

¿Y No AGD-Mus y AGD-XXXX emplean las mismas rutinas (especialmente el music_play) y se invocan con el mismo mecanismo?, por que lo que es el AGD no debería suponer ninguna diferencia, las áreas de variables están totalmente diferenciadas...

[pser1]

Hola,
¿Recuerdas José Luis que, al principio de la conversión comenté que no hacía falta mantener el código que genera la tabla vT_
ya que disponemos de ella en una serie de lineas con declaraciones fcb?
Pues bien, como luego aparecieron toda clase de problemas, acabé por realizar una conversión prácticamente textual por lo
que esta parte de código está ahora en el motor ... igual la elimino aunque solo sea para salvar espacio.
No hace mucho, hice una reestructuración de variables del motor y resulta que una llamada "zero16b" la cambié por un puntero a texto
Menos mal que lo he visto debugando paso a paso dos programas, el de música y el que no lleva script AGD (el único que iba bien)
Ahora mismo acabo de probar las tres versiones del DiamondGeezer y todas funcionan perfectamente.

Lo que noto es que la música emplea la última fila de volumen y por tanto varia de 0 hasta 15. Lo que sucede que es FlipFlap.pt3 usa
niveles muy altos, cercanos a 15 y así casi enmascaran a los efectos. Se oyen, pero quedan algo escondidos tras la música.
Supongo que se podría obligar a la música a echar mano de una linea algo mas arriba de la tabla de volúmenes relativos
En fin, mas vale tarde que nunca
saludos
pere

[pser1]

Hola,
he modificado el motor para que reproduzca la música sensiblemente mas baja que antes, de esta forma se oyen perfectamente
los efectos y no he notado apreciable pérdida en la música mientras suenan los efectos ...
He intentado reducir el volumen de sonido en el VTracker, pero solo he conseguido variar el volumen de reproducción, pero
al grabar guarda los mismos niveles anteriores.
¿Hay alguna forma de modificar 'globalmente' el volumen de sonido en un fichero .pt3 ?
muchas gracias
pere

Pd Este fin de semana intentaré grabar un vídeo del Diamond Geezer con música y efectos ...

[pser1]

Buenas tardes,
os traigo una nueva actualización.
El motor AGD ya es capaz de reproducir ficheros de música formato .pt3 y además emitir efectos de sonido.
Sigo utilizando como programa de pruebas el juego DiamondGeezer.
Os adjunto link donde podréis ver el video de demostración (poco menos de un minuto)
saludos y buen fin de semana!
pere
https://www.youtube.com/watch?v=zYMfmzttu3w

[jltursan]

Suena perfecto

[pser1]

Suena perfecto

Digamos que he tenido que bajar bastante el volumen de la música para que los efectos se oyeran claramente.
Me sorprende que no haya ninguna forma de controlar el nivel de volumen de la música, por ejemplo con un comando
dentro del script AGD ...
He estado mirando la parte que determina este volumen mientras decodifica datos de un frame, pero utiliza cuatro valores
y no está muy claro su valor, así que intentaré hacer una sesión de DBG_XRoar poniendo un breakpoint donde se calcula, a ver
si tengo suerte y puedo ver los valores que determinan la fila de la tabla de volumen 'relativo'.
saludos
pere

[pser1]

@jltursan
¿Sabes de algún sitio en el que se pueda averiguar el significado de las abreviaturas utilizadas en las variables pt3_xxxxx
y las correspondientes a ch_xxxx?
La verdad es que sería de una gran ayuda en mi intento de descifrar el proceso de cálculo del nivel de volumen que hay que aplicar
en un cierto canal
De momento tengo claro que se utiliza el valor del comando que se procesa (decodifica) tras hacerle cuatro shifts a la izquierda, de forma
que el nibble bajo pasa al alto. Esto indica la línea (fila) de la tabla de valores relativos a utilizar ya que se pasa al offset para acceder al valor
del volumen necesario.
Por otro lado, en reg_B encuentro el valor $8F del que solamente se utiliza el nibble bajo junto con el alto indicado antes ...
Lo malo es que en algún punto se le suma el contenido de ch_CrAmSl que no se como desencriptar su significado
saludos
pere

[jltursan]

No tengo mucha idea de las interioridades del tracker; pero buscando he encontrado esto:

http://www.deater.net/weave/vmwprod/pt3_player/README_pt3.txt

En el que en inglés explica lo siguiente:

* Samples

	The pt3 file allows for 32 samples.  These samples contain
	values that are applied to the music notes as they are playing.

	The 16-bit address of a sample X can be found by getting the
		16-bit little-endian address at offsets
		$6A+(X*2) and $6B+(X*2) in the header.

	Byte 0:	 LOOP VALUE -- sample offset to return to once hit the end
	Byte 1:  LENGTH     -- number of 32-bit sample values
	Byte 2+: VALUES     -- list of 4-byte (32-bit samples)

	* Sample format

		+ Byte 0 --- 7 6 5 4321 0
				Bit 7 - Amplitude sliding
				Bit 6 - 1/0 amplitude slide up/down
				Bit 5 - 1/0 envelope slide up/down
				Bits 4321 - sign extend, envelope slide value
				Bit 0 - Sample has envelope

		+ Byte 1 --- 7 6 5 4 3210
				Bit 7     - Envelope sliding
				Bit 6     - Accumulate Tone
				Bit 5     - parameter to envelope sliding?
				Bit 4     - Bit 6+4 used to set Noise/Channel
					    mixer value
				Bits 3210 - Amplitude

		+ Byte 2 --- Freq Low -\
		+ Byte 3 --- Freq High----- Used as base tone

Y a la vista de la rutina parece evidente que gestiona el "Amplitude sliding", almacenando los consecutivos valores del volumen cuando este está siendo subido o bajado. Respecto a la etiqueta, no consigo imaginar que significa "Cr", el resto parece evidente.

[pser1]

No tengo mucha idea de las interioridades del tracker; pero buscando he encontrado esto:
http://www.deater.net/weave/vmwprod/pt3_player/README_pt3.txt

Perfecto, muchísimas gracias
Me será muy útil cuando me ponga con los 'players' independientes del motor AGD.
Si me es posible haré dos versiones, una utilizando las interrupciones IRQ de Dragón (a 50Hz) para los usuarios que tengan
el módulo CoCo-PSG o parecido y otra versión empleando las interrupciones NMI del V9958 para quienes dispongan del Wordpak2+
y el CoCo-PSG o bien la nueva placa de John Whitworth, ahí lo fijaré a 50Hz pues parece ser la frecuencia estándar de los .pt3
Se me acumula el trabajo
saludos
pere

[pser1]

@jltursan,
después de las elucubraciones referentes a los ciclos empleados por el código musical entre interrupciones, cambié a modo PAL
para ganar un 20% de tiempo, pero esta tarde he vuelto a dejarlo como NTSC, la pantalla se ve mas grande con el V9958 y el
juego se acelera un 20%, cuestión muy importante, a costa de que la música vaya un poco más rápida.
Espero que esto signifique que todavía hay margen para añadir los efectos 'shrapnel' en un futuro próximo ...
saludos
pere

[jltursan]

Yo me mantendría en PAL, los monitores o TV en los que se va a pinchar esto van a ser en su 99% PAL y si generas NTSC puedes provocar algún problema según el soporte que de el monitor.
La velocidad tampoco supone gran cosa y sería más una molestia que otra cosa. Es más fácil adaptar los 50 frames del PAL a los 25 frames del motor AGD Spectrum original (o Dragon). Ojo, que no me refiero al propio ZX, que el Spectrum también genera 50 frames/seg. .

Lo que me choca es lo que dices que en NTSC la pantalla se te ve más grande. Es justo al revés, en NTSC tienes 525 líneas y en PAL 625, la pantalla en NTSC es algo más achatada y con peor calidad de color (ya sabes, NTSC, "NeverTheSameColor"). En PAL tienes mejor color y más líneas verticales; pero por contra al ser el refresco menor, menos nitidez
.