Scroll por hardware

[antoniovillena]

Bueno, tal y como lo pienso hacer no tendrá salidas UYV, sino RGB, y en la propia placa habrá un pequeño AD722 para generar una señal de video compuesto que se llevará con un cablecito a la entrada del modulador UHF. Esa misma señal estará presente en el bus trasero del Spectrum, como es habitual.

Respecto a VGA: con una CPLD veo varios problemas: uno de ellos es precisamente el timming, que no podría ser el original, puesto que la CPLD no tiene memoria como para un framebuffer que ocupe una línea. Pero lo peor es que a causa de esto, los accesos a memoria dinámica tendrían que ser al doble de la frecuencia (14MHz en lugar de 7MHz) de lo habitual, y eso estaría fuera del alcance de la DRAM incluida en el Spectrum.

Personalmente intentaría ponerle un conector RGB al Spectrum, y usaría un conversor RGB-VGA como los que se usan en proyectos de recreativa para obteener una señal VGA.

Genial. La sugerencia de generar UYV la hice por desconocimiento, creo que es una señal no estándar con la luminancia invertida que solo reconoce la circuitería del spectrum. Si piensas hacerlo directamente en RGB y usar circuitería redundante (AD722) para generar el video compuesto, seguramente generar la señal UYV será bastante más complicado de lo que pensaba.

Respecto a no poder generar VGA directamente usando la RAM lenta del spectrum, me trastoca los planes. Mis planes son muy a largo plazo y posiblemente queden en vaporware. Estoy empezando a ver cómo se programa el OLS http://www.speccy.org/foro/viewtopic.php?f=9&t=2432#p24800 y mi intención es sacar un cuasi-clon del spectrum 16K con salida VGA. Luego implementaría el scroll hardware y la paleta de 16 colores. Mi idea era trasladar el código VHDL de la FPGA a un CPLD para implementar un posible reemplazo de la ULA, pero va a ser que no.

Por ahora sólo quiero aprender y tengo un nivel muy bajo, pero me gustaría aportar todo lo que pueda al proyecto "reemplazo de la ULA", aunque sólo sea a base de ideas.

[Scooter]

Me ha parecido muy interesante este hilo, aunque creo que he entendido como la mitad de lo que se dice.
Pienso que una opción sería el reemplazo de la ULA sin mas (y sin menos) para recuperar equipos viejos.
La otra opción que a mi me resultaría interesante sería un "casi one" chip spectrum que quepa en una carcasa clásica o no; osea un z80, ram estática moderna, flash moderna y una "ULA moderna", al no ser un reemplazo directo creo que se tendría cierta libertad para poner solo salida VGA, olvidarse del cas y el ras etc. Claro que esto sería otro pentagon 1024 o algo así.
El intentar poner una ULA+ en el soket de la ULA lo veo difícil por lo que estáis comentando, bueno y una ULA a secas también.

[antoniovillena]

Me ha parecido muy interesante este hilo, aunque creo que he entendido como la mitad de lo que se dice.
Pienso que una opción sería el reemplazo de la ULA sin mas (y sin menos) para recuperar equipos viejos.
La otra opción que a mi me resultaría interesante sería un "casi one" chip spectrum que quepa en una carcasa clásica o no; osea un z80, ram estática moderna, flash moderna y una "ULA moderna", al no ser un reemplazo directo creo que se tendría cierta libertad para poner solo salida VGA, olvidarse del cas y el ras etc. Claro que esto sería otro pentagon 1024 o algo así.
El intentar poner una ULA+ en el soket de la ULA lo veo difícil por lo que estáis comentando, bueno y una ULA a secas también.

Hola Scooter

La opción de reemplazo de ULA sin más es lo que estábamos discutiendo. La idea de añadir mejoras yo la veo así: si en el mismo CPLD cabe una ULA con añadidos interesantes (con compatibilidad hacia atrás), ¿por qué no? Sería tan fácil como actualizar el firmware. Otra cosa son los añadidos que necesiten un CPLD superior, como ULA+, que también son válidos, pero encarecen y dificultan el diseño del reemplazo de ULA original.

