motor AGD para V9958 modo gráfico G4 para HD6309

[pser1]

Último mensaje de la página anterior:

y para rematar la jugada, una rutina que partiendo de los ocho bytes de un carácter nos creará los 32 necesarios en modo G4
para enviarlos a pantalla mediante un comando HMMC
Cualquier comentario será bien recibido!
saludos
pere

Código: Seleccionar todo

; asumiendo que regX apunta al principio de datos del carácter a enviar a pantalla
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FillBuff   ldu   #TabCol      ; puntero a la tabla de 4 combinaciones antes descrita
         ldy   #Result      ; tabla resultados (32 bytes)
         ldf   #8            ; bytes del carácter
Loop1      lde   #4            ; 4 bytes por línea (font byte)
         ldb   ,x+         ; lee un byte del patrón y apunta al siguiente
Loop2      clra               ; índice a cero
         lsld               ; envia 2 bits de la izquierda de regB
         lsld               ; a regA
         lda   a,u         ; recupera valor de este índice de la tabla TabCol
         sta   ,y+         ; guarda byte en buffer, avanza puntero
         dece               ; decrementa contador de pares de pixels
         bne   Loop2         ; no acabado? bucle atrás para el siguiente par de pixels
         decf               ; decrementa contador de bytes
         bne   Loop1         ; no acabado? bucle atrás para el siguiente byte
         rts               ; retorna   
Result   rzb   32            ; espacio para los 4x8 bytes del carácter en modo G4
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; Una vez llenados los 32 bytes se puede llamar al comando HMMC



[jltursan]

La cuestión es, ¿si preprocesas todo y HMMC sólo se dedicará a enviar los bytes, eso no te obliga a emplear por fuerza el chequeo del bit TR entre envío y envío?, ¿lo has llegado a probar con y sin "freno"?.

[pser1]

La cuestión es, ¿si preprocesas todo y HMMC sólo se dedicará a enviar los bytes, eso no te obliga a emplear por fuerza el chequeo del bit TR entre envío y envío?, ¿lo has llegado a probar con y sin "freno"?.

Hola José Luis,
de hecho tengo anotado en mis papeles que en cuanto se calcule un byte con los colores de dos pixeles ya se podría enviar al
comando HMMC pero de momento lo estoy implementando como he escrito aquí. Primero calculo los 32 bytes y luego llamo al HMMC
En cuanto funcione, que ya sería un gran paso, lo probaré de forma que esta rutina sea parte del HMMC ... o quizás no
Como el BChar va a tener que dibujar 64 bytes (doble altura) tendré que ver si puedo aprovechar algo de este código ...
De hecho en BChar habría que enviar 4 bytes dos veces y luego a por los 4 siguientes dentro del HMMC
Será cuestión de meditar un poco al respecto
saludos
pere

[pser1]

de momento, tras la primera prueba, una sola cadena: FOGGY;QUEST
y nada de esto en pantalla, en su lugar cosas sobrescritas en la misma posición ...
Tengo trabajillo para depurarlo, primero sobre papel a ver cuantos gazapos encuentro
saludos
pere

[pser1]

vaya gazapo!
No estaba informando el inicio de pantalla para cada carácter (esquina arriba izquierda), por esto se superponían todas las letras
Ahora va perfecto, puedo garantizar que el método indicado antes aplica correctamente los colores deseados
A velocidad normal (0,89 MHz) se ve como va pintando la pantalla (cortina) aunque solo con pasar a doble velocidad (1,78 MHz)
el resultado es perfectamente aceptable y por cierto, pasando del bit TR, como hay código entre byte y byte, la VDP es lo
suficientemente rápida como para soportar al 6309 a doble velocidad!
Ya trataré mas adelante de ver si se puede acelerar este proceso, tal vez tengo demasiadas llamadas a subrutinas.
Por lo menos PChar ha de ser agilizado al máximo ...
saludos
pere

[pser1]

unos pocos retoques, pero nada importante. No parece que le pueda apretar las clavijas mas ni a PChar ni a las subrutinas
auxiliares. De hecho he posicionado la DoHMMC justo a continuación de PChar para evitar una llamada a SBR y a pesar de todo
se podría reutilizar .. si hiciera falta
Una imagen (mala gracias al fotógrafo) vale mas que 100 palabras
Ahora a por el texto a doble altura ... y tal vez a por el texto desplazándose hacia la izquierda
saludos
pere

Texto-AGD-V9958-HD6309.jpg (85.32 KiB) Visto 401 veces

[pser1]

el texto a doble altura ha resultado extremadamente sencillo.
El código de Bmsg0 lo he eliminado y el de Dmsg0 decide si llama a PChar o a BChar según el tamaño requerido.
No he querido unificar PChar y BChar porqué con esta máquinas que van a tan pocos MHz es mejor, muchas veces, tener el código
repetido con pequeñas diferencias, que tener todo en una rutina con varias condiciones para decidir donde ir o que hacer.
Ahora, a por el texto desplazándose, ya veremos si resulta tan simple, me temo que no va a ser el caso
En todo caso cuando funcione ya será hora de hacer un video para, además de la presentación poder pasearse por
todas las pantallas viendo los tiempos de transición de una a otra ...
saludos
pere

[pser1]

buenas tardes,
de nuevo pensando en como hacer el texto que se desplaza hacia la izquierda ...
No estoy seguro del método que empleas en tu motor para MSX2, así que estoy pensando en hacer un HMMM con toda la anchura
de la ventana menos un pixel, empezando por el segundo pixel de la izquierda hasta el último de la derecha y moviendo este bloque
directamente un pixel a la izquierda sobrescribiendo el pixel de mas a la izquierda (que desaparece) y una vez hecho esto, pintar
un pixel justo en el de mas a la derecha, eso es enviar 8 ó 16 bytes con un HMMC
El pequeño escollo es que este píxel va a necesitar un procesado cuidadoso ya que estaré usando el mismo byte del mensaje ocho veces
y luego a por el siguiente y al pasar del último, volver al primero. Como solo se pueden enviar a la VDP bytes enteros, lo que se envíe
con el HMMC tendrá que ser bytes con el nibble de la izquierda representando al bit del carácter en curso y ceros a la derecha.
Realmente esto es pura elucubración, el siguiente paso va a ser escribir código para controlar esta última parte que me parece justo
el meollo de la función ya que el HMMM será siempre el mismo con los mismos parámetros!
Cualquier idea/sugerencia será muy bienvenida
saludos
pere

[jltursan]

Básicamente es eso, un scroll hacia la izquierda empleando un HMMM, lo podrás encontrar así en mi código. Recuerda lo de los 2px que comentábamos, no se puede hacer un scroll de 1px únicamente.

¡Estás cogiendo el ritmo!

[pser1]

Básicamente es eso, un scroll hacia la izquierda empleando un HMMM, lo podrás encontrar así en mi código. Recuerda lo de los 2px que comentábamos, no se puede hacer un scroll de 1px únicamente.
¡Estás cogiendo el ritmo!

gracias por confirmármelo, le echaré una ojeada al código Z80
Para el motor G3 recuerdo que hacia un shift left concatenado desde el primer byte de la izquierda hasta el último a la derecha en cada una
de las 8/16 filas que ocupaban.
Como no quise 'desperdiciar' memoria para crear un buffer tan grande, utilicé el área de memoria de pantalla de textos de $400 a $5ff
de forma que cuando había texto desplazándose, la pantalla del MC6847 se volvía loca con los shift lefts
Ciertamente fue un error empezar con el modo G3, me dejé arrastrar por el mero hecho de que soporta tiles y así era la base de datos de
los juegos AGD para Spectrum. Lo cierto es que todas las rutinas para modo G4 para mostrar texto han reducido el tamaño del binario en
mas de 1Kb, que hablando de ensamblador no es poca cosa
Se me avecinan unos días muy cargados de trabajos caseros así que, muy probablemente, tarde en colgar aquí el prometido video que muestre
hasta donde funciona el nuevo motor en modo G4 para el HD6309 y la tarjeta MSX2+ de John Whitworth, pero trataré de hacerlo cuanto antes,
dentro de lo posible.
saludos
pere

[pser1]

Básicamente es eso, un scroll hacia la izquierda empleando un HMMM, lo podrás encontrar así en mi código. Recuerda lo de los 2px que comentábamos, no se puede hacer un scroll de 1px únicamente.

Con las prisas no me había percatado de este comentario, es cierto que indican claramente que el bit mas bajo es omitido en G4, por tanto
hay que hacer una copia dos pixels a la izquierda, pero con esto, ¿No se acelerará demasiado el scroll?
Me ha parecido ver que tu haces el scroll solo una de cada dos llamadas a la rutina, ahora entiendo que es precisamente para desacelerar el movimiento.
En el fondo me alegro porque para enviar dos pixels basta un byte de modo G4, que ya lo tengo programado para el texto normal, o sea que,
en el peor de los casos, será un cortar y pegar
Tiene buena pinta este proyecto
saludos
pere

[jltursan]

Exacto, es lo que te comenté en un mensaje anterior, que por culpa de pasar a un scroll de 2px, tuve que desacelerar el scroll haciéndolo cada 2 frames. No queda mal y la versión MSX2 ha quedado mucho mejor ya que resulta mucho más económica (no empleo buffer para rotar los bytes) y potente, ya hago scroll de fuentes de doble altura

No creo que John tenga tampoco mucha prisa, tiene que estar encantado con lo que le vayas enseñando

[pser1]

Exacto, es lo que te comenté en un mensaje anterior, que por culpa de pasar a un scroll de 2px, tuve que desacelerar el scroll haciéndolo cada 2 frames. No queda mal y la versión MSX2 ha quedado mucho mejor ya que resulta mucho más económica (no empleo buffer para rotar los bytes) y potente, ya hago scroll de fuentes de doble altura

Tendré que echar una ojeada al método que has utilizado ya que de entrada no veía otra solución que preparar los 32/64 bytes e irlos
utilizando cada dos /FS y al usar los últimos 4, llamar de nuevo al 'cargador' del buffer. O peor todavía, tener un buffer para contener el carácter
en curso e irlo procesando de dos pix en dos pero cada proceso crea 4 bytes y mi HMMC actual echa mano del buffer de 64 caracteres y los
envía del tirón sin reparar en el bit TR y a doble velocidad!
Ya he visto que tenias en cuenta el modo y envías el doble o no de bytes, una mejora importante
saludos
pere

[pser1]

@jltursan,
me he pateado las rutinas scrly, scrltxt, buildcol y iscrly y de paso las he ido comentando línea a línea para entender mejor lo que hacen
Hay algunas instrucciones de Z80 que todavía me obligan a abrir el pdf que las explica.
Resumido en pocas palabras, perfecto
Espero poder hacer algo parecido con el 6309, solo que trataré de utilizar mis rutinas de llenado de tabla de colores (las 4 posibilidades)
y me haré una variante del llenado de 4x8 ó 4x16 bytes para que solo haga 1x8 ó 2x8 ya que procesamos 2 pixels en lugar de 8
Veo que has preferido usar el sistema de escritura directa via puntero en lugar de usar el HMMC
¿Crees que es mas rápido a pesar de tener que reposicionar el puntero para cada byte?
saludos
pere

[jltursan]

Probablemente no en el caso de los 16 bytes de alto; pero dado que hay que inicializar un HMMC y gestionarlo, pues tampoco esperaba que la diferencia fuese tan grande. Igual compensa pero diría que muy poco para el lío que supone...

[pser1]

buenas tardes,
al final me he decidido por un HMMM para el desplazamiento a la izquierda del bloque de texto y un HMMC para enviarle el par de pixels
nuevos por la derecha.
La rutina IScrly la he modificado para que rellene los parámetros de los dos comandos VDP y luego la Scrly que es llamada cada dos /FS
gestiona la extracción de los bits de la izquierda, los convierte en bytes con los colores calculados de la tabla que ya usé para PChar
y llama a los dos comandos VDP. Funciona que ya es mucho, de hecho debo admitir que ahora el movimiento lateral me va a doble velocidad
que antes a pesar de llamar la rutina cada 2 interrupciones verticales. He probado a dividir otra vez por dos, pero entonces, para mi gusto
se sincroniza con la frecuencia del NTSC y como movemos dos píxels a la vez, da la impresión de querer parpadear.
Lo voy a dejar a doble velocidad respecto al sistema anterior ... ya lo veréis cuando suba el video.
De momento me toca revisar la impresión de números. Display funciona pero me pinta en negro el espacio delante de la primera cifra
cuando debería ser un bloque de color azul (color de fondo)
Bien, otro paso adelante!
saludos
pere

[pser1]

Buenos días,
he decidido mantener en el motor la pequeña parte de código que añadí para pasar de una pantalla a otra sin jugar.
Ahora se compilará si DEBUG vale 1.
Se sale de la demo pulsando Break y pulsando Enter, el programa se posiciona en la primera pantalla del juego y ya se puede jugar

Bugs encontrados a partir de este momento:
- La rutina que hace parpadear las puertas no ha sido actualizada por despiste
- Al tocar Foggy un Objeto, el programa se 'cuelga', o sea a revisar RemoveObj y/o GetObj
Como los sprites siguen igual que en modo G3, se mueven perfectamente en todas las pantallas ... un trabajo menos
Hasta la próxima
saludos
pere