ZXUNO con salida VGA en el Spectrum

[jepalza]

Mañana le meto caña, ahora voy a probar otras cosas, como lo del HDMI, como ya tengo VGA tiene que estar chupado hacerlo.

[jepalza]

Estoy haciendo pruebas, y al margen de que lo has explicadio bien ("28.571MHz, que requiere de un multiplicador 4 y un divisor 7.") y lo has escrito mal ( ".CLKFBOUT_MULT (7) y .CLKOUT0_DIVIDE (7)" debería ser .CLKFBOUT_MULT (4) y .CLKOUT0_DIVIDE (7)) me da un error del que no consigo salir:

PhysDesignRules:1859 - The computed value for the VCO operating frequency of PLL_ADV instance
relojes_maestros/pll_base_inst/PLL_ADV is calculated to be 200.000000 MHz. This falls below the operating range of
the PLL VCO frequency for this device of 400.000000 - 1000.000000 MHz. Please adjust either the input frequency
CLKIN_PERIOD, multiplication factor CLKFBOUT_MULT or the division factor DIVCLK_DIVIDE, in order to achieve a VCO
frequency within the rated operating range for this device.


es curioso que con estos valores "9,16,32,64,128" sintetiza bien y en cambio con "4,7,14,28,56" da el error indicado

EDITO: lo he resuelto bajando el "CLKIN_PERIOD" a solo 10 (desde 20 originales). Seguro que no es el mejor método, pero al menos sintetiza. POr lo demas, con esos valores, ha mejorado el mmodo 48k (ahora se auto-centra el solo en TV) pero el modo 128 sigue igual.

[mcleod_ideafix]

The computed value for the VCO operating frequency of PLL_ADV instance
relojes_maestros/pll_base_inst/PLL_ADV is calculated to be 200.000000 MHz. This falls below the operating range of
the PLL VCO frequency for this device of 400.000000 - 1000.000000 MHz. Please adjust either the input frequency
CLKIN_PERIOD, multiplication factor CLKFBOUT_MULT or the division factor DIVCLK_DIVIDE, in order to achieve a VCO
frequency within the rated operating range for this device.[/i]

Mira, es sencillo. Lo que dice ahí es que para que el PLL funcione, la frecuencia, una vez multiplicada, ha de estar en el rango de 400 a 1000MHz, y resulta que con el multiplicador = 4, la frecuencia de PLL que obtenemos es 200MHz (50MHz x 4), así que hay que buscar otra frecuencia cuyo multiplicador sea al menos 9, para que esté en rango (50MHz x 9 = 450MHz).

No caí en ello . Prueba con esta otra frecuencia: 28.947MHz, que significa usar M=11, D=19 (y luego 38, 76 y 152 para el resto de divisores)

Con ella, la frecuencia del Z80 será de 3.6183MHz, y la frecuencia vertical (que es el valor más sensible para la mayoría de los monitores VGA) será de 51.773Hz para el modo de 48K y 51.480Hz para el modo de 128K.

Para calcular qué frecuencia de barrido vertical tendrás en ambos modos, usa estas fórmulas, en donde CLK es la frecuencia maestra que sintetizas en el PLL (28.947 en el ejemplo anterior)

Freq_vert_48K = 1000000 / (448*312*(4/CLK))
Freq_vert_128K = 1000000 / (452*311*(4/CLK))

La frecuencia de la CPU que obtendrás será: CLK / 8

En principio, cuanto más te alejes de la frecuencia de 50Hz y te acerques más a la de 60Hz, mejor te funcionará el monitor, pero a partir de cierto punto empezarás a notar que las cosas van ¡demasiado rápidas!

El core, de todas formas, aguanta hasta una frecuencia maestra de unos 35MHz aprox. Puede ser divertido ponerlo al límite y ver qué tal funciona. Mi mayor preocupación es el gestor de memoria, que emula una memoria de doble puerto con la SRAM. Como uso dos ciclos de reloj maestro y esta memoria es de 35ns, podría en teoría ponerse el reloj del gestor hasta un periodo de 35ns / 2 , que significa usar una frecuencia de unos 57MHz

A unos 33.54MHz, tendrías una frecuencia de reloj de la CPU de 4.19MHz, y una frecuencia de barrido vertical en el modo de 48K de 60Hz. Los valores de M y D más cercanos serían M=11 y D=16, que te dan 34.375MHz, lo cual es una frecuencia incluso un poco mayor.

¿Funcionará?