Respecto al one chip spectrum, hay bastantes proyectos sobre zx spectrum en FPGA por la web. Acabo de descubrir este: http://zxprism.blogspot.com/. Con estrictamente 1 chip no se puede: las FPGAs necesitan una ROM donde tener guardada su configuración, un oscilador y un regulador de tensión. Bueno tal vez se pueda, pero sería un chip custom y te gastarías una fortuna sólo en hacer las máscaras.

También pasa otra cosa, que la RAM suele ser limitada dentro de estos dispositivos, y si quieres implementar un modelo 48K tendrías que irte a las FPGAs con mejores prestaciones, y por tanto más caras. Para modelos 128K no hay más remedio que usar RAM externa, con lo que añadiríamos otro chip.

Por último, también sería interesante hacer una implementación en 4 chips: Z80, RAM, ROM y CPLD con todo lo demás. Aparte de ser más barato sería fácil de reparar, tan solo habría que reemplazar el chip que no funcione.

[Scooter]

Bueno, claro, lo bueno de usar un dispositivo programable es que se puede actualizar para corregir bugs o implementar pequeñas mejoras mientras quepan.

[jzx]

Para hacer eso necesitas el reloj de pixel, que en los modelos de 128K lo genera la ULA como señal de 8,8MHz. El problema es que también necesitas saber cuándo se ha terminado de generar el borde y comienza el paper, porque si no, ¿cómo sabes a partir de cuándo se ha de pasar los bits RGB por sendos registros de desplazamiento?

Yo lo que había pensado es simplemente pasar todo por los registros de desplazamiento. En principio el borde también, con lo cual no tienes que contar líneas ni columnas, como el borde es color liso, no importaría. Si quieres efectos de borde, pues entonces sí se verían afectados, pero igual hasta era útil.

Este contador se resetearía en cada flanco positivo del sincronismo vertical. Por cierto, la ULA del 128K entrega los sincronismos compuestos, no separados, aunque quizás usando la señal de interrupción es posible discernir cuándo es uno y cuándo es otro.

No había pensado de dónde sacar el reloj de pixel, pero si la señal de sincro es lo suficientemente rápida de flancos podría valer. Igual no hace falta separar los sincronismos, ya que durante la parte útil del cuadro sólo existe sincro de línea y durante el sincronismo de cuadro, el rgb estará en negro y no importa que no haya sincronización.

Efectivamente, sólo se puede llevar la imagen a la izquierda, pero si empiezas con el retardo máximo y luego vas reduciendolo, volvería a su sitio normal, y el efecto sería de que se mueve a la derecha.

Así creo que no sería muy complejo, aunque tendría el efecto de verse las líneas primera y última dando saltos cada vez que el programa desplace un caracter entero. Ahí es donde se complica la cosa, habría que generar una especie de borde, que tapara estas dos columnas (aquí si hacen falta contadores, y multiplexor).

No sé si esto valdrá, es una idea, pero hacer una ula completa tampoco será fácil

[jzx]

Y otra cosa, ya puestos a diseñar una ula nueva, ¿no sería buena idea meter también los modos de 512 pixels y color de alta resolución del timex? Al fin y al cabo son propios de una máquina real de la época, no un invento moderno (por lo de los puristas).

[mcleod_ideafix]

De momento, vamos a ver si somos capaces de echar a andar una ULA convencional con el mínimo de "trauma" para la placa del Spectrum A partir de ahí, lo que quepa en la CPLD, bienvenido será

Para empezar, aquí estoy haciendo "medidas" de la CPLD que tengo, una XC95144XL en encapsulado TQ100. La CPLD puesta encima de la ULA tiene practicamente el mismo ancho que ésta.


Si se quiere que la plaquita ocupe el mínimo espacio, es menester poner la CPLD en una cara, y la tira de pines con los 40 pinchos de la ULA original, en la otra cara, pero SIN usar tiras de pines "thru-hole" ya que chocarían con la CPLD, así que estoy mirando configuraciones de tiras de pines SMD.

De momento, lo que sí he comprado (aparte de las CPLD que ya tenía) son diodos 1N4148 en formato SMD, que no tengo ninguno, y necesito tres de ellos para mezclar la señal de brillo con las señales R,G,B y obtener así RGB analógico.

