motor AGD para V9958 modo gráfico G4 para HD6309

[pser1]

Último mensaje de la página anterior:

ya empieza a rayarme este juego
Lo he terminado unas cuantas veces mas, cada vez habilitando mas sprites para que usen colores.
He empezado solo con sprite 0 y he acabado con sprites 0-1-2-3-4-5-6-7-8 o sea una buena cantidad de variantes
No ha reaparecido el problema en ninguna de las pruebas a pesar de acabar el juego, tiene buena pinta
El código lo he cambiado a esto
Solo he cambiado un pseudo-registro por una variable y he puesto doble velocidad, como tengo en el Sprite16C
saludos
pere

Código: Seleccionar todo

SpriteInk   sta    SPEED2               ; set double speed
            ldd   3,y                  ; get pointer to sprite colour table
            beq   SprInkEx               ; if zero, exit
            lbsr   DisVdpInt            ; disable V9958 interrupts
            lbsr   SetVdpWrit            ; point to that VRAM area            
            ldb   #16                  ; bytes to write
            lda   <varN                  ; get calculated colour value
SprInkL1      sta   ,x                     ; write one VRAM byte
            nop                        ; waste two cycles
            decb                        ; decrement counter
            bne   SprInkL1               ; not done? loop
            lbsr   EnaVdpInt            ; enable V9958 interrupts
            sta   SPEED1               ; back to normal speed
SprInkEx      rts                        ; return

[pser1]

@jltursan,
comparando el código final con el que puse anteriormente, veo que además de los cambios mencionados, ya no modifico el
valor del color recibido del 'compilador C'. O sea no le 'elimino' el nibble alto porqué ya viene a cero, pero tampoco le sumo $20
para deshabilitar la detección automática de colisiones. ¿Crees que ésto puede haber solucionado el problema?

Si realmente no es necesario tener las interrupciones deshabilitadas mientras se envían datos, sinó solamente cuando se 'posiciona'
el puntero a la VRAM, podría eliminar todas las llamadas a DisVdpInt / EnaVdpInt y ponerlas en la entrada y salida de SetVdpWrit.
De todas formas, hay algunos puntos en los que se envían datos directamente a algunos registros, como SetBorder, los Comandos VDP,
Cls, ClW, y tal vez me olvide algún otro. ¿Podrían eliminarse de estos puntos también?

Cuando tenga un rato haré mas pruebas de la versión última del motor con el Bean Brothers que ya tiene todos los sprites llamando a las
dos funciones de color: SpriteInk y Sprite16C a ver si sigue funcionando correctamente como anoche ...
saludos
pere

[pser1]

mi gozo en un pozo
Hoy arranco el juego BeanBrothers, voy pasando de nivel despacito (pulsando 'N') y antes de llegar al final, sin haber movido un solo jugador,
aparece en algún cambio de pantalla el problema de marras
Está claro que la dirección guardada en la estructura de los sprites 'no jugadores' no se preserva en los cambios de imagen o se
sobrescribe en alguna parte. Ya tengo trabajo de investigación de nuevo
saludos
pere

[pser1]

esto ya me saca de quicio
Tengo añadidos dos controles a la rutina SpriteInk de forma que si la dirección recuperada de la estructura del sprite está fuera
de los límites de la tabla de colores para sprites ($f400-$f5ff) no haga nada, salvo guardar en RAM la dirección 'no aceptada'
Pues bien he estado jugando desde el primer nivel con esta versión y en alguno de los niveles va y aparece el error .
Pulso reset para consultar el contenido del área de RAM donde se guardan las direcciones no aceptadas y ... me encuentro que todo
está a cero. Antes de ejecutar el juego, POKEo toda el area de $7000 hasta $7100 a ceros o sea que no es culpa de la dirección
guardada en el sprite
Volveré a hacer pruebas con los dos personajes coloreándose, pero prohibiendo a los otros llamar a SpriteInk,a ver si empezando desde
el nivel 1 acaba por producirse el error también, ayer no pasaba, pero ... haberlas haylas
De hecho no me gusta nada que el SpriteInk está en el Evento de cada Sprite ya que a cada frame se llamará de promedio 10 veces
a la rutina SpriteInk, o sea 600 veces por segundo en NTSC, me parece una exageración. Creo que solamente debería llamarse cuando
cambia la imagen de un sprite ... pero si el programador en AGD se empeña en hacerlo mal, habrá que soportarlo igual, ¿No?
Adjunto el código de SpriteInk actual y de las dos rutinas llamadas.
A ver si tu que conoces mucho mejor que yo el sistema MSX2 puedes ver alguna cosa mal codificada. Ojalá

