mcleod_ideafix escribió:Una propuesta: en lugar de usar la ROM normal y corriente en el clon, usad la ROM de testeo que escribí.
Vaya, hasta mañana ya no puedo probarlo. El grabador lo tengo en la lonja, y ya no son horas (mañana me levanto a las 6:00).
Por otro lado, Mcleod_Ideafix, igual tienes razón con el 4040 y el reloj de 14mhz, por que si le hago malas jugadas poniendo a GND algunos pines, el 128 llega a arrancar sin basura.
edito: Coñe, que va a tener algo que ver, puestos a fastidiarle al 4040, poniendo a GND los pines 3 o 5 al arrancar (mejor con el 5), sale mal el menú, (de cajón, por que le estoy tocando las narices), pero si al de un par de segundos, quito el puente, tengo un 128 funcional, sin basura....
edito 2: Fijaros las dos fotos. La primera, poniendo a GND la patilla 5 del 4040 U39 (señal HC2), la segunda, al esperar un par de segundos a que inicie el menu (se ve perfectamente como aparece el menú del 128), y queda estable y sin basura, hasta que pulso enter, que se estropea de nuevo).
Edito 3: otra prueba MUY interesante. Si antes de pulsar ENTER para entrar a cualquiera de los menus, vuelvo a puentear a GND la patilla 5, y luego suelto, aparece el modo del menú elegido, sea cual sea, perfecto, sin basura.
Edito 4: al final, el problema va a ser únicamente de HC2. Lo he aislado, y mandado a GND solo el de U46 (el 138), y arranca perfecto el 128, pero con caracteres duplicados, o sea, que las filas pares son idénticas a las impares. Los tiros von por ahí. A ver si le sigo la pista hasta llegar al fallo, auqneu me tengo que ir la cama ya, pero me pica la curiosidad. (mirar la tercera foto, con los resultados de dejar aislado el 74138, pin 2)
IMG_4852.JPG (67.37 KiB) Visto 7655 veces
IMG_4853.JPG (65.51 KiB) Visto 7655 veces
Aislando patilla 2 del U46:
IMG_4854.JPG (73.72 KiB) Visto 7646 veces
Última Edición (y me voy a la cama): demostrado, la basura la generan las patillas 9 y 10 del U19C. Al estar conectadas al 74138 (U46) generan basura. Si las dejo al aire, sin conectar, el modo 128k arranca sin basura, pero con dificultades, una sí una no, pero al menos, sin basura (algunos caracteres no aparecen, pero es lógico, tengo el U19 sin conectar). La cosa tiene que ver con el reloj, por lo que sea, se arranca antes o a la par el WE de U4, antes de estar el reloj de 3.5 preparado, y recoge basura. Lo dejo por hoy, mañana mas
Llevo un buen rato pensando cual es el problema y cada vez me estoy liando más. Mañana haré la prueba de la ROM de McLeod a ver que tal. Y jepalza, menudo curro te estás pegando. Llevo un rato leyéndote, y en cada edición que escribías pensaba que el problema ya estaba localizado, pero entonces escribías una edición más y me hacía un lío.
Dios, que ganas tengo ya de que quitemos el problema de la basura...
-- Actualizado 14 Abr 2013, 22:01 --
En caso de que el 138 produzca dos salidas a 0, aunque sea momentáneamente, se pueden producir glitches que antes (en el clon de 48k) no ocurrían. Uno es en la puerta U19C y otro en la puerta U19D. Si esto fuera el origen de la basura, cambiando U19C por una OR y U19D por una NAND se acabarían los problemas.
antoniovillena escribió:En caso de que el 138 produzca dos salidas a 0, aunque sea momentáneamente, se pueden producir glitches que antes (en el clon de 48k) no ocurrían. Uno es en la puerta U19C y otro en la puerta U19D. Si esto fuera el origen de la basura, cambiando U19C por una OR y U19D por una NAND se acabarían los problemas.
Dos salidas a 0 lo dudo... pero que todas las salidas estén a 1 durante demasiado tiempo sí que puede pasar: ese decodificador está gobernado por tres señales que cambian con bastante rapidez (del orden del megahercio), pero una de las entradas de habilitación de dicho multiplexor está gobernado por HC8, que es la señal que máaaaaaas lento cambia en el HC4040 (más de 100ns de diferencia con el resto de las señales). De todas formas esto se notaría en el cambio de borde a paper, y de paper a border (es probable por tanto que se pierda el primer pixel de cada línea, y que el último de cada línea sea un poco más ancho: cuando pongais la ROM de test lo podréis notar mejor)
Recuerda: cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista
La mejor prueba que he hecho, ha sido la de retrasar la entrada del HC2, poniéndola a GND un tiempo prudencial, a mano. El Spec arranca mal (con los caracteres duplicados en filas), y al soltar tras un par de segundos, todo correcto. Hay que añadir algún retraso en HC2, quizás cambiando HC2 por HC3, o quizás cambiando la parte que le da WE a la memoria U4 en otra línea, y dejando el reloj de 3.5 en HC2, de modo que entre uno mas tarde que el otro. (todo teorías, a ver esta tarde si puedo probarlo sin tener que hacer cortes a la placa)
Como se ve en el video donde aparece la mayor cantidad de basura es durante la generación del tono guía, por lo que no son las escrituras en RAM alta lo que provoca la basura. Puede ser el OUT o lecturas en zonas concretas de la ROM.
-- Actualizado 15 Abr 2013, 11:00 --
He repetido algunas pruebas de jepalza y puedo confirmar que me ocurre lo mismo. En concreto cortocircuito los pines 16 y 10 de U46 con unas pinzas, que viene a forzar el C5 a VCC que es algo parecido a lo que hace jepalza poniendo HC2 a GND. Pues bien, lo que ocurre es que las columnas de caracteres impares, que es donde está la basura, se sustituyen por las pares, y es por eso por lo que no aparece la basura.
-- Actualizado 15 Abr 2013, 11:13 --
Definitivamente voy a optar por la opción lenta pero segura de downgradear poco a poco a superfo 48k hasta que desaparezca la basura.
-- Actualizado 15 Abr 2013, 12:19 --
Otra posibilidad, que en este caso concuerda con la basura es lo siguiente: -En C3 se lee byte impar, en C4 el atributo impar, en C5 el byte par y en C6 el atributo par. -En el clon 48 se genera AL (no viene etiquetada) con U24D y se niega con U23D, generando /AL (también sin etiquetar). -En el clon 128 se genera /AL con U19D y se niega con U24D, generando AL. -En la transición C6->C7, el retardo del inversor en el clon 128 provoca que durante un mínimo periodo de tiempo tanto AL como /AL estén activadas, cosa que no pasa en el clon 48. -El error ocurriría en el caso de que se dé una contención de escritura, el glitch provocaría que el bus de direcciones VA0..VA15 esté o bien con la dirección de memoria del byte par, o bien con una mezcla entre dicha dirección y la dirección correcta (la que genera el Z80).
Como se ve en el video donde aparece la mayor cantidad de basura es durante la generación del tono guía, por lo que no son las escrituras en RAM alta lo que provoca la basura. Puede ser el OUT o lecturas en zonas concretas de la ROM.
Fuerza IORQGE a 1 en cuanto comience el tono guía. Eso hará que de repente desaparezca toda actividad en el borde ya que dejará de haber E/S en la ULA.
De todas formas, sigo pensando en un problema de contención, provocado por retrasos en el contador de píxeles. El puerto $FE es contenido en el Spectrum original, pero en este clon en realidad no tiene por qué serlo, ya que el bus de datos de la VRAM es independiente del bus de datos de la E/S. Bueno, no tiene por qué serlo... en escritura.
Este es el procedimiento: - Con la ROM de testeo, vuelve a usar la opción de guardar datos (KB2 a masa) - En cuanto cmience el tono guía, fuerza WAIT a GND para deterner el procesador sin llevarlo a reset - Retira U26 de su zócalo. Esto aislará el puerto $FE en lectura (teclado y EAR) del bus de datos de la VRAM - Levanta el pin 9 de U14C y el 13 de U18D, y lleva esos pines a VCC. Con eso, el puerto $FE en escritura dejará de estar contenido. - Deja WAIT como estaba. La rutina de carga seguirá con lo que estaba haciendo, pero sin generar contiendas en los OUT's.
Si el problema está en las contiendas generadas en la E/S, al hacer esto dejará de generarse basurilla en pantalla.
-- Actualizado 15 Abr 2013, 15:10 --
Si el problema es realmente de contención, ya no estoy tan convencido de que sea por un retraso en las señales: - DEN es estable durante toda la generación del "paper", ya que las dos señales que la componen, HC8 y VBorder, no cambian durante todo el "paper". - C6 y C7 se generan por un circuito combinacional, que es bastante rápido. No tiene los problemas del HC4040. - CLK7 y HC0 son la misma señal, invertida una de otra, y al venir de las primeras etapas del HC4040, son las señales con menos glitches (unos 10-20ns) - El resto de señales vienen, directa o indirectamente, desde el Z80.
En el circuito de contención (ésta es la versión de Chris Smith) hay dos biestables: U21A y U21B. U21A es el biestable "generador de condiciones de contienda". Se actualiza en cada pulso del reloj de pixel. La salida usada vale 1 cuando la ULA está usando el bus de datos, y por tanto puede entrar en conflicto con el Z80. U21B es el biestable "cancelador de contienda". La salida usada vale 0 cuando el Z80 no genera contiendas, o cuando la contienda pendiente ha sido resuelta...
El decodificador U46 va señalando en qué momento de la generación de imagen estamos: - Cuando se activan (poniéndose a 0) C0 a C5, la ULA está usando el bus de datos - Cuando se activan C6 ó C7, la ULA no está usando el bus de datos.
Cuando cualquiera de los otros estados, C0 a C5, está activo, U19C da un 0. Si además DEN vale 0 (lo que significa que estamos generando "paper"), entonces se guarda un 0 en U21A, y la salida que estamos usando vale 1. Así que esta salida negada de U21A nos está "chivando" cuándo puede haber contienda. La hay si vale 1, y no la hay si vale 0. Esto va a una de las entradas de U17B.
La segunda entrada a U17B es una señal que vale 1 cuando el Z80 está iniciando un ciclo de bus que puede producir contienda: bien es un ciclo de bus de E/S al puerto $FE, o bien es un acceso a memoria contenida.
En cuanto a U21B, su entrada vale 0 cuando baja MREQ o baja la combinación IORQ+A0 (acceso a E/S). Supuestamente, cualquiera de estas dos condiciones debe cancelar la contienda en el próximo flanco de subida del reloj de U21B, que es ni más ni menos que el reloj del procesador. Aquí tengo mis dudas (de hecho también las tengo en el esquema de Chris)
La contienda en E/S se produce en T2 (en memoria, la contienda es en T1). IORQULA baja una vez ha comenzado T2, y esta señal tiene dos trayectorias en el circuito de contienda: por una parte, hace que la segunda entrada de U17B valga 1, indicando que hay contienda, y por otra parte, está queriendo entrar en U21B, pero no podrá hacerlo hasta que no ocurra otro flanco positivo de reloj del Z80. Como las tres entradas de la AND son 1, el reloj del Z80 (CLK35) y reloj de U21B se quedan a nivel alto. En este estado de enclavamiento, sólo la primera entrada a U17B (la que viene de U21A) será la que pueda ponerse a 0, permitiendo un nuevo flanco de subida en CLK35, permitiendo a su vez que ingrese IORQULA a U21B, y haciendo que otra de las entradas de U17B valga 0, asegurando que CLK35 no se quede "atascada" de nuevo en el ciclo de bus actual.
Bueno, pues duda resuelta... el circuito funciona como debe funcionar... siempre y cuando se cumpla que IORQULA baje después de que suba CLK35 indicando el comienzo de T2. DEN, C6 y C7 deberían tener un retraso gordísimo como para permitir un nuevo flanco de subida de CLK35 una vez que ha bajado IORQULA.
Recuerda: cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista
McLeod, creo que el problema es lo que indiqué antes, que hay que generar /AL después de AL y no al revés. De todas formas no lo he comprobado, tendría que hacer la prueba mañana.
El nuevo esquemático está ya publicado, con muchos cambios, entre otros la generación correcta de AL y /AL.
Como he rotado algunas puertas, ni de coña voy a probar este fix. Lo que haré será volver a negar AL con el inversor que no se usa en PAL (U24C), y en lugar de emplear el /AL de la salida de la XOR (ahora sólo lo usaría la entrada de U24D) emplear como /AL la salida del nuevo inversor (U24C).
Hasta aquí he podido montar en dos horas (es que me he quedado sin estaño):
Cimg9523.jpg (237.59 KiB) Visto 7472 veces
A ver si esta noche le pego el remate final y me pongo al día para averiguar lo que pasa.
MUCHO OJO: he visto que en el conector Compact Flash mi placa viene con varias pistas unidas (se han pasado estañando). Por seguridad deberíais todos repasar dichas pistas y cortar las uniones.
Yo tengo una máquina del tiempo, se llama ZX Spectrum, siempre me devuelve a los buenos momentos. (\.../) (\.../) (\.../) (\.../) ( *.*) ('.'= ) ('.'= ) ('.'= ) (")_(") (")_(") (")_(") (")_(") ╔═══╦═══╦═══╦══╦══╗ ║╔═╗║╔═╗║╔═╗╠╣╠╩╣╠╝ ║║─║║╚══╣║─╚╝║║─║║ ║╚═╝╠══╗║║─╔╗║║─║║ ║╔═╗║╚═╝║╚═╝╠╣╠╦╣╠╗ ╚╝─╚╩═══╩═══╩══╩══╝
mcleod_ideafix escribió:Cuando cualquiera de los otros estados, C0 a C5, está activo, U19C da un 0. Si además DEN vale 0 (lo que significa que estamos generando "paper"), entonces se guarda un 0 en U21A, y la salida que estamos usando vale 1.
Si cualquiera de los estados de C0 a C5 (también C6 y C7) está activo es porque Den vale 0, la señal Den actúa como enable en el decodificador. Es por eso por lo que te pregunté si se podría quitar U6D, poniendo la salida del U19C al reset asíncrono del biestable y Den a la entrada D del biestable. El efecto sería que la salida del biestable se adelanta medio ciclo, se produce al comienzo de C6, no en la mitad del ciclo. Lo que no sé es si este "adelanto" afectaría al resto del circuito, o si se puede compensar cogiendo C7 y C0. Una puerta OR no es que suponga mucho, pero siempre es bueno que nos "sobre algo" por si tenemos que hacer otro arreglo.
-- Actualizado 15 Abr 2013, 17:18 --
radastan escribió:MUCHO OJO: he visto que en el conector Compact Flash mi placa viene con varias pistas unidas (se han pasado estañando). Por seguridad deberíais todos repasar dichas pistas y cortar las uniones.
Yo también pensé lo mismo en cuanto las vi. Esas uniones están hechas a drede, sino fíjate en el PCB layout.
¿En 2 horas? Creo que estás a punto de batir el record de jepalza montando la placa. Poner los chips va a ser coser y cantar, los pines ya tienen la forma del zócalo.
un 128 funcional, sin basura....
