Comandos especiales en el V9958

Avatar de Usuario
pser1
Mensajes: 3154
Registrado: 08 Dic 2012 18:34
Agradecido : 784 veces
Agradecimiento recibido: 799 veces

Comandos especiales en el V9958

Mensajepor pser1 » 09 Feb 2021 19:42

Buenas tardes,
he estado probando a utilizar las funciones/comandos especiales como POINT, LINE y HMMV (llenar un área de pantalla en plan PCLS)
- El HMMV funciona en *todos* los modos gráficos, como MC,G1,G2,G3,G4,G5.G6 y G7 sin problema en ninguno de ellos a pesar de que los cuatro primeros requieren que se ponga a 1 el bit 6 de R#25 ya que con el V9938 no se admite hacerlo.
- Las otras dos funciones para dibujar puntos o trazar líneas solamente me funcionan en los modos que trabajan con mapa de bits.
Los otros modos que utilizan tiles/patrones fracasan estrepitosamente.
No tengo claro si estoy haciendo algo mal o si me estoy olvidando algún paso ... Me sorprende que, por ejemplo, en modo G3 el V9958
sea capaz de llenar la pantalla con el color que uno quiera, pero que sea incapaz de 'pintar' una simple línea -banghead
Los fuentes de los programas que utilizan el modo G3 son prácticamente idénticos a los del G4 solamente cambiando unos pocos bytes
en la rutina que pasa al modo gráfico en cada uno de ellos.
Adjuntaré mas adelante en otro mensaje los fuentes de los modos G3 y G4 con la función PSET por si alguien tiene la paciencia de echarles
una ojeada comparándolos y consigue encontrar el gazapo que se me está escapando ....
La verdad es que yo esperaba poder emplear las funciones POINT y PSET para añadir las funciones de 'shrapnel' al motor AGD para V9958
Si esto no es posible, representa un torpedazo en la línea de flotación de esta variante de motor AGD
No me parece una buena solución cambiar a modo G4 con la misma resolución y número de colores pero perdiendo los patrones/tiles
ya que implicaría un cambio muy grande en la rutina de carga de pantallas y en todo el follón que yo me he organizado para ir creando patrones
nuevos para el menú inicial y para el inventario ... Sería una revisión muy profunda ... espero no tener que llegar a este punto -banghead
Cualquier sugerencia/idea será super bien recibida -nb
saludos
pere

Avatar de Usuario
pser1
Mensajes: 3154
Registrado: 08 Dic 2012 18:34
Agradecido : 784 veces
Agradecimiento recibido: 799 veces

Re: Comandos especiales en el V9958

Mensajepor pser1 » 09 Feb 2021 20:13

adjunto los fuentes de los ejemplos en modo G3 y G4
saludos
pere
POINT G3-G4.zip
(6.81 KiB) Descargado 3 veces

jltursan
Mensajes: 3429
Registrado: 20 Sep 2011 13:59
Agradecido : 336 veces
Agradecimiento recibido: 947 veces

Re: Comandos especiales en el V9958

Mensajepor jltursan » 10 Feb 2021 09:41

Pues me temo que no. Los comandos del VDP sólo están preparados para funcionar correctamente en los modos G4 a G7 (los modos bitmap estandar).

Aunque el V9958 ya no impide, el uso de los comandos en modos de patrones, sólo los de tratamiento de bloques son útiles y eso haciendo malabarismos mentales ya que habría que convertir siempre del sistema de coordenadas cartesianas con el que trabaja el VDP, al almacenamiento lineal de la VRAM. Con las pruebas reales que ya has hecho, igual puedes confirmar si es necesario hacer esas transformaciones o también entiende de coordenadas en modo G3.
Esas transformaciones en el caso de los comandos de puntos/líneas deben de ser mortales ya que probablemente, el VDP no calcule correctamente las cosas.

La solución es simple, emplea el mecanismo estandar a la hora de pintar un píxel, la CPU ;-)

Avatar de Usuario
pser1
Mensajes: 3154
Registrado: 08 Dic 2012 18:34
Agradecido : 784 veces
Agradecimiento recibido: 799 veces

Re: Comandos especiales en el V9958

Mensajepor pser1 » 10 Feb 2021 12:23

jltursan escribió:Pues me temo que no. Los comandos del VDP sólo están preparados para funcionar correctamente en los modos G4 a G7 (los modos bitmap estandar).
Aunque el V9958 ya no impide, el uso de los comandos en modos de patrones, sólo los de tratamiento de bloques son útiles y eso haciendo malabarismos mentales ya que habría que convertir siempre del sistema de coordenadas cartesianas con el que trabaja el VDP, al almacenamiento lineal de la VRAM. Con las pruebas reales que ya has hecho, igual puedes confirmar si es necesario hacer esas transformaciones o también entiende de coordenadas en modo G3.
Esas transformaciones en el caso de los comandos de puntos/líneas deben de ser mortales ya que probablemente, el VDP no calcule correctamente las cosas.
La solución es simple, emplea el mecanismo estandar a la hora de pintar un píxel, la CPU ;-)
Gracias, José Luis
He comprobado que PSET y LINE fracasan estrepitosamente. No perderé mas tiempo tratando de averiguar que es lo que modifica en realidad
la VDP al recibir estos comandos en modo G3 o inferiores.
Estaba pensando seriamente en pasarme al modo G4 y copiar los tiles en las 64K altas así podría copiarlos luego llamando al comando mas rápido
que permita a la VDP copiar de VRAM a VRAM. No estoy seguro de que los módulos de John salgan todos con 192Kb así que de entrada no voy
a contar con guardar tiles en Extended RAM y luego copiar hacia la VRAM
Respecto al método de usar la CPU para dibujar los 'puntos' del shrapnel en mi caso se complica demasiado ya que yo no tengo un tile para cada uno de los 768 bloques de pantalla. Si un tile se emplea 20 veces, solo tengo uno en la tabla de tiles (en cada tercio de pantalla) y por tanto tendría que andar haciendo copias para cada punto y luego dejar el código anterior al borrarlos ... El modo G4 me permitiría hacer un PSET con operación lógica XOR de forma que la segunda vez borraría el punto sin necesidad de guardar lo que había antes ...
Todo es pura entelequia, necesito hacer una prueba de carga de tiles y modificar la rutina que de momento solo envia 768 bytes al VDP
y en su lugar hacer 768 llamadas a la función de copia que elija. Obviamente si se puede hacer suficientemente rápido, abre la puerta a
diseños de tiles con 16 colores individualmente para cada pixel, lo mismo para los objetos. Solo los sprites se quedarían con 1 color por fila
Ya iremos hablando, estoy seguro de que me surgirán muchas dudas a lo largo de la prueba, para la que utilizaré el Foggys Quest
saludos
pere

jltursan
Mensajes: 3429
Registrado: 20 Sep 2011 13:59
Agradecido : 336 veces
Agradecimiento recibido: 947 veces

Re: Comandos especiales en el V9958

Mensajepor jltursan » 10 Feb 2021 16:33

Vaya faena, tienes razón. Tu empleabas tiles "puras" para construir la pantalla y por tanto, el iluminar o apagar píxeles individuales es una auténtica locura. De pasarte a G4 o emplear G2 con los 768 tiles preasignados (lo que empleo yo) ya no tendrías problemas, claro.

Avatar de Usuario
pser1
Mensajes: 3154
Registrado: 08 Dic 2012 18:34
Agradecido : 784 veces
Agradecimiento recibido: 799 veces

Re: Comandos especiales en el V9958

Mensajepor pser1 » 10 Feb 2021 20:02