Código: Seleccionar todo

; ---------------------------------------------------------------------------------------------
SpriteInk   ldd   3,y                  ; get pointer to sprite colour table
            cmpd   #$f400               ; lower than colour table beginning?
            blo   SprInkEx               ; yes, save address and exit
            cmpd   #$f600               ; greater than colour table end?
            bhs   SprInkEx               ; yes, save address and exit
            sta    SPEED2               ; set double speed
            lbsr   DisVdpInt            ; disable V9958 interrupts
            lbsr   SetVdpWrit            ; point to that VRAM area            
            ldb   #16                  ; bytes to write
            lda   <varN                  ; get received colour value
SprInkL1      sta   ,x                     ; write one VRAM byte
            nop                        ; waste two cycles
            decb                        ; decrement counter
            bne   SprInkL1               ; not done? loop
            lbsr   EnaVdpInt            ; enable V9958 interrupts
            sta   SPEED1               ; back to normal speed
            rts                        ; return
SprInkEx      std   $7000                  ; save in RAM
            ldd   SprInkEx+1            ; get just used RAM address
            addd   #2                     ; skip used word
            std   SprInkEx+1            ; update address for next time
            rts                        ; return
; ---------------------------------------------------------------------------------------------
DisVdpInt   pshs   a                     ; save register A
            lda   #$42                   ;  0  BL IE0  M1  M2   0  SI MAG -> no screen, /IE0
            bra   ComVdpInt            ; jump to common part
EnaVdpInt   pshs   a                     ; save register A
            lda   #$62                   ;  0  BL IE0  M1  M2   0  SI MAG -> no screen, IE0
ComVdpInt   sta   PCONF                  ; send value to port #1
            lda   #$81                  ; register #1
            sta   PCONF                  ; send register to port #1
            puls   a,pc                  ; restore register and return
; ---------------------------------------------------------------------------------------------
SetVdpWrit   ldx   #PDATA               ; point to port #0
            std   <workPtr               ; save received address for later use in caller
            ldb   <workPtr               ; get high byte
            clra                        ; prepare a zero byte as high address byte
            lsld                        ; pass regB bit 7
            lsld                        ; and bit 6 to regA -> as bits 1-0 (A15-A14)
                                    ; regA now contains the address high byte
SetWR01      sta   1,x                  ; send address high byte to port#1
            ldb   #$8e                  ; get register number
            stb   1,x                  ; send it to port#1
            ldd   <workPtr               ; get received address
            stb   1,x                  ; send address low byte
            anda   #$3f                  ; discard bits 6-7 from medium byte (bit 7 must be zero, bit 6 is R/W flag)
            adda   #$40                  ; set write flag on
            sta   1,x                  ; send address medium byte with writting flag
            rts                        ; return                              
; ---------------------------------------------------------------------------------------------

[pser1]

He vuelto atrás a la versión que *NO* permite a los sprites 'enemigos' llamar a SpriteInk pero permite a los jugadores llamar a la
rutina que les pone hasta 16 olores.
He podido jugar desde el nivel 1 hasta el 20 saltándome el 16 que no se puede pasar, sin problema alguno, al finalizar vuelve a permitirte
jugar de nuevo y he hecho otra partida completa. En ningún momento se ha producido el error maligno
He parado el ordenador y mas tarde lo volveré a probar. He de probar hasta la saciedad
Aparentemente y, repito, aparentemente, la culpa la tiene la rutina SpriteInk, pero soy incapaz de encontrar un motivo para que produzca
el problema
saludos
pere

[pser1]

He probado de nuevo sin aceptar el comando SpriteInk y he jugado del nivel 1 al 20 sin problemas
Parece claro que hay que evitar esta función, pero estaría muy bien descubrir cual es el problema en su código.
El efecto visual es el que subí en una foto, pero lo peor es que el programa queda mal (stack modifiado) ya que si lo dejas
hasta que un enemigo mate a un jugador o tratas de pasar al siguiente nivel, se borra la pantalla, aparecen dos 'L' mayúsculas y el
programa ya no responde
saludos
pere

[pser1]