Tengo que consultar el libro de Chris para ver cómo es el circuito oscilador, y remedarlo fuera o dentro de la CPLD, a fin de poder usar el cristal de 14MHz existente en el Spectrum. Para el video compuesto no se podrá usar el cristal de 4,43MHz que tiene, sino que habrá que poner uno en la propia plaquita de la ULA. De todas formas, la primera versión que haga será sólo RGB, sin video compuesto.

Una cosa importante a considerar: el encapsulado en el que tengo la CPLD es TQ100. En este encapsulado, la CPLD más grande disponible es la XC95144, esto es, la que se ve en la foto. Si más tarde se diera el caso de que esta CPLD se queda pequeña para determinadas ampliaciones (scroll hardware, raster interrupt, paleta alternativa usando el bit de flash, color en alta resolución, etc.) habría que pasarse a la XC95288, que tiene el doble de recursos que ésta. Lo malo es que la 288 no está en encapsulado TQ100, sino TQ144 como mínimo, con lo que una plaquita que use como huella la TQ100 sólo podría usarse con el 95144. Hasta que no se escriba código con la descripción de la ULA no sabremos con seguridad si merece la pena seguir con el TQ100 o pasarse al TQ144 y así tener la posibilidad de montar una CPLD más grande (y más cara, claro). También la plaquita quedaría más ancha por ser el TQ144 un encapsulado más grande.

Los elementos que tendría esta ULA, como mínimo, serían:
- La CPLD
- Un regulador LDO de 3,3V SMD
- 6 resistencias y 3 diodos, para generar la señal RGB analógica
- Quizás un par de resistencias más para implementar los distintos niveles de tensión de EAR y MIC
- Circuitería no especificada, que me permita usar el cristal de 14MHz existente como oscilador. Si no pudiera, o si la circuitería necesaria fuera mucha (en la ULA original se usan 10 transistores en el oscilador), usaría un cristal de 14MHz + un 74HCT04, una resistencia y dos condensadores. Todo esto en formato SMD.

Las dimensiones de la plaquita serían poco más o menos lo que la ULA original, quizás unos 10mm más ancha (5mm por cada lado). Trataría de poner todos los componentes, excepto la CPLD, en la cara de abajo (aprovechando que la tira de pines eleva un poco todo el conjunto, y que el zócalo de la ULA original suele ser hueco). En uno de los lados cortos de la plaquita estaría el JTAG, y en el otro, el conector RGB.

[antoniovillena]

McLeod he estado investigando en los datasheets y el XC95144XL está disponible en los siguientes encapsulados:
-100 pin TQFP http://www.xilinx.com/support/documenta ... /tq100.pdf
-144 pin TQFP http://www.xilinx.com/support/documenta ... /tq144.pdf
-144 pin CSP http://www.xilinx.com/support/documenta ... /cs144.pdf

El TQFP de 100 y el de 144 tienen el mismo tamaño, por lo tanto el de 144 tiene las patillas más finas. Por lo que he leído por ahí el de 100 se puede soldar a mano ya que los pines son más robustos. Con el de 144 tienes que tener buen pulso porque los pines se doblan con facilidad. Así que para una primera placa de prototipo creo que lo mejor es el de 100.

Luego está el CSP, que es más pequeño y tiene bolitas de estaño por abajo (igual que BGA). Lo malo es que es imposible soldarlo a mano, sería para pedir la placa ya montada. Lo bueno es que tiene el mismo tamaño del XC9572XL y por tanto se pueden usar pines que atraviesen la placa para conectar la ULA. El enrutado no creo que sea muy problemático, porque ni de coña se van a usar los 144 pines, enrutando los pads más externos creo que es suficiente.

Con respecto al cristal, todas las placas que he visto tienen osciladores. En las FPGAs no hay más remedio, puesto que se arranca en modo configuración, y no se pueden crear puertas de la nada sin antes cargar la configuración de la ROM. En CPLDs parece ser que el problema es otro, por lo visto se puede, pero los relojes que se generarían tendrían mala calidad (mucho jitter). Así que yo usaría o bien un oscilador de 14MHz (viene a ser del mismo tamaño que el 74hc04) o bien aprovechar el cristal creando los inversores en el CPLD.

[flopping]

