[Reparación] Bionic Commando, no bootea

Foro para archivar logs de reparación de PCBs o hardware arcade en general.

[Reparación] Bionic Commando, no bootea

Notapor Artemio » Lun Mar 04, 2013 4:30 pm

En el lote de PCBs dañadas, había una de Capcom que se veía en buen estado. Una etiqueta que decía "Top Secret" se encontraba colgando de ella, pero no la había notado en la primer revisión. Después de ello, de inmediato quise saber si podía hacer algo para arreglarla, pues se trataba de Bionic Commando. El juego no arrancaba y sólo desplegaba la siguiente pantalla:

0-Boot.JPG
Pantalla de arranque


Lo primero que se debe hacer con una pcb que no arranca, es revisar si hay actividad en el CPU. Para comenzar, si es que hay señal de reloj. Luego si hay actividad en las lineas de datos y direcciones, confirmando que el reset se encuentre en alto; todo ello indica que el cpu está funcionando correctamente.

En este caso, el reloj estaba perfecto, pero no había actividad alguna en las líneas de datos. Procedí a extraer la información de algunas roms para confirmar de que revisión del juego se trataba, y si se encontraban en buen estado. Era la revisión americana del juego y por suerte el manual del juego cuenta con los esquemáticos de servicio, que hacen mucho más fácil diagnosticar y revisar la placa. Debo admitir que no tengo más experiencia haciendo esto que la que detalla a continuación, y he ido aprendiendo sobre la marcha. Así que después de familiarizarme con la arquitectura de la placa, asumí que algo tenía que estar muy mal. Mis sospechas se confirmaron al encontrar imágenes de la PCB en línea... le faltaba una pieza:

1-pcb.jpg
Mi PCB

1101503468.jpg
PCB Completa
1101503468.jpg (24.62 KiB) Visto 2464 veces


La PCB que faltaba - la C - contiene el código para el CPU 68000 del juego, sobra decir que no funcionaría sin ella. Se me ocurrió que podía substituirla con algo adaptado, después de todo sólo se trataba de datos, no de lógica del hardware. Por suerte dicha placa se conecta a la principal por medio de un conector en el cual entra perfectamente un cable "ide" de 50 pines, de los cuales tenía uno a la mano de una pcb pirata; y también contaba con un conector de pines para el otro extremo del cable y poder realizar la adaptación necesaria.

Con multímetro en mano me puse a confirmar las líneas de dirección desde el bus del CPU - controlado por un 74LS245 - hacia el conector, encontrando todas las direcciones, líneas de datos, la tierra y el voltaje. Apuntando todo en un papel, y después de confirmar en MAME los tamaños de las ROMS, decidí utilizar una 27c400, que aunque era del doble de capacidad de lo que necesitaba, tenía varias que uso pocas veces.

Realicé la relación de conexiones en una hoja de cálculo, y me día a la tarea de hacer una adaptación de lo que pensé podría ser muy sencillo.

2-adapter1.0.jpg
Adaptador 1.0
2-adapter1.0.jpg (59.92 KiB) Visto 2463 veces


Después de pensarlo mejor, decidí ir a buscar una placa fenólica, que no tenía en casa en ese momento, y hacer algo un poco más duradero y estéticamente mejor:

3-new adapter.JPG
Adaptador 2.0


Con ayuda de un editor hexadecimal uní las ROMs siguiendo el mapa de memoria de MAME:

ROM_LOAD16_BYTE( "tsu_02b.1a", 0x00000, 0x10000, CRC(cf965a0a) SHA1(ab88742a3225a0b82ee2dfef6ed0058d3e11c38c) ) /* 68000 code */
ROM_LOAD16_BYTE( "tsu_04b.1b", 0x00001, 0x10000, CRC(c9884bfb) SHA1(7d10cedff0a62847f8deb61a9611cc6661efb037) ) /* 68000 code */
ROM_LOAD16_BYTE( "tsu_03b.2a", 0x20000, 0x10000, CRC(4e157ae2) SHA1(cc02931376d22a7fcfc320e6fd4129e03a461a49) ) /* 68000 code */
ROM_LOAD16_BYTE( "tsu_05b.2b", 0x20001, 0x10000, CRC(e66ca0f9) SHA1(a503badf2fed38786d38c313d1dc315f3175d6de) ) /* 68000 code */


