motor AGD para V9958 modo gráfico G4 para HD6309

[pser1]

Último mensaje de la página anterior:

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

[pser1]

@jltursan
de momento iré convirtiendo algunas funciones del motor que solamente se llaman desde el compilador, por ejemplo
- AChar (un carácter individual)
- Spawn y asociados que tal vez no requieran casi cambios pues los sprites no han cambiado
- Clw (clear window) que podrá reusar mi rutina para redibujar la ventana de inventario, eso espero!
- QRand (no creo que requiera cambios)
- IDiv (también parece simple)
- Todas las rutinas de scores (display, addBonus, AddScore ...)
- DrwMeta (posiblemente sin cambios)
- TDed, GetCol, GtBlk, Dig, FdChk, Crumble (funciones varias a analizar sus posibles cambios)
- NwScr (cambio a una pantalla predeterminada)
Espero que no sea mucho trabajo, pero entiendo que debería hacer primero todas estas funciones y luego ya podré atacar el tema de
las partículas que tiene muchas funciones a adaptar al modo G4!
saludos
pere

[pser1]

buenas tardes,
- Las rutinas 'IDiv' y 'QRand' no necesitaban conversión, solo 'limpieza de comentarios'
- La rutina 'AChar' ha resultado vital para detectar un error en la rutina "NexLin"
Una vez implementada, quise probar primero con texto normal y luego a doble altura y finalmente para rematar la fiesta
probé a llamar cuatro veces seguidas a la rutina con distintos caracteres, pero empezando a escribir en la columna 30
Así que los caracteres 3-4 deberían escribirse en la línea siguiente. Y lo hace, pero ... solamente añade 1 a 'dispY' con lo cual, debido a que
solo baja una línea, solo sirve para texto normal. Para texto de doble altura hay que bajar *DOS* o la siguiente línea pisa la mitad inferior
de la anterior. Esta es la corrección que he añadido a la rutina mencionada, que estaba mal ya en la versión anterior y puede que en la
de Spectrum también ...
- La rutina 'ClW' (clear window) llama a la rutina 'Cls', por lógica, para enviar un comando HMMV, nada de llamar a mi rutina que muestra
el fondo de pantalla que había sido ocultado por la ventana de inventario!

Para seguir haciendo pruebas de otras funciones he extraído el motor del fichero FOGGY.ASM y lo he pasado a la cadena de trabajo
para ficheros AGD. Entonces que querido probar el 'Diamond Geezer' y ha fracasado estrepitosamente.
Los mensajes eran de etiquetas no encontradas, y yo las veía en el fichero fuente
Tras montones de fracasos, he caído en la cuenta. Dentro de inventario hay una rutina LMMM para invertir la línea del cursor, pero
yo además la reutilizo para mi función de bloques parpadeantes y como cabía esperar, al estar la rutina dentro del bloque de inventario,
si un juego *NO* tiene inventario, el bloque no se compila y por tanto la función pasa a ser desconocida
Ha bastado con sacarla del bloque condicional de inventario para solucionar el problema, mil ojos son pocos
El próximo paso va a ser revisar las cuatro rutinas de procesado de contadores (puntuación, récord, bonus y asociados)
Buen fin de semana
saludos
pere

[jltursan]

En esas rutinas no van a necesitar hacer nada probablemente, sólo necesitan la rutina para imprimir caracteres de la fuente a simple y doble altura

Yo ya he integrado los comandos PSET y LINE del VDP en las partículas. Los laseres también se han beneficiado de ello

[pser1]

En esas rutinas no van a necesitar hacer nada probablemente, sólo necesitan la rutina para imprimir caracteres de la fuente a simple y doble altura

Seguro, pero de momento he encontrado una incongruencia en el proceso de añadir el bonus al score.
He hecho un cambio para invertir el bit de carry antes de ir a por el siguiente dígito (anterior) ya que en mi motor si la suma ha sido superior
a 9, la comparación hace que el carry pase a cero y al revés si es menor.
Buscaré el SCORES.AGD que era un buen test para estas funciones y lo compilaré de nuevo a ver que hace

Yo ya he integrado los comandos PSET y LINE del VDP en las partículas. Los laseres también se han beneficiado de ello

Perfecto, en cuanto haya acabado con todas las funciones que me quedan ya te contactaré para echar una ojeada a estas nuevas 'armas'
saludos
pere

[pser1]