No si al final si nos juntamos 4 ó 5 y nos ponemos en plan "serio", sacamos una ula en poco tiempo, ¿por que hemos tardado tanto en darnos cuenta de eso?, aunando esfuerzos, cada uno podria ir desarrollando una parte del "proyecto", el que sepa programar que programase, el que sepa diseñar, pues eso, y asi con las soldaduras, montajes, etc..
Vamos que yo me ofrezco a hacer lo que pueda, de programacion no puedo ayudar mucho, pero si puedo montar circuitos, hacer pruebas de diseños, etc.. vamos mas electronica que otra cosa.

Yo creo que si juntamos esfuerzos, y repartimos las faenas, este proyecto puede llegar a buen puerto, por lo menos un reemplazo de una ULA normal de momento y cuando se vea que el tema funciona añadir mas funciones si se puede, quiza no se pueda llegar a una ULA+ (o quiza si), pero por lo menos las opciones que estais barajando parecen una buena solucion a ese clonado de ULA.

Pues nada, seguire este post para ver los progresos y si hace falta ayuda, me ofrezco a lo que pueda hacer, a ver si de una vez por todas conseguimos ese clon de la ULA y les damos en las narices a tanto "listo" que hay por el mundo, salu2.

[mcleod_ideafix]

Sigo dándole vueltas al tema, y creo que ya sé por dónde voy a empezar a "prototipar": en lugar de hacer un clon para la ULA del ZX 48K, la haré para el 128K/+2 gris.

¿Por qué? Pues por:
- Es un integrado de 48 pines, lo que significa que tengo más espacio para la CPLD, o para lo que necesite (en realidad, y por lo que voy a contar a continuación, realmente me hará falta más bien poco)
- Su salida de video es directamente RGBI digital, esto es, un bit para el rojo, verde, azul, y el brillo. Fuera de la ULA se combinan para obtener RGB analógico, lo que significa que no necesito diodos ni resistencias para combinar estos valores. También significa que no necesito integrar el conversor RGB-video compuesto, sino que puedo usar el que viene en el propio Spectrum, el TEA2000.
- Su entrada de reloj es TTL, no es un cristal, por lo que no necesito ningún oscilador dentro de la plaquita del clon.
- El 128K es un ordenador más espacioso, tanto en su versión "toastrack" como en la versión +2 gris, así que puedo usar tiras de pines "normales", ya que aunque el circuito suba de altura, no chocará con la carcasa de arriba.
- Puedo disponer de una salida RGBI directa desde los pines de salida de la ULA en el conector DIN, por lo que no necesito meter un conector interno en la propia plaquita.

De hecho, tanto se simplifica la cosa que la plaquita tendría, en esencia:
- La CPLD
- El regulador LDO de 5V a 3,3V
- Condensadores variados para desacoplo.
- Un conector para el JTAG.

Por contra, la lógica que hay que meter en esta ULA sería un pelín más compleja (sólo un poco), al tener que añadir la lógica para que la ULA sepa cuándo usar la pantalla shadow y cuándo no, y algo de lógica para manejar las dos mitades de la ROM de 32K como ROM's separadas. El resto del mapeado y direccionamiento del AY se hace fuera de la ULA, así que de eso no tengo que preocuparme. La gestión del teclado es igual que en modelos anteriores.

[antoniovillena]

Qué buena idea!!! Se simplifican mucho las cosas de esta manera. Incluso puedes hacer el desarrollo con el ordenador cerrado usando el conector del KeyPad como JTAG viewtopic.php?f=5&t=1296#p16051

[mcleod_ideafix]

Qué buena idea!!! Se simplifican mucho las cosas de esta manera. Incluso puedes hacer el desarrollo con el ordenador cerrado usando el conector del KeyPad como JTAG

Ganas de complicarse la vida, ¿no? Cuando puedo hacerlo con el ordenador abierto y la interfaz de teclado PS/2 si necesito escribir órdenes (o incluso sin ella, simplemente pasando los cables del JTAG mediante la ranura del conector trasero, o dejándolo a medio cerrar, simplemente subiendo un poco la mitad superior de la carcasa para descubrir parte de la ULA).