he probado otra táctica ...
En la rutina SpriteInk comparo la imagen nueva con la actual. Si ambas son iguales, sale sin hacer nada.
En caso de se distintas se actualiza el campo imagen actual y se envían datos al VDP
De esta forma se reduce muchísimo el número de veces que la rutina debe enviar datos, por lo que se minimizan
las posibilidades de que se produzca el error maligno
Por ahora, ha estado funcionando sin problemas las tres veces que he jugado de nivel 1 a nivel 20
Voy a mirar porqué no puedo regresar hacia arriba en el nivel 16 ...
El código actual de SpriteInk es el que sigue.
saludos
pere

Código: Seleccionar todo

SpriteInk   lda   6,y                  ; get new image
            cmpa   18,y                  ; same as current one?
            beq   SprInkEx               ; yes, exit
            sta   18,y                  ; update current image
            ldd   3,y                  ; get address of sprite colour data
            beq   SprInkEx               ; if zero, exit
            sta    SPEED2               ; set double speed
            lbsr   DisVdpInt            ; disable V9958 interrupts
            lbsr   SetVdpWrit            ; point to that VRAM area            
            ldb   #16                  ; bytes to write
            lda   <varN                  ; get calculated colour value
SprInkL1      sta   ,x                     ; write one VRAM byte
            nop                        ; waste two cycles
            decb                        ; decrement counter
            bne   SprInkL1               ; not done? loop
            lbsr   EnaVdpInt            ; enable V9958 interrupts
            sta   SPEED1               ; back to normal speed
SprInkEx      rts                        ; return

[pser1]

otra prueba mas jugando del nivel 1 hasta el 20, una vez corregido con truquillo el nivel 16 y no aparece el pantallazo maligno
Parece que al reducir la ejecución del comando SpriteInk y del Sprite16C a los cambios de imagen solamente ha solucionado
totalmente el problema
Al analizar el problema de la pantalla 16, jugué con la versión B/N y comprobé que podía escalar hacia arriba sin problemas la parte derecha
de pantalla, entonces me fijé que en otras pantallas el personaje es atraído hacia las cintas corrrederas desde la izquierda demasiado pronto, concretamente una celda. Si consideramos que horizontalmente la pantalla tiene 32, una celda o sea 8 pixels equivale sea un tile/patrón entero.
Esta prontitud hace que el jugador sea repelido una celda antes de llegar (en la pantalla 16)
Tendré que comparar las rutinas de detección de bloques actual y la antigua ...
saludos
pere

[pser1]

una vez estabilizada esta versión del motor CoCo-Dragon-MSX2 para modo G4, veré si puedo rescatar la rutina GetSlot que verifiqué, en su
momento, con el programa TESTSPEED que permite tener 16 sprites en pantalla y se pueden 'eliminar' y seguir creando mas sprites que
pasan a ocupar los 'slots' que ya no están en uso ...
Pero bueno a seguir por orden de prioridad:
a) Problema detección de bloques a demasiada distancia
b) Aplicar método GetSlot reutilizando los frames 'deshabilitados'
c) Convertir funciones de partículas
d) ???
saludos
pere

[jltursan]

¡Menudo torbellino!

Sólo una cosa, esas funciones de deshabilitar/habilitar interrupciones me resultan alienígenas. Estas deshabilitando la generación de la interrupción ligada al retrazado vertical, que tanto en un MSX (que tiene la interrupción IM1 ligada a esta interrupción del VDP) como en vuestro caso que hace que salte una NMI, permiten al procesador saber en todo momento que ha comenzado el vblank. Aparte de ser un método costoso, no se muy bien que efectos secundarios tendrá.

En un Z80 lo normal no es deshabilitar la generación de la interrupción del VDP, sino deshabilitar el tratamiento de interrupciones del Z80 mediante un DI por periodo muy breves de tiempo. Con el 6809 está chungo dado que no puedes deshabilitar la NMI; pero, ¿no podrías, en la rutina de interrupción, controlar un flag, por ejemplo "DI" , que indique que no debes hacer la lectura del registro de estado del VDP y consumir la interrupción?. Si evitas esa lectura, ya no se te pueden corromper los SetVDPWrit porque te pille justo a la mitad.
Si eso crees que puede apañarte, sería un ahorro ya que habilitarías/deshabilitarías la interrupción por software cambiando sólo una variable y no andarías escribiendo por los registros del VDP continuamente.

[pser1]

