Clon Superfo 128K - Manos a la obra

[mcleod_ideafix]

Sea como fuere: ¿podeis comprobar si es posible, esta demo en el clon físico y ver si se pasa lo mismo que en la simulación?

Claro que sí. Otra cosa más que apunto para hacer la semana que viene. Claro que es posible, el puerto EAR funciona (aunque yo todavía no lo he probado).

Gracias! A modo de curiosidad, si se ponen los jumpers para NTSC, el resultado es éste (2 segundos de animación, que en el GIF sale más lento)


Un desastre, como se ve En NTSC tenemos 264 líneas en lugar de 312 (totales), y la interrupción ocurre en la CPU 60 veces por segundo. Resultado: la rutina temporizadora de la demo se vuelve loca (quizás si la simulación se ejecutara desde el mismo comienzo de esta parte de la demo, donde primero hace un cálculo de los timmings, se vea mejor)

Para que no se produzca el glitch. Este fenómeno no ocurre en el clon 48 debido a que entre HCa y HC0 no existe ningún desfase (hay un HC161 que no es ripple counter)

Gracias! Probaré entonces con un contador que se comporte así, a ver...

PD: 30 páginas ya de posts en este hilo, a 10 posts por página... ¡300 posts friqueando sobre el clon !

[antoniovillena]

Miento, no es Thold lo que hay que mirar, sino "propagation delay" entre cCP y nQ, que es de 14ns en el caso de un 74HC74.

-- Actualizado 21 Abr 2013, 10:16 --

Un desastre, como se ve En NTSC tenemos 264 líneas en lugar de 312 (totales), y la interrupción ocurre en la CPU 60 veces por segundo. Resultado: la rutina temporizadora de la demo se vuelve loca (quizás si la simulación se ejecutara desde el mismo comienzo de esta parte de la demo, donde primero hace un cálculo de los timmings, se vea mejor)

Es un pena que en el clon no podamos hacer esta prueba. Le hemos quitado el inversor para arreglar el bug de la basura, y además necesitaríamos un cristal de cuarzo de 14.11MHz, a ver de dónde conseguimos semejante cristal.

-- Actualizado 21 Abr 2013, 10:19 --

PD: 30 páginas ya de posts en este hilo, a 10 posts por página... ¡300 posts friqueando sobre el clon !

Otros 300 post más y acabamos sintetizando el clon en un PIC 16F84

[mcleod_ideafix]

además necesitaríamos un cristal de cuarzo de 14.11MHz, a ver de dónde conseguimos semejante cristal.

Si la tele es un poco permisiva, con 14MHz podría funcionar. Fíjate que mi monitor 1084, que no es multinorma ni nada de eso, se traga perfectamente una señal NTSC. Por video compuesto la veo en blanco negro, obviamente, pero por RGB la veo en color. Seguro que se tragaría una señal cuasi-NTSC como ésta.

De todas formas.... ya veis que os perdeis poco ¿Superfo está usando PAL o NTSC en su clon?

[antoniovillena]

¿Superfo está usando PAL o NTSC en su clon?

Supongo que PAL. Si no, no podría haber aplicado el fix para arreglar el problema de la basura.

[TallerSeverino]

Buenas.
Como había leído en otro post, buscaré un sombrero para quitármelo, madre mía que dominio de lo digital.
Sin haber mirado hojas de características de las puertas, recuerdo vagamente que para hacer los diseños de tiempos había que tener en cuenta dos parámetros de propagación, el mínimo y el máximo, y hacer los cálculos para los dos casos, "Diseño en caso peor" que se llamaba, imagino que el 4040 del contador de píxeles es u38 en la revisión "A" que me la tengo imprimida pero tengo que rectificar los cambios que se han hecho.
Rectifico, estoy mirando un datasheet del Hc04 a modo de ejemplo y los Tpd son sólo típicos y máximos dependiendo de Vcc, por lo que habría que tener en cuenta los tiempos máximos y los típicos, pero al ser la condición <= serían los máximos, voy a rectificar el esquemático con los cambios y a hacer números.
Imagino, por otra parte que el software de Verilog debe ser bastante potente como para caracterizar los retardos en caso mínimo y máximo, voy a mirar las características y las señales para ver los retardos máximos y releerme el post.
Un saludo.

[mcleod_ideafix]

Imagino, por otra parte que el software de Verilog debe ser bastante potente como para caracterizar los retardos en caso mínimo y máximo, voy a mirar las características y las señales para ver los retardos máximos y releerme el post.

Sí. Puedo especificar retrasos en cualquier señal, con resolución de picosegundos. La cosa es que no he puesto retrasos en todas y cada una de las señales que he puesto. Tan solo en algunos de los chips. Otros (por ejemplo las puertas que calculan el CLR de los contadores, o todo lo relativo a la generación de imagen) se han modelado como dispositivos ideales, más que nada por pereza, sino me saldría una descripción mastodóntica propensísima a errores de transcripción, y es que la forma en la que he usado Verilog no a la que estoy acostumbrado. Yo he usado aquí un esquema RTL (especificar las partes del circuito y cómo se conectan entre ellas) en lugar de un esquema basado en el comportamiento (especificar cómo se comporta el circuito, y dejar que sea Verilog quien infiera los componentes y la forma de conectarlos).

