EXERION - Solamente muestra marcadores, no juega [SOLUCIONADO]

[Marcos75]

Hola a todos.

Aprovechando que existen esquemáticos de esta placa, que no tiene customs y que, por tanto, hay bastantes posibilidades de echarla a andar, voy a tratar de postear paso por paso todo lo que vaya haciendo durante la reparación.

Antes de nada, el estado inicial:



Creo que esta es la cuarta placa que he tenido como esta. Todas ellas con las pegatinas de SEGA, y todas con el invento de cables amarillos que veis en la parte izquierda inferior de la imagen. No sé para que es: parece tomar una señal de la placa, la invierte con un 74LS04 puesto a caballo sobre otro integrado de la placa, se amplifica con un transistor de potencia, y se lleva al conector, en un punto donde la placa por diseño no tiene nada conectado. Parece un tema "español" (ninguna foto de la placa que he visto por ahí lo lleva), y no sé muy bien para qué será (no sé si será una luz para alguna bombilla del mueble, o algo similar). Se lo quitaré (en otra que tengo se lo quité y funciona perfectamente). También le quitaré las pegatinas de SEGA, porque se caen a cachos y porque están las originales de JALECO debajo.

Tengo esta placa desde hace muchos años. En mis notas tengo: "Solamente se veían los marcadores. Un Z80 no hacía nada. Falta xtal de 20MHz". Ricky si ve esto estará moviendo la cabeza de lado a lado diciendo: "a quien se le ocurre quitarle el cuarzo a una placa..." Se ve que en algún momento necesité un cuarzo de 20 MHz, y se lo quité. La verdad es que es pan para hoy, y hambre para mañana: si le quitas hoy un componente a una placa "reparable", mañana te va a hacer falta

El caso es que tras lavarla, adecentarla, y ponerla el cristal, la placa tiene una pinta cojonuda:



Pero el problema sigue ahí:



Lo curioso es que meto créditos, y suben al marcador, pero no hace nada más, ni suena.

Editaré este mismo post contando los avances.

Un saludo.

ACTUALIZACIÓN 1

El primer paso ha sido el que menos me gusta, pero ya está hecho: inspección visual para ver que no haya ninguna pista rota, ningún pin tocándose con otro, etc. Todo parece normal. Luego he leído las EPROMs, y he comprobado las tres RAMs 6116 que hay en zócalo, con el programador. Las RAMs están bien.

Cuando he ido a comprobar las ROMs con MAME, me doy cuenta de que MAME tiene unas lecturas extrañas: son 11 EPROMs 2764 en lugar de 9 (7 x 2764 y 2 x 27128) como tiene mi placa. Las fotos que he visto por internet tienen todas 9 EPROMs, como mi placa, incluso los esquemáticos hacen referencia a 9, no 11 EPROMs.

La correspondencia entre las ROMs de MAME y las de mi placa es la siguiente:

Mi Placa	ROM MAME	Función
1	3	Background
2	4	Background
3	1	Background
4	2	Background
5	7+ 8 (9 bytes diferentes)	Main CPU
6	9 (4 bytes diferentes)	Main CPU
7	5	Sub CPU
8	6	Foreground chars
9	11 + 10	Sprites

Como veis, hay unos pocos bytes de diferencia, todos ellos en el programa principal, lo que puede ser achacable a una ligera variación de versión (lógica, si tenemos encima en cuenta que la distribución de EPROMs es distinta). Por ello pienso que las ROMs están todas bien.

Otra cosa, lo único que se ve en mi caso son los Foreground chars, ni Background ni sprites... Es decir, la ROM 8 parecer estar siendo gestionada, pero las 1, 2, 3, 4 y 9 no.

ACTUALIZACIÓN 2

De momento he utilizado solamente la punta lógica. Me voy a centrar en revisar los bloques principales de la CPU principal, y la CPU secundaria. Os pongo un par de imágenes de dichos bloques. A la izquierda la principal, a la derecha la secundaria:

   

