Para los gurus de la electronica, cambio de ram?

[mcleod_ideafix]

Ehhhh! está estupendo! Nada, cuando quieras me pasas un esbozo del esquema y lo pasamos a Eagle. En cuanto a la línea de dirección que sobra, o bien se pone a tierra, o bien a +5V con una resistencia de 4,7K... o se añade un poco de lógica y tendrías 2 bancos de 16K conmutables por software.

[fulas]

Bueno pues aqui esta el "esbozo" del invento


Sigo sin solucionar el tema de los pixelados en pantalla.
He probado con todas las interfaces que tengo y todas van bien, el adaptador de Droy y el mcleod_ideafix funcionando juntos , bueno la OPUS DISCOVERY no se si rula, pero la verdad, tampoco tengo ganas de andar con ese armatoste de un lado a otro.
Probe una ultracarga del manic miner y tambien funciona, pero con ruido en la pantalla.

[fulas]

[youtube]http://www.youtube.com/watch?v=MeJjnf1_23E[/youtube]
http://www.youtube.com/watch?v=MeJjnf1_23E

[mcleod_ideafix]

Has probado a usar CAS para habilitar la RAM en lugar de RAS?
Hace cosa de una semana quise ver en el osciloscopio cómo son las lecturas de la RAM de video por parte de la ULA, en un intento de ver cómo refresca sus contenidos. No vi nada de eso, pero si vi algo curioso: las lecturas de memoria las hace a pares: un byte de pixels, y otro de atributos. Pero lo más curioso es que durante las dos lecturas, RAS estaba bajo, y era CAS la que subía y baja con cada lectura individual.
Es posible que en tu montaje, al usar RAS para habilitar la memoria, estés metiendo "basura" en el bus de datos al no deseleccionarse entre una lectura y la siguiente.
Incluso aunque la ULA no tuviera este comportamiento, seleccionar el chip con RAS hace que esté activo incluso antes de que el bus de direcciones tenga la dirección real a leer o escribir. En escritura no es mucho problema ya que el puso de escritura ocurre mucho después de que baje CAS, pero en lectura, el pulso de lectura ocurre antes.
Entonces por qué el Z80 parece leer bien la memoria? Mira el esquema de la figura (ciclos de memoria del Z80A). Las señales de lectura ocurren muy temprano, pero la lectura en sí no se produce hasta casi llegar al flanco de subida de RD. Al llegar a ese momento, el bus de direcciones ya está estabilizado.

¿Cómo afecta esto a la memoria? Pues depende: un chip 4116 tiene este comportamiento en lectura y refresco:

En el cronograma de la izquierda se ve que el chip tiene su salida de datos a alta impedancia hasta un tiempo después de bajar CAS. Si sólo se baja RAS (como por ejemplo, para un refresco descrito en el cronograma de la derecha), la salida de datos sigue a alta impedancia. Fíjate además que durante el refresco se ignora WRITE, y CAS debe estar alta.
Pero tú estás usando una 62256 y habilitada con RAS a nivel bajo. Mira su ciclo de lectura:

OE es la negada de WRITE, que en la ULA siempre vale 1, con lo que durante los accesos de la ULA, OE está siempre bajo. Así que el tiempo que tarda esta memoria en volcar un dato es tACE (en tu circuito, tiempo desde que RAS baja hasta que el dato es válido):

Que vienen a ser 70ns en el peor caso (que tu memoria sea de 70 ns).
Si comparas con los cronogramas de la 4116, resulta que desde que baja RAS hasta que pasan 70ns, estamos en medio de la selección de columna (es decir, la dirección de memoria aún no está formada). De hecho, no se espera el dato hasta tRAC

Que vienen a ser unos 200ns.

En resumen: al usar RAS como chip select de la memoria 62256, estás metiendo datos tanto en los ciclos de lectura normal como en los ciclos de refresco, que para tu memoria son ciclos de lectura estándar (al estar WRITE a 1 siempre en la ULA). Esos ciclos de refresco "malévolos" están metiendo basura en el bus de datos cuando no deben y esto afecta a lo que la ULA muestra en pantalla. Dado que es la ULA la que realiza estas operaciones, el Z80 no está afectado. Además, tu memoria saca los datos antes de tiempo, más concretamente, antes de que la dirección de memoria esté totalmente formada en el latch, y esto no ocurre hasta que baja CAS

Bueno... es una teoría: ahora me dirás que es que tú ya habías puesto CAS como chip select... entonces es cuando cojo y me tiro del puente

