Reparación Bubble Bobble [SOLUCIONADO]

[ArcadeHacker]

Buenas noches,

Tengo en mis manos una Bubble Bobble original de Taito con problemas en la placa de las cpu como tambien en la placa de video. Por suerte tengo otra que funciona perfectamente y estoy pudiendo aislar temas, aun así se está volviendo una roca...os explico a ver si se os ocurre algo:

-No enciende (watchdogging), la placa cpu problematica está unida a la de video que está ok.
-Voltajes ok, reloj ok.
-ROMs ok, los 3 PAL ok, el custom PS4 (el del dragón) tambien ok.
-La cpu principal (z80 ic50) como también la de sonido (z80 ic45) recibe señal de reset cada 2 segundos +-.
-La cpu esclava a la principal (z80 ic36) no hace nada de nada pq no recibe secuencia de reset y en teoría es normal en este estado de la placa, reloj ok. Según mi comprensión del watchdog esto ocurre pq: el 74ls273 (ic55) no recibe CLK desde el 74ls139 (ic39), ya que este no recibe Enable desde el descodificador de direcciones PAL 16l8 (ic 49).  Osea, que la cpu principal no llama.
-He cambiado la cpu principal (z80 ic50) por una del mismo tipo 100% verificada.
-He comprobado con osciloscopio que hay addressing y datos en la cpu principal, y en los 74ls244 (ic 56  y 57), los 74ls157 (ic 40, 41, 42) y el 74ls245 (ic 45). Lo mismo con la memoria 6264 (ic 44).

Después de todo esto sigo sin averiguar pq no enciende, como dato adicional, cuando la placa está fría se ven algunos gráficos estáticos en plan mosaico y sin ninguna coherencia entre reset y reset.

Lo siguiente que se me ocurre es desoldar la memoria 6264 ic44 para comprobarla.

Se agradece cualquier idea o sugerencia. Gracias!

[ricky2001]

hola edcross, antes de nada felicitarte por tener 2 placas originales de Bubble Bobble, ¿como lo has hecho?, yo hasta la fecha no he conseguido ninguna aunque reconozco que he tenido alguna a tiro

En principio podría ser la ram que mencionas pero no me atrevo a asegurártelo, los zócalos tienen buena pinta?, a veces los malos contactos producen esos fallos,  a ver si Marcos o Pofo leen esto y te pueden ayudar mas que yo.

saludos, Ricky

[ArcadeHacker]

Es mi juego favorito, la primera la conseguí en españa, tenía algún problema y solo fue cambiar un condensador y una rom, esta otra viene de inglaterra. Al precio que van mejor comprarlas así y de paso entretenerse.

No he visto nada raro a nivel soldadura y he repasado todos los ttl esos que menciono...

hola edcross, antes de nada felicitarte por tener 2 placas originales de Bubble Bobble, ¿como lo has hecho?, yo hasta la fecha no he conseguido ninguna aunque reconozco que he tenido alguna a tiro

En principio podría ser la ram que mencionas pero no me atrevo a asegurártelo, los zócalos tienen buena pinta?, a veces los malos contactos producen esos fallos,  a ver si Marcos o Pofo leen esto y te pueden ayudar mas que yo.

saludos, Ricky

[Marcos75]

Cógete los esquemáticos y revisa todo lo que esté conectado directamente al bus de datos de la CPU principal. Esos son los sospechosos.

Un saludo.

[Pofo]

Que tal.

Mira, como dice marcos pillate los esquemas y te digo lo que opino.

Cuando el watchdog es muy rapido yo vi que suele ser cosa de buffers de los buses o algo muy cercano, la putada es que esto es muy complicado de ver por el propio mecanismo del watchdog, si es mas pausado como parece que es tu caso (2 segundos es un periodo que dista de las décimas que tengo en alguna) pues puede ser una ram principal u otra cosa, tal vez podria ser algo relacionado con el propio reset o cosas mas sutiles como malos contactos en zocalos, etc...

Yo, en este sentido tiraría de comparador(el de marcos por ejemplo es una maravilla para estas cosas), y en ese periodo miraria discrepancias esquemas en mano como te indica marcos.

Tampoco se como es el wd de la BB en concreto, a veces puede ser una pijada como una resistencia cortada, un condensador,...

Tienes una coleccion muy buena edcross

[ArcadeHacker]

Gracias a todos, tengo los esquemas, de lo contrario ni de broma hubiese podido identificar todo eso con la poca experiencia que tengo...

Que comparador me recomendais? Tengo el ojo en el tipico HP 10529 pero valen un dineral...

[Marcos75]

Pofo, en principio la frecuencia del watchdog no depende de la avería, sino de la placa. La putada de estas averías es que no se ve nada. Con los esquemáticos en la mano, hay que ver qué bufferes y RAMs están conectados al bus de datos. Habiendo previamente comprobado las EPROMs, claro.

[Pofo]

Marcos. En mi experiencia si tiene que ver es mas he buscado y lus comenta al
go en tu pacmania

 http://www.aumap.org/foro/index.php?topic=979.0

de todos modos a mi por experiencia tampoco opino exactamente igual y miro hasta la conductividad de las pistas de buses

[Marcos75]

Bueno, en realidad no dice eso exactamente.

Los watch-dog típicos funcionan con un contador, que cuenta libremente a la frecuencia que le marca un múltiplo de la frecuencia de video, por ejemplo. Cuando ese contador llega al fin, y se activa su acarreo, ese acarreo activa el reset. Es decir, ese contador nunca debe contar hasta el final.

Para evitarlo, existe un circuito que hace un clear de ese contador, siempre y cuando unas cuántas líneas involucradas estén bien. Si esas líneas están bien, se genera la señal de clear del contador, y este no genera el acarreo.

Como ves, la frecuencia de watch-dog en ese caso está asociada a la del reloj de dicho contador.

Ese es un esquema típico.

En este caso he visto en los esquemáticos que el contador es un 393, y que la señal de clock la genera Vblank.

Un saludo.

[ArcadeHacker]

Correcto, a parte del contador tb lleva un controlador de voltaje, si el +5 se va  amenos de 1.5v este salta y manda reset.

Una duda, el vblank ocurre a la misma frecuencia que el refresco de pantalla? En este caso 59.1856hz?

Bueno, en realidad no dice eso exactamente.

Los watch-dog típicos funcionan con un contador, que cuenta libremente a la frecuencia que le marca un múltiplo de la frecuencia de video, por ejemplo. Cuando ese contador llega al fin, y se activa su acarreo, ese acarreo activa el reset. Es decir, ese contador nunca debe contar hasta el final.

Para evitarlo, existe un circuito que hace un clear de ese contador, siempre y cuando unas cuántas líneas involucradas estén bien. Si esas líneas están bien, se genera la señal de clear del contador, y este no genera el acarreo.

Como ves, la frecuencia de watch-dog en ese caso está asociada a la del reloj de dicho contador.

Ese es un esquema típico.

En este caso he visto en los esquemáticos que el contador es un 393, y que la señal de clock la genera Vblank.

Un saludo.

[ricky2001]

Al precio que van mejor comprarlas así y de paso entretenerse.

El 99% de las placas que compro son "untested" o "not working" me divierto mas reparándolas que jugando

Saludos

[Rockman]

Si, el vblank se dispara a la misma frecuencia que el refresco de pantalla del juego.

Y por lo que veo en los esquematicos, efectivamente la señal Vblank hace de reset del contador que gestiona el /RESET de la CPU principal.
Por cierto no me ha dado tiempo de ver de donde viene la señal de reset de la subCPU (el segundo Z80) al que le llega la señal /SBRES. Lo generan por otro lado?

A ver si un dia tengo en mis manos mis dos bubble bobble bootlegs y me lio con ellas. Creo recordar que una funcionaba, la otra no.

[ArcadeHacker]

Funciona de la siguiente manera:

El IC 39 un 74LS139 escucha primero las lineas MA8 y MA7, si hay MA7 resetea el contador del Watchdog, si hay MA8 llama a la parte del sonido para que escuche el mensaje.

Despues, si no se ha llamado ni MA8 ni MA7, el mismo IC 39 escucha la linea MA6, en ese caso despierta a IC 55 un 74ls273, y este ultimo lee el bus de datos para lo siguiente:

    Addr                         Data
    1111101101------   W -----xxx           ROM bank
    1111101101------   W ----x---           n.c.
    1111101101------   W ---x---- SBRES     reset CPU #2
    1111101101------   W --x----- SEQRES    reset MCU
    1111101101------   W -x------ BLACK     blank screen
    1111101101------   W x------- VHINV     flip screen

Como verás hay un bit para resetear la CPU #2 y este IC 55 tiene conexión directa al reset de la cpu secundaria.

En mi caso este IC 55 nunca envia la secuencia de reset a la cpu secundaria, y por lo que tengo entendido es la cpu principal la que no envia la orden.

Este fin de semana espero poder investigar más, y a falta de un fluke 9010a pues llegar a desoldar la memoria principal para comprobarla en caso de ser necesario. 

Si, el vblank se dispara a la misma frecuencia que el refresco de pantalla del juego.

Y por lo que veo en los esquematicos, efectivamente la señal Vblank hace de reset del contador que gestiona el /RESET de la CPU principal.
Por cierto no me ha dado tiempo de ver de donde viene la señal de reset de la subCPU (el segundo Z80) al que le llega la señal /SBRES. Lo generan por otro lado?

A ver si un dia tengo en mis manos mis dos bubble bobble bootlegs y me lio con ellas. Creo recordar que una funcionaba, la otra no.

[Marcos75]

Funciona de la siguiente manera:

El IC 39 un 74LS139 escucha primero las lineas MA8 y MA7, si hay MA7 resetea el contador del Watchdog, si hay MA8 llama a la parte del sonido para que escuche el mensaje.

Despues, si no se ha llamado ni MA8 ni MA7, el mismo IC 39 escucha la linea MA6, en ese caso despierta a IC 55 un 74ls273, y este ultimo lee el bus de datos para lo siguiente:

En realidad la comprobación que hace el watchdog es más compleja, porque están involucradas más líneas del bus de direcciones, a través de la PAL, que es la que manda la señal de enable al 139...

Creo que comentaste que esa PAL está bien. Esta claro que hay algo conectado al bus de datos que no está bien, incluyendo las propias CPUs.

Un saludo.

[ArcadeHacker]

Ese PAL descodifica direcciones para pasarlas a otras partes pero desconozco en que situaciones desactiva el 139, por defecto me lo encuentro siempre en Active low, por lo tanto el 139 encendido.

Ayer hice un rapido repaso de las lineas de direccionamiento que he nombrado y no hay nada mal entre la cpu principal y esa región... Este fin de semana le meto unas horas más.

Funciona de la siguiente manera:

El IC 39 un 74LS139 escucha primero las lineas MA8 y MA7, si hay MA7 resetea el contador del Watchdog, si hay MA8 llama a la parte del sonido para que escuche el mensaje.

Despues, si no se ha llamado ni MA8 ni MA7, el mismo IC 39 escucha la linea MA6, en ese caso despierta a IC 55 un 74ls273, y este ultimo lee el bus de datos para lo siguiente:

En realidad la comprobación que hace el watchdog es más compleja, porque están involucradas más líneas del bus de direcciones, a través de la PAL, que es la que manda la señal de enable al 139...

Creo que comentaste que esa PAL está bien. Esta claro que hay algo conectado al bus de datos que no está bien, incluyendo las propias CPUs.

Un saludo.

[Pofo]

Marcos y las lineas de control que luego manejan la señal clear no actuan muy diferente por ejemplo de cuando por ejemplo un bus tiene un bit comprometido a que si por ejemplo hay un error de codigo¿?¿?, te lo digo porque por ejemplo la konami GT (que tiene un porron de historias) al cambiarle los buffers el WD cambia y me da ya un margen, antes tu pudiste ver que era la locura.

De otro modo, no se si probasteis a experimentar en reparaciones anulado en wd directamente.

La verdad que yo no se que es lo que valora en wd en este caso, ni tampoco se si es factible diferir entre WD con periodo identico al ciclo del contador (el clear no actua nunca), el tema del WD lo atajo de otra manera radicalmente distinta siempre mirando cpu-ram-buffers-eprom-buses (alguna vez he tenido alguna linea en corto).

Despues yo tiendo a seccinar patas por la base para meter mi reset, pero esto ya son gustos.

En mi experiencia ya digo, hay diferencias en funcion de la frecuencia, pero no es una ciencia exacta obviamente, al igual que no es una ciencia exacta sospechar de buffers porque a veces tienen muchos mas elementos enganchados a un bus o incluso elementos vinculados a la cpu que desencadenan el WD (y por ejemplo en este caso si que he tenido una carrier bootleg que me lo forzaba cada 4-5 segundos, por esto lo de los tiempos.

En el caso de la carrier, cuando salia de la pantalla de comprobacion de eproms, me saltaba el wd porque no podia cargar unos datos en una ram de video que en ese momento se conectaba al bus.

Bueno, es mi opinion jajajajajajajaj. En este caso, despues de escribir todo lo que se me ha venido en el momento a la cabeza jijijijiji, diria que es una ram o algo directamente conectado a un bus directamente (y lo de mirar el aislamiento de los buses es una prueba muuuuuuuuuy interesante).

Saludos a todos menos a Marcos, a Marcos no le saludo hoy jijijijijijiji

[Pofo]

Funciona de la siguiente manera:

El IC 39 un 74LS139 escucha primero las lineas MA8 y MA7, si hay MA7 resetea el contador del Watchdog, si hay MA8 llama a la parte del sonido para que escuche el mensaje.

Despues, si no se ha llamado ni MA8 ni MA7, el mismo IC 39 escucha la linea MA6, en ese caso despierta a IC 55 un 74ls273, y este ultimo lee el bus de datos para lo siguiente:

    Addr                         Data
    1111101101------   W -----xxx           ROM bank
    1111101101------   W ----x---           n.c.
    1111101101------   W ---x---- SBRES     reset CPU #2
    1111101101------   W --x----- SEQRES    reset MCU
    1111101101------   W -x------ BLACK     blank screen
    1111101101------   W x------- VHINV     flip screen

Como verás hay un bit para resetear la CPU #2 y este IC 55 tiene conexión directa al reset de la cpu secundaria.

En mi caso este IC 55 nunca envia la secuencia de reset a la cpu secundaria, y por lo que tengo entendido es la cpu principal la que no envia la orden.

Este fin de semana espero poder investigar más, y a falta de un fluke 9010a pues llegar a desoldar la memoria principal para comprobarla en caso de ser necesario. 

Si, el vblank se dispara a la misma frecuencia que el refresco de pantalla del juego.

Y por lo que veo en los esquematicos, efectivamente la señal Vblank hace de reset del contador que gestiona el /RESET de la CPU principal.
Por cierto no me ha dado tiempo de ver de donde viene la señal de reset de la subCPU (el segundo Z80) al que le llega la señal /SBRES. Lo generan por otro lado?

A ver si un dia tengo en mis manos mis dos bubble bobble bootlegs y me lio con ellas. Creo recordar que una funcionaba, la otra no.

Que señal te da ma7¿?

El bus de direcciones muestra actividad entre reseteos?.

Leyendo con un poco de tiempo todo el hilo creo que el analisis que estas haciendo no te va a llevar a conclusiones, me da a mi que tienes la ram principal mal (o lo que te comentan).

[Rockman]

edcross, mi consejo es que sigas el consejo de los expertos y mires la Ram principal primero.

[Marcos75]

Marcos y las lineas de control que luego manejan la señal clear no actuan muy diferente por ejemplo de cuando por ejemplo un bus tiene un bit comprometido a que si por ejemplo hay un error de codigo¿?¿?

Lo que hace el watch-dog generalmente es comprobar que el programa principal lleva su curso normal. Detecta si el programa entra en un bucle, o similar, muchas veces porque determinadas direcciones se quedan "estancadas" (por ejemplo, si el programa ha entrado en un bucle infinito). Otros circuitos incorporan líneas de datos en la comprobación, y comprueban que no haya ninguna "atada" también.

Por eso, cuando hay un problema directamente en el bus de datos de programa (que es lo que estamos diciendo desde el principio aquí), el reseteo es muy rápido, y de frecuencia siempre constante. Pero también puede suceder que tengamos, por ejemplo, una ROM gráfica mal, que utiliza el bus de datos, u otra zona del circuito que también comparte bus de datos. Estos fallos, a lo mejor no se detectan hasta pasado un tiempo, que es cuando el programa va a acceder a dichos datos. En ese caso, efectivamente la frecuencia de reseteo es menor.

Pero cuando el problema es en los integrados que gestionan la ejecución del programa, el watch dog resetea con una frecuencia constante, y muy rápida.

Por eso estamos diciendo que aquí el fallo está o en la CPU principal (ya está comprobada, y no es), en la RAM de programa, o en los bufferes que van al bus de datos (principalmente aquellos que leen puertos (incluyendo dip switches) y que están entre CPU y RAM principal).

Un saludo.

[Pofo]

Marcos y las lineas de control que luego manejan la señal clear no actuan muy diferente por ejemplo de cuando por ejemplo un bus tiene un bit comprometido a que si por ejemplo hay un error de codigo¿?¿?

Lo que hace el watch-dog generalmente es comprobar que el programa principal lleva su curso normal. Detecta si el programa entra en un bucle, o similar, muchas veces porque determinadas direcciones se quedan "estancadas" (por ejemplo, si el programa ha entrado en un bucle infinito). Otros circuitos incorporan líneas de datos en la comprobación, y comprueban que no haya ninguna "atada" también.

Por eso, cuando hay un problema directamente en el bus de datos de programa (que es lo que estamos diciendo desde el principio aquí), el reseteo es muy rápido, y de frecuencia siempre constante. Pero también puede suceder que tengamos, por ejemplo, una ROM gráfica mal, que utiliza el bus de datos, u otra zona del circuito que también comparte bus de datos. Estos fallos, a lo mejor no se detectan hasta pasado un tiempo, que es cuando el programa va a acceder a dichos datos. En ese caso, efectivamente la frecuencia de reseteo es menor.

Pero cuando el problema es en el programa, el watch dog resetea con una frecuencia constante, y muy rápida.

Por eso estamos diciendo que aquí el fallo está o en la CPU principal (ya está comprobada, y no es), en la RAM de programa, o en los bufferes que van al bus de datos (principalmente aquellos que leen puertos (incluyendo dip switches) y que están entre CPU y RAM principal.

Un saludo.

Pues si, es lo que pienso yo, pero tambien te digo una cosa en alguna placa el bus de direcciones se me quedo clavado porquemetía una direccion con alguna linea que hiba a lineas de control y que afectaban al bus de datos, con lo que tendias a pensar en el bus de datos y no, y lo mas puto no es esto, es que NO TENIA FORMA DE SABERLO al menos con mis medios.

La verdad que a veces por falta de tiempo no sigo el hilo desde el principio, hay si que entono el mea culpa.

Despues sobre el wd cuando es proximo a la cpu, osease este caso), yo ya digo que mi filosofia es distinta porque hombre si tienes paciencia puedes ver algo, pero yo no la tengo.

[ArcadeHacker]

Actualización

Sobre el control del watchdog. Estuve mirando un rato ayer y se puede desconectar tirando a tierra el pin 11 del 74LS139 IC 39, o la conexión de destino que es el pin 2 del 74ASL240 IC 35. Con esto conseguimos que en todo momento le llegue un nivel alto a las patas de Clear del contador del watchdog 74LS393 IC 31. Tiramos a tierra y con eso conseguimos un nivel alto? Si pq el IC 35 previo al contador es un inversor, si le entra bajo lo saca alto y viceversa.

Sobre la función del PAL 49. He tenido la sorpresa de descubrir que ninguno de los 3 PALs utilizados en el Bubble Bobble original están emulados. No solo no lo están, sino que tampoco parece que existan volcados o mapas de la lógica que llevan.

Igualmente ya tengo bastante más comprensión sobre su funcionamiento, a modo sumario este PAL vigila varias lineas de addressing (no voy entrar en detalles) y varios estados de la cpu (IORQ, RD, MREQ), y en base a su uso o no uso actua en consecuencia con sus salidas. Una vez haya podido reparar esta placa me tomo como reto siguiente el mapear estos pals para que exista emulación o poder hacer GALs que puedan reemplazarlos en caso de avería.

Duda para expertos en Z80. Me asalta la duda de para que se usa IORQ ya que mirando el código maquina principal del Bubble Bobble (Roms 6 y 5) no encuentro ninguna operación de tipo OUT/IN, con lo cual no se pq el PAL que menciono arriba hace uso de esa linea. Hay alguna operación en el Z80 a parte de OUT/IN que haga uso de IORQ?

Comprobación de las memorias. Al final he decidido no desoldarla todavía, la semana pasada conseguí hacerme con un Fluke 9010a y varios pods a muy buen precio. Prefiero esperar a que me llegue este trasto y hacer las pruebas con el y no tener que pasar por quirofano.

Saludos.

[enricnes]

Sobre la función del PAL 49. He tenido la sorpresa de descubrir que ninguno de los 3 PALs utilizados en el Bubble Bobble original están emulados. No solo no lo están, sino que tampoco parece que existan volcados o mapas de la lógica que llevan.

Estas seguro? http://www.jammarcade.net/pal-dumps/

Por cierto, que pods has conseguido? Y el 9010A?

Saludos!

[ArcadeHacker]

Buenas Enricnes, seguro hasta donde yo pude investigar. En la página que indicas veo 3 del bootleg del Bubble, correcto o hay de la original?

Pods: Z80, 6800 6802-6808, 6809, 68000.

Sobre la función del PAL 49. He tenido la sorpresa de descubrir que ninguno de los 3 PALs utilizados en el Bubble Bobble original están emulados. No solo no lo están, sino que tampoco parece que existan volcados o mapas de la lógica que llevan.

Estas seguro? http://www.jammarcade.net/pal-dumps/

Por cierto, que pods has conseguido? Y el 9010A?

Saludos!

[enricnes]

Tambien esta la original.
Por cierto, enhorabuena por los pods, has conseguido dos de los mas dificiles de conseguir, el 68000 y el 6809.
Saludos!

[ArcadeHacker]

Ahora si los he visto y bajado, gracias!!

Tambien esta la original.
Por cierto, enhorabuena por los pods, has conseguido dos de los mas dificiles de conseguir, el 68000 y el 6809.
Saludos!

[Marcos75]

Duda para expertos en Z80. Me asalta la duda de para que se usa IORQ ya que mirando el código maquina principal del Bubble Bobble (Roms 6 y 5) no encuentro ninguna operación de tipo OUT/IN, con lo cual no se pq el PAL que menciono arriba hace uso de esa linea. Hay alguna operación en el Z80 a parte de OUT/IN que haga uso de IORQ?

No soy experto ni mucho menos en Z80, pero me animo a contestar. /IORQ es una señal que genera el Z80. Lo hace durante un ciclo de entrada/salida, e indica que ha puesto en el bus de direcciones (en la parte baja) una dirección, que ya es válida para esa lectura/escritura. Ten en cuenta que tienes varias CPUs, y que quizá no sea el código principal el que hace las operaciones de entrada y salida.

Comprobación de las memorias. Al final he decidido no desoldarla todavía, la semana pasada conseguí hacerme con un Fluke 9010a y varios pods a muy buen precio. Prefiero esperar a que me llegue este trasto y hacer las pruebas con el y no tener que pasar por quirofano.

Como dicen en mi pueblo, con buena picha bien se jode. Yo ya hubiera quitado esa memoria hace una semana

[Characa]

Marchando un poco de teoría del funcionamiento del Z80

http://proton.ucting.udg.mx/dpto/maestros/mateos/z80/arquitectura/arquitectura.html

[Pofo]

Actualización

Sobre el control del watchdog. Estuve mirando un rato ayer y se puede desconectar tirando a tierra el pin 11 del 74LS139 IC 39, o la conexión de destino que es el pin 2 del 74ASL240 IC 35. Con esto conseguimos que en todo momento le llegue un nivel alto a las patas de Clear del contador del watchdog 74LS393 IC 31. Tiramos a tierra y con eso conseguimos un nivel alto? Si pq el IC 35 previo al contador es un inversor, si le entra bajo lo saca alto y viceversa.

Sobre la función del PAL 49. He tenido la sorpresa de descubrir que ninguno de los 3 PALs utilizados en el Bubble Bobble original están emulados. No solo no lo están, sino que tampoco parece que existan volcados o mapas de la lógica que llevan.

Igualmente ya tengo bastante más comprensión sobre su funcionamiento, a modo sumario este PAL vigila varias lineas de addressing (no voy entrar en detalles) y varios estados de la cpu (IORQ, RD, MREQ), y en base a su uso o no uso actua en consecuencia con sus salidas. Una vez haya podido reparar esta placa me tomo como reto siguiente el mapear estos pals para que exista emulación o poder hacer GALs que puedan reemplazarlos en caso de avería.

Duda para expertos en Z80. Me asalta la duda de para que se usa IORQ ya que mirando el código maquina principal del Bubble Bobble (Roms 6 y 5) no encuentro ninguna operación de tipo OUT/IN, con lo cual no se pq el PAL que menciono arriba hace uso de esa linea. Hay alguna operación en el Z80 a parte de OUT/IN que haga uso de IORQ?

Comprobación de las memorias. Al final he decidido no desoldarla todavía, la semana pasada conseguí hacerme con un Fluke 9010a y varios pods a muy buen precio. Prefiero esperar a que me llegue este trasto y hacer las pruebas con el y no tener que pasar por quirofano.

Saludos.

Es que el iorq lo genera la cpu de acuerdo a un algoritmo interno por el uso del bus direcciones, no tiene que ver con instrucciones de puertos.

Joder un fluke 9010a....eso a cuanto se cotiza???

Edito...veo que llego tarde jajajajajajaj, ya habian contestado mil posts jijijiji, es lo que tiene andar al salto la rana mil perdones.

[Rockman]

@edcross: con el Fluke 9010a podrás hacer la segunda parte de la peli "juegos de guerra". ;-)
Ya nos enseñaras el aparatito en algún momento.

@Characa: gracias por los apuntes del Z80.

[ArcadeHacker]

Gracias! No me ha quedado nada claro el texto en español sobre la relación de M1 y IORQ pero buscando otro texto alternativo ya lo he entendido mejor:

http://devster.monkeeh.com/z80/pio80.html

System Control:
When M1 and MREQ are both active, then that indicates that the current machine cycle is the opcode fetch cycle of an instruction execution (first process in getting the opcode/instruction from memory). When M1 and IORQ are both active, then that indicates an interrupt acknowledge cycle (an interrupt response vector can be placed on the data bus). Pin is an output, and active Low.

Marchando un poco de teoría del funcionamiento del Z80

http://proton.ucting.udg.mx/dpto/maestros/mateos/z80/arquitectura/arquitectura.html

[ArcadeHacker]

Lo haré, tengo ganas de meterle mano.

@edcross: con el Fluke 9010a podrás hacer la segunda parte de la peli "juegos de guerra". ;-)
Ya nos enseñaras el aparatito en algún momento.

@Characa: gracias por los apuntes del Z80.

[Pofo]

Se puede saber el precio del fluke con los adaptadores para z80 y 6502?



Jajajajjaja, acabo de ver el privado, estoy atolondrado ultimamente, jijijiji. Esta muuuuy bien de precio lo que has conseguido, es que en su dia lo mire para otra cosa y se me disparaba justo al doble con dos adaptadores, eso si, nuevo, y era ya un precio muy bueno.

Saludos y ya nos contaras.

[ArcadeHacker]

Buenas a todos, ya de vuelta de semana santa y con actualizaciones importantes.

Fluke en mano y con el watchdog desactivado ayer ya pude validar que mi teoría inicial sobre un problema de memoria de trabajo era cierta, leyendo de la memoria principal siempre veo 7E, lea lo que lea y escriba lo que escriba....pero...resulta que el problema tb ocurre con la memoria compartida con el custom...

Pregunta mental del momento: Ambas memorias están mal? Y ambas con el mismo síntoma? Poco probable... Así que fui directamente al bus encargado de servir datos a la cpu principal y bingo! Haciendo piggybacking con otro 74LS245 comencé a poder leer cosas coherentes de la memoria y tb escribir.

Cuando digo "comencé" es pq el problema no estaba completamente solucionado, lectura y escritura a la memoria de trabajo compartida con el custom ok, pero por algún motivo el bit 8 de datos hacia la memoria principal de trabajo no estaba funcionando.

Ya con el 74LS245 reemplazado y con un vistazo rápido al esquema pude ver que hay otro 245 en cascada con este antes de llegar a la memoria principal de trabajo. Con el osciloscopio ví claramente que el bit 8 entraba bien pero no salía del bus, lo raro es que haciendo piggybacking con otro 245 adicional mostraba el mismo comportamiento?

Me dio tiempo a desoldar este 245 y pasarlo por el programador, dando el resultado OK... El programador es un minipro TL866 barato, osea que a saber... El 245 de reemplazo tb da OK.

Esta noche le meto un socket y a ver que pasa, a cruzar los dedos


ps: El fluke es mano de santo, una diferencia muy grande entre estar a merced de lo que quiera hacer la placa, a estar tu en control en cada momento de lo que se hace con las lineas de direccionamiento y datos.

[Rockman]

Hola Edcross!

Creo entender que esos 245 te estaban fijando el bus de datos provocando que luego saltara el Watchdog.
A ver si cuando cambies el otro 245 empieza la cosa a funcionar.

Por cierto cuando hablas de Piggybacking supongo que te refieres a sombrerear el 245 con otro, no?

En este caso creo que has matado una mosca a cañonazos con el Fluke este, pero supongo que cuando lo domines, el aparatejo este te va a facilitar mucho detectar averías más jodidas.

Falta que inventen un Fluke que repare chips custom tan solo apretando un botoncito.

Saludos.

[ArcadeHacker]

Buenas Rockman, sí, efectivamente ese primer 245 estaba rompiendo cualquier dato que la cpu principal quisiera leer/guardar en memoria o compartir con otro componente. Ese 245 ya lo había "revisado" pero está claro que no lo hice bien.

Muy bueno lo de sombrerear, nunca lo había escuchado. Esta noche os cuento que sucede con el otro 245.

Hola Edcross!

Creo entender que esos 245 te estaban fijando el bus de datos provocando que luego saltara el Watchdog.
A ver si cuando cambies el otro 245 empieza la cosa a funcionar.

Por cierto cuando hablas de Piggybacking supongo que te refieres a sombrerear el 245 con otro, no?

En este caso creo que has matado una mosca a cañonazos con el Fluke este, pero supongo que cuando lo domines, el aparatejo este te va a facilitar mucho detectar averías más jodidas.

Falta que inventen un Fluke que repare chips custom tan solo apretando un botoncito.

Saludos.

[ArcadeHacker]

Novedades, el segundo 245 estaba bien tal y como dijo el tester, indagando he visto que lo que sucede es que la linea datos 7 en esta parte del circuito está tirada a tierra... después de indagar un poco más me he decidido a sacar la memoria y bingo, la pata D7 da continuidad con la pata de GND... El tester confirma la memoria como mala.

Toca ir de compras, sockets 28 wide y una memoria 6264.

[Pofo]

Esos sockets en china se compran en lotes de 10-20 por un euro o dos, miralo en ebay por ejemplo.

[ricky2001]

Eso si que es un instrumento útil, me alegro que hayas encontrado el fallo, si alguna vez veo uno a tiro no lo dudaré es la mejor herramienta para las placas sin ninguna duda.

Saludos

[ArcadeHacker]

Al final compré en europa (100 por 20 eur), a veces comprar de china es jugarsela con el tiempo, paso de esperar un mes.

Si alguien quiere la mitad de estos sockets dil28 por la mitad de lo que me han costado que me diga, eso o creo que me van a servir de herencia.

Esos sockets en china se compran en lotes de 10-20 por un euro o dos, miralo en ebay por ejemplo.

[Pofo]

Que va, no te la juegas para nada....es un mes o dos jajajajaajajajja

Pero 20 zocalos te cuestan un eurapio o asi...con envio y todo.

Yo antes destripaba placas, ahora me he volvido mas fisnolis.

[enricnes]

Yo te tomo esa mitad que ofreces si nadie se la ha quedado antes.
Saludos!

[ArcadeHacker]

ok, te escribo un pm cuando me lleguen.

Yo te tomo esa mitad que ofreces si nadie se la ha quedado antes.
Saludos!

[Pofo]

Has probado a medir el valor de la resistencia desde el gnd de la ram a la pata en corto y luego moverlo a la pata de buffer y medir?

Notas algo?

[ArcadeHacker]

Supongo que te refieres a con la memoria colocada en la placa, ahora mismo está desoldada y fuera de la placa, cuando me lleguen los zocalos lo pruebo.

[ArcadeHacker]

 



Memoria cambiada, despues de eso se resistió un poco más hasta que di con un LS157 encargado de varias lineas de direccionamiento con una de ellas (bit 2) a tierra.

Ahora ya arranca y se puede llegar a jugar. Aun con estas va a necesitar más tiempo ya que se va reseteando sola cada x tiempo o se acaba colgando.

Podeis ignorar la ausencia de color en la pantalla, es mi cable del monitor...

[Rockman]

Genial Edcross tu placa ya empieza a funcionar. A ver si descubres quien te provoca esos reseteos aleatorios. Podrían ser tema de rams ¿?

Por cierto no sabia que el emulador Fluke tuviera wifi jejejejeje. ;-)

Saludos.

[Marcos75]

Con respecto a los reseteos aleatorios, asegúrate de que los 5.0 V están llegando bien a todos los puntos de la placa.

Un saludo.

[Pofo]

si has encontrado dos cortos a gnd y no es tema de tensiones que comenta marcos...ojala no sea un corto interno por la dilatacipn del calor...son un asco de localizar...pero dada tu averia lo veria posible

[ArcadeHacker]

Correcto, he cambiado tres componentes directamente relacionados, un 245, 157 y la memoria de trabajo. El 157 y la memoria ambos con problemas de corto.

Cuando comentas corto interno, te refieres a dentro del integrado?

Teniendo el contador del watchdog desactivado no se exactamente que puede estar haciendo esos resets a parte del otro componente del watchdog que vigila el +5, para que este salte creo que hay que tener una bajada importante en el +5 (por debajo de 2.5v creo recordar).

Me va a tocar hacer mucha medición . A parte me queda la placa de video que tb vino muerta, a saber que como ocurrió todo esto.

si has encontrado dos cortos a gnd y no es tema de tensiones que comenta marcos...ojala no sea un corto interno por la dilatacipn del calor...son un asco de localizar...pero dada tu averia lo veria posible

[Marcos75]

Lo primero que yo haría sería comprobar que los reset que observas realmente llevan asociados un pulso a nivel bajo en el pin RESET de la CPU principal. Entiendo que sí, porque que yo sepa el Z80 no lleva un "circuito interno" de reset, o algo así. ¿Alguien lo sabe a ciencia cierta?

Si el contador no está provocando los RESET, entonces tiene que ser el circuito de RESET el que lo está haciendo, entiendo. Echando un vistazo a los esquemáticos veo que ese circuito, aparentemente (que alguien me corrija si me equivoco) debería resetear la CPU si la tensión cae por debajo de unos 4.2 V, con lo cual:

- Revisa que la tensión no esté cayendo realmente por debajo de ese valor.
- Quizá el circuito ese esté tocado.

Un saludo.

[Pofo]

No, solo hy una version embebida que yo conozca con generador interno lo usan unas maquinas vax vms.

No tiene porque ser tema directo del circuito de reset, a veces la caida de tension es por causas muy dispares y el circuito de reset solo es la parte ejecutora.

La tension a veces car mas de 4 voltios y no resetea.

A ver que es al final, tengo curiosidad, yo me inclino a pensar que es un component tocado ql dilatarse, pero puedes confirmar si  el reseteo tarda al princio y cuando calienta la pcb es mad reiterado?

Saludos.

[ArcadeHacker]

@Marcos: mirando el folleto del mb3771 que vigila esto: "User selectable threshold level with hysterisis (VSB = 1.23 V ± 1.5 %)" Significa que vigila el +5 y si cae más de 1.23v entonces hace reset? eg: 3.77v

@Pofo: Recuerdo que era evidente que a más tiempo encendida peor el comportamiento.

[Marcos75]

edcross, ese dato que indicas es cuando tú seleccionas Vs mediante resistencias externas. En los esquemáticos se ve que el Bubble Bobble no usa esas resistencias externas, con lo que Vs es fijo, y adopta un valor de en torno a 4.2V con una histieresis de 0.1 V aprox...

Pofo, para que el Z80 se resetee le tiene que llegar una señal de reset, y alguien la tiene que generar... Es decir, el origen seguramente sea el que tú mencionas, pero al final alguien tiene que ejecutar el RESET...

[enricnes]

Para estos casos creo recordar que iba bien un spray de aire frio, para ir enfriando por zonas y localizar el integrado problematico.
Saludos!

[Pofo]

Creo que estais centrados en algo obvio. El reset salta da igual si a 4 o a 2.

Creo que la causa no es ese circuito sino lo que comento lohe sufrido ya un integrado me comprpmete los 5 y el wd me
 resetea

perdonar que no me extienda macho eatoy por el mundo y este teclado es de movil

[Marcos75]

Pues creo que no es lo mismo que el reset salte a 2 que a 4.2V. Una vez sabido que es únicamente el controlador de voltaje quien tira la placa, podemos buscar por esa línea.

Que la tensión caiga a 4.2 V puede ser fácil por dos motivos, por ejemplo:

- El cableado JAMMA + ADAPTADOR no tiene la sección suficiente, y a medida que se calienta, varía la resistencia y por tanto la tensión la corriente, lo que puede acabar provocando caídas de tensión.

- Un componente defectuoso consume mucha corriente a medida que se calienta (por ejemplo por un corto) y hace bajar la tensión.

Pero que la tensión caiga a 2V es únicamente debido a un problema muy gordo, por ejemplo, con la sección de los cables...

[ArcadeHacker]

Gracias gurus! saldremos de dudas pronto, esta noche le pongo el oscilo a ver quien hace el reset.

[Marcos75]

¡Al ataque! 

[Pofo]

Marcos. Si es lo mismo porque ai es por temperatura es obvio q.ue me importa poco.

Si el wd salta a 4 o a 2 es un hablar....a 2 no funciona una cpu. Pero al arrancar tras el reseteo eso me dice que tanto no baja y es una dilatacion que me mete una resistencia parasita.

Es mas. Diria que si mide tensiones le dara unos 4,6 o asi y no baja ni en el reseteo (aparentemente de 4).haz esta medida edcross

la secciones qufe comentas....basico mirarlo si

mira si no te importa si la placa aparentemente tiene unos 4,7 v o asi y si la cuesta a la fuente regular

es una pena pero no puedo ensenarte u. Aparato que hice para esto

Yo en este caso enfrio zonas con celula peltier

[Pofo]

Me cupesta escrbir lo q quiero plasmar asiq ue mejor sigo en casa esto frustra macho

[Marcos75]

Tenemos distintos puntos de vista... pero ahí está la gracia, ¿no?

[Pofo]

Eso es lo bueno jijij.

Manana voy a casa, te mando mail pa quedar marcos.

Riky si lees esto pdemos quedar los3 mando mail a los 2 manana

[ArcadeHacker]

Buenas,

Ya tengo más datos, nadie ejecuta un reset a la CPU principal usando la linea de reset, ha de ser la propia cpu principal la que lo hace (saltar a la dirección 0000) para comenzar de nuevo. Mirando el codigo de la ROM se confirma que existe la instrucción en el codigo: 0D0Eh = RST 0.

A falta de profundizar más, mi teoría es que el problema se encuentra en la CPU secundaría/esclava. Esa CPU está totalmente controlada por la principal y seguramente tiene problemas de acceso o escritura. De hecho el juego solo se suele resetear cuando hay movimiento de personajes del juego (ya sea en demo o jugando), en la portada o pantallas sin acción de personajes no suele ocurrir.

Por si las moscas he dejado el fluke en loop testeando insistentemente las memorías accesibles por la cpu principal y tambien cambiado la memoría principal por otra por si acaso.  Todo ok.

Tirando de tester me he encontrado algo raro en una salida de un LS157 justo al lado del 157 defectuoso que ya había reemplazado, este otro 157 al igual que el reemplazado lleva direccionamiento de la cpu principal y esclava contra la memoria de trabajo principal. Midiendo resistencia en todas sus salidas comparadas con ground me da 700-800 excepto en una que da 150, esa salida conecta directamente con el bit 5 de direccionamiento de la memoría principal. He quitado la memoria principal por si acaso y sigue dando la misma lectura.

Que creeis? le meto el cuchillo? 

[Marcos75]

El 157 tiene la misma estructura interna en sus 4 multiplexores, con lo cual lo que mides no parece tener mucho sentido, siempre que el circuito de carga sea el mismo en todos casos (siempre que todas las salidas del 157 tengan conectado lo mismo a su salida).

Una menor resistencia hace que esa salida sea más vulnerable al ruido... En mi Konami GT, que tenía también un problema de ruido en un 157, con la placa en frío el problema no se manifestaba, pero a medida que se calentaba el problema se agravaba. Puedes probar a poner un condensador de filtrado a ver si la cosa mejora, o "tirar de cuchillo" (como tú dices) directamente.

Un saludo.

[Pofo]

 Mirando el codigo de la ROM se confirma que existe la instrucción en el codigo: 0D0Eh = RST 0.

el juego solo se suele resetear cuando hay movimiento de personajes del juego

salida de un LS157 justo al lado del 157 defectuoso ... Midiendo resistencia en todas sus salidas comparadas con ground me da 700-800 excepto en una que da """150"""

Que creeis? le meto el cuchillo? 

Has medido en la placa entiendo, tal vez por la arquitectura de la placa sea tema de ruido como dice marcos.

A la luz de estas nuevas investigaciones, damos por probable que se fuerce el rst por soft.

Hablo ahora sin saber edcroos, el fluke ese tiene alguna funcion de trazado que nos deje mirar cuando se resetea o nos deje  congelada la ejecucion?, puedes usarla?, realmente es que no conozco la potencialidad de esa herramienta.

Al principio cuando arranca en "frio" va todo bien o ya desde el principio casi al salir esos muñecos se resetea¿?,

Llegado este punto una buena herramienta seria el comparador, por ejemplo uno bit a bit.

Si tienes un poco de arte, puedes levantar la pata de gnd sin extraerlo montarle el otro encima y hacer un puente a gnd momentaneo. si estas por probarlo, pero en principio sobre la placa aunque sean distintas resistencias entiendo que es por la arquitectura de la placa y entiendo que si hubiera ruido tendria que haber algun filtrado.

[Marcos75]

Coño, Pofo, ya no escribes "raro"

[ArcadeHacker]

La linea de la resistencia rara es una via directa entre el 157 y la memoria, hice la prueba de sacar la memoria del socket para ver si tenia relacion pero no, la medicion rara sigue. Esta noche lo vuelvo a mirar y le meto el oscilo a ver que hay. El tema del ckndensador se lo meto entre esa salida y gnd o entre las entradas y gnd?

[Pofo]

Coño, Pofo, ya no escribes "raro"

ajjajaja, como en casa...

[Marcos75]

Si la "discrepancia" que observaste con el comparador era a la salida, puedes ponerle un condensador de 47p (por ejemplo), o de 220p, entre la salida "discrepante" y masa, a ver si la cosa mejora.

Un saludo.

[Pofo]

He notado en varias placas que con solo poner el comparador encima, si hay ruido, solo con poner el comparador encima notas cambios e incluso en la galaxian de crazyclimber al situar el comparador encima de un integrado con ruido que me dejaba la matriz de calibrado permanentemente, me atenuaba el ruido de las salidas.

Saludos.

[ArcadeHacker]

Efectivamente este 157 no estaba fino, en amarillo la señal de salida de la pata con poca resistencia contra ground y en verde la misma de un 157 adyacente.



Confirmado también como malo por el programador una vez sacado de la placa. Igualmente cambiarlo por uno bueno no ha servido de nada, el problema de los resets continua. Sea por el motivo que sea este 157 estaba cumpliendo su misión ya que de lo contrario la cpu principal no hubiese podido jamás utilizar la linea de direccionamiento 5 y los tests de memoria dar ok....

A seguir mirando.

[Pofo]

afortunados los que ahí veis mas de un color...jajajajajajajajajaj

[Marcos75]

Jajajaja, qué bueno, Pofo.

En realidad los niveles TTL son así de curiosos. Con poco más de 1 voltio es suficiente en muchos casos para interpretarlo como nivel alto. De todas formas, mejor haber cambiado ese 157. A la larga está claro que hubiera acabado en corto.

Un saludo.

[Pofo]

Si, pero cuando empiezan a subir menos no se porque tambien tienen mas retardo en hacerlo y a veces esto se confunde con ruido, esto lo he notado comparando con tu comparador que se iluminan un poquitin mas.

Edcross, yo en situaciones como la tuya tiro de comparador por la zona, en media hora tienes todos los ttl mirados menos los tri, y en tres cuartos todos mirados y cambiados. Despues te vas a tri, buffers y rams y quedas mas feliz que un ocho y medio.

[ArcadeHacker]

Me vas a hacer comprar un comparador  

Si, pero cuando empiezan a subir menos no se porque tambien tienen mas retardo en hacerlo y a veces esto se confunde con ruido, esto lo he notado comparando con tu comparador que se iluminan un poquitin mas.

Edcross, yo en situaciones como la tuya tiro de comparador por la zona, en media hora tienes todos los ttl mirados menos los tri, y en tres cuartos todos mirados y cambiados. Despues te vas a tri, buffers y rams y quedas mas feliz que un ocho y medio.

[ArcadeHacker]

Buenas a todos,

Me temo que estoy en el dique seco, no logro dar con el fallo. En este nuevo intento he metido un socket en el z80 esclavo para descartar que fuese problema de esa cpu o que tuviese problemas de acceso a su rom y/o memoria compartida con la cpu principal. De nada a servido, todo está correcto.

Abajo os dejo un video del problema, vereis que en algún momento sale "work ram error", pasa 1 de cada 100 resets pero tengo comprobadisimo desde el z80 primario y ahora el secundario, que no hay problemas de memoria de ningún tipo (trabajo, video, y la compartida con el custom). La placa de video de abajo es 100% buena ya que pertenece a mi otro Bubble Bobble.

Por lo general solo ocurre cuando el juego entra en algunas de las habitaciones, tanto en la demo como en una partida legitima. Si os fijais tambien vereis que hay corrupción en la composición de las habitaciones.

Alguna idea o recomendación? Según lo recomendado por Pofo tengo pendiente hacerme con un comparador para ir a destajo con todos los IC.

El video (el blanco y negro es por el cable de mi monitor):

[Marcos75]

Yo creo que el "work ram error" es una buena pista. Muchas veces una placa da un error de RAM, pero en realidad son otros elementos que intervienen los que fallan, como un buffer de intercambio de esa RAM.

Echa un vistazo a este log de reparación: http://marcos75-arcade.jimdo.com/log-de-reparaci%C3%B3n/bubble-bobble/

En un momento de tu video he visto una pantalla como la que mostraba yo en su día en esa foto. En definitiva, yo me cogería 4 EPROMs idénticas y que sepas que son buenas, buenas, grabaría código fresco, y las probaría en la placa. A ver si suena la flauta.

Un saludo.

[ArcadeHacker]

Buenas Marcos, tengo las roms comprobadas externa e internamente, lo mismo con la ram, en este caso reparada y probada internamente desde la posicion de la cpu principal y de la esclava, por si las moscas he probado dos rams....

Igualmente probare a cambiar las roms por las de la otra placa a ver.

Yo creo que el "work ram error" es una buena pista. Muchas veces una placa da un error de RAM, pero en realidad son otros elementos que intervienen los que fallan, como un buffer de intercambio de esa RAM.

Echa un vistazo a este log de reparación: http://marcos75-arcade.jimdo.com/log-de-reparaci%C3%B3n/bubble-bobble/

En un momento de tu video he visto una pantalla como la que mostraba yo en su día en esa foto. En definitiva, yo me cogería 4 EPROMs idénticas y que sepas que son buenas, buenas, grabaría código fresco, y las probaría en la placa. A ver si suena la flauta.

Un saludo.

[Marcos75]

Sí, pruébalo, no pierdes nada. Una cosa es probar la EPROM en el lector, "sin estrés", y otra cosa es puesta en la placa. Si el error fuese continuo, entonces en el lector también cantaría, pero ante un error esporádico, como el que estás sufriendo, ya no estaría tan seguro.

Aún así, por lo que cuentas, no tengo mucha fe en que sean las EPROM, pero la prueba de la que hablamos es sencilla de hacer, y por lo menos descartas.

Un saludo.

[ArcadeHacker]

Nada... lo he cambiado todo, las cuatro roms, los tres pals, y el custom, sigue igual.

Mientras hacia esto se me ha pasado una cosa por la cabeza, pudiera ser que la memoria que yo he puesto para reemplazar la mala no sea compatible?

Es decir, en los test unitarios con el fluke ir bien, pero no ir bien una vez en vivo con ambas cpus utilizando el sistema como es debido?

He sacado una foto a la memoria que lleva la Bubble original que funciona y otra a la que he reparado:



Que opinais?

[Marcos75]

No lo puedo asegurar 100%, pero yo diría que esas memorias deberían poder ser intercambiables. ¿La otra u otras con las que has probado, son el mismo modelo?

[ArcadeHacker]

Si, tengo 4 iguales, mismo modelo/marca.

No lo puedo asegurar 100%, pero yo diría que esas memorias deberían poder ser intercambiables. ¿La otra u otras con las que has probado, son el mismo modelo?

[Marcos75]

Pues quizá sería otra prueba interesante, probar con otro modelo de 6264. No sé si puedes tomar prestada alguna de otra placa para hacer la prueba.

[ArcadeHacker]

Resumo para recapitular lo que me he encontado mal en esta placa y ha sido reparado:

IC54  74LS245, bus de datos de cpu principal (frito)
IC42  74LS157, direccionamiento cpu principal y esclava (A2 y A3 en corto)
IC44  SRAM 6264, memoria de trabajo compartida por cpu principal y cpu esclava (D7 en corto)

[Pofo]

Tipicos integrados petados de un churrascazo.

[ArcadeHacker]

Yo creo que el "work ram error" es una buena pista. Muchas veces una placa da un error de RAM, pero en realidad son otros elementos que intervienen los que fallan, como un buffer de intercambio de esa RAM.

He revisado la rom principal con el debugger y he encontrado la secuencia inicial que comprueba las memorias y alguna cosa más, de estar algo mal en ese momento el mensaje saldría inmediatamente sin ni siquiera arrancar el juego.

El hecho de que de vez en cuando salga ese mensaje al colgarse me parece normal si el juego pierde el norte y la cpu esclava sigue haciendo de las suyas mientras la cpu principal pasa por las rutinas de inicio.

La rutina de comprobación de memoria escribe y lee en todos los bytes tres veces (FF AA 55), si algo de lo escrito no consigue leerlo saca el error.



A seguir buscando...

[Pofo]

Puede no ser la ram edcross p. Puede ser la ejecucion la que este mal , cualquier punto de la logoca que lleve al programa a ese punto, un buffer, etc.

El camino de la ultracomprension de los procesos que estas tomando, editando y etc es un algo diametralmente opuesto a lo que yo hago. Yo saneo lo principal cpu.buff.ram.eprom de prg.video. A base de sonda.osc y comp. Despues yo sigo.

Sinceramente no veo la necesidas de buscar la rutina de comprobacion aunque sea para trazar el programa y ver que nos lleva ahi.

Mi tecnica es totalmente medieval. Amputation ma. pero en 2 horas tienes lo basico mirado.

si vas por el camino de trazar el programa y tengo un amigo que lo hace a lo mejor no compraste el mejor fluke. hay uno con serie que te lo maneja a tiempo real

[ArcadeHacker]

Victoria!!!!!!

Efectivamente había un problema de accesos a memoria cuando las dos cpu's corrian juntas, aquí el culpable:



Control de la linea de Wait a la cpu esclava desde el PAL 43 cortada. Este PAL se encarga entre otras cosas de que las cpu's no choquen entre si al acceder a memoria. Esto nunca lo vi antes pq la señal de Wait está en alto por defecto incluso con esa pista cortada...

Os agradezco a todos mucho la ayuda y el haber seguido el hilo, no solo me lo he pasado genial pero tb he aprendido bastante.  Partidas gratis a los que paseis por Barcelona


Resumen de la reparación:

IC54  74LS245, bus de datos de cpu principal (frito)
IC42  74LS157, direccionamiento cpu principal y esclava (A2 y A3 en corto)
IC41  74LS157, direccionamiento cpu principal y esclava (A7 con poca resistencia, cambiado por si acaso)
IC44  SRAM 6264, memoria de trabajo compartida por cpu principal y cpu esclava (D7 en corto)
Pista cortada en linea Wait de CPU esclava (pin 24) contra Pal 43 (pin 16).

[Pofo]

ainssssss si es queeeeee.

me alegro. una buena inspeccion ocular es muy importante.

de que viene tu experiencia con el z80? algun desarrollo?

[ArcadeHacker]

Fui criado por un Amstrad 6128 

ainssssss si es queeeeee.

me alegro. una buena inspeccion ocular es muy importante.

de que viene tu experiencia con el z80? algun desarrollo?

[Marcos75]

Enhorabuena por la reparación.

Un saludo.

[Rockman]

Ole ese edcross que está hecho un crack!! Je, al final era una pista rota, me caguen la.... ;-)

Por cierto, y disculpa mi ignorancia, ese desensamblado con que soft lo has hecho? Es el debugger de mame? Los comentarios los has puesto tú o es tan listo que te los pone el directamente? Me gusta.

Saludos!

[ArcadeHacker]

Es el IDA Pro, con mis comentarios.

Ole ese edcross que está hecho un crack!! Je, al final era una pista rota, me caguen la.... ;-)

Por cierto, y disculpa mi ignorancia, ese desensamblado con que soft lo has hecho? Es el debugger de mame? Los comentarios los has puesto tú o es tan listo que te los pone el directamente? Me gusta.

Saludos!

[Rockman]

Es el IDA Pro, con mis comentarios.

Muchas gracias. Ya le echare un vistazo cuando tenga el tiempo (y el valor). ;-)

[ArcadeHacker]

Hazlo sin duda. Ida es EL desensamblador.

Es el IDA Pro, con mis comentarios.

Muchas gracias. Ya le echare un vistazo cuando tenga el tiempo (y el valor). ;-)

[Pofo]

Recomiendas algun texto de ensamblador z80?

Me parece interesante un cacharro como el tuyo con conexion a pc para trazar el programa y pararlo en el fallo.

Me ha parecido una reparacion muy interesante no ya por lo que era sino pprque tu enfoque mira al soft...algo que nunca he echo yo.

[enricnes]

Pofo, hasta donde yo se, el fluke 9010A utiliza el puerto serie para cargar scripts al cacharro desde el ordenador. Suelen ser rutinas de escaneo de rams y roms, creo que no tiene la funcionalidad que tu quieres. Quizas su hermano mayor, el 9100, si lo haga.

[ArcadeHacker]

Sin ninguna duda recomiendo este: "Spectrum Machine Language for the Absolute Beginner"

http://www.worldofspectrum.org/infoseekid.cgi?id=2000363

Es un libro escrito con mucha inteligencia y muy fácil de seguir. En la página hay un link para su descarga en pdf.

Recomiendas algun texto de ensamblador z80?

Me parece interesante un cacharro como el tuyo con conexion a pc para trazar el programa y pararlo en el fallo.

Me ha parecido una reparacion muy interesante no ya por lo que era sino pprque tu enfoque mira al soft...algo que nunca he echo yo.