ZONA DE PRUEBAS

Hoy he estado reparando un Spectrum 128K heatsink. Lo comento por aquí porque esta reparación no ha sido "al uso", sino que ha habido que hacer tests "ad-hoc".

Habitualmente lo primero que hago es usar el test de memoria que hice en su momento. En este caso, no sirvió de mucho.


En cicunstancias normales, esto indicaría que fallan TODOS lso chips de memoria, lo cual no es muy normal. Además, había un patrón curioso: el primer y tercer tercio de pantalla aparecian con un disposición similar, en tanto que el segundo tercio (la mitad de la pantalla) aparecía completamente diferente.

Por lo demás, el ruido y el cambio de borde estaban indicando que la CPU y la ROM de pruebas funcionan bien. Que el test muestre esto, aunque no se vea nada legible en pantalla, significa bastante: el Z80 funciona, su bus de direcciones y de datos también, y no hay ninguna interferencia en dichos buses que impida que se lean instrucciones de la ROM. La RAM en cambio, no funciona. Puede que sea porque los chips estén mal (en este caso, no muy probable) o bien porque algo esté impidiendo que se lean posiciones de memoria (más probable)

Basándome en que estaba viendo el patrón antes mencionado, resolví que habría que usar tests más específicos. Había casi descartado el fallo múltiple en RAM, así que lo que queda es que ésta no se esté direccionando bien. En dicho direccionamiento entran tres chips: el Z80, el PFC1306 y la ULA. Si la memoria no falla, entonces falla uno de estos tres.

Para probar nuevos tests, dispongo de un cartucho ROM casero con una flash de 128K, dividida en 8 bancos de 16K cada uno. Con unos jumpers decido qué ROM de 16K voy a usar. Habitualmente tengo en esta flash algunas ROM de tests, el Open SE, la ROM de CargandoLeches, etc.


Esta flash la grabo con este grabador universal, que es el mismo que uso para grabar las GAL's.


Y que después uso en esta Interface II


El test que quiero hacer es un pequeño programa que recorre el primer tercio de pantalla leyendo el dato que haya, complementándolo (cambio 0 por 1 y 1 por 0) y volviéndolo a grabar. Antes de este recorrido hago otro para poner toda la memoria a 0 (todas las páginas), y la parte de atributos a 56 (paper blanco, tinta negra).

Habitualmente escribir un programa que haga esto en ensamblador no tiene mucha historia. Sin emabrgo, aquí el quid de la cuestión está en que no puedo fiarme de la memoria RAM, con lo que el programa que haga no puede usar variables en memoria, ni subrutinas (no hay RAM para gestionar el stack, así que no puede haber CALL/RET) ni interrupciones (por la misma razón)

Pero gracias a que el Z80 dispone de muchos registros internos, no es demasiado complicado hacer un programa que sólamente use esos registros. Hacer esto con otro micro como el 6502 o el 6809 es más complicado precisamente porque estos micros no disponen de tantos registros, y se apoyan en memoria para casi todas las operaciones. En la época en la que estaba estudiando el chip ACID del CPC+, llegué a escribir en ensamblador un programa capaz de mover un sprite hardware por pantalla sin usar ni una sola posición de RAM. Esto me permitía ejecutar el programa desde un cartucho del CPC+ incluso aunque dicho cartucho no tuviera el ACID puesto (el ACID, o mejor dicho, la falta del ACID, impide que el Z80 pueda leer de memoria RAM)

Este es el test:


En un Spectrum "sano", este test debería comportarse así:


Sin embargo, en éste Spectrum se veía lo siguiente:


Esto que se ve significa lo siguiente:
- Los primeros 256 bytes se leen y escriben sin problemas en pantalla. Esto es, desde la dirección 4000 hasta la 40FF se lee 00, se complementa (FF) y se escribe.
- Los siguientes 256 bytes, en lugar de escribirse a continuación, se "sobreescriben" a los que ya tenía (al leer y complementar, el valor vuelve a ser 00). Esto ocurre desde la posición 4100 a 41FF
- Los siguientes 256 bytes se leen y escriben sin problemas. Esto es, desde 4200 a 42FF
- Los siguientes 256 bytes se sobreescriben a los anteriores. Esto ocurre desde 4300 a 43FF
- Los siguientes 256 bytes que se supone que deben leerse y escribirse desde 4400 a 44FF, es como si en realidad estuviera leyendo y escribiendo en el rango 4000 a 40FF.
- Los siguientes 3 bloques de 256 bytes se comportan igual, como si el rango 4400-47FF se viera en realidad como el rango 4000-43FF.

Así pues, tenemos que las direcciones del estilo
4000-40FF
4200-42FF
funcionan bien.

En cambio,
4100-41FF
4300-43FF
Están "mapeadas" a las primeras direcciones (se sobreescriben)

Los 8 bits bajos de la dirección funcionan, porque el relleno se realiza en orden siempre, así que podemos descartarlos. Lo que sea que pase, pasa con los 8 bits altos del bus de direcciones.

40XX es 0100 0000 XXXX XXXX
41XX es 0100 0001 XXXX XXXX
Si estas dos direcciones aparecen como la primera, 40XX, significa eso que el bit 8 (la línea de dirección A8) está puesta siempre a 0

42XX es 0100 0010 XXXX XXXX
43XX es 0100 0011 XXXX XXXX
Si estas dos direcciones aparecen como la primera, 42XX, se sigue cumpliendo que A8 está "atascada" a 0.

Por otra parte también se observa que el rango 4400-44FF aparenta ser 4000-40FF, es decir:

40XX es 0100 0000 XXXX XXXX
44XX es 0100 0100 XXXX XXXX
Si estas dos direcciones aparecen como la primera, 40XX, entonces significa que el bit 10 (línea A10) está siempre a 0.

Ahora bien: el bus de direcciones no aparece tal cual a la memoria RAM. El PFC1306 tiene que multiplexar dos líneas de dirección en una línea de salida a las memorias, así que podría ser que el PFC1306 esté suministrando direcciones erróneas a las memorias. Tiene sentido porque el Z80 está funcionando y direccionando la ROM, así que debe estar generando direcciones correctas (la ROM no tiene el bus de direcciones multiplexado, así que si el PFC1306 está mal, a la ROM no le afecta). POr otra parte, si pido a la ROM que ejecute algunos tests que están en posiciones de memoria de la ROM más altas, no las ejecuta y se bloquea.... curioso.

Bueno... seguimos sospechando del PFC1306 que está dando direcciones erróneas a la RAM. El siguiente paso es medir señales en los pines del PFC1306 que tienen que ver con las direcciones A8 y A10 del procesador, pero... el test que hemos hecho hace un montón de operaciones en memoria. Mirar todo eso con un analizador lógico o un osciloscopio sería morirse en un mar de señales que ocuparían muchísima memoria del analizador o del osciloscopio.

Necesitamos hacer operaciones de memoria sólamente en una dirección, para que sepamos a priori qué valores deberíamos encontrarnos en las diferentes señales que participan. Además, debe ser una operación de memoria que no ofrezca lugar a confusión sobre quien la está realizando (la CPU). Esto último tiene sentido porque resulta que la memoria de pantalla es leída tanto por la CPU como por la ULA, así que si hago un programa que realice operaciones de lectura en memoria RAM, no sabría después, cuando viera los ciclos de bus, si se corresponde con un ciclo de lectura de la CPU o de la ULA.

Más sencillo es usar una operación de escritura en memoria. Estas operaciones sólamente la puede hacer la CPU, así que no hay lugar a la confusión.