En la zona de la CPU principal compruebo el Z80: todas sus líneas de direcciones y datos tienen actividad, hay pues CLK, el RESET funciona sin problemas, READ y WRITE tienen actividad, y lo único que me llama la atención es que no hay interrupciones (ni /NMI ni /INT). Voy a los esquemáticos, y veo que efectivamente es así. La única interrupción que admite esta CPU es la de meter moneda. Por eso veo ese efecto extraño de que cuando meto una moneda sube al marcador, realmente la CPU principal está trabajando.

Compruebo los buses de direcciones y el bus de datos (5P, 6P y 2P en la imagen de la izquierda). Tienen actividad normal: sus entradas y salidas son coherentes, tienen actividad, y las señales de control (ENABLE, y selector de DIRECCIÓN) son coherentes, tienen actividad. Hay que decir que en un bus de direcciones lo normal es que la dirección del bus (valga la redundancia) sea única, ya que es la CPU la que genera las direcciones. Por eso esta señal está fija a nivel alto, lo cual es lógico. De hecho se ve en los esquemáticos que está conectada a Vcc.

Luego me voy al decodificador de direcciones, compuesto en este caso por 3 demultiplexores (2 x 138s en 3M y 3P, y 1 x 139 en 3R). Aquí empiezan mis dudas. Para empezar el 139 tiene dos salidas siempre a nivel alto (marcadas en rojo en la imagen). Eso hace que el 138 en 3M no esté habilitado, con lo cual queda "inutilizado" (tachado en rojo en la imagen). Malo, porque como veis genera una serie de señales de control que, por su nombre, parecen importantes

Por otro lado el otro 138, en 3P, solamente tiene una señal activa. De hecho, no tiene activa la que marco en verde, señal que luego "echaré de menos" en la CPU secundaria.

Con el comparador, los dos 138s y el 139 están bien. Aún así el 139 me ha parecido tan sospechoso que lo he cambiado. Ya en una ocasión un 138 no me "cantó" con el comparador, y resultó estar mal. En este caso no he tenido tanta suerte. Todo sigue igual.

Con respecto a la CPU secundaria, en la imagen de la derecha podéis ver el bloque principal. Aquí las cosas están peor. Determinadas líneas de direcciones no tienen actividad, y solamente tiene activa la señal READ; WRITE nunca se activa. Eso hace que la RAM nunca se escriba. Sin embargo a nivel de lectura todo parece normal, y la ROM se está habilitando para lectura, aparentemente.

El decodificador de direcciones, el 138 de 3T, parece tener un comportamiento normal. Sin embargo, tenemos al 374 en 2S, que es el interfaz con la CPU principal, y que tiene su CLK sin actividad. Me da a mi que ese es el principal motivo de que la CPU secundaria no esté haciendo nada. Ese CLK viene del 138 en 3P (address decoder de la CPU principal), y es la señal que os decía que "echaría de menos". Entiendo pues que no hay comunicación entre CPU principal y CPU secundaria, y esto es la pescadilla que se muerde la cola.

Como siguiente paso tengo sacar el osciloscopio, a ver qué veo, y sacar la placa que tengo funcionando, para leer las EPROMs y asegurarme de que los pocos bytes de discrepancia en las ROMs de programa que tengo con MAME, son normales.

ACTUALIZACIÓN 3

Bueno, pues me he puesto otro rato esta tarde con la placa, y la he dejado reparada. El que la sigue, la consigue

En este caso había pasado por el error varias veces, sin detectarlo. El buffer principal del bus de datos (un 74LS245) estaba mal. Poniendo otro encima, la placa funciona perfectamente, así que lo he cambiado.

El error se me había pasado por confiar demasiado en lo que muestra la punta lógica. Como veía actividad a ambos lados del buffer, pensé que todo iba bien, pero no es así. Cuando tenemos integrados con salidas tri-estado (es decir, que conectan a buses) hay que tener cuidado, ya que la actividad que vemos puede ser generada por el integrado, o por cualquier otro elemento del bus. Es decir, podemos pensar que nuestro integrado está generando salidas buenas, y en realidad tener todas sus salidas en alta impedancia (que es lo que seguramente estaba pasando en este caso).

Hace poco reparé una Snow Bros. en la que este problema era evidente, ya que la señal que estaba a la entrada del integrado dejaba las luces de la punta lógica fijas (alta frecuencia), pero las que veía en la salida (bus) hacían parpadear los LEDs (baja frecuencia), lo cual no era coherente. Pero generalmente ambas señales serán de alta frecuencia, y con la punta lógica no detectaremos estos errores, teniendo que ir al osciloscopio (o al método prueba / error, que es lo que he hecho yo aquí).

