Clon Superfo 128K - Manos a la obra

[antoniovillena]

Pues como sea eso chico, menudo descubrimiento. Es como cuando se inventó el "post-it" por accidente.

A ver, es una intuición, todavía no es seguro, habría que confirmarlo. Olviden lo último que he dicho del fanout, el chip que falla (U29) no va al bus de datos sino al bus VA8..14, VCS, VRD. Puede que alguna de estas 2 señales (VCS, VRD) sea crítica, y con el circuito LS lo sea menos. Lo que sí puedo probar mañana es aumentar y disminuir R10 y R11 (probar con una resistencia de 5.6K y luego con otra de 15K) y volver a ejecutar los tests de RAM.

[radastan]

Bueno, vamos a pensar con la cabeza y no pensemos en milagros. La serie 74HCxx se diferencia de la 74LSxx en dos cosas teóricamente: los HC son más rápidos y consumen menos.

Si va con el 74LS245 y no con el 74HC245 lo suyo es ver en que se diferencian dato por dato para encontrar el "milagro". Para empezar vamos a ver que demonios es el 74xx245, independientemente de su tecnología de fabricación:



Se trata de un buffer triestado, que transfiere los datos de un lado a otro según dos señales de entrada (uno para activar el "trasvase" y otra para indicar el sentido). A nivel de pineado y esquema interno el 74LS245 y el 74HC245 son exactamente iguales, por lo que los pines y las señales de mando no cambian, veamos los parámetros:

74HC245 -> Velocidad de propagación: 7 ns (10ns en el 74HCT245) para 5V Vcc

74LS245 -> Velocidad de propagación: 8 ns para 5V Vcc (12ns para Vcc de 5.5 V)

¡Tachán! Ahora es cuando Jepalza nos tiene que decir con la mayor exactitud posible que tensión de Vcc está usando, porque cada milivoltio cuenta en saber cuanta velocidad de propagación está teniendo. El problema parece ser que el buffer pasa los datos antes que éstos estén en el bus, es demasiado rápido, por lo que coge los datos que hubiera antes.

A ver si me llegan las resistencias de 1K, o me puedo pasar a por ellas mañana, y de paso veo si tengo algún 74LS245 por aquí para probarlo yo también (de la serie LS tengo un buen puñado de referencias).

[flopping]

No se, pero a mi me da que eso no influye demasiado en este tema, ademas, un solo integrado que nos fastidie todo, no lo veo muy claro, creo que debe de haber algo mas que se nos escapa o la influencia de varios integrados o valores de resistencias, quizas, a lo mejor las tolerancias o algo asi, yo monte el antiguo clon de 48K, con practicamente todo integrados LS y tambien con HC y funcionaban exactamente igual, lo unico es que con LS consumia 500mA y con HC 100mA, incluso mezcle LS y HC y no habia diferencia, todo funcionaba igual, una cosa tambien que podria ser, son las velocidades de propagacion de las memorias usadas, tanto RAM como Eprom o Eeprom, quiza hay si que este la diferencia, es cuestion de hacer algunas pruebas mas.

Por cierto convendria colocar al principio del hilo, los cambios a realizar, para no tener que leerse todo el hilo, ya que esta todo un poco disperso, una pregunta que queria hacer es si segun Mcleod_ideafix, sobre el papel, con la emulacion que ha realizado, no hay gliches y tdo funciona perfectamente, ya que los contadores emulados son perfectos, no asi los reales, si en los reales hay gliches y eso nos hace que aparezca basura en el clon, entoncesm si yo uso los antiguos contadores del clon original de 48, es de suponer que no tendre gliches y que no me haria falta cortar las pistas y hacer los puentes para quitar la basura, ¿correcto?, ya que segun se ha comentado los antiguos contadores son sincronos y no producen gliches, eso si tendre que usar 3 contadores (3 integrados) en lugar de uno, ¿eso es asi o estoy equivocado?, aunque como ya vimos en el antiguo clon, cambiamos los 3 contadores por uno de los de ahora y el clon 48 seguia funcionando exactamente igual, eso lo verifique yo mismo, por eso me extraña que aqui este dando problemas, pero bueno, ¿si hago esa prueba, no corto pistas de la basura ok?, evidentemente las pistas del borde si que tendria que cortarlas, pero no las de la basura.

En fin, vere si puedo montar el mio y pruebo a cambiar integrados HC por LS y memorias Eprom por Eeprom y tambien de diferentes velocidades, por si influyeran en algo y asi vamos descartando cosas, salu2.

[antoniovillena]

Para que quede claro el tema de los contadores. Tanto los 161 como los 4040 son síncronos. Lo único que es asíncrono son los resets de los chips, pero lo es en ambos. Los 161 se pueden configurar para que hagan el reset síncrono mediante la carga en paralelo, pero no están configurados así.

Tampoco presentan glitches a las salidas (ni el 161 ni el 4040). La única diferencia es que en el 161 todas las salidas cambian a la vez, mientras que en el 4040 lo hacen primero los bits de menor peso, hay un retardo en la propagación. Y el retardo es acumulativo, si cambian 8 bits (por ejemplo de 255 a 256) habría que multiplicar por 8 dicho retardo. Con los 161 tampoco estamos libres de estos retardos, pero pasa en grupos de 4 bits (porque hay 3 contadores en cascada). Por ejemplo HC1 y HC2 cambian a la vez con contadores 161, pero no HC2 y HC3. Para el caso peor se multiplica por 3 dicho retardo (y no por 8 como en los 4040).

Donde pueden existir glitches es en salidas combinacionales que dependan de distintas señales HCx, aunque el diseño tiene eso en cuenta para que no nos den problemas. De todas formas hasta ahora no he visto ningún problema por tener un 4040 en el contador horizontal, tengo el clon superfo 48 con el reemplazo 161->4040 permanente y funciona correctamente.

-- Actualizado 22 Abr 2013, 21:32 --

@flopping la lista de cambios está publicada en la primera página del hilo. Yo no puedo editarla porque el hilo no lo abrí yo, pero radastan y jepalza sí que pueden y la tienen actualizada. También hay otra lista en el hilo de speccy.org. Soy consciente de que este proyecto está desparramado en varios foros, y sé que es un coñazo tener que leerse un hilo entero para montar la placa, lo siento. De todas formas el hilo más completo es éste (es el que te recomiendo que leas), porque es el que tiene más fotos. Por ejemplo aquí está el montaje paso a paso de mi placa, la construcción de los cables de video y los mods que ha hecho jepalza muy bien explicados.

[jepalza]

Trato de explicar "el milagro": cuando hicimos los puentes para evitar el lío de /AL y AL, todo iba mas o menos bien con unos puentes chapuceros que hice. Los quité uno a uno y los fuí sustituyendo por unos definitivos para "la foto oficial en ZDP", pero olvidé uno de ellos, y no lo probé, lo dejé y me fui a la cama.

Al día siguiente, soldé el puente que faltaba, retoqué la foto, arranqué el Spectrum... y "milagro", de repente no enciende, salen colorines en pantalla, cuando el día anterior si funcionó con los puentes temporales.

Repasé los puentes, y no había fallo, pero al rato de tenerlo encendido con colorines bailando en la pantalla, el HC se calentaba. Lo apagué y lo dí por muerto, lo sustituí por un LS, y se obró "El Milagro", volvió a la vida.

Con el LS TODO el tiempo puesto, he hecho las pruebas de RAM, las de CF, he cargado juegos por el EAR en los tres modos, 16k, 48k y 128k todo correcto.
En una de esas, me da la tontería de volver a poner el HC "supuestamente" estropeado, y ocurrió el mismo síntoma, que arranca con colorines, y una de cada tres por deciar algo, me dejar incluso teclear, pero acaba muriendo al tiempo.

Ahí lo dejé, volví a poner el LS, y con este, todo bien, luego hice algunas pruebas mas de RAM en el modo Amstrad, apagué y me vine a Polonia.
(Por cierto Radastan, las pruebas de voltajes, el viernes, que no llego a casa hasta el jueves noche )

Y esa es la historia, con un HC y los puentes que corrigen la basura por el lío /AL y AL, no arranca bien, pero con un LS arranca bien SIEMPRE (el 99% de las veces).
Nota: pero el AL siempre en el zócalo mas cercano a la CPU, no en el de al lado (no tengo foto y no sé cuál es)

[radastan]

Por cierto convendria colocar al principio del hilo, los cambios a realizar, para no tener que leerse todo el hilo, ya que esta todo un poco disperso

Es que eso he echo desde el principio ¿me falta alguno?

[mcleod_ideafix]

Para que quede claro el tema de los contadores. Tanto los 161 como los 4040 son síncronos.

No, no lo son. El 4040 es un contador asíncrono: las salidas no se actualizan a la vez. En el 161, todas se actualizan a la vez. Ambos tienen un clear asíncrono (que actúa independientemente del reloj del contador).
En el diseño interno del 4040 y del 161, la diferencia entre síncrono y asíncrono hace referencia a qué relojes actúan en los biestables de dichos contadores: en el 161, la señal de reloj es la misma para todos los biestables (por eso se llama síncrono). En el 4040, es la salida de cada biestable la que hace de reloj para el siguiente biestable (los relojes son por tanto diferentes, así que el contador se llama asíncrono). Quizás el término no sea muy afortunado sobre todo cuando en electrónica digital se usa más el término "asíncrono" referido a sistemas en los que no hay reloj (lo que hay en su lugar son señales de handshaking), y por eso confunde el hecho de que un dispositivo con reloj pueda ser llamado "asíncrono".

Tampoco presentan glitches a las salidas (ni el 161 ni el 4040). La única diferencia es que en el 161 todas las salidas cambian a la vez, mientras que en el 4040 lo hacen primero los bits de menor peso, hay un retardo en la propagación. Y el retardo es acumulativo, si cambian 8 bits (por ejemplo de 255 a 256) habría que multiplicar por 8 dicho retardo.

Ese comportamiento es el que hace que los 4040 tengan (más) glitches que el 161. De hecho, los tres 161 del superfo original siguen siendo un contador síncrono, porque fíjate que la señal de reloj se aplica a todos por igual. No hay "cascadeo" en la señal de reloj. Donde sí hay "cascadeo" es en la señal de carry out, pero como esa señal se aplica a una entrada síncrona en el siguiente contador, el conjunto de los tres forma un contador monolítico con los mismos retrasos de reloj a cada una de las salidas (no se acumulan retrasos ni siquiera de un chip al siguiente).

Donde pueden existir glitches es en salidas combinacionales que dependan de distintas señales HCx

Sí. Sobre todo si el circuito combinacional tiene caminos más cortos para una señal que para otras. En cualquier caso, el hecho de que el 4040 sea en cascada acentúa los retrasos que pueden producirse en los circuitos combinacionales que dependen de las salidas de él.

aunque el diseño tiene eso en cuenta para que no nos den problemas.

Eso también es cierto, al menos en lo que he visto del contador vertical (VC8 es la última que se actualiza, y si lo hiciera a la vez que las demás, al tener el camino más corto en el circuito de reset de ese contador, el contador se resetearía a las 256 vueltas en lugar de a las 312). En el contador horizontal, las tres señales que se usan en el reset tienen el mismo camino: al ser las señales correspondientes a los bits más significativos, el contador se queda en el valor 312 durante bastantes nanosegundos (unos 50 o así) antes de que la puerta AND de tres entradas "vea" tres 1's y haga saltar al clear del 4040.

En la simulación, y como ya he comentado, por pura vaguería, no he implementado retrasos en todas y cada una de las señales que uso: tan solo en los chips más "gordos". Comprendedme... estoy empezando como quien dice con el tema de Verilog como simulador (en síntesis no se usan retrasos) y aún no domino la sintáxis para especificar retrasos aquí y allá

