Comandos especiales en el V9958

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 » 21 Feb 2021 21:21

Último mensaje de la página anterior:

la pregunta del millón es, ¿Cómo se diferenciaría estas dos direcciones? $f400 de $f600?
- - - - - - - - - - - - - - - - - - - - -
bit num -- 1111 1100 0000 0000
------------ 5432 1098 7654 3210
- - - - - - - - - - - - - - - - - - - - -
- $f400 - %1111 0100 0000 0000
- $f600 - %1111 0110 0000 0000
- - - - - - - - - - - - - - - - - - - - -
En el registro R#5
contenido = A14 A13 A12 A11 A10 1 1 1, pondríamos el valor $E4 para valor $f400 mas los unos fijos = $EF
contenido = A14 A13 A12 A11 A10 1 1 1, pondríamos el valor $E6 para valor $f600 mas los unos fijos = $EF
¿Como sabe el sistema cual es la dirección de inicio que hemos configurado?
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 » 22 Feb 2021 09:52

No acabo de entenderte muy bien, en principio cada dirección tiene un valor de registro diferente, obviamente no hay problema en diferenciarlos. El problema es que con tanto 1 y 0 te has liado ;-).
Los 9 primeros bits no están bajo tu control, sólo se consideran los 7 restantes (A10-A16) y si te fijas en tu propio esquema, el bit A10 de $F400 y el de $F600 son diferentes:

R#5 = $f400 - %1111 0100 0000 0000 = %11010111/$D7
R#5 = $f600 - %1111 0110 0000 0000 = %11011111/$DF

Creo que no me han bailado los 1 y los 0, revísalo si eso que si que es verdad que el manual es un pelín confuso...

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 » 22 Feb 2021 11:40