Para hacer lo que dices tendría que trastear en las pistas del ordenador para dejar "libre" el conector del Keypad (que es raro ya de por sí), llevar los pines del JTAG al conector en el Spectrum, y por último, fabricarme un adaptador con el conector de marras hasta el JTAG de Xilinx que tengo... Sinceramente, no veo la ventaja.

[antoniovillena]

Qué buena idea!!! Se simplifican mucho las cosas de esta manera. Incluso puedes hacer el desarrollo con el ordenador cerrado usando el conector del KeyPad como JTAG

Ganas de complicarse la vida, ¿no? Cuando puedo hacerlo con el ordenador abierto y la interfaz de teclado PS/2 si necesito escribir órdenes (o incluso sin ella, simplemente pasando los cables del JTAG mediante la ranura del conector trasero, o dejándolo a medio cerrar, simplemente subiendo un poco la mitad superior de la carcasa para descubrir parte de la ULA).

Para hacer lo que dices tendría que trastear en las pistas del ordenador para dejar "libre" el conector del Keypad (que es raro ya de por sí), llevar los pines del JTAG al conector en el Spectrum, y por último, fabricarme un adaptador con el conector de marras hasta el JTAG de Xilinx que tengo... Sinceramente, no veo la ventaja.

Jaja es cierto. Más que nada es para chulear... mira tengo un spectrum transformer, le meto un cable por aquí y tachán.

Bueno mucha suerte, más de uno estaremos al tanto de tus avances. Creo que sería posible el ULA+ (versión 16 colores) haciendo PWM con el circuito que propones, pero de momento con tener ULA de toda la vida en un CPLD nos daremos más que satisfechos.

[mcleod_ideafix]

Creo que sería posible el ULA+ (versión 16 colores) haciendo PWM con el circuito que propones, pero de momento con tener ULA de toda la vida en un CPLD nos daremos más que satisfechos.

Mmmm..... no estoy seguro. Hay que tener en cuenta algunas cosas:
- La ULA del 128K da una señal RGBI digital, y eso es lo que esperan el TEA2000 y el resto de la circuitería de video. Una ULA+ "drop-in" en el 128K no es posible. Habría que hacer como en la ULA del 48K: generar las señales RGB, sacarlas por un conector, y si quieres video compuesto, añadir un AD722 a la plaquita.
- Por la misma razón no es posible generar una señal RGB analógica por esos pines, ni mediante resistencias DAC, ni mediante PWM.
Las dos anteriores razones pueden omitirse si se olvida uno de la generación de video compuesto y sencillamente saca la señal por el conector RGB, que en el 128K "toastrack" se convertiría de golpe y porrazo en señal analógica, y en el +2 gris habría que configurar los puentes de la placa en modo "standard" (compatible 128K) para tener el mismo tipo de salida. En este modo, el pin de brillo se ignoraría, y por RGB tendríamos una señal analógica.
- Incluso para sólamente 16 colores necesitas 16*8=128 bits de almacenamiento, y la 95144 tiene 144 bits. Habría muy pocos registros para implementar los contadores y máquinas de estado. Si se quiere pensar de verdad en una ULA+ con una CPLD, hay que meter una pequeña SRAM rápida en el conjunto. La más pequeña que conozco es una de 1024x8 bits, a 25ns. Sobradísimo para la ULA+ (que necesita 64x8 bits)

Por otra parte, para generar una señal por PWM hace falta que la frecuencia del PWM sea bastante mayor que la frecuencia de la señal que pretendemos pasar a analógico, y esto en la plaquita que se propone no es posible, ya que la frecuencia a la que han de generarse los píxeles es de unos 7MHz, mientras que el reloj maestro más rápido disponible es de 17MHz. Para generar PWM con una resolución aceptable (8 niveles para cada color primario si queremos algo parecido a la ULA+) necesitaríamos un reloj PWM de al menos 7*8=56MHz. El doble incluso si no se quiere perder demasiada información al filtrar la señal de salida. En este caso, creo que saldría mejor (y además consumiría menos recursos de la CPLD) el sacar una sencilla señal digital con el formato de la ULA+, es decir, 3:3:2 y dejar a la típica red de resistencias que haga su trabajo

[antoniovillena]

