motor AGD para V9958 modo gráfico G4 para HD6309

[jltursan]

Último mensaje de la página anterior:

Ah, claro, tu has podido reciclar el SPRITEINK, tienes razón. En mi caso ha sido un poco más complicado; pero bueno, está operativo igualmente.
Del PSET del VDP espero bastante, o mucho me equivoco o debería ser bastante más rápido que el de la CPU.

[pser1]

Ah, claro, tu has podido reciclar el SPRITEINK, tienes razón. En mi caso ha sido un poco más complicado; pero bueno, está operativo igualmente.
Del PSET del VDP espero bastante, o mucho me equivoco o debería ser bastante más rápido que el de la CPU.

He tenido un serio encontronazo al tratar de modificar ReDraw para que solo redibuje la parte ocupada por la ventana del Inventario.
Aparentemente funciona, pero en alguna ocasión y suele ser en la pantalla de la pirámide, el texto de inventario se convierte en basura
ocupando una línea solamente, acepto y vuelvo a pulsar 'I' y ya sale bien
Manteniendo la rutina antigua para redibujar la pantalla competa no hay problema nunca!
Quería evitar que los bloques sobrescritos por objetos se vean un momento antes de que se redibujen los objetos.
Actualmente utilizo las coordenadas XY del objeto en pixels para calcular las celdas sobrescritas en la tabla 'tileCpy'
de donde saco los códigos de los patrones que deben ser pintados al quitar el objeto.
Por lo tanto, si pusiera un 255 en esta celdas para marcar que 'no se ven' y no dibujarlas cuando se pinta la pantalla
luego al quitar el objeto me faltarían los códigos de los patrones ...
Tal vez me decida a guardarme los códigos de estos patrones como ya hacía en la versión para G3, con lo que el 255 sería una opción ...
Guardar cuatro bytes mas por objeto no va a ser el fin del mundo
saludos
pere

[jltursan]

No se si merece la pena el esfuerzo, como dices, sólo se verán un momento (cosa de ms. vamos).

De todas formas, recuerda que el VDP tiene un mecanismo para deshabilitar la pantalla y dejarla a oscuras, mediante esto podrías camuflar todo el redibujado y además, conseguir un extra de velocidad importantísimo.

Fíjate a que me refiero viendo el paso de pantallas en este juego que usa G4:

https://www.youtube.com/watch?v=sItWZpE7LKY

[pser1]

No se si merece la pena el esfuerzo, como dices, sólo se verán un momento (cosa de ms. vamos).
De todas formas, recuerda que el VDP tiene un mecanismo para deshabilitar la pantalla y dejarla a oscuras, mediante esto podrías camuflar todo el redibujado y además, conseguir un extra de velocidad importantísimo.
Fíjate a que me refiero viendo el paso de pantallas en este juego que usa G4:

Buenos días,
es una posibilidad, pero me parece horroroso comparado con la transición limpia e inmediata de una a otra sin recurrir a deshabilitar la pantalla.
Si en el motor G3 me guardaba los cuatro patrones, aquí debería poder hacer lo mismo, entonces podría poner un 255 a los patrones sobrescritos
en el mapa en RAM y la rutina que envia la pantalla completa los 'saltaría'.
No tengo prisa, lo volveré a probar hoy. Al final anoche me quedé con una versión que, las veces que lo probé, no presentaba el defectillo
que mencioné al dibujar el menú de inventario ni siquiera en la pantalla de la pirámide donde usas la bomba para abrir el camino
saludos
pere

[jltursan]

es una posibilidad, pero me parece horroroso comparado con la transición limpia e inmediata de una a otra sin recurrir a deshabilitar la pantalla.

El mundo MSX es un poco particular al respecto. Mira lo que me comentaban en este hilo (penúltimo mensaje)

Al final yo me decanto por el "blankeo" de pantalla, la ganancia de velocidad es importante y parece ser un estándar en el mundo MSX

[pser1]