Pero... ¿a qué dirección escribimos? Tiene que ser una dirección que me permita después, con el osciloscopio, comprobar fácilmente que el PFC1306 está funcionando, y además debe ser una dirección que tenga A8=1 y A10=1, para poder comprobar en qué momento se fuerzan a 0. Como el efecto lo hemos visto en la memoria de pantalla, también deben cumplirse que A15=0, A14=1, A13=0, y A12=0
Para el resto de bits, tengo que tener en cuenta que el PFC1306 multiplexa los bits de direcciones de la siguiente forma:
A0 y A7 van multiplexados y salen por DMA0
A1 y A8 van multiplexados y salen por DMA1
...
A6 y A13 van multiplexados y salen por DMA6

(más información sobre las entrañas del PFC1306, en la página de José Leandro: http://trastero.speccy.org/cosas/JL/pcf ... 1306P.html )

Dado que sólo puedo ver dos señales a la vez en el osciloscopio, y una de ellas es la señal de escritura WE, no puedo además mostrar RAS y CAS, que me harían falta para saber cuándo estoy poniendo la parte alta de la dirección y cuándo la parte baja. Para no liarme, lo que haré será hacer que el bit de la parte alta y el de la parte baja sean iguales. Así, me interesa una dirección en la que A0 sea igual que A7, A1 sea igual que A8, etc. A esto tengo que unir las condiciones que puse antes sobre los bits de la dirección (A15 hasta A12). De esta forma, podré ver sin problemas el valor que toma la salida del multiplexor durante un ciclo de escritura. Usaré el osciloscopio de forma que me muestre el valor de una señal del PFC mientras la señal de escritura WE del procesador está a nivel bajo.

La dirección que he escogido es: 0100 1101 1001 1011 en binario, que se corresponde a 4D9B hexadecimal. Durante una operación de escritura, los valores de DMA0 a DMA6 deben ser:
DMA0 = 1
DMA1 = 1
DMA2 = 0
DMA3 = 1
DMA4 = 1
DMA5 = 0
DMA6 = 0

El nuevo test, mucho más corto que el anterior, es éste:


He puesto algunas capturas del osciloscopio con lo que veo:

Señal DMA0 (A0 y A7). Tengo que fijarme unicamente en cuánto vale la señal de abajo (DMA0) mientras la de arriba vale 0 (WE). Vemos que aquí se cumple que está a nivel alto (vale 1)


Aunque no tengo RAS y CAS, por la forma en la que se desarrolla el ciclo de escritura, puedo deducir dónde hace el cambio el multiplexor para pasar de darme el bit bajo de la dirección para darme a continuación el bit alto. Con la señal DMA0, los momentos en los que esto ocurre están marcados en este gráfico:

Obviamente, dado que A0 y A7 valen lo mismo, las dos regiones tienen el mismo valor.

Señal DMA1 (A1 y A8). Aquí debería estar todo el tiempo a 1, como la anterior, pero no es así. De hecho está a 0 casi todo el tiempo. Sé que A1 no es culpable, así que A8 no está multiplexándose bien.


Señal DMA3 (A3 y A10). Pasa lo mismo que con la anterior.


Y sé que A1 no es culpable en el caso anterior, o A3 en éste, porque si vuelvo a sobreexponer las cotas como en A7, obtengo esto:

Aquí se puede ver que primero el multiplexor envía el valor de A3 (que es 1), y a continuación A10, que debería ser 1 tambien, pero que aparece como 0.

Señal DMA4 (A4 y A11). Es correcta, estando todo el tiempo de la escritura a nivel alto.


Señal DMA5 (A5 y A12). Es correcta, estando todo el tiempo de la escritura a nivel bajo.


Entonces veo que el multiplexor PFC1306 no puede ser el culpable, porque sus salidas DMA1 y DMA3 no están siempre a 0, sino que fluctúan. Si hubiera un corto en el interior del PFC1306, su salida sería 0 independientemente de la entrada, pero vemos que no es así, así que la entrada del PFC1306 es lo que debe estar mal.

Mido señal en el pin 38 y 40 de la CPU (señales A8 y A10) y me encuentro con esto (he quitado el zoom a la señal y en lugar de verse una única señal de escritura se ven varias)


En ningún momento la línea de dirección A8 ó A10 pasan a ser 1, y deberían serlo durante la operación de escritura.
Mido resistencia y no hay ningún corto entre esos pines y masa.

Si nadie está forzando esas señales a 0 voltios...
... y el multiplexor PFC1306 da en su salida ambos valores (5V y 0V) y no fuerza a 0V...
... es que en su entrada no está recibiendo valores correctos...
... y la CPU es la única que puede dar esos valores.

Ergo: la CPU está mal (¡claro! eso explicaría por qué al intentar tests que estaban situados en posiciones altas de la ROM, estos fallaban... no podía direccionarlos bien)

Prefiero hacer este tipo de cábalas porque no soy nada amigo de empezar a quitar chips y probar con recambios a ciegas "a ver si es eso". Hay un motivo práctico: desoldar un chip de 40 pines es estresante (para quien lo hace, y para la placa de circuito impreso sobre todo) así que si se pueden evitar operaciones de desoldadura a lo loco, mucho mejor. La placa del Spectrum no es de muy buena calidad y no soporta muchas operaciones de desoldadura.

Con el convencimiento de que es el Z80 el que está fallando, lo desueldo de la placa


Una cosa con la que hay que tener cuidado es que no queden restos de estaño en forma de salpicaduras que ocasionan micro cortocircuitos, que una vez que pongamos el zócalo, dejaremos de ver, ocasionando un problema aún más gordo que el que teníamos. Para evitar estos sustos, uso este producto, un limpiador de circuitos impresos. Fíjate si será fuerte, que conseguí con él limpiar un circuito impreso de uno de mis monitores 1084, que sufrió la "lluvia dorada" de uno de mis gatitos. El pipí se coló por las ranuras de ventilación, causando estragos en la placa. Tuve mala suerte de no darme cuenta en el momento, sino al cabo de algunas horas, cuando ya la orina había corroido parte de la placa. Pues bien, con este limpiador, y mucho frotar con la brochita que tiene, conseguí que volviera a funcionar


La cara de pistas, después del limpiado


Y la cara de componentes


El Z80 ya retirado, y el zócalo que voy a poner


Con el nuevo Z80 instalado vuelvo a mirar la línea A8, y efectivamente, ahora tengo un nivel alto en ella durante el ciclo de escritura.


El test de memoria "habitual" que uso, me da una imagen estupenda, lo que significa que la memoria está OK.


Quito el cartucho ROM y vuelvo a arrancar...


Pues esto ya funciona. Compruebo rapidamente que el nuevo Z80 tiene la línea M1 correcta. Para ello pincho un DivIDE y veo que arranca normalmente.


Ahora ya puedo hacer más pruebas al ordenador. Le pincho mi adaptador de teclado PS/2 - Spectrum, y a continuación, el DivIDE para cargar rapidamente demos y juegos


Nyan Cat 128K


Demo Mescaline


Aplico a este Spectrum el doble mod sonido-video compuesto que explico en este artículo:
viewtopic.php?f=39&t=1998

Y pruebo la calidad de la imagen, primero en RGB:


Y luego en video compuesto.


El dueño se quejaba que la señal que veía era en blanco y negro. Hay dos razones por las que en este Spectrum la imagen se veía en blanco y negro:
- Si la sintonizabas por antena, salía en blanco y negro porque el TEA2000 no estaba recibiendo alimentación de 12V, porque el regualdor DC-DC estaba estropeado. Cambiando TR4 se soluciona el problema.
- Si se coge señal de video compuesto por el conector DIN, resulta que éste la entrega en blanco y negro y no en color (aunque el TEA esté bien).

El doble mod comentado soluciona el problema de la salida de video compuesto, que ahora es en color, y añade sonido a una de los pines del conector DIN que en el modelo español del 128K está libre (más detalles en el artículo)

Para probar la memoria, usé dos juegos que ocupan bastante: Rainbow Islands...


Y La Abadía del Crimen:



Ea, pues ya está. Un Z80 y un ZTX650 estropeados era lo que tenía este ordenador.

Madre mía, qué investigación, y qué didáctico has sido explicándola. Muchas gracias, de verdad, porque se aprende un montón con un desarrollo así.

Y no sabía que llegaste a hacer ese programilla de test de mover un sprite sin acceder a la memoria, en un 6128+. ¿Lo llegaste a comentar en algún foro? Aunque mis conocimientos de CM son muy rudimentarios (o quizá precisamente por eso :-), me parece asombroso; ¡gracias, gracias!

En dos palabras... IM - PREZIONANTE!



Estoy pensando hasta en mandarte mi MSX VG8280 por correo y todo...

Gracias por la lección compañero.



Retrosaludos!!!

javitronik escribió:En dos palabras... IM - PREZIONANTE!



Estoy pensando hasta en mandarte mi MSX VG8280 por correo y todo...

Gracias! pero la gracia del asunto es que conozco muy bien a los Spectrums. Desgraciadamente no puedo decir lo mismo de los MSX. Igual puedo arreglarlo, igual no.

-- Actualizado 03 Feb 2013, 14:27 --

alt escribió:¿Lo llegaste a comentar en algún foro? Aunque mis conocimientos de CM son muy rudimentarios (o quizá precisamente por eso , me parece asombroso; ¡gracias, gracias!

Sí, llegué a hablar de ello en el foro de Amstrad de "miarroba". En mi página web hablo sobre lo del ACID y hay un enlace al hilo donde discutimos todo aquello.

Espero que te hayan pagado bien porque ha sido una buena reparación.

Cada vez me dan más ganas de ir a la universidad esa donde trabajas e iniciar un master, contigo de profesor.
¡¡¡ÉSTO es reparar ordenadores, no lo que hice yo con el MSX!!!
¡A ÉSTO es a lo que me gustaría aspirar a mi! ¡qué grande!

makinavaja escribió:Cada vez me dan más ganas de ir a la universidad esa donde trabajas e iniciar un master, contigo de profesor.

Gracias! pero dado que aún no soy doctor, no imparto cursos del master Eso sí, a mis alumnos internos los pongo a hacer Jupiter ACE's, o Spectrum, o cosas así
Yo mismo, si todo va bien, empezaré un master (como alumno) sobre diseño de sistemas nanométricos (en cristiano: diseño de chips a muy alta escala de integración) en el Centro Nacional de Microelectrónica aquí en Sevilla.

makinavaja escribió:¡¡¡ÉSTO es reparar ordenadores, no lo que hice yo con el MSX!!!
¡A ÉSTO es a lo que me gustaría aspirar a mi! ¡qué grande!

¿Qué hiciste con tu MSX?

Mira... poniéndonos en plan filosófico... hoy mismo he tenido otra experiencia arreglando cosas, esta vez no tan buena como con el Spectrum: la lavadora que no va. Entre mi mujer y yo la desmontamos, y nos vamos directos a la bomba de desagüe, que suele ser lo que casca en estos cacharros. La limpiamos bien limpia, y comprobamos que funciona. Montamos toda la lavadora y ejecutamos el auto-test que trae (que me costó sudores dar con un manual de servicio técnico de una lavadora similar a la mia). El auto-test sale bien, así que ponemos una colada, y de repente, nada, que no va. El auto-test dice ahora que no es capaz de leer la velocidad del motor. Comprobamos que el motor es que no está funcionando... ¿y ahora qué? Miramos conexiones... todo bien. Desmonto la placa de control... tiene su poco de hollín, pero no veo ningún estropicio... Veo que trae un triac, un BTB16-700. ¡Dios! Hace como 20 años que no uso triacs... La resistencia entre puerta y terminal es muy baja, casi cortocircuito... ¿es normal eso? Ni idea. Hoy es domingo... no hay un "servicio de guardia de componentes electrónicos". ¡Cachis! Un triac no es algo que suela yo tener en mi cajita de recambios (y no, no es SMD )

Suponiendo que el problema sea el triac: uno nuevo me cuesta unos 80 céntimos. Si llamara al técnico no se molestaría en ver si es o no el triac. Pondría otra unidad de control. ¿Funciona? Ea, pues eso era. ¿No? Pues te cambio el motor. Y así con todo. Y me cobraría casi lo mismo que cuesta una lavadora nueva. ¡Viva la obsolescencia programada!

La primera tele que tuvimos en color era una Vanguard. En ella puse por primera vez mi Spectrum. Duró desde 1978 hasta 1994 aproximadamente. Se estropeó varias veces, sí, y siempre venía un técnico de Vanguard, con su soldador, su tester, su maletín de recambios... Te la arreglaba en casa y la reparación era una fracción de lo que valía el aparato nuevo. Ya no se ven esos técnicos.

Contento con cómo le había salido ese Vanguard, mi padre compró otro cuando ya el primero no dio más de sí. Este segundo Vanguard no duró ni la cuarta parte del tiempo que el primero.

Nos hemos acostumbrado a que si un aparato ya no funciona, casi no merece la pena llamar al técnico (sobre todo si es un aparato que haya costado 100 euros o menos). Se tira y se compra otro. Mientras eso ocurre aquí en Europa, en Argentina, que han estado durante años en "el corralito" han desarrollado un know-how tremendo sobre volver a las viejas costumbres de "no tiro el aparato, lo arreglo", porque no te puedes permitir el lujo de gastarte el dinero en una tele nueva.

Paradojicamente, hoy día que se encuentra de todo por Internet, es mucho más fácil encontrar un manual de servicio técnico de un ordenador antiguo, que un manual de servicio técnico de una tele de plasma, o un dvd, o de mi lavadora. Los argentinos han resuelto esa falta de manuales con una comunidad bien comunicada, con cursos sobre cómo reparar teles de plasma, LCD, etc, aunque no tengas los manuales de servicio técnico.

mcleod_ideafix escribió:

makinavaja escribió:Cada vez me dan más ganas de ir a la universidad esa donde trabajas e iniciar un master, contigo de profesor.

Gracias! pero dado que aún no soy doctor, no imparto cursos del master Eso sí, a mis alumnos internos los pongo a hacer Jupiter ACE's, o Spectrum, o cosas así
Yo mismo, si todo va bien, empezaré un master (como alumno) sobre diseño de sistemas nanométricos (en cristiano: diseño de chips a muy alta escala de integración) en el Centro Nacional de Microelectrónica aquí en Sevilla.

makinavaja escribió:¡¡¡ÉSTO es reparar ordenadores, no lo que hice yo con el MSX!!!
¡A ÉSTO es a lo que me gustaría aspirar a mi! ¡qué grande!

¿Qué hiciste con tu MSX?

Hice ésto: viewtopic.php?f=28&t=2793
Tranquilo, tiene final feliz, pero fui casi a lo Rambo XD
Y no soy tan bueno como tu desoldando XD De ver esa foto del z80 desoldado se me han saltado los colores XD

Si reparar Spectrum y ordenadores fuera como en los deportes que te dan medallas, me parece que no ibas a tener sitio para ponerlas...

Lo que me da miedo es ese master que vas ha hacer... eres capaz un día de decirnos que has montado un Spectrum en la cabeza de un alfiler... supongo que se podrá porque si los intel y tal tienen millones de transistores, y no serán más grandes que 2 o 3 cm cuadrados...

Como siempre, Excelente, aunque no creo que pueda valorar ni 1/10 parte de tú trabajo...

Enhorabuena por la reparación y gracias por hacer un post tan detallado