Hola,
tras poner a punto el entorno AGD para Dragon-CoCo-MSX2+ he conseguido compilar y ejecutar el Test SCORE
Con mi nuevo motor (rutina corregida), los cálculos son correctos.
He compilado el mismo AGD en el entorno MC6847 anterior y sale mal, ved pantallazo
El Score es de 660 puntos y el Bonus de 270
Luego veréis
ADDING BONUS TO SCORE, y debajo pone 000830 que es incorrecto, lo correcto es 000930
saludos
pere

ScoreErrorG3.jpg (40.06 KiB) Visto 366 veces

[jltursan]

Oh, ¿significa esto que los packs de juegos Dragon contenían este fallo en la puntuación?. No es grave; pero desde luego si alguno se ha fijado le habrá hecho rascarse la cabeza

[pser1]

Oh, ¿significa esto que los packs de juegos Dragon contenían este fallo en la puntuación?. No es grave; pero desde luego si alguno se ha fijado le habrá hecho rascarse la cabeza

Ahora mismo no recuerdo muchos juegos que tuvieran contador para puntuación y además bonus. El error estaba en la rutina AddBo, donde por motivos inescrutables, decidí convertir el opcode ccf de Z80 por un simple clearCarry (entendiedo que era un clear clarry flag )
Desafortunadamente esto implica que nunca se aplica el carry de un dígito a otro
En el motor actual paso los flags al regB, alli le hago un eor #$01 para invertir el bit 0 (carry) y lo devuelvo al regCC
Son tres pasos, pero funciona correctamente. Con el 6809/6309 no hay ninguna instrucción que pueda manipular los flags. Solo acepta AND y OR
saludos
pere

[pser1]

@jltursan
Estoy con las rutinas "GetCol" y "GtBlk" y tengo una duda ...
Veo en tu rutina "gtblk" que calculas las coordenadas dispXY a partir del numero de celda en que está el block 'colectable'
Sin embargo, antes de llamar a 'GetBlk' se llama a 'TDed' para saber si se ha encontrado este tipo de bloque y para ello
dicha rutina informa las variables 'dispXY'.
Yo estaba pensando en quitar todo este cálculo en 'GetBlk' y limitarme a pasar a cero la propiedad del bloque y llamar a
la rutina PAttr para mostrar un bloque #0
¿Te parece correcto o estoy olvidando alguna cosa?
muchas gracias
pere

Código: Seleccionar todo

tded:
      ld l,(ix+3)         ; x coordinate.
      ld h,(ix+4)         ; y coordinate.
      ld (dispx),hl       ; set up test coordinates.

Código: Seleccionar todo

gtblk:
      ld (hl),0           ; make it empty now.
      ld de,MAP           ; block properties beginning address
      and a               ; clear carry.
      sbc hl,de           ; find cell number.
      ld a,l              ; get low byte of cell number.
      and MSX_MAXCOLS-1   ; 0 - 31 is column.
      ld d,a              ; store y in d register.
      add hl,hl           ; multiply by 8.
      add hl,hl
      add hl,hl           ; x is now in h.
      ld e,h              ; put x in e.
      ld (dispx),de       ; set display coordinates.
      xor a
      jp pchr

[pser1]

@jltursan,
creo que ya veo el motivo por el que se recalcula ... incluso en mi versión para G3
La rutina "TDed" llena dispXY con la posición del sprite para analizar si tiene un bloque del tipo solicitado cerca de el.
Sin embargo, para eliminar el bloque 'colectable' hay que llenar dispXY con la posición real del bloque encontrado!
saludos
pere

[pser1]

buenos días,
en esta conversión a modo G4, estoy tratando de comprender lo que hace cada rutina, quizá sea mas quisquilloso de lo necesario,
pero esto me permite algunas veces reducir el código que saldría de una conversión de z80 a 6809 'literal' línea a línea.
En la rutina NwScr he visto que cargan con #80 el contador de máximo número de pantallas del juego.
Todos los ficheros que genera mi compilador, llevan tras la última definición de pantalla, declarada una variable con el número de
pantallas que le preceden:

Código: Seleccionar todo

   ; Screen nr.1
        fcb 255,0,0,255,0,0,255,0,148
numSc   fcb 1

En cada caso la cifra que sigue al fcb es el número exacto de pantallas del juego
Por lo tanto empleando esta variable en lugar del número 80 a piñón fijo me parece mucho mas seguro
sobretodo para evitar problemas si al crear el script AGD se intenta pasar a una pantalla mas allá de la última declarada

Código: Seleccionar todo

NwScr         ldx   #mapDat               ; point to map start
;            ldb   #80                  ; max room number
            ldb   >numSc               ; number of rooms in game

La tabla mapDat está justo delante de Event00, así que un valor 80 para un juego con menos pantallas, acabará apuntando a
bytes del evento. Por lo tanto puede darse la casualidad de que uno de ellos coincida con el valor (erróneo) que estamos buscando
y se pondría como pantalla actual un valor totalmente incorrecto. Por supuesto, si el valor es correcto será encontrado antes y no causará
nunca problemas. Sería solo una protección contra un error al crear el fichero AGD por parte del diseñador del juego ...
saludos
pere

[jltursan]

Ese 80 no parece muy apropiado ahora que lo dices. El caso es que me lo tendría que mirar atentamente tal como has hecho tú, así de cabeza hay algo que no me cuadra todavía...

[pser1]

Ese 80 no parece muy apropiado ahora que lo dices. El caso es que me lo tendría que mirar atentamente tal como has hecho tú, así de cabeza hay algo que no me cuadra todavía...

No es ningún problema el 80 mientras el autor del fichero AGD decida pasar a una pantalla existente, pero si se equivoca y pone una cifra mayor que la última pantalla definida, cabe la posibilidad de que coincida con un byte del Evento00 y la lie parda. Pero serían muchas coincidencias, tengamos en cuenta que hemos convertido 219 juegos de AGD a MC6847 y no han surgido problemas en ninguno de ellos. Es solo una cuestión de protección ante un error de diseño ...
saludos
pere

[jltursan]

Ok, pues creo que ya lo tengo listo

En principio no valdría emplear "numsc" ya que contiene el número de "screens" definido; pero no el número de pantallas que ocupa el mapa. Este número incluye todos los "agujeros" y los bordes laterales, lo que hace que este valor al final sea bastante mayor que "numsc".

Lo que he hecho es incluir un "equ" en el engine tal que así:

Código: Seleccionar todo

MAPLEN   equ stmap-mapdat-MAPWID

De manera que luego en nwscr empleo MAPLEN directamente como número de posiciones a recorrer en el mapa buscando la solicitada en el comando SCREEN. Así se recorren, ni más ni menos, las pantallas que hay exceptuando los límites verticales, sin fallo posible. Si el desarrollador se equivoca, entiendo que al final no se acaba cambiando "roomtb" y el jugador se queda en la misma pantalla tras un reinicio de la misma.

[pser1]

Ok, pues creo que ya lo tengo listo
En principio no valdría emplear "numsc" ya que contiene el número de "screens" definido; pero no el número de pantallas que ocupa el mapa. Este número incluye todos los "agujeros" y los bordes laterales, lo que hace que este valor al final sea bastante mayor que "numsc".
Lo que he hecho es incluir un "equ" en el engine tal que así:

Código: Seleccionar todo

MAPLEN   equ stmap-mapdat-MAPWID

De manera que luego en nwscr empleo MAPLEN directamente como número de posiciones a recorrer en el mapa buscando la solicitada en el comando SCREEN. Así se recorren, ni más ni menos, las pantallas que hay exceptuando los límites verticales, sin fallo posible. Si el desarrollador se equivoca, entiendo que al final no se acaba cambiando "roomtb" y el jugador se queda en la misma pantalla tras un reinicio de la misma.

Tienes razón!
Me parece muy buena solución la que has implementado. Haré lo mismo
muchas gracias
pee

[pser1]

@jltursan
cambiado y verificado. Funciona perfectamente
gracias de nuevo
pere

[pser1]

ya he convertido las rutinas/funciones siguientes:
- NwScr controlando no salir del límite de la tabla de pantallas
- GtBlk
- Dig
- FdChk
Los dos últimos los tenía mal en la versión para modo G3, así que he tenido que comparar con la versión para MC6847
El problema está en que yo decidí para el motor para V9958 que dispX representaría el valor de la posición X y dispY el de Y
justo al revés de lo que hace el motor AGD que los invierte. En la estructura de los sprites la posY está en offset 8 y la posX en offset 9
Así cuando se copian sobre dispX quedan invertidos
Basta con copiarlos en dos veces en lugar de todo de golpe y solucionado
Suerte de disponer del fichero TESTDIG.AGD con el que he podido ir debugando sobre la marcha
No he encontrado ningún test para bloques colectables, ¿Recuerdas algún juego que los utilice?
Lo mismo me pasa con los Metabloques, no se como probarlos ...
A todo esto ya solamente me quedan dos para convertir (antes de ir a por el shrapnel)
- Spawn que solo tiene dos rutinas y no creo que tenga grandes cambios
- Crumble que puede que necesite cambios, no estoy seguro
Ya falta menos
saqludos
pere