@jltursan
increíble que en MSX2 esté tan bien visto el tema de blanquear pantalla para ganar velocidad de GPU.
Yo no lo voy a aplicar, me parece correcto tal como me funciona la última versión.
Por cierto, por una vez, en lugar de ponerme a picar código para guardar los patrones sobrescritos por los objetos, he estado
analizando su efecto ... para acabar descubriendo que "no me sirve para nada"
Veamos, cuando se sale del Inventario, se llama a mi nueva rutina 'ReDrawM' que solamente repinta el área que ocupaba la ventana del menú
de forma que no hay efectos indeseados ...
Solo cuando se cambia de una pantalla a otra se dibujan primero los patrones que la forman y a continuación se pintan los bloques guardados
en el modo aventura, a continuación los Sprites y finalmente los Objetos. Esto hará que *siempre* se vea como se sobrescriben unos pocos
patrones por bloques en modo aventura (si los hay) y los objetos que deben aparecer en la nueva pantalla.
No importa lo que haga, siempre se hace esto en este orden (tal como está en AGD). En todo caso se podría dibujar los Objetos antes que
los Sprites y no tengo claro que esto cambie mucho.
Mirando el fuente buscando puntos en los que paso a doble velocidad (1,78 MHz) he encontrado los siguientes:
- WBloc parte donde se guardan los bloques en la tabla de modo aventura
- Dmsg parte que muestra mensajes de texto
- ayFX_P01 reproducción de sonidos via AY-3-8910 ó compatible
- Pt3_Play reproducción de música via mismo chip
- LoadObj para cargar objetos en pantalla
- DRoom dibujar la pantalla con los patrones necesarios
A mi gusto faltaban unos pocos, así que he añadido
- RBloc que dibuja en pantalla los bloques del modo aventura necesarios
- ReDrawM que redibuja los patrones que estaban detrás de la ventana de inventario
- ShowOb rutina que muestra un objeto dejado por el jugador
Y posiblemente añada LoadSprt que muestra los sprites
Cualquier idea será bien recibida
pere

[pser1]

he cambiado el orden de los Objetos y los he puesto antes que los Sprites a los que tengo a doble velocidad ...
Ha mejorado bastante aunque es ligeramente perceptible si sabes donde va a aparecer un objeto.
Voy a dar por cerrado el tema de migración a modo G4 dejando el motor en las mismas condiciones que para modo G3
si bien hay diferencias en la longitud del binario (ejecutable)
- modo G3 -> 23.964 bytes
- modo G4 -> 21.701 bytes
No está mal el ahorro de 2.263 bytes
Hay que tener en cuenta que ahora tanto los patrones/tiles como los objetos se precargan directamente a la VRAM
por lo que el ahorro se reparte así, tomando como referencia el juego Foggy's Quest
- Objetos - 860 bytes
- Patrones - 632 bytes
- Programa - 771 bytes
saludos
pere

[pser1]

Viendo que la imagen no sale siempre en la misma posición de centrado horizontal a pesar de tener un valor fijado en el R#18
al pasar al modo gráfico G4, he estado buscando si hay alguna forma de *leer* los registros en lugar de escribir en ellos, pero
parece que no es posible.
Voy a añadir una opción al motor AGD para que permita centrar la imagen al usuario justo al empezar el juego
Supongo que el motor tendrá que guardar en variables del sistema, en mi caso, en la primera página de RAM, una copia de aquellos
registros que se deseen consultar o variar sobre la marcha.
Ahora mismo se me ocurren dos
- El color del borde en R#7 nibble bajo
- El ajuste horizontal/vertical de la imagen en R#18
Agradeceré cualquier información al respecto por si hubiera alguna otra forma de conseguirlo ...
muchas gracias de antemano
pere

[jltursan]

Que curioso, ¿y vas a añadir el código extra necesario para que el engine permita de serie un ajuste de la posición vertical/horizontal de la pantalla?
Eso es hilar muy fino, tu piensa que a fin de cuentas vas a sacrificar RAM (y la "molestia" de obligar al usuario a determinar la posición óptima) para un número a priori limitado de usuarios. Por experiencia te digo, no se como está implementada la placa de John; pero jamás he encontrado un MSX pinchado a uno de los múltiples monitores/TVs con los que los he probado y que presente un desajuste vertical. Si que es verdad que el horizontal varía mucho, además hay modos que se desplazan más que otros según el monitor, supongo que sólo por eso merece la pena el ajuste.

