[Reparación] TMNT PCB Arcade Varias fallas

Foro para archivar logs de reparación de PCBs o hardware arcade en general.
Responder
Avatar de Usuario
lugerius
Mensajes: 33
Registrado: Vie Nov 11, 2016 2:44 pm
Cuenta de Twitter: lugerius

[Reparación] TMNT PCB Arcade Varias fallas

Mensaje por lugerius » Vie Jul 20, 2018 4:33 pm

REPARACIÓN TMNT ARCADE PCB
  • Características de la PCB
Título: Teenage Mutant Ninja Turtles ™ ®
Versión: Asia 4 Players
Sistema: GX963 PWB351853A
Fabricante: Konami Inc © 1989®

TMNT_PCB.png
  • Condiciones iniciales
No arranca (pantalla blanca)
Tiene desprendido un Circuito Integrado etiquetado como Konami 051550. (Lo recibí por separado)
A simple vista se aprecia la falta un capacitor en la zona donde está el amplificador de audio.
  • Obtener la documentación que puede ayudarnos a lo largo del proceso de diagnóstico y reparación.
Información general del juego
Manual y esquemático
Información relacionada al custom 051550
Reproducción de un 051550
Hojas de datos de distintas TTLs
Código fuente del driver del juego en MAME
  • Limpieza y análisis inicial
Se realiza una limpieza a la placa y se hace una búsqueda de piezas faltantes, del resultado vemos que solamente faltan el custom 051550 y el capacitor.
Se comprueba que no exista un corto circuito (continuidad) entre los pines de energía que puedan ocasionar un daño a nuestra fuente de poder
  • Reinstalación del circuito 051550
051550-PCB.png
051550_sin_pines.png
Antes de conectar la tarjeta por primera vez, iniciamos con la reinstalación del konami custom 051550, un circuito encapsulado de 23 pines que se encarga del conteo de créditos, del encendido y de la función reset en los chips de gráficos y de la sección de sonido.
051550.png
051550.png (53.21 KiB) Visto 536 veces
051550_Pines_reparando.png
La reparación se logra soldando nuevas patas, en este caso se usaron terminales dupont macho.
051550_Pines_reparado.png
Verificar la correcta orientación de los pines antes de soldarlo, el pin 1 se identifica por un recuadro en la PCB y por un punto blanco en el custom.
  • Reparación de pistas y pines doblados
Resultado de la inspección visual, entre otras cosas, se pueden ver en la parte trasera de la placa (también conocida como solder side) múltiples patas dobladas y en algunos casos haciendo contacto unas con otras, se corrigieron todas para evitar problemas y posibles daños a la PCB
Patas_dobladas.png
Además de que noté algunos rasguños sobre la superficie de la tarjeta, en la parte trasera, algunos superficiales sin aparente daño sobre las pistas, otros por el contrario si parecían ser lo bastante profundos.
Pistas_abiertas.png
Dichas pistas fueron verificadas para continuidad con multímetro y efectivamente se confirmó falla, por lo que de inmediato fueron reparadas. Dicho proceso se hizo simplemente reforzando con soldadura la conexión entre las pistas y en el caso más extremo se colocó un hilo de cobre (pueden obtenerlo de la malla de desoldar) sobre la pista para recuperar la continuidad de la línea.
Reparacion_pistas_abiertas.png
Una forma de hacerlo es limando ambos extremos de la pista con una aguja o alfiler, aislando la zona afectada, removiendo la capa de barniz o resina que protege las pistas. Una vez que se tiene la parte de cobre despejada se usa alcohol isopropílico para eliminar cualquier impureza que pudiera dificultar la adherencia de la soldadura o estaño. Posteriormente se estañan las pistas, así como también se estaña el hilo de cobre. Después simplemente se coloca con precisión el hilo de cobre sobre la pista y se toca con el cautín para que ambas soldaduras se fundan y se adhieran perfectamente.
  • Prueba inicial
Primer_arranque.png
Después de las reparaciones el juego presenta una falla de inicio, ya que se muestra una pantalla negra con líneas verticales con la leyenda RAM ROM CHECK durante un par de segundos seguido de una pantalla blanca reiniciando el sistema nuevamente. Debo mencionar que la letra R no aparece correctamente por lo que supone un problema adicional que debe ser atendido.
  • Reparación de falla - Líneas verticales
Al estar energizada la PCB, comencé a presionar sobre los circuitos integrados, con tal de verificar que no hubiera fallas debido a falso contacto. Ya que en algunas ocasiones, sobre todo en componentes de montaje superficial, se tienen fallas que son casi imperceptibles a la vista y al ejercer presión se hace más evidente la falla, ya sea para mejorar la imagen o para empeorar. Esta -técnica- también sirve en ocasiones para detectar, al tacto, si la temperatura de los chips es normal o hay sobrecalentamiento.

Con este método logré que las líneas verticales desaparecieron momentáneamente, mientras mantuve presión sobre un circuito integrado konami custom 051962 de montaje superficial. El cual se encarga de algunas tareas en la sección de video. Para más información http://www.system16.com/konami_customchips.php#052109

Al desconectar la pcb y revisar el circuito, noté que al menos 4 patitas de un lado y 3 de otro estaban sin hacer contacto. Por lo cual me dispuse a reparar esta falla limpiando perfectamente la zona y añadiendo soldadura a los conectores afectados.
Pines_desoldados_Custom.png
Una vez más al probar el funcionamiento de la PCB. Los resultados nos muestran por un par de segundos, la pantalla RAM ROM CHECK seguido de la pantalla blanca y después se reinicia, pero ahora ya no aparecieron la líneas verticales durante la prueba.
  • Deshabilitando el watchdog
- El Watchdog es un mecanismo que resetea la PCB cuando se detecta falta de actividad en el BUS, o algún otra condición no esperada. Desactivarlo generalmente se logra soldando un Jumper, típicamente el Jumper 1. *
Siguiendo las indicaciones y verificando en el diagrama esquemático, me dispongo a detener el reseteo constante al poner en corto el jumper 1 ubicado entre los pines 4 y 5 del CUSTOM 051550.
  • Análisis y diagnóstico con la ayuda del diagrama esquemático
Lamentablemente el sistema no logra avanzar hasta la pantalla de diagnóstico que nos indique por completo el estado de las memorias RAM y ROM. Por lo tanto, el siguiente paso es revisar el diagrama esquemático de la PCB.

Analizamos primero el CPU MC68000 buscando actividad, especialmente en las direcciones o -Address-
68000.png
68000.png (83.07 KiB) Visto 536 veces
De las mediciones obtenemos que el CPU si presenta actividad en la mayoría de sus conectores, incluyendo la señal de reloj en el pin 15 la cual nos indica una frecuencia de 8MHz.

Al finalizar las mediciones, temporalmente habilité el watchdog con el fin de verificar si había algún cambio durante el proceso de arranque y por un momento si lo hubo, se mostraba una pantalla con múltiples colores antes de llegar al RAM ROM CHECK. Después dejó de hacerlo y la pantalla RAM ROM CHECK cambio de color negro a morado
  • Diagrama de componentes
Adicionalmente al esquemático que se encuentra en el manual, tomé una fotografía de la placa y la modifiqué para etiquetar los circuitos integrados, eprom, ram y custom chips que la conforman. Esto para que sea más fácil el diagnóstico de su funcionamiento con la ayuda de su hoja de especificaciones
PCB_componentes.png
  • Verificando señales de reloj
Me encontré que un par de Konami Custom 007644, ubicaciones L12 y J12, son alimentados con una señal de reloj en su pin 12, ambos provenientes de la misma fuente, el pin 8 PE de un Konami Custom 051960. Pero uno de ellos, el L12 no presentaba actividad en el pin 12, pese a que en el circuito ubicado en J12 si había una señal de 3MHz. Por lo que suponía una falla en alguna pista de conexión. La cual se confirmó tras una revisión más a detalle en la parte trasera de la tarjeta y que se puede observar en la imagen siguiente.
Falla_reloj_custom051960.png
Debido al acercamiento hecho, se pudo notar también otra falla en pista de conexión de la memoria RAM D4364CX-12 ubicada en L13.
Pista_abierta_RAM_D4364CX.png
Ambas líneas de conexión fueron reparadas y el resultado eliminó el problema con la letra R de la pantalla RAM ROM CHECK.
Letras_correctas.png
  • Identificando las memorias EPROM
Al retirar las ROMS notamos que se encuentran muy sucias tanto las EPROM como los socket que las alojan. De tal manera que se realiza una limpieza más a conciencia sobre estos componentes.
dump_roms.png
dump_roms.png (171.87 KiB) Visto 536 veces
limpieza_slots.png
limpieza_slots.png (363.51 KiB) Visto 536 veces
Una vez finalizada la limpieza se procede a -dumpear- las EPROM, proceso que viene explicado en el video siguiente del canal de Artemio.



El resultado de romident fue
romident.png
romident.png (138.35 KiB) Visto 536 veces
Debo mencionar que por la suciedad de las EPROM, en más de una ocasión, el programador de EPROM no las detectó correctamente. Por tal motivo, les sugiero que se tomen su tiempo para limpiar perfectamente todos los conectores de cada memoria de solo lectura. Esto les puede ahorrar el reemplazo de alguna EPROM.

Al reinsertar en su socket cada ROM y energizar la PCB notamos que hubo un cambio en la pantalla de error. Por un breve instante se pudo ver la siguiente imagen.
Boot_artefactos.png
Boot_artefactos.png (360.52 KiB) Visto 536 veces
Pero después de reiniciar el sistema la imagen quedó como sigue. Donde ahora ya podemos ver completamente el resultado del autodiagnóstico RAM ROM CHECK.
ram_rom_check_bad.png
ram_rom_check_bad.png (143.57 KiB) Visto 536 veces
Cabe mencionar que ésta imagen con el detalle completo RAM ROM CHECK no me aparece automáticamente cada que enciendo o reinicio la PCB, sólo lo hace al presionar firmemente sobre la EPROM J15. Debido a esto, supongo que el socket, a pesar de la limpieza, se encuentra en mal estado y debe ser reemplazado. Y para descartar falla por el mismo motivo en las demás EPROM, decido cambiar los sockets de K15, I17, y K17 también. Para hacerlo corté el plástico de los sockets, para facilitar la remoción, pues no vale la pena tratar de salvarlos arriesgando dañar la tarjeta al momento de desoldarlos.
cambio_sockets.png
De la información en pantalla obtengo que las memorias RAM ubicadas en G8, F22, F23, G27 y G28 se encuentran en estado OK y las ROM K17, I17, K15 y J15 aparecen como BAD.

Aquí hay un dato confuso en la RAM ROM CHECK, pues se indica en dos ocasiones el estado de J15 y K15. Una vez en la parte superior del autodiagnóstico, junto con las RAM y la segunda ocasión en la parte inferior junto con la prueba a ROMs. Pero sabiendo que los circuitos ubicados en J15 y K15 son EPROMs y que J13 y L13 son RAM 8Kx8bits NEC D4364CX-12L, supongo que el diagnóstico se refiere a estas últimas en la parte de pruebas a la RAM.

Guiándonos por el resultado del test del propio juego y sabiendo que las ROMS están correctas, la falla puede estar en algún otro circuito o pista conectada directamente con las EPROM mencionadas.

Para continuar con el diagnóstico para J15 y K15 (M27512) y para I17 y K17 (AM27C010) apoyándonos en el sus diagramas de conexión.
am27c010.png
am27c010.png (64.3 KiB) Visto 536 veces
m27512.png
m27512.png (90.11 KiB) Visto 536 veces
De nuestra revisión obtenemos que las EPROM AM27C010 ubicadas en K17 y I17, tienen una señal alternante de valores (1’s y 0’s) en pin 24 correspondiente a OE, el cual se habilita en -LOW-. Una señal Chip Select - CS en -LOW- Por lo que presenta actividad adecuada.

En cambio las EPROM en ubicaciones K15 y J15 presentan -Chip Select- en bajo y OE -output enable- pin 22 en señal alta o -HIGH-, siendo que en la hoja de datos de la M27512, nos indica que el OE=GVpp se habilita en bajo o -LOW-. Lo cual significa que no están siendo habilitadas las salidas.

Debido a esto no queda más que revisar la línea de conexión que cada uno de los OE de las EPROM y encontramos que para K15 y J15, la señal OE proviene de la salida Y2 - pin 13 del circuito ubicado en H25 - 74LS138 y para I17 y K17 de pin 3 H19 - 74LS08 el cual se alimenta también del propio H25. Este circuito integrado forma parte esencial de lo que se conoce como -address decoding circuitry- o circuitería de decodificación de direcciones.
dm74ls138.png
dm74ls138.png (101.12 KiB) Visto 536 veces
Nuestras mediciones indican lo siguiente:
Lecturas_74ls138.png
Lecturas_74ls138.png (3.02 KiB) Visto 536 veces
Del análisis al H25 - 74LS138 todo parece indicar que funciona bien considerando los valores entrada provenientes del CPU - MC68000. Sin embargo, me extraña ver que únicamente recibe señales bajas en A,B y C, por lo que sólo recibo señal alternante de 1’s y 0’s en la salida Y0. En las demás salidas, de Y1 a Y7 recibo señal fija en alta. Lo que supone al menos, falla en la señal de entrada Output Enable en las EPROM J15 y K15 , así que decido reemplazar el 74LS138 y lamentablemente al hacerlo no hubo cambios en nuestra pantalla se error.

Ahora nuestra atención se centra en las entradas A,B y C del H25 - 74LS138 y su procedencia, ya que de ellos depende como se activan las salidas del propio integrado, tal y como se puede deducir de la tabla lógica del circuito. Midiendo pin 45,46 y 47 del CPU 68000* correspondientes a 1,2 y 3 de H25 - 74LS138 obtenemos la misma señal que se interpreta como -0- lógico. Aunque a decir por la imagen pareciera que trata de generar una señal alternante pero no tiene la suficiente potencia para que sea interpretada como 0’s y 1’s.
osciloscopio_74ls138.png
osciloscopio_74ls138.png (43.72 KiB) Visto 536 veces
La salida Y0 alimenta a H19 - 74LS08 una compuerta AND, junto con Y1 para obtener la señal de salida que se ingresa a OE de las ROM I17 y K17.


Para las mediciones que hicimos, Y1 (pin 1) permanece en estado Alto o High = 1, Y0 (pin 2) muestra alternancia en su valor, debido a un tren de pulsos 0 - 1. Por lo que nuestra salida AND (pin 3) del H19 - 74LS08 es cambiante al igual que Y0. Esta salida se convierte en Output Enable de K17 e I17. Por tal motivo al realizar mediciones en pin 24 de las ROMs indicadas, obtenemos alternancia de valores en nuestra señal confirmando que están siendo habilitadas.
osciloscopio_oe_k17_l17.png
osciloscopio_oe_k17_l17.png (47.07 KiB) Visto 536 veces
H10 - 74LS04 pines 3 y 4 inversor
osciloscopio_oe_k17_l17b.png
osciloscopio_oe_k17_l17b.png (37.59 KiB) Visto 536 veces
La misma señal de salida ingresa a I12 - 74LS00 (NAND)
diagrama_74ls00.png
diagrama_74ls00.png (14.18 KiB) Visto 536 veces
Entrada A Pin1 - Entrada B Pin2
osciloscopio_nand.png
osciloscopio_nand.png (28.28 KiB) Visto 536 veces
  • Reparando la pantalla de color morado
Antes de continuar, con el análisis y diagnóstico sobre las ROMS, y cansado de ver la pantalla de error en color morado, revisamos en nuestro diagrama esquemático los circuitos más cercanos a la salida de colores Red, Green, Blue de nuestro conector JAMMA, con el fin de ubicar si alguno de ellos tiene falla que resulte ser causante de que la pantalla se vea de color morado o magenta.

