Hola,
una reflexión ....
Si tenemos un ordenador PAL, que genera 50 imágenes por segundo
nos deja exactamente 0,02 segundos = 20 milisegundos para hacer
operaciones entre DOS imágenes ...
Como Dragón funciona (en RAM) a 0,89Mhz, esto nos da
890.000 ciclos/seg * 0,02 seg = 17.800 ciclos de reloj
Si tomamos la parte del bucle de la versión SCROLL5 para ver el conteo de ciclos
Código: Seleccionar todo
400D 3576 ( scrol5.txt):00008 (4+8) bucle puls d,x,y,u
400F 32E820 ( scrol5.txt):00009 (4+1) leas 32,s
4012 3476 ( scrol5.txt):00010 (4+8) pshs d,x,y,u
4014 32E8E8 ( scrol5.txt):00011 (4+1) leas -24,s
4017 3576 ( scrol5.txt):00012 (4+8) puls d,x,y,u
4019 32E820 ( scrol5.txt):00013 (4+1) leas 32,s
401C 3476 ( scrol5.txt):00014 (4+8) pshs d,x,y,u
401E 32E8E8 ( scrol5.txt):00015 (4+1) leas -24,s
4021 3576 ( scrol5.txt):00016 (4+8) puls d,x,y,u
4023 32E820 ( scrol5.txt):00017 (4+1) leas 32,s
4026 3476 ( scrol5.txt):00018 (4+8) pshs d,x,y,u
4028 32E8E8 ( scrol5.txt):00019 (4+1) leas -24,s
402B 3576 ( scrol5.txt):00020 (4+8) puls d,x,y,u
402D 32E820 ( scrol5.txt):00021 (4+1) leas 32,s
4030 3476 ( scrol5.txt):00022 (4+8) pshs d,x,y,u
4032 32E8A8 ( scrol5.txt):00023 (4+1) leas -88,s
4035 118C0C00 ( scrol5.txt):00024 (4) cmps #$0c00
4039 24D2 ( scrol5.txt):00025 (3) bhs bucle
El bucle que se repite 192 veces requiere: 8 * (4+8 + 4+1) + 4 + 3 = 192 * 143 = 27.546 ciclos
que EXCEDE en mucho los 17.800 ciclos máximos que podemos usar entre dos imágenes.
Claramente 2 imágenes permitirían 2 * 17.800 = 35.600 lo que nos da para ésto ya mucho mas!
Pero para ello NO podemos estar marraneando directamente en pantalla, sino que debemos
trabajar en otra área (técnica de doble buffer) y conmutar de la anterior a la nueva cuando
llegue la siguiente interrupción una vez hecho el scroll.
Lo que nos sucede ahora es que cuando llevamos hecho 17800/27546 o sea aproximadamente
un 65% de las líneas, la pantalla es actualizada creando el maldito glitch en la línea sobre la
que estamos trabajando en aquel momento
Analizar como implementar el doble buffer se cargará sin dudas el método del stack ya que las
áreas origen y destino estará separadas, por lo menos, unos 6144 bytes y estos offsets pueden
penalizar mucho (habría que verificar). Aparte el frame rate sería de 25, todavía soportable.
El otro tema a tener en cuenta es que primero copiamos (desplazando) de A hacia B (aumentando
la posición de memoria), pero la siguiente vez copiaremos de B hacia A (reduciendo la posición
de memoria)
Se aceptan propuestas ...
saludos
pere