Clon Superfo 128K - Manos a la obra

[antoniovillena]

Hola McLeod

El cambio de 3 contadores 74hc161 por un 74hc4040 está ya probado, lo probó flopping sobre el clon Superfo hace ya un tiempo. Yo también tenía mis dudas, si Chris usó 3 chips en lugar de 1 tendría que tener su lógica. De todas formas los contadores tienen glitches por todos los lados, incluso con los 74hc161 también los tenían, por eso Chris usaba trucos como poner un biestable RS con 2 puertas NAND para amortiguarlos. Yo este circuito lo eliminé y puse otro combinacional, que en el primer prototipo (este es el segundo) me triplicaba el valor del contador vertical, por eso lo cambié por el 74hc166.

Tal vez los tres 74hc161 produzcan menos glitches que el 74hc4040, pero si funcionó en el clon Superfo (en la prueba que hizo flopping) no veo porqué tendría que fallar en este clon. Para hacerlo totalmente síncrono (sin glitches) tendríamos que usar reset síncronos cuando la cuenta llegue a n-1, en lugar de reset asíncronos cuando la cuenta llega a n. Tanto el contador horizontal como el vertical detectan la cuenta 448 y 312 respectivamente, creando un pulso muy estrecho que se encarga de resetear el contador. El problema es que la lógica para detectar 447 y 311 requiere más puertas.

Por otro lado la idea de sintetizar el circuito es muy buena, así podemos anticipar errores o comprender los errores que aparezcan. Yo puedo hacer mediciones con el osciloscopio, pero el mío es muy lento, de 8Mhz creo. También tengo el analizador lógico OLS, aunque sólo compré un juego de pinzas, por lo que sólo puedo muestrear 8 señales.

Seguro que en cuanto montes la placa detectas rápidamente el fallo, yo suelo ser muy malo para este tipo de cosas. Por ejemplo le he estado dando muchas vueltas a mi problema con el video, cuando al final era una tontería de un pin mal soldado. En este caso el error también lo ha reproducido Superfo, igual es una tontería o algo más serio del diseño, el problema está en descubrir el origen del error. Mientras más personas seamos haciendo pruebas, más difícil es que nos atasquemos más de lo necesario.

Mañana probaré lo de poner el dedo, lo del hielo no lo veo muy viable. No tengo nevera donde hago las pruebas, y puede venir un cliente y para cuando vuelva ya se ha derretido. Para que te hagas una idea, hay veces que tengo el soldador encendido toda la mañana y sólo hago 10 soldaduras. Si lo apagase cada vez que entra un cliente en lugar de 10 haría 5, porque pierdo un par de minutos mientras se calienta.

[mcleod_ideafix]

Por otro lado la idea de sintetizar el circuito es muy buena, así podemos anticipar errores o comprender los errores que aparezcan. Yo puedo hacer mediciones con el osciloscopio, pero el mío es muy lento, de 8Mhz creo. También tengo el analizador lógico OLS, aunque sólo compré un juego de pinzas, por lo que sólo puedo muestrear 8 señales.

Gracias! Bueno, de momento obviaré los glitches. Ahora he llegado a donde llegásteis vosotros: el borde que no se genera bien.

Esto es lo que pasa: para fijar ideas, en mi simulación la memoria de video siempre devuelve el valor 01010101, tanto si se lee la parte de bitmap como si se leen los atributos. El registro de 3 bits que contiene el borde vale 111.
Esto significa que si todo funciona bien, una línea cualquiera de las 192 que contienen borde y paper debería verse:
- Borde izquierdo a 7
- 256 píxeles alternando entre el color 5 (tinta) y 2 (paper)
- Borde derecho a 7
- Zona de blanking horizontal en alta impedancia (U31 se queda en alta impedancia)

Pues bien, lo que obtuve fue esto:

Fijaros sobre todo en las dos últimas señales: pixel es una señal que indica si el pixel que se está pintando está encendido o apagado. Mientras se pinta el borde está apagado. Si se enciende, se pinta en color de tinta, y si se apaga, en color de paper. Esta captura corresponde al periodo de tiempo en el que pintamos el borde izquierdo, y a continuación empezamos a pintar el paper. La línea que se dibuja es la 3 (mirar el valor del contador VC)

