¿Posible "snow effect" en un Spectrum 48k?

[eltargui]

Hola a todos.

Desde hace algún os días he observado que una de las placas mostraba una imagen extraña al conectarlo. Pensaba que era por otros motivos, no sé, algún condensador, etc... Esta placa es una issue 3B, y hace algún tiempo le cambié casi todos los condensadores electrolíticos, pero aún así pensaba que pudiera ser esto.

La imagen que muestra es:



Pero ahora al cargar un cartucho en la IF2 para ver algo más de pantalla y color, he obtenido esto:



Un montón de rayitas moviendo. El tercio inferior está como duplicado. Es parecido a los vídeos que hay en este hilo.
http://foro.speccy.org/viewtopic.php?f=11&t=4079
Aunque en mi caso es más una tempestad que un "effect".

Se me ha ocurrido sacar la ULA y llevarla a otro ordenador sano, y obtengo el mismo efecto. Por lo que he deducido que era un problema de ULA, y por el hilo anterior, que podía ser este "snow effect".

Anteriormente había corrido el test de mcleod, simplemente por ver patrón de pantalla. Estos son los patrones que obtuve.

Indistintamente, tras conectar las tomas 1 u 2 a masa en el conector pequeño del teclado KB1.


Tras conectar la toma 5.


He leído algo de las causas de este efecto pero no dice que pasara en continuo sino en algunas circunstancias, y con algún juego. Tampoco se dice cual podría ser la solución, salvo en los 128k.

Me tiene algo despistado este patrón. ¿Tenéis alguna idea?.

[mcleod_ideafix]

No es el snow effect clásico de la ULA. Es una ULA fastidiada.

Con el test inicial ejecutándose (de mi ROM), coge y deja a la CPU en reset permanente (dejando pulsado el botón de reset, o cortocircuitando el pin de reset de la CPU a masa). ¿Se deja de ver ruido y se ve el patrón bien?

Mi sospecha es el pin 5 de la ULA (A0). Ese pin, a diferencia de lo que podría suponerse, es bidireccional. Durante un ciclo de lectura de la CPU, en ese pin hay una copia del bit A0 del bus de direcciones de la CPU, y se usa para decodificar el puerto $FEh

En un ciclo de acceso a la RAM de video por parte de la ULA, en ese pin va primero el bit 0 de la dirección y luego el bit 7. Pues bien, me da la sensación de que cuando internamente la ULA tiene que sacar el valor del bit 7 de la dirección, si este bit es un 1, le cuesta trabajo, como si el driver estuviera dañado, así que a veces la memoria ve un 0 y a veces un 1, y de ahí el ruido que estás teniendo. En el tercio inferior de hecho también hay ruido, pero como el patrón es el mismo en todo el tercio, no se nota (el byte leído cuya dirección tiene el bit 7 a 1 tiene el mismo valor que el byte que tiene ese mismo bit a 0)

Poco puedes hacer por solucionarlo, pero si en la prueba que te comento en el primer párrafo resulta que la ULA deja de hacer ruido, quizás haya una posibilidad de salvar esa ULA: incrementando el valor de R17, de 330 ohmios que es el valor nominal, a uno mayor tal como 470 ohmios, 560 ohmios, o incluso 680 ohmios.

[eltargui]

Gracias por la respuesta.

He hecho la prueba con tu ROM de prueba y el reset pulsado. Desaparece el ruido, pero el patrón queda desplazado.



Supongo que no tendrá que ver pero pareciera que uno de los multiplexores IC3 o IC4 no estuviera haciendo su trabajo. Un patrón similar me salió precisamente con un problema en los 74LS157. En ese caso fue uno de los de la memoria RAM alta (IC25 e IC26). Al hacer el test de memoria baja no daba problema, pero al pasar al de memoria alta no reaccionó, y al regresar al de memoria baja me dio ese patrón precisamente.
El IC4 es el que está al pin 5 de la ULA.
No he hecho nada todavía con la resistencia R17.

[mcleod_ideafix]