[fulas]

Aaaaaaaaaaaaa, joder, meti la pata con el "esbozo" , en realidad, estan invertidas. Las acabo de corregir.
No tenia sentido, si hubiera puesto el latch a CAS, no pillaria la primera parte del bus de direcciones.
Otra cosa es que tengo unidas LE con OE y no se, pienso que OE se tendria que entregar un poco mas tarde, no?

[mcleod_ideafix]

No importa que OE esté activado antes de tiempo, ya que el 62256 no hará caso a OE hasta que no baje CE.

[fulas]

En el cronograma de la izquierda se ve que el chip tiene su salida de datos a alta impedancia hasta un tiempo después de bajar CAS. Si sólo se baja RAS (como por ejemplo, para un refresco descrito en el cronograma de la derecha), la salida de datos sigue a alta impedancia. Fíjate además que durante el refresco se ignora WRITE, y CAS debe estar alta.

Bueno pues de momento, si te parece, vamos a eliminar ese ciclo de refresco, como ya me habias comentado en este mismo post, unos mensajes atras, que esta activando inutilmente el latch.
Esta claro, que es la ula la que no se lleva con mi circuito ya que el Z80, entiendo, que esta funcionando bien.
¿como pillar el ciclo de refresco con algo de logica?

Un problema que es necesario eliminar es el de la señal de refresco, que puede "engañar" al circuito de detección de acceso a las direcciones "3FFE-3FFF". Ese es el objetivo del condensador C2 de 1KpF, eliminar los pulsos generados por los ciclos de refresco, que son iguales que los de lectura y escritura, pero más cortos. Un condensador de 1KpF puede absorber un pico de lectura pequeño, y a la vez ser "inocuo" con una lectura y/o escritura real.

http://www.speccy.org/trastero/cosas/droy/zxflash/zxflashcart_s.htm
¿serviria esto?
Se que, o imagino, que elimina los refrescos del Z80 por la señal MREQ, pero supongo que hay similituder entre MREQ Y RAS.

[mcleod_ideafix]

Usando CAS para activar la memoria debería hacer que se ignore el ciclo de refresco (que sólo usa RAS)

[fulas]

Usando CAS para activar la memoria debería hacer que se ignore el ciclo de refresco (que sólo usa RAS)

Si, para la memoria si, pero para el latch, no deberiamos evitar eso.

[mcleod_ideafix]

El latch debe "latchear" en el flanco bajo de RAS. No pasa nada si también "latchea" en un ciclo de refresco, porque la memoria no se enterará, al no haber CAS que la habilite. El OE del latch debe estar siempre activo.

[fulas]

El latch debe "latchear" en el flanco bajo de RAS. No pasa nada si también "latchea" en un ciclo de refresco, porque la memoria no se enterará, al no haber CAS que la habilite. El OE del latch debe estar siempre activo.

Si dejo el OE del latch siempre activo, se queda colgado en el arranque.

[mcleod_ideafix]

El latch debe "latchear" en el flanco bajo de RAS. No pasa nada si también "latchea" en un ciclo de refresco, porque la memoria no se enterará, al no haber CAS que la habilite. El OE del latch debe estar siempre activo.

Si dejo el OE del latch siempre activo, se queda colgado en el arranque.

Se queda colgado si haces las tres conexiones que te he dicho?
OE del latch = 0 voltios
CE de la RAM = CAS
LE del latch = RAS (suponiendo que LE sea activa en flanco de bajada)

[fulas]

Si, se queda colgado, el latch es un 74ls373 LE es activa por estados y no por flancos, creo, probare el 74ls374 que es por flanco de subida.
http://www.ortodoxism.ro/datasheets/motorola/SN74LS373N.pdf

[mcleod_ideafix]

Si, se queda colgado, el latch es un 74ls373 LE es activa por estados y no por flancos, creo, probare el 74ls374 que es por flanco de subida.
http://www.ortodoxism.ro/datasheets/motorola/SN74LS373N.pdf

No. Eso tendría practicamente el mismo comportamiento que el que estás usando ahora. Busca un latch que sea activo en flanco de bajada, o bien usa un inversor para negar RAS en la entrada de LE.

[fulas]

He estado mirando en YAREK y me he encontrado con esto.http://8bit.yarek.pl/upgrade/zx.zx4mb/problem.html
Igual nos sirve para el problema. Una cosa, alguna idea de como saco ese grafico, es como un analizador logico, pero como sacado de un spectrum.