El borde debería pintarse en color 7, sin embargo se pinta con color 2, es decir, que se retiene el último valor que se usó de paper.

Un zoom a esta parte del cronograma evidencia aún más problemas:


El borde se pinta, como ya se ha dicho, con el último color de paper usado. La señal vout indica, si está a nivel bajo, que toca pintar píxeles (es decir, que hemos entrado en paper). Pues bien, los 8 primeros píxeles se pintan con colores equivocados (no sé si llegaste a ver algo de esto en las primeras pruebas). El registro que contiene los colores a mostrar (U34) se actualiza en cada pulso de outlatch, pero resulta que en el diseño actual, outlatch sólo se tiene en cuenta si ya ha bajado vout. Como se puede ver, vout baja justo después de que baje outlatch, con lo que los primeros 8 píxeles aún no se pintan con sus colores correctos. En la segunda bajada de outlatch, vout ya vale 0, así que esta vez sí que se actualiza.

Dejemos por un momento vout. La señal outlatch tiene otro problema: no hay pulsos de outlatch durante la generación del borde. Esto es malo porque si no hay pulsos de outlatch, el color del borde no se carga en el registro U34. En el diseño original esto no era problema, porque el borde no se procesaba hasta el final, en el último multiplexor que elige entre color de borde o paper, pero en este diseño se puso antes.

La solución de Antonio Villena, si no he leído mal, consiste en volver a poner el borde en la última etapa, a la salida de U34. Esto es: mover las 5 resistencias de 470 ohmios para que se conecten a los pines correspondientes pero del lado de la salida del registro U34. U34 ahora no estará siempre habilitado, sino que se activará o no según el valor de vout, como ocurre con U35. Algo así:


Bueno, pues he estado mirando la forma de minimizar el número de cortes y puentes para obtener el mismo resultado: esto es a lo que he llegado, en base a lo que tengo hasta ahora simulado.

El primer problema, que outlatch no da pulsos durante la generación del borde, se soluciona usando una versión de outlatch que dé pulsos todo el tiempo. Para ello, hay que mirar qué parte del circuito es la que "silencia" a outlatch cuando no se genera paper. Y la he encontrado aquí, en U10B. Esta puerta OR, que es la que genera en última instancia outlatch, es la que la deja a 1 cuando no se genera paper. Si cojo outlatch justo antes de esta puerta OR (es decir, en la salida de U9D) obtendré una señal outlatch sin interrupciones. Esta señal es la misma que se usa como reloj para U22B.


El comportamiento de esta señal se puede ver en este cronograma:


la señal rotulada como outlatch sigue siendo la versión original. La nueva outlatch que usaremos en U34 es la señal rotulada como clku22b. Puede verse que no se interrumpe cuando deja de generarse el paper. Aquí aún no se está usando clku22b para el reloj de U34, pero en cuanto se use, el valor del borde será el correcto.

Sin embargo, seguimos teniendo el problema de que los 8 primeros píxeles se pintan mal. Esto ocurre porque los valores leídos de memoria en U35 (los atributos de esos primeros 8 píxeles) no se vuelcan en U34 hasta que no baja vout. En resumen: vout baja 8 ciclos más tarde de lo que desearíamos. La solución es usar una versión de vout que baje 8 ciclos antes.

Afortunadamente también la tenemos: es la señal de entrada al registro U22B. U22B precisamente se encarga de retrasar vout 8 ciclos de reloj. Ahora, ese retraso no nos interesa.

Así, si usamos en U35 la señal vout sin retrasar (es decir, la salida de u22a), obtenemos esto:


He dejado el vout original con su nombre, y el "nuevo vout" está rotulado como u22a. Se puede ver que el primero baja 8 ciclos después que el segundo.

Los cambios a hacer en el circuito, a priori, son menores que con la modificación de Antonio (dos cortes y dos puentes, aunque luego en la placa real puede que sean más, depende de cómo estén rutadas las señales a cortar). Además, tiene el "efecto colateral" de hacer que sobre el biestable U22B (creo que vout no se usa en ningún otro sitio salvo en U35, ¿no?).


El cambio de outlatch sólamente afecta al reloj de U34. El resto de integrados que usan outlatch siguen usando la versión "silenciada".

