Prototipo 2 del ZX-Uno

[yombo]

Esos diseños de cajas 3D que rulen, que yo tengo un amigo con impresora 3D...

[antoniovillena]

Intentaré que quepan los 4 diseños porque la PCB va a costar lo mismo haya uno o haya 4. Está claro que si dispones de impresora 3D siempre puedes hacer una caja donde quepa todo y quede bonito. Para el resto de los mortales tenemos que elegir entre placa superpuesta al ZX-Uno con la tapa abierta, o bien placa externa al mismo nivel pero con posibilidad de cerrar la tapa.

[jepalza]

Esos diseños de cajas 3D que rulen, que yo tengo un amigo con impresora 3D...

El finde me pongo con ellos, y ya los dejaré por aquí.

-- Actualizado 14 Oct 2014, 11:03 --

Intentaré que quepan los 4 diseños porque la PCB va a costar lo mismo haya uno o haya 4. Está claro que si dispones de impresora 3D siempre puedes hacer una caja donde quepa todo y quede bonito. Para el resto de los mortales tenemos que elegir entre placa superpuesta al ZX-Uno con la tapa abierta, o bien placa externa al mismo nivel pero con posibilidad de cerrar la tapa.

Ahora no me puedo poner con ello, pero me los puedo dibujar en el CAD, y ver como quedan en medidas. Lo mismo se puede hacer la placa acoplada mas alta, de forma que el VGA entre debajo, y que no sobresalga de una caja estándar.

Algo como esto digo:

opcion-vga3.jpg (39.91 KiB) Visto 7013 veces

Sería usar un conector mas alto de acople entre placa ladrona y plana madre, y de ese modo, el de VGA entraría debajo, y no sube la altura.

[antoniovillena]

El elemento más alto con el que chocaría el conector es el cristal de cuarzo, así que suma la altura desde nivel PCB que tienen un conector VGA más un cristal de perfil bajo y eso te dará la separación entre placas. La clave creo está en escoger una tira de pines macho de la altura que quieras, eso sí, el conector hembra cuando encaje nunca va a tocar la PCB de abajo.

Adjunto montaje con 4 diseños.

[jepalza]

Es cierto, está el cristal debajo. A ver si me puedo dibujar todo luego, y os puedo dar medidas de una placa donde rutear.

[antoniovillena]

Para aclarar un poco, los 4 montajes son:

• Montaje 1: Puerto de expansión. Es el menos interesante ya que se pierden muchos pines de la FPGA. Además no estará soportado oficialmente, por lo que requiere manipular algo de código fuente en Verilog. La única ventaja que tiene es que permite a la vez salida VGA y RGB/Compuesto, no hay que andar conmutando.
• Montaje 2: Es el más completo porque tiene VGA, JTAG y una salida alternativa a RGB por mini din que usa el mismo pinout que el clon superfo pero sin resistencias internas. No valdría el mismo cable a menos que lo abras y cortocircuites todas las resistencias. La placa quedaría fuera del ZX-Uno, pudiendo tener la tapa cerrada del mismo.
• Montaje 3: El más simple porque sólo tiene el conector VGA, la placa quedaría fuera al igual que en el montaje 2.
• Montaje 4: El de jepalza. Es como el simple anterior pero con la placa superpuesta al ZX-Uno, el cual tendrá conector recto en lugar de conector acodado. Como comparte conector VGA hay que elegir cómo cortarlo y quedarte con el montaje 3 o el montaje 4. También puedes no recortar el conector de la izquierda, así tendrías el conector JTAG disponible, aunque sobresale un poco por la izquierda.

[TallerSeverino]

Es cierto, está el cristal debajo. A ver si me puedo dibujar todo luego, y os puedo dar medidas de una placa donde rutear.

Jepalza, un saludo!
Muy buena idea este layout. Voy al otro pc a rutearlo

[mcleod_ideafix]

¿No es el mismo problema que existe al conectar un amiga a un monitor VGA; necesita que sea multisincronismo y aceptar dicha señal?

El problema que mencionas ocurre cuando un Amiga 1200 o 4000 se conecta a un monitor VGA. Estos dos modelos soportan lo que se llama "modos de productividad" que no son más que modos de video con los timmings de una VGA. En estos casos, es ovbio que si se emplea el mismo monitor para los modos nativos de Amiga y los modos de productividad, necesitas que dicho monitor sea multisync.

En el ZX-Uno no se pretende que el sistema conmute de modo VGA a modo RGB durante su funcionamiento, sino que el modo se determine por el usuario al comienzo del arranque. Así puedes elegir entre usar un monitor de video compuesto / RGB 15kHz, o bien usar un monitor VGA (pero no ambas cosas a la vez).

La primera solución es una memoria de "frame", me recuerda a que en un estudio de tv (de los 90 -2000) dicha memoria era lo más caro para mantener el sincronismo.

Porque se requiere que esa memoria sea de doble puerto, o en el caso más barato, una memoria de muy alta velocidad. Además necesitas mucha de ella: para un scandoubler de calidad "broadcast" en PAL estaríamos hablando de dos bufferes de 720*576*24 = 9953280 bits cada uno (1215 KB por buffer). Cada uno de estos bufferes debe poder soportar escrituras a la velocidad de reloj del reloj de pixel del sistema entrante (PAL), es decir, poder escribir 720 pixeles, que son 2160 bytes en 52 us, o 24ns por byte. En lectura la cosa es aún peor, ya que tiene que poder soportar lecturas al ritmo que indique el sistema saliente (VGA-800x600), que usa un reloj de 40MHz, y que por tanto necesita leer 3 bytes en 25ns, es decir, un tiempo de 8,3ns por byte.

NOTA: en la práctica lo que se hace (según he visto en algunos scandoublers antiguos, como uno que se vendió para los IBM PS/1 y PS/2 para ver "la tele en el monitor") es que parfa cada buffer se usan tres chips de memoria iguales, uno para cada color primario, funcionando a la vez (compartiendo el bus de direcciones y las señales de control) como si fueran una memoria de 24 bits en el bus de datos. Con eso se relajan un poco los tiempos de acceso respecto a los cálculos descritos.

En el ZX-Uno, la memoria SRAM incorporada en placa, ni es lo suficientemente grande para implementar un scandoubler de frame completo, ni lo suficientemente rápida para satisfacer los tiempos de lectura y escritura RGB-VGA, así que habría que irse a usar un único buffer de Block-RAM en configuración de memoria de doble puerto: un puerto de escritura, en el que la ULA enviaría píxeles, y otro de lectura, que usaría el driver de VGA para formar la imagen.

Dado que usamos varios modos gráficos en el ZX-Uno, cada uno con capacidad de mostrar más o menos colores, y más o menos píxeles, la cantidad de memoria a usar para el frame buffer será la cantidad máxima que se necesiten para alguno de estos modos. Teniendo en cuenta además el borde, y que el programador puede hacer virguerías del estilo de cambiar la paleta cada X tiempo, o conmutar páginas de pantalla para obtener más líneas verticales (modos gigascreen o interlaced).

Así, creo que el mayor gasto de memoria sería para una pantalla en modo ULAPlus, HiColor, interlaced. Esto es, 256x384, con dos colores diferentes en cada fila de 8x1 píxeles. Cada color gasta 8 bits (*). A eso súmale un borde que en modo completo tiene... a ver si me acuerdo, creo que eran 48 lineas arriba y abajo (que serían 96 líneas en modo interlaced) y que cada línea de video son en realidad 256 píxeles del "paper", más 48 píxeles de borde por cada lado izquierdo y derecho. En el borde puede haber como máximo un color distinto por cada rayita de 8x1 píxeles. Así que tenemos:

Modo ULAPlus, HiColor, interlaced: 256x384 píxeles.
- 48 líneas borde superior + 48 líneas borde inferior. Cada línea de borde son 48+256+48=352 píxeles, es decir, 44 grupos de 8x1 píxeles, es decir, 44 bytes. Los dos borders superior e inferior sumarán 96*44 = 4224 bytes.
- Cada línea de "paper" está flanqueada por un borde izquierdo y otro derecho. Cada borde ocupa 48 pixeles. Ambos borders ocupan 96 píxeles, es decir, 12 líneas de 8x1 píxeles, que necesitarán 12 bytes. La parte del "paper" en sí misma son 32 líneas de 8x1 píxeles, y cada una de ellas usa 2 bytes (color de paper y color de ink). Esto son 2 bytes por cada línea de 8x1 píxeles. Esta parte del "paper" ocupa entonces 32*2 = 64 bytes. Unido a lo que ocupan sus dos borders flanqueantes, tenemos 12+64=72 bytes por línea. Hay 384 de estas líneas (recordemos: modo interlaced) así que el total asciende a 384*72 = 27648 bytes.
- Uniendo ambas cosas, la cantidad de memoria necesaria, en un único buffer en memoria de doble puerto es de 31872 bytes.

