Autor Tema: Reparación Bubble Bobble [SOLUCIONADO]  (Leído 11044 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Pofo

  • Visitante
Re:Reparación Bubble Bobble
« Respuesta #15 en: 08 de Abril de 2014, a las 13:20 horas »
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

  • Visitante
Re:Reparación Bubble Bobble
« Respuesta #16 en: 08 de Abril de 2014, a las 13:49 horas »
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.  ;D



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

  • Con experiencia
  • ***
  • Mensajes: 1281
Re:Reparación Bubble Bobble
« Respuesta #17 en: 08 de Abril de 2014, a las 14:43 horas »
edcross, mi consejo es que sigas el consejo de los expertos y mires la Ram principal primero.

RESUMEN: Proyecto de incluir versiones españolas de juegos a Mame (Oficial): http://www.aumap.org/foro/index.php?topic=1270.0

Marcos75

  • Socio
  • ****
  • Mensajes: 3046
  • Arcadero de los 80s
Re:Reparación Bubble Bobble
« Respuesta #18 en: 08 de Abril de 2014, a las 15:30 horas »
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.
« última modificación: 08 de Abril de 2014, a las 15:35 horas por Marcos75 »


Pofo

  • Visitante
Re:Reparación Bubble Bobble
« Respuesta #19 en: 08 de Abril de 2014, a las 15:37 horas »
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

  • Con experiencia
  • ***
  • Mensajes: 643
  • .
Re:Reparación Bubble Bobble
« Respuesta #20 en: 14 de Abril de 2014, a las 16:17 horas »
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.




Busco placa de Taito: Chack'n Pop.

enricnes

  • Administrator
  • *****
  • Mensajes: 370
Re:Reparación Bubble Bobble
« Respuesta #21 en: 14 de Abril de 2014, a las 16:22 horas »
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

  • Con experiencia
  • ***
  • Mensajes: 643
  • .
Re:Reparación Bubble Bobble
« Respuesta #22 en: 14 de Abril de 2014, a las 16:36 horas »
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!
Busco placa de Taito: Chack'n Pop.

enricnes

  • Administrator
  • *****
  • Mensajes: 370
Re:Reparación Bubble Bobble
« Respuesta #23 en: 14 de Abril de 2014, a las 16:59 horas »
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

  • Con experiencia
  • ***
  • Mensajes: 643
  • .
Re:Reparación Bubble Bobble
« Respuesta #24 en: 14 de Abril de 2014, a las 17:10 horas »
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!
Busco placa de Taito: Chack'n Pop.

Marcos75

  • Socio
  • ****
  • Mensajes: 3046
  • Arcadero de los 80s
Re:Reparación Bubble Bobble
« Respuesta #25 en: 14 de Abril de 2014, a las 22:01 horas »
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 :)
« última modificación: 14 de Abril de 2014, a las 22:04 horas por Marcos75 »


Characa

  • Con experiencia
  • ***
  • Mensajes: 906
Re:Reparación Bubble Bobble
« Respuesta #26 en: 14 de Abril de 2014, a las 22:19 horas »
Marchando un poco de teoría del funcionamiento del Z80 ;)

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

Pofo

  • Visitante
Re:Reparación Bubble Bobble
« Respuesta #27 en: 14 de Abril de 2014, a las 22:48 horas »
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.
« última modificación: 14 de Abril de 2014, a las 22:51 horas por Pofo »

Rockman

  • Con experiencia
  • ***
  • Mensajes: 1281
Re:Reparación Bubble Bobble
« Respuesta #28 en: 15 de Abril de 2014, a las 00:03 horas »
@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.
RESUMEN: Proyecto de incluir versiones españolas de juegos a Mame (Oficial): http://www.aumap.org/foro/index.php?topic=1270.0

ArcadeHacker

  • Con experiencia
  • ***
  • Mensajes: 643
  • .
Re:Reparación Bubble Bobble
« Respuesta #29 en: 15 de Abril de 2014, a las 01:13 horas »
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
Busco placa de Taito: Chack'n Pop.