Otra cosa por investigar es si es posible (que yo creo que sí) usar más de un PLL, alimentando el segundo con una frecuencia sintetizada por el primero. De esa forma, el rango y precisión de frecuencias que puedes llegar a conseguir es mucho mayor

[jepalza]

El último valor, el que genera 3.5 con 156, no sirve, dice que solo es posible un valor entre 1 y 128. Falseando y dejándolo en 128, da 4.3mhz, me paso de los 3.5, pero al menos, para probar, funciona. Y lo hace bastante bien en general. El modo 48 es muy estable, el de 128 sigue con unas finas líneas horizontales, inapreciables, pero molestas.

Con M=11 y D=16 tambien funciona, mismos o parecidos resultados (al menos, para mi ojo desentrenado).
Lo que me he fijado, es que, cuanto mas subimos de frecuencia, menos borde queda en el lado derecho, se va recortando. O eso me parece a mi.

De todos modos, quizás el fallo sea solo de mi monitor. Como no tengo espacio encima de la mesa (hace un año mas o menos, mi mujer me obligó a poner mesa pequeña, por que le quitaba mucho espacio) solo puedo tener un monitor a la vez sobre la mesa, y por no andar cambiando he dejado uno fijo, uno de marca nisupu que es ademas TV. En la tele de la sala sé que funciona bien, pero son pruebas incómodas.
Lo ideal sería que varios probaran en sus monitores, a ver que resultados arroja.

EDITO: He subido al repositorio el core que he usado para las pruebas, por si alguno quiere probarlo ( @radastan ). Está en la carpeta "jepalza" subcarpeta "test19_multi_vga". Dentro va una carpeta "firmware" con el MCS y el BIT. Si no queréis tocar el MCS de vuestro ZXUNO , no grabéis el mio, (es mas lento meter un MCS que un BIT). En ese caso, solo hace falta el BIT directo a la spartan6, y se puede ver el resultado (claro, siempre que ya tengáis el MCS del core bueno, el test19_multi anteriormete grabado). Como solo está en la spartan, al apagar y encender, se pierde y recuperáis vuestro MCS actual. A ver cómo se comporta vuestro monitor VGA. Al mio le cuesta autocentrary recorta un borde (el derecho), pero funciona bien. El modo 128 tiene unas finas rayas horizontales, pero se puede soportar.

[Radastan]

Bien, por partes:

- No tengo cable JTAG, ¿se puede meter la actualización por software?
- Que alguien me diga los pasos a seguir de ser así

Alguien tendrá que hacer de conejo de indias, y es justo que el que más lo ha pedido sea el que lo haga.

[jepalza]

Upss! Pues por soft no. Tiene que ser JTAG. Al menos el BIT inicial. Me suena que Quest ha hecho algo. A ver si aparece y nos lo comenta.

De todos modos, el primer prototipo de ZXUNO que tuvimos, las primeras pruebas las hice con un JTAG casero con unas pocas resistencias. Lento, pero funcionaba. Hay varios esquemas sencillos de hacer en una "protoboard":
https://www.osta.ee/en/lpt-jtag-xilinx- ... 74769.html
http://wiki.openwrt.org/doc/hardware/po ... unbuffered

[Quest]

Pues sin cable JTAG, en este caso difícil

El test que ha sintetizado jepalza (sobre test19_multi) usa el nuevo mapa de la flash incompatible con el anterior y por tanto un nuevo bootloader. Aunque hiciéramos un .TAP para actualizarte el core vía EAR desde la BIOS, te haría un bonito brick, puesto que en el resto de la flash, las "cosas" no están donde el core espera que estén.

No obstante aunque sintetizaras una versión antigua modificada con el VGA no recomiendo que actualices el core sin cable JTAG porque te expones a que pase algo y no puedas arrancarlo o no puedas actualizarlo más.

Estuve probando ayer lo que subió jepalza y de vez en cuando provoca errores en los timings. Muy de vez en cuando hay corrupciones. Si esto pasa cuando lee/escribe de la flash o de la SRAM cuando estés actualizando por EAR (que incluso con turbocargas se va a los 3-4 minutos) imagínate el resultado.