[elnaib]

Hola Marcos,

Si necesitas las lecturas o algo dimelo ya sabes que tengo la placa que me regalaste.

Un saludo

[Rockman]

Hola Marcos!

Te has fijado en el codigo de Mame que existe la version exeriont que tiene una configuración de memorias igual a la tuya, pero con la numeración cambiada? Esta es la versión licencia de Taito para USA pero oficial también.
La versión boot que está en Mame también tiene la configuración de la tuya.
Quizás la versión original de Jaleco con 11 roms es muy escasa y no se suele ver.

Esos cuatro bytes diferentes del codigo de la CPU no harán que no se pinten sprites y los fondos y no suene la musica?
Hay acceso de datos, se activan enables y Chip selects de las memorias de los graficos y sonido?

Saludos.

[Marcos75]

Gracias por el ofrecimiento, elnaib. Me quedé yo con otra que funciona bien, con lo que podría tener acceso también a las lecturas de una placa buena.

Rockman, esas dos versiones no tienen exactamente la misma configuración de ROMs que la mía. Sí agrupan en dos ROMs el código principal, en lugar de en tres, pero no agrupan la información de sprites en una ROM, como lo hace mi placa... La verdad es que al no ser mi placa ni bootleg ni la versión americana, ni he comparado mis lecturas con esas versiones...

Mañana os cuento más detalles. Básicamente lo que he visto es que la placa se comporta como si no tuviese la sub-CPU. De hecho, si la quito, el error es el mismo. En la CPU principal todo parece normal.

Un saludo.

[Bubu]

Bien pudiera pasar que un Z80 se encargue de la detección de la moneda, y el otro Z80 del juego en sí, y el único Z80 que te funcione (o esté actuando correstamente) fuera el de la moneda.

Por cierto, el Exerion recuerdo que fue un juego que descubrí con MAME hace la pila de años, y me dejó perplejo el efecto 3D del movimiento, ¡¡del año 83!! Lo he jugado muchas veces, es alucinante.


Me apunto este hilo, esto es emocionante. Gracias muchas por contar tantos detalles ;-)

[Rockman]

Es verdad Marcos, se me escapó el detalle de las dos roms de Sprites convertidas a una sola en tu placa.

Habrá que revisar entonces todas las señales de control de la segunda CPU, que efectivamente se encarga del sonido y graficos.

[Fortuna]

Huh, me huele que es una placa mas antigua, quien sabe, en esas sea un set que no hay en MAME y sea un set nuevo no emulado

[Marcos75]

Ando más perdido que un camello en un garaje. Esta tarde le dedicaré otro rato, de momento os cuento lo que he ido viendo (Actualización 2).

Bubu, el "misterio" de la moneda parece aclarado. Esta placa tiene una gestión de la moneda realmente extraña...

Fortuna, quizá más moderna en lugar de más antigua. Lo que es seguro es que, efectivamente, este set no está en MAME.

Un saludo.

[Rockman]

A ver quién es el causante de que no tengas la señal IO2...

Si dices que el decoder 139 está bien pero genera problemas en los 138 que están colgados de él... Las entradas del 139 parecen coherentes?
Si dices que todas las señales de la cpu principal van ok, y el 139 ko.... tenemos un problema. Al sustituirlo ya ha empezado a trabajar bien? Me has dejado con la duda.

A ver si aparece esa señal IO2 (y las demás) de esos decoders. Las entradas que hay en juego ahí son los bits altos de memoria. Decias que la cpu principal pulsaba todo correcto. O son los causantes los decos o algo en el bus los hace atarse. (Por probar hay justo por ahí unas puertas logicas colgadas de las entradas del 139 que podrían causarte problemas si están mal.)

Estoy a la espera de los avances.

[Marcos75]

Hola Rockman.

De momento he dejado esta placa en suspenso. Al final cambié todo el "address decoder" de la CPU principal (el 139 y los dos 138) pero nada cambia.

