Aprendiendo a manejar los chips de video V9958 y sonido YM-2149

[jltursan]

Último mensaje de la página anterior:

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.

[ron]

Off Topic

Otro hilo, master class. Gracias a los dos.

[pser1]

Bueno, he tenido suerte y he encontrado en mis cajones de circuitos integrados otro integrado Yamaha V9958!!
Me ha faltado tiempo para quitar el que venía en el módulo WordPak2 y poner el mio.
Una vez cambiado, he vuelto a conectar todo y al hacer las pruebas con los tres programas que realizan el cambio de
pantallas por métodos diferentes, he obtenido los mismos resultados que con el chip original, así que descarto un defecto
interno del chip. Me temo que será que, por microcódigo, cuando ha de manejar pantallas de 64k habilita el entrelazado/interlineado
por su cuenta sin que surja ningún efecto el valor del registro R#9
No creo que sea tema de pistas ya que el valor de un registro es interno al chip, no hay ningún acceso a él desde la placa de circuito impreso ...
En fin, una verdadera lástima ya que esto habría permitido ver imágenes a 256*256/2 colores o sea 32.768 nada menos
Ahora pasaré directamente al modo G4 que permite 256x192 @16 colores (de una paleta de 512 => 3 bits por cada componente - RRRGGGBBB) lo
cual permitirá, eso espero, mayor flexibilidad a la hora de convertir imágenes fijas.
Además es el modo 'perfecto' para juegos, estando muy cerca del CoCo3 que permite 320x200 @ 16colores (sobre 256)
En fin, seguiremos en contacto con lo que vaya sucediendo ...
Por cierto, me he preparado un driver para el modo texto1 (40 columnas) y otro para el modo Texto2 (80 columnas)
Ambos se instalan e interceptan tanto al Basic como al DOS por lo que se puede trabajar en la pantalla grande, es un lujazo!
saludos
pere

[pser1]

ufff, exasperante
Muy fácil convertir el Modo G7 en G4, cambiando pocas cosas ya funciona.
Pero sigue haciendo interlineado/entrelazado de las barras verticales con las horizontales ...
Me parece increíble que no se puedan 'superponer' dos imágenes sin caer en el maldito alternado de lineas de ambas imágenes ...
mala suerte
saludos
pere

[pser1]

@jltursan
Ayer, al final, abrí un hilo en archive worldofdragon para comunicarme con dos colegas ingleses que también disponen
de la placa Wordpak2+ aunque uno de ellos está esperando materiales para acabar el montaje ...
Puede verse aquí:
http://archive.worldofdragon.org/phpBB3 ... =9&t=10454

Ahí estarán los ficheros/VDKs de pruebas que vayamos creando
A ver si hoy puedo añadir unas fotos de los drivers de texto en ambos modos, 40 y 80 columnas
Y mas adelante algunas imágenes a 256x192@256 colores convertidas de 24bpp a 8bpp con un programa mio en Java
que me temo que trabaja demasiado a piñón fijo, quero decir que aplica unas ecuaciones y basta. Me temo que habría que
aplicar algún tipo de 'dithering' cuando se reduce la calidad de una imagen ...
saludos
pere

[jltursan]

Pues aquí te dejo otra versión, esta vez con algunas cosas corregidas para poder trabajar a pantalla completa y con una malla con las 256 posibles mezclas. Es a lo cutre, no he redefinido el 0 así que no son los que deberían ser; pero tampoco tendría claro cual sería la mejor paleta de 16 colores a la hora de conseguir las mezclas óptimas (¿la Dawnbringer?)

g6demo.zip

(1.76 KiB) Descargado 11 veces

Prueba la ROM y comprobarás como no hay ningún problema a la hora de realizar la mezcla entre dos pantallas, de hecho, si tienes un par de imágenes separadas a partir de una paleta de mezclas, pasamelo todo y monto el completo para presentar la imagen.

Y mas adelante algunas imágenes a 256x192@256 colores convertidas de 24bpp a 8bpp con un programa mio en Java
que me temo que trabaja demasiado a piñón fijo, quero decir que aplica unas ecuaciones y basta. Me temo que habría que
aplicar algún tipo de 'dithering' cuando se reduce la calidad de una imagen ...

Pues este que tienes online ya da una calidad notable: https://msx.jannone.org/conv/

No pierdas tiempo con eso, hay cantidad de conversores que la gente ya se ha curradomuy mucho.

[pser1]

Pues aquí te dejo otra versión, esta vez con algunas cosas corregidas para poder trabajar a pantalla completa y con una malla con las 256 posibles mezclas. Es a lo cutre, no he redefinido el 0 así que no son los que deberían ser; pero tampoco tendría claro cual sería la mejor paleta de 16 colores a la hora de conseguir las mezclas óptimas (¿la Dawnbringer?)