@jltursan
es que he estado todo el dia lejos del ordenador y en cuanto he podido he entrado a matar ...
Ya he corregido el error de las cintas transportadoras ... en la rutina TDed no se porqué pero utilicé el valor 32
en lugar del 31 que tenía en la versión de B/N. Solo este cambio ya ya se comportan correctamente aunque ahora son mas
complicadas en algunas pantallas
Veamos, esta es mi interrupción NMI para 6809/6309
La verdad es que no es muy molesto enviar dos bytes al VDP para deshabilitar las /FS. Envio $42 ó $62 al R#1.
En principio todo el código se debería estar ejecutando durante el período de blanqueo de pantalla así que no se debería 'saltar' ninguna interrupción. Los sonidos/música lo notarían. Hasta ahora efecto negativo ninguno, tuve muchos cuando no los deshabilitaba ...
Si se le permite generar interrupciones entonces el sistema llama a la rutina NewNMI que debe borrar el flag de interrupción o no llegaría
ninguna otra mas ...
saludos
pere

Código: Seleccionar todo

NewNMI      ldx   #PDATA               ; point to VDP port #0
            ldd   #$008f               ; ask for S#0 to R#15
            sta   1,x                  ; send status register number
            nop                        ; *** ADDED TO HELP VDP GET BYTES ***
            stb   1,x                  ; send register number to port #1
            nop                        ; *** ADDED TO HELP VDP GET BYTES ***
            lda   1,x                  ; read port #1 to clean flag
            inc   >TIMER               ; increment high byte
      IF (YFLAG || EFLAG)            ; if Music or Effects are enabled
            lbsr   PsgrOut               ; send the registers to the YM-2149
         IF YFLAG                     ; if Music enabled
            lbsr   Music_Play            ; play a music frame
         ENDIF
         IF EFLAG                     ; if effects enabled
            lbsr   Sfx_Play               ; play a sound frame
         ENDIF
      ENDIF
NewNMIEx      rti                        ; return from interrupt

[jltursan]

Cachis, cuanto más miro, más me extraño

La lectura del VDP ligada a la interrupción no se hace mediante el mecanismo habitual del V9938, te bastaría con el "ld a 1,x" para leer el port #1. Supongo que el resto del código no afecta demasiado; pero diría que no deberías necesitarlo.
Por cierto, en el Dragon, ¿la NMI sólo te va a llegar gracias al VDP?.

Volviendo a las rutinas que comentabamos, el problema que les veo es que me parecen una pescadilla que se muerde la cola. ¿Que pasa si antes de finalizar EnaVdpInt (antes del último "sta PCONF" por ejemplo) te llega la interrupción que pretendías desactivar?.

[pser1]

Cachis, cuanto más miro, más me extraño
La lectura del VDP ligada a la interrupción no se hace mediante el mecanismo habitual del V9938, te bastaría con el "ld a 1,x" para leer el port #1. Supongo que el resto del código no afecta demasiado; pero diría que no deberías necesitarlo.

¿Quieres decir que no hace falta indicarle a la máquina que quieres el estado del registro S#0? No veo porqué el sistema debe devolverme precisamente en lugar del S#1, S#2 u otro
De hecho, según manual debo enviar al R#15 el registro de status que quiero consultar y solo luego debo leer el port#1 ...

Por cierto, en el Dragon, ¿la NMI sólo te va a llegar gracias al VDP?.

Efectivamente, Dragón podría generar IRQ a cada /FS pero serían PAL ya que el MC6847 solo trabaja en modo PAL, en el CoCo sería NTSC si es americano ... Para unificar, decidí utilizar la interrupción que genera el V9958, que por diseño de la placa se envia a la entrada NMI de la CPU

Volviendo a las rutinas que comentabamos, el problema que les veo es que me parecen una pescadilla que se muerde la cola. ¿Que pasa si antes de finalizar EnaVdpInt (antes del último "sta PCONF" por ejemplo) te llega la interrupción que pretendías desactivar?.

Entiendo que te refieres a DisVdpInt, pues si llega antes de finalizar ... ni idea de lo que pueda suceder, desde que el NewNMI no consiga leer el estatus para borrar el flag, cosa que podría dejar a la máquina sin interrupciones o lo que te puedas imaginar.
En la práctica no ha pasado nunca y mira que se llega a llamar veces a estas subrutinas ... supongo que es muchísimo mas probable que llegue
cuando la CPU está en otros menesteres que justamente deshabilitando interrupciones.
Pero esta situación puede pasar en cualquier programa que tenga una rutina para deshabilitar interrupciones y tenga mas de 1-2 operaciones
saludos
pere

