Apuntes sobre problemas en la ram de los gomitas

Avatar de Usuario
hamham
Mensajes: 273
Registrado: 19 Sep 2012 09:49
Ubicación: Alicante
Agradecido : 37 veces
Agradecimiento recibido: 19 veces

Apuntes sobre problemas en la ram de los gomitas

Mensajepor hamham » 22 Mar 2013 10:25

Hola, como la informacion de como afrontar un problema con la memoria de nuestro querido
gomitas esta un poco dispersa, me e decidido a subir los apuntes que en su dia recopile
de las respuestas que daban distintos usuarios por la web, afrontando problemas con la ram.

Mis mas sinceras gracias y reconocimiento a todos ellos, y de verdad que de haber pensado un dia en subir este paper, hubiera apuntando sus nombres, dando reconocimiento a su trabajo.

Disculpar las erratas, falsa o excasa informacion que pudierais observar en algun punto, de ser asi agradeceria que lo hicierais notar y lo rectificaria lo mas pronto posible.

Saludos y espero que a algun novato como yo le sirva de utilidad.

Edito: paper modificada con nueva informacion, gracias mcleod
Adjuntos
La ram en el 48K_Rev 2.rar
(96.18 KiB) Descargado 846 veces

Avatar de Usuario
Luis
Mensajes: 1979
Registrado: 03 Nov 2010 19:00
Ubicación: Villaquijada del Tuerto
Agradecido : 1411 veces
Agradecimiento recibido: 665 veces

Re: Apuntes sobre problemas en la ram de los gomitas

Mensajepor Luis » 22 Mar 2013 13:21

Gracias por el aporte hamham. Las primeras dos páginas son una traducción del Service Manual, y son esos POKEs y la tabla de la página 2 lo que he utilizado para saber que el IC20 (memoria alta) de uno de mis gomas no funciona correctamente (indicado en el otro hilo del Spectrum con pantalla negra).

Aunque tiene su lógica, me sigue resultando muy curioso que a base de POKEs pueda saberse qué integrado está mal en un Spectrum :-)
AHA! YOU GOT THE WUMPUS!
HEE HEE HEE - THE WUMPUS'LL GET YOU NEXT TIME!!

Avatar de Usuario
hamham
Mensajes: 273
Registrado: 19 Sep 2012 09:49
Ubicación: Alicante
Agradecido : 37 veces
Agradecimiento recibido: 19 veces

Re: Apuntes sobre problemas en la ram de los gomitas

Mensajepor hamham » 22 Mar 2013 17:21

harnas escribió:Gracias por el aporte hamham. Las primeras dos páginas son una traducción del Service Manual, y son esos POKEs y la tabla de la página 2 lo que he utilizado para saber que el IC20 (memoria alta) de uno de mis gomas no funciona correctamente (indicado en el otro hilo del Spectrum con pantalla negra).

Aunque tiene su lógica, me sigue resultando muy curioso que a base de POKEs pueda saberse qué integrado está mal en un Spectrum :-)


Si esa informacion la cogi del service manual , la traduccion como veras es bastante libre, pero la hice para aclararme a nivel particular.
Con los de los pokes te doy la razon es super curioso el tema por logico que sea.
saludetes

mcleod_ideafix
Mensajes: 925
Registrado: 13 Ene 2012 09:45
Agradecimiento recibido: 8 veces

Re: Apuntes sobre problemas en la ram de los gomitas

Mensajepor mcleod_ideafix » 22 Mar 2013 17:22

Donde dices...
2 Si es distinto ejecutar la siguiente sentencia :
POKE 43201,85 : PRINT PEEK 43201 (= respuesta A)
Si el valor resultado es 85, y no estais comprobando un Spectrum16K probar la siguiente sentencia :
POKE 43201,170 : PRINT PEEK 43201 (= respuesta B)


¿Por qué usas la dirección 43201 en concreto? Si la memoria alta está estropeada, en una dirección mayor a esa, ese POKE no te resolverá nada.
Lo que hay que hacer es averiguar cuál es la última dirección que el test de memoria dio por bueno, así:

Código: Seleccionar todo

LET D=PEEK 23732+256*PEEK 23733

Si D no es 65535, y el Spectrum es de 48K, hay un problema con la memoria alta. Los dos POKEs que hay que hacer son a la dirección D+1 (la primera que falla), así:

Código: Seleccionar todo

POKE D+1,85: PRINT PEEK (D+1)

Código: Seleccionar todo

POKE D+1,170: PRINT PEEK (D+1)

Aunque yo no suelo usar 170 y 85, sino 0 y 255. El fallo más habitual es que el chip se haya "roto" del todo, y no dé ninguna salida. En ese caso los 1s se leen bien (porque coincide con el bus flotante) pero los 0s no, así que con el POKE D+1,0 suele ser suficiente. Si el valor no es 0, el bit que está fallando te lo da la posición del bit (o bits) que estén a 1 al hacer PEEK (D+1).

Ah! Tampoco se comenta, pero es conveniente hacer los POKE/PEEKs cuando la ULA no está leyendo la pantalla, para que el bus flotante sea de verdad "flotante". Es decir:

Código: Seleccionar todo

POKE D+1,0: PAUSE 1: PRINT PEEK (D+1)
Cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista.

Avatar de Usuario
Luis
Mensajes: 1979
Registrado: 03 Nov 2010 19:00
Ubicación: Villaquijada del Tuerto
Agradecido : 1411 veces
Agradecimiento recibido: 665 veces

Re: Apuntes sobre problemas en la ram de los gomitas

Mensajepor Luis » 22 Mar 2013 17:34

La verdad, no se por qué se usa esa dirección de memoria, tiene más lógica lo que dices, de ir moviendose por las direcciones de memoria para ver si se puede cambiar el contenido en ellas o no.

En el caso de mi gomas, que es de 48Kb, me dio estos resultados:

LET D=PEEK 23732+256*PEEK 23733 ---> 32767 (debería ser 65535, por lo que indica que funciona como un 16K, algo hay mal en la memoria alta)
POKE 43201,85 : PRINT PEEK 43201 ---> 85 (vale, ese está ok)
POKE 43201,170 : PRINT PEEK 43201 ---> 117 (debería ser 170. Según la tabla, el IC20 está mal)

El caso es que el sistema de la dirección 43201 parece funcionar, ¿no? Lo que hay que averiguar es por qué es esa dirección y no otra a modificar...
AHA! YOU GOT THE WUMPUS!
HEE HEE HEE - THE WUMPUS'LL GET YOU NEXT TIME!!

mcleod_ideafix
Mensajes: 925
Registrado: 13 Ene 2012 09:45
Agradecimiento recibido: 8 veces

Re: Apuntes sobre problemas en la ram de los gomitas

Mensajepor mcleod_ideafix » 22 Mar 2013 17:38

hamham escribió:Con los de los pokes te doy la razon es super curioso el tema por logico que sea.
saludetes


Bueno... es que con POKEs y PEEKs estás haciendo lo mismo que hace la rutina de test de memoria del Spectrum en código máquina: escribe un valor, y luego lee a ver si es el mismo. El test de memoria del +2A/+3 mira en el resultado que lee qué bit está a un valor diferente que el que debería, y pone el borde de un color o de otro, según que bit haya fallado. Dado que en el Spectrum (el 48K y el 128K/+2 gris) cada bit se guarda en un chip independiente, al averiguar qué bit falla estás apuntado directamente a qué integrado es el que falla.
Cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista.

mcleod_ideafix
Mensajes: 925
Registrado: 13 Ene 2012 09:45
Agradecimiento recibido: 8 veces

Re: Apuntes sobre problemas en la ram de los gomitas

Mensajepor mcleod_ideafix » 22 Mar 2013 17:46

harnas escribió:El caso es que el sistema de la dirección 43201 parece funcionar, ¿no? Lo que hay que averiguar es por qué es esa dirección y no otra a modificar...

Funcionará esa dirección como funcionará cualquier otra igual o superior a 32768, porque en tu caso resultó que el chip estaba mal del todo y fallaba en todas las direcciones. No sé dónde has leído de usar esa dirección, pero puede (o no) funcionar. Si el error ocurre en un bit, pero no para todas las direcciones, sino sólo para unas pocas, y esas pocas resultan estar de las últimas, la dirección 43021 te dirá que todo está ok.

Hay otro tipo de errores relacionados con la memoria, pero no causados por ella, y que curiosamente detecta el test de memoria de la ROM, pero no son detectados por los sistemas de POKE/PEEK que has descrito. Los síntomas eran los siguientes:
- El Spectrum arrancaba normalmente y se podía acceder al BASIC
- Al hacer un PRINT PEEK 23732+256*PEEK 23733 para saber la memoria disponible me daba 49151 en lugar de 65535
- Al hacer un POKE 49152 con cualquier valor, el PEEK 49152 me respondía con el mismo valor correcto.
- Al escribir un valor (el que sea) en todas las posiciones de memoria de la 32768 hasta la 65535, al leer esas mismas posiciones se lee el valor correcto.
- Al hacer un POKE 23732,255: POKE 23733, 255: CLEAR 65535 (es decir, forzar 48K y poner la pila en la parte de memoria "afectada") el sistema no se bloqueaba... al menos no inmediatamente.
- Los juegos de 48K no funcionaban.

¿A que no te imaginas qué pasaba? ;)
Cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista.

Avatar de Usuario
hamham
Mensajes: 273
Registrado: 19 Sep 2012 09:49
Ubicación: Alicante
Agradecido : 37 veces
Agradecimiento recibido: 19 veces

Re: Apuntes sobre problemas en la ram de los gomitas

Mensajepor hamham » 22 Mar 2013 17:47

mcleod_ideafix escribió:¿Por qué usas la dirección 43201 en concreto? Si la memoria alta está estropeada, en una dirección mayor a esa, ese POKE no te resolverá nada.


Hola mcleod, esa parte esta copiada del service manual de spectrum y mis conocimientos no me hacen saber por que el que redacto el paper uso concretamente esa.

mcleod_ideafix escribió:
Lo que hay que hacer es averiguar cuál es la última dirección que el test de memoria dio por bueno, así:

Código: Seleccionar todo

LET D=PEEK 23732+256*PEEK 23733

Si D no es 65535, y el Spectrum es de 48K, hay un problema con la memoria alta. Los dos POKEs que hay que hacer son a la dirección D+1 (la primera que falla), así:

Código: Seleccionar todo

POKE D+1,85: PRINT PEEK (D+1)

Código: Seleccionar todo

POKE D+1,170: PRINT PEEK (D+1)

Aunque yo no suelo usar 170 y 85, sino 0 y 255. El fallo más habitual es que el chip se haya "roto" del todo, y no dé ninguna salida. En ese caso los 1s se leen bien (porque coincide con el bus flotante) pero los 0s no, así que con el POKE D+1,0 suele ser suficiente. Si el valor no es 0, el bit que está fallando te lo da la posición del bit (o bits) que estén a 1 al hacer PEEK (D+1).

Ah! Tampoco se comenta, pero es conveniente hacer los POKE/PEEKs cuando la ULA no está leyendo la pantalla, para que el bus flotante sea de verdad "flotante". Es decir:

Código: Seleccionar todo

POKE D+1,0: PAUSE 1: PRINT PEEK (D+1)


Gracias por enseñarnos a los que tanto nos queda que aprender, esperare un tiempo a que salgan posible erratas o aportaciones tan interesantes como la tuya y modifico el paper.
Saludos

Avatar de Usuario
wilco2009
Mensajes: 2142
Registrado: 07 Ene 2013 16:48
Ubicación: Valencia
Agradecido : 202 veces
Agradecimiento recibido: 384 veces

Re: Apuntes sobre problemas en la ram de los gomitas

Mensajepor wilco2009 » 22 Mar 2013 18:14

Gracias por el aporte, y a mcleod por las puntualizaciones.

Me bajo el paper y en cuanto lo actulices me lo vuelvo a bajar.

Lo dicho, muchas gracias.
"Nada viaja a mayor velocidad que luz con la posible excepción de las malas noticias las cuales obedecen a sus propias leyes."

Douglas Adams. Guía de autoestopista galáctico.

Avatar de Usuario
hamham
Mensajes: 273
Registrado: 19 Sep 2012 09:49
Ubicación: Alicante
Agradecido : 37 veces
Agradecimiento recibido: 19 veces

Re: Apuntes sobre problemas en la ram de los gomitas

Mensajepor hamham » 22 Mar 2013 19:16

Bueno como me voy de finde y no creo que pueda seguir el hilo, actualizo el paper con la informacion proporcionada por maestro mcleod, -thanks
Adjunto en el post inicial modificado a version 2.
Saludetes y buen retrofinde

Avatar de Usuario
Luis
Mensajes: 1979
Registrado: 03 Nov 2010 19:00
Ubicación: Villaquijada del Tuerto
Agradecido : 1411 veces
Agradecimiento recibido: 665 veces

Re: Apuntes sobre problemas en la ram de los gomitas

Mensajepor Luis » 22 Mar 2013 21:13

¿A que no te imaginas qué pasaba? ;)


Me rindo!

Me pasa a mí y me vuelvo loco...
AHA! YOU GOT THE WUMPUS!
HEE HEE HEE - THE WUMPUS'LL GET YOU NEXT TIME!!

BlackHole
Mensajes: 1683
Registrado: 03 Ago 2011 23:07
Ubicación: Aluche, Madrid
Agradecido : 32 veces
Agradecimiento recibido: 526 veces

Re: Apuntes sobre problemas en la ram de los gomitas

Mensajepor BlackHole » 23 Mar 2013 04:40

¿Hacemos un concurso? -derisive
Mi apuesta al azar: el equipo hacía espejo de los 16 KB entre $8000 y $BFFF a los 16 KB entre $C000 y $FFFF porque el bus de direcciones estaba mal.

Avatar de Usuario
wilco2009
Mensajes: 2142
Registrado: 07 Ene 2013 16:48
Ubicación: Valencia
Agradecido : 202 veces
Agradecimiento recibido: 384 veces