En la práctica, y si quiero conservar una interfaz limpia entre la ULA y el scandoubler, debería aceptar como entrada del scandoubler los píxeles ya generados y procesados, al ritmo que indique el reloj de píxel más rápido que haya en el sistema, y ese es el reloj de 14MHz. En cada ciclo de este reloj se genera un pixel, y lo que sé seguro es que no se va a generar más de un pixel durante ese tiempo. En 52us genero 704 píxeles horizontales máximo, y cada frame contiene 288 líneas (192 de paper + 96 líneas entre los borders superior e inferior), si no tengo en cuenta el modo interlaced, o 576 si lo tengo en cuenta. Cada pixel que me envía la ULA ocupa 9 bits, así que mi frame buffer completo, sin entrelazado, y válido para cualquier modo generado por la ULA es de 704*288 = 202752 x 9 bits, o 1782 Kbits. Si quiero poder soportar los modos entrelazados, y convertirlos a progresivo en la salida, necesito el doble de buffer, esto es, 405504 x 9 bits.

Para un frame buffer completo sin entrelazado necesito por tanto 1782 Kbits de memoria block RAM. La Spartan 6 LX-9 que usamos en el ZX-Uno tiene unos nada desdeñables 576 Kbits de block RAM. Son muchos, pero insuficientes para un scan doubler por frame buffer completo.

Así que, salvo que haya obviado algún detalle, o error en los cálculos, ya adelanto que el único scandoubler posible con el hardware existente será el scandoubler de línea, en el que lo que tengo son dos pequeños bufferes en el que cada uno guarda una línea de pantalla. Mientras la ULA está escribiendo en uno de ellos la línea que está generando desde el ZX-Uno, el otro (que contendría la línea anterior) es leído dos veces al doble de velocidad por el driver de VGA, mostrando dos líneas en pantalla, una debajo de la otra. Ambas tareas terminarán a la vez, y los papeles de los bufferes se invertirán para la siguiente línea a a leer.

Dado que la frecuencia de lectura depende así de la frecuencia de origen, y ésta es PAL, estamos hablando de que en la salida VGA, una línea durará la mitad que en PAL, esto es, 32us, que nos da a su vez una frecuencia horizontal de 31,25kHz. La frecuencia vertical es la misma que PAL, 50Hz. Este scandoubler no realizará desentrelazado de señales que provengan de modos "interlaced" (se verán, pero con mucho parpadeo).

En resumen: el scandoubler que puedo implementar con mis conocimientos y el hardware del que disponemos en el ZX-Uno es uno que dará una señal VGA de 704x576 puntos, a 31,25kHz horizontal y 50Hz vertical. Probablemente pueda recortar la imagen para mostrar sólamente 640x480 a costa de comer un poco de borde por los cuatro lados.



(*) aunque ahora que lo pienso: gasta 8 bits cuando estamos en modo ULAplus. En modo "Sinclair original", son 9 bits de color lo que tenemos, así que los cálculos son ligeramente diferentes: donde dice bytes debería decir "grupos de 9 bits"

[TallerSeverino]

En resumen: el scandoubler que puedo implementar con mis conocimientos y el hardware del que disponemos en el ZX-Uno es uno que dará una señal VGA de 704x576 puntos, a 31,25kHz horizontal y 50Hz vertical.

Como siempre mcleod muy bien explicado, había confundido los 50Hz verticales con los horizontales de 31Khz, cosas del directo.

[antoniovillena]

A mí también me parece una burrada implementar un scan double de frame completo. Creo que con un scandoubler de línea es suficiente. Modos entrelazados que yo sepa no hay, no hay ningún modo que supere las 192 líneas.. Acabo de enterarme que hay un modo entrelazado de 512x384. En estos casos tampoco pasa nada si parpadea en modo VGA, porque implementar una alternativa que no parpadee aparte de consumir recursos, se cambian los timings originales.

Adjunto el diseño del adaptador invertido de jepalza+adaptador simple en amarillo.

mounting.png (109.47 KiB) Visto 6973 veces

vga7.zip

(44.99 KiB) Descargado 344 veces