¿Y el borde?, si eso lo controlas con el comando BORDER del AGD...en este caso no acabo de pillarte...

Lo de leer y escribir los registros no lo tengo en la cabeza; pero juraría que salvo un conjunto, la mayoría son de solo lectura. En el MSX se guarda en RAM en todo momento una copia de muchos de ellos y de los que no, instintivamente se tienden a mantener como variables en RAM, que es mucho más económico y menos engorroso que tener que leer el registro cada vez. Otras informaciones de registros que te puedo sugerir tener muy a mano: sprites habilitados o no, frecuencia 50Hz/60Hz, pantalla habilitada o no...y seguro que yo mismo tengo alguno más por ahí.

[pser1]

Que curioso, ¿y vas a añadir el código extra necesario para que el engine permita de serie un ajuste de la posición vertical/horizontal de la pantalla?
Eso es hilar muy fino, tu piensa que a fin de cuentas vas a sacrificar RAM (y la "molestia" de obligar al usuario a determinar la posición óptima) para un número a priori limitado de usuarios. Por experiencia te digo, no se como está implementada la placa de John; pero jamás he encontrado un MSX pinchado a uno de los múltiples monitores/TVs con los que los he probado y que presente un desajuste vertical. Si que es verdad que el horizontal varía mucho, además hay modos que se desplazan más que otros según el monitor, supongo que sólo por eso merece la pena el ajuste.

Tiene razón casi siempre sale bien centrado verticalmente, peo ya puesto a añadir código para ajuste horizontal le he puesto para vertical también. Con John comprobamos que el horizontal varia icluso de una sesión a otra en la misma máquina y si no quieres tocar nada, te saltas
esta parte y a jugar

¿Y el borde?, si eso lo controlas con el comando BORDER del AGD...en este caso no acabo de pillarte...

Quería poner el borde de un color distinto al de juego para facilitar el centrado. Foggy me sale con fonfo = margen ...
Al salir del centrado restauro el del juego, así que necesito saber cual era

Lo de leer y escribir los registros no lo tengo en la cabeza; pero juraría que salvo un conjunto, la mayoría son de solo lectura. En el MSX se guarda en RAM en todo momento una copia de muchos de ellos y de los que no, instintivamente se tienden a mantener como variables en RAM, que es mucho más económico y menos engorroso que tener que leer el registro cada vez. Otras informaciones de registros que te puedo sugerir tener muy a mano: sprites habilitados o no, frecuencia 50Hz/60Hz, pantalla habilitada o no...y seguro que yo mismo tengo alguno más por ahí.

De momento me he guardado los R#7 y R#18, los demás no me han hecho falta (todavía)
muchas gracias una vez mas por compartir tus conocimientos!
Saludos
pere

[jltursan]

Tiene razón casi siempre sale bien centrado verticalmente, peo ya puesto a añadir código para ajuste horizontal le he puesto para vertical también. Con John comprobamos que el horizontal varia icluso de una sesión a otra en la misma máquina y si no quieres tocar nada, te saltas
esta parte y a jugar

Cierto, el MSX cuenta para ello con una pequeña memoria mantenida con pila y que permite salvar todas estas configuraciones de factoría. En este caso, eso no existe y se queda a la buena de Dios.

Quería poner el borde de un color distinto al de juego para facilitar el centrado. Foggy me sale con fonfo = margen ...
Al salir del centrado restauro el del juego, así que necesito saber cual era

Y cierto también, yo siempre tengo en cuenta el BORDER en MSX; pero claro, vete tú a saber que cantidad de juegos hay ya hechos que se llevarán en la mochila el color que acabes poniendo tú en esa pantalla

[pser1]

