|
SapphiRe_MSX
Visitante
|
 |
« Respuesta #15 : 29 de Mayo de 2007, 05:20:04 pm » |
|
La rutinita de marras: ; FAST LDIRVM (en MSX1 sólo funciona dentro del vblank o con la pantalla apagada)
FLDIRVM: ld a,[7] ; a = puerto #0 de escritura del VDP
ld c,a ; c = puerto #0 de escritura del VDP
inc c ; c = puerto #1 de escritura del VDP
out [c],e ; Escribimos en el VDP el byte bajo de la direccion de destino
set 6,d ; Activamos el sexto bit del byte alto (no seria necesario si ya lo dejamos activado al inicializar DE)
res 7,d ; Desactivamos el séptimo bit del byte alto (no seria necesario si ya lo dejamos desactivado al inicializar DE)
out [c],d ; Escribimos en el VDP el byte alto de la direccion de destino
dec c ; c = puerto #0 de escritura del VDP
@@LOOP: outi ; (1)
outi ; (2)
outi ; (3)
outi ; (4)
outi ; (5)
outi ; (6)
outi ; (7)
outi ; (8)
outi ; (9)
outi ; (10)
outi ; (11)
outi ; (12)
outi ; (13)
outi ; (14)
outi ; (15)
outi ; (16)
djnz @@LOOP
ret
Uso: HL = Direccion de origen en RAM DE = Direccion de destino en VRAM (si activamos los bits adecuados de D nos podríamos ahorrar las instrucciones set y res) B = Numero de bloques de 16 bytes a transferir, pero multiplicados por 17 y módulo 256 Es decir, para transferir, por ejemplo, 704 bytes, habría que inicializar B a: 704 div 16 = 44 44 * 17 = 748 748 mod 256 = 236 Si el número de bytes a transferir fuera múltiplo de 256, el primer número (en este caso 44) y el último (en este caso 236) coincidirían. ¿Por qué he escogido usar 16 outis? Por la sencilla razón de que la cantidad máxima que puede enviar esta rutina es de 2048 bytes (256 bloques de 16 bytes), que es, precisamente, el tamaño de una tabla de patrones o colores, pero claro, se puede cambiar y meter el número de outis que sean necesarios, si quieres 32 o incluso 64, modificando adecuadamente los números de las operaciones. Un último consejo: usadla con las interrupciones desactivadas  Saludos -- Sph. |
|
|
|
« Última modificación: 29 de Mayo de 2007, 05:24:04 pm por SapphiRe »
|
En línea
|
|
|
|
|
SapphiRe_MSX
Visitante
|
|
« Respuesta #16 : 30 de Mayo de 2007, 05:19:55 pm » |
|
¿Nadie le ha echado un vistazo?  |
|
|
|
|
En línea
|
|
|
|
|
Darth_Fistro
|
|
« Respuesta #17 : 31 de Mayo de 2007, 10:18:16 am » |
|
Mil gracias, Sapphire  La ví ayer,pero no pude responder, y ahora no es que me pueda extender mucho, que estoy en el curro De muerte viene la rutina, por cierto  Cosillas: comentas que puede mandar 2048 bytes, supongo que en un vblank Pero por lo que se ha comentado, el máximo que se puede mandar en un vblank en una máquina a 60Hz son 800 bytes y 1536 en una de 50Hz. Aquí me quedo un poco "pillao". ¿Qué no cuadra? Tenía entendido que ese era el tope en un MSX1 (y no veas si me jode, necesito velocidad por un tubo)  Si te sales del vblank, debería aparecer basura en pantalla, ¿cierto? ¡¡Gracias de nuevo!! |
|
|
|
|
En línea
|
MSX FOREVER (hasta que saquen un ZX81 con TMS, PSG y 64K de RAM)
|
|
|
|
SapphiRe_MSX
Visitante
|
|
« Respuesta #18 : 31 de Mayo de 2007, 10:59:10 am » |
|
Cosillas: comentas que puede mandar 2048 bytes, supongo que en un vblank No, no. Digo que tal y como está, es capaz de transferir hasta un máximo de 2048 bytes, que son, precisamente, 256 bloques de 16 bytes. Si en lugar de 16 outis metes 32, el máximo que es capaz de transferir sería 4096. Esta rutina es muy rápida, pero SÓLO funciona en el vblank y si la pantalla está apagada. Calculo que (en NTSC) se podrían transferir aproximadamente unos 512bytes sin problemas en el vblank con esta rutina, así que si consigues dividir las transferencias en paquetes de medio kb, te serviría perfectamente. De todas formas, creo que alguien por aquí ya ha estado jugueteando con esta rutina para transferir más de lo que yo vuelco en el QBIQS... a ver, a ver... ¿alguien tiene más datos que aportar? Y si la usas, no olvides inicializar b correctamente que ese es el truco |
|
|
|
« Última modificación: 31 de Mayo de 2007, 11:01:02 am por SapphiRe »
|
En línea
|
|
|
|
|
jltursan
|
|
« Respuesta #19 : 31 de Mayo de 2007, 02:31:13 pm » |
|
Si te sales del vblank, debería aparecer basura en pantalla, ¿cierto? Um, no. Esas cantidades como bien dices, son los límites teóricos de la cantidad de bytes que se pueden volcar a la VRAM usando OUTIs durante el vblank. El vblank es el periodo comprendido entre el fin de la ultima linea de la pantalla activa (empieza por tanto en la 192) y acaba al comienzo de la misma (virtualmente sería la coordenada -1), el resto de la pantalla es visible y no es vblank, para volcar datos durante este intervalo el único requisito es que esperemos un poco entre OUTI y OUTI; pero no tiene porque salir basura si así lo hacemos. Durante el frame o cuadro se pueden enviar muchos más bytes que los que se pueden enviar durante el vblank ; claro, que tampoco es cuestión de pulirse todo el tiempo de la CPU enviando datos a pantalla  ¡A este paso dentro de poco te vas a convertir en Darth VDP! :-D |
|
|
|
|
En línea
|
Doom dee doom dee doom
|
|
|
|
SapphiRe_MSX
Visitante
|
|
« Respuesta #20 : 31 de Mayo de 2007, 02:36:06 pm » |
|
por cierto, JL, ¿recuerdas cuando empezamos a intercambiarnos mensajes sobre esta rutina? Fíjate en lo que ha quedado al final |
|
|
|
|
En línea
|
|
|
|
|
Darth_Fistro
|
|
« Respuesta #21 : 31 de Mayo de 2007, 04:08:12 pm » |
|
¡Gracias a ambos, monstruos! Ya me ha quedado claro lo del vblank y fuera de él (algo aprendo, lento pero algo) pero lo comentaba porque en la rutina de Sapphire los outis van a saco sin nops por medio (a no ser que me pierda algo, eso me parece). Por eso decía que fuera del vblank se podría marear la cosa. Ya tengo claro que vblank=outis a saco, y luego si la transferencia es mayor=creo rutina que vuelca el resto con dos nops  Para las cosillas spectrumeras, como quiero música de por medio (cómo mola, jeje) quiero saber más o menos cuántos ciclos consume el Caruso a tres canales, y así poder hacer por ejemplo una rutina tal que así: halt (salta el Caruso -> tralarí, tralará, reggaeton del güeno y tal...) Volcado de x bytes a saco (outis, outis and more outis) Resto del volcado-> usando nops Ahora necesito saber si después del vblank, con el Caruso en marcha, puedo volcar 600 bytes, 500 o lo que sea. Aunque a lo mejor lo suyo es no arriesgar y hacer la rutina con nops y me aseguro que tarde lo que tarde el reproductor no se descuadra el volcado a VRAM. De nuevo, gracias, estoy dando el salto al lado oscuro poco a poco (a empujones, eso sí) |
|
|
|
|
En línea
|
MSX FOREVER (hasta que saquen un ZX81 con TMS, PSG y 64K de RAM)
|
|
|
|
SapphiRe_MSX
Visitante
|
|
« Respuesta #22 : 31 de Mayo de 2007, 04:21:23 pm » |
|
Resto del volcado-> usando nops Claro que, en lugar de nops, puedes aprovechar esos ciclos para ir haciendo otros cálculos... |
|
|
|
|
En línea
|
|
|
|
|
Darth_Fistro
|
|
« Respuesta #23 : 31 de Mayo de 2007, 04:50:40 pm » |
|
Pero... ¿qué cálculos puedo hacer en 8 ciclos? ¿Y cómo controlo el flujo de las instrucciones, qué ejecutar y el orden?  Eso suena muy maquiavélico... ¡cuenta, cuenta! |
|
|
|
|
En línea
|
MSX FOREVER (hasta que saquen un ZX81 con TMS, PSG y 64K de RAM)
|
|
|
|
SapphiRe_MSX
Visitante
|
|
« Respuesta #24 : 31 de Mayo de 2007, 05:02:33 pm » |
|
Pero... ¿qué cálculos puedo hacer en 8 ciclos? ¿Y cómo controlo el flujo de las instrucciones, qué ejecutar y el orden? A ver, los 8 ciclos son un tiempo MÍNIMO de espera. Si tienes que hacer un cálculo donde no intervengan de, hl ó bc, puedes aprovechar esos tiempos entre outi y outi para hacer todo lo que necesites con el acumulador y de. Si necesitases más registros siempre puedes hacer un exx, utilizarlos lo que necesites y repetir el exx para recuperar los valores adecuados de hl y bc. Aunque siendo estrictos, incluso podrías utilizar b, sabiendo que se decrementa tras cada outi. Claro que todo esto sólo lo puedes hacer desenrollando "a lo bestia" (del todo) el bucle de transferencia, e intercalando el cálculo entre los outis... |
|
|
|
« Última modificación: 31 de Mayo de 2007, 06:19:04 pm por SapphiRe »
|
En línea
|
|
|
|
|
pitpan
|
|
« Respuesta #25 : 31 de Mayo de 2007, 05:21:32 pm » |
|
Juanma:
En cuanto al uso del Caruso te recomiendo que la secuencia se la siguiente:
HALT
CALL DUMP_PSG ; Creo que se llama así
; Aquí, todos los temas de volcado a VRAM
...
; Y aquí, el resto de procesos del Caruso
...
De este modo, conseguirás que el sonido sea síncrono pero no pierdas tiempo de v-blank con procesos no relacionados con VRAM.
|
|
|
|
|
En línea
|
|
|
|
|
jltursan
|
|
« Respuesta #26 : 31 de Mayo de 2007, 07:44:23 pm » |
|
por cierto, JL, ¿recuerdas cuando empezamos a intercambiarnos mensajes sobre esta rutina? Fíjate en lo que ha quedado al final Grin Sí....y hay que ver como se ha desarrollado la condenada De este modo, conseguirás que el sonido sea síncrono pero no pierdas tiempo de v-blank con procesos no relacionados con VRAM. Eso que te comenta Robsy es muy importante, todo lo dicho se queda en nada si lo primero que haces tras la sincronización no es la transferencia a video. Eso suena muy maquiavélico... ¡cuenta, cuenta! Como ya te explica Sapp, se pueden hacer muchas cosas; pero en este caso, depende 100% de como tengas montada la rutina y de lo que estes haciendo, es posible que puedas aprovechar el tiempo o que no puedas  . Tu siempre ten presente que los NOPs es una perdida de tiempo |
|
|
|
|
En línea
|
Doom dee doom dee doom
|
|
|
|
