Ehum, ¿alguien compartiría conmigo -por el amor de dios- la sabiduría de las transferencias rápidas a VRAM (esto es, sin usar la BIOS). Para una demo que ando preparando necesitaría transferir 1536 bytes a VRAM en un solo frame, ya se que es un poco bestia, pero...

Además temo el asunto de las incompatibilidades con las diferentes máquinas... ¿alguien que pueda construir una rutina sólida y reutilizable -léase snippet- con comprobación de cuales son los puertos de lectura/escritura de VRAM utilizados por el FTP y demás?. He estado buscando pero solo he visto pequeñas reseñas de OUTs sin dejar las cosas muy claras.

Notese que quien suscribe es un completo neófito en hacer burradas con el VDP y que siempre ha sido muy formalito y ha usado siempre la BIOS en sus relaciones sexuales .

Por el tema de las incompatibilidades yo no me apuraría. Pero si quieres hacerlo bien, tienes que leer las posiciones de memoria 6 y 7 del slot 0-0, es decir, de la BIOS. En cualquier MSX sin tunear, tendrás

?HEX$(PEEK(&h0006))
98
Ok

Ese es el puerto de datos. ¿Cómo usarlo?

Pues bien sencillo desde ensamblador:

LD A,[0006h]
LD C,A

Y a partir de aquí, en lugar de utilizar OUT [nn],A habría que usar OUT [C],A o las instrucciones parecidas de bloques, OUTI, OTIR, etc

Mi recomendación: pasar de todo. Asume que 98 y 99 están siempre ahí. De hecho, sólo cambiaría para MSX1 con ampliación externa a MSX2, pero seguirían teniendo en 98 y 99 los puertos del TMS9918, así que ningún problema

Y con OUTIs llegas bien a 1,5 KB, incluso a 60 Hz, siempre que no quieras copiarlos "muy arriba" en la pantalla.

Creo que ronda los 800 bytes o así, ¿no?  ... no se si habrá alguien que nos pueda dar el dato exacto...

Voy a ser mas claro, se puede hacer una transferencia de 768 Bytes (osea un screen 1 completo) y algo más(32 bytes mínimo) desde la Bios. O para estas cantidades ya es mas apropiado usar los puertos.

Gracias.

¡Veo que cada vez más gente se vuelca al lado oscuro!

Respecto a la velocidad del volcado, yo no consideraría únicamente eso. También tienes que tener en cuenta el tiempo que te roba la interrupción de la BIOS cada uno de esos frames. Si quieres rascarle un buen pico, este hilo de Sapphire no tiene desperdicio:

http://www.msxgamesbox.com/karoshi/index.php?topic=212.0

Y respecto al volcado a VRAM yo haría varias consideraciones :

- Los consumos en ciclos son :
Así pues, el OUT (N),A es la instrucción de volcado más rápida que hay, el OUTI la supera gracias a que incluye un par de operaciones sobre los registros del Z80. El OTIR es bestialmente más potente que los anteriores, hay que tener en cuenta que si ponemos 600 OUTIs seguidos tendremos un consumo extra de 2T por cada OUTI, 600x2=1200T contra los 2T extras que consumirá el OTIR (¡se te olvidaron los ciclos de espera M1 Wyz !). Una pena que definitivamente no se pueda usar en los MSX de primera generación, ahora que ¿os imaginas lo potente que es en un TR?; pues de hecho es (mucho) más rápido que usar el VDP
Respecto a cual usar; pues dependerá de lo que se quiera volcar y de su geometría en pantalla. ¿Te acuerdas aquel comentario de Sapphire hablando de la "multitarea"?, si por ejemplo, se trata de un volcado en el que el ancho no es de 32 bytes (si hablamos de NAMTBL) y por tanto te ves obligado a sumar una cantidad al puntero a la VRAM, puedes hacerlo de manera que esta operación sea el propio retardo, vamos que procura no usar NOPs, que eso es desperdiciar el Z80 .

- Está claro que el VDP de los MSX1 no soporta un flujo continuo de datos, necesita forzosamente alguna pausa entre OUTs . Esa es la razón de porque no funciona el OTIR en los MSX1; bueno, para ser precisos si que funciona; pero cuantos más datos le hagamos volcar el riesgo de que se nos vaya a la porra se incrementa. Lo mejor es usarlo para transferencias mínimas.

- La pausa que tenemos que dejar es lo que levanta más discusiones. Históricamente se hablaba de 8T, recientemente dvik en un hilo de MRC comentaba que se necesitan 16T (en ningún caso estoy contanto los ciclos empleados por el propio OUT), la BIOS deja 40T y yo empíricamente he llegado a dejar lo mínimo, 5T y ha funcionado.

- Hay muchos modelos de MSX1, no se cual se puede considerar el más lento. Personalmente, el HB-75P lo tengo considerado como equipo lento, únicamente porque fue de los primeros en llegar a España, la pregunta es ¿cuales son los primeros modelos MSX1 que aparecieron en el mercado?. Ya se que probablemente esos modelos incorporaran memorias lentas en sus primeras series y que luego se actualizará su hardware; pero es por tener alguna referencia. Con esa información se podría tratar de averiguar, a base de testeos, cual es el mínimo retardo necesario para que funcione en el 99,99% de los aparatos.

En el "Caverns of Titan" yo tengo las siguientes estructuras:

Funciona en todos los equipos que he probado. Si le quitas el NOP se va al carajo. Lo podeis comprobar en el texto parpadeante de la pantalla inicial del juego.

E indefinidamente repites las anteriores instrucciones. Funciona bien para todo lo que lo he usado : caracteres animados sobre todo (cascadas, puerta, rayos, etc.).

Idem que el anterior. Lo uso en la rutina de impresión de carácteres.

El OTIR sólo lo uso en la rutina de BiFi de cambio de paleta, que como son pocos bytes no pasa nada.

Bueno, ya está bien, que me duele muuuuucho la cabeza y empiezo a no tener claro lo que he escrito

P.D.: ¿Lo de los 3,5Kb era broma, no, Robsy?

Pues las pruebas son satisfactorias. Prepararé algo un poco más llamativo, para que no creais que os estoy tomando el pelo con algún truquillo de feria, y veréis un video a 50/60 Hz y media pantalla. La aplicabilidad para juegos es aún discutible, pero creo que tengo CPU suficiente aún como para además incluir un replayer ligero funcionando sincronizado con el refresco.

He estado haciendo cuentas y ni por esas...veamos:

El retardo base en los accesos al VDP es de 2 microsegundos, por lo que habrá que calcular cuantos ciclos de espera supondrán para un Z80 a 3,579545Mhz

1T/3579545 = 0,000000279 segundos/ciclo

0,000002/0,000000279 = 7,16845 ciclos

Suponen 7,16 ciclos del Z80 de los MSX, ya tenemos pues que hay que esperar entre 7-8 ciclos de media. Luego en función del modo de pantalla habrá que esperar (o no) un poco más antes de poder acceder al dato en la VRAM (tanto da leer como escribir). Para screen 2 tenemos un retardo extra que va de 0 a 6 microsegundos, por lo que, en el peor de los casos tendremos que esperar hasta 28T-29T. La excepción la tenemos únicamente durante una ventana que dura 4300 microsegundos tras el retrazado vertical, en ese intervalo el retardo extra es cero. Durante ese intervalo basta con esperar esos 7-8 ciclos iniciales.
¿Cuantos bytes podriamos transferir teóricamente durante ese intervalo (que es el óptimo para transferir datos a toda velocidad)?. Para calcularlo primero averiguamos cuantos ciclos tenemos disponibles durante ese lapso de tiempo :

(4,3ms * 3579545) / 1000ms = 15392 ciclos

15392 / 18 (ciclos OUTI) = 855 instrucciones OUTI

Así pues, podriamos encadenar 855 OUTIs uno detrás de otro sin esperas, lo que da poco más de 1/6 de pantalla o 3 lineas y pico de caracteres. A todas luces insuficiente.

Y si definitivamente si no accedemos al VDP en ese intervalo, hay que esperar un poco entre acceso y acceso.

He hecho también alguna preguntilla por el MRC para ver si me aclaran algunas dudas que tengo...

Como es probable que con tanto número me haya liado, espero que algún matématico que ronde por aquí le eche un vistazo a las cuentas y razonamientos en general. A ver si resulta que está más o menos correcto

Vamos que me muero de ganas de ver esos experimentos

Quita, quita, ni se te ocurra, piensa que la media de retardo viene a ser de 18T y (si me lo confirman en MRC) resulta que el OUT también podría contarse; así que las espaldas estarían cubiertas.
Y todo ello suponiendo que no envies mucho más de 900 bytes, si te apañas con eso, casi seguro que lo puedes hacer a toda caña sin preocuparte por nada. Yo también me he puesto a hacerme algunos programillas para ver si hay un fundamento "práctico" en todo esto o como siempre del dicho al hecho hay mucho trecho.