@jltursan
el control de arriba y abajo es super sencillo, basta con sumar o restar 16 (1 al nibble alto) al contenido del R#18
La operación corrige automáticamente los desbordamientos en ambos sentidos
Pero mover a derecha e izquierda es peor. Al sumar 1 al nibble bajo los dos desbordamientos producen una variación
en el nibble superior, justo en su bit mas bajo, y no es fácil detectar estos casos, de momento tengo esto funcionando, pero
le dedicaré mas tiempo a ver si encuentro un método mejor ...

Código: Seleccionar todo

DoLeft      adde   #1                     ; increment low nibble
            tfr   e,a                  ; pass to regA
            bita   #$0F                  ; test low nibble
            bne   CenApply               ; if not zero (overflow), skip next
            sube   #16                  ; else deduct received halfcarry on high nibble
            bra   CenApply               ; apply option
DoRight      sube   #1                     ; decrement low nibble
            tfr   e,a                  ; pass to regA
            anda   #$0F                  ; use low nibble
            cmpa   #$0F               ; is it %1111 (borrow)?
            bne   CenApply               ; no, skip next
            adde   #16                  ; yes, add suffered borrow to high nibble
CenApply      ste   <copyR18               ; update variable


Si alguien tiene una idea/sistema mejor, agradeceré cualquier comentario para mejorar el que estoy usando
muchas gracias
pere

[jltursan]

Um, ¿y manipular los nibbles por separado y sólo juntarlos al actualizar el registro?

[pser1]

Um, ¿y manipular los nibbles por separado y sólo juntarlos al actualizar el registro?

Lo he probado, José Luis y desafortunadamente los 4 shift left y 4 shift right para recomponerlos usan demasiados bytes para poca
mejora. Al final he decidido no preocuparme por el hecho de que una de cada 16 veces tanto derecha como izquierda van a afectar
la posición vertical, simplemente que lo corrija verticalmente el usuario. Lo he probado varias veces y es mas que aceptable!
Todo el código añadido, incluyendo la lectura de teclado y decodificación de tecla queda así
saludos
pere

Código: Seleccionar todo

DoCenter      bsr   InvBorder            ; invert border colour
WaitForK2   jsr   [$A000]               ; wait for a keypress
            beq   WaitForK2            ; if none, loopback
            cmpa   #13                  ; was it Enter?
            beq   DebugEnd               ; stop debug mode
            ldb   #$10                  ; add 1 to high nibble
            cmpa   #'U'                  ; requested Up?
            beq   CenApply               ; yes, process it
            ldb   #$F0                  ; subtract 1 from high nibble
            cmpa   #'D'                  ; requested Down?
            beq   CenApply               ; yes, process it
            ldb   #$01                  ; add 1 to low nibble
            cmpa   #'L'                  ; requested Left?
            beq   CenApply               ; process it
            ldb   #$FF                  ; subtract 1 from low nibble
            cmpa   #'R'                  ; requested Right?
            bne   WaitForK2            ; no, loopback
CenApply      addb   <copyR18               ; add R#18 current value
            stb   <copyR18               ; update variable
            lbsr   WaitVDP               ; be sure VDP is not busy
            ldb   <copyR18               ; get new value
            stb   1,x                  ; send to port #1
            ldb   #$92                  ; get R#18
            stb   1,x                  ; send register
            bra   WaitForK2            ; loop back


[pser1]

buenos días!
supongo que era previsible que no me quedara contento con la solución de aceptar que al mover horizontalmente la imagen, esta se
moviera un pixel arriba o abajo de vez en cuando ...
Estudiando el problema, cosa que debí hacer la primera vez, descubrí lo siguiente:
- El valor 15 en el nibble bajo (posición horizontal) puede aparecer al ir sumando uno, del 14 al 15, correcto en este caso
pero también aparece restando 1 de 0 dando 15, este caso debe ser corregido ya que ha restado uno del nibble alto
- El valor 0 en el nibble bajo puede aparecer al ir restando uno, del 1 al 0, siendo correcto en este caso
pero también aparece sumando 1 a 15, en este caso debe ser corregido ya que ha sumado uno al nibble alto
Resumiendo *NO* siempre que se encuentra un 0 o un 15 hay que aplicar la corrección, este fue mi error
Entonces, aplicando el buen consejo de José Luis, vi que aislando el nibble alto para los movimientos horizontales y añadiéndolo
de nuevo al finalizar los cálculos solventa el problema con un bajo coste: 13 bytes extras y el uso de una variable de la página 1!
Me parece perfectamente admisible. El conjunto de código empleado para el centrado de la imagen ha pasado a ser en total 68 bytes
que tampoco es exagerado, ¿no?
Adjunto la rutina entera por si alguien puede echarle una ojeada y si encontráis alguna forma de abreviarla, agradeceré vuestros
comentarios/ideas. He tratado de no emplear registros del 6309 ya que ocupan un byte extra y por tanto son 1 ciclo mas lentos
saludos
pere