El caso es que la placa se queda parada en la secuencia de arranque. Es decir, no es que tenga un problema de video y de sonido, y que por eso solamente se muestren los marcadores. Es que esta placa arranca así. Pero no progresa. He leído en el driver de MAME que es un poco extraño el sistema de protección que tiene, comprobando en determinadas ocasione un checksum y comparándolo con un valor esperado.

Mi hipótesis es que no progresa en una de esas comprobaciones. Por ello sospecho que algo "al otro lado del bus de datos", en una zona de direccionamiento distinta al código, está mal, y es lo que provoca que el checksum sea incorrecto. Tengo dos opciones, buscar por buscar, a ciegas, o desensamblar el código, seguir la secuencia de arranque, y así saber dónde va a realizar cada checksum. Ninguna de las dos opciones me atrae mucho, así que la he dejado.

Mientras he arreglado una City Connection y una Pocket Gal, a ver si subo el log de reparación. De momento estoy parado, porque me he quedado sin soldador. Mi pobre JBC... ¡snif!

Un saludo.

[enkonsierto]

casualmente tengo una mutant fighter que le ocurre prácticamente lo mismo (sólo muestra el texto de créditos y funciona y todo cuando introduces moneda, hasta suena), pero necesito tiempo para comprobar y comparar con otra mutant que tengo funcional.

[Rockman]

Vaya te ha cascao el soldador, que pu*ada...
No se si tenía sus años o era nuevo, dicen que los jbc de ahora no aguantan tanto trote, pero vaya esos soldadores son muy duraderos. Tocaré madera que no le pase nada al mío por decirlo.

Ya que estas parado con el estaño, puedes probar de grabar un set con el código de la cpu principal del Mame. Que no fueran por un casual esos 4 bytes de diferencia, que te provoquen un error en las comprobaciones de checksum. No se si lo has probado ya.

Saludos.

[Marcos75]

Pues tenía ya 10 años. Le tenía mucho cariño. El de ahora es negro, ya no tiene el típico color naranja y blanco de los JBC...

Lo del set de MAME ni lo he intentado, porque no coincide en cuanto al número de ROMs (esos pocos bytes de diferencia bien pudieran justificar la variación), y porque la otra placa Exerion que tengo funcionando también tiene esos bytes de diferencia, y funciona perfectamente...

enkonsierto, tu error es distinto al mío. En tu caso el código principal sí parece correr, con lo cual el error debes buscarlo en otra parte. En mi caso todo apunta a que la CPU entra en un bucle infinito.

Un saludo.

[Rockman]

Es verdad Marcos, ahora creo que todos son negros. Será cuestión de modas.

Te iba a decir que aunque haya diferencias en el numero de roms pero se mantenga el tamaño total, siempre se pueden unir o separar con un editor hex para ajustarse al tamaño de memorias, no tiene porque haber problema.
Ahora si tienes otra placa operativa y el codigo es el mismo, LO DESCARTAMOS.

Conclusion, el problema esta en el hardware. :-P

[enkonsierto]

enkonsierto, tu error es distinto al mío. En tu caso el código principal sí parece correr, con lo cual el error debes buscarlo en otra parte. En mi caso todo apunta a que la CPU entra en un bucle infinito.

Eso es cierto, yo creo que la culpa es del set de roms, pero tengo que pararme a comprobarlo. A ver si con tiempo lo hago.

[Marcos75]

Actualizo el primer post, he conseguido reparar la placa.

Un saludo.

[pirilipi]

Hace poco reparé una Snow Bros. en la que este problema era evidente, ya que la señal que estaba a la entrada del integrado dejaba las luces de la punta lógica fijas (alta frecuencia), pero las que veía en la salida (bus) hacían parpadear los LEDs (baja frecuencia), lo cual no era coherente. Pero generalmente ambas señales serán de alta frecuencia, y con la punta lógica no detectaremos estos errores, teniendo que ir al osciloscopio (o al método prueba / error, que es lo que he hecho yo aquí)

hola, estoy leyendo los post para aprender y me surgio una duda con respecto a los buffers ( 245 por ejemplo) . entiendo que la punta logica muestre actividad y nos oculte el chip malo. pero como me doy cuenta usando el osciloscopio?, la señal se veria de una forma en los pines del 245 y distinta en otra parte del bus?