Gracias, recién descargada. A ver si veo las diferencias respecto a la versión anterior. Entiendo que las barras las pintas en $00000 y en $10000 y luego en el bucle vas cambando de una a otra ...

Prueba la ROM y comprobarás como no hay ningún problema a la hora de realizar la mezcla entre dos pantallas, de hecho, si tienes un par de imágenes separadas a partir de una paleta de mezclas, pasamelo todo y monto el completo para presentar la imagen.

No tengo la menor duda de que en MSX las dos pantallas se mezclan. Mi problema es que esto tengo que conseguirlo en este módulo y podría muy bien ser que al enviar la señal VGA 15kHz directamente a la entrada SCART de una TV moderna haya alguna cosa imprevista a pesar de que, en general, se ve muy bien todo.
Esperaré a ver como le funciona a John Whitworth y veremos si tenemos (o tengo) algún problema en mi módulo ...

Pues este que tienes online ya da una calidad notable: https://msx.jannone.org/conv/
No pierdas tiempo con eso, hay cantidad de conversores que la gente ya se ha currado muy mucho.

No le dediqué mucho tiempo, en java hacer una conversión directa es muy simple, pero el resultado también lo es
Gracias por la web. Voy a tener que convertir las imágenes de pruebas porqué todas las tengo en BMP y las que tengo PNG superan con mucho
los 400kB de máximo

[pser1]

A lo largo de este fin de semana voy a convertir el código Z-80 MSX2 a 6809 para Dragón
Trataré de usar las macros del ASM6809 a ver si puedo hacerlo lo mas parecido posible.
Una vez hecho y probado, subiré el fuente aquí para que puedas verificar que no he cometido
ningún error en la conversión ...

Mi versión va a tener que cargar una paleta ya que al no haber Sistema Operativo debajo que soporte la V9958, esta arranca
sin nada de nada (ni fuentes ni paleta). Si has empleado alguna concreta puedes pasármela para que yo vea los
mismos colores en ambas pantallas ... muchas gracias!
saludos

[pser1]

@jltursan
Buenos días,
me tentaba tanto la conversión ... que ya la he hecho y por practicar novedades, la CPU destino es la HD6309
y estoy usando los registros 'nuevos' como W,E,F,V así como algunos opcodes para ellos.
Cuando puedas, échale una ojeada al fichero adjunto para ver si he cometido algún gazapo grave ...
A la derecha del código 6309 está en comentarios el de Z-80 para comparar
Tengo algunas dudas sobre como funciona el programa.
Supongo que "dibuja las barras" pinta las horizontales y que "dibuja las columnas" pinta las verticales, ¿Verdad?
Lo que no veo es como le cambias la dirección de inicio de VRAM ya que el código de la segunda viene a continuación de la primera
Y entre Pagina0 y Pagina1 hay una buena cantidad de memoria no utilizada ...
He visto que utilizas en las macros el operador >> que entiendo que es un ShiftRight el numero de veces que se indica a continuación, ¿OK?
Perdona el peñazo, pero me tiene muy intrigado el comportamiento del V9958
Creo que ya te dije que encontré uno por casa, lo substituí en la placa y sucede lo mismo, así que no veo el motivo
Muchas gracias por anticipado
Saludos
pere

G6MIX2V3.ZIP

(3.02 KiB) Descargado 7 veces

[pser1]

he osado probar el ejecutable compilado, via drivewire y la pantalla ni siquiera se ha inmutado
Me temo que tendré que ir probando por partes ...
saludos
pere

Pd ya he visto que dentro de rectFill se posiciona la VRAM cada vez, un problema menos ... sigo debugando
pero XRoar es patético para esto ya que no presenta correctamente ni los valores de los registros añadidos ni
los opcode nuevos ...

[pser1]

avanzando muy lentamente ...
Como habilitas las interrupciones, el chip envia IRQ a l aCPU que las recibe como NMI y estas son rocesadas
internamente por el sistema.
Las he deshabilitado en el 'hook' del sistema en Dragón.
De momento el programa inicializa G6 y borra la Página 0 y luego la 1.
He puesto paradas para ver el resultado en cada página, y resulta que en ambos casos la parte final pantalla
digamos que unos 2 cm son de diferente color.
La página 0 la borro a blanco y el resto a rosa
La página 1 en azul y resto en rojo
Pues bien estos restos parecen ser la parte que iría de la linea 192 a la 212 ...
A ver si encuentro donde se está liando el programador
He quitado los DisplayOFF y DisplayON para ver lo que pasa realmente y se ve claramente que primero se pintan las 212 líneas
con la primera llamada a fillVRam, pero la siguiente llamada parece que apunta a VRAM antes del final de la linea 212
Por cierto en la P1 me aparece arriba a la derecha un 'sprite?'. Si en la inicialización prohibo sprites, desaparece!