Código: Seleccionar todo

DoCenter      bsr   InvBorder            ; invert border colour
            bra   SetCurCen            ; apply current image position using R#18 copy
WaitForK2   jsr   [$A000]               ; wait for a keypress
            beq   WaitForK2            ; if none, loopback
            cmpa   #13                  ; was it Enter?
            beq   CentEnd               ; exit center mode
            ldb   #$10                  ; to add 1 to high nibble
            cmpa   #'U'                  ; requested Up?
            beq   CenApply               ; yes, process it
            ldb   #$F0                  ; to subtract 1 from high nibble
            cmpa   #'D'                  ; requested Down?
            beq   CenApply               ; yes, process it
            ldb   #$01                  ; to add 1 to low nibble
            cmpa   #'L'                  ; requested Left?
            beq   CenHoriz               ; process it
            ldb   #$FF                  ; to subtract 1 from low nibble
            cmpa   #'R'                  ; requested Right?
            bne   WaitForK2            ; no, loopback
CenHoriz      addb   <copyR18               ; add R#18 current value
            andb   #$0f                  ; delete high nibble
            addb   <r18High               ; add current one to avoid undesired borrow/overflow
            bra   CenUpdate            ; skip next one
CenApply      addb   <copyR18               ; add R#18 current value
CenUpdate   stb   <copyR18               ; update variable with new value
            andb   #$f0                  ; delete low nibble
            stb   r18High               ; save high nibble for next time
SetCurCen   lbsr   WaitVDP               ; be sure VDP is not busy
            ldb   <copyR18               ; get new value
            stb   1,x                  ; send to port #1
            ldb   #$92                  ; get R#18
            stb   1,x                  ; send register
            bra   WaitForK2            ; loop back

[jltursan]

Me parece muy razonable, sobre todo si funciona

He tratado de no emplear registros del 6309 ya que ocupan un byte extra y por tanto son 1 ciclo mas lentos

¡Anda!, eso no lo sabía, aun así supongo que el poder disponer de registros extra compensa en algunos casos esos ciclos extra...

Por cierto, mediante una demo técnica ya he hecho una prueba de rendimiento entre el "ploteo" mediante CPU vs. VDP y como era de esperar, mediante VDP es el doble de rápido de largo. Adicionalmente, estoy convencido de que el código va a ser mucho menos así que ya estoy tardando en mirar el motor de partículas

[pser1]

He tratado de no emplear registros del 6309 ya que ocupan un byte extra y por tanto son 1 ciclo mas lentos

¡Anda!, eso no lo sabía, aun así supongo que el poder disponer de registros extra compensa en algunos casos esos ciclos extra...

Ciertamente al tener mas registros puedes conservar variables o contadores en ellos y además su juego de instrucciones tiene algunas del tipo addr, subr que permiten sumar o restar un registro directamente de otro sin problemas (incluso 16 bits) no solo en el acumulador.

Por cierto, mediante una demo técnica ya he hecho una prueba de rendimiento entre el "ploteo" mediante CPU vs. VDP y como era de esperar, mediante VDP es el doble de rápido de largo. Adicionalmente, estoy convencido de que el código va a ser mucho menos así que ya estoy tardando en mirar el motor de partículas

Muy bien, enhorabuena
Animo, y a por el cambio! Ya hablaremos de las nuevas rutinas porqué así podré empezar directamente con comandos VDP en lugar de empezar a base de CPU ...
saludos
pere