Los cronogramas tienen esta pinta ahora:

- Una línea cualquiera de video (la línea 2 en este caso), que tenga borde y paper:


- Las dos últimas líneas de pantalla con paper (líneas 190 y 191) seguidas por unas cuantas líneas que sólamente tienen borde (de la 192 en adelante):

[antoniovillena]

En dos palabras ... IM PRESIONANTE. Al comenzar a leer pensaba: -este no se ha enterado que el borde ya funciona. Pero luego me di cuenta lo que estabas haciendo. Mi intención al poner el borde en la etapa anterior era tener un comportamiento fiel a la ULA original, la cual también mete el borde ahí y por lo tanto sólo se actualiza cada 8 píxeles. Al ver que la cosa no funcionaba, volví al diseño del Superfo original, es decir meter el borde en la última etapa y por tanto se actualiza de forma inmediata. No es que esté mal que se actualice de forma inmediata, pero estos pequeños detalles son los que hacen que el clon no sea del todo exacto.

El primer prototipo no llegó a funcionar, o mejor dicho no llegó a arrancar porque el video sí que se mostraba, por lo que no pude apreciar el problema del borde. Al ver que el fallo del borde en este segundo prototipo no llegué a pensar que podía arreglarse usando señales ya generadas, por eso me fui a lo más fácil que es deshacer los cambios.

Lo que más me ha impresionado es el método que has usado, de esta forma se pueden verificar cambios antes de hacerlos, es todo un lujo. Bueno ya que estás, hay una optimización que tengo en mente para quitarnos del medio la puerta U6D, que seguramente te llevará menos tiempo a tí simularlo que a mí probarlo. Se trata de conectar directamente la señal "Den" a la entrada D del biestable, la salida de la XOR a la entrada /PRE (set asíncrono) del mismo biestable.

[Hark0]

Yo si que estoy impresionado... PEDAZO HILO!

Bravo tíos... sois unos máquinas

[vtsartas]

Yo si que estoy impresionado... PEDAZO HILO!
Bravo tíos... sois unos máquinas

No solo eso... está siendo como un parto (esperemos que no dure 9 meses, claro) ¡Deseando que nazca el bebé!

[Gatuso]

Creo que estoy aprendiendo mas en este hilo que en los cinco años de carrera

Bravo por todos

[Lex Sparrow]

Creo que estoy aprendiendo mas en este hilo que en los cinco años de carrera

Bravo por todos

Lo mismo me pasa a mí. Pensaba que el Orcad sólo se usaba para hacer simulaciones de puertas lógicas sencillitas. Me está gustando ver pintado algo interesante.

[mcleod_ideafix]

Lo mismo me pasa a mí. Pensaba que el Orcad sólo se usaba para hacer simulaciones de puertas lógicas sencillitas. Me está gustando ver pintado algo interesante.

Esto no se ha hecho con OrCAD (aunque por lo que me enseñó Don Superfo parece ser que sí puede simular sistemas más o menos complejos hechos con puertas lógicas). Esto está simulado con iSim, que es un componente del entorno de desarrollo ISE de Xilinx. El circuito se ha descrito enteramente en Verilog.

[jjsaenz1969]

Yo también estoy flipando en colores.
Y tengo que decir que en su día saque una fp2 en electrónica industrial.
Pero todo esto para mi es completamente nuevo. Me encanta como va el proyecto, es como retransmitido. Día a día, segundo a segundo. Cada vez que me conecto hay un avance nuevo.
Ánimo a todos, sois cojonudos.
Otra cosa, antoniovillena me encanta tu osciloscopio.

[antoniovillena]

Pues el osciloscopio me costó poco más de 100 euros en aliexpress.com, aunque el ancho de banda es limitado (8MHz).

Esta mañana no he podido probar nada, a ver si hay suerte mañana. He creado la imagen del remiendo de McLeod. Yo no lo voy a aplicar porque ya he hecho el otro, pero es mucho mejor que el que yo indiqué (3 cortes / 3 puentes frente a 8 cortes/8 puentes).

Edito: Si no me equivoco, U22B ya no se utiliza, por lo tanto ahora nos sobra un biestable. Este biestable nos puede venir de perlas para implementar el sistema antirrebotes del botón NMI.