saludos

[pser1]

En las llamadas para borrar el resto de página, no estoy 'reposicionando' el puntero a la VRAM
con lo cual utiliza el último empleado. Asi no sobreesccribe lo ya pintado. No lo entiendo, pero pasaba ...
Por otro lado enviando 10 en lugar de 8 al R#8 desactivo los sprites y el incordión desaparece
Ahora a por la parte que pinta barras horizontales ...
hasta pronto
pere

[jltursan]

Caray, a ver, muchas cosas...

Lo de las interrupciones es un incordio pero es que en MSX es necesario controlar eso bastante ya que si están habilitadas, aparecen zonas críticas en las que no puedes dejar que te salte una ya que te roba inmediatamente el estado del VDP (S#0). Al utilizar el mecanismo del vblank es cuando más tiempo permanecen ya que por narices me tengo que esperar a que cambie el estado y lo lea yo. En un programa MSX real no se haría así nunca, claro.

Primero se dibujan las horizontales y luego las verticales, el puntero a la VRAM se construye en cada rutina con AHL, en la primera (horizontales, página 0) son A=0 y HL=0 y en la segunda (verticales, página 1) son A=1 y HL=0. Una diferencia crucial es que ahora siempre invoco a SetVdp_Write ya que voy a acabar apuntando a cualquier punto de los 128KB, siempre inicializo los tres registros que determinan el puntero donde escribir.

El borrado inicial de pantalla lo hago encadenando las macros "fillvram", primero 212 lineas a color y luego 44 (sumando 256 líneas) a 0 y eso en cada página (sumando el total de las 512 líneas de altura = 128KB). Dentro de ese primer bloque a 0 de la primera página (si no recuerdo mal) residen los sprites que al quedar a 0 se hacen invisibles aunque eso no sea el mecanismo correcto. Si los ves debe de ser porque en tu caso el 0 es el transparente y tu lo habrás redefinido. ¿No los verás con ese color redefinido?. El borrado correcto debería ser con una coordenada Y=217 en cada sprite, la X y el patron son irrelevantes.
De todas formas, si deshabilitas TODOS los sprites mediante el registro de control, ganarás fácil un 30% de velocidad para el blitter del VDP.

Y si, en el sjasm, el ">>" es el shift right o lo que es lo mismo dividir por una potencia de dos o en este caso, pasar el byte alto al bajo.

[pser1]

muchas gracias José Luis
Como ha habido cosas mal convertidas, me fallaban y he acabado añadiendo rutinas mías (partes de código
ya utilizado, que funcionan si o si) y cuando he conseguido ver las dos páginas pintadas de colores diferentes,
he ido analizando las diferencias entre mi código y el 'mal' convertido. Poco a poco he ido eliminando mis rutinas
con lo que ahora ya solo están la convertidas, de otra manera no me podría fiar de la prueba ...
Ahora puedo ponerme con el pintado de barras horizontales ya que las macros/rutinas que llama han sido verificadas,
otro tema serán los errores de conversión en el bucle propio de cada 'pintor'
Ya te iré contando como van las cosas ... sin prisas, pero sin pausas
saludos
pere

[pser1]

Hola José Luis,
muy a mi pesar, el resultado final ha sido el mismo que con los programas que he hecho hasta ahora ... aunque era presumible
Te adjunto aquí el fuente del programa convertido. Tal vez puedas encontrarle algo ...

Me temo que esto va a ser debido a problemas hardware:
a) Relacionado con la implementación que se ha hecho en el Wordpak2+
b) Debido a usar la señal de VGA 15kHz contra la entrada SCART de un TV moderno. A saber como se vería en un monitor de los de antes!

saludos y muchísimas gracias por las molestias que te has tomado con este problema
pere

G6MIX2V9.ZIP

(3.43 KiB) Descargado 10 veces

[pser1]

Se puede ver el video del programa mostrando primero las barras horizontales, luego la verticales
y finalmente mezclando ambas imágenes aquí:
http://archive.worldofdragon.org/phpBB3 ... 795#p22795
Veréis que las entrelaza y además añade un parpadeo molesto

saludos
pere

[wilco2009]

Yo si tuviera que apostar, diría que ese efecto te lo está haciendo la conversión que hace la tele.
No tienes un monitor a 15khz o un scandoubler?