Sigo estudiando el tema de trabajar en modo G4 (256x192 a 16 colores por pixel sin limitaciones)
Para convertir los juegos AGD que contienen tiles definidos en 8x8 (píxels ancho x alto) y 8 bytes de color
que para el modo bitmap se tiene que convertir en cuatro bytes de anchura (cada uno con el color de dos píxels) x 8 líneas
con lo cual pasamos de 16 bytes (8+8) a 32 bytes por 'tile'. Y esto afectará también a las 'fonts'
Si 200 tiles mas letras ocupaban 3200 bytes ahora pasaríamos a 6400 si la transformación se lleva a cabo en el compilador
Podríamos hacer el trabajo una vez al cargar el juego convirtiendo sobre la marcha cada tile/font a su formato G4
Posiblemente me decantaré por la segunda opción ya que la primera implica muchos cambios en el compilador y mas espacio desperdiciado
en el binario del programa creado.
Asumiendo que estos tiles/fonts en formato G4 se envían a las 64K altas de VRAM, luego para copiar cada una al dibujar la pantalla
habrá que usar el comando HMMM moviendo 8x8 píxels que implicarán la copia de 32 bytes.
Las 768 tiles requieren 24.576 bytes. Tengo que hacer la prueba para ver si esto es muy visible en Foggy al pasar de una pantalla a otra.
Lo que tengo que ver es como envío los datos al VDP. No se si será mejor utilizar el comando HMMC que permitiría montar en la VRAM las
tiles cada 8 pixels y en 8 filas o bien pringar y enviar los datos usando el puntero a la VRAM aunque como el puntero se mueve linealmente
tendría que enviar bloques de 32 tiles una fila de cada uno en secuencia (128 bytes = 256 píxeles) para que queden bien alineados y se puedan
copiar a pantalla en bloques de 8x8 píxeles mas tarde.
saludos
pere

jltursan
Mensajes: 3429
Registrado: 20 Sep 2011 13:59
Agradecido : 336 veces
Agradecimiento recibido: 947 veces

Re: Comandos especiales en el V9958

Mensajepor jltursan » 10 Feb 2021 21:17

Lo bueno (y lo malo) es la inmensa cantidad de posibilidades y combinaciones que ofrece ese modo junto con el VDP :-)

Como verás, es muy importante planificar la estrategia para cada tipo de elemento. En el caso que mencionas de la fuente, hay un factor extra de complejidad, la tinta y el papel son seleccionables...empiezan los problemas -banghead

De todas formas yo ya tengo portado el AGD a G4 así que puedo ofrecerte la arquitectura que empleo y analizas que te conviene o que no.

Avatar de Usuario
pser1
Mensajes: 3154
Registrado: 08 Dic 2012 18:34
Agradecido : 784 veces
Agradecimiento recibido: 799 veces

Re: Comandos especiales en el V9958

Mensajepor pser1 » 10 Feb 2021 22:19

jltursan escribió:Lo bueno (y lo malo) es la inmensa cantidad de posibilidades y combinaciones que ofrece ese modo junto con el VDP :-)
Como verás, es muy importante planificar la estrategia para cada tipo de elemento. En el caso que mencionas de la fuente, hay un factor extra de complejidad, la tinta y el papel son seleccionables...empiezan los problemas -banghead
De todas formas yo ya tengo portado el AGD a G4 así que puedo ofrecerte la arquitectura que empleo y analizas que te conviene o que no.

Creo que con las fuentes ya habíamos pasado por esto. Hay una variable que contiene 16*Tinta + Papel. En la versión para MC6847 creo que
las letras se definen con color (a unos) y fondo (a ceros) y antes de pintarlo en pantalla se le hace una doble operación OR-AND o algo parecido
con lo que podíamos tener los cuatro colores (00-01-10-11) Supongo que aquí podría hacerse algo parecido. De hecho ahora las letras están
definidas en blanco y negro y se les aplican los colores desde una variable vdpCol ...
Me parece una buena idea echar una ojeada a tu versión para G4. Seguro que encuentro muchas ideas e incluso código directamente utilizable
tras convertirlo al 6309, claro!
Que has preferido, ¿Trabajar con comandos VDP o manejando los bitmaps por soft?
saludos

jltursan
Mensajes: 3429
Registrado: 20 Sep 2011 13:59
Agradecido : 336 veces
Agradecimiento recibido: 947 veces

Re: Comandos especiales en el V9958

Mensajepor jltursan » 11 Feb 2021 09:10

Excepto las partículas, todo funciona mediante comandos de VDP.

Lo apaño un poco y en cuanto pueda te lo paso por si quieres examinarlo.

Avatar de Usuario
pser1
Mensajes: 3154
Registrado: 08 Dic 2012 18:34
Agradecido : 784 veces
Agradecimiento recibido: 799 veces

Re: Comandos especiales en el V9958

Mensajepor pser1 » 11 Feb 2021 11:24

jltursan escribió:Excepto las partículas, todo funciona mediante comandos de VDP.
Lo apaño un poco y en cuanto pueda te lo paso por si quieres examinarlo.

muchas gracias, de verdad te lo agradeceré un montón.
Estaba pensando en cambiar el formato de la tabla bCol que pasa el compilador.
Ahora me llega el mismo valor 8 veces (uno por fila) con Tinta y Fondo
Se me ocurre reducirlo a la mitad enviando: 2x Fondo, Fondo y Tinta, Tinta y Fondo, 2xTinta o sea cuatro bytes solo
Esto sería utilizable directamente según el contenido de cada dos bits: 00,01,10,11 aprovechando la facilidad de
indexación del 6309, pero son simples elucubraciones. La otra alternativa sería recibir directamente los 4 bytes por fila
de cada tile desde el compilador. Ocuparía justo el doble pero probablemente sea aceptable y permitiría subir los valores
a la VRAM más rápidamente ...
saludos
pere

Avatar de Usuario
pser1
Mensajes: 3154
Registrado: 08 Dic 2012 18:34
Agradecido : 784 veces
Agradecimiento recibido: 799 veces

Re: Comandos especiales en el V9958

Mensajepor pser1 » 12 Feb 2021 17:40

Hola,
he estado currando con el compilador hasta que he conseguido que genere el fichero ASM enviando a la tabla de patrones chgFx
32 bytes para cada patrón, 8 por cada fila como necesita el modo G4. Pelín enrevesado, pero me ahorraré muchas operaciones en el 6309
y la verdad es que el fichero binario para el Foggy solamente ha aumentado de tamaño unos 1280 bytes
Ahora miraré si puedo hacer otro tanto con las letras/signos de las fuentes para ir viendo el tamaño total de Foggy ... mi juego de control ;-)
De todas formas me parece un espectáculo tener que enviar 80 patrones mas 96 signos cada uno con 32 bytes desde la memoria RAM
hacia la VRAM que hará de tabla de patrones, unos 5.632 bytes enviados de uno en uno al comando HMMC además debiendo mirar
el bit TR antes de enviar cada byte. Alucinante si a pesar de estos requerimientos funciona razonablemente rápido ...
Y sin olvidar que los objetos está formados por cuatro patrones que deberán ser enviados también por el mismo método.
saludos
pere

jltursan
Mensajes: 3429
Registrado: 20 Sep 2011 13:59
Agradecido : 336 veces
Agradecimiento recibido: 947 veces

Re: Comandos especiales en el V9958

Mensajepor jltursan » 12 Feb 2021 19:17

Te voy contando un poco como organizo los datos para el modo G4. Con unas capturas lo verás más claro.

Yo parto de un MSX2 con 64KB de VRAM mínimo, por lo que sólo me planteo usar dos páginas en G4:

Foggy_page1.jpg
Foggy_page1.jpg (69.33 KiB) Visto 212 veces

Definiendo el alto a 192px, dispongo todavía al final de la página de 8 filas de 32 caracteres cada una para almacenar bloques. Dicho y hecho, ahí los guardo, caben justos los 256 que tiene como máximo el AGD.
En la página 1 de la VRAM se almacenará pues la pantalla principal de juego y los bloques. He cambiado los punteros de los sprites de manera que ya no residen aquí.

Foggy_page2.jpg
Foggy_page2.jpg (26.3 KiB) Visto 212 veces

En la página 2 almacenaré al comienzo de la misma los objetos. De momento no defino límite, tampoco espero que haya juegos con 256 objetos, debería plantearme un límite de unos 192 que entrarían justos en 192px, dejando libre VRAM suficiente para gestionar los sprites y quizá alguna cosilla más.

Así pues, los bloques y los objetos se envían a pantalla mediante HMMM, los textos se imprimen mediante HMMC ya que guardo la font en RAM y la manipulo al vuelo y los sprites funcionan de forma similar a como lo hacían en MSX1, cargo en VRAM los necesarios en todo momento, empleando la CPU pura. El HMMC es lento pero algo más rápido que la CPU pura, el bit TR, si la CPU no es un relampago podría llegar a obviarse; pero ya sabes, si usas un 6309 a doble velocidad, igual la CPU envía el siguiente byte antes de que el VDP haya acabado; en un MSX parece que eso no suele pasar (aunque tampoco me fío y ahora mismo leo el estado).

En tu caso; pues todo depende de que datos gráficos quieras cargar y como los organices.

Avatar de Usuario
pser1
Mensajes: 3154
Registrado: 08 Dic 2012 18:34
Agradecido : 784 veces
Agradecimiento recibido: 799 veces

Re: Comandos especiales en el V9958

Mensajepor pser1 » 12 Feb 2021 20:17

Hola José Luis,
esto es fabuloso y muy ingenioso, felicidades!!
Y muchas gracias por compartir las ideas y las fotos ...
Efectivamente, los juegos usarán la resolución de 256x192 como en modo G3
Como la pantalla de juego tiene 192x128=24576 bytes entiendo que te refieres a que reservas hasta el límite de las primeras 32K, o sea
32x1024-24576=8192 Este espacio sirve para 256 patrones/tiles de 32 bytes cada uno
Los objetos que pones a continuación entiendo que equivalen a cuatro patrones como en G3, solo que ahora requieren
ocho bytes for fila, o sea 8x16=128 bytes cada uno por lo que incluso cargándolos todos al principio cabrían 256, que me parecen muchos!

El tema de sprites lo dejaré como está en mi caso ya que el modo G3 permite sprites tipo 2 y mantendré por tanto la carga dinámica.
Pero ya no será necesario para objetos ni letras llevar ningún control del número de los mismos para reservarles 'tiles' con el contador
como hacía hasta ahora. Qué alivio!!

Como bien dices, para enviar datos a la pantalla del juego, habrá que emplear HMMC para fonts y HMMM para patrones/objetos
Pero en la carga inicial de patrones y objetos también habrá que utilizar HMMC, ¿verdad?

Como ya descarté el tema convertir los fonts a 32 bytes, solamente me quedan los objetos. Tengo que modificar el compilador para que haga lo mismo que me hace ahora para los patrones/tiles.
Va a ser un trabajo duro pero muy interesante este cambio de modo gráfico.
Es un salto adelante muy importante y entiendo que sienta bases para un futuro modo G7 que sería al summum para las máquinas MSX2+ supongo ... ya que los modos de colores YJK me paren terroríficos
saludos
pere

Avatar de Usuario
pser1
Mensajes: 3154
Registrado: 08 Dic 2012 18:34
Agradecido : 784 veces
Agradecimiento recibido: 799 veces

Re: Comandos especiales en el V9958

Mensajepor pser1 » 12 Feb 2021 20:24

@jltursan
Te copio un fichero de texto en plan 'brainstorming' que escribí sobre el tema de los fonts/signos, por si algo te sirviera ...
Como lo hice pensando en comentar algo con el grupo de Dragon-MSX2+ pues lo escribí en anglosajón
saludos
pere
; -------------------------------------------------------------------------------------------
Currently fonts come 8 bytes = 8 bits per 8 rows: $11,$22,$33,$44,$55,$66,$77,$88
No colour is received so before printing the program reads a variable vdpCol to use it (contains 16 * Foreground + Background)
A bit set implies Foreground color and a reset bit Background colour
Each byte has to be split into four, each for two bits, and each nibble of these four bytes will represent a pixel, for instance a font byte = $b4
in binary will be -> 10 11 01 00

Now lets see what we should do to apply a value found in vdpCol = $73
We create a table of 4 elements using that vdpCol that way:
element 0 - $33 for values bits 00
element 1 - $37 for values bits 01
element 2 - $73 for values bits 10
element 3 - $77 for values bits 11
then we get a byte from the table for each bit pair from the source
10 11 01 00 -> $73, $77, $37, $33 and these bytes can be sent to the VDP to form a row
; -------------------------------------------------------------------------------------------
This means that fonts cannot be expanded to 4 bytes at compile time
This must be done by the engine before printing a char, using the 4 values table that will
be filled every time we want to define a different foreground/background combination (vdpCol)
This work should be assigned to the compiler and let it set these four values

As vdpCol contains $FG BG then we could create the 4 values table
// vdpCol default value = $f1 (white over black)
foreg = (vdpCol & 0xf0)/16; // get the high nibble
backg = vdpCol & 0x0f; // get the lower nibble
colTable[0] = 16* backg + backg; // default value 0x11 - black - black
colTable[1] = 16* backg + foreg; // default value 0x1f - black - white
colTable[2] = 16* foreg + backg; // default value 0xf1 - white - black
colTable[3] = 16* foreg + foreg; // default value 0xff - black - black

The variables coltable[0-1-2-3] have to be reserved in the engine and must be known to the compiler
; -------------------------------------------------------------------------------------------
Then to calculate the four bytes for every font row, let us name it patByte, we do:
byte0 = coltable[(patByte & 0xc0)/64];
byte1 = coltable[(patByte & 0x30)/16];
byte2 = coltable[(patByte & 0x0c)/4];
byte3 = coltable[(patByte & 0x03)];

These four values can be calculated in 6309 assembler
ldx #colTable ; point to element zero of table filled by compiler
ldy #byte0 ; point to 1st byte to be calculated
lde #4 ; bytes to fill
ldb #patByte ; get pattern in process byte
NextPair clra ; index to zero
asld ; shift left
asld ; two bits (pixels) to regA
lda a,x ; get the correct entry
sta ,y+ ; save to send it to the VDP later
dece ; decrement counter
bne NextPair ; do next one
; -------------------------------------------------------------------------------------------

jltursan
Mensajes: 3429
Registrado: 20 Sep 2011 13:59
Agradecido : 336 veces
Agradecimiento recibido: 947 veces

Re: Comandos especiales en el V9958

Mensajepor jltursan » 12 Feb 2021 20:42

Bueno, la verdad es que la carga inicial en VRAM me sale muy barata. Dado que de momento todo se carga desde disco y para ello empleo un cargador en MSX-BASIC, es desde este cargador desde donde voy ejecutando las cargas de cada bloque gráfico de manera que cuando el juego arranca, ya está todo en su sitio listo pasa ser usado. El compilador ya se encarga de hacer todas las transformaciones de datos y de generar los archivos de carga de pantallas estandar en el MSX-BASIC (que no son más que poco más que un volcado raw de los datos de la VRAm tal cual).

Avatar de Usuario
pser1
Mensajes: 3154
Registrado: 08 Dic 2012 18:34
Agradecido : 784 veces
Agradecimiento recibido: 799 veces

Re: Comandos especiales en el V9958

Mensajepor pser1 » 12 Feb 2021 21:36

jltursan escribió:Bueno, la verdad es que la carga inicial en VRAM me sale muy barata. Dado que de momento todo se carga desde disco y para ello empleo un cargador en MSX-BASIC, es desde este cargador desde donde voy ejecutando las cargas de cada bloque gráfico de manera que cuando el juego arranca, ya está todo en su sitio listo pasa ser usado. El compilador ya se encarga de hacer todas las transformaciones de datos y de generar los archivos de carga de pantallas estandar en el MSX-BASIC (que no son más que poco más que un volcado raw de los datos de la VRAm tal cual).

La verdad es que yo también había pensado en crear un fichero de patrones y objetos que son los que requieren mas bytes ahora, pero esto sería
básicamente para reducir el espacio en memoria del juego en si, cosa que permitiría juegos mayores ...
Pero para CoCo-Dragón habrá que preparar un binario que suba a la VRAM estos ficheros que previamente serán cargados en memoria, así que
va a tener que usar comandos HMMC
Lo que veo es que para hacer mas rápida la carga de patrones, por ejemplo, se deberían alinear de 32 en 32 de forma que ocuparían 128 bytes
y así se podrían enviar todos con un solo comando HMMC a pesar de que en la última fila de patrones podría haber varios a ceros.
Tengo que ver como puedo hacer que el compilador haga este trabajo antes de crear el fichero ASM
Y para los objetos otro tanto, tendría que alinearlos de 16 en 16 para llenar los 128 bytes de una fila y rellenar con ceros la última fila
¿Como preparas los ficheros para hacer mas rápida la carga a VRAM en MSX-BASIC?
saludos
pere


Volver a “Software MSX”

¿Quién está conectado?

Usuarios navegando por este Foro: pser1 y 1 invitado