Flopping: en mi simulación no he encontrado un solo glitch en video. La única cosa que he cambiado respecto al circuito original del esquemático es el tema de la generación de outlatch para que el borde se genere correctamente. Las cosas que ha hecho jepalza, por ejemplo, para eliminar los glitches, yo no las he implementado (basicamente lo de cambiar la forma en la que se generan AL y /AL. Probablemente, cuando incorpore retrasos a esas señales, sí que vea "cosas raras".

[antoniovillena]

Tienes razón. Ahora me acabo de dar cuenta que síncrono y asíncrono también se pueden aplicar al propio contador, en el sentido de que los asíncronos son los "ripple" y los síncronos son los que tienen el mismo reloj en todos sus biestables y hacen "look ahead carry". Lo que pasa es que para evitar confusiones, en los datasheets se suele especificar "ripple" cuando es asíncrono y nada cuando es síncrono. Para mas inri los contadores tienen a su vez carga paralela y reset, y dependiendo de si ésta se produce "sinconizada" con el reloj también puede ser síncrona o asíncrona. En teoría se pueden dar las 8 combinaciones: reloj síncrono/asíncrono, carga síncrona/asíncrona, reset síncrono/asíncrono. En la práctica sólo los he visto de 3 tipos:

• Contadores asíncronos sin carga y con reset asíncrono.
• Contadores síncronos con carga síncrona y con reset asíncrono.
• Contadores síncronos con carga síncrona y con reset síncrono.

También es verdad que los 161 comparten el reloj y se actualizan a la vez todas las salidas. En teoría con el 4040 como reloj horizontal deberíamos ver glitches por todos los lados (me refiero a la lógica combinacional que hace uso de HCx), sin embargo esto no ocurre en la práctica. Por ejemplo la señal Outlatch se genera con los 4 bits inferiores y su salida va a la entrada de reloj del contador que genera las direcciones de memoria. Cualquier glitch aquí sería visible.

-- Actualizado 23 Abr 2013, 02:41 --

Creo que he encontrado una explicación, la secuencia de los 4 bits bajos de un contador "ripple" como el 4040 es esta:

Código: Seleccionar todo

0000-0
0001-1
0000*0
0010-2
0011-3
0010*2
0000*0
0100-4
0101-5
0100*4
0110-6
0111-7
0110*6
0100*4
0000*0
1000-8
1001-9
1000*8
1010-A
1011-B
1010*A
1000*8
1100-C
1101-D
1100*C
1110-E
1111-F
1110*E
1100*C
1000*8
0000-0
...


Con guiones está la secuencia correcta, y con asteriscos los glitches. La secuencia de glitches es ésta:

Código: Seleccionar todo

02046408A8CEC8

Todos los números son pares, lo que quiere decir que cualquier combinacional que active sólo una secuencia impar está libre de glitches, como por ejemplo la señal que genera Outlatch, que activa la secuencia 0101 (5).

[TallerSeverino]

Buenos días.
Esa cuenta del 4040 debe ser su funcionamiento normal antes de dar la cuenta definitiva, pero vamos, viendo que son 27ns desde clk14 hasta HCa y 8 ns adicionales para cada bit más alto, esa cuenta "espúrea" debe entrar dentro de los 27ns de incertidumbre a la salida en HCa, haciendo números estos son los tiempos que no deben ser tenidos en cuenta, pero claro, eso no lo saben los combinacionales de detrás

0000 - 27ns - 0001 - 35ns - 0010 - 27ns -0011 - 43ns - 0100 - 27ns - 0101 - 35ns - 0110 - 27ns - 0111 - 51ns - 1000 .... etc

Si ya cambiamos el bit 5 (HC3) 01111 -> 10000 hay 59 ns, HC4 67 ns, etc.

Voy a seguir haciendo cuentas que la historia debe ir por aquí como bien ha dicho Antonio.

Un saludo.
Edito: En algunos foros de audio que he estado mirando hablan del VHC4040 que es más rápido, la propagación es 9,3 ns para CLK hasta Q1 y 3,1ns de cascada, sigo haciendo cuentas y soldando el euroconector.
2ª edición: enlace del datasheet y correccion de los tiempos de propagación : http://www.fairchildsemi.com/ds/74/74VHC4040.pdf

[antoniovillena]

Bueno, ya he soldado algunos componentes, cambiado el orden de patillas del transistor y probado la entrada EAR. Al igual que a jepalza, me ha funcionado perfectamente. Sin embargo la demo que he probado (Shock Megademo) da algunos problemas en la contención, habría que estudiarlos.

Esta es la placa antes:



Estos son los componentes que voy a soldar:

P4230002.JPG (545.89 KiB) Visto 9386 veces

Esta es la placa de después:

P4230004.JPG (549.29 KiB) Visto 9386 veces

Y este el video de la carga en cinta y de Shock Megademo