RetroWiki & Cacharreo [RW]

Último mensaje de la página anterior:

jltursan escribió:Pues todo lo que cuentas parece correcto. Yo empezaría revisando la inicialización del modo G6 (de la que ya hablamos de los registro implicados) y el cambio de página fuera de la interrupción, por ejemplo cada vez que pulses una tecla. Si puedes visualizar una imagen correctamente y luego cambiar a otra página para ver la otra, enganchar eso a la interrupción exclusiva que has hecho parece trivial...
¡Ánimo!

Veamos, mi programa carga una imagen en la página 0 que se ve en pantalla, luego carga otra imagen en la pagina 1 y al
mismo tiempo se ve en pantalla. Si pongo un contador y cambio cada 120 interrupciones, por decir algo, se ven las pantallas alternadas
y de forma correcta, cambiando cada dos segundos.
Mirando la doc del V9938 yo creo que el modo automático de alternado a 60fps *dobla* la resolución vertical y para ello alterna una linea
de cada imagen. Me temo que es así aunque a mi no me guste/interese
saludos
pere

Pd Si se te ocurre alguna otra prueba o configuración distinta ... la probaré en cuanto me sea posible!

Hola amigos,
tengo la posibilidad de que un colega experto en fotografia-imágenes me convierta imágenes fijas de Windows 24 bpp
a 8bpp sistema MSX2+ y además me podría dar dos frames para mezclarlos cambiando a cada VBLANK
Pero para ello es *indispensable* que funcione el sistema de alternar dos imágenes a 60fps para dar una imagen fija a 30fps
Desgraciadamente hasta ahora lo único que he conseguido siguiendo los consejos de las hojas de datos del V9938 es que
no se solapen las imágenes sino que resulten interlineadas alternativamente resultando una definición vertical doble
pero mostrando una imagen 'rara', poco agradable.

A ver si alguien puede echarme una mano y podemos aclarar definitivamente si esto es posible o es solo un deseo
Muchas gracias por adelantado
saludos
pere

Ando justo de tiempo, como siempre, pero voy a ver si estos días voy preparando una demo para tratar de hacer eso. Entiendo que no debería ser extremadamente complicado.

Te iré contando...

Adjunto una demo con lo que creo que necesitas:

Hola José Luis,
gracias por el código que has subido.
He tratado de hacer, mas o menos, lo mismo en Dragón, pero me sigue mostrando la pantalla interlineada en lugar de mezclar los colores
He visto que selecciones PAL, yo usaba NTSC, pero el resultado es el mismo.
Y lo que es peor, encima ahora me añade un parpadeo realmente molesto que no soy capaz de encontrar que lo provoca.
Haré unas pruebas mas y al final del dia subiré el fichero fuente del programa que estoy probando, a ver si cuando puedas echarle una ojeada encuentras lo que se me está pasando por alto
muchas gracias
pere

Hola,
por mas que haga cambios no lo consigo. Lo mas que logro es que se vean entrelazados ... ver imágenes
Al final incluyo dos ficheros, la V5 cambiando el vector de interrupción NMI de Dragón para que actúe al
recibir una interrupción de retrazado vertical del V9958. El otro es como la demo que subiste, controlando el bit7 del
registro de estado #0
A ver si tenemos suerte y detectas que estoy haciendo mal u omitiendo
saludos
pere

Ese resultado (o uno muy parecido) es el mismo que aparece cuando el inercambio de páginas se hace a escape libre.

¿Habías comentado ya que el código que intercambia las páginas tenía algún contador para controlar con certeza que se estaba invocando a 60Hz?, y otra cosa, ¿Esas dos pantallas de lineas horizontales y verticales ya están dibujadas cada una en su página correspondiente?, lo digo por descartar el tema de un paginado o inicialización del modo incorrectos.Si es así, sólo queda el intercambio de páginas y el como se está haciendo...

La prueba más tonta, si en vez de por interrupción, haces el cambio al pulsar una tecla, ¿las páginas cambian correctamente?

Más cosas, ¿has probado bien a hacer cosas con el modo G7?, ¿sin problemas?

jltursan escribió:Ese resultado (o uno muy parecido) es el mismo que aparece cuando el inercambio de páginas se hace a escape libre.
¿Habías comentado ya que el código que intercambia las páginas tenía algún contador para controlar con certeza que se estaba invocando a 60Hz?,

El contador lo puse para poder hacer cambios de página a velocidad inferior a 60fps. Por defecto a cada VBlank cambia de página P0 <--> P1
cambiando a cada VBlank entremezcla las imágenes. Cambiando cada dos también lo hace pero no se ve tan claramente debido al parpadeo
que se añade por baja velocidad (15 fps, bajo para la retención de imágenes del ojo humano)

y otra cosa, ¿Esas dos pantallas de lineas horizontales y verticales ya están dibujadas cada una en su página correspondiente?, lo digo por descartar el tema de un paginado o inicialización del modo incorrectos.Si es así, sólo queda el intercambio de páginas y el como se está haciendo...

Una está en la dirección $00000 con A16 a cero y la otra en $10000 con A6 a uno, teóricamente correcto.

La prueba más tonta, si en vez de por interrupción, haces el cambio al pulsar una tecla, ¿las páginas cambian correctamente?

pulsar una tecla es super lento y lo único que se consigue es ver una pantalla o la otra, de ninguna manera se llegarían a solapar/mezclar, por lo menos yo no soy capaz de pulsar 60 veces alguna tecla por segundo

Más cosas, ¿has probado bien a hacer cosas con el modo G7?, ¿sin problemas?

Actualmente tengo imágenes convertidas de 256x192 a 256x384 en Windows a 24bpp y con un programa hecho en Java genero un fichero que
tiene al principio todas las lineas pares de la imagen (192) y luego vienen todas las lineas impares (192)
El programa en Dragón carga cada imagen en una página distinta y puedo 'ver' la Pag 0 o la Pag 1 o bien la mezcla de ambas (activando IL)
y como en este modo se dedica a mezclar una línea de cada pantalla, me recompone la imagen original mostrando doble definición vertical
a pesar de tener las dimensiones normales ... funciona bien, para mi aunque me habría gustado mas que los colores se mezclaran en lugar de
duplicar la resolución vertical, veremos si se le puede sacar partido a este comportamiento ...
saludos
pere

El contador lo puse para poder hacer cambios de página a velocidad inferior a 60fps. Por defecto a cada VBlank cambia de página P0 <--> P1
cambiando a cada VBlank entremezcla las imágenes. Cambiando cada dos también lo hace pero no se ve tan claramente debido al parpadeo
que se añade por baja velocidad (15 fps, bajo para la retención de imágenes del ojo humano)

¿He de entender entonces que tienes más que comprobado que el intercambio se hacía estrictamente 60 veces por segundo?

pulsar una tecla es super lento y lo único que se consigue es ver una pantalla o la otra, de ninguna manera se llegarían a solapar/mezclar, por lo menos yo no soy capaz de pulsar 60 veces alguna tecla por segundo

Quizá no me he explicado bien, no se trata de pulsar una tecla a esa velocidad, se trata únicamente de descartar que hay algún problema con la visualización de las pantallas, una en cada página. Es decir, ves una correctamente y luego pulsas tecla y ves la otra, correctamente también y así repetido e intercambiando pantallas cada pulsación. Si eso funciona, es un problema relacionado únicamente con la operación de intercambio sincronizado.

Respecto al G7, por lo que cuentas (nunca había pensado en G7+entrelazado, consumes 128K de VRAM nada menos) funciona correctamente. Me imagino que habrás probado también pantallas normales a 256 colores sin entrelazar correctamente. Eso descarta posibles problemas con el segundo banco de 64KB y que los 128KB funcionan bien (¿o son 192KB los que monta?).

Voy a echarle un vistazo al codigo a ver si veo algo...

EDITO: Pues así por encima ya veo algo que no me mola:



Creo que se te ha pasado inicializar IE0...

Otra cosa que me despista es como cambias de página; veo que inicializas también A16 en R#14, ¿para ahorrar trabajo cuando prepares las escrituras?, es que no me cuadra existiendo a su lado los bits A15 y A14 y que te obligarían a volver a escribir sobre R#14. No he mirado mucho más tampoco...

EDITO2: Ah, lo habilitas después con una nueva escritura sobre R#2. Salvo que haya una buena razón, ¿porque no inicializarlo al configurar el modo y ya?

jltursan escribió:¿He de entender entonces que tienes más que comprobado que el intercambio se hacía estrictamente 60 veces por segundo?

efectivamente, cambia sobre seguro 60 veces por segundo en NTSC

Quizá no me he explicado bien, no se trata de pulsar una tecla a esa velocidad, se trata únicamente de descartar que hay algún problema con la visualización de las pantallas, una en cada página. Es decir, ves una correctamente y luego pulsas tecla y ves la otra, correctamente también y así repetido e intercambiando pantallas cada pulsación. Si eso funciona, es un problema relacionado únicamente con la operación de intercambio sincronizado.

Efectivamente, tengo un programa que me permite ver las imágenes pulsando '0' o bien '1' y se ven perfectamente bien
Además al pulsar '2' habilita el entrelazado y se ve la mezcla bien realizada

Respecto al G7, por lo que cuentas (nunca había pensado en G7+entrelazado, consumes 128K de VRAM nada menos) funciona correctamente. Me imagino que habrás probado también pantallas normales a 256 colores sin entrelazar correctamente. Eso descarta posibles problemas con el segundo banco de 64KB y que los 128KB funcionan bien (¿o son 192KB los que monta?).

Lo primero que hice fue probar con ocho imágenes 256x192 @256 colores y se cargan correctamente en la Página 0

Creo que se te ha pasado inicializar IE0...
Otra cosa que me despista es como cambias de página; veo que inicializas también A16 en R#14, ¿para ahorrar trabajo cuando prepares las escrituras?, es que no me cuadra existiendo a su lado los bits A15 y A14 y que te obligarían a volver a escribir sobre R#14. No he mirado mucho más tampoco... Ah, lo habilitas después con una nueva escritura sobre R#2. Salvo que haya una buena razón, ¿porque no inicializarlo al configurar el modo y ya?

Creo que habilitándolo de entrada, mientras estoy cargando la imagen, si se produce un VBLANK se activaría la rutina de interrupción y me cambiaría la página, así que lo retrasé hasta el momento en que ya he cargado las dos imágenes a mezclar.
El tema de A16 no haría falta cuando cambio de páginas en la rutina de interrupción, solo cuando estoy cargando ficheros para apuntar a la VRAM en el punto correcto.
Saludos
pere

El listado que he mirado ha sido el del polling activo del vblank, ese en principio no debería tener las interrupciones activas. De cabeza no me acuerdo si las tenía; pero si no las tiene no habría peligro de que nadie se metiera por medio.

Si empleas las interrupciones, al menos en el MSX, es mucho más fiable actualizar un contador de frames y emplear un polling sobre el mismo en lugar de uno sobre el bit del registro. Igual podría ser otra alternativa.

jltursan escribió:El listado que he mirado ha sido el del polling activo del vblank, ese en principio no debería tener las interrupciones activas. De cabeza no me acuerdo si las tenía; pero si no las tiene no habría peligro de que nadie se metiera por medio.
Si empleas las interrupciones, al menos en el MSX, es mucho más fiable actualizar un contador de frames y emplear un polling sobre el mismo en lugar de uno sobre el bit del registro. Igual podría ser otra alternativa.

Pues vaya! estoy acostumbrado a activarlas para que llamen la nueva rutina que creo para su tratamiento.
Eliminaré esta activación, ya que al no haber nueva rutina, cada VBLANK llama a la NMI std del Basic.
Muchas gracias, ya te contaré. De todas formas me temo que en los modos G6 y G7 al tener que manejar en dos imágenes las 128k es posible
que la GPU internamente decida hacer el entrelazado. Cuando llegue a modos mas bajos, por ejemplo 256x192@16 colores a lo mejor si
que hace la mezcla ... paciencia, todo llegarà
saludos
pere

@jltursan
Buenos días,
he llevado a cabo unas pruebas mas y creo que voy a pasar página ...
Adjunto los dos fuentes que he estado utilizando:
- G6MIX2V7 utiliza una subrutina para procesar las interrupciones VBLANK recibidas como NMI en Dragón. Entrelaza las lineas de ambas imágenes, pero crea una imagen nítida y estable
- G6MIX2V8 utiliza el método de polling (sin interrupciones habilitadas) y muestra las dos imágenes, para mi, también con signos de entrelazamiento, pero encima añade un parpadeo altamente molesto. No tengo ni idea de que puede estarlo provocando
He revisado los fuentes para asegurarme que los comentarios explican lo que hace cada línea de código.
Verás que el programa en si es una retahila de llamadas a subrutinas/funciones
Espero que tengas mas suerte que yo leyendo y releyendo estos fuentes y puedas encontrar algo que hago mal, en el orden incorrecto
o tal vez estoy omitiendo algún paso de configuración
saludos
pere

EDIT 2020-03-03: Los textos añadidos a cada fichero en .zip y en el fuente están intercambiados.
La v8 utiliza NMI mientras que la V7 emplea polling. Las prisas son malas consejeras

Pues si viste mi versión MSX funcionando está claro que algo tiene que estar fuera de sitio, realmente el VDP puede hacer lo que puede hacer

Por ejemplo, si en la versión sin interrupciones sabes que se tiene el control absoluto (que es la parte más puñetera del VDP), sólo se depende de hacer las cosas bien y en el orden correcto. Por descartes ya habíamos llegado a la conclusión de que el modo G6 se inicializa bien y muestras pantallas nítidas, además las dos páginas estaban accesibles y podías seleccionar cual ver; por narices el problema tiene que estar en el mecanismo de cambio de páginas sincronizado. En teoría para realizar esa operación, sólo hay que acceder al R#2 para cambiar, exclusivamente un registro a tocar y el cambio por tanto depende únicamente de eso y de detectar correctamente el vblank.
¿Que el VDP tiene trampas?, sí, alguna más. De memoria y suponiendo de nuevo que no hay interrupciones que puedan acceder también al VDP, sólo recuerdo que los accesos aunque son mucho más rápidos que los del TMS9918, pueden en algunos casos raros necesitar unas pequeñas pausas, no recuerdo si se ha llegado a descubrir un patrón de uso concreto; pero recuerdo haber leido del tema. En tu caso sería raro ya que los bucles en los que se vuelca contenido se hace siempre con varias operaciones por iteración en las que el VDP sólo queda ocupado durante el STA, doy por hecho que las pruebas las has hecho de varias formas incluyendo el modo "6809" estandar. El VDP no debería asfixiarse ni de lejos.

Y lo último sería el hardware; pero eso me parecería de lo más raro...

@jltursan
Trataré de pasarle un disco .VDK al colega inglés que también tiene el Wordpak2+ para ver que pasa en su máquina.
Por lo menos saldremos de dudas en lo concerniente al chip V9958 en si mismo.
Además queda todavía un sistema de cambio de pantallas automático que no requiere ni hacer 'poll' controlando el bit7 de S#0
ni necesita interrupciones.
En el manual del V9938 he visto ésto:
----------------------------------------------------------------------------------
SPECIAL FUNCTIONS •••••••••••••••••••••••••••••••••••••••••••• 102
1. Alternate display of two graphics screen pages •••••••• 102
2. Interlace display ••••••••••••••••••••••.•••••••••••••. 103
----------------------------------------------------------------------------------
- Para el apartado 1 dice que hay que enviar al R#2 la dirección de la página impar (asumo la P1 en $10000)
y luego indicar los tiempos 'on' de cada página en R#13
El problema es que el menor tiempo posible es de 1/6 de segundo lo cual implica 6 cambios por segundo o sea una imagen a 3fps (patético)
debe verse un parpadeo considerable ...
- Además propone una alternativa (1A): haciendo el primer paso igual en R#2, basta con poner a uno el bit 'EO' de R#9
Con esto debería alternarlas sin entrelazado/interlineado
- Finalmente para el apartado 2, se pone a 1 el bit IL (bit3 de R#9) con lo que se habilita el entrelazado/interlineado
Creo recordar que el método '1A' me producía interlineado así que lo desestimé, pero lo volveré a probar para tener un ejemplo
de cada una de las posibilidades. Es como si el bit 'IL' se pusiera a uno 'automáticamente' para estos modos gráficos
de alto uso de memoria ... tiempo al tiempo
saludos
pere

por cierto, hablando de tiempos de espera enviando datos al VDP, tuve que abandonar usar el TFM del HD6309 por ser demasiado rápido.
Incluso sin él, pero con el POKE &HFFD9 para ir a doble velocidad, hay que meter algun NOP entre envíos de datos ...
Así que he optado por no usar estos 'acelerones'
Pero si los utilizo para leer las imágenes del CoCo-SDC ya que el chip de esta tarjeta 'vuela' y permite el máximo de Dragon 6309
saludos
pere

Sí, para un humilde Z80 el VDP9938 práticamente no falla nunca; pero con el 6309 seguro que pierde la comba . De todas formas no creo que sea esto, entre acceso y acceso al VDP parece que hay tiempo de sobra y donde realmente se vería el fallo sería al dibujar las bandas, en las que aparecería basurilla.

Es como si el bit 'IL' se pusiera a uno 'automáticamente' para estos modos gráficos
de alto uso de memoria ...

A eso me refería con lo del problema de hardware, que haya algo que provoque ese comportamiento, un mal diseño a ese nivel o alguna soldadura que se ha ido de varas y ha hecho algún contacto extra.

A ver las pruebas del colega, es muy raro lo que está pasando. Y lo malo es que no hay otra referencia de ese chip con un 6809 para poderlo ejecutar ahí.
Seguiré remirando el código del que no usa interrupciones.