En otras palabras, las roms tsu_02b.1a y tsu_04b.1b entrelazadas un byte de cada una primero, seguidas por tsu_03b.2a y tsu_05b.2b. Emocionado corrí a probar mi nuevo Frankenstein, pero me recibió una pantalla muy similar llena de basura.

Así que asumí haber hecho algo mal, esto debía funcionar. Con la continuidad del multímetro revisé una a una todas las conexiones. Todo estaba tal cual lo había diseñado en papel. Así que fue momento de saber si el CPU estaba recibiendo los datos que según yo debería. Con el fin de realizar esto, se me ocurrió medir con el osciloscopio cada una de las 16 líneas de datos del 68000, utilizando como referencia la línea de reset del CPU. Y visualmente determinar los primero bits que llegan por el bus al cpu. con los 16 bits podría saber los primeros dos words que le estaban llegando al 68000. Y eso hice, en parte por la curiosidad de saber si podía hacer tal cosa y en parte por saber si la teoría de lo que había hecho coincidía con la realidad, o confirmar que no entiendo nada de lo que intento hacer. remarco, que sigo en proceso de aprendizaje continuo de esto.

Lo que vi en el Bus fue 1111 1110 0000 0000 seguido de 0000 0000 0001 0000, o FE 00 00 10. Exactamente lo que debería estar allí porque es lo primero que hay en la ROM que entrelacé. Justo el pensar eso me hizo darme cuenta de la posibilidad de mi error. "¿Y si el endianness es al revés?", pero de inmediato asumí que esto tenía que ser como lo hice, había corrido el debugger de MAME y los datos aparecían exactamente en el orden que lso grabé en la ROM. Por otra parte yo sabía que el 68000 (Big Endian) tiene endianness inverso al 8086 (Little Endian). Sin nada que perder, grabé la ROM con los bytes invertidos. Y cual sería mi sorpresa, el juego mostró otra pantalla. Pero en este caso, una que me informaba que la RAM principal de la PCB no se podía leer/escribir adecuadamente:

4-Work RAM.jpg
Work RAM


Ya sin quejarme mucho de que MAME me mostraba las cosas "al revés", o que yo estaba pasando por alto algo que no debería, le creí de inmediato a la pcb y procedí a desoldar las dos Work RAMs del sistema para cambiarlas por unas que funcionaran. Lo usual: desoldar, poner socket, poner una RAM que se sabe funciona y... lo mismo. Probé las RAMs que quité del sistema en el grabador de ERPOMs, y funcionaban ala perfección. Ok, algo más fallaba en la forma en que se escribían y leían los datos a la RAM que estaba causando algún problema. Y no debí saltar con cautín en mano antes de confirmar si las RAMs en verdad fallaban.

Durante mi tiempo de comida, decidí seguir el código del juego con el debugger de MAME, y así saber si realmente estaba probando las que había asumido eran las Work RAMs que cambié. No quería ponerme a desoldar RAMs aleatoriamente, con la posibilidad de causar más daño. Cabe resaltar que los diagramas claramente marcaban como /WRAM a aquellas que había cambiado, pero había mucha más RAM que al que indicaban las pruebas en toda la PCB.

Después de entender el código, confirmé que efectivamente esas eran las RAMs que se estaban probando. Ya en casa, probé si todas las líneas de control hacia la RAM se encontraban llegando bien, y así era. Revisé las líneas de datos y había ruido en ellas. Seguramente el lector que tiene más experiencia que yo en este momento sabe exactamente cual era el error, y sí lo confirmo. Mi adaptación de la EPROM estaba corrompiendo las líneas de datos, por una omisión mía. La línea de control de lectura de las ROMS estaba siempre activa en mi diagrama, y esto lo podía haber evitado de saber más o de haber estudiado el manual de la PCB con más detalle.

Resulta ser que en el manual se encuentra detallado todo el esquema de la placa C que había reconstruido, pero no en donde yo esperaba, sino más bien unas páginas más adelante. Y allí se detalla la línea de control y a que pin va. Como yo deje dicha línea en tierra en mi ignorancia, porque eso había visto en varias PCBs, la ROM alegremente respondía con los datos que yo mismo había puesto, durante la prueba de RAM pues se encontraban en el mismo bus.