jltursan escribió:No acabo de entenderte muy bien, en principio cada dirección tiene un valor de registro diferente, obviamente no hay problema en diferenciarlos. El problema es que con tanto 1 y 0 te has liado ;-).
Los 9 primeros bits no están bajo tu control, sólo se consideran los 7 restantes (A10-A16) y si te fijas en tu propio esquema, el bit A10 de $F400 y el de $F600 son diferentes:
R#5 = $f400 - %1111 0100 0000 0000 = %11010111/$D7
R#5 = $f600 - %1111 0110 0000 0000 = %11011111/$DF
Creo que no me han bailado los 1 y los 0, revísalo si eso que si que es verdad que el manual es un pelín confuso...
Hola José Luis,
permíteme que disienta.
El bit mas bajo es el bit0, por lo tanto el bit 10 tiene el mismo valor para ambas direcciones. Es el bit 9 el que cambia
A menos que me digas que el bit de la derecha es el bit1 ... rompiendo mis esquemas :-(
$f400 -> %1111 0100 0000 0000 - tiene bit 10 a 1 y bit 9 a 0
$f600 -> %1111 0110 0000 0000 - tiene bit 10 a 1 y bit 9 a 1 también, pero este bit 9 = A9 no se puede configurar en R#5
¿Estoy contando mal los bits?
saludos
pere
Pd ¿Podrías decirme que valores has puesto en tu motor para MSX2 para R#5 y R#11? Muchas gracias

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

Re: Comandos especiales en el V9958

Mensajepor jltursan » 22 Feb 2021 13:01

A menos que me digas que el bit de la derecha es el bit1


Pues con ello contaba; pero ya me haces dudar. Si considero A01 como el primer bit, los 16 bits de la definición no permitirían direcciones superiores a 64KB por lo tanto deberían ser al menos 17 (A00-A16) -banghead. La memoria expandida no recuerdo si se podía utilizar para esto.

De todas formas creo que ya se donde reside el problema. La granularidad de la SPRATR es de 1024 bytes, no 512 bytes. Según eso, $F400 da como resultado la misma SPRATR que $F600. La anterior válida sería $F200:

R#5 = $f200 - %01 11100 10 0000 0000 -> R#11=1, R#5=$E7
R#5 = $f400 - %01 11101 00 0000 0000 -> R#11=1, R#5=$EF
R#5 = $f600 - %01 11101 10 0000 0000 -> R#11=1, R#5=$EF

En rojo, los bits significativos de R#11, en verde R#5.

Pensándolo bien, esto es lógico si tenemos en cuenta que nos movemos con potencias de 2. Esta dirección ubica simultáneamente 512+128 bytes = 640 bytes, por lo tanto cada "hueco" al no entrar de 512 en 512 bytes, tiene que saltar a huecos con 1024 bytes de tamaño.

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 » 22 Feb 2021 14:53

jltursan escribió:
A menos que me digas que el bit de la derecha es el bit1

Pues con ello contaba; pero ya me haces dudar. Si considero A01 como el primer bit, los 16 bits de la definición no permitirían direcciones superiores a 64KB por lo tanto deberían ser al menos 17 (A00-A16) -banghead. La memoria expandida no recuerdo si se podía utilizar para esto.
efectivamente, con el bit 16 que también está en R#11 podemos direccionar las 128k VRAM, las otras 64 (expanded memory) solo son
utilizables para leer/escribir, siendo el R#45 quien identifica VRAM - Expanded RAM siendo direcciones de 0 hasta 64k
De todas formas creo que ya se donde reside el problema. La granularidad de la SPRATR es de 1024 bytes, no 512 bytes. Según eso, $F400 da como resultado la misma SPRATR que $F600. La anterior válida sería $F200:
R#5 = $f200 - %01 11100 10 0000 0000 -> R#11=1, R#5=$E7
R#5 = $f400 - %01 11101 00 0000 0000 -> R#11=1, R#5=$EF
R#5 = $f600 - %01 11101 10 0000 0000 -> R#11=1, R#5=$EF
En rojo, los bits significativos de R#11, en verde R#5.
Pensándolo bien, esto es lógico si tenemos en cuenta que nos movemos con potencias de 2. Esta dirección ubica simultáneamente 512+128 bytes = 640 bytes, por lo tanto cada "hueco" al no entrar de 512 en 512 bytes, tiene que saltar a huecos con 1024 bytes de tamaño.

jltursan escribió:
A menos que me digas que el bit de la derecha es el bit1

Pues con ello contaba; pero ya me haces dudar. Si considero A01 como el primer bit, los 16 bits de la definición no permitirían direcciones superiores a 64KB por lo tanto deberían ser al menos 17 (A00-A16) -banghead. La memoria expandida no recuerdo si se podía utilizar para esto.
efectivamente, con el bit 16 que también está en R#11 podemos direccionar las 128k VRAM, las otras 64 (expanded memory) solo son
utilizables para leer/escribir, siendo el R#45 quien identifica VRAM - Expanded RAM siendo direcciones de 0 hasta 64k
De todas formas creo que ya se donde reside el problema. La granularidad de la SPRATR es de 1024 bytes, no 512 bytes. Según eso, $F400 da como resultado la misma SPRATR que $F600. La anterior válida sería $F200:
R#5 = $f200 - %01 11100 10 0000 0000 -> R#11=1, R#5=$E7
R#5 = $f400 - %01 11101 00 0000 0000 -> R#11=1, R#5=$EF
R#5 = $f600 - %01 11101 10 0000 0000 -> R#11=1, R#5=$EF
En rojo, los bits significativos de R#11, en verde R#5.
Pensándolo bien, esto es lógico si tenemos en cuenta que nos movemos con potencias de 2. Esta dirección ubica simultáneamente 512+128 bytes = 640 bytes, por lo tanto cada "hueco" al no entrar de 512 en 512 bytes, tiene que saltar a huecos con 1024 bytes de tamaño.

Tiene sentido. He estado mirando mi motor para G3 y resulta que utilizo $1e00 para tabla de atributos de sprites
el valor 1E00 = 0001 1110 0000 0000 - curiosamente el bit9 está a 1 y, sin embargo, no se puede definir en R#5 ya que por defecto ya está a 1
A mi me funciona poniendo a 1 los bits 10-11-12 o sea enviando $3C al R#5
Siendo 3C = 0011 1100 según algunos manuales los dos bits bajos los marcan con un X o sea indiferente, por lo que los dejé a cero.
En fin, que nos hemos pegado una buena disquisición sobre el bendito tema de las direcciones en el V9938
Muchas gracias
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 » 22 Feb 2021 15:04

Ojo; pero nunca dejes los 3 bits inferiores de R#5 a cero, su contenido no es indiferente, debe ser 1 obligatoriamente. Se pueden poner a 0, pero se producen efectos de mirroring de esas tablas en otras posiciones de memoria.

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 » 22 Feb 2021 16:36

jltursan escribió:Ojo; pero nunca dejes los 3 bits inferiores de R#5 a cero, su contenido no es indiferente, debe ser 1 obligatoriamente. Se pueden poner a 0, pero se producen efectos de mirroring de esas tablas en otras posiciones de memoria.

Los tengo a cero en el motor para modo G3 y no he detectado este problema, pero a saber en que posiciones se 'reflejan' los datos ...
Uno de los manuales del V9938 pone para los dos bits bajos una X mientras que para el bit2 pone claramente un 1
Pero, vamos, que no me cuesta nada ponerlos a 1 los tres! Muchas gracias por el aviso -drinks
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 » 22 Feb 2021 17:00

Esta es una versión corregida del manual, había bastantes bugs en el original: http://rs.gr8bit.ru/Documentation/V9938-programmers-guide.pdf

Aunque todavía pueda tener bastantes erratas, es la mejor en la que basarte :-)

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 » 22 Feb 2021 18:59