Para facilitar un poco nuestra búsqueda, encontramos la siguiente imagen que nos indica la combinación de colores RGB (Rojo, Verde, Azul). Donde podemos ver que la combinación de rojo, azul y ausencia del color verde nos da como resultado un color morado o magenta, tal y como el que obtenemos en nuestra pantalla. La cual debe mostrar color negro. Para mostrar negro todos los colores deben estar apagados. Por lo que se infiere que los colores rojo y azul están activos constantemente, por lo que se deben revisar los circuitos que los controlan o generan.
Corregir_negro.png
Como se puede ver en la imagen se trata, en su mayoría, de 74LS07 - HEX BUFFERS/DRIVERS.
diagrama_74ls07.png
diagrama_74ls07.png (27.33 KiB) Visto 536 veces
En estos integrados se tienen 6 búferes , es decir 6 entradas -A- con sus respectivas salidas -Y-, tal y como se observa en el diagrama interno del integrado.
buffer.png
buffer.png (12.7 KiB) Visto 536 veces
Después de revisar algunos circuitos de nuestras salidas RGB se obtiene que:
pines 1 y 2 del 74LS07 ubicado en D23……………..1-High y 2-Low…....BAD
pines 1 y 2 del 74LS07 ubicado en D22…………….1-Low y 2-High…....BAD
pines 13 y 12 del 74LS07 ubicado en D20…………13-High y 12-Low.....BAD

Señales como la siguiente nos indican que el búfer no funciona bien, D22 pin 1 y 2.
osciloscopio_buffer_falla.png
osciloscopio_buffer_falla.png (24.63 KiB) Visto 536 veces
Azul - Señal de entrada y Rojo - Señal de salida

La siguiente imagen demuestra el funcionamiento de un Búffer operando correctamente.
osciloscopio_buffer_ok.png
osciloscopio_buffer_ok.png (28.68 KiB) Visto 536 veces
Para confirmar la falla en el circuito ubicado en D22, usamos la técnica -piggyback- ejemplificada en la imagen de la izquierda y el resultado al energizar la tarjeta es el que se observa en la imagen de la derecha.
Piggyback_ramrom_black_ok.png
Por fin dejamos de ver la pantalla de color morado y vuelve a su color negro original.
Con éste resultado procedo a reemplazar el circuito ubicado en D22 - 74LS07.
socket_74ls07.png
Siguiendo con las mediciones en circuitos integrados, encontramos que un 74LS07 (Buffer) ubicado en D23, arroja señales equivocadas en al menos 3 de sus entradas con sus respectivas salidas.
  • Retomando el análisis de RAM y ROM marcados como BAD
Ahora siguiendo con el análisis de las ROM marcadas como BAD y asumiendo que la falla se encuentra otro circuito conectado al mismo bus donde se conectan las ROMs, me dispongo a ubicar todos los circuitos que se conectan directamente y encuentro algunos posibles responsables en C24, D24, E24, F24. Todos son circuitos integrados 74LS245, los cuales son reemplazados. En parte por que se trata de integrados de la marca fujitsu, los cuales tienen la reputación de fallar eventualmente.

Lamentablemente no hubo cambios favorables.
  • Reemplazando el CPU MC68000
Considerando el comportamiento de H25 - 74LS138 (circuito que controla los OE de algunas ROM y RAM) su problema parece estar con las entradas A,B y C. Las cuales provienen directamente del MC68000, por tal motivo el siguiente paso es reemplazar el CPU, esperando que con éste cambio se solucione el problema.

La recomendación como siempre, es instalar un socket para cada circuito integrado que se reemplace. Y en este caso me brinda 2 importantes posibilidades.

Primero, facilitar la instalación de un nuevo CPU MC68000 cuando sea requerido.
Segundo, aprovechar el socket del CPU (64 pines) para hacer pruebas en la RAM y ROMs con el Ghetto Fluke 9010A. diseñado por Artemio Urbina.

Ahora, atendiendo nuestra primer opción, al conectar el nuevo CPU se observa mucha basura gráfica junto con la pantalla RAM ROM CHECK. Se verifican todas las líneas de conexión del CPU, así como de algunos circuitos recién reemplazados y se encuentra una falla en el circuito integrado 74LS245 ubicado en F24 pin#16. Falta de continuidad entre el integrado y el socket. Se soluciona el problema y regreso al punto donde veo la pantalla de autodiagnóstico RAM ROM CHECK. Conclusión: el cambio de CPU no soluciona el problema.
  • Diagnosticando con Ghetto Fluke 9010A
El Fluke 9010A entre muchas funciones, nos brinda la posibilidad de revisar el funcionamiento de las memorias RAM y ROM sin la necesidad de removerlas de la placa. Pueden encontrar el manual de uso de dicha herramienta en el siguiente enlace. Fluke 9010A Manual. Aunque el producto está descontinuado, el buen Artemio Urbina desarrolló una alternativa implementada con un Arduino Mega. toda la información pueden encontrarla en https://github.com/ArtemioUrbina/GhettoFluke9010A
Fluke9010A.png
Ghetto_fluke_9010A.png
El Ghetto Fluke se conecta directo en el slot donde va el CPU 68000 y nos va a permitir calcular el CRC de las ROMS, así como verificar que las RAMS funcionen correctamente

Para hacer uso del Ghetto Fluke 9010A, necesitamos conocer los Rangos de memoria ROM y RAM en PCB TMNT . Para ello nos apoyamos en el código fuente de MAME. específicamente en el driver tmnt.cpp

En ese archivo debemos buscar ROM START ( tmnta ) y ADDRESS_MAP_START. Aquí ubicamos la que corresponde al juego tmnt, ya que este mismo driver es utilizado por múltiples juegos de konami como TMNT2 y Sunset Riders por mencionar algunos. En nuestro caso se trata de -tmnta- como vimos anteriormente al hacer el romident

ROM_START ( tmnta )
https://github.com/mamedev/mame/blob/27 ... .cpp#L2967

Código: Seleccionar todo

ROM_START( tmnta )
    ROM_REGION( 0x60000, -maincpu-, 0 ) /* 2*128k and 2*64k for 68000 code */
    ROM_LOAD16_BYTE( -tmnt j17.bin-,      0x00000, 0x20000, CRC(00819687) SHA1(65624465b8af21000ca42b759c6fe123b4570e08) )
    ROM_LOAD16_BYTE( -tmnt k17.bin-,      0x00001, 0x20000, CRC(6930e085) SHA1(3c35c663346a81d06cd0169fbae08c19d1bde2eb) )
    ROM_LOAD16_BYTE( -tmnt j15.bin-,      0x40000, 0x10000, CRC(fd1e2e01) SHA1(63c3e8adcb5025a0a11f28e623cf2692f5f030a3) )
    ROM_LOAD16_BYTE( -tmnt k15.bin-,      0x40001, 0x10000, CRC(b01eea79) SHA1(3f0201ed471380fcafaf2e570454c3d742c0e03d) )

*hasta este momento solo nos interesa revisar los ROMs de programa y por eso no requerimos de los demás datos para ROMs de audio, tiles, etc..


ADDRESS_MAP_START( tmnt_main_map, AS_PROGRAM, 16, tmnt_state )
https://github.com/mamedev/mame/blob/27 ... t.cpp#L514

Código: Seleccionar todo

static ADDRESS_MAP_START( tmnt_main_map, AS_PROGRAM, 16, tmnt_state )
    AM_RANGE(0x000000, 0x05ffff) AM_ROM
    AM_RANGE(0x060000, 0x063fff) AM_RAM /* main RAM */
    AM_RANGE(0x080000, 0x080fff) AM_DEVREADWRITE8(-palette-, palette_device, read8, write8, 0x00ff) AM_SHARE(-palette-)
    AM_RANGE(0x0a0000, 0x0a0001) AM_READ_PORT(-COINS-) AM_WRITE(tmnt_0a0000_w)
    AM_RANGE(0x0a0002, 0x0a0003) AM_READ_PORT(-P1-)
    AM_RANGE(0x0a0004, 0x0a0005) AM_READ_PORT(-P2-)
    AM_RANGE(0x0a0006, 0x0a0007) AM_READ_PORT(-P3-)
    AM_RANGE(0x0a0008, 0x0a0009) AM_DEVWRITE8(-soundlatch-, generic_latch_8_device, write, 0x00ff)
    AM_RANGE(0x0a0010, 0x0a0011) AM_READ_PORT(-DSW1-) AM_DEVWRITE(-watchdog-, watchdog_timer_device, reset16_w)
    AM_RANGE(0x0a0012, 0x0a0013) AM_READ_PORT(-DSW2-)
    AM_RANGE(0x0a0014, 0x0a0015) AM_READ_PORT(-P4-)
    AM_RANGE(0x0a0018, 0x0a0019) AM_READ_PORT(-DSW3-)
    AM_RANGE(0x0c0000, 0x0c0001) AM_WRITE(tmnt_priority_w)
    AM_RANGE(0x100000, 0x107fff) AM_READWRITE(k052109_word_noA12_r, k052109_word_noA12_w)
//  AM_RANGE(0x10e800, 0x10e801) AM_WRITENOP ???
    AM_RANGE(0x140000, 0x140007) AM_DEVREADWRITE8(-k051960-, k051960_device, k051937_r, k051937_w, 0xffff)
    AM_RANGE(0x140400, 0x1407ff) AM_DEVREADWRITE8(-k051960-, k051960_device, k051960_r, k051960_w, 0xffff)
ADDRESS_MAP_END

Una vez que tenemos eso conectamos nuestra interfaz de 64 pines del Ghetto Fluke 9010A en el socket del MC68000 y hacemos la prueba de ROM, la cual nos debe indicar el CRC, pero en nuestro caso al hacer CHECK ROM - 0x000000 a 0x020000 correspondiente a J17 nos envía datos incorrectos que no corresponden con la información CRC documentada. Mismo caso para las demás EPROMs K17, K15,J15, incluso cotejando datos con tmnt de versiones y regiones diferentes. Esto a pesar de que ya hemos verificado los ROMs ejecutando el juego en MAME. Entonces el CRC erróneo puede ser debido a una falla en la circuitería que se encuentra entre el CPU y las ROMs.

Posteriormente hacemos una prueba en RAM de 0x060000 a 0x063FFF , automáticamente el programa comienza a escribir AA55 y 55AA en diferentes regiones de memoria RAM para posteriormente recuperarla haciendo la lectura del mismo dato en la misma dirección y obtenemos un mensaje de error. R:AA00 E:AA55 Haciendo más pruebas grabando datos de manera manual en distintas direcciones de memoria dentro del rango 0x060000 y 0x063fff encontramos que dos direcciones estaban fijas, escribíamos FFFF y al leer la misma dirección se leía FFEE.
Ghetto_test.png
Ghetto_test.png
Mediante esta herramienta se deduce que hay una falla en la memoria RAM. Ahora solo queda determinar cuál o cuáles memorias RAM son las que están fallando. En la prueba de autodiagnóstico del juego, RAM ROM CHECK se indican

RAM ----------->F22-OK, F23-OK
RAM ----------->G27-OK, G28-OK
RAM ----------->J15-OK, K15-BAD
RAM ----------->G8-OK

ROM ----------->I17-BAD, K17-BAD
ROM ----------->J15-BAD, K15-BAD

Como mencioné anteriormente en este documento, en el autodiagnóstico de la PCB hay un error al identificar las memorias RAM resaltadas en color rojo. pues J15 debería indicar su ubicación en J13, así como K15 se encuentra en L13. Ambas son RAM 8Kx8bits NEC D4364CX-12. Y se trata de la memoria principal del sistema.

Lamentablemente no tengo una memoria de reemplazo y debo averiguar si se puede conseguir el mismo modelo o debo elegir una compatible.

Tras una búsqueda rápida en línea de tiendas de electrónica en México, no tengo mucha suerte y desde China tendría que esperar algunas semanas para recibirla, Debido a esto comienzo a investigar sobre memorias compatibles con D4364CX-12 8Kx8bit y encontré éste sitio donde presentan varias opciones de memorias RAM compatibles.
http://www.citylan.it/wiki/index.php/SRAM_8k_x_8.

Mientras consigo la RAM, trataré de replicar la falla en MAME con el fin de confirmar si la falla en la memoria que tenemos puede ocasionar los mensajes de error mostrados en el autodiagnóstico de la propia PCB. De esta manera tendríamos un poco más de certeza, de que al reemplazar la RAM se solucionará nuestro problema.
  • Replicando la falla con MAME
La idea es, replicar la falla de nuestro hardware en el emulador modificando algunos parámetros del código del juego. Específicamente del driver tmnt.cpp Para compilar mame seguir la guía oficial

La idea es simular que tenemos la memoria RAM dañada o mejor dicho ausente en nuestra PCB. Y para ello:

En ADDRESS_MAP_START, debemos comentar (con // al inicio) la línea de código siguiente, ubicada en la sección dedicada al juego tmnt
AM_RANGE(0x060000, 0x063fff) AM_RAM /* main RAM */
tmnt_mame_src.png
Una vez comentada compilamos con

Código: Seleccionar todo

make SOURCES=src/mame/drivers/tmnt.cpp REGENIE=1 -j5
Obtenemos en pantalla que las RAM J15,K15, así como las ROM I15, K15, J17 y K17 son marcadas como BAD. Recordar que las RAM J15 y K15 son en realidad J13 y L13.
mame_vs_pcb_ram_rom_check_bad.png
Aquí se confirma que al remover la memoria RAM del sistema, hace que el autodiagnóstico de la PCB TMNT señale como BAD a las 4 ROMs. Esto me indica que una memoria RAM dañada también puede generar que las ROMs aparezcan como BAD y por tanto debo reemplazarla para confirmar si esto soluciona ese problema.
  • Reemplazando la memoria RAM
Mientras pasa la larga espera a que llegue la memoria desde China , solo pude conseguir una HY6264-LP10, la cual según su pinout es idéntica a la D4364CX-12, solo que en DIP 28. Es decir debo hacer un adaptador para poder instalar esa memoria en la PCB.
adaptador_memoria_ram.png
adaptador_memoria_ram.png (292.08 KiB) Visto 536 veces
Al instalar la nueva RAM en la PCB obtenemos una pantalla de error diferente a la anterior que teníamos. Pues ahora aparecen muchas letras -A- por sobre toda la pantalla y en la imagen se alcanza a percibir el autodiagnóstico RAM ROM CHECK indicando algunas de las ROMs en estado OK. Pero no se logra ver con claridad cuales son.
Ram_rom_check_New_ram.png
Al analizar con Ghetto Fluke 9010A realizamos nuevamente las pruebas de RAM el resultado es RAM OK.
Ghetto_test_ram_ok.png
Ghetto_test_ram_ok.png (249.36 KiB) Visto 536 veces
Sin embargo, al hacer la prueba de ROMS el resultado ahora es -No DTACK signal Ignoring-
Ghetto_ROM_NO_DTACK.png
Ghetto_ROM_NO_DTACK.png (268.96 KiB) Visto 536 veces
Con el equipo conectado comenzamos a hacer mediciones con el osciloscopio, con la meta de ubicar alguna falla en las señales A0 - A23 y Q0- Q15.Tras varios minutos se revisar nuevamente cada uno de los puntos de conexión mencionados, encontramos algunas falla se comunicación, continuidad, entre los EPROMs J15, K15 y CPU, RAMs y custom chips involucrados.

Se refiere a Q4 el cual no indica actividad , solo una línea de voltaje de 2.0V, lo cual es indicativo de una falla, pues las demás direcciones funcionaban correctamente. A pesar de haber reemplazado el socket de esta EPROM J15, el pin #16 mostraba falta de continuidad entre EPROM y socket.

Se repite la limpieza de socket y EPROM, pero esta vez confirmando continuidad en cualquier punto del circuito y la placa.

Continuando con esta revisión encontramos en el diagrama esquemático que hay un par de custom chips Konami 7644 ubicados en K12 y L12. Los cuales tienen conexión directa con CPU, RAMs y ROMs, por lo que se revisa también minuciosamente.

Encontramos una falta de continuidad en el pin #13 de L12 del resto de componentes involucrados. El pin #13 se refiere a -Q0- que conecta directamente con MC68000 pin#5 , K17 pin#13, K15 pin#11 y RAM en L13 pin#11 (la recién reemplazada).

Trato de seguir la pista desde L13 custom 7644, pin#13 hasta el CPU y lamentablemente no pude ubicar la pista dañada que ocasiona la falta de señal. Seguramente pasa por debajo de algunos chips. Debido a lo anterior se instala un -jumper wire- o -puente- entre CPU pin#13 y Custom 7644 ubicado en L13 pin#13.

Se colocan los componentes en su lugar, incluyendo el CPU y se comprueba el funcionamiento nuevamente.

Debo mencionar que, para esta prueba, el juego aún mantiene el jumper que deshabilita el watchdog y al energizar la placa se puede ver la imagen siguiente. Lo cual demuestra que hubo un cambio, pero hasta este momento no sabemos si es favorable o todo lo contrario.
Ram_rom_check_pista_reparada.png
Después de eliminar el jumper watchdog, reiniciamos el juego y para nuestra sorpresa, el juego por fin bootea, avanza por la pantalla RAM ROM CHECK indicando todo OK, y por fin el juego funciona. Lamentablemente el juego no emite el sonido, sólo se escucha ruido , por lo que debemos analizar y diagnosticar la sección de audio a detalle. Cabe mencionar que al apagar el juego por algunos minutos y volver a energizarlo, nos presenta la misma falla de la imagen anterior y sólo tras tenerla encendida por unos minutos, es que el juego deja de reiniciar y comienza el juego. Un nuevo problema que atenderemos a continuación.
TMNT_arranca_primera_vez_ok.png
  • Reparando el problema para iniciar inmediatamente
Cronológicamente, éste problema fue el último que logré solucionar, una falla difícil de diagnosticar porque se presentaba de manera aleatoria.
Ram_rom_check_pista_reparada_falla_watchdog.png
Repetí la técnica de presionar sobre circuitos integrados como CPU, memorias RAM y ROM, sin lograr identificar con precisión la falla. Pues en ocasiones al presionar un determinado circuito el juego iniciaba, pero en otras no tenía el mismo efecto, sino que otro circuito diferente hacía el -truco- de hacerla funcionar. Eventualmente dí con los 74LS245 ubicados en C24, D24, E24 y F24 que había reemplazado y noté que había cambios en la pantalla al presionarlos. Comencé a realizar mediciones con osciloscopio en cada una se sus patas intentando ubicar la falla. Y efectivamente en D24 pin#2, acorde al diagrama, se debía recibir la misma señal D0 que su correspondiente en C24 y esto no estaba sucediendo, ya que en D24 solo se veía una línea flotando entre 1 y 2 volts. Cuando en C24 la señal era una señal cuadrada perfectamente definida.

Al verificar continuidad pasó algo un poco extraño, ya que, si aplicaba la prueba tocando exclusivamente las patas de los circuitos, había falta de continuidad, pero si tocaba directamente sobre el socket D24, no había problemas. Esto me indica que la línea de conexión entre ambos sockets (C24 y D24) está bien y sin problemas, no así entre el socket ( headers torneados ) D24 con su circuito 74LS245.

Sin éxito, traté de solucionar el problema limpiando a conciencia el socket y patas del integrado, también supuse que el socket estaba un poco flojo y agregué un poco de estaño en los conectores del integrado para hacerlos más gruesos y así embonar con mayor firmeza pero tampoco funcionó. Finalmente solucionamos el problema agregando 3 muy finos hilos de cobre dentro del header para tener mejor superficie de contacto y listo. Esta reparación solamente corrigió el problema en la memoria RAM K15 (L13), ya que ahora aunque seguía indicando diversas fallas en RAM ROM CHECK, ya no aparece falla en K15.

Lamentablemente no era la única falla pues el juego aún no ingresaba inmediatamente, seguimos haciendo pruebas al tacto de los demás circuitos, hasta ubicar que al presionar F24, otro 74LS245 , el juego por fin podía iniciar, pero al soltarlo, se reiniciaba nuevamente, dando lugar a la pantalla con basura gráfica indicada anteriormente.

Una vez más y repitiendo la misma fórmula del caso anterior en D24, usando el osciloscopio se hicieron mediciones sin encontrar indicios claros de una señal con falla. Teniendo como referencia lo acontecido con D24 comencé a ajustar cada conector del socket F24 con una pequeña punta de cable dupont macho o aguja tratando de identificar cuál pin ocasiona el problema hasta llegar al pin#10 correspondiente a GND. La cual como habrán de imaginarse era muy difícil de diagnosticar falla, pues al medir con multimetro u osciloscopio en patas del integrado o en el socket la señal siempre debía ser 0 volts. Pero al hacer la misma reparación que en D24 el juego por fin inicia.

  • Analizando la falla de sonido
Ahora el audio...
Al hacer diagnósticos en la etapa de sonido, se inicia la revisión rastreando la señal de audio analógico, desde las salidas del amplificador, en este caso el MB3731 hacia atrás hasta donde se origina.

Medimos si hay señal en pin#1 haciendo tierra con pin#3 y no obtenemos señal de audio analógico. Por tal motivo debemos seguir buscando en una etapa anterior.
NEC C324C (LM324 - Amplificador operacional) Salida en pin#14 sin señal aún. Entrada en pin#1 sin señal.
Medimos en el DAC Yamaha YM-3012 salidas en CH1 pin#9 y CH2 pin#10 sin señal.
ym3012.png
ym3012.png (95.5 KiB) Visto 536 veces
YM2151(Generador FM) Muestra Chip Select en pin#7 estado -H- o inactivo. Mientras que SH1 y SH2 con una señal cambiante de H a L, o -1’s- a -0’s-, además de que emite la señal de reloj de 1.79Mhz que alimenta a CLK de YM3012.Pero sus D0 a D7 se muestran en estado H o un valor flotante de alta impedancia. Pero ninguna con actividad de -1,’s- y -0’s-.
ym2151.png
ym2151.png (88.97 KiB) Visto 536 veces
El -Chip Select- anterior proviene directamente de un demultiplexor 74LS138 -Y4 pin#11 el cual a su vez es alimentado por direcciones del Z80. Por su parte las demás señales que recibe el YM2151 provienen en su mayoría del Z80A y la mayoría aparecen como en alta impedancia, es decir no son ni -1- ni -0-. Algunos valores están flotando en rangos de 1 y 2 volts. Lo que supone un problema ya que no debería ser así. Cabe mencionar que las señales en D0 a D7 comparten conectividad con una EPROM 27256 ubicada en G13, con una RAM 2128SL ubicada en F16, con un (FlipFlop 3-state) 74LS374 ubicado en F21 y con el CPU Z80A (4MHz). Por lo que debemos revisar que ninguno de estos componentes esté afectando la señal que debe generar el Z80A.
  • Revisando y reemplazando el Z80A (4MHz)
Buscamos el diagrama esquemático del procesador , dedicado al audio, Z80A y de ahí partimos para ubicar nuestros puntos de interés en las mediciones. Como son alimentación, señales de reloj, direcciones de memoria, reset, etc.. Aquí se muestra los resultados que se obtuvieron al realizar mediciones.
diagrama_z80.png
Como habrán notado, para todas las mediciones use Volts, excepto en el caso del reloj que se utilizaron MHz como unidades de medida, en lugar de usar el -0- o -1- lógico, como se supone debería hacerse. Y esto fué para tener como referencia las variaciones que se encuentran al medir circuitos TTL y que en algunos casos deben considerarse 1 o 0 lógico, pero en muchos otros quedan entre esos valores -flotando- fuera de la zona de operación TTL.
TTL_Voltage_levels.png
TTL_Voltage_levels.png (116.26 KiB) Visto 536 veces
Analizando las mediciones, podemos deducir que el Z80A no funciona correctamente. Casi todas las As se encuentran en estado lógico -0- o en alta impedancia. Debido a esto decidimos reemplazar el CPU Z80A de 4MHz.

Una vez instalado el CPU Z80A de reemplazo sobre su respectivo y obligado socket probamos nuevamente la PCB y por fin emite sonido.
socket_z80.png
  • Reemplazando el potenciómetro
pot_5k_audio.png
pot_5k_audio.png (283.08 KiB) Visto 536 veces
Cabe mencionar que, aún cuando ya se escucha, lo hace de manera intermitente. El juego inicia sin la música y tema oficial de introducción y eventualmente se deja de escuchar para segundos después regresar. Lo que supone que todavía se tienen problemas en esta etapa. Principalmente el potenciómetro que controla los niveles de volúmen.(5KΩ) presenta un comportamiento inestable.

Esto se nota al bajar o subir volúmen, no lo hace con precisión y esporádicamente deja de escucharse o se escucha muy fuerte. Por tal motivo debe darse mantenimiento o ser reemplazado.

A pesar del cambio de control de volúmen, el juego se escucha saturado, por lo que seguramente hay otro componente en mal estado. Además el juego parece más inestable, ya que se reinicia constantemente. Esta falla puede ser causada por algún componente que se encuentra en corto circuito y demanda más corriente del sistema lo que hace que el sistema se reinicie.

De momento, en la etapa de sonido solo se han reemplazado el Z80, potenciómetro de 5KΩ y también un capacitor ubicado en C20 de 1000µF, el cual estaba parcialmente desprendido de uno de sus conectores o patas.

Ahora ya que tenemos algunos sonidos en el sistema, podemos repetir nuestra prueba de seguir la falla desde el amplificador MB3731 y hacia atrás determinando dónde es que se encuentra la falla que hace que el sistema se reinicie además de ubicar el origen de no tener audio en la -introducción del juego-, así como los sonidos faltantes y su intermitencia.
  • Diagnosticando el problema de sonidos faltantes (voces, golpes, percusiones)
Como se mencionó anteriormente el juego presenta la falla de reproducir música, sin voces en absoluto y sonidos por lapsos. Además de tener un problema de ruido y saturación casi en todo momento.

Para confirmar si la falla se saturación se debe al MB3731 podemos inyectar sonido desde una fuente externa, por ejemplo un generador de señales, ajustando 1kHz con una amplitud de 50mV ó desde un reproductor de música, Smartphone, tablet, ipod, etc.. ajustando el volumen hasta alcanzar los 50mV de amplitud medidos con osciloscopio. Esto lo hacen usando un conector miniplug con los cables de GND y señal expuestos los cuales se conectan directamente al MB3731 GND(pin#7) y señal de entrada (pin#1). Esto mientras el juego no se encuentre reproduciendo sonidos. Por ejemplo pueden ingresar al test menu. De esta manera en nuestro caso pudimos confirmar que nuestro amplificador de sonido MB3731 funciona correctamente.

Un dato curioso, es que en algunas zonas del juego, como al momento de estar en el menú de selección de personaje se escucha correctamente la música y no deja de hacerlo, es decir mientras permanezco en esa pantalla, puedo escuchar la música del juego sin interrupciones ni saturación.
diagrama_etapa_audio_analogico.png
diagrama_etapa_audio_analogico.png (99.5 KiB) Visto 536 veces
Al analizar el diagrama en la etapa de audio que alimenta al MB3731, podemos notar en pin#1 que la señal de entrada proviene de pin#14 de LM324 ubicado en B12. Y revisando la señal que ingresa a B12 en pin#13 en el diagrama, notamos que opera como sumador mezclando las señales -SNDSIG- de diversas etapas que conforman la salida de audio completa del juego. Es decir, música, voces, efectos de sonido, etc..
  • Revisando señales de audio con audífonos
Nuestro siguiente movimiento es utilizar unos audífonos conectados a la PCB, similar a cuando usamos una punta lógica, un polo conectado a GND y el otro lo usaremos para revisar señales de audio analógicas provenientes de los amplificadores operacionales y demás componentes de la etapa de audio analógico en la PCB.

En mi caso lo hice utilizando un conector hembra miniplug, al cual se le sueldan en sus polos conector caimán para GND y una punta o pinzas (de las que usan en proyectos arduino o analizador lógico), para el otro extremo.
Adaptador_audifono.png
Adaptador_audifono.png (179.02 KiB) Visto 536 veces
Advertencia: No conectar el audífono directamente a la salida del amplificador de audio, se va a quemar. Tampoco deben conectar su auricular a puntos sin señal analógica, ya que sólo escucharán ruido. Es decir cualquier punto de entrada en los DAC’s.

Con la ayuda del diagrama esquemático, comienzo mi análisis por la salida del potenciómetro de 5KΩ pin#3 que controla el volúmen y que a su vez se conecta a la entrada de audio del amplificador MB3731 pin#1. En este punto sigo escuchando la mezcla de sonido incompleta, con saturación y ruido.

Siguiendo el diagrama, me enfoco ahora en verificar el LM324 ubicado en B12. Su señal de salida en pin#14 alimenta al potenciómetro mencionado. La señal apenas es perceptible, pero se escucha continuamente sin interrupciones. Lo recomendable en este caso es reemplazar todos los capacitores de la etapa de sonido y si es necesario algunas resistencias para filtrar un poco el ruido en la señal. Algunos de ellos son los capacitores de tantalio de 4.7µF a 16V. Como el ubicado en C15 que presenta evidente deterioro.
capcaitores_audio.png
Una vez reemplazados el juego se escucha un poco más en la salida del MB3731, aunque aún le faltan sonidos y el problema de saturación sigue presente.

Ahora hago la misma prueba pero en la entrada pin#13 de B12 y se escucha parte de la mezcla final de sonido con música, algunos efectos de sonido saturados. Ahora solo resta ubicar dónde es que se pierde la señal que le llega hasta este nodo.
  • Analizando problemas con la música
Como mencioné anteriormente en el nodo B12 pin#13 se combinan varias señales -SNDSIG- , que conforman la mezcla final de audio en el juego. Y en éste caso analizaremos la etapa donde se genera la música.
diagrama_mezcla_audio.png
Lo primero que hacemos es averiguar si nuestra falla se genera en la parte analógica o en la digital de esta etapa. Y para ello debemos buscar el DAC (Convertidor Digital Anlógico) en este caso el Yamaha YM-3012 y medir la salidas directamente con nuestro audífono en pines #9 y #10. Si obtenemos señal de audio, entonces sabemos que la parte digital está trabajando correctamente, así como el DAC.

Si no obtenemos señal alguna, entonces medimos con osciloscopio en las entradas del YM-3012 para verificar si se están recibiendo correctamente. Con esto podemos identificar si la falla radica en el DAC ó se encuentra ántes de llegar al convertidor. En nuestro caso se escucha bien en la salidas del DAC por lo que sigue es revisar etapas posteriores.

Analizando el diagrama esquemático y hoja de datos del LM324, se puede ver que cada integrado incluye 4 amplificadores operacionales.
Diagrama_LM324.png
Diagrama_LM324.png (96.69 KiB) Visto 536 veces
La sección que genera la música hace uso de 4 distribuidos en 2 LM324,el ubicado B12 y en B15.

Analizando nuestra primer señal SNDSIG, la obtenemos de B12 pin#1, justo después del R2 colocamos nuestro audífono y escuchamos una señal clara y libre distorsiones de una parte la música del juego. Lo cual nos indica que ésta etapa funciona correctamente.

Ahora revisando la señal en B15 - LM324 pin#8 se escucha correctamente, pero siguiendo el diagrama de conexiones hasta SNDSIG en B6 - R1 560Ω. La señal percibida en este punto con los audífonos se escucha con ruido, por lo que reemplazamos C13 - 4.7µF a 16V y tambien R1 de 560Ω y R5 de 1KΩ. La señal se limpió un poco y ahora se escucha con más claridad, aunque sin llegar a ser perfecta.
osciloscopio_audio.png
Para el caso de B12 reemplazamos R2 y R10 de 1KΩ, R8 de 560Ω y C8 de 4.7µF, logrando también una mejoría notable en la señal de audio.
diagrama_audio_digital_analogico.png
Ahora seguimos con B12 pin#8 y escuchamos muy ligeramente el juego, pero con ruido, por lo que medimos en pin#9 del mismo amplificador y la señal sigue débil. Siguiendo la señal hacia atrás llegamos a B15 pin#1 donde se escucha claramente una parte más de la música. Ahora revisando B12 pin#7 se escucha ruido, por lo que se deduce que parte de nuestro problema se encuentra en esta señal.

Reemplazamos C23 y C15 4.7uF para limpiar la señal.

El LM324 ubicado en B12 fue reemplazado recientemente, por lo que se descarta falla en este elemento. Entonces debemos seguir la señal de entrada en pin#5. La cual sigue presentando ruido, debido a esto se reemplaza C7. Dicho cambio no resuelve nuestro problema. El rastro de la señal nos guía al Custom 7340 pin#9 , el cual es la salida de un arreglo de resistencias con 7 entradas alimentadas por el custom 7232 en E13.

Tras analizar esas entradas, se detecta una inconsistencia en konami 7340 pin#8 el cual presenta una señal flotando entre 1 y 2 volts sin llegar a generar la señal cuadrada completa, como las demás entradas si la tienen.

Regresamos al uso del multímetro para verificar continuidad en esa línea que conecta al konami 7232 pin#23 con konami 7340 pin#8 y se encuentra falla.
Pista_7232_to_7340.png
Pista_7232_to_7340.png (252.74 KiB) Visto 536 veces
Se repara la continuidad y ahora podemos ver una señal saludable en los puntos mencionados y que posteriormente ingresa al LM324 en B12 pin#5. Esta señal son sonidos de percusiones y algunos sonidos similares del juego.

Ahora la música del juego se escucha completa y correctamente en el punto donde se suman las señales SNDSIG, es decir en LM324 B12 pin#13.

Como se mencionó anteriormente los capacitores en etapas de audio, entre otras cosas, ayudan a filtrar el ruido en las señales. Y debido a esto, se reemplazan 2 capacitores de 100uF, 1 de 10uF y otro de 220uF. Todos ellos conectados directamente el amplificador de audio. Si algun capacitor se encuentra totalmente dañado puede generar que el recorrido de la señal se trunque y debido a esto tener interrupciones en la mezcla final de sonido.
  • Analizando problemas con las voces y efectos de sonido
Las voces dentro del juego TMNT, así como los efectos de sonido como son golpes, espadazos, etcétera, se almacenan en la ROM D18, el cual recibe sus direcciones de memoria de un konami custom 7759c y de un 74LS273 ubicado en B16.

Tras revisar con nuestro audífono en pin#5 del LA6358 (LM358) en B16 sin haber encontrado señal alguna, y tampoco de pin#3. Se revisa con osciloscopio las direcciones de memoria en el EPROM D18 y no se encontró ninguna señal diferente de 0 lógico.
diagrama_audio_efectos_voces.png
Entonces revisamos al Custom 7759c y notamos que no está emitiendo señales A0-A8, pero tampoco está recibiendo señales en I0-I7 provenientes de F15 un 74LS273. Inmediatamente revisamos las entradas en F15 y se confirma que son saludables. Por lo que se deduce falla en F15 y debe reemplazarse.

Tras el cambio se revisa la señal con audífono en pin #3 de LA6358 y seguimos sin escuchar por completo las voces. Por tal motivo verificamos nuevamente direcciones de memoria en la EPROM D18 y ahora detectamos que no se reciben señales de 74LS273 en B16. Por lo que también debemos reemplazar este circuito y tras el cambio por fin escuchamos las voces en plenitud así como también los sonidos correspondientes a golpes, espadazos, caídas, azotes, etc.

Al igual que en otras secciones de la etapa de audio, reemplazamos los capacitores para filtrar la señal y limitar el posible ruido que acarrea.

Ahora regresamos a nuestro nodo en B12 pin#13 con la mezcla de audio y por fin recibimos una señal completa durante las acciones del juego. Pero aún nos falta rescatar el tema clásico TMNT de la introducción.
  • Diagnosticando el problema de sonido en la introducción del juego
Investigando en foros de reparación y confirmando con análisis del diagrama esquemático de la PCB, encontré que el tema principal TMNT de la introducción se encuentra en la ROM ubicada en D5, la cual es susceptible a fallar, y su operación depende de 3 integrados 74LS393 que generan las direcciones de memoria, las cuales son activadas por una señal de reloj de 640kHz en E9 que pasa a través de un 74LS74 en E10, 74LS161 en D9 y un 74LS32 en G9.

Tras revisar con osciloscopio encontramos que hay una correcta señal de reloj en el cristal E9, de igual manera en el 74LS74 en E10, pero al llegar al 74LS161 en D9 solo se muestra una señal flotando entre 1 y 2 volts, misma señal que recibe el 74LS32 ubicado en G9. Y por ende al ingresar al 74LS393 en D7 el contador no inicia, debido a que este circuito es encargado de iniciar el conteo en cascada que se forma de 3 integrados 74LS393 y que termina por generar las direcciones de memoria que son enviadas a la ROM D5. Como puede verse en el diagrama.
diagrama_audio_intro.png
Un dato curioso que encontré sobre este sistema de creación de direcciones para ingresar a la ROM en D5, es que debido a que se gesta en circuitos integrados 74LS393 independientes del Z80 o MC68000, no consume ciclos de reloj de ninguno de ellos. Pues el contador en cascada genera todas las direcciones posibles de la ROM y básicamente al ir recorriendo todas ellas el contenido de la ROM se ejecuta de principio a fin.

Debido a esto lo siguiente es reemplazar 74LS161 en D9. Además lo recomendable sería cambiar los 3 x 74LS393 ya que todos ellos son Fujitsu y tienen la mala fama de fallar eventualmente.

Una vez reemplazados los integrados mencionados, se prueba el sistema y la falla ha desaparecido. Por fin podemos escuchar el clásico tema oficial de TMNT de nuestra intro. Lamentablemente, se escucha un poco saturado y lo que sigue es medir la salida proveniente del convertidor digital analógico DAC Yamaha YM-3014 pin#2 (analog out). Con la finalidad de averiguar si la saturación se genera directamente en este DAC o lo hace un etapa posterior .

Tras aplicar esta prueba y confirmando con audífono se nota saturación de audio directamente en la salida del YM3014, por lo que, para dar solución a éste problema se remplazó el YM3014, el LM358 ubicado en C10 y el capacitor de 0.033UM C68
LM358_pinout.png
LM358_pinout.png (18.91 KiB) Visto 536 veces
Conclusiones

Esta PCB del juego TMNT prácticamente tuvo todas las fallas posibles que me hubiera imaginado y por ello fué un verdadero problema diagnosticar, aunque debo agradecer que no hubo Custom Chips para reemplazar, ya que de haber existido la rehabilitación de esta placa se hubiera retrasado indefinidamente hasta conseguir otra placa similar con las refacciones adecuadas o posiblemente hubiera fracasado.

Debo mencionar que en algunos casos, gracias a esfuerzos independientes de personas admirables, se han logrado replicar los custom con componentes comerciales, solo hay que seguir la guía de ensamblado y listo.

Viendo el lado positivo de un proyecto de reparación como este. Además del reto, te ofrece una gran oportunidad de aprender y entender un poco más del cómo es que funcionan las PCB’s de la época.

Durante el proceso de reparación, nos enfrentamos a ciertas adversidades y contratiempos que en ocasiones ponen en riesgo nuestro deseo de continuar, debido a lo tedioso que implica diagnosticar el problema, así como también lo abrumador o aparente dificultad del mismo.

En muchas ocasiones se cree haber resuelto un problema, para que momentos después reaparezca el mismo error por motivos diferentes, parecía que avanzabas un paso y retrocedías dos. El deterioro de la PCB la hacía muy suceptible de fallar y difícil de diagnosticar.

Otro detalle al que se puede enfrentar es que cuando por fin se logra diagnosticar y solucionar una falla, el hacerlo descubre nuevas fallas no consideradas en un principio. Como el reemplazo del Z80 que reactivó el sonido, esto reveló una serie de fallas subsecuentes que requieren ser analizadas de manera particular. Como son la ausencia de sonido en el tema de introducción TMNT, de las voces y efectos, o la música incompleta durante el juego

Afortunadamente resultó ser bastante entretenido y hasta divertido hacerlo, quitando un poco la parte de conseguir las refacciones la cual no es tan entretenida por la situación de angustia que genera el tratar de conseguir refacciones que llevan descontinuadas desde hace más de una década, eso sin considerar en muchas ocasiones los casi irremplazables custom chips.

Debo comentar que me hubiera gustado capturar e incluir más imágenes y video de las diferentes etapas en esta reparación, pero algunas de ellas por cuestiones técnicas no me fue posible hacerlo, en otras como en el caso de las pruebas de sonido con el audífono, al conectar a la computadora para grabar las señales, simplemente desaparecen por sus bajos niveles de voltaje y hacía imposible grabarlos.

Debido a ello trate de hacer la bitácora de reparación lo más detallada posible sin obviar cuestiones técnicas que para los experimentados parecerán obvias e innecesarias pero para muchos pueden ser de utilidad, pues como mencione anteriormente, las fallas que encontré en este juego me ofrecieron una gran oportunidad de aprendizaje por su diversidad y diferentes grados de complejidad.

Como en otras ocasiones me gustaría agradecer a todos aquellos que sirvieron como fuente de información e inspiración para seguir rescatando estos grandiosos juegos. A Artemio por compartir información y por el ghetto fluke, al buen vitocheroms por venderme la placa y a mi hermano Rodrigo que se rifó con gran parte del diagnóstico y documentación.

Espero que este documento sirva para reparar alguna otra PCB

P.D.Al terminar de escribir este documento correspondiente a la reparación de TMNT 4 Players Asia, pude conseguir una memoria RAM DIP28 slim de una PCB Bootleg donadora de órganos y de esta manera reemplazar la que use con mi adaptador instalado en ubicación L13.

Avatar de Usuario
Artemio
Site Admin
Mensajes: 2227
Registrado: Lun Ago 06, 2012 5:04 pm
Cuenta de Twitter: Artemio
Ubicación: México
Contactar:

Re: [Reparación] TMNT PCB Arcade Varias fallas

Mensaje por Artemio » Vie Jul 20, 2018 7:43 pm

Como siempre muchas gracias por la dedicación y documentación, es invaluable.

Y muchas felicidades por abatir los problemas y a la frustración.

Con respecto a este detalle:
Mediante esta herramienta se deduce que hay una falla en la memoria RAM. Ahora solo queda determinar cuál o cuáles memorias RAM son las que están fallando. En la prueba de autodiagnóstico del juego, RAM ROM CHECK se indican
Un tip: Cuando hice el programa se pausa para ayudar a diagnosticar cuál es. Es hacerlo "en cámara lenta". Las líneas de control siguen activas cuando se despliega el mensaje, y se puede avanzar de dirección en dirección si no mal recuerdo.

De esta manera puedes revisar el comportamiento de la PCB, con lógica de direccionamiento y control, como si estuviese pausada. Así puedes dar con la RAM buscando el OE o CS que se encuentre activo.

Saludos y gracias!
"But for those lurking around the fringes of the masses... there is always hope for their seduction."

The Policenauts Translation Project
240p Test Suite

Avatar de Usuario
lugerius
Mensajes: 33
Registrado: Vie Nov 11, 2016 2:44 pm
Cuenta de Twitter: lugerius

Re: [Reparación] TMNT PCB Arcade Varias fallas

Mensaje por lugerius » Vie Jul 20, 2018 9:13 pm

Artemio escribió:
Vie Jul 20, 2018 7:43 pm
Como siempre muchas gracias por la dedicación y documentación, es invaluable.

Y muchas felicidades por abatir los problemas y a la frustración.
Gracias, definitivamente esto pone a prueba la paciencia como pocas cosas.
Artemio escribió:
Vie Jul 20, 2018 7:43 pm
Con respecto a este detalle:
Mediante esta herramienta se deduce que hay una falla en la memoria RAM. Ahora solo queda determinar cuál o cuáles memorias RAM son las que están fallando. En la prueba de autodiagnóstico del juego, RAM ROM CHECK se indican
Un tip: Cuando hice el programa se pausa para ayudar a diagnosticar cuál es. Es hacerlo "en cámara lenta". Las líneas de control siguen activas cuando se despliega el mensaje, y se puede avanzar de dirección en dirección si no mal recuerdo.

De esta manera puedes revisar el comportamiento de la PCB, con lógica de direccionamiento y control, como si estuviese pausada. Así puedes dar con la RAM buscando el OE o CS que se encuentre activo.

Saludos y gracias!
Si gracias, voy a checarlo, justo esta semana pude diagnosticar otra PCB con el ghetto pero esa afortunadamente resultó que pasó todas las pruebas.

vitocheroms
Mensajes: 174
Registrado: Vie Jul 31, 2015 6:47 pm
Cuenta de Twitter: @vitoche_inc

Re: [Reparación] TMNT PCB Arcade Varias fallas

Mensaje por vitocheroms » Sab Jul 21, 2018 1:52 pm

me quito el sombrero ante ti, la verdad es impresionanti

Avatar de Usuario
lugerius
Mensajes: 33
Registrado: Vie Nov 11, 2016 2:44 pm
Cuenta de Twitter: lugerius

Re: [Reparación] TMNT PCB Arcade Varias fallas

Mensaje por lugerius » Sab Jul 21, 2018 9:15 pm

vitocheroms escribió:
Sab Jul 21, 2018 1:52 pm
me quito el sombrero ante ti, la verdad es impresionanti
Gracias, afortunadamente para esta placa existe el diagrama que resulta de mucha ayuda y otros logs de reparación que igual ayudaron.
La intensión es que el documento no solo sirva para reparar unicamente otra TMNT, el hecho de que a esta le fallaban muchas cosas puede servir de guía para diagnosticar otras placas. Seguro gente con más experiencia, habilidades y conocimiento habría resuelto los problemas más rápido, aquí se trató de mostrar cronológicamente hasta donde fue posible las distintas etapas en el proceso de reparación

Avatar de Usuario
miguelangeloorti
Mensajes: 354
Registrado: Sab Jul 25, 2015 1:59 pm

Re: [Reparación] TMNT PCB Arcade Varias fallas

Mensaje por miguelangeloorti » Dom Jul 22, 2018 2:09 pm

Muchas gracias por compartir este tipo de informacion y compartirla la verdad es una super explicacion y super trabajo esta informacion y ayuda es la que necesitamos en hora buena bro muchas felicidades

Enviado desde mi SM-G955F mediante Tapatalk


Avatar de Usuario
lugerius
Mensajes: 33
Registrado: Vie Nov 11, 2016 2:44 pm
Cuenta de Twitter: lugerius

Re: [Reparación] TMNT PCB Arcade Varias fallas

Mensaje por lugerius » Dom Jul 22, 2018 9:35 pm

miguelangeloorti escribió:
Dom Jul 22, 2018 2:09 pm
Muchas gracias por compartir este tipo de informacion y compartirla la verdad es una super explicacion y super trabajo esta informacion y ayuda es la que necesitamos en hora buena bro muchas felicidades

Enviado desde mi SM-G955F mediante Tapatalk
Que bien, ojalá te sirva. Un saludo y gracias

Avatar de Usuario
lugerius
Mensajes: 33
Registrado: Vie Nov 11, 2016 2:44 pm
Cuenta de Twitter: lugerius

Re: [Reparación] TMNT PCB Arcade Varias fallas

Mensaje por lugerius » Mar Ago 07, 2018 6:25 pm

Acabo de ver que este log de reparación no puede leerse desde tapatalk, solo puede leerse correctamente desde el navegador ya sea en móvil o en escritorio.

Responder