Bien, procedí a corregir mi error, habiendo aprendido mucho gracias a ello. Y las sorpresas aún no terminaban:

5-Spirtes.jpg
Sprites incompletos


La diversión apenas comenzaba, el audio funcionaba perfecto, y el juego se podía jugar con los gráficos incorrectos. Por lo menos mis arreglos habían funcionado hasta el momento.

[Esta entrada continuará]
"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
Artemio
Site Admin
 
Mensajes: 1945
Registrado: Lun Ago 06, 2012 5:04 pm
Ubicación: México

Re: [Reparación] Bionic Commando, no bootea

Notapor Lunatico » Lun Mar 04, 2013 7:49 pm

Wow, realmente te mereces un aplauso artemio.
Tu documentacion es invalorable, espero en algun momento poder reparar cosas tan complicadas.
Avatar de Usuario
Lunatico
 
Mensajes: 371
Registrado: Lun Sep 17, 2012 3:16 pm
Ubicación: Monterrey

Re: [Reparación] Bionic Commando, no bootea

Notapor typesolid » Lun Mar 04, 2013 11:07 pm

quiero divertirme igual que tu Artemio, (algun dia)
typesolid
 
Mensajes: 121
Registrado: Mar Ago 14, 2012 7:03 pm

Re: [Reparación] Bionic Commando, no bootea

Notapor Artemio » Mar Mar 05, 2013 4:23 pm

@typesolid, no hay nada que te impida empezar a hacerlo. Con una punta lógica de 15 USD se puede comenzar a diagnosticar o a aprender, y es una herramienta suficiente para muchos casos. Apenas estoy empezando a aprender a usar el osciloscopio en los casos donde sea realmente necesario.

@Lunatico Pues esta basada en la de otros foros, como New Life Games y Arcade Otaku. Gracias a su tutela es que estoy aprendiendo. También por eso documento mis errores.

Bien, continuemos con el log de reparación de la PCB. Tenía como se muestra en la última imagen un layer gráfico con problemas. Curiosamente la foto no muestra el problema como realmente se veía, ya que las mitades de los sprites que siempre veía eran las superiores. Cuando tomé esa foto, estaba pasando lo que menos ocurría, mostrar los inferiores. Esto sólo sucedía al cambiar de nivel verticalmente o disparar. Pero es un buen ejemplo del problema.

Como se puede apreciar, los textos y los fondos se desplegaban perfectamente. Así que procedí a lo usual, debía tratarse de las ROMs que almacenan los gráficos, las RAMs encargadas de esa parte (si es que existían) o alguna línea de direcciones de dicha sección.

En ese momento mi entendimiento del hardware de un arcade se limitaba a que una parte de la PCB se encarga de leer la información necesaria de las ROMs, esta se mezcla de alguna manera hacia el hardware encargado de mezclar los layers de gráficos y finalmente se despliega a la pantalla. Así que empecé por buscar las ROMs que contuvieran a los sprites. Para esto MAME es nuevamente de gran ayuda:


ROM_REGION( 0x40000, "gfx4", 0 )
ROM_LOAD( "tse_10.13f", 0x00000, 0x8000, CRC(d28eeacc) SHA1(8b4a655a48da276b07f3464c65743b13cec52bcb) ) /* Sprites */
ROM_LOAD( "tsu_09.11f", 0x08000, 0x8000, CRC(6a049292) SHA1(525c862061f426d679b539b6926af4c9f14b47b5) )
ROM_LOAD( "tse_15.13g", 0x10000, 0x8000, CRC(9b5593c0) SHA1(73c0acbb01fe69c2bd29dea11b6a223c8efb54a0) )
ROM_LOAD( "tsu_14.11g", 0x18000, 0x8000, CRC(46b2ad83) SHA1(21ebd5691a544323fdfcf330b9a37bbe0428e3e3) )
ROM_LOAD( "tse_20.13j", 0x20000, 0x8000, CRC(b03db778) SHA1(f72a93e73196c800c1893fd3b523394d702547dd) )
ROM_LOAD( "tsu_19.11j", 0x28000, 0x8000, CRC(b5c82722) SHA1(969f9159f7d59e4e4c9ef9ddbdc27cbfa531eabf) )
ROM_LOAD( "tse_22.17j", 0x30000, 0x8000, CRC(d4dedeb3) SHA1(e121057bb541f3f5c755963ca22832c3fe2637c0) )
ROM_LOAD( "tsu_21.15j", 0x38000, 0x8000, CRC(98777006) SHA1(bcc2058b639e9b71d16af05f63df298bcce91fdc)


Revisé las lineas de datos, direcciones y control sin que estas mostraran problema alguno. Ya que me había adentrado en el código del juego gracias al debugger de MAME, y porque suponía alguna RAM debía estar causando el problema; además de la flojera que me daba revisar todos y cada uno de los TTLs involucrados en el video, decidí alterar el código del juego para que revisara las RAMs que no se revisaban al arrancar el juego. Nuevamente, de MAME:


0x000000, 0x03ffff) ROM
0xfe0000, 0xfe07ff) /* RAM? */
0xfe0800, 0xfe0cff) spriteram
0xfe0d00, 0xfe3fff) /* RAM? */
0xfec000, 0xfecfff) txvideoram
0xff0000, 0xff3fff) fgvideoram
0xff4000, 0xff7fff) bgvideoram
0xff8000, 0xff87ff) paletteram
0xffc000, 0xfffff7) working RAM


Cuando el juego arranca, después de inicializar la memoria de video y paletas de color para desplegar el texto, arranca a revisar la Work RAM, seguida de VRAM, Scroll 1, Scroll 2 y luego la ROM. ¿A que corresponde cada uno de ellas? Algunas son fáciles de adivinar del código de MAME y la documentación. Working RAM es la misma que Work RAM, pero ¿cuáles son VRAM y las dos scroll? Me interesaba saberlo para tener indicios de cuales de los - por lo menos - 14 chips de RAM de ambas placas debía revisar.

Un análisis de las líneas me llevaron a deducir las que arriba estan marcadas en negritas como las que se revisan al arrancar, asi que eso me dejaba la memoria de paleta, la de sprites y las no identificadas. Decidí alterar el código ya existente, y substituir la rutina que revisa la work RAM y VRAM por la sprite RAM y la de paleta. Por si a alguien le sirve, estas son las direcciones de ROM en el mapa de memoria del juego donde se realizan dichas validaciones:

Work RAM $2b934
VRAM $2b962
Scroll 1 $2b992
Scroll 2 $2b962
ROM $2b9f2

Subrutina general de comprobación $2baf6


Aquí el código desensamblado de cuando se manda a revisar la dirección de la work RAM:

Código: Seleccionar todo
02B934: 41F8 C000                  lea     $c000.w, A0
02B938: 43E8 3FFE                  lea     ($3ffe,A0), A1
02B93C: 7E01                       moveq   #$1, D7
02B93E: 45FA FEE2                  lea     (-$11e,PC), A2; ($2b822)
02B942: 4DFA 0006                  lea     ($6,PC), A6; ($2b94a)
02B946: 6000 017E                  bra     $2bac6


(Nota: El formato de las líneas es del desensamblador de MAME: La dirección seguida de dos puntos, el binario de ejecución e hexadecimal y la instrucción y sus parámetros desensamblados.

En la primer línea, se carga hacia el registro A0 la dirección $c000 en formato word, lo cual llena A0 con 0xffc000, que es la dirección de la work RAM; de allí carga en A1 la dirección de A0 más $3ffe, para indicar el final de la comprobación. La tercer línea sólo carca 1 a D7, lo cual le indica ala subrutina que revise esa memoria de un byte en un byte. Las dos siguiente slíneas indican a donde brincar el código en caso de éxito o fracaso, y la última mand allamar la rutina encargada de la comprobación.

La comprobación de la RAM es en realidad sencilla, recorre el rango de direcciones grabando un dato a la RAM y luego leyéndolo. Si los datos coinciden, la RAM se asume que funciona. Si no coinciden, se brinca a la rutina que imprime "NO GOOD" y el juego se queda congelado.

Código: Seleccionar todo
02BAC6: 2648                       movea.l A0, A3
02BAC8: 203C AAFF 5500             move.l  #$aaff5500, D0
02BACE: 7203                       moveq   #$3, D1
02BAD0: 204B                       movea.l A3, A0
02BAD2: 1410                       move.b  (A0), D2
02BAD4: 1080                       move.b  D0, (A0)
02BAD6: B010                       cmp.b   (A0), D0
02BAD8: 6612                       bne     $2baec
02BADA: 1082                       move.b  D2, (A0)
02BADC: 41F0 7000                  lea     (A0,D7.w), A0
02BAE0: B1C9                       cmpa.l  A1, A0
02BAE2: 63EE                       bls     $2bad2
02BAE4: E088                       lsr.l   #8, D0
02BAE6: 51C9 FFE8                  dbra    D1, $2bad0
02BAEA: 4ED6                       jmp     (A6)


Yo quería cambiar dos cosas, primero que revisara otros rangos de direcciones. Y en segunda, que si fallaba no se quedara congelado el juego, quería que se quedara revisando ese mismo segmento de RAM para que yo pudiera físicamente detectar cual estaba activa y así reemplazarla sin descifrar nada más. El código de las demas revisiones es muy similar, de hecho sólo se ponen los parámetros y se manda a llamar la subrutina en 02BAC6.

Así que las modificaciones serían muy sencillas, cambiar la dirección de RAM y tamaño a revisar, y en segundo lugar cambiar la dirección de salto después de un fallo, para apuntar hacia el comienzo del chequeo nuevamente. Es decir cambiar 41F8 C000 por 41F8 8000 y 43E8 3FFE por 43E8 07FE para revisar la palette RAM en lugar de la Work RAM, y algo similar con la Sprite RAM en lugar de la VRAM. Sólo modificar unos 6 bytes en total de la rom, y a probarla en MAME.

Pues sorpresa, MAME me corrompía toda la memoria al hacer los cambios de JMP a otras direcciones para hacer las pruebas en loop, al grado de nisiquiera comenzar a ejecutarse. Pero sí me permitía correr con solo los loops de escritura y lectura de los nuevos segmentos de RAM. Boté MAME y decidí probar mis cambios en el hardware, que corrieron perfectamente. Salvo un detalle, me marcó que la Work RAM fallaba, es decir la Palette RAM. Felizmente procedí a desoldarla, me hizo sentido ya que en MAME el juego arrancaba con un fondo negro, y mi placa arrancaba con un fondo ros como se ve en las fotos arriba.

DSC_0685.JPG
RAM cambiada (izquierda)


Cual sería mi sorpresa debido a que efectivamente el fondo era ahora negro, pero seguía fallando mi prueba. Cambié la RAm de junto también, y el resultado era el mismo. Y entonces me dí cuenta de algo evidente. La placa nos las revisaba porque eran RAMs de sólo lectura, revisé los diagramas y efectivamente el CPU no tiene manera de leer esas RAMs, sólo de escribirlas. Era obvio, ¿para que iba a querer leer esa RAM el código del juego? Por eso la prueba siempre iba a fallar. Y como MAME sí me había permitido escribir y leer estas direcciones, había seguido delirando que era posible. MAME no emula estos niveles de detalle.

Había aprendido mucho de juego, pero había desperdiciado mi tiempo en cuanto a la reparación... sin mencionar que habla desoldado dos RAMs. Ya que casualmente una de ellas efectivamente estuviera dañada y los colores estaban mal - en el booteo principalmente - era otra cosa. Mi diagnóstico había sido erróneo, y me había dejado llevar por la emoción de estar jugando con el código del juego, aunque fuese ligeramente.

Así que me puse a revisar las cosas manualmente, que era lo que quería evitar usando mi diagnóstico por software. Ya no probé el código que revisaba la sprite ram, y me dí a la tarea de revisar los TTLs.

Mientras hacía eso, sin querer se me cayó la punta del osciloscopio sobre la placa, causando un corto. No le di mucha importancia pero el juego se veía mal. Apagué y prendí para ver si era algo temporal.

Y sorpresa:

6-Scroll.JPG
Scroll RAM: NOT GOOD


Había jodido la Scroll RAM.

[continuará]
"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
Artemio
Site Admin
 
Mensajes: 1945
Registrado: Lun Ago 06, 2012 5:04 pm
Ubicación: México

Re: [Reparación] Bionic Commando, no bootea

Notapor Artemio » Mar Mar 05, 2013 5:22 pm

Después de recobrar la paciencia, procedí a desoldar la Scroll 1. Aquí sí utilicé mi código modificado para que se pusiera a revisar siempre la RAM y así identificarla fácilmente, por ello en la foto no se alcanza a ver el texto de NOT GOOD.

La ironía de que el código sirviese para algo después de todo... para reparar algo causado por mí. Después de desoldar la RAM:

8-scroll.JPG
Scroll RAM desoldada, contra luz


El juego regresó al mismo estado, y comenzó la búsqueda de nuevo. Por puro deporte la desoldé recuperándola, lo mejor en estos casos es desoldarla sin importar el chip y cuidando no dañar la PCB. Pero aquí l aprueba de mi daño durante el corto a la RAM:

9-Scroll.JPG
Prueba de scroll RAM


Así que me dí a la tarea de revisar toda la lógica de la placa, comenzando desde la lectura de las ROMs. Con un plumón verde marcando cada chip, y la verificación consistió en revisar las entradas y salidas del chip. Buscando alguno con daño evidente.

10-Docs.JPG
Docs


Gracias a ello, entendí mucha de la lógica del juego y su funcionamiento. Pero todo lo que revisé estaba funcionando perfectamente.

Ya desesperado, empecé a intentar la técnica del "piggyback". Es decir, montar un chip que funciona sobre el que se sospecha que tiene daño. Y si hay algún cambio o se arregla, asegurarse y reemplazarlo. Hacer piggyback tiene sus riesgos, ya que se pueden arruinar ambos chips al hacer la prueba. Pero en este caso resultó bien.

Así dí con la un cambio drástico al montar un 6116 sobre la RAM de direcciones hacia los sprites. Salían dobles, llenando las líneas que siempre me aparecían mal. Viendo una salida, procedí a cambiarla. Ya a estas alturas me había acabado las RAMs que había recuperado de una Street Fighter II pirata.

Y quedó:

b5028e7a4c801a094fff19fce8fd7447_full.jpg
Bionic Commando


Pero no me dió el gusto que esperaba. Y no pasó eso, porque el diagnóstico no fue puntual. Me la pasé dando tumbos y cometiendo errores. Yo sabia que la causa podía ser RAM, pero no la supe detectar con precisión. Sé que estoy aprendiendo a hacer esto, y aprendí mucho de esta reparación... Incluso hice más cosas de las arriba documentadas, como sustituir una PROM 63s141 que mi lector no puede leer ni escribir, con un adaptador a 27c256 ya que dicha PROM generaba mucho ruido (esto no arregló el problema, así que revertí dicha modificación).

Acto seguido, procedía jugar el título. Tenía más de 20 años de no verlo, y cuando lo jugué de pequeño nunca pude meter más de un par de fichas.

Que un juego te parta el trasero después de arreglarlo... =) eso es gratitud.
"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
Artemio
Site Admin
 
Mensajes: 1945
Registrado: Lun Ago 06, 2012 5:04 pm
Ubicación: México

Re: [Reparación] Bionic Commando, no bootea

Notapor ronalvel » Lun May 08, 2017 12:25 pm

Leí cada parte de la reparación y es increible tu trabajo, recién ahora estoy tratando de entender algo para reparar mis placas, gracias por enseñarnos.
ronalvel
 
Mensajes: 1
Registrado: Lun May 08, 2017 11:32 am

Re: [Reparación] Bionic Commando, no bootea

Notapor Artemio » Lun May 08, 2017 4:41 pm

Gracias por tu amable comentario ronalvel. Es sólo compartir lo mismo que he aprendido en la red, y ayudar a que otros puedan aprender y compartir también.
"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
Artemio
Site Admin
 
Mensajes: 1945
Registrado: Lun Ago 06, 2012 5:04 pm
Ubicación: México


Volver a Reparaciones

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado

cron