[TallerSeverino]

Sí. Puedo especificar retrasos en cualquier señal, con resolución de picosegundos. La cosa es que no he puesto retrasos en todas y cada una de las señales que he puesto. Tan solo en algunos de los chips. Otros (por ejemplo las puertas que calculan el CLR de los contadores, o todo lo relativo a la generación de imagen) se han modelado como dispositivos ideales, más que nada por pereza, sino me saldría una descripción mastodóntica propensísima a errores de transcripción, y es que la forma en la que he usado Verilog no a la que estoy acostumbrado. Yo he usado aquí un esquema RTL (especificar las partes del circuito y cómo se conectan entre ellas) en lugar de un esquema basado en el comportamiento (especificar cómo se comporta el circuito, y dejar que sea Verilog quien infiera los componentes y la forma de conectarlos).

McLeod, ese software es mucho más complejo de lo que tenía en mente, voy a ver si con un segundo café se me aclara la mente y hago los números y las rectificaciones en el esquemático. Retrasos de picosegundos es una resolución inimaginable para la velocidad del clon, lo que da idea de la potencia del software. Vaya tela.. marinera, en el buen sentido claro.

Un saludo.

[jepalza]

Sea como fuere: ¿podeis comprobar si es posible, esta demo en el clon físico y ver si se pasa lo mismo que en la simulación?

Yo no puedo ponerme a hacer mas cosas al invento, estoy preparando el viaje a Polonia, salgo esta tarde a las 15:00 y vuelvo el jueves noche. Hasta el Viernes tarde no puedo hacer nada mas.
Me sacaréis ventaja en estos cinco días.
(os seguiré desde el hotel por las tardes-noches)

[josevall]

Madre mía,¿pasaría Richard Altwasser por todo esto? ,jejejejeje

Saludetes

[mcleod_ideafix]

McLeod, ese software es mucho más complejo de lo que tenía en mente...

Es que es un entorno de desarrollo completo. Y eso que es la versión gratuita. Ni idea de cómo será con el ModelSIM (que te permite meter un analizador lógico construido en la propia FPGA que vas a testear), o con el sistema de desarrollo para MicroBlaze (un microcontrolador que existe como código sintetizable en una FPGA, pero que una vez metido dentro de ella, puedes meterle programas compilados con un compilador de C que trae, o en ensamblador mismo).

Este es el editor, cuando escribo en Verilog (Verilog es el lenguaje, no el nombre de la aplicación)

Seguramente podreis reconocer algunas construcciones. Parte de lo que se ve aquí usa descripción RTL (sobre todo la parte en la que uso circuitos 74HCloquesea y los conecto a cables) y parte es descripción mixta RTL/comportamiento (la parte de abajo, donde se ve cómo funcionan los jumpers para elegir PAL o NTSC. En estos jumpers uso un operador que es análogo al operador ternario de C: (a)? b : c . Esto se traduce en que la expresión vale "b" si "a" es cierto, en otro caso, vale "c". Es una construcción muy usada para implementar multiplexores. Un jumper con dos posiciones no es más que un multiplexor en donde la entrada de control es nuestra mano que cambia el jumper de sitio.

Cuando simulo el circuito, puedo moverme a izquierda y derecha por el cronograma. Puedo añadir señales (están a la izquierda), agruparlas (por ejemplo, todas las de la ROM, todas las de la SRAM, etc) para mostrarlas u ocultarlas según me convenga, añadir cursores para medir tiempos, etc. Aquí estoy trabajando con una resolución de 20ps (las marcas pequeñas, las grandes están a 200ps). Lo que se ve es un ciclo de bus de búsqueda de instrucción (dos ciclos de reloj para leer la instrucción, y otros dos para el ciclco de refresco). El cursor amarillo está puesto en el instante justo en que el Z80 captura el dato de la ROM.


En la imagen anterior se observa un glitch (arriba a la derecha) en el valor del contador HC al pasar de 127 a 128. Puedo hacer zoom sobre esa parte del cronograma hasta tener una resolución de 1ps y ver cómodamente qué valores va tomando HC hasta que se estabiliza. El glitch está enmarcado por los dos cursores, que me dan su duración: 56 ns.


-- Actualizado 21 Abr 2013, 13:01 --

Yo no puedo ponerme a hacer mas cosas al invento, estoy preparando el viaje a Polonia, salgo esta tarde a las 15:00 y vuelvo el jueves noche. Hasta el Viernes tarde no puedo hacer nada mas.
Me sacaréis ventaja en estos cinco días.
(os seguiré desde el hotel por las tardes-noches)

¡Suerte con el tema! Yo aún no lo he montado del todo. Me faltan unos cuantos chips. Me da a mi que al final cogeré y pondré una CPLD en lugar de los chips que me faltan (o de toda la circuitería de control de video) a ver qué pasa