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:
Código: Seleccionar todo
org 0
Main di
ld bc,32765
xor a
out (c),a
ld a,6
out (254),a
ld e,7
BucPagina out (c),e
ld hl,49152
BucRellena ld (hl),56
inc hl
ld a,h
or l
jr nz,BucRellena
dec e
jp m,BucPagina
ld hl,16384
BucRellena2 ld (hl),56
inc hl
ld a,h
cp 0c0h
jr nz,BucRellena2
;
ld hl,16384
ld bc,6144
BucRPant1 ld (hl),0
inc hl
dec bc
ld a,b
or c
jr nz,BucRPant1
ld hl,16384
ld bc,6144
BucRPant ld a,(hl)
cpl
ld (hl),a
inc hl
dec bc
ld de,2000
BucPausa dec de
ld a,d
or e
jr nz,BucPausa
ld a,b
or c
jr nz,BucRPant
ld a,2
out (254),a
haltEn 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:
Código: Seleccionar todo
org 0
Main di
Bucle ld a,055h ;15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
ld (4D9Bh),a ; 0 1 0 0 1 1 0 1 1 0 0 1 1 0 1 1
jr Bucle
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.
Eso sí, a mis alumnos internos los pongo a hacer Jupiter ACE's, o Spectrum, o cosas así 