[pser1]

En Dragón normalmente se bloquean las interrupciones con un único opcode: orcc #$50
Pero esto solo a afecta a IRQ y a FIRQ. El NMI como su nombre indica no es 'maskable' por lo que se llama *siempre* a su rutina
de servicio ... vamos, que es imparable
Solo bloqueando el hardware que genera la interrupción que es enviada a la patilla NMI de la CPU se puede evitar su generación
Y en el V9958 parece que solamente deshabilitando /FS en R#1 tiene dicho efecto (pasando a cero el bit IE0)
saludos
pere

[pser1]

el segundo punto de mi 'lista', lo de añadir el GetSlot espero poder hacerlo hoy.
Ayer se me ocurrió añadir en el bucle principal del motor un poco de código para mostrar en la línea 24 el número de sprites creados
y el número de frames usados (en la tabla de slots)
Así pude ver que cuando se cambia de imagen (por necesitar mas frames que la actual), se deshabilita la entrada en la tabla en RAM de sprites
sprTab que tiene espacio para 16 y además se deshabilita la entrada de atributos y colores en las tablas de sprites en VRAM
Pero, se crea otra a continuación de la última utilizada en VRAM, con lo cual se podría llegar a dar el caso de ocupar secuencialmente las
32 entradas de VRAM. Si esto sucediera, el motor, defensivamente, ya controlaba si se pasaba del límite, entonces el sprite no era creado.
Esto no ha sucedido nunca hasta ahora, pero con el programa de pruebas TESTSPEED sería muy fácil hacer que pase, simplemente creando
muchos sprites, eliminándo algunos y creando nuevos una y otra vez ...
Para evitarlo, he añadido una variable al sistema "reUseSpr" que permite avisar a la rutina SendSprite para que sepa si tiene que *reutilizar*
las entradas actuales del sprite en VRAM o bien crear nuevas entradas al final ...
No ha sido muy complicado ya que solo requieren este control LoadSprt (inicio de pantalla), UpdImage (puede ser mayor o no) y Spawn
Como ya tengo la parte que agrupa slots ya no en uso, en cuanto GetSlot esté implementado, creo que ya habrá protección total contra
accidentes por exceso de sprites creados/borrados
saludos
pere

[pser1]

he estado probando y comparando los contadores de sprites y frames entre dos versiones,
la VDPE401D que no recupera slots en VRAM para Colores/Atributos
la VDPE402D que si lo hace, la diferencia se puede ver en las pantallas donde se necesitan imágenes que ocupan mas que la anterior
y en una versión generan nuevo slot en VRAM, mientras que en la otra no lo hacen

...........VDPE401D............VDPE402D	
Screen	SprtCnt	framCnt	  SprtCnt  framCnt
4	7(8)	27(32)	  7	   27(32)
10	9(11)	35(40)	  9	   35(40)
11	8(10)	25(34)	  8	   25(34)
14	9(12)	29(44)	  9	   29(44)
16	8(9)	30(35)	  8	   30(35)
17	8(9)	28(33)	  8	   28(33)

Podéis ver que para la VDPE401D el número de sprites aumenta (indicado entre paréntesis), mientras que para la VDPE402D no cambia para
nada ya que controla estas situaciones y reusa en espacio del anterior sprite en VRAM

Esta es la parte buena, la mala noticia es que cuando he querido re-verificar el nivel 11, al pasar muy rápidamente de nivel, he conseguido
que se diera el error maligno ... pantalla llena de basura y programa bloqueado ...
Esto significa que mi sistema de reducir al mínimo las ocasiones en que se llama a SpriteInk funciona bastante bien, pero sin ser una seguridad
al 100%. Lo cierto es que Bean Brothers tenía en la versión B/N un retardo importante cuando querías saltar un nivel y aquí, por prisas he
reducido este retardo a la quinta parte. Tal vez esto esté propiciando el error. Tendré que seguir haciendo pruebas además de tratar de
comprender mejor el sistema de interrupciones del VDP que, presumiblemente, está relacionado con este error
De todas formas voy a añadir el GetSlot para reaprovechar los slots anulados en la tabla de frames en RAM
saludos
pere

[jltursan]

La verdad es que el hecho de que esté ligado a una NMI es una faena. ¿Es un imponderable cuando se trata de periféricos en el Dragon, están siempre ligados a la NMI o es una decisión de diseño de la tarjeta V9958?