Hablando ya del VGA, En mi monitor que se lo traga todo (da igual que la sincro sea separada, compuesta, 15khz, 31khz, 50Hz, 60Hz... lo que sea...) se ve que en el modo 48k hay líneas por encima de la imagen que están fuera de sincro aunque el resto de la imagen se vea bien (con lo cual los valores no están 100% bien ajustados en el VHDL). Se ve mucho más acentuado con timings de 128K (cuyo reloj es ligeramente distinto) Probé durante 2 horas a ajustarlos en el código y no hay manera de que quede perfecto. Inlcuso con determinados valores el spectrum ni arranca (sacando pantallas de cuadraditos parpadeantes de colores) Me da que si los relojes no son 100% exactos, el scandoubler (al menos ese) no va a funcionar bien. Y por lo que veo puede afectar incluso al funcionamiento del spectrum.

Con los valores que están en el scandoubler, me da en el monitor 31.8Khz / 50.9Hz. El borde inferior es demasiado alto. El borde derecho demasiado estrecho (y no es por el tema de la ULA, porque sin el scandoubler, a 15Khz, las dimensiones de los bordes son correctas).

Las líneas que se te ven con los timings de 128k, en mi monitor se puede ver por fuera de la imagen cómo hay líneas que no se si es que son líneas fuera de sincro o son líneas de sincro (o no visibles) dentro del rango de las visibles. Pero no deberían de estar ahí. Pongo foto:

Esas líneas también aparecen sobre la imagen del modo 48K, aunque no se vean a simple vista, se pueden ver modificando la geometría en el monitor.
En este caso se pueden ocultar cambiando el valor de vpad a algo entre 4 y 8. Entiendo que lo único que hace es ocultarlas, pintando píxeles negros en los bordes inferior+superior. Sin embargo esto no sirve para el timing de 128k porque el problema ahí es más grave, el problema de sincro no está al principio y al final por lo que deduzco, sino también por enmedio.

[jepalza]

Está claro que cada monitor PC es un mundo. Hice pruebas en tres monitores con los valores originales del TEST19 en el módulo de cuatro relojes y solo se veía bien el modo 48k en la TV Samsung. En un monitor de PC de 1366x768 no lo cogía, y en la TV "nisupu" 1366x768 (modo entrada VGA) que uso habitualmente, la que está junto a mi portátil, no se autocentraba, y tenía que centrarlo "a mano", pero el modo 48k se veía de perlas (con el borde recortado, pero sin líneas feas). EL modo 128k se veía con las rallas que te salen a ti (hay una foto unos mensajes mas arriba, en la página 1).
Retoqué los relojes según indicaciones de Mcleod_Ideafix, y logré que el modo 48k se quedara igual (no alterado) en MI monitor TV, y el de 128k unas líneas finas, apreciables, pero no tan gordas como al principio.

EL módulo "scan_converter.vhd" que empleo para adaptar las señales de la ULA a las de la VGA, es uno cogido del ZX Spectrum HDMI de la placa pipistrello. Y ya te digo, que mi TV (no es monitor PC, sino TV Full HD con entrada 1366x768 para PC) el modo 48k se ve "casi" perfecto, pero sin rallas.

Edito: prueba si quieres a dejar los valores del módulo de cuatro relojes, en sus valores iniciales,a ver cómo te va.

[Quest]

El tema es que no hay que fijarse únicamente en si el monitor lo soporta o no o si se ve mas hacia un lado o hacia otro, sino en que los valores en el core generen una imagen lo más correcta (y cercana al estándar) posible.

Fijándose muy en detalle, se puede observar cómo en la imagen generada (con el timing de 48k que es el que "mejor se ve") nos da alguna pista de que algo no está bien:

Marco con flechas donde se ve que se pintan las líneas hasta la mitad, y se terminan de pintar en el retrazo siguiente (o al menos es lo que deduzco al verlo).

También se puede observar en este mismo modo cómo se pintan al final las líneas que comentaba que no deberían estar en el área visible:

Independientemente de que sea mi monitor o el tuyo o el de perico pérez, no se debe pintar nada de la zona no visible en la visible, etc. Salga o no salga en la pantalla que sea.

Yo de temas de sincros no controlo mucho, así que quizá Mcleod nos pueda decir qué está pasando exáctamente al generar la imagen y por dónde se puede tirar para corregirlo o para detectarlo.

[jepalza]

Yo tampoco controlo de temas de vídeo, y fíjate si soy malo en el tema de los detalles, que ese "quiebro" que te hace a ti, también me lo hace a mi, pero como no se apreciaba en la pantalla blanca tras un reset, no pensé que molestara ni que fuera importante.

Bueno, pues hay que ajustar esos valores como sea, está claro. La base es buena, el resultado malo.