jltursan escribió:Esta es una versión corregida del manual, había bastantes bugs en el original: http://rs.gr8bit.ru/Documentation/V9938-programmers-guide.pdf
Aunque todavía pueda tener bastantes erratas, es la mejor en la que basarte :-)

muchas gracias, descargado ya!
jeje, el manual que has indicado, ciertamente es la última versión 1.01d (yo usaba la v1.01c), pero si te miras la parte de los sprites mode 2
verás en la página 102 que el R#5 tiene marcados con X los bits 0-1
Pero en la descripción del modo G4 en la página 49 dice que los bits 0-1-2 deben ser cero -banghead
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 » 22 Feb 2021 20:44

¿Y eso?, yo en la página 49 veo esto:

Sprites_V9958.jpg
Sprites_V9958.jpg (49.46 KiB) Visto 210 veces


El de la página 2 sin embargo si que está mal...:-D

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 » 22 Feb 2021 22:43

jltursan escribió:¿Y eso?, yo en la página 49 veo esto:
Sprites_V9958.jpg
El de la página 2 sin embargo si que está mal...:-D

ERROR, lo siento, escribí demasiado rápido. Efectivamente indica que los tres deben ser UNOS
pero la página Sprites mode 2 a los dos mas bajos les pone X
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 » 23 Feb 2021 09:13

Y anda que yo, ¡es el de la página 102, no 2! -grin

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 » 23 Feb 2021 21:47

otra sorpresa mas!
Estaba modificando la rutina DRoom para que pinte las pantallas copiando con el comando HMMM desde la tabla de tiles/patrones que
empieza justo después de la pantalla de 192 filas, o sea a partir de $6000 y se envían los datos hacia el inicio de pantalla, o sea $0000
Mirando cualquiera de los manuales del V9938, el comando HMMM requiere parámetros en los registros de 32 al 46 y se ejecuta perfectamente
Lo que me ha pasado es que solamente me copiaba una fila de datos de cada patrón/tile -banghead
El registro R#45 tiene dos bits DIX y DIY que indican si la copia se hace hacia la derecha/izquierda y hacia arriba/abajo
Parece razonable decir que al ir de $6000 hacia $0000 la copia siempre se hará hacia arriba, según manual esto implica DIY = 1
que tiene el valor 8 en R#45 y esto es lo que yo estaba haciendo sin obtener el resultado correcto.
Cuando me he hartado de errores, se me ha ocurrido dejar R#45 a CERO, o sea copiar a derecha y abajo ... y va y funciona -shock
La verdad es que me molestan estas cosas, pero bien está lo que bien acaba. Quien no se conforma es porqué no programa en ensamblador -507
Si alguien tiene alguna explicación mejor que la del manual, será bienvenida!
La primera pantalla ya sale perfectamente con el nuevo motor para G4 (en curso) y no me ha parecido que tardara demasiado (768 comandos).
Añadiré un poco de código para mover pantalla delante y atrás para tener una idea exacta de tiempos de carga
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 » 23 Feb 2021 22:19

