Hello! 

Pues revisando el mogollón de topics que he abierto dando la vara sobre el tema, quiero ir sacando un poco "conclusiones"´para utilizar en juegos spectrumeros (léase tabla de patrones a piñón fijo):

He aquí una rutina original cortesía de Mr.Robsy:


Para empezar, Dioniso sugiere cambiar lo siguiente:


por:


ahorrándonos unos bytes, teniendo que añadir a la llamada a la rutina, tan sólo el sumar a HL el valor $4000 (si volcamos a la 6144, p.e., pues ld hl,6144+$4000)

JL apuntó que para que la rutina funcione en MSX1 debemos intercalar un par de nops en los primeros 6 outis (no me quedó claro por qué en los seis y no en los ocho). La cosa quedaría así.


Y por último, JL también propone "desrollar" la rutina si disponemos de memoria suficiente repitiendo el bucle de outis, supongo que el número de bytes a volcar tendrá que ser múltiplo del número de outis dentro del bucle.

¿Alguna nueva sugerencia para lograr una rutina veloz e interrumpible? (al fin y al cabo los resultados los sufriréis vosotros, jeje) 

Pues no tengo ni idea, Alfonso, en eso estoy pez y si me lo pones en hexa, peor 

Bueno, lo de los nops que faltan en los dos últimos outi ya lo veo: el ld b,d y el jp nz,loop ya introducen retardo por ellos mismos. Si dices que ld a,0 ahorra un estado y funciona en un MSX real, daríamos un pasito en cuanto a velocidad  ¡Hay que exprimir el VDP!

(si hace falta, se le puente un chip Fat Agnus)

Gracias a ambos

O sea, que si más o menos transfiero 1kb, con un nop va que chuta. Si quiero tansferir 4kbs, le pongo 2 nops y así aseguro que no aparece la imagen distorsionada.

Así a bote pronto, con la rutina anterior, ¿cuántos bytes se pueden mandar en un vblank?

1) Efectivamente, los NOPs son solo necesarios cuando nos encontramos fuera del VBlank. Se puede usar NOP o lo que se quiera; pero se tienen que sumar alrededor de 28T contando los consumidos por el propio OUT. Para saber cual es la cantidad exacta (teórica por supuesto ) de bytes que se pueden transferir sin necesidad de retardos, echa un vistazo por aquí. Fuera de este intervalo te arriesgas a que si no retardas, aparezca basura.

2) Para enviar la dirección de inicio de escritura basta con enviar los dos bytes consecutivamente al VDP a través del puerto de comandos, primero se envía el bajo tal cual y luego el alto. El AND $3F se hace únicamente para asegurar que no vamos a superar los 16Kb y el OR $40 porque ese bit (el 6) tiene que estar a 1 para escritura. Ambas operaciones son superfluas, tal como dice Dioniso basta con construirse una direccion de VRAM un poco "especial" previamente (con $4000 escribiriamos en la $0000). Otra cosa, el EI puede estar por encima del último OUT, las interrupciones se activan a continuación de la instrucción que sigue al EI.
La rutina quedaria algo así:

3) La rutina de volcado de Robsy estaba pensada para que se intentarán enviar durante el VBlank todos los bytes posibles sin retardo y a partir de ese punto intercalaba retardos hasta alcanzar el total de bytes que quería enviar. Funciona (o debería) en cualquier emulador y equipo real.

Otra: si se puede forzar un evío de 1500 bytes, volcar la pantalla en cuatro HALTs como cuatro bloques de 1,5 kbs para evitar las "olas" fuera de sincronismo. Could I?

Básicamente es así como se hace. El HALT sigue siendo problematico a la hora de sincronizar video; pero bueno, es que es tan cómodo...


Porque el propio Robsy lo comentó en su día y además yo la desensamblé...


Nunca hagas eso (aunque yo lo hice en el CoT ), si la máquina es un MSX1 a 60Hz, no vas a poder conmutar la frecuencia y por lo tanto tu juego no funcionaría bien en esos modelos. Lo mejor es prepararte para lo peor y hacerlo pensando en 60Hz, si luego le sobra, mejor que mejor.


El como distribuyas los volcados ya depende de como tengas montado el juego, el tipo de este, lo que quieras conseguir, etc. Simplemente tu sigue la regla de los 800+NOPs y el resto tendrás que imaginarlo tú... ;-)
Recuerda que todo esto es simplemente una guía de como sacarle la máxima velocidad al VDP evitando corrupciones. El como evitar parpadeos y tirones ya depende de como te organices.

Bueno, yo lo que hago es agrupar todas las transferencias de forma que se realicen siempre en el vblank, para lo cual no necesito meter retardos entre outi y outi. Si tengo que hacer transferencias más grandes (normalmente al inicio de un nivel o algo así) desconecto la visualización de la pantalla, lo cual me permite hacer lo mismo durante todo el tiempo.

Además, ahorro unos cuantos ciclos extra desenrollando el bucle y aprovechándome de que cada outi realiza un dec b de forma automática, por lo que si en cada bucle hago 16 outi más un djnz, realmente estoy decrementando b un total de 17 veces por bucle. Así, si quiero transferir 320 bytes hago el siguiente cálculo:

320 div 16 = 20 -> tengo que dar 20 vueltas al bucle
20 * 17 = 340 -> he de decrementar b en 340 unidades antes de que llegue a cero, luego
340 mod 256 = 84 -> este es el valor con el que tengo que inicializar b

En general, si cada bucle se compone de N instrucciones outi, para transferir L bytes (con L múltiplo de N, por supuesto) habría que inicializar b con la siguiente instrucción:


y como esas operaciones se realizan en tiempo de compilación, no hay problema alguno y ahorramos unos cuantos ciclos extra que en las rutinas que Darth ha publicado en el primer post se llevan las instrucciones ld d,b y ld b,d.

Por si alguien se pregunta si podría darse el caso de que estuviéramos realizando un número incorrecto de transferencias, le diré que se tranquilice, ya que N y N+1 son números primos entre sí, por lo que su mínimo común múltiplo es, precisamente, el producto de ambos y el método funciona para cualesquiera L y N (con L múltiplo de N).

Ahora no tengo aquí la rutina, así que si os interesa decídmelo y la pongo aquí para quien quiera utilizarla y optimizarla (cosa que molaría mucho).

Saludos
--
SapphiRe

Según para que cosas...


Hombre, si le mandas para acá le pediré un autógrafo para todos los del foro En cuanto tenga algo de tiempo enchufo el portátil y copio la rutina aquí.


Pos si, y si no es así, que alguien me corrija

Saludos
--
Sph.