Mmmm..... no estoy seguro. Hay que tener en cuenta algunas cosas:
- La ULA del 128K da una señal RGBI digital, y eso es lo que esperan el TEA2000 y el resto de la circuitería de video. Una ULA+ "drop-in" en el 128K no es posible. Habría que hacer como en la ULA del 48K: generar las señales RGB, sacarlas por un conector, y si quieres video compuesto, añadir un AD722 a la plaquita.

Acabo de examinar los esquemáticos http://members.multimania.co.uk/eightbi ... zx128a.png http://members.multimania.co.uk/eightbi ... zx128f.png

Y es verdad. El TEA2000 acepta dos bits por color, dando un rango teórico de 64 colores. Como sólo se pueden dar las entradas 00, 10 y 11 (por el diodo) en cada canal y las entradas 11 se dan en los tres canales (RGB) a la vez, se reducen a 15. En un caso desesperado (un spectrum con la ULA no funcional) sí que se podrían quitar los diodos, cortocircuitar el diodo de bright en un canal, y sacar 2 líneas para los otros 2 canales y así poder mostrar 64 colores por UHF. Con su DAC de 2 bit en caso de querer usar la salida RGB.

- Por la misma razón no es posible generar una señal RGB analógica por esos pines, ni mediante resistencias DAC, ni mediante PWM.
Las dos anteriores razones pueden omitirse si se olvida uno de la generación de video compuesto y sencillamente saca la señal por el conector RGB, que en el 128K "toastrack" se convertiría de golpe y porrazo en señal analógica, y en el +2 gris habría que configurar los puentes de la placa en modo "standard" (compatible 128K) para tener el mismo tipo de salida. En este modo, el pin de brillo se ignoraría, y por RGB tendríamos una señal analógica.

No sé, no me gusta la idea de tener que sacrificar el video compuesto sólo por el ULA+. Vamos que puestos a elegir yo prefiero una ULA normal con ambas opciones de salida de video.

- Incluso para sólamente 16 colores necesitas 16*8=128 bits de almacenamiento, y la 95144 tiene 144 bits. Habría muy pocos registros para implementar los contadores y máquinas de estado. Si se quiere pensar de verdad en una ULA+ con una CPLD, hay que meter una pequeña SRAM rápida en el conjunto. La más pequeña que conozco es una de 1024x8 bits, a 25ns. Sobradísimo para la ULA+ (que necesita 64x8 bits)

Por otra parte, para generar una señal por PWM hace falta que la frecuencia del PWM sea bastante mayor que la frecuencia de la señal que pretendemos pasar a analógico, y esto en la plaquita que se propone no es posible, ya que la frecuencia a la que han de generarse los píxeles es de unos 7MHz, mientras que el reloj maestro más rápido disponible es de 17MHz. Para generar PWM con una resolución aceptable (8 niveles para cada color primario si queremos algo parecido a la ULA+) necesitaríamos un reloj PWM de al menos 7*8=56MHz. El doble incluso si no se quiere perder demasiada información al filtrar la señal de salida. En este caso, creo que saldría mejor (y además consumiría menos recursos de la CPLD) el sacar una sencilla señal digital con el formato de la ULA+, es decir, 3:3:2 y dejar a la típica red de resistencias que haga su trabajo

Pues por lo que cuentas, veo la ULA+ más inaccesible. Lo más lógico que se me ocurre es sacar RGB a 2 bits por canal con la red de resistencias y hacer las modificaciones en la PCB antes propuestas para sacar video compuesto (habría que deshacer si queremos volver a la ULA normal). Aún así necesitaríamos 96 bits para una paleta de 16 colores (84 bits si obviamos los negros 0 y 8 ). Esto nos da 48 ó 60 bits libres, todavía insuficiente para el resto de elementos.

Todavía no me rindo así que seguiré pensando. Siento que tengas que ir corrigiéndome las "ideas felices" que se me pasan por la cabeza. Casi mejor me espero a que tengas la ULA acabada y me digas los bits que te sobran.

Edito: Acabo de darme cuenta de que si hacemos las modificaciones para obtener el video compuesto, habría que hacer otras para llevar las señales RGB directamente desde la red de resistencias al conector RGB, cortando las que provengan de la PCB. Muchas modificaciones sólo por intentar aprovechar el TEA2000