ya he añadido el código necesario para poder pasar pantallas adelante y atrás.
Funciona muy bien, incluso diría que aprox. como en el modo G3 (escasa diferencia)
Pero me vienen ganas de probar que pasaría al poner la CPU a doble velocidad justo en la rutina DRoom ...
saludos
pere

EDIT. Ya lo he probado y algunos tiles quedan mal en la parte donde estaría el marco (o pannel). Tal vez si ahí hubiera algo
ya dibujado no pasaría nada, pero ... para andar haciendo ajustes poniendo NOPs para reducir velocidad en algunos puntos,
no merece la pena doblar la velocidad de la CPU ...
Tal como lo tengo ahora a 0,89MHz va suficientemente rápido como para decir que no se distingue del modo G3 -drinks

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 » 24 Feb 2021 09:08

Buenos días,
una vez conseguido mover pantallas adelante y atrás sin diferencia de tiempo respecto a la versión anterior en modo G3, me decidí
a hacer experimentos para justificar la decisión (solución a los problemas) de copiar *siempre* hacia la derecha y hacia abajo.
Primero copié solamente 32 patrones o sea los que caben en una fila y el resultado era una simple línea copiada arriba del todo
en pantalla. Cambiando la cantidad a 33, resulta que además de la línea anterior, me copiaba el primer patrón de la izquierda completo
o sea 8 líneas pero siendo la última la primera de la segunda fila de patrones ...
Y esto ya me dió la pista definitiva -thumbup
Una vez indicados los puntos origen y destino, los parámetros DIX y DIY no indica la diferencia de coordenadas entre estos dos puntos
como si lo hacen para el comando LINE) sinó que indican hacia que sentido se copian los píxeles (partiendo del punto dado).
Esto permitiría indicar como punto de origen y destino cualquiera de los cuatro extremos del rectángulo a copiar (arriba izquierda,
arriba derecha, abajo izquierda, abajo derecha) y entonces indicar respectivamente, para obtener el mismo resultado:
arriba izquierda requiere DIX = 0 (derecha), DIY = 0 abajo
arriba derecha requiere DIX = 1 (izquierda), DIY = 0 abajo
abajo izquierda requiere DIX = 0 (derecha), DIY = 1 arriba
abajo derecha requiere DIX = 1 (izquierda), DIY = 0 arriba
Una vez entendido esto, las cosas parecen claras y muy sencillas. Además simplifica la complejidad de cálculos para cada patrón.
Hoy haré un intento de aceleración que se me ha ocurrido mientras dormía -507
saludos
pere
Pd No es que los manuales sean malos, es que son incompletos -banghead

Avatar de Usuario
minter
Mensajes: 3358
Registrado: 22 Jul 2014 18:51
Agradecido : 4029 veces
Agradecimiento recibido: 1611 veces

Re: Comandos especiales en el V9958

Mensajepor minter » 24 Feb 2021 09:17

pser1 escribió:Pd No es que los manuales sean malos, es que son incompletos -banghead

-11

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

Re: Comandos especiales en el V9958

Mensajepor jltursan » 24 Feb 2021 09:18

Pues fíjate que esa parte siempre me pareció muy intuitiva, me ha chocado tu anécdota :-)
Es tan sencillo como que partes de esas coordenadas de origen y le dices en que sentido tiene que desplazarse horizontal y verticalmente para copiar el ancho y alto especificados en las coordenadas de destino.
Como verás, el calcular desde donde copias el elemento (ya sea bloque u objeto) en base a su código, es muy sencillo. Y una cosa que me viene a la cabeza antes de que te topes con ello, HMMM sólo trabaja con coordenadas pares. No creo que te afecte; pero es otra curiosidad ;-)


Volver a “Software MSX”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado