Arcades MX

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:
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:
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.
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:
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:
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:
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á]

Wow, realmente te mereces un aplauso artemio.
Tu documentacion es invalorable, espero en algun momento poder reparar cosas tan complicadas.

quiero divertirme igual que tu Artemio, (algun dia)

@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:
(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.
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.
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:
Había jodido la Scroll RAM.

[continuará]

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:
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:
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.
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ó:
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.

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.

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.