Supongo que no tendrá que ver pero pareciera que uno de los multiplexores IC3 o IC4 no estuviera haciendo su trabajo.

Sería eso si no fuera porque dices que has probado la ULA en otro equipo y hace lo mismo.

Además, si fuera un problema en alguno de esos IC's, el equipo no arrancaría, y según las fotos el equipo arranca y muestra (es un decir ) el mensaje de (C)1982...

Por lo que concluyo que la CPU ve a la memoria sin problemas. Quien no la ve bien es la propia ULA, que no es capaz de generar correctamente la dirección, o no es capaz de leer correctamente el dato, o ambas cosas. Los cálculos que he hecho me indican que es el bit 7 del bus interno de direcciones de la ULA el que no funciona. Ese bit 7 sale por A0 (pin 5) de la ULA multiplexado con el bit 0.

El patrón que muestra la ROM es el mismo para todo un scan de píxeles, con lo que no puedo saber a priori si es el driver de ese pin 5 el que se ha estropeado (afectando tanto al bit 0 como al 7), o es el bus interno de direcciones el que ha cascado en su bit 7. Sea como fuere, el bit 7 no consigue ponerse a 0, la memoria siempre lo ve como que vale 1 cuando la CPU está en estado de reset. Cuando la CPU está activa, ese bit tiene ruido. Mi conjetura es que esa línea se ha desconectado internamente de la ULA y no envía ningún dato. Ese bit por tanto tiene el valor que le dé la CPU, y como ésta lo cambia continuamente, de ahí el ruido. Cuando dejas a al CPU reseteada, su bus de direcciones queda con un valor fijo y cesa el ruido.

Me temo que en este caso, ni siquiera cambiando R17 vas a conseguir nada.

[eltargui]

Vaya....

Lo de los multiplexores lo dije por similitud, pero es cierto que no tenia sentido.

Muchas gracias por la explicación. Muy instructiva, como siempre.

Saludos

[eltargui]

Refloto este hilo para contar lo que me ha pasado en unas pruebas que he hecho.

En realidad, lo que he hecho es meter una modificación para poder usar una EPROM en vez de la ROM original. Para ello he seguido el esquema de modificación de El Trastero. He usado EPROMs 27C128 (16k) y 27C256 (32k). Esta modificación la he aplicado sobre esta placa con la ULA dañada (como entrenamiento ), y después también sobre otro spectrum sano.

He probado varias ROMs (original, Groot, Gosh Wonderful,...) y siempre hay dos que no funcionan en esta placa de ULA dañada. Son la OpenSE (de 1981 de Nine Tiles - no confundir con la SE Basic, como me pasó a mí) y la del Jupiter ACE de Paul Farrow. Ya sea en la 27C128 o en la 27C256 junto con otra ROM, fallan. A veces, la OpenSE funciona. Una de cada diez veces.

Las pantallas que obtengo son. Para la OpenSE:



Y para la Jupiter ACE:



Estas dos ROMs funcionan bien en la otra placa donde he hecho la misma modificación. Y funcionan en cualquier combinación. Luego hay algo en esta placa que impide que arranquen estas ROMs.

Lo más curioso fue cuando le metí una ROM externa y probé diferentes programas de test. Al principio de este hilo se ven imágenes con el test mcleod. Ahora he probado otras ROM de testeo, y con la de RAM de Paul Farrow obtengo la pantalla correcta al final

Dejo un video con la prueba. Empieza con la pantalla llena de basura, pero al terminar la prueba muestra la pantalla final bien. Lo he probado varias veces, y la mayoría sale la pantalla final bien. Pero alguna vez sale la pantalla bien de imagen pero cambian algunos caracteres y las palabras no se entienden. Es como si estuviera escrito en otro idioma, un montón de consonantes seguidas, palabras muy largas.... todo ininteligible.

https://dl.dropboxusercontent.com/u/887 ... rrecto.MOV

¿Pudiera ser que este programa, por la razón que sea, forzara un valor de la línea A0 de la ULA y por lo tanto corrigiera el error indirectamente?.