Re: Apuntes sobre problemas en la ram de los gomitas

Mensajepor wilco2009 » 23 Mar 2013 11:24

BlackHole escribió:¿Hacemos un concurso? -derisive
Mi apuesta al azar: el equipo hacía espejo de los 16 KB entre $8000 y $BFFF a los 16 KB entre $C000 y $FFFF porque el bus de direcciones estaba mal.


Parece lógico lo que dices, pero entonces al hacer un PRINT PEEK 23732+256*PEEK 23733 para saber la memoria disponible ¿porqué devuelve 49151 en lugar de 65535?
¿No debería equivocarse también la ROM?
"Nada viaja a mayor velocidad que luz con la posible excepción de las malas noticias las cuales obedecen a sus propias leyes."

Douglas Adams. Guía de autoestopista galáctico.

mcleod_ideafix
Mensajes: 925
Registrado: 13 Ene 2012 09:45
Agradecimiento recibido: 8 veces

Re: Apuntes sobre problemas en la ram de los gomitas

Mensajepor mcleod_ideafix » 23 Mar 2013 15:03

BlackHole tiene razón. Eso es lo que pasó. Concretamente, hubo un fallo en uno de los multiplexores que adecúan el bus de direcciones del Z80 al de la memoria dinámica.

La rutina de la ROM no se equivocó porque es un poco más inteligente que el test típico de escribo algo, leo algo. La rutina de la ROM escribe un valor (el 2). Y luego lo que hace es volver a leer lo que ha escrito restándole 1. Luego comprueba si el resultado es 1. Y luego vuelve a hacer lo mismo (restar y comparar). Por eso en el arranque se ve durante un momento unas rayas rojas sobre fondo negro (el 2 en la parte de píxeles hace que se vean líneas verticales cada 8 píxeles, y el 2 en la zona de atributos significa fondo negro, tinta roja).

Si hay espejo de memoria, habrá zonas de memoria que se resten dos veces en lugar de una, y ahí es donde se da cuenta la ROM. Desafortunadamente, no da ningún indicio de qué chip ha fallado (y mira que en la ROM original había espacio de sobra para implementar un test mucho más concienzudo)
Cada vez que se implementa un sistema clásico en FPGA, Dios mata a un purista.

julio
Mensajes: 4
Registrado: 26 Abr 2013 19:07

Re: Apuntes sobre problemas en la ram de los gomitas

Mensajepor julio » 11 Feb 2014 20:26

Hola, solo comentar que explicas en el documento todo sobre memorias, y nos ponemos en el raro caso que
los voltajes estén bien.
Cuando lo normal es que esto no sea así. Lo habitual es que fallen los voltajes y que el implicado o culpable de los fallos suele ser el ztx650 y sus compinches y que antes de cambiar las memorias hay que asegurarse que los voltajes están bien.

Si ampliaramos el documento con ayuda para el reemplazo del ztx650 ó trucos para emular el ztx650.

Me explico, yo uso un TIP31c (TO220) que agüanta bastante mas que el ztx650, hasta 100v 3A con ni mas ni menos que 40W de disipación frente al 1w del ztx650, esto es provechoso.
Imagen
Al ZTX650, le corto las patitas y conecto el TIP31c con unas minipinzas soldadas a él y respetando logicamente las puertas EBC, (no se ponen al libre albedrío). Visto tal cual, por el frente que es romo y suele tener marcado la nomenclatura, de izq a dcha las puertas son CBE.
El tip31c visto de frente dejando el disipador de aluminio detras-->BCE.
asi que ojo:
ztx650/ztx651--->CBE
tip31c-------------->BCE

Alimento la placa y normalmente una o varias de las memorias bajas está en corto, el TIP31c intenta meter la
alimentación correctamente y se calienta que llega a quemar los dedos pero agüanta lo suficiente para calentar
las memorias bajas malas, o sea que tocamos con los dedos las memorias (no el tip31c por que os vais a quemar los dedos de verdad) y de esta manera he arreglado unas cuantas placas de spectrum.
Comentar que el ztx651 se sigue fabricando y es de directo reemplazo al ztx650.
Una vez comprobadas las que se calientan de verdad corto las patas de alimentación de las malas y vuelvo a aplicar voltaje, si hemos dado con la mala o con las malas el tip31c ya no se calienta y suele mostrar una pantalla con basura en paper y border de color.
Para asegurarnos que no vamos a estropear la placa de circuito impreso, corto el resto de patas elimino el cuerpo de la memoria y procedo a extraer cada pata aplicando la punta del soldador y tirando suavemente
y digo suavemente por que las patas de las memorias bajas suelen "abrazar" la placa, o sea que no van rectas.

saludos
Julio.


Volver a “Software Spectrum”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 4 invitados